11 Nov
2011
11 Nov
'11
5:15 p.m.
On 11/11/11 7:45 PM, David Riley wrote:
On Nov 7, 2011, at 2:57 PM, Glen Slick wrote:
I am! I own some CQD boards...
I haven't seen any behavior like that with
any of the CQD-220/TM that
I have. What version of the firmware are you using? The latest image
I have is CQD-220/TM B3A.02 (F220Y1B3A, F220Y2B3A) 10/17/95. Swapping
in different EPROMs would be trivial to try, but might not be too
likely to change the behavior. The only PAL I have looked at is the
CSR decode PAL, which I reverse engineered to be able to convert
CQD-220/T and CQD-220/M versions into CQD-220/TM versions.
So if anyone is at all curious about the answer to this particular
quandary ... the answer seems to be busted
aging non-volatile storage. I desoldered the NMC9306 (Microwire
EEPROM) and put a socket in so I could test it in my ROM burner. The
ROM burner reads all Fs from it (I checked continuity to all pins, so
it wasn't that) and can't program anything to it, so I guess the chip
is borked. At least with a socket, it'll be easy to put the new one
in.
If I run the thing without the EEPROM in (I saw provisions for a
blank/absent chip in the 8086 code, so I figured I'd give it a shot)
it works! The serial port works as expected now, too. The EEPROM
holds some information necessary for running, like the LUN offset and
some disk/tape configuration options that I haven't work out yet
(though defaults are loaded if the EEPROM doesn't come up right).
Given the amount of fallback for absent EEPROMs, I should probably be
able to get this thing to run without one for the time being.
I meant to interject in this thread before, but better late than never:
You guys are GOOD. Really good!
--T
Of course, there's always a catch ...
- Dave