• Please review our updated Terms and Rules here

Bad CQD-220TM

fraveydank

Member
Joined
Feb 25, 2011
Messages
32
Location
Philadelphia, Pennsylvania, United States
I acquired a CMD CQD-220TM (QBUS SCSI card) a while back that was working when I got it. Now, however, it's gone flaky; about 4 times out of 5, when I start my 11/23+ up, the thing doesn't respond properly to its CSRs. It's working in a sense, in that I can get the diagnostic utility to copy over to RAM when it does work properly, but it goes off after that at some point (when I bring up the "other utilities" section, it hangs when trying to read the serial number, and stepping through the code using ODT I can see it's stuck polling the CSRs and never leaving because it's always getting 0 back).

The infuriating part about this is that it was working, and it stopped behaving just when I finally had the time (and SCSI disks) to do something with it. The CPU appears to be an 8088 (or 8086, but there's only two '373s on the bus interface and an 8086 usually has 3; I don't really want to peel back the label on the CPU because I'll never get it back on). I'm worried that what's gone wrong is one of the million or so PLDs on the board (this thing is more than half PAL/GAL/PEEL); if that's the case, it'll never work unless someone happens to have bitfiles for the devices lying around somewhere. I could get an 8088 to replace this pretty easily, and if anyone has known good ROM dumps, I can at least verify the ROMs (and I have a UV EPROM eraser and a burner, but that would require peeling the labels back again).

Anyone have experience fixing/troubleshooting these? I'm a little bummed about this.
 
No experience with that particular module, but if no one else can give you better help - I'll take a crack at it with ya.

Is this the one?

If so, it looks like someone has done some of the work for us, decoding / reverse engineering some of the PALs.

I still have a lot of 808X data books here - we have to be able to get somewhere with it. I'll look to see if there's any more documentation out there for it.

Apparently one of our members is familiar with this unit. You might try PMing him.

I'm guessing this is you?

Looks like a nice module... probably worth fixing.
 
Last edited:
I have EPROM versions F220Y1A8 / F220Y2A8 on my CMD CQD-220/TM. I could dump them and upload images of them.

I don't have source code for the CSR decode PAL, but I reverse engineered a functional equivalent so I could turn a CQD-223/M version and a CQD-223/T version into CQD-223/TM functional versions. I used 22V10's for the replacement although the logic is purely combinatorial and there are no registered outputs or feedback terms.

https://sites.google.com/site/glensvintagecomputerinfo/cmd-cqd-220-scsi
 
Glad to see you gslick... I linked to you hoping he'd PM ya. Let's see what happens. There's one of these on eBay for $799 right now. LOL
 
Thanks, that should be really helpful; I happen to have some GAL22v10s lying around, but it appears my new desktop machine doesn't have a parallel port, so I'll have to wait for one before I can burn the GAL with my burner. If that doesn't fix the problem, I'll ping you about the ROM images (can't very well use those without the burner either). Thanks!
 
gslick, could you dump / post your EPROM contents someplace? It would be good to have them. [I've looked elsewhere and have not seen them] Have you tested the reverse engineered PAL code? If so you might post that too, if you're willing.

I've got no GALs, but I have a couple programmers here, so if this effort gets stuck, there should be a way. [I kept my Win98 machine for exactly this reason] I've got both an EMP20 and a PROTEUS, so I'm sure they can be programmed. Even got a couple erasure chambers here somewhere.

I used the EMP20 about 2 years ago to re-flash my mother's bricked hp laptop. Boy, that was a mess. Had to surgically remove the old PLCC [soldered to the motherboard] and install a socket. Bought the exact replacement part at DigiKey. Whole project took a month end-to-end.
 
Amusingly enough, I got this burner to fix a server I had bricked by applying a BIOS patch that didn't work. Handy things! No longer in support, but I know it does GALs and any kind of EPROM from before about 2002 just fine. I've ordered a parallel port card from NewEgg which should come in a few days; we'll find out then.
 
I dumped the EPROMs of all of the firmware versions I have and uploaded the contents here:
https://sites.google.com/site/glensvintagecomputerinfo/

MTI QTS-30 REV A, TMSCP
-----------------------
F200T1C5.BIN, F200T2C5.BIN

MTI QTS-30 REV B, TMSCP
-----------------------
F200T1C6B.BIN, F200T2C6B.BIN

CMD CQD-200/TM, MSCP and TMSCP
------------------------------
F200Y1A8C.BIN, F200Y2A8C.BIN


CMD CQD-220/M, MSCP
-------------------
F22001E7A.BIN, F22002E7A.BIN

CMD CQD-220/T, TMSCP
--------------------
F220T1F1.BIN, F220T2F1.BIN

CMD CQD-220/TM, MSCP and TMSCP
------------------------------
F220Y1A8.BIN, F220Y2A8.BIN


CMD CQD-220A/M/T, MSCP or TMSCP
-------------------------------
F220AE1F2L.BIN, F220AE2F2L.BIN


What I don't have and what I would like to find is a copy of this CQD-220A firmware:
CQD-220A/TM F220AY1B2L, F220AY2B2L
 
Saw your board docs... Very cool! Thank you.

I particularly liked the HP-10276A module. I heard of this, but never saw one. It could be used by the hp-1631 logic analyzer [brochure here and here]

I have hp-1615 and hp-1611 logic analyzers here, with a general purpose "roll your own" pod for the 1615, but not the original Z80 I/F unit that came with the 1611.

Your card is still listed on some of the test equipment websites.
 
Got the burner going again, finally (apparently Xeltek's software won't support anything past XP, so I had to run it under VMWare). Results:

- Burning a new GAL22V10 (10 ns vs the PEEL's 30 ns) with your code had about the same effect as removing and firmly reseating the existing PEEL. The CSR response seems much more stable now, but the same problems crop up. I can issue a format command, but it finishes more quickly than it seems it should; qualify doesn't seem to work at all; pulling up "additional utilities" still crashes when it's reading the serial number. Changing the LUN offset seems to work, and the change persists through several power cycles, so it looks like the little serial EEPROM soldered on the board seems to work; I don't know where the serial number is stored, I might try disassembling the ROMs in a bit.

- Replacing the firmware ROMs with what you've provided has interesting effects. My board comes with rev A7A (you seem to have A8), so I burned your A8 onto a pair of spare 27(C)256 chips and tried them out. The board responds to the CSRs OK, and I can copy the utility into RAM, but when I try to start it and provide it with the CSR, it says "NOT A SCSI CONTROLLER". If I try to specify a CSR that it's not at, it says "NO CONTROLLER PRESENT", which indicates that at least it sees something there. Not sure what it's looking for; I'd have to dump the program and disassemble it to see what's going on. I can also provide you with the A7A firmware if it would be useful.

- I still can't seem to see anything on the serial port. The manual indicates that the serial pinout is pretty much the same as DEC's; if I hook up one of my bodged-up PC serial cables resoldered to match the DEC pinout, I get nothing and the card seems to show an error on the diagnostic LEDs. Is there a trick to the serial port? Perhaps it's 5V instead of RS232 levels? I don't see any level converters on the card, though I haven't tried to map out a schematic to see if they've done a custom one. Hoping I haven't done any damage, though it at least seems to be diode-protected against reverse polarization.


Anyone got next step ideas beyond disassembling the code? I'm working on that (have a copy of IDA pro which is doing as admirable a job as it can, but I'm having a bit of trouble with the 8086's disgusting segment register concept).
 
Fun fact: The ROM images actually form a DOS executable. I thought IDA was nuts when it said "hey, this looks like a DOS EXE", but I guess they must have used an XT as the prototyping system or something and just tagged the reset vector on at the end? Dunno. Anyway, that does seem to make disassembling a whole lot easier.
 
That is interesting. I've used Datalight ROM DOS when I designed stuff like that.

Very clean. The BIOS is distributed in source so it can be customized to the platform.

A little hint... debugging was via Borland Turbo Debug using "remote mode".

Might help you figure things out.
 
- I still can't seem to see anything on the serial port. The manual indicates that the serial pinout is pretty much the same as DEC's; if I hook up one of my bodged-up PC serial cables resoldered to match the DEC pinout, I get nothing and the card seems to show an error on the diagnostic LEDs. Is there a trick to the serial port?

I have used the serial ports on all of my CMD controllers without any problems. Just a three wire connection: GND, TX, RX to my PC running a terminal emulator. You don't need the jumper (7-9?) on the 10-pin connector that you need on standard DEC 10-pin serial connectors.

-Glen
 
Is there any trick to it? The manual isn't too clear; says the system should be in halt or something like that. I've tried every combination of halt, reset, etc. with no luck. Perhaps that's indicative of the problem... maybe I need to trace out the UART circuit and see if I can't see something closer up the chain on the scope.
 
That is interesting. I've used Datalight ROM DOS when I designed stuff like that.

Very clean. The BIOS is distributed in source so it can be customized to the platform.

A little hint... debugging was via Borland Turbo Debug using "remote mode".

Might help you figure things out.

Doesn't look to be that; the site indicates that ROM DOS came out in 1989 (the board is from '88, though I guess the firmware might not be) and claims to require a 186 or higher (this is a straight up 8086 in a 40-pin DIP). Moreover, the bottom of the ROM (the first 0x200 bytes) are an MZ-style DOS executable header, which indicates that they intended this to be run on a PC actually running DOS. The reset vector at offset 0xFFF0 starts execution at the program entry point (0xF000:0200, indicating that the ROM is mapped at 0xF0000 on the board).

Good guess, though... do you know of any PC-based embedded prototyping frameworks from around then?
 
Doesn't look to be that; the site indicates that ROM DOS came out in 1989 (the board is from '88, though I guess the firmware might not be) and claims to require a 186 or higher (this is a straight up 8086 in a 40-pin DIP). Moreover, the bottom of the ROM (the first 0x200 bytes) are an MZ-style DOS executable header, which indicates that they intended this to be run on a PC actually running DOS. The reset vector at offset 0xFFF0 starts execution at the program entry point (0xF000:0200, indicating that the ROM is mapped at 0xF0000 on the board).

Good guess, though... do you know of any PC-based embedded prototyping frameworks from around then?

I understand what you saying about the EXE in the ROM. I guess there could be another ROM with the BIOS, but more likely it's in the same devices and partitioned by an addressing trick.

Have a look at Borland Turbo C [there were other languages too] for DOS and later, Windows.


Myself and others used this as a cross-development environment for many years, even on embedded targets. Once I'd get a board up and working as a prototype, I'd port a BIOS to it and include TD's Remote Debugging driver in it. Allows the Turbo Debugger [Windows application] to run on my local machine and talk to the target system over a serial port to debug software on it remotely. [even the BIOS] Extremely small footprint on the target [~2k as I recall].

My last such design was a 386EX based board intended to be a "special purpose" protocol translator with up to 18 serial ports or other devices. Fun project. Too bad we don't do manufacturing in the U.S. any more... I'd like to still be doing that kind of work.
 
Hm, curious. I wouldn't be terribly surprised if they just did the initial development with an ISA card mockup and ran in DOS; the DOS program seems to load the ROM into a different region of memory than the ROM seems to be mapped at (0x10000 instead of 0xF0000) and just tagged a boot vector onto the binary and stuck it in ROM. I wouldn't be surprised if it was done using Borland, though; the debug stubs might be present.

In any case, I think the fact that I don't see anything at all on the UART may be a sign of something else failing and messing with the firmware execution; I'm going to trace that circuit out and see if I can figure out where it goes and whether I can fix it.
 
If you know the serial port should be active that's a good strategy. Look to see if the processor reset line gets toggled alot too.

You could be right, and the EXE header is just a vestigial artifact of the compilation process.
If the EXE contains code to relocate the ROM address after startup, it seems more likely that it has the entire code for the board. After all, it's real mode [186?] so everything is possible, and there may be no need for a BIOS if the author knows enough.
I can't imagine debugging on anything easier than TD, but if they didn't have those tools, they may have done it another way. Of course, the debugging isn't needed in the final product and may not be present, or it's deactivated by some trick too.
Note: One thing about TD... it needs the target EXE to be in RAM to really be fully functional. Look for a copy-ROM-to-RAM phase in the startup somewhere. If it's not there, TD can't be active in this edition except to step.
Special hardware versions for development were possible in those days too, so anything could be.

Should be fun for you to puzzle out. I'd look through the ROM contents to see what else you can recognize.

Got any idea what the running memory map looks like yet?
 
Incidentally... DataLight is just the ROM DOS I used later one [because they included the BIOS code for your use] There were other ROM DOS's going way back to the first laptops and portables.

86 is when I saw the first preliminary Borland Turbo products, although not fully fleashed out.

Anyway, let's focus on what you have there... could you post a hi-res photo of the board someplace?

I gotta get one of these things if I'm gonna help, even if it's bad. Anyone got anything to send me?
 
I'm pretty sure this is just bare metal; there's only 16k of RAM on this board (not counting the hardware FIFOs attached to the SCSI controller), so I'm willing to bet this thing runs straight out of ROM. The code is actually pretty much all position independent (within the code segment, anyway), so it doesn't actually matter where it's located in memory; the DOS header says it's located at one location, but the actual execution from the reset vector indicates that the real board has it located in another.

My guess is that the memory map at least has the ROM in 0xF0000-0xFFFFF, since the 8086 boot vector is 0xFFFF0 and it directs execution to 0xF000:0x2000 (or 0xF0200 in real-person terms). The initial parts of the boot code zero both DS and SS, so I'm assuming the RAM starts at 0x0000 and goes to 0x3FFF (16k).

There's at least a bunch of string tables I can see that look a lot like what the PDP-11 side of things spits out for the online tool; I'm assuming the same strings get copied out to the PDP-11 with the online tool code, but I haven't looked hard enough to find where that happens. Right now, I'm concerned that some of the internal memory decoding may be screwed up, which would indicate why the serial number can't get read and why the UART doesn't work; the interface between QBUS and the 8086 seems to be more or less OK, and it does appear to at least operate normally a lot of the time until it gets stuck. Curiously, while reading the serial number seems to fail, reading the LUN offset (also stored in non-volatile memory) does not, which indicates that they may be in different non-volatile locations. I only see one 8-pin serial EEPROM.

As far as a high-res picture, the ones on gslick's site are pretty good; they should probably give you a good idea of what's on there. Unfortunately, a lot of the routing goes underneath the chips, so I'll probably need to buzz some things out with my meter.
 
Back
Top