Dodo modules

I believe there are a hand full of flightless birds at the end of their evolutionary path in the form of a few modules which either do nothing useful or have become redundant or largely duplicated.

In idle moments I plan on taking them out of the gene pool. The motivation here is that there are enough CMOS unplug bits for about 144 modules, and there are currently about 120 modules in ROM. It’d be nice to include at least a small handful of other territories out of the box (since not everyone is in the UK) while not affecting the net number of modules too much.

Numbered list to allow easy referencing:

1. ARM – just provides *CONFIGURE CACHE and *CACHE commands, propose pushing those into the Kernel where all the other ARM support is
2. BASICTrans – superceded by MessageTrans, had a quick look at this and should map pretty easily to MessageTrans calls (noting the proposal to pull the assembler out of BASIC, some of the interactive help will be chucked anyway)
3. OMAP4Video – 97% common code with OMAPVideo, propose merging into one driver that supports the PowerVR 5xx family detecting which is which at runtime for the 3% deltas
4. NetUtils – dummy module, loaded from disc by !InetSetup for NetFS < 2.79, and RMInserted (but with silent errors) on enabling AUN. Delete it.
5. WindowUtils – was kept for things to RMEnsure against, but since this is a RISC OS 2 patch it seems unlikely that a GUI app that ran on RISC OS 2 still works on a 32 bit version without having some rework. Delete it.
6. GameModes2 – extra modes from pre mode selector era but now a dummy module. Delete it.

Help! Do NOT remove the assembler from BASIC!!!!!

You would certainly break some of my software if you remove BASICTrans, and I suspect there are other elephant traps waiting there in legacy programs, eg: BASICTrans converts unique error numbers to message tokens, so it is not just a case of getting BASIC to look up the tokens itself. You would need to recompose the Messages file etc.

Do NOT remove the assembler from BASIC

Don’t panic, that’s not what I (intended to) say. The proposal is to remove it from the BASIC module but not from use from within BASIC. This avoids duplication between BASIC V and BASIC VI, and allows extensions to be added by 3rd parties without needing to patch binaries – for example a 6502 assembler.

You would certainly break some of my software if you remove BASICTrans

Can you elaborate? With a strong enough case the BASICTrans SWIs could just be moved into BASIC, but the underlying lookup performed by MessageTrans.

Could dummy NetUtils/WindowUtils not be soft-loaded at bootup from within !System?

Or, !inetsetup updated to only conditionally check for it?

One solution could be to have dummy versions of the dodo modules held within the kernel, and inserted into the module chain at the appropriate point (e.g. during the UtilityModule initialisation entry point). That way the modules will still exist, but they won’t go towards the ROM module count. However there is the downside that if you killed one of them you wouldn’t be able to do a simple *rmreinit to get it back (unless *rmreinit was given knowledge of them).

Alternatively, update the *unplug logic so that it skips modules with certain names, instead of just skipping the first N modules in the ROM image. I’d imagine this would be pretty easy to do. It could even be done with a flag in the module header, avoiding the need for the kernel to keep a blacklist and to mess around doing string comparisons.

Another module we could (potentially) get rid of is the IIC module. On RISC OS 5 machines all this does is provide one SWI that’s a simple wrapper for OS_IICOp.

It may also be worth adding a dummy version of CallASWI (as ROL have done), so that software doesn’t unnecessarily softload a copy of the module, potentially resulting in loss of some functionality (e.g. if the OS has a better implementation of a SWI than the CallASWI version)

3.OMAP4Video – 97% common code with OMAPVideo, propose merging into one driver that supports the PowerVR 5xx family detecting which is which at runtime for the 3% deltas

I’d be impressed if combining the two modules produced a PowerVR driver! The modules are drivers for TI’s display controller chips/silicon, not the PowerVR GPUs. I’m not entirely sure why Willi decided to create his own version of the module instead of adding the extra functionality to mine, so you’d have to speak to him about that.

Can you elaborate? With a strong enough case the BASICTrans SWIs could just be moved into BASIC, but the underlying lookup performed by MessageTrans.

I call BASICTrans SWIs to lookup error messages. IIRC the original BASICTrans was independent and contained its own Internationalised messages, but current versions do use MessageTrans for lookup. I suspect that moving the SWIs into the BASIC module would be feasible, because the International aspects are now in the Messages file.

I’d be impressed if combining the two modules produced a PowerVR driver!

My mistake, I had the datasheets open, eyes pointing at it, but the sugar in the breakfast cereal hadn’t made it to my brain yet.

It may also be worth adding a dummy version of CallASWI

The recommended RMEnsure sequence should avoid that need shouldn’t it? Because the UtilityModule and CallASWI come in pairs. Also, CallASWI doesn’t have the 32 bit flag set so you’ll get a rude message trying to load it on RISC OS 5.

For making fake modules in the module chain (without requiring ROM modules) do you even need the module node? Could RMEnsure just keep a look out? Or do we need to deal with OS_Module use too? Maybe it’s geting a bit messy.

Would a “Legacy” plug-in for configure that contains all the dummy modules, work?

Any selected modules would be loaded early in the boot sequence (if the version of RO 5 is high enough.)

I say chop the lot at some point – if there are problems with legacy RMEnsures, you can always dump dummy modules in !System. But this pruning activity wouldn’t be anywhere near the top of my priority list…