New PiDP-11 software - for daring beta testers

[oscarv]

Hi,

I just did a major overhaul of the PiDP-11 software. Expect some wrinkles yet, but if you find beta testing entertaining:

https://github.com/obsolescence/pidp11

Changes:

• I hope the spurious race condition that froze some people's LEDs is gone. It should be, but I can't know for sure as it never hit me.
• The latest RSX-11M+ from Johnny Bilquist and 2.11BSD from Chase Covello get installed directly from their sites, and can be updated at any time.
  
• The VT-11 graphics now work under Wayland
  
• The whole process is changed - the PiDP-11 now runs similar to the PiDP-10. No more processes running as root
• Nice (I hope) new desktop with VT-52 simulator at a double-click. It's Angelo Papenhoff's. There's also a Teletype 33 simulator with sound, but that is only for entertainment. Do not look at the source code, it is just a hack. But works well for demonstrations, with all the clattering

One problem still remains: the new Raspberry Pi OS breaks the 2.11BSD-over-wifi recipe from Upi Tamminen, the one in the PiDP-11 manual. I have not yet found a good new solution. For now, the built-in NAT of simh (in Chase Covello's 2.11BSD update) is the next best solution, but it is not a full solution.

...to be continued.

Kind regards,

Oscar.

[Johnny Billquist]

To make a comment or two on the whole WiFi issue. There have been a lot
of hacks to work around the problem, but I do not consider things like
using reverse ARP to trick systems a satisfactory solution.

Running on physical ethernet is simple and straight forward, but many
people do not have that these days.

Setting up a bridge network interface is a proper solution, but managing
to get that setup and running seems to be tricky, and different for
almost every version of every OS, so I'm not super excited about this
for that reason.

One other solution would be to actually update simh to something more
current, since there is a perfectly fine, working solution there, that
do not require any of this hacking around. More recent simh have a
built-in NAT capability, meaning any outgoing connections appear as they
are coming from the host system, but are in fact from the simh system.
You can configure incoming connections on specific ports to then lead
into the simh system (doing that for things like telnet and ftp make
sense), and it all works just fine always.

But the headache of having a hacked version of simh makes this
constantly a difficult proposal. There are other changes and updates to
simh from time to time as well, which also don't show up in the PiDP-11
for this reason. This is basically not a good solution as the things are
currently.

PiDP-11 *really* needs to move to a solution where it can use a current
version of simh without a huge effort.

Johnny

On 2024-12-02 03:44, oscarv wrote:
> Hi,
>
> I just did a major overhaul of the PiDP-11 software. Expect some
> wrinkles yet, but if you find beta testing entertaining:
>

> https://github.com/obsolescence/pidp11 <https://github.com/obsolescence/
> pidp11>
>
> Changes:
>
> * I hope the spurious race condition that froze some people's LEDs is

> gone. It should be, but I can't know for sure as it never hit me.

> * The latest RSX-11M+ from Johnny Bilquist and 2.11BSD from Chase

> Covello get installed directly from their sites, and can be updated
> at any time.

> * The VT-11 graphics now work under Wayland
> * The whole process is changed - the PiDP-11 now runs similar to the

> PiDP-10. No more processes running as root

> * Nice (I hope) new desktop with VT-52 simulator at a double-click.

> It's Angelo Papenhoff's. There's also a Teletype 33 simulator with
> sound, but that is only for entertainment. Do not look at the source
> code, it is just a hack. But works well for demonstrations, with all
> the clattering
>
> One problem still remains: the new Raspberry Pi OS breaks the 2.11BSD-
> over-wifi recipe from Upi Tamminen, the one in the PiDP-11 manual. I
> have not yet found a good new solution. For now, the built-in NAT of
> simh (in Chase Covello's 2.11BSD update) is the next best solution, but
> it is not a full solution.
> ...to be continued.
>
> Kind regards,
>
> Oscar.
>

> --
> 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
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/
> aef420fe-d88b-40ed-8ed8-314c9dcd8fbcn%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/aef420fe-
> d88b-40ed-8ed8-314c9dcd8fbcn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

--
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

[Flavio Villanustre]

Johnny, I agree with you. Ideally, if it was possible to configure a standard bridge between 802.11 and 802.3 networks, that would be the perfect solution, but that's not technically possible (different mediums). ProxyARP (proxying MAC addresses back and forth, mapping them to the IP address on the corresponding side and forwarding packets without decrementing the IP hop count) as it was done before with parprouted is a reasonable option. NAT would work with a combination of sNAT and dNAT, but it wouldn't be very straightforward if you want to use your BSD as a server, since you would need to remap ports and forward those packets as needed (for BSD as a client, simple masquerading should work). 

Oscar, regarding testing your beta version, it seems that simh running under the pi user has issues attaching to the network interface, and I'm not sure how to solve that, other than sudoing that process. This is the error message (it's the same for tap0):

sim> do boot.ini
boot.ini-5> reset all
Can't change speed mode while attached.
:boot.ini-18> attach dz 4000
Listening on port 4000
DZ      address=17760100-17760107*, vector=310-314*, BR5, lines=8
        attached to 4000, 7b, 0 current connections
Eth: Pcap capable device not found.  You may need to run as root
boot.ini-26> attach xu eth0
File open error
XU      address=17774510-17774517, vector=120, BR5, MAC=08:00:2B:B7:84:99
        type=DELUA, throttle=disabled
        not attached
ETH devices:
 eth0   tap:tapN                             (Integrated Tun/Tap support)
 eth1   nat:{optional-nat-parameters}        (Integrated NAT (SLiRP) support)
 eth2   udp:sourceport:remotehost:remoteport (Integrated UDP bridge support)

And eth0 was in promiscuous mode (of course).

Every time I run pcap tools (tcpdump, for example), I run them as root for this reason. Do we need to run simh as root to attach to the network interface?

Thanks,

Flavio

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/b008be99-914b-40ce-81fb-2410129cdfdc%40softjar.se.

[Flavio Villanustre]

And now to answer my own question, it seems that certain capabilities are necessary for raw access to a network device while running as a normal user. I don't see these applied to client11.

It seems that we need this (but I could be wrong):

setcap cap_net_raw,cap_net_admin=eip /opt/pidp11/bin/client11

Best,

Flavio

 

[Adam Thornton]

On Mon, Dec 2, 2024 at 10:58 AM Johnny Billquist <b...@softjar.se> wrote:

Running on physical ethernet is simple and straight forward, but many
people do not have that these days.

Setting up a bridge network interface is a proper solution, but managing
to get that setup and running seems to be tricky, and different for
almost every version of every OS, so I'm not super excited about this
for that reason.

I've tried to make adding bridge devices pretty easy, and as I rebuild mvsevm.fsf.net, as part of checking my own configs into source control so it's less hassle next time I wear out an SD card, I'll put my script to do so in there.  I'll post a link once I have done that.

That said, I bridge to an ethernet device, not wlan, and it hasn't been tested beyond fairly recent Debian.

Adam

[Flavio Villanustre]

Oscar, answering my own question again, you need to add the capabilities to the client11 executable before it can open the network devices for listening when running as non-root:

sudo setcap cap_net_raw,cap_net_admin=eip /opt/pidp11/src/02.3_simh/4.x+realcons/bin-rpi/pdp11_realcons

Flavio

--

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/CAP2nic29JY%3DpnQVs%3DDT9taQS9ih1K7ffNybQVdVHdDN92s9UCA%40mail.gmail.com.

[Flavio Villanustre]

Oscar,

I'm aggregating my findings from my own discovery process, as I got your new beta version network working on a brand new PiOS installation:

1. use nmcli to create a tun/tap interface. Assign an unused IP address outside of your DHCP range but within your network

2. put wlan in promiscuous mode (drop this script in /etc/NetworkManager/dispatcher.d/50-promisc and make make it executable)

#!/usr/bin/bash -e
case "$2" in
    up)
        if [[ "$1" = "wlan0" ]] || [[ "$1" = "Wlan0" ]]; then
            ip link set dev $1 promisc on
        fi
        ;;
esac

3. set proxy_arp and ip_forward in /etc/sysctl.conf

net.ipv4.conf.all.proxy_arp=1
net.ipv4.ip_forward=1

4. run parprouted as root with: parprouted wlan0 tun0 (you could run this also from /etc/NetworkManager/dispatcher.d/)

5. give client11 the necessary capabilities to bind to a raw socket while running as non-root:

sudo setcap cap_net_raw,cap_net_admin=eip /opt/pidp11/src/02.3_simh/4.x+realcons/bin-rpi/pdp11_realcons

6. tell simh to bind to tap:tap0 (the other end of the tunnel) in your boot.ini for 211bsd. This is very important, not tap0 but tap:tap0

attach xu tap:tap0

7. boot 211bsd

Once you do step 7, your tap0 interface will come up indicating that the tunnel is available. 

8. configure 211bsd as usual

This works here with a pristine installation of Raspberry Pi OS from today.

I hope this helps. 

Flavio Villanustre

[Flavio Villanustre]

And to run parprouted from NetworkManager, just change the script in /etc/NetworkManager/dispatcher.d/50-promisc to this:

#!/usr/bin/bash -e
case "$2" in
    up)
        if [[ "$1" = "wlan0" ]] || [[ "$1" = "Wlan0" ]]; then
            ip link set dev $1 promisc on
        fi

        if [[ "$1" = "tap0" ]] || [[ "$1" = "Tap0" ]]; then
           parprouted wlan0 tap0
fi
        ;;
esac

Best,

Flavio Villanustre

[Johnny Billquist]

On 2024-12-02 19:55, Flavio Villanustre wrote:
> Johnny, I agree with you. Ideally, if it was possible to configure a
> standard bridge between 802.11 and 802.3 networks, that would be the
> perfect solution, but that's not technically possible (different
> mediums).

No. There are no actual problem with that. The media is different, but
not in ways that prevent a bridge from working.
And this is something you have if you have a router at home that have
both multiple ethernet ports, and WiFi, and then have one outgoing WLAN
connection. The other ethernet ports are acting like a switch, and the
WiFi is on that same switch, and it's all bridged together. And then the
router routes traffic (possibly also with NAT) when it needs to go to
the outside. But there is no routing going on when communicating between
the different machines on the LAN side.

No different than if you were to have a switch connected to another
switch. Multiple devices appear to be on the same port. The addressing
on the MAC layer is for the correct device, but the radio communication
is done to the actual interface that is talking radio.

For computer WiFi interfaces, they are not always capable of doing this,
though. But that is a limitation on that side, and nothing is
technically preventing you from such a setup.

> ProxyARP (proxying MAC addresses back and forth, mapping them
> to the IP address on the corresponding side and forwarding packets
> without decrementing the IP hop count) as it was done before with
> parprouted is a reasonable option. NAT would work with a combination of
> sNAT and dNAT, but it wouldn't be very straightforward if you want to
> use your BSD as a server, since you would need to remap ports and
> forward those packets as needed (for BSD as a client, simple
> masquerading should work).

I sortof disagree. ProxyARP is really being abused when you try to use
it this way. But if you want that, you can even accomplish the same
thing even without ProxyARP, if you are just able to set multiple
addresses on an interface.

NAT works more straightforward, but you do indeed have to do the setting
up of any ports you want to work for incoming connections.

> Oscar, regarding testing your beta version, it seems that simh running
> under the pi user has issues attaching to the network interface, and I'm
> not sure how to solve that, other than sudoing that process. This is the
> error message (it's the same for tap0):

I don't really fully understand the worries about simh running as root
here...

Johnny

[Flavio Villanustre]

Well, I got it working again with simh as non-root, with parprouted and everything under NetworkManager, so we are back in business now 😀

Follow the recipe that I posted earlier and everything magically works again.

Flavio

[Michael Lyubinin]

Setting up a bridge network interface is a proper solution, but managing
to get that setup and running seems to be tricky, and different for
almost every version of every OS, so I'm not super excited about this
for that reason.

I used a cheap portable wifi bridge ($25 on Amazon - https://www.amazon.com/gp/product/B01199OGK0), and the setup was relatively easy. Raspberry Pi itself is connected over wifi, and simh is using ethernet to the bridge. Works great!

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/b008be99-914b-40ce-81fb-2410129cdfdc%40softjar.se.

[Mike Kostersitz]

Hi Oscar,

I have set up a new SD card with the latest OS, installed all the bits and pieces including Johnny's RSX. When I boot RSX from Johnny's image I am not getting TCP to come up or DECNET.

Any pointers?  

Mike

---

From: pid...@googlegroups.com <pid...@googlegroups.com> on behalf of oscarv <vermeul...@gmail.com>
Sent: Sunday, December 1, 2024 6:44 PM
To: [PiDP-11] <pid...@googlegroups.com>
Subject: [PiDP-11] New PiDP-11 software - for daring beta testers

 

--
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/aef420fe-d88b-40ed-8ed8-314c9dcd8fbcn%40googlegroups.com.

[Ville Laitinen]

I fully agree with 

" PiDP-11 *really* needs to move to a solution where it can use a current
version of simh without a huge effort.

"

Simh version even in the latest update is from 2016, even if the PDP11 part is fairly mature is has had 

a number of significant fixes between that and now.

If realcons/blinkenlights (is it still maintained) was not accepted into simh4 at the time could

it be accepted into open-simh ? 

The simh panel api at first glance is not a drop-in replacement, 

one used in pidp8 might be but once again will require someone to update the simh/panel glue.

I'm sure more than one person would volunteer to maintain the simulator environment if it was located 

in some source control system that is accessible for all - and a way forward was decided.

(obviously now there is at least the beta in github where anyone could make suggestions) 

This was in no way intended to criticize Oscar's work, the OS (unfortunately as it was supposed to be debian known 

for it's it's glacial movement speed regarding any major changes...) updates alone make it very hard release anything and expect 

that to work on every piece of kit there.

perhaps an sd-card image with no update functions would have been the easy way out :)  

... as it is it would be nice if we could have more people nurturing the distro than just the creator alone..

and again, not meant as as criticism... it's just the PiDP11 already has been released into the wild, why not give

it the ability to open its wings properly

-V

br,

-V

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/b008be99-914b-40ce-81fb-2410129cdfdc%40softjar.se.

[oscarv]

Johnny,

On Monday, December 2, 2024 at 6:58:34 PM UTC+1 b...@softjar.se wrote:

To make a comment or two on the whole WiFi issue. There have been a lot
of hacks to work around the problem, but I do not consider things like
using reverse ARP to trick systems a satisfactory solution.

It will work for 2.11BSD at least, and though I understand the best solution is just to connect the Pi to an Enternet cable, there's too many people for whom that is not practical.

That's why the manual assumes in all its chapters that the Pi is connected to Ethernet, with the Wifi 'hack' relegated to the appendices. But it still matters - to get more users to enjoy networked life :-)

 

Running on physical ethernet is simple and straight forward, but many
people do not have that these days.

I'm going to add a chapter on the next-best solution, which is to have the PiDP Ethernetted to a second Pi, which can go out to wifi. But again, that's fine for committed PDP-11 users, but it's still an additional step that too many won't go for.

 

to get that setup and running seems to be tricky, and different for
almost every version of every OS, so I'm not super excited about this
for that reason.

The Raspberry Pi OS changing things around with every incarnation (and every generation of Pi) is a headache for everyone. I understand these changes are part of Modern Life, but it still gives Pi users a headache every time something changes.

Still, that's how it is and I should keep the PiDP-11 up with Raspberry Pi OS changes. I'm happy with the way it now lives with Wayland.

The new (githubbed) version will start with support for the current OS version as its baseline though. If people want to use older OS versions, they can still fall back to the old software package to run on that. Although (I tested) the new github version will work on older OSes, it just will not do all the desktop eye candy.

One other solution would be to actually update simh to something more
current, since there is a perfectly fine, working solution there, that
do not require any of this hacking around. More recent simh have a
built-in NAT capability, meaning any outgoing connections appear as they
are coming from the host system, but are in fact from the simh system.

That capacity is in there with the PiDP-11! The PiDP-11 has that simh version. We're at 4.0-0.

But  NAT proves a headache too. At least for me it is.

[on the built-in NAT from simh:]

You can configure incoming connections on specific ports to then lead
into the simh system (doing that for things like telnet and ftp make
sense), and it all works just fine always.

I've been struggling. Sometimes it works, then you reboot and, no.

 

But the headache of having a hacked version of simh makes this
constantly a difficult proposal. There are other changes and updates to
simh from time to time as well, which also don't show up in the PiDP-11
for this reason. This is basically not a good solution as the things are
currently.

But you need a 'hacked' version of simh... bringing in the front panel code inevitably makes it a hack. Nor is a hack a bad thing. 

 

PiDP-11 *really* needs to move to a solution where it can use a current
version of simh without a huge effort.

All it takes is diff. But my brain is not quite what it used to be - nor do I think we're missing anything substantial (I think you might have missed the move to simh-4.0 with built-in NAT etc).

The wifi networking issues all stem from a desire to force things that were meant for Ethernet on to wifi. And I persevere with it because for practical reasons, it's all most people are prepared to use. 

Simh is not the culprit there. The ARP Proxy hack from Upi Tamminen was perfectly acceptable for 2.11 up to the moment that the Raspberry Pi OS changed to NetworkManager! So the quest is for a new recipe.

BTW - On another note, I do assume you're not impressed with my boot.ini for your latest RSX-11M+ image - if you have time to look at it, tell me your suggestions :-)

Are you OK with having 2024 as the SR switch setting to boot into the new image? I wanted to leave the old RSX-11M+ image in the package because disk space is cheap, and it's probably appreciated by some users who've grown used to it. There are quite a few blog posts with 'how to do this and that' that assume the old image, breaking them would cause needless frustration.

Kind regards,

Oscar.

[oscarv]

Flavio,

That is brilliant!! Thank you!

I will update the github tonight.

Kind regards,

Oscar.

[oscarv]

On Tuesday, December 3, 2024 at 3:25:23 PM UTC+1 vlai...@gmail.com wrote:

Simh version even in the latest update is from 2016

No, it's been updated perhaps two years ago?

PDP-11 simulator V4.0-0

(If you see anything else, it's time to update your PiDP-11 image, it's been the default for a while actually).

If realcons/blinkenlights (is it still maintained) was not accepted into simh4 at the time could

it be accepted into open-simh ? 

They had good reasons not to, it's too specific for BlinkenBone and the PiDP-11 to clutter the simh source code.

 

The simh panel api at first glance is not a drop-in replacement, 

It is not! So I do feel a bit unhappy about people calling Joerg's BlinkenBone version (which is what the PiDP-11 uses, the PiDP-11 is a BlinkenBone component even though many people don't realise it) a hack. 

Everything is a hack, many hacks are Good Things.

one used in pidp8 might be but once again will require someone to update the simh/panel glue.

The PiDP-8 and PiDP-10 are hacks into simh the same way the PiDP-11 is: get the front panel data out of the CPU simulation. Which in the case of the 11 and the 10 is non-trivial if you want to do it right.

The difference between the 8/10 and the 11 is just that the 11 leads out the front panel data to a little server program that then drives the front panel. Whereas in the 8/10, it's just a new thread inside the simulator program.

Joerg had very good reasons to set it up this way. It makes it possible to drive a PiDP-11 front panel, a real front panel with BlinkenBone, or a virtual front panel from the simh simulator; and the front panel can even be on a different machine.

 

I'm sure more than one person would volunteer to maintain the simulator environment if it was located 

in some source control system that is accessible for all - and a way forward was decided.

(obviously now there is at least the beta in github where anyone could make suggestions) 

Well, exactly! 

I'm a bit of a github noob, but I think we should have 

- a main branch that is only updated after an extensive test cycle (multiple Pis, multiple OS versions, it takes a remarkable amount of time)

- an up to date branch open to more rapid contributions.

I'll figure out how that can be set up safely, give me a couple of days. Or tell me (oscar.v...@hotmail.com if you prefer not to over a public group).

 

This was in no way intended to criticize Oscar's work, the OS (unfortunately as it was supposed to be debian known 

for it's it's glacial movement speed regarding any major changes...) updates alone make it very hard release anything and expect 

that to work on every piece of kit there.

Oh but some criticism to me is justified. Up till now, I was extremely "conservative" in updating. That is where github (much as I dislike git) will be a solution.

perhaps an sd-card image with no update functions would have been the easy way out :)  

There's been SD images for a while already, for those that have zero desire to mess with Linux.

 

... as it is it would be nice if we could have more people nurturing the distro than just the creator alone..

and again, not meant as as criticism... it's just the PiDP11 already has been released into the wild, why not give

it the ability to open its wings properly

I agree. And even if not meant as criticism, I think it would be fair criticism. That's why the move to github now matters :-)

Kind regards,

Oscar.

[Flavio Villanustre]

BTW, the standard configuration of the 211BSD+ image using NAT works fine too, if you don't mind connecting to the linux box on port 2323 for telnet and 2121 for FTP (you could also map port 80 to 8080 or something along those lines). That configuration, as Johnny indicated before, does not require a tap device or anything special and it's fully supported by simh.

Also, when you create the tun/tap device, you can specify for it to be owned by the pi user. If you do that, there is no need to set any special capabilities on the client11 executable. The nmcli command to create a tap0 interface as the user pi is:

sudo nmcli connection add type tun ifname tap0 con-name tap0 mode tap owner `id -u` ip4 192.168.1.121

The IP address used for the tap device is not important (it's a /32 after all). It just prevents a pesky error message in the linux logs.

So, whatever floats your boat: either NAT and remap ports or bridge with parprouted. Both configurations work like a charm with the current Pi OS (I am using NAT for 211BSD+ and bridge for 211BSD).

Best,

Flavio

Flavio Villanustre

--
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/3f28d472-3c86-4fa8-a6f4-7b27cab66c75n%40googlegroups.com.

[oscarv]

Flavio,

On Tuesday, December 3, 2024 at 3:56:32 PM UTC+1 fvilla...@gmail.com wrote:

BTW, the standard configuration of the 211BSD+ image using NAT works fine too, if you don't mind connecting to the linux box on port 2323 for telnet and 2121 for FTP

I had major issues getting it to work reliably. And decided it might not be all my fault when Ian mentioned his issues one or two days ago?

 

Also, when you create the tun/tap device, you can specify for it to be owned by the pi user. If you do that, there is no need to set any special capabilities on the client11 executable.

Indeed!

 

So, whatever floats your boat: either NAT and remap ports or bridge with parprouted. Both configurations work like a charm with the current Pi OS (I am using NAT for 211BSD+ and bridge for 211BSD).

I think the NAT remains a commented-out option in boot.ini; and the tun/tap is the preferred option. For 211BSD at least, AFAIK RSX-11 will still only get full functionality with a wired network. That is how it is.

So the boat seems firmly afloat. Which is good news, I happen to live on a boat most of the time :-)

Kind regards,

Oscar.

[Daniel Williams]

Hi Oscar,

A couple of minor things:

/opt/pidp11/install/install.sh line 190 (GUI or Profile choice) checks the wrong variable, and as a result always default to the GUI install, and to that effect lines 198 and 214 need to be updated to show that H/h is a possible option.

What’s the plan to run pdp11controll start when running headless?  I can see when running via the GUI it’s done via ~/.config/autostart/ should we call it from .profile, or update the pdp11 script to ensure it’s started before each run?

It would be nice to include some steps for switching between the old tarball and the new GitHub based setup.  Whilst ideally it’d be nice to always start from a fresh install, I’m too lazy to get a screwdriver to get into pull the SD card.  I seem to remember the steps being:

sudo /etc/init.d/pidp11 stop

update-rc.d pidp11

unlink /etc/init.d/pidp11

unlink /home/pi/pdp.sh

sed -e “:/home/pi/pdp.sh:d” -i /home/pi/.profile

mv /opt/pidp11 /opt/pidp11.old

<follow new install instructions>

Dan

[Jon Crowell]

The historybuffer.c changes to avoid a race condition need to be pulled into the pool. 

PiDP-11, Locked up LEDS and switches after 35+ days, 2 systems

files included in this conversation.