Fixing the PiDP-11 code has been an exercise in frustration

[terry-...@glaver.org]

[Sorry to come across all whiny, but "it's been a day..."]

As you may have read, I forked Oscar's GitHub PiDP11 repo with the intention of fixing the LED freeze issue.

This has expanded to a major slog through the code, particularly install.sh, to fix other issues.

Large pieces of install.sh have apparently never been tested, or have been broken by later changes and not tested after. For example, the install for Debian amd64 was horribly broken. Now it is just mildly broken - there's no amd64 Teletype binary in the installation directory and the install.sh script doesn't know how to build it. I still need to fix that one.

Other things in install.sh are out-of-sequence, like assigning capabilities to a program that hasn't been compiled / installed yet. I still need to move those to later in the install script.

I just spent the entire evening (it's now 1:15 AM) trying to figure out why the heck client11 (simh + realcons) was dying very late in the startup of my canned RSTS/E kit. It turns out that if you create a DHU11 multiplexor but don't map it to either telnet ports or physical devices, when RSTS/E broadcasts that the system is up, simh dies.

As I said, I spent lots of time trying to figure out what was going on, wiping the install and trying something else repeatedly. I actually went as far as to wipe everything and start over with Oscar's version, using his binaries, and it still failed. I ended up single-stepping through the later parts of the RSTS/E boot process and found that it was dying on the broadcast. The light bulb went on over my head: "It's not my code changes!"

This is NOT broken in Open-SIMH 4.1.0 latest, which is why I never ran into it on my non-PiDP-11 systems using the same OS disk image. The need to use the realcons mods in an obsolete simh version is leaving us further and further behind current Open-SIMH. I'm not going to to try to bring the realcons patches to Open-SIMH 4.1.0, nor am I going to wade through the Open-SIMH commit logs to find this particular fix and cherry-pick it. That's a job for someone else who is a lot more familiar with that code.

The good news is that all of the changes I've made so far in my fork ("This branch is 17 commits ahead of obsolescence/pidp11:main." - see the list at the end of this post) are working and I've made some progress on the installation script.

But I could use some moral support (I'll also accept immoral support 8-) at this point to keep going...

GitHub: https://github.com/Terri-Kennedy/pidp11 if you want to try it, but be aware it is very much a work in progress and I don't guarantee you'll get something that works if you clone the repo and do an install. Testing would be VERY welcome, though.

Done so far:

Commits on Sep 4, 2025
    Update README.md

Commits on Sep 5, 2025
    Eric N mutex fixes 1/4
    Eric N mutex fixes 2/4
    Eric N mutex fixes 3/4
    Eric N mutex fixes 4/4
    Import HOME fixes from bbqsrc / pidp11 Commit 1c126ac
    Merge mutex fix from Bill Ezell
    Fixed failure to install terminal emulator binaries when compiling from source
    Added setcap to recompile path, added note that compiling is strongly recommended

Commits on Sep 6, 2025
    Handle systems (like Debian) where cc is not aliased to gcc
    Add compilation success message to match the one in makeserver.sh
    Determine system architecture before asking about recompiling
    Comment out extraneous 'pwd'
    Be more verbose when recompiling or skipping installation
    Fix grammar in early install.sh error messages

Commits on Sep 7, 2025
    Verify we are running under Debian Bookworm
    Punctuation

[Adam Thornton]

Well, I for one think this is excellent work.  I'm running from my own (not very good) set of startup scripts because...yeah.

I'll give it a shot next time I have time to reinstall my PiDP-11.

Adam

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/3693f7c0-c344-4c9e-b534-e7274f558b84n%40googlegroups.com.

[Terry Kennedy]

On 2025-09-08 13:06, Adam Thornton wrote:

> Well, I for one think this is excellent work. I'm running from my own
> (not very good) set of startup scripts because...yeah.
>
> I'll give it a shot next time I have time to reinstall my PiDP-11.

Thanks!

[Randy James]

Thank you for all of the long hours and expertise to make this hobby so enjoyable!  I am in awe of your skills!

On Sep 8, 2025, at 12:17 AM, terry-...@glaver.org <terry-...@glaver.org> wrote:



--

[terry-...@glaver.org]

You're welcome! It's support like this that encourages me to keep going.

[timr...@gmail.com]

Here's offering my Thanks and moral support.  I don't know enough about Simh or its workings to be very helpful in any other way.

[Adam Thornton]

Looking at the actual organization: most of the changes to simh are localized in the PDP-11 cpu code, and that mostly to declare the various realcons interaction bits, but I don't yet see an easy way to glue that on top without copying and modifying the code.  Which means that it's never NOT going to be a production to add realcons to simh.

The realcons/blinkenbone code has been untouched for like 7 years, too, so...I dunno, in my copious free time I guess I should look at how it does what it does and see if there's a more straightforward way to approach what's going on.  But without a generic CPU and memory state hook mechanism I don't know what that would be.

--

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

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/0190ec72-7170-4eea-9211-f1f4e6ffb659n%40googlegroups.com.

[terry-...@glaver.org]

On Monday, September 8, 2025 at 8:29:55 PM UTC-4 atho...@gmail.com wrote:

Looking at the actual organization: most of the changes to simh are localized in the PDP-11 cpu code, and that mostly to declare the various realcons interaction bits, but I don't yet see an easy way to glue that on top without copying and modifying the code.  Which means that it's never NOT going to be a production to add realcons to simh.

The realcons/blinkenbone code has been untouched for like 7 years, too, so...I dunno, in my copious free time I guess I should look at how it does what it does and see if there's a more straightforward way to approach what's going on.  But without a generic CPU and memory state hook mechanism I don't know what that would be.

I'm told that the reason simh never merged the code was because it rather invasively changed the simh codebase.

Since then, simh has added a front panel API of their own, and said that they were willing to consider extending it to meet the needs of front panel emulators. But I don't know if that API is fast enough for use on the PiDP-11, nor if the simh developers are willing to add everything that's needed.

If somebody were to bring the realcons code into a fork of Open-SIMH, changes made to the master simh repo will need to be tracked and merged as they happen. Fortunately we're only interested in a small subset - core simh + PDP-11, so if they change (for example) something in the HP2000 simulator, we don't need to worry about it. Plus, the commit rate to Open-SIMH seems to generally be rather infrequent. If the realcons code lives in a fork of Open-SIMH, it should be easier to identify changes happening upstream.

If the realcons code was ever in GitHub as a fork of any of the simh variants, I've never seen it. All I've worked with is Oscar's version.

[terry-...@glaver.org]

On Monday, September 8, 2025 at 6:25:07 PM UTC-4 timr...@gmail.com wrote:

Here's offering my Thanks and moral support.  I don't know enough about Simh or its workings to be very helpful in any other way.

Fortunately I haven't had to touch simh (which is why I was baffled when it kept failing at the end of RSTS/E startup).

My work in the front panel code (beyond the crash fixes already committed) will just be committing a new option to control the knob rotation.

Tonight's changes (not yet commited) provide a way of optionally recompiling sty, as well as getting both the install script and actual code to work better on Debian. I was actually able to boot RSTS/E under generic Debian with my latest changes.

[Claude Felizardo]

A big thank you Terri for working on this.  I write code during the day which leaves very little time and energy for my own coding projects at home.   I have one working PiDP11 I built a couple of years ago but a friend gifted me another one earlier this year and it's been on my list of things to do for a while now so your work will be very much appreciated. 

Claude

[Adam Thornton]

On Mon, Sep 8, 2025 at 8:59 PM terry-...@glaver.org <terry-...@glaver.org> wrote:

> If the realcons code was ever in GitHub as a fork of any of the simh variants, I've never seen it. All I've worked with is Oscar's version.

I think it's https://github.com/j-hoppe/BlinkenBone but I don't know whether Oscar has modified that.

Adam

[terry-...@glaver.org]

I believe Oscar said that there were just a few changes needed.

However, the GitHub BlinkenBone repo is itself not a fork of any other repo, simh or other. All we know is that the BlnkenBone repo was populated om March 19, 2018. The only identifier from the BlinkenBone version of simh is "PDP-11 simulator V4.0-0 Current", so we don't really know what simh version it came from.

[desa...@gmail.com]

>  If somebody were to bring the realcons code into a fork of Open-SIMH, changes made to the master simh repo will need to be tracked and merged as they happen.

I did manually merge the realcons changes to a newer git branch here:

https://github.com/desaster/simh-realcons-pdp11

But this was already 5 years ago, so I'm sure much has changed after that. Having the changes in git made merging the realcons changes to newer upstream much easier though.

Realcons changes to the upstream code can be examined as a diff by comparing the branches. On github this can be done with the pull request feature:

https://github.com/desaster/simh-realcons-pdp11/compare/upstream...desaster:simh-realcons-pdp11:realcons?expand=1

[terry-...@glaver.org]

On Tuesday, September 9, 2025 at 3:30:42 AM UTC-4 desa...@gmail.com wrote:

I did manually merge the realcons changes to a newer git branch here:

https://github.com/desaster/simh-realcons-pdp11

But this was already 5 years ago, so I'm sure much has changed after that. Having the changes in git made merging the realcons changes to newer upstream much easier though.

 

Indeed. But then someone has to keep up with the upstream version or it can become more work to keep up with upstream vs. just doing a new fork and re-merging realcons: "This branch is 5 commits ahead of, 1325 commits behind simh/simh:master."