PiDP-8/I Software

Put the processor into single instruction mode, set SR with some value, click "Load Add," then "Exam." You get some value on MB, as the 1970 Small Computer Handbook says you should. But load the address and exam again, and you get a *different* value in MB!

Furthermore, poking around with the "e" command at the SIMH prompt gives different values still. Poking a value in with a "d" command and then trying to Exam it via the front panel doesn't work.

Is this entirely broken? It used to work. Apparently we're going to have to go bisecting. To whoever does this checking: be aware that you can say "make bin/pidp8-sim", which should avoid the need to rebuild the media on each bisect step.

Is this damage from the MB fix applied in v20190425?

<p>I'm not sure I fully understand how to reproduce this problem.

<p>Can someone please re-verify this problem and help me understand what I am doing wrong?

<p>There did seem to be a time when I got random differences between what the front panel showed and what ODT and SIMH showed, but I was able to identify specifically a case where ODT was active, and playing with memory contents under the covers that might have
interacted in a funky way with SIMH and the front panel.

<p>On my PiDP-8/i, I hadn't rebuilt in a while, so I had a checkout from May, 2020. I did a quick check the Exam functionality with Sing Inst engaged.
It looked right.

<p>I just built with the latest trunk, and here is a careful transcript of what did:
<ol>
<li>Booted system.</li>
<li>Confirmed OS/8 was running.
<pre>
pi@pidp8:~/src/pidp8i/trunk $ screen -r
Configured by pi@pidp8 on 2021.01.31 at 19:34:22 EST
Restart address = 07600
...
</pre>
</li>
<li> Use ODT and SIMH exam to review memory contents.
<pre>
.ODT

2022/4343 
0200/1203 

00201 /7000 
5000/1114 

05001 /1405 
^C
.
Simulation stopped, PC: 01207 (KSF)
sim> e 2022
2022:   4343
sim> e 0200
200:    1203
sim> e 0201
201:    7000
sim> e 5000
5000:   1114
sim>
sim> e 5001
5001:   1405
sim>
</pre>
<p>If I hit "Sing Inst" here, nothing happens. The SIMH processor must be running to obey the front pane.
<pre>
sim> c
</pre>
</li>
<li>Flipped the "Sing Inst" switch.
<pre>
Program Counter: 1210
Memory Address: 1203
Memory Buffer: 0
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre>
</li>
<li>Put 0200 in the switch register.</li>
<li>Press Load Add
<pre>
Program Counter: 0200
Memory Address: 1203
Memory Buffer: 0
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 0201
Memory Address: 0200
Memory Buffer: 1203
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Load Add
<pre>
Program Counter: 0200
Memory Address: 0200
Memory Buffer: 1203
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 0201
Memory Address: 0200
Memory Buffer: 1203
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 0202
Memory Address: 0201
Memory Buffer: 7000
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Put 2022 in the switch register.</li>
<li>Press Load Add
<pre>
Program Counter: 2022
Memory Address: 0201
Memory Buffer: 7000
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 2023
Memory Address: 2022
Memory Buffer: 4343
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Put 5000 in the switch register.</li>
<li>Press Load Add
<pre>
Program Counter: 5000
Memory Address: 2022
Memory Buffer: 4343
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 5001
Memory Address: 5000
Memory Buffer: 1114
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Press Exam
<pre>
Program Counter: 5002
Memory Address: 5001
Memory Buffer: 1405
Accumulator: 0 
Link: 0
Multiplier Quotient:
</pre></li>
<li>Put 7600 in the switch register.</li>
<li>Press Load Add
<pre>
Program Counter: 7600
Memory Address: 5001
Memory Buffer: 1405
Accumulator: 0 
Link: 0
Multiplier Quotient: 0
</pre></li>
<li>Raise Sing Inst</li>
<li>Press Start</li>
<li>Use OS/8 and SIMH to examine memory locations.
<p><b>IMPORTANT</b>: If you examine 0200 in SIMH escaping from ODT, you will get the hack that ODT uses to let you examine memory.
<pre>
.ODT

2022/4343
0200/1203
00201 /7000
5000/1114
05001 /1405
Simulation stopped, PC: 00206 (JMP 205)
</pre>
<p><i>This is where it looked wierd but subsequently we saw it was ODT</i>
<pre>
sim> e 200
200:    4577
sim> e 201
201:    3020
sim> e 5000
5000:   1114
sim> e 5001
5001:   1405
sim> c
^C
.ODT

200/1203

Simulation stopped, PC: 00205 (KSF)
sim> e 200
200:    4577
sim> c
200/1203
</pre>
<p>As soon as we go back to OS/8 memory contents is what we expect.
<pre>
^C
.
Simulation stopped, PC: 01210 (JMP 1207)
sim> e 200
200:    1203
sim>               
</pre>
</li>
</ol>
<p>This conforms to what I expect.  When we first pause the execution, by hitting "Sing Step" the contents of the Memory address and Memory Buffer will be random.

<p>I have a 1970 Small Computer Handbook, but in the skim I did, I did not find any specific reference to indicator displays when the "Sing Step" switch was active.

<p>What should I be doing different or looking for?

There's no good reason to involve OS/8 and ODT in debugging front panel display issues. You can narrow things down with a much simpler debugging sequence:

1. Stop any running (backgrounded) simulators and run `bin/pidp8i-test` to ensure that your switches and lights are working properly to begin with.

    This is not idle advice: *not* doing this bit me in a scratch build directory where I apparently did not give the `--serial-mod` flag I need on this particular PiDP-8/I, so my results were bogus until I fixed that.

    That might've been on purpose; can't remember. Point is, make sure before continuing.

2. Build just the bare necessities for this test:

        tools/mmake bin/pidp8i-sim boot/ac-mq-blinker.script

3. Dump the above script to the screen for reference, possibly in a different terminal tab or text editor:

        cat boot/ac-mq-blinker.script

4. Run the script to load the AC/MQ blinker demo into core and start it running:

        bin/pidp8i-sim boot/ac-mq-blinker.script

5. Stop the processor by flipping the Sing Inst switch **down**.

6. With SR=0000, toggle Load Add. This should reset PC to 0000 if the PiDP-8/I front panel is to properly emulate an actual PDP-8/I per p.21 of the 1970 Small Computer Handbook. (Henceforth, just "the handbook".)

7. Toggle Exam. According to the handbook, this should put the value at core memory location 0000 in the current data (?) field into MB, being 2020 for the start of this particular program. PC should advance to 0001.

8. Toggle Exam again. PC should change to 0002 and MB should change to the next value in the program, 5000, at location 0001, the prior value of PC.

9. Toggle Load Add again. PC should reset to 0000. Repeat step 7. You should get 2020 in MB again, and PC should advance to 0001.

All of that happens here, except that MB remains 0000 as of [version 2020-05-01](/info/93d521bdd3) rather than showing me the contents of each core memory location in sequence from the initial Load Add point.

Exit SIMH with a Ctrl-E, q command sequence. You *might* need to flip Sing Inst back **up** and toggle Cont so SIMH will run again before it will pay attention to keyboard input.

If you saw the same incorrect output I did, anchor one end of the bisect with:

    fossil bisect reset
    fossil bisect bad

If you saw something that made sense to you, change the "bad" to "good" in the second command instead.

Now move to another version and see what that does:

    fossil up 07a540166c
    tools/mmake bin/pidp8i-sim boot/ac-mq-blinker.script

…and goto 4.

The above version is the nearest trunk release to v20190425, which I used instead to encourage Fossil to stay on trunk thru the bisect. If you anchor the two ends of a bisect on different branches, Fossil's shortest-path algorithm for determining which DAG nodes to visit will get confused, since the path thru the "release" branch is shorter than the path thru "trunk", resulting in confusion.

If your build is like mine, you will find that works, so:

    fossil bisect good

At that point, you've anchored the other end of the bisect, so all you have to do is repeat the core steps, deciding "good" or "bad" at each step.

After following this procedure, bisect blamed [this commit](/info/c331a1d35668ff53). Rolling back to the immediate prior commit on trunk (`fossil up prev`) fixes the symptom.

Therefore, something they did upstream in SIMH broke our use of MB for updating the front panel, at least in single-instruction mode, anyway.

I'm filing this comment as-is because it's a good description of the way you chase this sort of problem, and also because it means the next step is to figure out what changed in SIMH over this 1-year span between updates.

Further investigation shows that nothing in the SIMH PDP-8 simulator proper changed in any meaningful way, that I can see. ([Diff](/vdiff?from=059aac0685d12ee6&to=c331a1d35668ff53&glob=src/SIMH/PDP8*)) It's just a few changes to track the core improvements to tape device and clock handling, nothing to do with the simulated CPU.

On a wild guess, I tried the following diff, and it fixed the symptom, both atop the problematic SIMH merge and against tip-of-trunk:

``` diff
Index: src/SIMH/PDP8/pdp8_cpu.c
==================================================================
--- src/SIMH/PDP8/pdp8_cpu.c
+++ src/SIMH/PDP8/pdp8_cpu.c
@@ -1571,13 +1571,14 @@
     if (pidp8i_gpio && (++skip_count >= (max_skips - dither))) {
         // Save skips to inst counter and reset
         inst_count += skip_count;
         skip_count = 0;
 
-        // We need to update the LED data again.  Using IR for the MB
-        // line here for same reason as above.
-        set_pidp8i_leds (PC, SteadyMA, IR, IR, LAC, MQ, IF, DF, SC,
+        // We need to update the LED data again.  Unlike above, circa
+        // line 444, we pass the final MB value, not a copy of IR, as
+        // MB is settled by this point.
+        set_pidp8i_leds (PC, SteadyMA, MB, IR, LAC, MQ, IF, DF, SC,
                 int_req, Pause);
 
         // Has it been ~1s since we updated our max_skips value?
         time_t now;
         if (time(&now) > last_update) {
```

I made the comment change to give my *belief* as to why this fixes things, but it's the 2-character parameter change that matters.

This then opens a new question: which of the many changes to SIMH's generic code (i.e. outside the PDP-8 simulator) affected this? I mean, it seems safe to guess that upstream changed register handling in some way, but how did this affect what we're doing here? Did they fix a bug we were relying on?

I ask because it makes me wonder if the other use of IR in place of MB is wrong now, too.

Should I just commit the fix and move on?

<p>I followed the steps you called out. I give details below.  If I understand you, I should see 2020 in MB (Memory Buffer) in step 4 below, but the failure is that I would see 0000.

<p>I should see the failure in the current trunk:
<pre>
updated-to:   daf8e4403ce0bcd73821cd861962e3417ee1114f 2020-12-16 19:52:08 UTC
tags:         trunk
comment:      Moved a link for better locality. (user: tangent)
</pre>

<p>I don't see the bad value.

<p>I do see that when I verified the trunk status using fossil status,
my previous reply which I thought was built with the current trunk instead was just a rebuild of the check-in: a2ffdcf544 that I'd labeled "good-exam-1".

<p>I had misunderstood the effect of:
<pre>
cd ..
mv trunk good-exam-1
mkdir trunk
cd trunk
fossil open ~/museum/pidp8i.fossil
</pre>

<p>It re-opened trunk where it was, not at the current leaf.

<p>So I did fossil up trunk, confirmed it really was what I thought it was this time, rebuilt and retried.

<p>Alas, I <b>cannot</b> reproduce the problem.

<p>Please review and see if I mis-followed the steps.

<p>I followed your steps. At your step 1, All my lights and switches test ok.

<ol>
<li> 0000 Load Add: 
<pre>
PC: 0000
MA: 0000
MB: 1505
AC: 3177
MQ: 4600
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 3177
MQ: 4600
</pre>
</li>
<li>Exam: 
<pre>
PC: 0002
MA: 0001
MB: 5000
AC: 3177
MQ: 4600
</pre>
</li>
<li>Load Add: 
<pre>
PC: 0000
MA: 0001
MB: 5000
AC: 3177
MQ: 4600
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 3177
MQ: 4600
</pre>
</li>

</ol>

<p>Now after doing fossil up trunk and seeing that I was using the OLD build... And rebuilding everything...

<ol>
<li> 0000 Load Add: 
<pre>
PC: 0000
MA: 0000
MB: 2551
AC: 4117
MQ: 3660
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 4117
MQ: 3660
</pre>
</li>
<li>Exam: 
<pre>
PC: 0002
MA: 0001
MB: 5000
AC: 4117
MQ: 3660
</pre>
</li>
<li>Load Add: 
<pre>
PC: 0000
MA: 0001
MB: 5000
AC: 4117
MQ: 3660
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 4117
MQ: 3660
</pre>
</li>

</ol>

<p>I applied the patch, rebuilt and have followed the test steps.

<p>Below are my results.

<p>My conclusion is that the patch is benign on my configuration.  So if it fixes the problem on your configuration, then we should check it into trunk.

<ol>
<li> 0000 Load Add: 
<pre>
PC: 0000
MA: 0000
MB: 3562
AC: 4211
MQ: 3566
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 4211
MQ: 3566
</pre>
</li>
<li>Exam: 
<pre>
PC: 0002
MA: 0001
MB: 5000
AC: 4211
MQ: 3566
</pre>
</li>
<li>Load Add: 
<pre>
PC: 0000
MA: 0001
MB: 5000
AC: 4211
MQ: 3566
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 4211
MQ: 3566
</pre>
</li>

</ol>

<p>As one final test, I did:

<pre>
pi@pidp8:~/src/pidp8i/trunk $ fossil up v20190425
Autosync:  https://tangentsoft.com/pidp8i
...
pi@pidp8:~/src/pidp8i/trunk $ ./configure
...
pi@pidp8:~/src/pidp8i/trunk $ tools/mmake
...
pi@pidp8:~/src/pidp8i/trunk $ bin/pidp8i-sim boot/ac-mq-blinker.script
</pre>

<p>And re-ran the testing to see if that particular version did manifest
the bug on my hardware.

<p>My conclusion: The bug doesn't manifest on my hardware.

<ol>
<li> 0000 Load Add: 
<pre>
PC: 0000
MA: 0000
MB: 1212
AC: 3401
MQ: 4376
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 3401
MQ: 4376
</pre>
</li>
<li>Exam: 
<pre>
PC: 0002
MA: 0001
MB: 5000
AC: 3401
MQ: 4376
</pre>
</li>
<li>Load Add: 
<pre>
PC: 0000
MA: 0001
MB: 5000
AC: 3401
MQ: 4376
</pre>
</li>
<li>Exam: 
<pre>
PC: 0001
MA: 0000
MB: 2020
AC: 3401
MQ: 4376
</pre>
</li>

</ol>

Closed by [709bc3a7f6d7].