#rom dumping

The VT100 technical manual indicates that the first thing that the firmware does on boot is run checksums on the ROMs. I figured I should work out how those checksums are computed, since it would be nice to know that my dumps are correct and also because I'll need to add my own bits to the code later to ensure the checksums work out.

It's also a good exercise for me, because I've never done any 8080 work before, and it's nice to get some practice reading the mnemonics. Here's the checksum code, annotated:

;;; Run checksum on each 2K ROM, indicating with ;;; the keyboard LEDs which is being scanned. ;;; The # of the chip being scanned is stored in B. xra a ; zero A mov d,a ; zero D, L, H mov l,a mov h,a csrom: inr a ; next 2K ROM mov b,a ; store the current ROM # in B out 82h ; show current ROM on LEDs mvi c,8 ; Checksum over 8 256B blocks X004f: rlc ; Rotate A left xra m ; A <- A ^ memory inr l ; next memory address jnz X004f ; ... repeat until end of block inr h ; next block dcr c ; decrement block count jnz X004f ; ... repeat until end of chip ora a ; Check the value of the accumulator X005b: jnz X005b ; If it's not zero, hang forever mov a,b ; Put the ROM # back in the accumulator cpi 4 ; If it's not 4... jnz csrom ; repeat for the next ROM

The way the checksum works is pretty clear here: for each byte, it rotates the accumulator one bit to the left and XORs it with the byte. The accumulator is initialized with the number of the ROM being scanned (1-4) so if the wrong ROM is somehow being scanned it will fail the checksum. At the start of each chip's checksum, the number of the chip is written to the keyboard status register. The VT100 keyboard has several LEDs that are set by writing to this status register; so the current chip being checked is indicated. If a checksum fails, the terminal enters an infinite loop, and the identity of the failed chip is displayed on the keyboard LEDs. Pretty neat for thirty bytes of code.

Dumping the ROMs

On the back of the VT100 is a tall access panel affixed by four screws. Behind it is a card cage containing the Basic VT100 video card. Once the keyboard is unplugged, the video card can be easily removed by carefully pulling it out of its slot.

This VT100 has the Advanced Video Option (AVO) board installed. That's the small daughterboard you can see on top of the main board in the third picture. The VT100 ROMs are in sockets beneath the AVO board.

The VT100 shipped in two variants: with a single 8Kx8 24-DIP ROM or with 4 2Kx8 24-DIP ROMs. We have the 4 2Kx8 variant. Here's where it gets a little loopy: in the technical manual, ROM 0 is towards the middle of the board and ROM 3 is towards the edge. Confusingly, the order of the ROM chips on my (working) board was reversed! I was chalking it up to an error in the technical manual, but a few failed attempts to dump one of the ROMs later I suspected something was up. That's when I noticed the schematic above.

Rather than use a demultiplexer to select the correct ROM chip based on the high two bits of the address, the DEC engineers decided to essentially handle the demuxing in the individual ROMs themselves, with this weird three-line chip select mechanism. It's a really clever solution, since

it saves the cost of another demultiplexer chip,

you can drop in a single 8Kx8 ROM (more on that later) instead of four 2Kx8 ROMs in a later revision without having to alter the board layout, and

you can install the ROMs in any order you want, and the thing will still work.

Now that I understood how the chip select mechanism worked, I modified my dumper to set the CS1..3 lines correctly, dumped all four 2K ROMs, and assembled them into an 8K image.