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...
Thanks, it seems I was confused by ARM3 (the implementation) and ARMv3 (the architecture, but not the one of the ARM3 implementation) once more. Yikes... this is quite a chaos.
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.
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.
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!
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 have a StrongARM RISC PC; where do I start? (https://wiki.netbsd.org/ports/acorn32/) and https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/acorn32/INSTAL...
formidable!
The NetBSD/acorn26 port only supported ARMv2 and ARMv2a [1].
The earm architecture doesn't imply ARMv3, support for that has been removed from gcc which from memory was why the acorn26 port was deleted.
[1] https://wiki.netbsd.org/ports/acorn26/
Thanks, it seems I was confused by ARM3 (the implementation) and ARMv3 (the architecture, but not the one of the ARM3 implementation) once more. Yikes... this is quite a chaos.
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.
[1]: https://github.com/chirsz-ever/busybox-linux
I'm still exploring this; related information is in this repository, written in Chinese:
https://github.com/chirsz-ever/ubisurfer9
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.
I recall Yellow Dog, probably because of the PS3.
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.
Wasn't that one of the main reasons to get the 486 coprocessor?
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.
Run RISC OS and contribute!
https://www.riscosopen.org/content/
I think the saddest part is that it can’t run Acorn’s Unix. It had IXI’s desktop tools, which were really nice back then when time itself was new.
> So maybe I can dual boot and get myself something like a Raspberry Pi Zero, but with one sixth of the RAM, and one twentieth the clock speed
:)
> RiscPC... it's an ARM desktop
Putting this info in the title would have prevented a lot of misinterpretation...