Updated card image or updated repository

[Mike Katz]

A couple of months ago I tried to install Raspberry Pi OS on a Pi 4B and
i was unable to fine a working card image or repository that I could
build from.

I am running a Pi 4B with the latest version of bookworm on it. Does
anyone no of a repository I can build and run with a fresh install from
the Raspberry Pi Imager or a complete SD card image that boots the
latest code (and all patches) in bookwork?

In the mean time I'm running the walking LED test but I would really
love to be running a real OS.

Thank you

[Johnny Billquist]

If you want to run RSX, I *strong* recommend you go to
http://mim.stupi.net/pidp.htm and install that one.
Honestly, this is for everyone: do not use any other source/image. There
is so much that is improved in the system in that image that you will
not get by using any other option that it's just a bad idea to use any
other.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Mike Katz]

Johnny,

Does that image support picking the OS by the front panel switches?

Thank you,

          Mike

[Johnny Billquist]

The whole question of picking up OSes happens at an earlier stage. The
RSX distribution is just one PDP-11 OS. Picking happens before anything
is booted.

Johnny

[Mike Katz]

Johnny,

I'm trying to find a card image that has all (or most of the most
recent) patches in it for all of the 11 OS's or a repository that i can
clone and build off of like we do the Fossil repository that Bill Cattey
maintains for the PiDP-8/I.

Thanks again,

               Mike

[Johnny Billquist]

Sorry. I have not tried to replace, or manage the boot system selection
bits, nor any of the other OSes. I'm only working on RSX, but you really
should be using that RSX image, and not any of the others.

But the whole design of the system to pick a OS to boot is completely
agnostic to what images you use. Just place this in one directory, and
off you go. Read up on how that bit works. It's pretty simple.

Johnny

[terry-...@glaver.org]

To do a clean install on the latest Raspberry Pi OS, go here: https://obsolescence.dev/pidp-11-building-instructions.html and scroll down to "Option #2".

There are a number of issues remaining. The most annoying one

is the front panel emulation dying and other related bugs (like

clicking the PiDP-11 desktop icon and just getting a window that

prints "0" and exits. The 32-bit PiDP-11 package has a hack to

reduce the frequency of these. It's in the 64-bt but the binary

was never compiled (the sources are correct, the binary is out-

of-date).

Also, some of the disk images are missing when installed from

that script are missing - for example, the RT-11 games disk. Ask

around for someone who has an old copy of systems.tar.gz. It

should be about 111MB. You can get the missing pieces there.

There are a number of meta-issues as well:

Oscar doesn't put release dates on the download links, and his 

web server does not allow directory listings, so you can't tell if 

what's there is newer than what you have or not.

There are a number of people who maintain OS images "out

of tree" - Johnny for RSX-11M+, someone else for 2BSD, and

me for RSTS/E 10.1.

I have suggested to Oscar that he move to GitHub for all of

this and give commit privs to the people maintaining those OS

images, but he hasn't been too receptive.

Frankly, if someone rewrites the front panel code to use the

API available in modern simh, I think it is time for a fork. I can

do the rewrite, but I just got off a 6 month long product de-

velopment and am taking a well-deserved 2-month break in the

Mojave Desert. Maybe when I get back, if nobody else has

started working on it.

[oscarv]

Terry,

On Wednesday, November 13, 2024 at 8:02:52 PM UTC+1 terry-...@glaver.org wrote:

To do a clean install on the latest Raspberry Pi OS, go here: https://obsolescence.dev/pidp-11-building-instructions.html and scroll down to "Option #2".

There are a number of issues remaining. The most annoying one

is the front panel emulation dying

That should have been fixed with today's post! https://groups.google.com/g/pidp-11/c/sviHgH1-OZU/m/BbMMDBr5CQAJ

 

I have suggested to Oscar that he move to GitHub

I should - but these days I have 1-2 hours of Fog Free Brain time, so I'm struggling with major moves :-(

 

Frankly, if someone rewrites the front panel code to use the

API available in modern simh

That will not work well, the API can't handle all the corner cases of the front panel behaviour. At least, that was the case a few years ago but I'd be surprised if it changed. To give you an idea of the corner cases, look at Joerg Hoppe's video archive from the panel tests we did: https://www.retrocmp.com/stories/pdp-11-70-panel-research (mention far beyond honorary to Mike Hill, who wrote a 50 page test script for this exercise at the LCM's Miss Piggy 11/70!)

 

If I set up a PiDP-11 github repository, and give you access, would that work?

Kind regards,

Oscar.

[oscarv]

On Saturday, October 19, 2024 at 1:32:59 AM UTC+2 justme...@gmail.com wrote:

A couple of months ago I tried to install Raspberry Pi OS on a Pi 4B and
i was unable to fine a working card image or repository that I could
build from.

[..]

In the mean time I'm running the walking LED test but I would really
love to be running a real OS.

I'm a bit confused here, still - the setup procedure on the Building Instructions (including running the install script!) will get you all the running OSes?

https://obsolescence.dev/pidp-11-building-instructions.html

Tested pretty much weekly by myself and about 5 new builders a week, that gets you to full bootabilty of all OSes. 

Or do you refer to the new, updated OS images from Johnny and Chase Costello? Yes, you can just drop them in the opt/pidp11/systems directory.

Kind regards,

Oscar.

[Mike Katz]

Oscar,

It's good to see you back online.

What I was looking for for the PiDP-11 is what we have (thanks to Bill Catty) for the PiDP-8/I. 

For the PiDP-8/I I do the following:

1. Create a bootable microSD card with the Raspberry Pi Media Creator
2. Boot the Pi and update the operating system
3. Get the PiDP-8/I software branch from Fossil
4. Follow the build instructions
5. Viola I have a fully functional PiDP-8/I with several operating system and other programs.

I was unable (on a Pi 5 or Pi 4) to be able get anything working.  I tried multiple images, 32 and 64 bit OS and the Pi 4 and Pi 5.

Does your latest image either have the full boot microSD image or has a compressed tar file that i can install on a clean card?

Thank you,

           Mike

--
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/01e44490-331e-4e0b-9dd6-1b51dd975f06n%40googlegroups.com.

[Johnny Billquist]

Oscar,

On 2024-11-25 19:46, oscarv wrote:
> Terry,
>
>
> On Wednesday, November 13, 2024 at 8:02:52 PM UTC+1 terry-...@glaver.org
> wrote:
>
> To do a clean install on the latest Raspberry Pi OS, go here:
> https://obsolescence.dev/pidp-11-building-instructions.html
> <https://obsolescence.dev/pidp-11-building-instructions.html> and
> scroll down to "Option #2".
>
> There are a number of issues remaining. The most annoying one
> is the front panel emulation dying
>
>
> That should have been fixed with today's post!
> https://groups.google.com/g/pidp-11/c/sviHgH1-OZU/m/BbMMDBr5CQAJ

> <https://groups.google.com/g/pidp-11/c/sviHgH1-OZU/m/BbMMDBr5CQAJ>

If that is the same fix that has been published before, it makes the
system work better, but it still hangs eventually.

> Frankly, if someone rewrites the front panel code to use the
> API available in modern simh
>
>
> That will not work well, the API can't handle all the corner cases of
> the front panel behaviour. At least, that was the case a few years ago
> but I'd be surprised if it changed. To give you an idea of the corner
> cases, look at Joerg Hoppe's video archive from the panel tests we did:
> https://www.retrocmp.com/stories/pdp-11-70-panel-research
> <https://www.retrocmp.com/stories/pdp-11-70-panel-research> (mention far
> beyond honorary to Mike Hill, who wrote a 50 page test script for this
> exercise at the LCM's Miss Piggy 11/70!)

I honestly don't know what the API looks like, but I do think something
else than the current hack should be put in. And I don't understand the
"streaming of LED data" solution. It might work, but it would make more
sense to just have some shared memory where the client side just would
write the intensity (even more clever, bump it up whenever it goes on,
and have a decay working in the background to achieve the effect of LEDs
fading out). And the server side just reads out what the intensity
should be, and does each LED based on that.
No streaming of data, no fancy communication between the two sides. Keep
things simple and straight forward.

And if the simh API isn't up to the task, then it should be rewritten.

Johnny

[Mike Katz]

Maybe I totally misunderstand the problem but hasn't all of this,
including incandescent lamp simulation, already been done for the PiDP-8/I.

Is there any reason that the PiDP-8/I front panel code can't be used on
the PiDP-1170 with the appropriate SiMH front panel hooks that the
PiPD-8/I is using but for PDP-11 simulation.

That code could then also be used for the PDP-10 and PDP-1, giving us a
common light driver for all of the PiDP's.

[oscarv]

Mike,

I don't quite understand - we have the same for the PiDP-11 as for the -8: ready-made disk images and (recommended) an install procedure to get a normal Raspberry Pi OS installed for the PiDP-11?

See here: https://obsolescence.dev/pidp-11-building-instructions.html , in the 'prepare your Pi' section.

I went through the steps yesterday - no problems even with the latest Pi OS version of 19 November.

On Monday, November 25, 2024 at 8:10:30 PM UTC+1 justme...@gmail.com wrote:

I was unable (on a Pi 5 or Pi 4) to be able get anything working.  I tried multiple images, 32 and 64 bit OS and the Pi 4 and Pi 5.

Does your latest image either have the full boot microSD image or has a compressed tar file that i can install on a clean card?

Yes, both options. I'm confused on why you can;t get it to work - would you mind mailing me directly at oscar.v...@hotmail.com to figure out where the problem is?

But from the above URL:

sudo mkdir /opt/pidp11
cd /opt
sudo wget http://pidp.net/pidp11/2024/pidp11.tar.gz
sudo gzip -d pidp11.tar.gz
sudo tar -xvf pidp11.tar
sudo /opt/pidp11/install/install.sh

...on a (any, 32 or 64 bit) fresh Raspbian SD card will get the PiDP-11 to Blinkenlights with all the OSes.

Kind regards,

Oscar.

[oscarv]

Johnny,

On Monday, November 25, 2024 at 9:18:58 PM UTC+1 b...@softjar.se wrote:

I honestly don't know what the API looks like, but I do think something
else than the current hack should be put in.

As in, we hacked the driving of the front panel into the simh's simulated PDP-11 CPU? I don't think the word 'hack' there has any negative connotations for me ;-)

Getting simh to drive the LEDs in all corner cases is decidedly nontrivial.

We did this before the simH front panel API came into being. But I must say, that API looks very complicated - I never quite 'got it'. It certainly does not have less overhead than what's being done in the BlinkenBone/PiDP-11: have a separate, concurrent thread read out the CPU register variables constantly - with a few hacks necessary in the CPU code to ensure the panel lamps behave authentically.

 

So, the current setup:

1) a few places in the CPU emulation where lines are added to SimH for fidelity of the front panel behaviour,

2) a concurrent thread that samples the simulated CPU register variables and takes care of Lamp Glow averaging,

3) a separate program that receives the lamp data and brings it onto the Pi's GPIO pins for the panel.

Yes, 3) could be brought into 2). But the reduction in CPU load for the Pi is not all that much. And Joerg's argument that separating the two allows for more options *is* a valid one.

And I don't understand the
"streaming of LED data" solution.

This was Joerg's concept - keep in mind the same code is used on the BlinkenBone to revive real PDP-11 front panels with simh. The idea is that it gives you flexibility because if you want, the simulator can run on a different computer than the panel driver. Not necessary on the PiDP-11 - almost nobody runs the simh client on a desktop with the Pi running just the front panel. But if you want the fastest PDP-11, that is how you can do it.

The PiDP-8 and -10 have the front panel driver straight in SimH, not as a separate client/server model. But it's just different means to the same end.

 

It might work, but it would make more
sense to just have some shared memory where the client side just would
write the intensity (even more clever, bump it up whenever it goes on,
and have a decay working in the background to achieve the effect of LEDs
fading out).

Joerg's approach does that!

So IMHO the choice between driving the LEDs directly from within the simH binary or driving them over a server program is a matter of preference. I personally like  the direct approach, because simplicity. But the overhead from data flow between client and server is insignificant, really.

And if the simh API isn't up to the task, then it should be rewritten.

I'm working on driving the PiDP front panel from just a $7 esp32 board, based on Jeroen (SpriteTM)'s example of a few years ago. I've got a $7 esp32 with onboard SD card, and it is all that's needed to run 211BSD at authentic speeds. Evening project to get that blinking the front panel. But there too, using the SimH API will not work well, adds overhead for the humble esp32. The 'hack' approach (of all the PiDPs, they're all the same in following that approach) is lighter.

Kind regards,

Oscar.

[terry-...@glaver.org]

On Monday, November 25, 2024 at 10:46:17 AM UTC-8 oscarv wrote:

On Wednesday, November 13, 2024 at 8:02:52 PM UTC+1 terry-...@glaver.org wrote:

There are a number of issues remaining. The most annoying one

is the front panel emulation dying

That should have been fixed with today's post! https://groups.google.com/g/pidp-11/c/sviHgH1-OZU/m/BbMMDBr5CQAJ

  Is that a different fix than the 64-bit parts of the binary install using old compiled versions without the fix? You had me do a make to bring the 64-bit parts up-to-date with the 32-bit parts a while ago that didn't help.

  I'm 2500+ miles away right now so I can't test.

  However, that's far from the only issue (although they may all be related). These are from memory and may be incomplete/incorrect:

  1) Getting an "assertion failed" and having the front panel display blank or stuck

  2) Getting a "write to socket failed" and having the front panel display blank or stuck

  3) (May be a result of either of the first two) the front panel display process just disappears

  4) Clicking the PiDP desktop icon just opens a terminal window that displays "0" and closes

  5) We need a way to (persistetly) specify the correct rotation of the rotary encoders - that could be in the realcons section of the simh config

  Generally, my way out of all of these has been to reboot the Pi, since it isn't obvious what the recovery steps would be. I think for 1 & 2 the simh code won't recognize a new launch of the LED display program, and for 4 this means that something has gone wrong with screen (possibly due to dying processes).

  If we're going to stick with the simh version we have with the blinkenbone code, the error handling needs to be made more resilient (like retrying the operation and if necessary re-launching the LED display program instead of just abandoning the front panel emulation). I don't know what is going on with screen from item 4.

I have suggested to Oscar that he move to GitHub

I should - but these days I have 1-2 hours of Fog Free Brain time, so I'm struggling with major moves :-(

  My issues with the current distribution method are:

  1) There's no way to see what has changed (if anything) - the web server you're using will only serve a file if you know the name, and all of this lives in a "2024" filename, and I don't know if that's a moving target or if it never changes. When I hosted the files, you could get a directory listing and see if the file modification times had changed.

  2) The install script fetches something similar to the old systems.tar.gz which appeared to be incomplete compared to that old file - one thing I noticed was that the RT-11 games disk was missing.

  3) We have contributors for at least RSX (bqt), 2BSD (I forget who) and RSTS/E 10.1 (me) who would probably push images to a repo when changes are made. Right now it's "do the install as documented, find the missing disk images somewhere, then fetch newer images from a bunch of places. To keep up to date, remember to look in all of those places.

  4) People have reported that the graphics terminal in RT-11 doesn't work, which is likely related to random Raspberry Pi OS changes (see below)

  5) People have reported that the "throttle" command in the config sometimes erroneously reports an error that the emulator can't execute fast enough to meet the throttle setting, which is untrue. I don't know what the simh timing sampling code is doing, but I do know it has been fixed in newer [Open]simh releases.

Frankly, if someone rewrites the front panel code to use the

API available in modern simh

That will not work well, the API can't handle all the corner cases of the front panel behaviour. At least, that was the case a few years ago but I'd be surprised if it changed. To give you an idea of the corner cases, look at Joerg Hoppe's video archive from the panel tests we did: https://www.retrocmp.com/stories/pdp-11-70-panel-research (mention far beyond honorary to Mike Hill, who wrote a 50 page test script for this exercise at the LCM's Miss Piggy 11/70!)

  It gets us onto a modern version of simh (AFAIK, neither the original simh nor Opensiimh accepted the Blinkenbone patches, so we're stuck at whatever level of simh we're running). That isn't a huge issue as the actual PDP-11 emulation hasn't changed, but some of the ways simh does things have changed.

  If the API doesn't support needed functions or implements some incompletely/incorrectly, we can approach the maintainers with bug reports and (ideally) code fixes. That means we can simply track Opensimh. I've run into a number of issues with physical serial ports in the simh version that the PiDP-11 is using that have been corrected in later [Open]simh releases. I've also had some people tell me my instructions for physical serial ports don't work, mostly because of differences in [Open]simh, but also because parts of my instructions were apparently lost when you rearranged the web page.

  We also need to get something that isn't so fragile that changes to Raspberry Pi OS don't break it. The blame for that lies with the Raspberry Pi OS people - they definitely use the "move fast and break stuff" methodology. We need a way to be responsive to those changes and have the installer reflect them (see my comment about versioning above).

  API speed issues should be a non-issue - even a Pi 3B+ can easily outperform a real 11/70 when throttling is off, and a Pi 5  with throttle off is so fast that you pretty much never see anything other than the idle LED pattern. The 4 is somewhere in the middle. I have the timings written down somewhere at home.

If I set up a PiDP-11 github repository, and give you access, would that work?

  We need to get buy-in from the various people that maintain up-to-date OS images, so that the can push them with minimal effort.

  I'm kind of burned out from various projects (the MOD-SIX clock in the past, another maker-type project since then, and now I'm coordinating product development and writing the Windows programing software for a number of different radio models) and I'm just wrapping up an unexpectedly long stay in California (car trouble, etc.) so I missed both my partner's birthday and Thanksgiving, so I'll also have to atone for that once I get home. I have a major radio release coming in the January / February timeframe, as well as needing to give some long-postponed lectures on a variety of topics, so it likely won't be until the March / April timeframe before I can add more than a token effort. On the bright side, that should provide time to see if the latest front panel code changes fix things, and to get buy-in from the other OS maintainers.

[oscarv]

Terry,

On Sunday, December 1, 2024 at 3:33:43 PM UTC+1 terry-...@glaver.org wrote:

  Is that a different fix than the 64-bit parts of the binary install using old compiled versions without the fix? You had me do a make to bring the 64-bit parts up-to-date with the 32-bit parts a while ago that didn't help.

Yes.

  I'm 2500+ miles away right now

You might have some jet lag :-)

  However, that's far from the only issue (although they may all be related). These are from memory and may be incomplete/incorrect:

Issues 1-3, I've never heard of, but --

   5) We need a way to (persistetly) specify the correct rotation of the rotary encoders - that could be in the realcons section of the simh config

I'll look into that but  the fix is easy.

Anyway, maybe try this in a few days (when the inevitable bugs from a new version have been ironed out:

https://github.com/obsolescence/pidp11

But please, start from a clean new install on the latest Raspberry Pi OS - I'm wondering about the condition of your current SD OS image...

  We also need to get something that isn't so fragile that changes to Raspberry Pi OS don't break it.

Sorry - this thing is not 'so fragile' at all. You seem to have some specific issues, but fragility is not exactly the feedback that I get otherwise.

Keep in mind that Raspberry PI OS goes through quite radical changes over time. Everything from networking to X/Wayland transitioning to new Pi versions which break basic GPIO code. I'd think I updated the package for every one of those moves reasonably quickly. And otherwise there's preinstalled SD card images with the previous Raspberry OS for download too, just so people don't get frozen out after a new Pi OS releases crops up unannounced.

 

  We need to get buy-in from the various people that maintain up-to-date OS images, so that the can push them with minimal effort.

Done - the new install script grabs disk images straight from Johnny's ftp and from Chase's github. I hope they'll have some feedback clean up the boot.ini for both systems.

 

  I'm kind of burned out from various projects (the MOD-SIX clock in the past, another maker-type project since then, and now I'm coordinating product development and writing the Windows programing software for a number of different radio models) and I'm just wrapping up an unexpectedly long stay in California (car trouble, etc.) so I missed both my partner's birthday and Thanksgiving, so I'll also have to atone for that once I get home. I have a major radio release coming in the January / February timeframe, as well as needing to give some long-postponed lectures on a variety of topics, so it likely won't be until the March / April timeframe before I can add more than a token effort. On the bright side, that should provide time to see if the latest front panel code changes fix things, and to get buy-in from the other OS maintainers.

Anyway - I hope for some feedback from daring beta testers of the new Github-based version. I'm sure there will be some wrinkles (the thing has to run under X and Wayland, 32 and 64 bit, a few generations of Raspberry Pi OS, enough to make any brain fog over). In a week or two, after some feedback from early adopters, I'll make the Github version the one described in the manual and on the website.

 Kind regards,

Oscar.