How many modules does a minimal RISC OS 3.11 desktop need?

[Sophira]

(Answer: Between 7 and 15 (or 17), depending on what you consider "working". Curious? Read on.)

So after the "A3000 repair advice" thread elsewhere on the forums where the CMOS needed to be replaced, I got curious about how many modules were required in order to get the RISC OS 3.11 Desktop minimally working on a machine where every module had been *Unplug'ged, not counting the modules that RISC OS automatically reinitialises on every bootup.

Before I start, though, an obligatory notice: This is just for entertainment purposes. Don't actually use this for getting your machine up and running! If you're in a situation where you need to use this, just do a DEL-power on to reset the CMOS - this will auto-insert all the ROM modules and configure all settings to sensible values.

With that said...

These first seven modules are needed to get the Desktop loading up without any error messages, in order of usage during the desktop load sequence:

• Desktop - obviously.
• WindowManager - the Desktop won't even go into a graphics mode without this module, perhaps unsurprisingly.
• ColourTrans - this one surprised me, because on RISC OS 2 the module was on a separate disc, so I assumed the RO3 Desktop would continue to not need it for startup.
• FontManager - without this the Desktop will try to display an error message, but the error box doesn't contain any message.
• Filer - the Desktop uses the *Filer_Boot command for something, so this module is necessary.
• FPEmulator - this was surprising for the same reason as ColourTrans! I'm not entirely certain what floating-point operations the Desktop would be using, but it apparently does because it fails with either "undefined instruction" (the first time) or "Use *Desktop to start Filer" (on subsequent attempts without rebooting) without this. (If your machine has an FPA10, you don't need this module.) [edit: Turns out this is only true on Arculator - on real hardware, you require FPEmulator!]
• Obey - the Desktop wants to *Obey something, so this module is needed.

At this point, we get to a point where there are no more error messages, so if that was your definition of "working", congrats! Trouble is, we also don't have a mouse pointer and can't actually do anything. We need to *RMReInit our 8th module (I hope you're not auto-booting into the Desktop so that you can do this!):

• SpriteExtend - With this in place, we finally have a mouse pointer!

At this point, if you have any extension ROMs that put icons on the icon bar (for example, Arculator's HostFS extension ROM), then the icons will display on the icon bar and are minimally usable, but will probably not work correctly. (You can click MENU on HostFS, for example, but trying to click its "Free" option or click the icon itself will fail to do anything.) Otherwise, the icon bar won't display at all. Either way, we're kind of stuck here.

Let's get ourselves a method of being able to run *Commands without rebooting. To do that we need to load two or three more modules, so that Task Manager will load:

• TaskManager - the module that provides the Acorn icon on the far right of the icon bar.
• ROMFonts - without this module, TaskManager won't load correctly. You'll also notice after loading this module that the Desktop starts attempting to display its splash screen, but fails.
• ShellCLI (optional) - So technically you can do it with just two modules (with the first two, you can use the Exit command to run more *Commands) but this one will allow us to use the familiar F12 key to get a command-line prompt.

We now have Task Manager loaded and working, and we can use the Exit command or the F12 key to run more *Commands. It's finally safe to auto-boot into the Desktop!

So that's 11 modules to get a minimally-usable Desktop - but you still can't actually do much with this. So let's at the very least get our Apps icon working, along with !Edit and !Configure.

• ResourceFiler - the module that allows us to access the Resources filing system via the Filer. (Note that ResourceFS is one of the modules that's automatically reinit'd by RISC OS on every bootup, so we don't need to worry about that one.)
• !Configure - the module that every teacher unplugged and a select few pupils knew how to reinit again.
• Squash - for some reason, !Configure requires this module in order to load. *shrugs*
• Basic - used to run an "Export" BASIC file in ResourceFS which allows !Edit to read and write BASIC files. Without this module, !Edit will refuse to load.

Which makes our 15 modules!

...okay technically we're cheating a bit here because while we can now load !Edit and !Configure, the !Run files for these applications will also re-initialise a few other modules for us:

• !Edit - yep, !Edit reinits its own module. To be fair, it's kind of an important tool.
• SharedCLibrary - !Configure reinits this module when it loads. I have no idea why Acorn didn't decide that it should do the same for Squash, but there you go.

So, 15 17 modules later (or 16 if you didn't bother with ShellCLI), we have something we can do with our minimal desktop!

Okay let's finally fix three more issues that might be bugging you but aren't technically necessary for a minimal desktop:

• Draw - loading this module will finally allow the splash screen to display properly. It also fixes the Info window in the Task Manager menu.
• PaletteUtil - gives us the good old Palette utility next to the Task Manager.
• TaskWindow - allows us to use the Task Window option in the Task Manager menu to run *Commands in an !Edit window.

We still don't have any kind of proper filesystem support in our desktop... but at that point it wouldn't be very minimal, so I'll leave that as an exercise for the reader.

[jms2]

A great post! I was wondering the same thing recently. I know this isn't practically useful information, but it is interesting.

[IanJeffray]

If your machine has an FPA10, you don't need this module.

Are you sure about that? Because, as far as I'm aware, FPA10 *requires* the softload FPA400 module with hardware FPA support or it does nothing.

[jregel]

A really interesting post, thanks. It's a useful explanation of what is actually happening "under the hood".

[Sophira]

If your machine has an FPA10, you don't need this module.

Are you sure about that? Because, as far as I'm aware, FPA10 *requires* the softload FPA400 module with hardware FPA support or it does nothing.

I only tested it in Arculator, but assuming the emulation is accurate, then yes, the Desktop load sequence does not require FPEmulator if the machine has an FPA10.

[IanJeffray]

the Desktop load sequence does not require FPEmulator if the machine has an FPA10.

That's very odd. Particularly moreseo as, AIUI, FPA only implements part of the FP instruction set, leaving the rest to the software module.
I have repeated the behaviour you described, in Arculator, - Illegal Instruction at &03877ac8 - a "RFS" FP instruction in WindowManager, unless "FPA10" emulation is enabled.

I can confirm this does NOT happen on real hardware -- as I still have AndyMc1280's R260 with FPA here. Unplugging FPEmulator, with a real FPA10 in the machine, gets the same illegal instruction error. Have to suggest this is a bug/funny in Arculator.

OS_Core/Desktop/Wimp/s/Wimp07:

Code: Select all

; In    R4 -> task block of current task
; Out   FP registers saved if FPEmulator present and task knows Wimp 2.23

saveFPregs
        Push    "R0-R3,LR"

        Debug   fp,"Saving FP state for task",#taskhandle
        Debuga  fp,"Reading FP status: "

        RFS     R1                      ; <==== NB: pending trap can occur here
                                        ; so do it before claiming block!

[Sophira]

Honestly, though, the thing that feels really weird to me when I think about it is, the FPEmulator requirement turns up after the *Filer_Boot command but before the *Obey command. I would have thought that the former would be calling the latter when running an application's !Boot file, which suggests that the FPEmulator requirement happens somewhere in the *Filer_Boot command... but what possible use could it have for that?

[edit: Oh, judging from what you pasted above, I guess it's saving the state. That makes a little more sense!]

[IanJeffray]

[edit: Oh, judging from what you pasted above, I guess it's saving the state. That makes a little more sense!]

Yeah, it seems this code path only happens at SWI Wimp_StartTask.
And only for tasks which declare they know about WIMP >= 2.23

[Sophira]

Makes sense. I opened a GitHub issue for the Arculator issue, but as I don't have real hardware I don't feel qualified to work on this myself.

[IanJeffray]

Makes sense. I opened a GitHub issue for the Arculator issue, but as I don't have real hardware I don't feel qualified to work on this myself.

The FPA macrocell docs do say it provides RFS, so I'd guess that the issue may be down to how ARM handles the illegal instruction - with no FPEmulator module, there's nothing to trap the 'faulty' CoPro instruction and divert it to the FPA - so I'd have to guess Arculator's doing that in some other special way. But honestly I don't how if ARM somehow has some actual way of auto-sending unknown instructions to CoPros rather than the trap for software emulation.

[Sophira]

This is starting to get complex enough that I might have to ask for clarification on exactly what error you received, since we've mostly been using the term "illegal instruction" here, but the actual error I got on Arculator without FPA10 emulation was an "undefined instruction". Specifically, the error I get in Arculator is:

Internal error: undefined instruction at &03877AC8

Do you get the same error on real hardware, or does it say "illegal instruction"? I can see both strings in the RISC OS 3.11 ROM and there may be a subtle difference between the two.

[IanJeffray]

the actual error I got on Arculator without FPA10 emulation was an "undefined instruction"

Your pedantry is a fair cop I should have been more precise. Here's the R260 on the left and Arculator on the right...

[Sophira]

No worries! Thank you for the clarification that the two are the same "undefined instruction" error. I was trying to not be pedantic but given the weirdness of the situation, I wanted to make sure there wasn't anything there that might give additional clues as to how Arculator should be handling things.

I'm actually a little disappointed - I thought I might have been onto something! Oh well.

[IanJeffray]

So what does a real ARM7500FE machine (A7000+) with its FP hardware do if you unplug FPEmulator?...

Yep, that's the same death at the same RFS instruction.

[sirbod]

Don't forgot an FPA needs configuring before it will intercept instructions. The FPASC component (FPEmulator in our case) does that be setting the Exception Trap Enable bits in the FPSR.

You could fudge it yourself with one instruction, but for the purposes of this thread its simpler to assume FPEmulator is a required Module on all machines.

[NancySadkov]

Was FP used that much on RISC PCs? In what area?
IIRC x86 also had optional FPU, but I'm not sure if people used it widely in 80ies-90ies.
I never had a computer back then, beside a playstation, which did everything in fixed point.

[qUE]

Was FP used that much on RISC PCs? In what area?
IIRC x86 also had optional FPU, but I'm not sure if people used it widely in 80ies-90ies.
I never had a computer back then, beside a playstation, which did everything in fixed point.

I think last time x86 had the option was when 486s were about with the 486SX having no hardware FPU and 486DX having it. After that I assume Pentium 1, Cyrix 586 and other 586 CPU clones (I still have some oddities) all had it.

I would hazard a guess anything complex math related like spreadsheets, scientific, 3D graphics (raytracing, rendering) and of course 3D games like Doom would've made use of the hardware acceleration on Acorn Computers.

What is kind of interesting is Acorn's choice to passthrough FP support to hardware if it exists in the OS SWI/API calls, I gather on x86 DOS and Windows 3 around the same time it would've been done at the application, one of many forward thinking OS decisions Acorn made. Unfortunately there were quite a few things they didn't pre-empt, and the same as other OS makers legacy hardware hold backs due to software compatibility and time constraints to market.