PiDP-8/I Software

Changes To OS Compatibility
Log In
Next Previous

Changes to "OS Compatibility" between 2021-02-08 18:56:28 and 2021-04-01 16:50:15

1
2
3



4
5
6
7
8
9
10
11


12

13
14

15
16

17
18

19
20

21
22

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

57
58
59
60
61
62
63
64
65
66
67
68
69
70

71
72
73
74
75
76

77
78
79
80
81
82
83

1
2

3
4
5
6
7
8
9
10
11
12
13
14
15

16
17

18
19

20
21

22
23

24
25

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

60
61
62
63
64
65
66
67
68
69
70
71
72
73

74
75
76
77
78
79

80
81
82
83
84
85
86
87



-
+
+
+








+
+
-
+

-
+

-
+

-
+

-
+

-
+

















-
+















-
+













-
+





-
+








# The Situation

Although the core software underlying the PiDP-8/I software distribution is broadly portable, the dominance of Raspberry Pi OS on Pi hardware means it gets the most attention when it comes to testing and development. This article documents what it known to work, where, today.
Although the core software underlying the PiDP-8/I software distribution is broadly portable, the dominance of Raspberry Pi OS on Pi hardware means we focus on making it work there first when it comes to final testing. However, we actually *develop* the software on regular desktop platforms, so it does remain fairly portable, if not quite as much as the union of the individual components in the distribution.

The remainder of this article lists the platforms where the software is known to work and the limitations that prevent it from working on others.

If you need the software to work on some platform where it currently doesn't, [we accept patches!][patch] You can also send problem reports [to our development forum](/forum), file a [bug report](/bugs), or [discuss it on the users' mailing list][ml].

[patch]: /doc/trunk/HACKERS.md


# Debian & Derivatives: Raspberry Pi OS, Ubuntu...

[Raspberry Pi OS](https://www.raspberrypi.org/downloads/raspberry-pi-os/) is the official OS for the Raspberry Pi, so that is our primary deployment target. However, because it doesn't deviate much from the underlying Debian OS it's based on, the software should work on Debian, Ubuntu, and other sufficiently close derivatives.

All instructions given for the PiDP-8/I software assume that you're running a Debian derivative where not otherwise stated. This is because the software is primarily designed to run on [Raspberry Pi OS](https://www.raspberrypi.org/downloads/raspberry-pi-os/), the official OS for the Raspberry Pi.
All instructions given for the PiDP-8/I software assume that you're running a Debian derivative where not otherwise stated.

The trunk version of this software successfully runs on the stable release of Raspberry Pi OS, currently v10 — a.k.a. Buster — released in early July 2019.
The current stable release of this software successfully runs on the stable release of Raspberry Pi OS as of the time of its release, v10 — a.k.a. Buster — released in early July 2019.

We have not yet made a stable release of the PiDP-8/I software atop that version. Raspberry Pi OS v9 (Stretch) was current when the stable binary OS images were built.
The prior stable release of the software (v2019.04.25) targeted the prior OS release, Raspbian v9, a.k.a. Stretch. We believe the current stable software still runs atop Stretch, but it's been a while since we tested it, since the active developers' PiDP-8/I test boxes have all been upgraded to Buster.

Prior releases were built atop the [Raspbian Jessie Lite](https://www.raspberrypi.org/blog/raspbian-jessie-is-here/) (v8) distribution, but somewhere along the line, we broke compatibility with Jessie. If you need to keep running on Jessie, which is now out of support, we recommend that you run version 2017.04.04 of the PiDP-8/I software, the last version specifically tested atop Jessie.
The stable release prior to *that* (v2017.04.04) targeted [Raspbian v8](https://www.raspberrypi.org/blog/raspbian-jessie-is-here/), a.k.a. Jessie. Somewhere along the line between this release and the one for Stretch, we broke compatibility with Jessie, so if you need to keep running on Jessie, which is now out of support, we recommend that you run version 2017.04.04 of the PiDP-8/I software, the last version specifically tested atop Jessie.

Related OSes like [pipaOS](http://pipaos.mitako.eu/) should also work, but the project's current developers don't test this.
The software should work atop related OSes like [pipaOS](http://pipaos.mitako.eu/), but the project's active developers don't test this.

The project's primary maintainer occasionally builds the software on x86 Debian derivatives, which works fine, since Raspberry Pi OS is a Debian derivative. On such systems, the software detects the absence of the PiDP-8/I front panel hardware and works without it.
The project's primary maintainer occasionally builds and runs the software successfully on x86 Debian derivatives. On such systems, the software detects the absence of the PiDP-8/I front panel hardware and works without it.



# Devuan

There is one major exception to the rule that the software works on Debian derivatives. After Debian (and thus Raspbian) moved to `systemd` many years ago, we transitioned to it as well. Thus, the current software does not run out of the box on [Devuan](https://devuan.org/), a Debian derivative that purposefully removes systemd. You can recover the old SysVInit script from the software repo with:

    $ fossil revert -r 27f585bd1b etc/pidp8i-init.in

You will then have to make the following manual substitutions in the file:

| @VARIABLE@    | Standard replacement     |
|---------------|--------------------------|
| `@ABSPREFIX@` | `/opt/pidp8i`            |
| `@BOOTDIR@`   | `/opt/pidp8i/share/boot` |
| `@INSTUSR@`   | Either `pi` or `pidp8i`  |

Copy the resulting file to `/etc/init.d/pidp8i`, then commands like `sudo service pidp8i start` should work.
After copying the resulting file to `/etc/init.d/pidp8i`, commands like `sudo service pidp8i start` should work.



# Non-Debian Linuxes

There are non-Debian type Linux based OSes for the Raspberry Pi such as [openSuSE for the Pi 3](https://en.opensuse.org/HCL:Raspberry_Pi3) and [CentOS for the Pi 3](https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32/RaspberryPi3). Since the primary developers on this project haven't tried any of these Pi Linux distros, and no one has reported on their attempts to make it work, we can only speculate on the workarounds required, if any.

Off the Pi, pretty much every Linux distribution should be able to build and run our software, once you've installed all of its prerequisites. We've built and run it successfully a few times on 64-bit Intel boxes under CentOS, for example.



# macOS

This project's current primary maintainers use macOS at home, so the PiDP-8/I software is frequently built and tested on macOS while we are working on features that do not require the PiDP-8/I front panel hardware.

Why? Because it builds many times faster than on a Pi, depending on what has to be built!
Why? Because it builds many times faster than on a Pi!

Stock macOS doesn't have everything you need to make it work. We recommend installing [Homebrew](https://brew.sh/), then using that to install the third-party dependencies that the PiDP-8/I software needs.



# FreeBSD

Because of our regular testing on macOS, the software works well on x86 FreeBSD.

On FreeBSD 12, you need the following prereqs:

    $ sudo pkg install coreutils gmake perl5 python py37-pip

Note that this gets you Python 3, which currently only works with the trunk release of the software. The current stable release only works with Python 2, which was the default version on FreeBSD 11 and older.
Note that we preferentially target Python 3 now, which means if you're still using FreeBSD 11 or older, which included Python 2 instead, things may or may not work. We *think* we're still compatible with Python 2, but we haven't tested it recently.

The configuration process will fail if you do not give the `--prefix` option because `/opt` isn't present on FreeBSD by default. Rather than create that subtree, a more "native" FreeBSD configuration would be:

    $ ./configure --prefix=/usr/local/pidp8i

There is a [FreeBSD build for the Pi][fbpi], but we believe it [will not work with the front-panel hardware](/tktview?name=856225858e). You are more than welcome to fix this and [send us a patch].
There is a [FreeBSD build for the Pi][fbpi], but we believe it [will not work with the front-panel hardware](/tktview?name=856225858e). You are more than welcome to fix this and [send us a patch](/doc/trunk/CONTRIBUTING.md#patches).

[fbpi]: https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi



# Windows
︙
95
96
97
98
99
100
101
102
103
104
105
106
107

108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

124
125

126
127

99
100
101
102
103
104
105


106
107
108

109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124

125
126

127
128
129








-
-



-
+















-
+

-
+




## Cygwin

This works, and appears to work *well* besides in the multiple times we've tried it. The most recent test was on 2019.05.11 with 64-bit Cygwin 3.0.7 on Windows 10.

You will have to install the `libncurses-devel` and `python2-pip` packages as well as standard Unix build tools: GCC, GNU Make, etc. Having done all that, the software will build and run.

For `bin/pidp8i` to run properly, you need to run the trunk version of our software: the systemd improvements made to it for the most recent stable release don't work under Cygwin, but we've fixed that on trunk.


## Windows Subsystem for Linux

Terminal emulation and [pty](https://en.wikipedia.org/wiki/Pseudoterminal) handling have been a longstanding problem with WSL, and there were still bugs in it the last time I tried it, on 2019.05.11 with 64-bit Windows 10 Pro 1803 running Ubuntu 18.04.02 LTS. It's much better than the tests we conducted back in 2017, however.
Terminal emulation and [pty](https://en.wikipedia.org/wiki/Pseudoterminal) handling have been a longstanding problem with WSL 1, and there were still bugs in it the last time I tried it, on 2019.05.11 with 64-bit Windows 10 Pro 1803 running Ubuntu 18.04.02 LTS. It's much better than the tests we conducted back in 2017, however.

These problems mainly show up when running the simulator under GNU screen, as our `bin/pidp8i` wrapper does. In my latest attempt, the following would result in a "dead" screen session:

    $ pidp8i start      ← start simulator under GNU screen
    $ pidp8i            ← attach to screen session
    Ctrl-A, d           ← detach; leave it running
    $ pidp8i            ← reattach; reports it "dead"
    
You can avoid these problems by running the simulator directly:

     $ make run
     $ bin/pdp8 boot/0.script

...and so forth.

It is possible that the improvements announced at [Build 2019](https://news.microsoft.com/build2019/) to [WSL 2](https://devblogs.microsoft.com/commandline/announcing-wsl-2/) and [the Windows console](https://github.com/microsoft/Terminal) will solve these remaining pty and terminal emulation problems. Until they're addressed, the above choices are better options.
[WSL 2](https://devblogs.microsoft.com/commandline/announcing-wsl-2/) and the new [Windows Terminal](https://github.com/microsoft/Terminal) should solve these remaining pty and terminal emulation problems, but we haven't actually tested that yet.

As with Cygwin, there are portability fixes on trunk now that are not yet released.
We still mention the WSL 1 problems because there are cases where you can't use WSL 2, such as when running Windows in a VM that doesn't allow double-virtualization of the CPU. (e.g. Windows under Parallels on an Apple silicon ARM Mac.) WSL 2 is basically a specialized Hyper-V instance, where WSL 1 is an in-kernel Windows subsystem, so WSL 1 works on such systems where WSL 2 cannot.

[ml]: (https://groups.google.com/forum/#!forum/pidp-8)