Dodo modules
Sprow (202) 1155 posts |
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:
|
Chris Hall (132) 3554 posts |
Help! Do NOT remove the assembler from BASIC!!!!! |
Steve Drain (222) 1620 posts |
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. |
Sprow (202) 1155 posts |
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.
Can you elaborate? With a strong enough case the BASICTrans SWIs could just be moved into BASIC, but the underlying lookup performed by MessageTrans. |
Andrew Rawnsley (492) 1443 posts |
Could dummy NetUtils/WindowUtils not be soft-loaded at bootup from within !System? Or, !inetsetup updated to only conditionally check for it? |
Jeffrey Lee (213) 6048 posts |
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)
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. |
Steve Drain (222) 1620 posts |
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. |
Sprow (202) 1155 posts |
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.
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. |
Jess Hampshire (158) 865 posts |
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.) |
Steve Revill (20) 1361 posts |
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… |