risc os on Brian Benchoff’s “minimum viable computer'”

Could risc work as a usable gui for Brian Benchoff’s “minimum viable computer’” as a linux alternative if for nothing else but to say it has a GUI?

Hi David,
welcome to the forum.

This question was asked already on the stardot channel on discord.

IIRC, Brian Benchoff MVC is based on the ARM926EJ-S, which should be a faster version of the CPU used in a quite famous post-Acorn RISC OS computer, the A9Home:

https://en.wikipedia.org/wiki/A9home

I think (maybe) Sarah Walker has done some work on this regard already, but I may be wrong.

Anyway, here is a link with info on how to build RISC OS 5 for the A9Home which should be a good starting point for your endeavor:

https://www.riscosopen.org/wiki/documentation/show/Notes%20for%20building%20RISC%20OS%20on%20the%20A9Home

For the GUI, RISC OS is not using any hardware acceleration, and it should be using just a framebuffer for the Desktop GUI, so I am pretty sure that it should be possible to get it to have the Desktop running on the MVC.

The amount of memory on the MVC is also totally fine for RISC OS, no problem at all with 32 or 64MB of RAM.

The only issue I see at the end of the porting process is that RISC OS GUI rely a lot of the use of a mouse at the moment (I am working to make this change and I think others are too, so shouldn’t be a show stop problem in the end)

Hope this helps

NB the guide linked above is for building the ROM on the A9home, not /for/ the A9home. I don’t think there’s a version of RO5 that works on the A9home. I had that machine for a number of years, and it was a pleasure to use. Fast for its vintage.

NB the guide linked above is for building the ROM on the A9home, not /for/ the A9home.

Whoops, I stand corrected, thanks WPB.

AFAIR, RISC OS 5 should have support for the ARM9 already. So, it should be just a matter of the extra bits added to the MVC boards, which I think are very little, so most likely just the screen/resolution and, possibly, the USB (if on a separate chip). I am not sure if it has anything else on board at all.

[update]
did some search and found the board page/details: https://bbenchoff.github.io/pages/LinuxDevice.html
[/update]

I’m not sure what the point would be of compiling RISC OS 5 on possibly the slowest computer anyone still has access to, if it doesn’t run on it???

I’m not sure what the point would be of compiling RISC OS 5 on possibly the slowest computer anyone still has access to, if it doesn’t run on it???

It only took about 50 minutes, and the Pi ROM built on the A9home is running on the RPi4.

By way of a bonus I now have the A9home displaying 1920×1200, previously the best offer was 1680×1050.

defmod is flagged as an issue in the notes but all I did was to expand DefMod.!Run

I’m not sure what the point would be

As I’ve said enough times in my life…

Why? There is no why. Only because.

It only took about 50 minutes, and the Pi ROM built on the A9home is running on the RPi4.

And how long does it take to compile on the Pi 4?

By way of a bonus I now have the A9home displaying 1920?1200, previously the best offer was 1680?1050.

So it works on the A9home?

So it works on the A9home?

Exactly (thanks David), can we please be clear?

Does RISC OS 5 works on the A9Home yes or not?

Does RISC OS 5 works on the A9Home yes or not?

Not.

Thanks David Pitt!

That Allwinner chip is actually quite a nice platform – it’s basically a single chip ARM system for a sub-$5 parts cost (+enclosure and stuff). Everything including the RAM is included. The board just has some power supply chips and that’s it. It’s also in a friendly package for hobbyists to solder, and can be built with cheap PCBs. It’s a bit like the microcontrollers used on Arduino boards, but able to run a full OS.

So the question is: if you had a single chip $5 RISC OS system, what could you do with it? That is roughly the cost of a Pi Zero, but in a way that would more easily be able to integrated into existing systems (as part of the board design/etc). Perhaps you wouldn’t be concerned so much about the desktop / mouse / etc UI, but more as an embedded platform. Would there be applications where RISC OS would shine?

The whole point of an Arduino / Pico board is you don’t have any OS, you either compile a bit of C code together with a bare metal runtime library, or you have a micro Python environment. The only thing running RISC OS would get you is BBC BASIC for those that have never moved on to other languages.

35 years ago we were putting little 2 inch 6502 controller boards in to eddy current test equipment, they were effectively mini-BBC Micros with BBC BASIC, which was the only viable high level language at the time (contemporary PCs were still on versions of Pascal), and you had the whole BBC Micro ecosystem to back you up. These days Python would be language of choice, as there is a library for literally everything, where as BBC BASIC is still the authentic bare bones experience it was in 1987.

Would there be applications where RISC OS would shine?

As a bootloader for another OS? ;-)
Since you asked, Theo, you must have had some thoughts about possible applications.

@ Druck

The only thing running RISC OS would get you is BBC BASIC for those that have never moved on to other languages.

IIRC there is an actual implementation (or an ongoing project) to have a BBC BASIC for microcontroller (without OS).

Would there be applications where RISC OS would shine?

I echo David.

So, to use RISC OS effectively on one of those boards (beside that it requires an MMU), it would need:

1) A runtime that doesn’t spins up the CPU has it happens now outside of the Desktop (this can be fixed, but it’s not fixed yet and it has been so for like 25 years now)
2) Use of multicore, because this is where normally you want to have an OS in place instead of go bare-metal/embedded (basically when you need multi-core support, multi-tasking etc…) – so yeah RISC OS is in a pretty bad shape right now.
3) Possibly have the uCLib project completed, for all those situations where you may need to run external commands without quitting your main program (uCLib allows the build of transient code using C). But worst case one could use modules for everything outside of the main program.
4) Libs, libs and more libs… dev tend to chose a system because of the available libraries and framework, to work less and have to test less code (some may argue that is not a correct approach, we have seen it with log4j etc… but indeed is how quite a lot of people think)

For the possible applications, they would be apps that requires more than just a traditional microcontroller and embedded C or micropython and less than a full blown up rich OS.

That, IMHO, shrinks the choice to the usual suspects:

Stand-Alone: MP3 players, tamagotchi-like kids games, MIDI Players, timer-watches, retrogaming handled devices, emulation

Networked (ethernet): nothing because a) RISC OS needs a better stack, b) ROD made it and c) ROOL went berserk, so we’ll need to wait even more before a modern stack get added.

However, if someone opt to use ROD stack then: RISC OS could be used for networked controllers (press button send network message to something), info displays (monitors that share train time etc.), Totem/Info Points (using Iris if ROD understands they need to add a full screen mode for Iris)

WiFi/Bluetooth: well here it’s where it gets truly ridiculous, but oh well. The answer here is “nothing for another 10 years” (sorry for the sarcasm)

Where could it excel? Nowhere, everything has already been done, BUT given that people are using, in some cases, FreeDOS for this type of apps… I mean, why not to use RISC OS? (it’s not that these days there are so many MS-DOS developers around, so convenience is not the issue).

Stand-Alone: MP3 players,

Potentially not.

I tried this with my OLED screen. Sending around 11K at the faster 400kHz IIC rate ¹ still disabled interrupts around the IIC transfer ² which took longer than the capacity of the sound buffer. Result? Choppy glitchy music and frequently it just gave up and stopped playing.

because a) RISC OS needs a better stack, b) ROD made it and c) ROOL went berserk, so we’ll need to wait even more before a modern stack get added.

Hmm. FUD? Honestly I have no idea WTF is going on with the stacks. All I know is that I’m running a recentish version of RISC OS and the new (ROD) stack. If I have to softload the thing at start, so be it. There are ways.

The answer here is “nothing for another 10 years” (sorry for the sarcasm)

Probably best not to lump them together. As I understand it, part of the consideration of the new stack is a way to introduce WiFi support.
Think, also, that WiFi is quite alien to the way RISC OS works. Connections can come and go. You might get a different IP address each time. There may be authentication on this AP, but not that one. Or different authentication on different APs. Plus there’s that mechanism that exists on public APs where before you can use the WiFi you need to go to a (local) web page to say that you agree to a bunch of legal waffle.

The current RISC OS stack is heavily predicated on the idea that “there’s a network, you have an IP address, the end”. Hell, part of the reason I have my Pi on static IP is because it boots up like twenty times faster than the router, and RISC OS can’t really cope with sorting out its IP address minutes later.

So bringing WiFi means a lot of groundwork is necessary.

But I’ll hand you Bluetooth. That may well be another decade… ;)

¹ Note, for some reason the RISC OS default at the time (maybe still?) was 100kHz, four times slower. Anything old enough to fail at 400kHz will be too old to support 3.3V operation…

² Which is a bit of a nonsense when it’s hardware IIC rather than bit banging two pins of the IOC like in the Archie days.

I tried this with my OLED screen. Sending around 11K at the faster 400kHz IIC rate 1 still disabled interrupts around the IIC transfer 2 which took longer than the capacity of the sound buffer. Result? Choppy glitchy music and frequently it just gave up and stopped playing.

I haven’t looked at the details yet, got my hands full already at the moment and still have a day job to do too ahah :D – But I think a device like the ARM926EJ-S should be able to do it with RISC OS. I’ll probably have a look in the future if I manage to have some time for this.

BTW, thanks for sharing the details :)

Hmm. FUD? Honestly I have no idea WTF is going on with the stacks. All I know is that I’m running a recentish version of RISC OS and the new (ROD) stack. If I have to softload the thing at start, so be it. There are ways.

Sorry Rick, I wasn’t judging the “reasons why ROOL and ROD”, I was just mentioning the effect of it on someone who may want to use RISC OS (for what Theo as mentioned) at the moment.

For the “embedded device” market, softloading a network stack isn’t optimal unfortunately (although if it may not be a show-stop either I think), but I understand it completely from the point of view of your Desktop/Personal use, I’ll probably end up doing exactly the same.

Probably best not to lump them together.

Indeed, I was just trying to shorten my reply.

Yes, both the ROOL and ROD, efforts are meant to be able to add WiFi support, but the WiFi support is not yet underway, so my point was that between all that needs to be done, to have WiFi support on RISC OS it will take time, so, if someone today would like to make an app that requires it they simply can’t.

For example, at the moment FreeDOS has WiFi support although if it’s limited to 802.11b and just silly WEP. – While writing this I just realized the irony: we had the same WiFi support back at the time of RO 4 (STD WiFi expansion) using a “big driver” that did the whole WiFi + WEP and then passed packets to the RISC OS stack. -

Embedded Linux, Windows for IoT, QNX, Integrity, VxWorks, eCos (on the Pro version), WebOS, obviously, have full WiFi support and WPA2 etc. So, the point was for apps that need WiFi and a semi-rich OS, right now, RISC OS is not viable.

So bringing WiFi means a lot of groundwork is necessary.

Yup, this was exactly my point :)

But I’ll hand you Bluetooth. That may well be another decade… ;)

hehe, oh well :)

(although if it may not be a show-stop either I think)

Unless you’re going a ROM or Flash route, RISC OS pretty much needs some sort of filesystem, to boot from, to load its application from… why not drop the stack in there as well?

It’s not unheard of for a device to hide an SD card inside to boot from. Here is a look inside my old ebook reader – https://youtu.be/qTyihhyXH88

For example, at the moment FreeDOS has WiFi support although if it’s limited to 802.11b and just silly WEP.

In my setup, that pretty much translates as “FreeDOS does not have WiFi support”. If anybody still seriously uses WEP, they might like to look at what something called AirCrack can do (if the name isn’t a clue). WEP? Like writing your password on a piece of paper and putting it inside a transparent envelope.

that did the whole WiFi + WEP and then passed packets to the RISC OS stack.

I think that’s how people use the Vonets gizmos. They, at least, support WPA2.

So, the point was for apps that need WiFi and a semi-rich OS, right now, RISC OS is not viable.

I’m not sure RISC OS ever will be. What makes a lot of these things stand out is a massive pile of frameworks. While layer upon layer may suck and be riddled with problems, when it comes to doing things like “this is a video advertisement”, one can pretty much say the video content goes here and is this size on the screen, with this background around it, here’s the URL (or filename), make it so. It’s also possible to support hardware buttons to do different things (different video? info kiosk?).
I wrote my game from scratch, basically moving sprites around and sorting out what happens when. Elsewhere? Various game engines. Defold, for instance, or Adventure Game Studio (note: I’ve used neither…).

So even with WiFi, the next hurdle is a tonne of libraries to make things work the way people from afar would expect. Shall we say, maybe in 10 years? ;)

What makes a lot of these things stand out is a massive pile of frameworks.

I am glad to see you agree then with my original point:

“4) Libs, libs and more libs… dev tend to chose a system because of the available libraries and framework, to work less and have to test less code (some may argue that is not a correct approach, we have seen it with log4j etc… but indeed is how quite a lot of people think)”

Shall we say, maybe in 10 years? ;)

lol and what did I say???? XD