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
23 Jan
23 Jan
5:53 p.m.
On Mon, Jan 23, 2012 at 4:57 PM, David Riley <fraveydank at gmail.com> wrote:
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.
On my CQD-220/TM with original CMD labeled EPROMs I have F220Y1A8 /
F220Y2A8. Is that the same A8 version to which you refer?
I also have .HEX files for a CQD-220/TM B2A Release 06/24/94:
220Y1B2A.HEX
220Y2B2A.HEX
And a CQD-220/TM B3 Firmware 09/23/94
F220Y1B3.HEX
F220Y2B3.HEX
I wonder what is different between the A8 and B2A and B3 versions. I
don't think I have ever tried loading the B2A or B3 versions on my
CQD-220/TM.
-Glen
6:16 p.m.
On Jan 23, 2012, at 8:53 PM, Glen Slick wrote:
On Mon, Jan 23, 2012 at 4:57 PM, David Riley
<fraveydank at gmail.com> wrote:
Yes, in fact I'm pretty sure I got the image files from you. :-)
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.
On my CQD-220/TM with original CMD labeled EPROMs I have F220Y1A8 /
F220Y2A8. Is that the same A8 version to which you refer? I wonder what is different between the A8 and B2A and
B3 versions. I
don't think I have ever tried loading the B2A or B3 versions on my
CQD-220/TM.
Not a clue. The locations aren't identical on the A8 rev, but they're very close
(within a few lines worth, say about 20 bytes). The reset vector code at 0xFFFF0 does a
bit more initialization than the A7A version as well (the A7A just does a "jmp
0xF000:0x0200", the A8 zeroes two memory locations). I don't have the need to
examine it further, so I probably won't, but if anyone has any idea, it might satisfy
my curiosity.
- Dave
23 Apr
23 Apr
1:09 p.m.
On Jan 23, 2012, at 8:53 PM, Glen Slick <glen.slick at gmail.com> wrote:
On Mon, Jan 23, 2012 at 4:57 PM, David Riley
<fraveydank at gmail.com> wrote:
Old topic, but somewhat pertinent: Sweden's Update computer club
seems to have the release notes filed.
ftp://ftp.update.uu.se/pub/pdp11/doc/cmd/
Are the firmware images still available somewhere? I want to see
if updated firmware will fix the hang problem I'm having booting
the VMS 7.3 CD (it boots, but hangs while trying to start the
standalone backup; this happens when my Pioneer CD drive is
jumpered for 512 or 2048 byte blocks). I can't seem to find CMD's
site anymore, though I could swear someone linked it around here
not long ago.
- Dave
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.
On my CQD-220/TM with original CMD labeled EPROMs I have F220Y1A8 /
F220Y2A8. Is that the same A8 version to which you refer?
I also have .HEX files for a CQD-220/TM B2A Release 06/24/94:
220Y1B2A.HEX
220Y2B2A.HEX
And a CQD-220/TM B3 Firmware 09/23/94
F220Y1B3.HEX
F220Y2B3.HEX
I wonder what is different between the A8 and B2A and B3 versions. I
don't think I have ever tried loading the B2A or B3 versions on my
CQD-220/TM.
1:34 p.m.
On Tue, Apr 23, 2013 at 1:09 PM, David Riley <fraveydank at gmail.com> wrote:
On Jan 23, 2012, at 8:53 PM, Glen Slick <glen.slick
at gmail.com> wrote:
The most recent CQD-220/TM image I have from the CMD website archive is:
CQD-220/TM B3A.02 Firmware - 10/17/95
http://web.archive.org/web/19961226090415/http://www.cmd.com/ftproot/pub/de…
On Mon, Jan 23, 2012 at 4:57 PM, David Riley
<fraveydank at gmail.com> wrote:
Old topic, but somewhat pertinent: Sweden's Update computer club
seems to have the release notes filed.
ftp://ftp.update.uu.se/pub/pdp11/doc/cmd/
Are the firmware images still available somewhere? I want to see
if updated firmware will fix the hang problem I'm having booting
the VMS 7.3 CD (it boots, but hangs while trying to start the
standalone backup; this happens when my Pioneer CD drive is
jumpered for 512 or 2048 byte blocks). I can't seem to find CMD's
site anymore, though I could swear someone linked it around here
not long ago.
- Dave
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.
On my CQD-220/TM with original CMD labeled EPROMs I have F220Y1A8 /
F220Y2A8. Is that the same A8 version to which you refer?
I also have .HEX files for a CQD-220/TM B2A Release 06/24/94:
220Y1B2A.HEX
220Y2B2A.HEX
And a CQD-220/TM B3 Firmware 09/23/94
F220Y1B3.HEX
F220Y2B3.HEX
I wonder what is different between the A8 and B2A and B3 versions. I
don't think I have ever tried loading the B2A or B3 versions on my
CQD-220/TM.
1:40 p.m.
On Tue, Apr 23, 2013 at 1:09 PM, David Riley <fraveydank at gmail.com> wrote:
Are the firmware images still available somewhere? I want to see
if updated firmware will fix the hang problem I'm having booting
the VMS 7.3 CD (it boots, but hangs while trying to start the
standalone backup; this happens when my Pioneer CD drive is
jumpered for 512 or 2048 byte blocks). I can't seem to find CMD's
site anymore, though I could swear someone linked it around here
not long ago.
Oh, and BTW, I have never had any issues booting the VMS 7.3 CD on
KA630, KA650, KA655, and VAX 4000 CPUs from CMD CQD-220/TM with
Plextor SCSI CD-ROM drives. I doubt it is a CQD-220/TM firmware
issue, but you never know...
-Glen
1:53 p.m.
On Apr 23, 2013, at 4:40 PM, Glen Slick <glen.slick at gmail.com> wrote:
On Tue, Apr 23, 2013 at 1:09 PM, David Riley
<fraveydank at gmail.com> wrote:
I suspect you're right. The annoying part is that it seems to
work fine with the boot, but once it tries to launch standalone
BACKUP, it just hangs there. I've verified that the CD is OK;
I can attach Simh directly to the disc and it works fine.
Do you turn off sync for your CD drive? It's on my list of
things to check this evening, but it would be nice to know
ahead of time.
- Dave
Are the firmware images still available somewhere? I want to see
if updated firmware will fix the hang problem I'm having booting
the VMS 7.3 CD (it boots, but hangs while trying to start the
standalone backup; this happens when my Pioneer CD drive is
jumpered for 512 or 2048 byte blocks). I can't seem to find CMD's
site anymore, though I could swear someone linked it around here
not long ago.
Oh, and BTW, I have never had any issues booting the VMS 7.3 CD on
KA630, KA650, KA655, and VAX 4000 CPUs from CMD CQD-220/TM with
Plextor SCSI CD-ROM drives. I doubt it is a CQD-220/TM firmware
issue, but you never know...
4:22 p.m.
On Apr 23, 2013, at 4:40 PM, Glen Slick wrote:
On Tue, Apr 23, 2013 at 1:09 PM, David Riley
<fraveydank at gmail.com> wrote:
Turns out it works if I turn sync mode off for the CDROM. It
makes a certain amount of sense, I guess; it's a REALLY old
external CD drive that came with a Mac LC 475, which was one
of the '040 Macs right around the beginning of the CD era, so
it's certainly possible that it's just a finicky old drive.
There's nothing that leads me to believe it's anything more
than a 1x, though it is at least tray-loading, so it's quite
possible it just doesn't do sync transfers; at 150KB/s, why
bother?
- Dave
Are the firmware images still available somewhere? I want to see
if updated firmware will fix the hang problem I'm having booting
the VMS 7.3 CD (it boots, but hangs while trying to start the
standalone backup; this happens when my Pioneer CD drive is
jumpered for 512 or 2048 byte blocks). I can't seem to find CMD's
site anymore, though I could swear someone linked it around here
not long ago.
Oh, and BTW, I have never had any issues booting the VMS 7.3 CD on
KA630, KA650, KA655, and VAX 4000 CPUs from CMD CQD-220/TM with
Plextor SCSI CD-ROM drives. I doubt it is a CQD-220/TM firmware
issue, but you never know...
8:40 p.m.
On Apr 23, 2013, at 7:22 PM, David Riley wrote:
Turns out it works if I turn sync mode off for the
CDROM. It
makes a certain amount of sense, I guess; it's a REALLY old
external CD drive that came with a Mac LC 475, which was one
of the '040 Macs right around the beginning of the CD era, so
it's certainly possible that it's just a finicky old drive.
There's nothing that leads me to believe it's anything more
than a 1x, though it is at least tray-loading, so it's quite
possible it just doesn't do sync transfers; at 150KB/s, why
bother?
Nope, nevermind, that didn't fix it. It got me to the
BACKUP prompt... once. Haven't managed to duplicate it.
I'm still running the A7A revision of the firmware, so I
should try with both A8 and the B2A/B3 revisions that are
available. I'm particularly curious to see if they fixed
the zero disks/zero tapes bug I found in the B revs. In
any case, it seems like there's some bug related to CD
drives here that's somewhat time-dependent.
- Dave
24 Apr
24 Apr
3:19 p.m.
On Apr 23, 2013, at 11:40 PM, David Riley wrote:
Nope, nevermind, that didn't fix it. It got me to
the
BACKUP prompt... once. Haven't managed to duplicate it.
I'm still running the A7A revision of the firmware, so I
should try with both A8 and the B2A/B3 revisions that are
available. I'm particularly curious to see if they fixed
the zero disks/zero tapes bug I found in the B revs. In
any case, it seems like there's some bug related to CD
drives here that's somewhat time-dependent.
Updating the firmware to the B3A2 revision seems to have
done the trick. I'm now running through my second install
(my CD is reporting fatally bad blocks, so it's a good
thing I imaged it when I got it) and everything seems
fairly happy aside from the disc errors.
As far as I know, bumping to A8 might have fixed it, but
given the relatively long and interactive process that
testing several revisions would take, I thought I might
go for the gold. For those wondering: B3A2 seems to work
very nicely, and has vastly improved the online utility
(the one reachable through either executable code or the
serial port). It even seems to have added improved SCSI
clustering support, if anyone was interested in that.
And it even feels a bit snappier, though that's totally
subjective and possibly all in my head.
Thanks to Glen Slick for the link to the firmware! It
was quite helpful. I haven't established whether there
is still a bug related to zero disks/tapes, but I'm not
in the mood to recover another bricked board just now;
I'll check later.
- Dave
4:25 p.m.
On Wed, Apr 24, 2013 at 3:19 PM, David Riley <fraveydank at gmail.com> wrote:
Updating the firmware to the B3A2 revision seems to have
done the trick. I'm now running through my second install
(my CD is reporting fatally bad blocks, so it's a good
thing I imaged it when I got it) and everything seems
fairly happy aside from the disc errors.
As far as I know, bumping to A8 might have fixed it, but
given the relatively long and interactive process that
testing several revisions would take, I thought I might
go for the gold. For those wondering: B3A2 seems to work
very nicely, and has vastly improved the online utility
(the one reachable through either executable code or the
serial port). It even seems to have added improved SCSI
clustering support, if anyone was interested in that.
And it even feels a bit snappier, though that's totally
subjective and possibly all in my head.
Thanks for the update. I never bothered to try out the updated
firmware myself. I'll have to give it a try now.
-Glen
24 Jan
24 Jan
10:48 a.m.
On Mon, 23 Jan 2012, David Riley wrote:
Also, are there copyright implications to consider? I
know CMD is long
gone, but I still worry about these things.
You can get around copyright issues by publishing just the change you made
(i.e. change bytes xxx-yyy to blah). The change is your original work, and
you have every right to publish it. People that need the changes will have
the affected ROM, so they can read it out, apply your change and burn a
new one.
Alexey
11:25 a.m.
On Jan 24, 2012, at 1:48 PM, Alexey Toptygin wrote:
On Mon, 23 Jan 2012, David Riley wrote:
That's certainly my last resort. I wish there were a more standardized format for
binary patches (I don't think a universal diff will cover it, except for the case of
hex files).
It still raises the question of where to post them so they'll reach people who need
them (generally via Google). I don't have much of a web presence anymore (at least
not any that isn't covered in cobwebs).
- Dave
Also, are there copyright implications to
consider? I know CMD is long gone, but I still worry about these things.
You can get around copyright issues by publishing just the change you made (i.e. change
bytes xxx-yyy to blah). The change is your original work, and you have every right to
publish it. People that need the changes will have the affected ROM, so they can read it
out, apply your change and burn a new one. 
2:47 p.m.
That's certainly my last resort. I wish there
were a more standardized
format for binary patches (I don't think a universal diff will cover it,
except for the case of hex files).
Would definitely be nice if there was a more standardized format.
In the absence of that, pick a tool that's relatively widely available
(xdelta, maybe?) and use it. Or write two trivial programs, one to dump
a file in hex, and one to read such a hex dump and turn it back into a
binary file. Then you can distribute garden variety text diffs, and the
source code for the two little programs.
De
7:46 p.m.
On 1/24/2012 9:25 PM, David Riley wrote:
That's certainly my last resort. I wish there were a more standardized format for
binary patches (I don't think a universal diff will cover it, except for the case of
hex files).
That question discussed:
http://stackoverflow.com/questions/688504/binary-diff-tool-for-very-large-f…
Also, are there copyright implications to consider? I
know CMD is long gone, but I still worry about these things.
You can get around copyright issues by publishing just the change you made (i.e. change
bytes xxx-yyy to blah). The change is your original work, and you have every right to
publish it. People that need the changes will have the affected ROM, so they can read it
out, apply your change and burn a new one. 
3:51 p.m.
The correct option would be to contact Silicon Image, Inc. (who purchased
CMD Technology, Inc. in June of 2001) and ask for them for permission
to publish the image files.
Clint
On Mon, 23 Jan 2012, David Riley wrote:
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
4211
days inactive
4667
days old
15 comments
6 participants
participants (6)
-
alexeyt＠freeshell.org -
cctech＠vax-11.org -
dennis_mailing_lists＠conus.info -
drb＠msu.edu -
fraveydank＠gmail.com -
glen.slick＠gmail.com