[Coco] Flash updated Dragon DOS into SDC... help!

Pere psergm at gmail.com
Sun Mar 13 04:26:38 EDT 2016

Hi Rogelio,

> I did try to use the updater VDK file as it is released but on the Dragon
> DOS/SDC release I had on my card, the WRITE commands of the BASIC updater
> program came off as unrecognized tokens, flagged by ! characters.
The VDK updater disk will only work if you start the Dragon with an old 
version. If you satrt with the DOS/SDC version for CoCo or the one by 
Sixxie, then
the commands I added will not be recognized at all, will show the '!' sign 

> I also tried to snoop out the BIN file LOADM address out of its preamble,
> but being it a data file more than an executable binary program, I hinted
> that the preamble calculated load address would be meaningless, the length
> reported on the file with the 'preamble' read as is was even more out of
> bounds than the 'load' address - the update BIN file did have the codes 
> for
> characters D and K properly set on the first two bytes - a Disk ROM file.
> More on this later...
The BIN file in that disk, is really the ROM saved in XRoar to disk, so it 
a std Dragon header (9 bytes) that contains:
$55, $02, LoadAdrs, Length, Exec, $AA
The LoadAdrs should be $3000 'cause it has the DOSPlus50 and the extender.
Length should be $3F00 and exec the same as Load.
So, loading it into the Dragon with simply:
LOAD"UPD2503.BIN"     it will occupy from $3000 to $6F00
Then you could issue WRITE MEM @bank without parameters and this will flash
the chosen bank with default values ($3000, $C000,$3F00)

> Been playing with the Dragon setup all morning, no problems found on any 
> of
> the VDK images loaded. Now any updates should be a cinch to do using the
> Dragon - heard 2504 is out... later.
Now that you have the v0.25.03 you could use the Basic program UPD2504
that comes in the VDK Updater disk to get the new v0.25.04 in any bank.

> I am not sure how the BIN updater file in the 2503 distribution VDK got
> such padding at its start and end... MS Windows?
This file is created by a batch file while compiling.
The binary file has NO padding at the beginning, just the Dragon std header.
It consists of the DOSPlus and then the extender, being rounded to a
multiple of 256 bytes padding it right with zeros.
The lowercase 'dk' is the signature for a DISK image, whilst 'DK' is the one
for a DOS system ROM.
My VDKs are DW4 compatible, so they have a header 256 bytes long that 
some 8 geometry bytes data and padded with zeros to the end.


More information about the Coco mailing list