PiDP-8/I Software: View Ticket

Ticket Hash:	7ae7a73744c9c0e7b5554f8e2f2af76b100ffef3
Title:	LOAD_ADD + EXAM not working
Status:	Closed	Type:	Code Defect
Severity:	Critical	Priority:	Immediate
Subsystem:	front panel	Resolution:	Fixed
Last Modified:	2021-02-07 23:11:15
Version Found In:	trunk and v20190425
User Comments:
tangent added on 2020-07-20 23:48:11: 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. tangent added on 2020-07-20 23:49:06: Is this damage from the MB fix applied in v20190425? poetnerd added on 2021-02-01 02:43:25: I'm not sure I fully understand how to reproduce this problem. Can someone please re-verify this problem and help me understand what I am doing wrong? 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. 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. I just built with the latest trunk, and here is a careful transcript of what did: Booted system. Confirmed OS/8 was running. pi@pidp8:~/src/pidp8i/trunk $ screen -r Configured by pi@pidp8 on 2021.01.31 at 19:34:22 EST Restart address = 07600 ... Use ODT and SIMH exam to review memory contents. .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> If I hit "Sing Inst" here, nothing happens. The SIMH processor must be running to obey the front pane. sim> c Flipped the "Sing Inst" switch. Program Counter: 1210 Memory Address: 1203 Memory Buffer: 0 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Put 0200 in the switch register. Press Load Add Program Counter: 0200 Memory Address: 1203 Memory Buffer: 0 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 0201 Memory Address: 0200 Memory Buffer: 1203 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Load Add Program Counter: 0200 Memory Address: 0200 Memory Buffer: 1203 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 0201 Memory Address: 0200 Memory Buffer: 1203 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 0202 Memory Address: 0201 Memory Buffer: 7000 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Put 2022 in the switch register. Press Load Add Program Counter: 2022 Memory Address: 0201 Memory Buffer: 7000 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 2023 Memory Address: 2022 Memory Buffer: 4343 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Put 5000 in the switch register. Press Load Add Program Counter: 5000 Memory Address: 2022 Memory Buffer: 4343 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 5001 Memory Address: 5000 Memory Buffer: 1114 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Press Exam Program Counter: 5002 Memory Address: 5001 Memory Buffer: 1405 Accumulator: 0 Link: 0 Multiplier Quotient: Put 7600 in the switch register. Press Load Add Program Counter: 7600 Memory Address: 5001 Memory Buffer: 1405 Accumulator: 0 Link: 0 Multiplier Quotient: 0 Raise Sing Inst Press Start Use OS/8 and SIMH to examine memory locations. IMPORTANT: If you examine 0200 in SIMH escaping from ODT, you will get the hack that ODT uses to let you examine memory. .ODT 2022/4343 0200/1203 00201 /7000 5000/1114 05001 /1405 Simulation stopped, PC: 00206 (JMP 205) This is where it looked wierd but subsequently we saw it was ODT 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 As soon as we go back to OS/8 memory contents is what we expect. ^C . Simulation stopped, PC: 01210 (JMP 1207) sim> e 200 200: 1203 sim> 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. 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. What should I be doing different or looking for? tangent added on 2021-02-01 17:13:07: 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: 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. Build just the bare necessities for this test: `tools/mmake bin/pidp8i-sim boot/ac-mq-blinker.script` Dump the above script to the screen for reference, possibly in a different terminal tab or text editor: `cat boot/ac-mq-blinker.script` Run the script to load the AC/MQ blinker demo into core and start it running: `bin/pidp8i-sim boot/ac-mq-blinker.script` Stop the processor by flipping the Sing Inst switch down. 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".) 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. 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. 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 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. 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. tangent added on 2021-02-01 17:59:05: Further investigation shows that nothing in the SIMH PDP-8 simulator proper changed in any meaningful way, that I can see. (Diff) 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: 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? poetnerd added on 2021-02-02 01:49:05: 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. I should see the failure in the current trunk: updated-to: daf8e4403ce0bcd73821cd861962e3417ee1114f 2020-12-16 19:52:08 UTC tags: trunk comment: Moved a link for better locality. (user: tangent) I don't see the bad value. 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". I had misunderstood the effect of: cd .. mv trunk good-exam-1 mkdir trunk cd trunk fossil open ~/museum/pidp8i.fossil It re-opened trunk where it was, not at the current leaf. So I did fossil up trunk, confirmed it really was what I thought it was this time, rebuilt and retried. Alas, I cannot reproduce the problem. Please review and see if I mis-followed the steps. I followed your steps. At your step 1, All my lights and switches test ok. 0000 Load Add: PC: 0000 MA: 0000 MB: 1505 AC: 3177 MQ: 4600 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 3177 MQ: 4600 Exam: PC: 0002 MA: 0001 MB: 5000 AC: 3177 MQ: 4600 Load Add: PC: 0000 MA: 0001 MB: 5000 AC: 3177 MQ: 4600 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 3177 MQ: 4600 Now after doing fossil up trunk and seeing that I was using the OLD build... And rebuilding everything... 0000 Load Add: PC: 0000 MA: 0000 MB: 2551 AC: 4117 MQ: 3660 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 4117 MQ: 3660 Exam: PC: 0002 MA: 0001 MB: 5000 AC: 4117 MQ: 3660 Load Add: PC: 0000 MA: 0001 MB: 5000 AC: 4117 MQ: 3660 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 4117 MQ: 3660 poetnerd added on 2021-02-07 22:41:19: I applied the patch, rebuilt and have followed the test steps. Below are my results. 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. 0000 Load Add: PC: 0000 MA: 0000 MB: 3562 AC: 4211 MQ: 3566 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 4211 MQ: 3566 Exam: PC: 0002 MA: 0001 MB: 5000 AC: 4211 MQ: 3566 Load Add: PC: 0000 MA: 0001 MB: 5000 AC: 4211 MQ: 3566 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 4211 MQ: 3566 poetnerd added on 2021-02-07 22:59:13: As one final test, I did: 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 And re-ran the testing to see if that particular version did manifest the bug on my hardware. My conclusion: The bug doesn't manifest on my hardware. 0000 Load Add: PC: 0000 MA: 0000 MB: 1212 AC: 3401 MQ: 4376 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 3401 MQ: 4376 Exam: PC: 0002 MA: 0001 MB: 5000 AC: 3401 MQ: 4376 Load Add: PC: 0000 MA: 0001 MB: 5000 AC: 3401 MQ: 4376 Exam: PC: 0001 MA: 0000 MB: 2020 AC: 3401 MQ: 4376 tangent added on 2021-02-07 23:11:15: Closed by [709bc3a7f6d7].