• Please review our updated Terms and Rules here

Bad CQD-220TM

On the photos - he's got several versions [his have an 8086]. Could you please pick out one that's right?

16K (8Kx16) Ram, and 64K (32Kx16) PROM

I did a 188 design a few years back... I'll pull the docs and re familiarize myself with the 186 programming details.

Did you look to see if the reset keeps getting hit?
 
Last edited:
OK, so a bit of tracing later...

The UART does indeed seem to be implemented in software, though it's a hard-to-trace system; the Tx comes off of a 74LS273 (8-bit edge-triggered flip-flop) which takes its data (at least for that bit) off one of the four FIFOs. The Rx goes straight into another one of the FIFOs through a 74LS244 (just a buffer with output enable). I haven't traced where the other data bits in the FIFOs go (would be quite a bit of work), but their read/write strobes come from a PAL. Once I get some more time today, I'll scope out those bits; I wouldn't be surprised if the strobe happens to be coming at 9600 Hz.

I haven't check to see if the reset line is toggling, but I'm fairly confident that the CPU is running more or less OK; it doesn't respond to the CSRs with any intelligible data if I pull the ROMs or the CPU, so I'd be willing to say that if it were getting constantly reset, I wouldn't be able to download the on-line program into the host RAM.
 
On the photos - he's got several versions [his have an 8086]. Could you please pick out one that's right?

16K (8Kx16) Ram, and 64K (32Kx16) PROM

Oh, and I only see one version on the site (not the 220A, just the original 220). That looks to be the correct size for RAM and PROM. There's a little SPI EEPROM (NMC9306N) on there that gets bit-banged via a crude GPIO setup using the same '273 the UART does; I'd be curious to see if that hooks up to the same FIFO.

It might be useful to cook up a schematic. I have a number of schematic packages at my disposal; I'll see what I can do with a limited time budget.
 
I've finally had a bit of time to sit down and disassemble this, both in the 8086 and PDP-11 domain. IDA Pro, as it turns out, has some issues with doing the disassembly of the 8086 because all of the string tables are kept in ROM (and are thus referenced by the cs register) but whenever an address is loaded into a register (e.g. for printing a string), it assumes it's an address relative to ds. Oh well. Duplicated the data at the ds address and all is mostly well.

For anyone curious about the structure of the ROM: the PDP-11 utility portion starts at address 0xE000 and goes until nearly the end. On the PDP-11 side, it gets copied into address 05000 (octal), so if you're disassembling it, make sure it points there (there is an absolute location at the start and all the string references are pretty much absolute).

Fun facts:

- The "additional utilities" section actually communicates its text directly with the 8086 (which makes a certain amount of sense). The actual routine is just a loop polling CSR+2 for text data with appropriate bits set and printing them out if it gets them, then polling the UART for incoming bytes and sending them back to CSR+2 with appropriate bits set. This explains why I couldn't find the relative strings in the massive string table in the PDP-11 section. It also means the 8086 is definitely where the thing is crashing, because it prints out "S/N =" and then stops.

- The 8086 does its serial via bit-banging. I haven't quite figured out how it does its timing (I'm not particularly good with 8086 bus cycles; give me a 68k any day), but there seems to be a general-purpose set of I/O registers at 0x80xx (curiously, the actual QBUS data transaction registers appear to be at 0x7Fxx). Assuming all the bit-banging is done via one register (not out of the question, since the same latches/bus drivers seem to go to both the UART pins and the SPI EEPROM), I think I may be getting close to the problem. The bad news: It's probably a PLD that I'll have to desolder and guess the function of by tracing it out on the board, which is not a task I relish.

I wish I had a logic analyzer that would clip onto the pins of the 8086. That would help things immensely. I have an FPGA board that I could run a cable over to and capture the data, but prying the 8086 loose and plugging square pins into its sockets for a capture board is another task I don't relish.

If anyone has IDA Pro, I'll be glad to send my disassembly database so far. It's certainly an interesting example of an embedded computer, if nothing else.
 
If anyone has any interest in this (a year and a half later), I found out what the problem was. If you somehow accidentally set the number of tape and disk drives to zero (which is not impossible to do), the firmware for the 8086 crashes in a routine that sets up the device IDs because it uses a pre-decremented counter to loop through the devices; when it pre-decrements 0, it becomes 255 and the thing runs amok through the memory. Bad news, especially because it turns out to be not very difficult to set both to zero.

There are two solutions. The first is to replace the little 9306 EEPROM on board, which will cause the board to identify it as erased/corrupt and initialize from defaults. Unfortunately, the damn thing is soldered in, so you'll have to desolder it (I put in a socket for future replacements). Also, you'll lose your serial number unless you copy it over; I don't quite recall what byte positions held that, but I can look it up if anyone's curious. If you take out the 9306 and have a ROM burner that supports it, you can also just erase it instead; my ROM burner theoretically supports it, but it turns out to have a bug in the 9306 algorithm and doesn't work. I repurposed an FPGA board to be my read-write maching.

The second solution involves fixing the ROM. As luck would have it, there is a useless five bytes of instructions in precisely the spot where it's needed (a register is loaded with what it's already loaded with, so the five bytes of instruction space are unneeded). I was able to put a quick check to determine that the number of devices was zero and if so, branch to loading the defaults. It's not perfect, but it keeps the 8086 from crashing, which essentially bricks the card, so I'll take it.

I'll try to get the patched ROMs posted somewhere; the legality is a little fuzzy, I think, but CMD was long ago absorbed by Silicon Image, and I doubt they'd be all that picky.
 
I'm always available for a PM of fuzzy.
I don't have any of the hardware involved, but I just had to post because the debugging job is phenomenal. I'm seriously impressed. That probably doesn't mean much, but it's sincere.
patscc
 
If anyone has any interest in this (a year and a half later), I found out what the problem was....
Sorry for not posting a response sooner, but this is the first time I've had to a chance to re-read the thread enough to comment.

After a year+ I'm glad I was still around to see your solution. I think your code fix was definitely the way to go. Good Job! So many of these type of threads go unresolved, it's nice to see the loop closed on one for a change.

Personally, I'd also like to see your intermediate products along the way... disassembly of source code, marked up listings, what you learned about the memory map, etc...

I've done this kind of reverse engineering too, and it's always been gratifying to complete. Anything you could share about the experience would make entertaining reading for me. [maybe a couple other nutz here at the forums too] :jumping1:

The legality shouldn't be a problem. As long as you reverse engineered it without signing any agreements with the original manufacturer, your work product would be "clean" from a legal standpoint. Your options would be to publish [post] a complete revised ROM image, or instructions for modifying the original ROM contents to fix the problem. [Be sure to include the "before" and "after"]

Anyway, great going. It's useful knowledge for this community to be aware of in any case.
 
Back
Top