Skip to content

Commit

Permalink
Fix tense issues in GT40-2.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@fritzm
fritzm committed Sep 9, 2023
1 parent e64bdbd commit 01e816c
Show file tree
Hide file tree
Showing 8 changed files with 218 additions and 206 deletions.
70 changes: 36 additions & 34 deletions author/fritz-mueller.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@

<div><p><em>[Continuation of restoration work on a DEC GT40 graphic display terminal; part one
<a href="https://fritzm.github.io/gt40.html">here</a>.]</em></p>
<p>At this point, Scott has taken over the restoration work as I have had to leave town for work. We consulted a
<p>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.</p>
<p>The next thing that needed doing was to replace the failed microcode PROM described at the end of the previous
Expand All @@ -98,21 +98,21 @@
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).</p>
<p>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 is turned back to the bootstrap ROM terminal emulator LF handling
problem, which is consistent and repeatable. Scott begins single stepping the code by instruction, using the
listings in the GT40/GT42 User's Guide, and soon makes two discoveries:</p>
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:</p>
<ul>
<li>
<p>The unit has the GT42 version of the boostrap ROM, and not the GT40 version (this can be seen because
the bootstrap terminal emumator handles TAB characters).</p>
the bootstrap terminal emulator correctly handles TAB characters).</p>
</li>
<li>
<p>Upon receiving a LF char, the bootstrap code gets to a loop which is scanning the input buffer looking for
LFs, but it fails to find any and loops indefinitely.</p>
<p>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.</p>
</li>
</ul>
<p>The malfunctioning ROM code scanning for LFs can be seen at location 166310, in the listing on PDF page 81 of
the User's Guide, and is as follows:</p>
the GT40/GT42 User's Guide, and is as follows:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
Expand All @@ -127,8 +127,9 @@
</pre></div>
</td></tr></table>

<p>Scott begins microstepping at address 166310, which is machine code 122300, <code>CMPB (R2)+,R0</code>. The microcode
flow traced through is as follows, using state names from the microcode listings in the engineering drawings:</p>
<p>Scott began microstepping at address program address 166310, which is machine code 122300, <code>CMPB (R2)+,R0</code>.
The microcode flow traced through is as follows, using state names from the microcode listings in the
engineering drawings:</p>
<ul>
<li><code>H-2</code>: Tracing activity starts with the machine halted and looping in microstate H-2. The KM11 is set to
manual clock mode, front panel CONT swithch depressed, and several manual clocks taken causing microbranch
Expand All @@ -139,39 +140,40 @@
<li><code>F-1</code>: Loads BA←PC, and initiates asynchronous bus cycle to fetch instruction.</li>
<li><code>F-2</code>: Loads B←PC+2, causing next instruction address to be displayed on console lights.</li>
<li><code>F-3</code>: Loads PC←B, updating the PC, and suspends processor clock until fetch bus cycle reaches SSYN.</li>
<li><code>F-4</code>: Resume here when fetch data is on bus; latches bus data into B (displaying on console lights) and also
into the IR decode register; releases the bus.</li>
<li><code>F-4</code>: Resumes here when fetch data is on bus; latches bus data into B (displaying on console lights) and
also into the IR decode register; releases the bus.</li>
<li><code>F-5</code>: First big microcode branch based on instruction type.<br><br></li>
<li><code>S2-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates bus cycle to read
operand.</li>
<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR (increment source register by 1 or 2 depending on byte or word instruction).</li>
<li><code>S2-3</code>: R[S]←B (store back incremented source register), suspend processor clock until read bus cycle
reaches SSYN.</li>
<li><code>S1-2</code>: Resume here when source data on bus; latches bus data into B and releases the bus, then branches on
byte even, byte odd, or word.</li>
<li><code>S2-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates bus cycle to read source
operand from memory.</li>
<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR (increments source register by 1 or 2 depending on byte or word instruction).</li>
<li><code>S2-3</code>: R[S]←B (stores back incremented source register), suspends processor clock until source operand
fetch bus cycle reaches SSYN.</li>
<li><code>S1-2</code>: Resumes here when source operand data is on bus; latches bus data into B and releases the bus, then
branches on byte even, byte odd, or word.</li>
</ul>
<p>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 be shifted right 8 bits, then sign extended. This is done over the course
of the next 8 microsinstructions, <code>SBO-1</code> - <code>SBO-8</code>. Here Scott notices a problem: bit 3 is always set in the
B register after <em>any</em> single right shift, even if the bit to its left is zero. This points directly at E044
on sheet DPA, a four bit shift register which implements bits 0:3 of the B-register:</p>
of the next 8 microsinstructions, <code>SBO-1</code> - <code>SBO-8</code>. Here Scott noticed a problem: bit 3 was always set in
the B register after <em>any</em> single right shift, even if the bit to its 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:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-bad-BREG-shift.png" title="KD11-B data path bad BREG shift register" width="85%"/></p>
<p>This part was pulled and replaced, and the ROM terminal emulator could then correctly handles LFs! After a
few additional red herring 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:</p>
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:</p>
<p><img src='/images/pdp11/gt40-line-feeds_thumbnail_tall.jpg' title='GT40 displaying multiple lines after CMPB (R2)+,R0 fix.' onclick='pswipe("pdp11",113);'/>
<img src='/images/pdp11/gt40-first-lunar-run_thumbnail_tall.jpg' title='GT40 running the lunar lander game, but still with some display issues.' onclick='pswipe("pdp11",114);'/></p>
<p>Scott discovered a major clue concerning remaining loader problems: some GT40 binary-loader encoded binaries
downloaded off other enthusiast web sites contain erroneous extra linefeed and "!" characters, which confuse
the loader and/or trigger bad checksums. After stripping these out, the loader was seen to work quite
reliably.</p>
<p>With diagnostics now in hand, Scott was able to track down a few remaining hardware issues (a bad register
with a stuck high bit, and a swap of one of the DACs that 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 I get more details.)</p>
<p>Below, 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!</p>
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.</p>
<p>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 that 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 details.)</p>
<p>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!</p>
<p><img src='/images/pdp11/gt40-diags_thumbnail_tall.jpg' title='Repaired GT40 running diagnostic MAINDEC-DDGTE.' onclick='pswipe("pdp11",115);'/>
<img src='/images/pdp11/gt40-lunar-better_thumbnail_tall.jpg' title='Repaired GT40 running the lunar lander game.' onclick='pswipe("pdp11",116);'/>
<img src='/images/pdp11/gt40-cheeseburger_thumbnail_tall.jpg' title='Repaired GT40: Scott lands on the moon and gets his cheesburger!' onclick='pswipe("pdp11",117);'/></p></div>
Expand Down
70 changes: 36 additions & 34 deletions category/pdp-11.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@

<div><p><em>[Continuation of restoration work on a DEC GT40 graphic display terminal; part one
<a href="https://fritzm.github.io/gt40.html">here</a>.]</em></p>
<p>At this point, Scott has taken over the restoration work as I have had to leave town for work. We consulted a
<p>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.</p>
<p>The next thing that needed doing was to replace the failed microcode PROM described at the end of the previous
Expand All @@ -98,21 +98,21 @@
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).</p>
<p>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 is turned back to the bootstrap ROM terminal emulator LF handling
problem, which is consistent and repeatable. Scott begins single stepping the code by instruction, using the
listings in the GT40/GT42 User's Guide, and soon makes two discoveries:</p>
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:</p>
<ul>
<li>
<p>The unit has the GT42 version of the boostrap ROM, and not the GT40 version (this can be seen because
the bootstrap terminal emumator handles TAB characters).</p>
the bootstrap terminal emulator correctly handles TAB characters).</p>
</li>
<li>
<p>Upon receiving a LF char, the bootstrap code gets to a loop which is scanning the input buffer looking for
LFs, but it fails to find any and loops indefinitely.</p>
<p>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.</p>
</li>
</ul>
<p>The malfunctioning ROM code scanning for LFs can be seen at location 166310, in the listing on PDF page 81 of
the User's Guide, and is as follows:</p>
the GT40/GT42 User's Guide, and is as follows:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
Expand All @@ -127,8 +127,9 @@
</pre></div>
</td></tr></table>

<p>Scott begins microstepping at address 166310, which is machine code 122300, <code>CMPB (R2)+,R0</code>. The microcode
flow traced through is as follows, using state names from the microcode listings in the engineering drawings:</p>
<p>Scott began microstepping at address program address 166310, which is machine code 122300, <code>CMPB (R2)+,R0</code>.
The microcode flow traced through is as follows, using state names from the microcode listings in the
engineering drawings:</p>
<ul>
<li><code>H-2</code>: Tracing activity starts with the machine halted and looping in microstate H-2. The KM11 is set to
manual clock mode, front panel CONT swithch depressed, and several manual clocks taken causing microbranch
Expand All @@ -139,39 +140,40 @@
<li><code>F-1</code>: Loads BA←PC, and initiates asynchronous bus cycle to fetch instruction.</li>
<li><code>F-2</code>: Loads B←PC+2, causing next instruction address to be displayed on console lights.</li>
<li><code>F-3</code>: Loads PC←B, updating the PC, and suspends processor clock until fetch bus cycle reaches SSYN.</li>
<li><code>F-4</code>: Resume here when fetch data is on bus; latches bus data into B (displaying on console lights) and also
into the IR decode register; releases the bus.</li>
<li><code>F-4</code>: Resumes here when fetch data is on bus; latches bus data into B (displaying on console lights) and
also into the IR decode register; releases the bus.</li>
<li><code>F-5</code>: First big microcode branch based on instruction type.<br><br></li>
<li><code>S2-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates bus cycle to read
operand.</li>
<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR (increment source register by 1 or 2 depending on byte or word instruction).</li>
<li><code>S2-3</code>: R[S]←B (store back incremented source register), suspend processor clock until read bus cycle
reaches SSYN.</li>
<li><code>S1-2</code>: Resume here when source data on bus; latches bus data into B and releases the bus, then branches on
byte even, byte odd, or word.</li>
<li><code>S2-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates bus cycle to read source
operand from memory.</li>
<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR (increments source register by 1 or 2 depending on byte or word instruction).</li>
<li><code>S2-3</code>: R[S]←B (stores back incremented source register), suspends processor clock until source operand
fetch bus cycle reaches SSYN.</li>
<li><code>S1-2</code>: Resumes here when source operand data is on bus; latches bus data into B and releases the bus, then
branches on byte even, byte odd, or word.</li>
</ul>
<p>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 be shifted right 8 bits, then sign extended. This is done over the course
of the next 8 microsinstructions, <code>SBO-1</code> - <code>SBO-8</code>. Here Scott notices a problem: bit 3 is always set in the
B register after <em>any</em> single right shift, even if the bit to its left is zero. This points directly at E044
on sheet DPA, a four bit shift register which implements bits 0:3 of the B-register:</p>
of the next 8 microsinstructions, <code>SBO-1</code> - <code>SBO-8</code>. Here Scott noticed a problem: bit 3 was always set in
the B register after <em>any</em> single right shift, even if the bit to its 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:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-bad-BREG-shift.png" title="KD11-B data path bad BREG shift register" width="85%"/></p>
<p>This part was pulled and replaced, and the ROM terminal emulator could then correctly handles LFs! After a
few additional red herring 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:</p>
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:</p>
<p><img src='/images/pdp11/gt40-line-feeds_thumbnail_tall.jpg' title='GT40 displaying multiple lines after CMPB (R2)+,R0 fix.' onclick='pswipe("pdp11",113);'/>
<img src='/images/pdp11/gt40-first-lunar-run_thumbnail_tall.jpg' title='GT40 running the lunar lander game, but still with some display issues.' onclick='pswipe("pdp11",114);'/></p>
<p>Scott discovered a major clue concerning remaining loader problems: some GT40 binary-loader encoded binaries
downloaded off other enthusiast web sites contain erroneous extra linefeed and "!" characters, which confuse
the loader and/or trigger bad checksums. After stripping these out, the loader was seen to work quite
reliably.</p>
<p>With diagnostics now in hand, Scott was able to track down a few remaining hardware issues (a bad register
with a stuck high bit, and a swap of one of the DACs that 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 I get more details.)</p>
<p>Below, 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!</p>
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.</p>
<p>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 that 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 details.)</p>
<p>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!</p>
<p><img src='/images/pdp11/gt40-diags_thumbnail_tall.jpg' title='Repaired GT40 running diagnostic MAINDEC-DDGTE.' onclick='pswipe("pdp11",115);'/>
<img src='/images/pdp11/gt40-lunar-better_thumbnail_tall.jpg' title='Repaired GT40 running the lunar lander game.' onclick='pswipe("pdp11",116);'/>
<img src='/images/pdp11/gt40-cheeseburger_thumbnail_tall.jpg' title='Repaired GT40: Scott lands on the moon and gets his cheesburger!' onclick='pswipe("pdp11",117);'/></p></div>
Expand Down
Loading

0 comments on commit 01e816c

Please sign in to comment.