Fix a few remaining typos/grammos in GT40-2.md

author/fritz-mueller.html

@@ -131,46 +131,48 @@
 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
-   to...<br><br></li>
+<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 switch depressed and held, and several manual clocks taken causing
+   microbranch to...<br><br></li>
 <li><code>CCS-1</code>: Loads B←PC, causing PC to be displayed on console lights.</li>
 <li><code>CCS-2</code>: Loops waiting for CONT switch to be released.</li>
 <li><code>CCS-3</code>: Turns on RUN light.<br><br></li>
 <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>: 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-3</code>: Loads PC←B, updating the PC, and suspends processor clock until instruction fetch bus cycle reaches
+  SSYN.</li>
+<li><code>F-4</code>: 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.</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 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-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates asynchronous bus cycle to
+  read source operand from memory.</li>
+<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR, which increments the 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>
+<li><code>S1-2</code>: 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.</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 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>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, <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 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:</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 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);'/>
+<p><img src='/images/pdp11/gt40-line-feeds_thumbnail_tall.jpg' title='GT40 displaying multiple lines after CMPB (R2)+,R0 LF 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
 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
+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 details.)</p>
+if/when I get more information.)</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>

category/pdp-11.html

@@ -131,46 +131,48 @@
 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
-   to...<br><br></li>
+<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 switch depressed and held, and several manual clocks taken causing
+   microbranch to...<br><br></li>
 <li><code>CCS-1</code>: Loads B←PC, causing PC to be displayed on console lights.</li>
 <li><code>CCS-2</code>: Loops waiting for CONT switch to be released.</li>
 <li><code>CCS-3</code>: Turns on RUN light.<br><br></li>
 <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>: 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-3</code>: Loads PC←B, updating the PC, and suspends processor clock until instruction fetch bus cycle reaches
+  SSYN.</li>
+<li><code>F-4</code>: 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.</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 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-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates asynchronous bus cycle to
+  read source operand from memory.</li>
+<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR, which increments the 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>
+<li><code>S1-2</code>: 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.</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 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>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, <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 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:</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 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);'/>
+<p><img src='/images/pdp11/gt40-line-feeds_thumbnail_tall.jpg' title='GT40 displaying multiple lines after CMPB (R2)+,R0 LF 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
 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
+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 details.)</p>
+if/when I get more information.)</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>