In part 6, I established that something was stopping the floppy disc drives in my 16500A working when I changed the ROMs to software version 00.02. Thanks to the help of some on the hp-agilent-equipment Yahoo group, especially Glen Slick, I have determined that there’s an important difference between early CPU boards running 00.00 and later ones running 00.02: the floppy disc controller chip has changed!
The old board has an FDC9793 and the new one a uPD765 (or at least its Zilog equivalent). There are pictures of all the boards here. Now, I started to wonder, could I somehow fit the uPD765 to my board? It seems crazy and would only make sense if it wasn’t possible to exchange the whole board. So I started investigate. As luck would have it I have a functional 16500B with a logic analyzer plugin, so I could have a look and see what was going on around the disc controller on my CPU board. I wired up the relevant pins of the FDC9793.
Examining the logic analyzer trace, it seems that the CPU is trying to read something from the disc controller, which is at least a start.
It’s reading from what would be the status register repeatedly, as if waiting for some condition to be true. It gets a value of 0x04 every time, which is presumably not what it wants. It does this at the right stage of the self-test. I thought this was promising, since it is at least addressing the chip. Might it be possible to wire one in place of the other? Their pinouts are different. Comparing them, using their datasheets:
| FDC9793 | uPD765 | |||||
| 1 | RESET | I | active high | |||
| 2 | nWE | I | nRD | I | ||
| 3 | nCS | I | nWR | I | ||
| 4 | nRE | I | nCS | I | ||
| 5 | A0 | I | D/nS | I | data/nStatus register select | |
| 6 | A1 | I | D0 | I/O | ||
| 7 | D0 | I/O | D1 | I/O | ||
| 8 | D1 | I/O | D2 | I/O | ||
| 9 | D2 | I/O | D3 | I/O | ||
| 10 | D3 | I/O | D4 | I/O | ||
| 11 | D4 | I/O | D5 | I/O | ||
| 12 | D5 | I/O | D6 | I/O | ||
| 13 | D6 | I/O | D7 | I/O | ||
| 14 | D7 | I/O | DRQ | O | DMA request | |
| 15 | STEP | O | Step output | nDACK | I | DMA ack |
| 16 | DIRC | O | Direction (high=in, low=out) | TC | I | end of DMA transfer |
| 17 | EARLY | O | write precompensation | IDX | I | index pulse |
| 18 | LATE | O | write precompensation | INT | O | interrupt output |
| 19 | nMR | I | master reset | CLK | I | 8MHz |
| 20 | GND | GND | ||||
| 21 | +5V | WCK | I | write clock | ||
| 22 | nTEST | I | tie to +5V | RDW | I | read data window |
| 23 | HLT | I | input, head engaged | RDD | I | read data from data sep |
| 24 | CLK | I | 1MHz in | VCO/SYNC | O | enable VCO |
| 25 | RG | O | read gate to data sep | WE | O | write enable |
| 26 | RCLK | I | read clock from data sep | MFM | O | MFM/FM |
| 27 | nRAW READ | I | raw data from drive | HD | O | head select |
| 28 | HLD | O | head load | US1 | O | unit select |
| 29 | TG43 | O | track greater than 43 | US0 | O | unit select |
| 30 | WG | O | write gate | WDA | O | write data |
| 31 | WD | O | write data | PS1 | O | precompensation shift (early/late/normal) |
| 32 | READY | I | ready | PS0 | O | precompensation shift (early/late/normal) |
| 33 | nWF | I/O | write fault/vfo en to data sep | FLT/TR0 | I | track 0/fault |
| 34 | nTR00 | I | track 0 | WP/TS | I | write protect/two side |
| 35 | nIP | I | index pulse | RDY | I | drive ready |
| 36 | nWPRT | I | write protect | HDL | O | head load |
| 37 | nDDEN | I | double density | FR/STP | O | fault reset/step |
| 38 | DRQ | data req, open-collector | LCT/DIR | O | low current/direction | |
| 39 | INTRQ | interrupt req, open-collector | nRW/SEEK | O | indicates seek/read/write mode | |
| 40 | +5V |
There are some important differences here. Firstly, the uPD765 expects an 8MHz clock where the FDC9793 used a 1MHz clock. That’s not a good start. The uPD765 includes drive and side select logic, but the FDC9793 doesn’t. The two also differ a lot in how they handle things like write precompensation signals, and the uPD765 effectively multiplexes various signals too.
At this point I think the swap is just too difficult. It becomes cheaper and easier to swap the whole CPU board, if I can find one, or simply upgrade the whole machine to be a 16500B.
martinjonestechnology 
What about dropping in the ROM routines for the floppy accesses from the old V00 ROM inplace of the equivalent routines in the V02… “how different can they be?” (infamous last words before embarking on a never-ending adventure).. You ought to be able to tell where in V02 ROM they are by watching the ROM addr pins while you’re trapped in the drive test loop, and if you can trigger on an access to that chip when V00 ROM is back, and record the ROM addresses then, you ought to have a good idea of where the working routines are located.
It’s a bold idea, but it would be more reverse engineering than I was prepared to put in…it was easier, though I agree less intellectually satisfying, just to buy a 16500B instead!
No argument there,… as a fellow 16500B owner I took mine to 32 megas with such triviality (I had the 2x16MB SIMMs sitting in a bag of similar parts) it seemed almost too easy after reading about your hassle to get a memory upgrade in your ‘A unit — my ‘B unit came equipped with 8MB — I had only really been using the ‘scope card so far, but after I realized it had 72-pin SIMM slots, it was an obviously-must-do upgrade.