A lot of the problems encountered here seem to be due to bit rot, unavailable archives and these were, from my experience, not too uncommon for relatively rare Linux platforms like the RISC PC even more than 20 years ago.
RISC PC systems are still a supported (tier 2) platform in NetBSD. You should be able to cross-compile the whole system including X11 from any Linux or NetBSD host (I did this last week for the next68k port) and the developers would certainly be happy
about feedback before the 11.0 release is published. So this might be worth giving a try.
Not everything is working in NetBSD all the time. When testing the “previous” NeXT emulator, we faced some nasty regressions last year that prevented NetBSD 10 (and, as we found out, every release after 5.2.3!) to run on next68k, but things were fixed eventually thanks to the nice and friendly next 68k platform maintainer!
I just tested the build. It seems that the NetBSD build tries to compile for armv4 (which, as on Linux, means StrongARM only).
When trying to specify -a earm (which should imply ARM v3) instead of the default -a earmv4 to build.sh (./build.sh list-arch gives the supported architectures), the script complains that "MACHINE_ARCH 'earm' does not support MACHINE 'acorn32'".
So it seems there's more work to be done for the armv3 machines, sorry...
Update: Early Acorn machines with ARM2 and ARM3 processors were supported by NetBSD/acorn26 (see https://www.netbsd.org/ports/acorn32/faq.html). This is a bit strange, since IIRC ARMv3 got rid of the 26 bit PC mode.
Unfortunately, support for this port ended back in 2018 with NetBSD 8.0 and the acorn26 supported platform list doesn't include the ARM710 RiscPC, so it might also be significantly more difficult to get NetBSD to work on your machine...
I've recently been doing something similar: I have a UbiSurfer 9, a netbook using an S3C2416 chip as its CPU, running the ARMv5 instruction set, and with 128MB of DDR2 memory. Its original operating system is WinCE 6.0, and I'm trying to run Linux on it. The good news is that Debian still maintains the armel architecture, so we potentially have a large number of userspace programs available. The bad news is there's no suitable kernel and bootloader. Fortunately, a friend helped me write a bootloader and modified the kernel source code to make it work. Running a Debian system is possible, but quite slow, so I created a minimal system with only Busybox[1], and it works perfectly.
Risc PCs were obscure machines, even then and compared to the original Archimedes (which itself was an oddity), so lacking support isn't surprising. A 710 model not upgraded to a StrongArm would have come from well outside the enthusiast sphere which is where all the dev work was happening. (So probably a school model from a time when schools were heavily moving to PCs).
Back in 1995/6 or so it seemed like half the Acorn employees at Acorn World had their Risc PCs running NetBSD. By 1995 if you were doing software dev on Risc OS your environment and tools were absolutely terrible compared to what existed on Mac/PC/Unix, which was a factor that contributed to people interested in programming abandoning Acorn hardware entirely.
Back in the day I worked for the makers of Yellow Dog Linux, and I think because of these scarcities we had a pretty good model of buying Apple Risc hardware at OEM prices and putting Linux on them, mostly for university scientists but also for enthusiasts. There was a lot of work keeping Linux running on hardware created by a company that was ambivalent about having alternative operating systems on its hardware, but it was fun and a great group of people to work for.
The big thing most people from outside the Acorn era of Arm are missing here is the Risc PC never had decent floating point support. For pure integer stuff the StrongArm upgrade was, at lauch, simply astounding, but floats . . . nope. (The StrongArm upgrade merely needed to be in the slot near the vents too, it had no active cooling or even a serious heatsink).
Oddly the later lower end A7000 came in a A7000+ variant which did have an FPU, probably because Arm needed to test their FPU out somewhere.
The main reason was to run Windows (3.1) inside a window on Risc OS in parallel. You could copy/paste between them too iirc. Use of floating point code from Risc OS was so non-uniform (i.e. the culture was rolling your own fixed point code) that any attempt to speed that up via offloading to another type of CPU would have only worked for a specific configuration of everything. The x86 cards available weren't exactly speed demons either.
At one time there was a lot more community excitement about shoving many Arms on a single board, or a DSP, but the StrongArm upgrade was already fast enough to oversaturate the bus making such a thing pointless.
Around this time Win95 overtook Risc OS in terms of realistic UX/cost as well.
With hindsight the Risc PC existed so there was an upgrade path for people from the Archimedes for particular software before ports of that to PCs were completed. e.g. Sibelius. Acorn knew they didn't have a chance.
RISC PC systems are still a supported (tier 2) platform in NetBSD. You should be able to cross-compile the whole system including X11 from any Linux or NetBSD host (I did this last week for the next68k port) and the developers would certainly be happy about feedback before the 11.0 release is published. So this might be worth giving a try.
https://wiki.netbsd.org/ports/acorn32/
https://www.netbsd.org/docs/guide/en/chap-build.html
Not everything is working in NetBSD all the time. When testing the “previous” NeXT emulator, we faced some nasty regressions last year that prevented NetBSD 10 (and, as we found out, every release after 5.2.3!) to run on next68k, but things were fixed eventually thanks to the nice and friendly next 68k platform maintainer!
reply