23 Jan
2012
23 Jan
'12
4:57 p.m.
A while back, I mentioned that I'd found and potentially fixed the
"bricking" problem with the CQD-220.
To recap, for those that werent following, the problem lies in the code for the on-board
8086 when you set the number of both disks and tapes to zero. The 8086, during its
routine to load the values from the EEPROM, loads the total number of disks and tapes and
executes a loop with a counter predecrement; if the counter is loaded as 0, it effectively
runs through the loop 256 times instead of 7 (the max), which spins out of control and
blows away some RAM somewhere before crashing.
Fortunately, through a compiler bug or some such, there are 5 bytes available from a
totally redundant instruction (loading a value into a register where the same value is
already loaded) in just the right place to test the total number of devices and jump to
the "uninitialized device table in EEPROM" section of the routine if it is zero.
With one byte to spare! (good thing NOP is only a byte in 8086)
This applies to the A7A revision of the ROM, anyway; I haven't gotten to the A8
version yet, though I know it exhibits the same bug. Hopefully it also has the same
redundant instruction. In any case, I should be able to find and fix it quickly once I
have the time, because I know where to look.
So, here's the thing; I've finally gotten the time to test the fixed ROM image
(was temporarily short of 27256 chips, but that's been resolved) and I'd like to
get the fixed images somewhere they'll be easy to find if anyone else runs into the
same problem (this took me over a year of sporadic attention to fix). Does anyone know
where I should post this? There's my own website, which is really not a thing
anymore, but there are probably lots of places Google is more likely to find.
Also, are there copyright implications to consider? I know CMD is long gone, but I still
worry about these things.
Last thing: does anyone know the difference between the A7A ROM and the A8? I've not
found anything different; I assume it's probably an obscure bugfix.
The images are only 64K total, so I shouldn't imagine they'll be bandwidth
intensive.
- Dave