Looking for help with strange issue

[Bill E]

A user is trying out my mods version. He runs spacewar48, it runs fine. He turns on ss6, pidp halts. Apparently happens on some other progs that use sense switches. I can't duplicate this on an rpi4, pi5, or linux using the hardware panel, the virtual panel, the browser display, p7simES, or t30dpy. I've even done a complete new install on the pi4 of the operating system (Trixie) and pidp-mods.

Has anyone seen anything like this? Nothing I've changed should have anything to do with

the sense switches.

Thanks, Bill

PS - He does have the regular pidp version on his system, but he did a full install of mds. I do that also, again not had a problem. All I can think is that there is some mismatched binary, but if the prog runs, seems unlikely.

[Bill E]

Really getting frustrated with this one. I just tried a dual install, I can switch back and forth via the install.sh script in either, still can't duplicate the problem.

Help!

Bill

[Whit Turner]

Is he running on a physical panel? I am currently just running in virtual mode on a Pi 5 desktop since I don't have a kit yet. I just installed your pidp1-mods alongside the old pidp-1 software and could not duplicate this; things are working fine, FWIW.

Whit

--
You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/2c0764d4-afc5-4fd6-9bbb-f5ad6bb091a8n%40googlegroups.com.

[Bill E]

Yes, but he also tried it using the virtual panel. I checked the address in spacewar48 that was displayed when the pidp halted, it wasn't anywhere in the program code, but the instruction in the memory buffer was a regular dpy -i 4000, which is executed in many places. It's totally strange and I still haven't been able to duplicate it with any combination of  pi4, panels, single or dual installs, etc. I'd think it was a hardware issue, except he says it happens on another pi4 also. Hmm, weren't there 2 versions of the pi4? Maybe it's the older version? Still doesn't explain why it's happening. Well, I'll keep this as an open bug for now, if someone else sees it, possibly that will give some useful info.

Bill

[Whit Turner]

Bill - I am running Trixie 13..5 (and I think with all the latest updates) and it seems to behave in virtual mode - is that what you do your testing with? Wondering if there could be issues with older versions.

I recall reading something about Trixie breaking GPIOs with the physical panel; not sure if that got fixed in the PiDP-1 code.

Whit

On Wed, May 27, 2026 at 5:49 PM Bill E <wjegr...@gmail.com> wrote:

Yes, but he also tried it using the virtual panel. I checked the address in spacewar48 that was displayed when the pidp halted, it wasn't anywhere in the program code, but the instruction in the memory buffer was a regular dpy -i 4000, which is executed in many places. It's totally strange and I still haven't been able to duplicate it with any combination of  pi4, panels, single or dual installs, etc. I'd think it was a hardware issue, except he says it happens on another pi4 also. Hmm, weren't there 2 versions of the pi4? Maybe it's the older version? Still doesn't explain why it's happening. Well, I'll keep this as an open bug for now, if someone else sees it, possibly that will give some useful info.

Bill

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/4be080e7-e717-4754-8ecd-06030a5ad8d9n%40googlegroups.com.

[Win Heagy]

I have not tried it with the virtual panel, but as Bill mentioned, I did try with two different RPi 4b and see the same issue with each.  When running spacewar48.rim (also other software like icss*.rim), when I move the SS6 (or any SS) to On to remove the central star, the display goes blank and the front panel halts.  I cannot restart without reloading the tape.  

Even more strange is that on the one RPi4, it does this only in the -mods repo.  On the second RPi4, it does it in both repos...both in the GUI and the web interface.  I put my RPi5 back in the PiDP-1 and everything works as expected.  Just to be complete, I swapped out USB devices (keyboard, mouse, etc.) and tried different power supplies, with no significant change.  I've also tried fresh OS installs and only installing -mods...no change.  

Win

[Whit Turner]

Wondering if this is a firmware issue between the two Pi 4s. Have you tried:

sudo rpi-eeprom-update

?

Also what version of raspbian are you using?

Whit

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/8ce4b31a-3c7a-42ce-a01d-57b474e8686en%40googlegroups.com.

[Win Heagy]

Hmmm...good idea.  I have not tried a firmware update but will do that.  The two Pi 4 that I have are a couple years old, at least.  I am running raspberry Pi OS, 64 bit, with a 2026-04-21 release date.  

Thanks,

Win

[Bill E]

Testing with my pi4 with the latest release and firmware, still can't duplicate. Just to confirm, did you see this same problem with the virtual on-screen panel? If so, it can't be the gpio timing, only the physical panel driver uses that. This makes it even more of a mystery.

Bill

[Win Heagy]

Hey Bill,

Thanks for checking.  

I just tested with the Pi4 and it worked fine for me with the virtual panel.  No issues.

Win

[Bill E]

The original panel driver should work with the mod release, except for the high speed channel light. You could take the driver, which is  opt/pidp1/src/blincolnlights/panel_pidp1/panel_pidp1 and copy it over the corresponding one in /opt/pidp1-mods if you want to try that. I reviewed the few changes I made, there was only one that could possibly be related, but not sure. It was a small change in timing around one bit of gpio timing. Don't see how it could crash the pidp1 though, it's a separate process.

Bill

[Win Heagy]

When I replaced the -mods panel driver with the original, it fixed the display blanking issue when changing a SS, but the panel LEDs flicker at a very high frequency...it almost looks like the panel is shimmering.  So it appears to possibly be something in the panel driver.

Thanks,

Win

[Bill E]

Ok, I'll change the one timing factor that has to do with switches back to the original. It was 20 usecs, I changed to 10 usecs. Apparently the pi4 has some gpio timing sensitivity.

Thanks again for all your help,

Bill

[Bill E]

Done.

Bill

https://github.com/wjenh/pidp1-mods.git

[Win Heagy]

Bill,

That did it!  I tried a few programs that I knew were giving me issues and they all work.  I only copied over the panel_pidp1.c file and rebuilt.  I assume that is the only one you changed.

Thanks for the time on this.

Win

[Malcolm Ray]

One thing to watch out for when switching binaries around is that the panel_pidp1 binary doesn't lose the cap_sys_nice capability. Without it, you'll often get flickering like you describe. If you look at the install.sh script, you'll find the setcap command which sets the necessary capability.

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/195e2337-4581-4e24-98fe-8a10dea0e941n%40googlegroups.com.

[Win Heagy]

Yes, thanks.  I did notice that and ran the install script and all looks good.

Win

[Bill E]

Good point. Normally, should be no need to mix binaries, and the panel driver is the only thing that needs special settings. I'm looking at that currently, no reason it should other than it is very compute intensive and also scans the state of the lights the pdp1-emulator sets every 3 microseconds. Given that the original bulbs took tens of milliseconds to turn on and off, seems excessive. It appears to do this to accumulate a duty cycle for each light. Why that isn't done in the emulator itself is a mystery. Stay tuned on that one.

As for mixing binaries, the new display, t30dpy, is the only new closely-tied bit that will work completely with either version, and I think with various simh versions.

The am1 assembler is totally independent, but the debugger is totally dependent, won't work at all with the original emulator. The current modified panel supports the H.S. Cycle light, but that isn't used in the original. None of the new audio features or any of the added peripherals will work, no support for the IOTs, and neither will some of the extended 1D instructions.

Bill