I've inherited a PiDP8i that I'm trying to get up and running for a museum I volunteer at.

Pi4B 2Gb Ram. I've Clean installed latest 32bit OS, downloaded PiDP8 source and rebuilt ok (no errors).

If I run Pidp8i-test /all - to test the LEDs DMB1-DMB12 don't light up at all. Is it time for surgery to test LEDs etc ?

Is there any obvious snafu I could check first ?

Pi4B 2Gb Ram.

If you haven't got some kind of GPIO hack patched in, it won't work right because they changed the GPIO peripheral incompatibly in Pi 4, then again in Pi 5.

The ugly workaround is this commit. There is no working pretty version because the only one who tried to present such a thing is me, here, which failed because I did not then — and do not now — have a Pi 4 to test it with.

I have no interest in rebuilding my Pi 3 based unit around an overpriced and overspecced Pi 4 merely to work all this out for others' benefit. Someone with the itch needs to step up and take this task on, not rely on me to set up 4+ different PiDP-8/Is just to test all the major combinations and keep them working.¹

Oscar Vermeulen has privately sent me some changes that are supposed to handle the Pi 4 and 5, but it sits disregarded in my email inbox for the same reasons as above. The best I could do is blindly commit it all and hope someone would test it for me.

Perhaps you are willing to get with him and do the integration work and testing? I'm willing to grant you commit rights on this repo if so.

Beware: I won't merge hackery to trunk, and I'll back it out if someone else commits it. What I want is a single GPIO abstraction that works on all Pi generations, ideally via runtime tests so I don't have to ship additional binary OS images, but if by compile-time tests, then so be it. My ideal is a library I can link to that lets me set/get GPIO pin states in a generic manner. Oscar's submission uses something called "pinctrl", but I know nothing about it.

If I run Pidp8i-test /all

The pidp8i-test program ignores its arguments. There is no "/all" flag.

---

1. ^{^} Pi 2B for non-ILS, my current Pi 3 based one, a Pi 4 based one, and now an even more overpriced and overspecced Pi 5 one. Sheesh!

It behaves exactly the same with a Pi2 in place using the pre-compiled binaries. I'm going to check the LED polarity first for that now as that's a straightforward check.

(Only reason for replacing Pi2 is to get WiFi/SSH access, without adding a necklace of dongles etc. I did try but the one bought wouldn't play, it wanted to be a new WiFi hub, rather than allow access to existing hubs)

I'd agree with your dissatisfaction the state of Pi4 things (ignoring Pi5 for now), with the non-availabilty of new Pi2/3 models there definitely needs to be a Pi4 HowTo, or alternatively maybe limit future support to PiZero(w) only.

Sadly as a newb (to both SIMH & PDP8, plus I'm not particularly adept at building branches) I'm not your new Pi4 champion.

There are some new (cheap) Pi3 wrapper cards for the PiZero (I have a spare PiZeroW and may investigate, and I'll report back if I do).

I'd happily be a guinea pig for the Oscar Pi4 changes if you want one, but I'd be limited to a Yes it worked/No it doesn't response because of my Newbness.

Don't think I made it clear enough, that the Pi2 was running the pre-compiled binaries from tangentsoft. Apologies for the confusion.

Pretty sure it's a hardware fault of some kind, that's what I am after any advice about.

(And thanks for the Fossil tip)

Eureka ! Got an electronics whizz to take a look, and he discovered that the link between LED3 & XLED3 was broken requiring a bit of tinned wire to replace the broken etched link.

Working fine now on Pi2 ....