GT40 Terminal II: Lunar Lander
Fri 01 September 2023 by Fritz Mueller[Continuation of restoration work on a DEC GT40 graphic display terminal; part one here.]
At this point, Scott had taken over the restoration work as I had had to leave town for work. We consulted a few times via IMs and video calls over the next couple weeks; the following is a narrative of Scott's continued work on the project as I understood it remotely.
The next thing that needed doing was to replace the failed microcode PROM described at the end of the previous article. I did some work to manually transcribe the PROM contents from the binary microcode listings included in the engineering drawings (4 bits x 256 microcode locations). Scott double-checked my work here and found and fixed at least three transcription errors (always good to have a double check on tedious tasks like this, and I seem to be developing a worsening dyslexia with age -- thanks, Scott!)
Scott tracked down and burned a replacement PROM and replaced the failing one on the board, and we were back again to the previous high water mark (able to run toggle in programs and the ROM bootstrap terminal emulator, with the same linefeed and binary load failures I had seen previously).
Scott played around with the binary loader for a bit, but it seemed to be suffering a pretty frustrating blend of several different issues. Attention was turned back to the bootstrap ROM terminal emulator LF handling problem, which was consistent and repeatable. Scott began single stepping the code by instruction, using the listings in the GT40/GT42 User's Guide, and soon made two discoveries:
-
The unit has the GT42 version of the boostrap ROM, and not the GT40 version (this can be seen because the bootstrap terminal emulator correctly handles TAB characters).
-
Upon receiving a LF char, the bootstrap code got to a loop which was scanning the input buffer looking for LFs, but failed to find any and looped indefinitely.
The malfunctioning ROM code scanning for LFs can be seen at location 166310, in the listing on PDF page 81 of the GT40/GT42 User's Guide, and is as follows:
1 2 3 4 5 6 | 166310 122300 LFLOOP: CMPB (SCAN)+,CHAR ;AND LOOK FOR A LINEFEED
166312 001406 BEQ LFOUND ;GOT IT, SEARCH HAS ENDED
166314 020327 007000 CMP SCAN,#BLIMIT ;ARE WE AT END OF BUFFER?
166320 103773 BLO LFLOOP ;NOPE, KEEP ON LOOKING.
166322 012703 001000 MOV #BSTART,SCAN ;IF AT TOP, RESET TO BOTTOM OF BUFFER
166326 000770 BR LFLOOP ;AND KEEP ON LOOKING.
|
Scott began microstepping at address program address 166310, which is machine code 122300, CMPB (R2)+,R0
.
The microcode flow traced through is as follows, using state names from the microcode listings in the
engineering drawings:
H-2
: Tracing activity starts with the machine halted and looping in microstate H-2. The KM11 is set to manual clock mode, front panel CONT switch depressed and held, and several manual clocks taken causing microbranch to...CCS-1
: Loads B←PC, causing PC to be displayed on console lights.CCS-2
: Loops waiting for CONT switch to be released.CCS-3
: Turns on RUN light.F-1
: Loads BA←PC, and initiates asynchronous bus cycle to fetch instruction.F-2
: Loads B←PC+2, causing next instruction address to be displayed on console lights.F-3
: Loads PC←B, updating the PC, and suspends processor clock until instruction fetch bus cycle reaches SSYN.F-4
: Resumes here when fetched instruction is on bus; latches into B (displaying instruction on console lights) and also into the IR decode register; releases the bus.F-5
: First big microcode branch based on instruction type.S2-1
: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates asynchronous bus cycle to read source operand from memory.S2-2
: B←R[S]+1+BYTE.BAR, which increments the source register by 1 or 2 depending on byte or word instruction.S2-3
: R[S]←B (stores back incremented source register), suspends processor clock until source operand fetch bus cycle reaches SSYN.S1-2
: Resumes here when source operand is on bus; latches into B (displaying source operand on console lights) and releases the bus, then branches on byte even, byte odd, or word.
So far so good. In the case being traced, we happen to be doing a byte read from an odd address. In this
case, the fetched source data must next be shifted right 8 bits; this is done over the course of the next 8
microsinstructions, SBO-1
- SBO-8
. Here Scott noticed a problem: bit 3 was always set in the B register
after any single right shift, even if the bit4 to the left was zero. This points directly at E044 on sheet
DPA, a four bit shift register which implements bits 0:3 of the B-register:
This part was pulled and replaced, and the ROM terminal emulator could then correctly handle LFs! After a few additional red herring to do with loose power connectors and occasional accidental bumping of the test switches on the M7013 display control board, Scott was also able to get the lunar lander code to load and run via the ROM bootstrap binary loader, though still with some display problems:
Scott discovered a major clue concerning remaining loader problems: some GT40 binary-loader encoded binaries we had been using which were downloaded off other enthusiast web sites contained erroneous extra linefeed and "!" characters, which confused the loader and/or triggered bad checksums. After stripping these out, the loader was seen to work quite reliably.
With diagnostics now in hand, Scott was able to track down a few remaining hardware issues on the display boards (a bad register with a stuck high bit, and a swap of one of the DACs which had been acting flaky with one from a spare board. I don't have precise details on these particular fixes, but will expand here later if/when I get more information.)
Below, screen shots of some diagnostics, and at long last, Scott lands on the moon and gets his cheeseburger! Drop by and visit Scott at his booth at VCFMW this weekend, see and play game, and hear tales of the restoration first-hand!