Mystery solved - Re: CMD CQD-220TM problems

On Nov 11, 2011, at 8:15 PM, Toby Thain wrote: OK, I built up a rig for reading the EEPROM (I don't have any 93C46 chips yet, but I'll check to make sure the same algorithm works on them... it's a pesky line of chips because unlike most SPI devices, the bit strings are not multiples of 8. The read command also inserts a dummy zero bit before the data, so the read command is actually one bit longer than the write bit. It's a mess. Anyway, I verified that my old EEPROM is, in fact, still basically good (Xeltek's algorithm for the SuperPro 280 just doesn't work, and I don't have a digital scope to see what it's doing wrong), but I must have done the same thing a year or so ago that I did almost as soon as I got it working again. Both disk and tapes are set to zero in the unit count config word (which they took the trouble of protecting against corruption with a "magic nibble" but didn't bother bounds-checking, as described below). In short, MAKE SURE you don't accidentally tell it during configuration that you have 0 disks and 0 tapes, because if you do, the 8086 crashes when it's trying to load the disk config data. It uses the total number of units to loop through and read n unit configs out of the EEPROM and store them at [0x500 + 2i]. The problem is that the 8086 LOOP instruction predecrements the counter and checks the result for zero; if the counter is zero on the first instruction, it thus goes for 65535 iterations. Obviously, that causes problems, since we're writing memory. I made a patch for the ROM to fix this problem, because it doesn't appear to be fixed in the A8 revision either (at least, I assume; I haven't actually tried the A8 since I've replaced the EEPROM, but I'd like to think it'll work). This bug will brick a rather hard-to-find board if you make a simple mistake while typing late at night. There's an extraneous MOV instruction (probably the result of a poorly-optimizing compiler) in an opportune location to run an 8-bit add on the disk and tape numbers which JUST HAPPEN to be in registers that get thrown away shortly after. The MOV instruction gives me 5 bytes, and it looks like I only need 4 plus the trailing NOP for the ADD and JZ. In any case, I'll test it later this weekend when I've had a chance to dig up some appropriate EPROMS out of the parts bin and made sure my UV eraser still works (it got dropped during the move, but it's been dropped before and nothing looks visibly broken). I doubt I'd really run into copyright problems from a completely defunct company for a very obsolete board if I posted the fixed ROM image. Any thoughts? If the fix for the A7A revision works (that's what came with mine and it's what I have installed now), I'll make one for the A8 (which Glen Slick provided for testing) once I can disassemble enough of it to find the offending code (and hope the extra MOV instruction didn't disappear). - Dave