IOMD ROM space saving

Since IOMD ROMs are close to overflowing, I thought it would be good to have a list of potential actions we could take to reclaim some space.

1. HAL – The HAL is only about 12KB in size, but is being padded out to 64KB. So we could easily get 48KB of space by adding a 16KB HAL size option.
2. BASICs – There are two copies of BASIC in ROM, for 5-byte floats and FPA. Total space used is about 128K, so finding ways of sharing duplicate code could save up to 64KB. E.g. splitting out the assembler has been previously discussed – some kind of service call or vector to allow the external modules to implement different assembler dialects. The assembler is about 50% of BASIC’s code, so storing only one copy of it would save about 32KB.
3. Sprites in ResourceFS – We could save about 75KB of space by converting the ROM sprites to newer, more memory-optimised formats. However since we’re talking about IOMD here, we’d probably also want to do some profiling to make sure the new formats aren’t significantly slower than the old ones. https://www.riscosopen.org/forum/forums/3/topics/10252
4. Unify the filers – There’s a fair amount of duplicate code in the filing system filer modules (especially since several of them are all built from the same sources). https://www.riscosopen.org/forum/forums/2/topics/815
5. Compress the ROM apps – Currently I believe all the ROM apps are designed to save on RAM, by having the code directly execute from ROM instead of being copied to application space. But most of the time, you’re only going to be running zero or one copy of each of the apps (Paint, Draw and Edit all allow multiple documents to be open) – so what’s the harm in sacrificing a bit of RAM, by compressing the code that’s held in ROM?
6. Remove some of the ROM fonts – The desktop only needs one font (two if you count WIMPSymbol), the others are superfluous and could easily be moved to the disc image.

Finally, there are a few fallback options for “making the ROM bigger”

1. I’m not sure what the restrictions are for physical ROM chips in IOMD machines, but if 8MB ROMs are supported by real hardware then that would be an obvious solution that would leave us with plenty of space.
2. If bigger physical ROMs aren’t possible, compressed ROMs are the fallback. Full ROM compression might not be the best option (some of the benefit of using physical ROMs is lost if you have to sacrifice several MB of RAM to store the OS), so it might be worth developing a hybrid system where only the last few KB of the ROM is compressed – just enough to get it below the size limit. Then at runtime the majority of the logical mapping of the ROM will map directly to the physical ROM, while the remainder will be mapped to the RAM copy of the decompressed section.
3. Or, a different take on the same thing: Compress some of the ROM modules and have the OS decompress and run them from the RMA instead. This would require the modules to be properly relocatable, but it should work, and will also allow the RAM used by those modules to be reclaimed if the module is unplugged or replaced with a softloaded version.

We should also consider:

• Ceasing IOMD development
• Dropping physical ROMs
• Moving anything that isn’t critical to disk
• Compressing ResourceFS

Personally I think it’s about time we diverted resources to migration to C and newer standards, instead of maintaining legacy machines. Drop Iyonix as well.

Ceasing IOMD development

Don’t do this. While “real” IOMD hardware may be over 20 years old, RPCEmu provides a useful way of running RISC OS under emulation. I find it really handy to be able to run an RPCEmu session to swiftly check something out, without having to fire up another machine.

Don’t do this.

Seconded. Having the option of running RO5 under emulation is pretty much essential here.

Since IOMD ROMs are close to overflowing, I thought it would be good to have a list of potential actions we could take to reclaim some space.

In response to the observation that correcting the build options for Draw and Paint to include stack limit checking caused the ROM to (just) overfill, I went with your first option and shrink the HAL to 32k. I haven’t submitted it yet as I’m waiting for some of the churn around BuildSys to settle. I also went with 32k (rather than 16k) just so there’s a pleasing 32/64/96/128 progression – slight OCD tendency.

Looking at the ROM link summary for anything > 64k has, in order:

• Messages &Bxxxx
• ROMFonts &5xxxx
• Kernel &3xxxx
• RISC_OSLib &3xxxx
• Draw &2xxxx
• Paint &2xxxx
• Internet &2xxxx
• SpriteExtend &2xxxx
• Wimp &2xxxx
• LanManFS &1xxxx
• Debugger &1xxxx
• BASIC &1xxxx
• FileCore &1xxxx
• FontManager &1xxxx
• InternationalKeyboard &1xxxx

Of that list I’m pretty you could chuck LanManFS out; I doubt anyone’s booting using that and there’s a softloading copy inside Omni.

I’m not sure compressed ROMs will fly since the A7000 can have as little as 4MB of RAM soldered to the PCB, leaving you with little/none to run in.

I’d certainly look at compressing ResourceFS as sprites and message files will compress very well, but how about supporting compression in ResourceFS itself so the files can be read directly from the ROM?

There is very little gain from including things like Draw, Paint and LanManFS in ROM, as they are not used all the time, and take minimal RAM when in use.

We should also consider:
Ceasing IOMD development
Dropping physical ROMs

My question is how much effort is needed to continue IOMD development?
What if any restrictions does doing so impose?

I see developers find emulators with IOMD builds useful but I do wonder how many people are actually using physical ROMs?

We’ve acquired several copies of the RO5 ROMS, as part of peoples clear outs. I think the owners all told us that they’d never been fitted and had been bought ‘to support ROOL’.

I believe all IOMD machines can have at least 128MB of RAM fitted (FPM/EDO RAM is still available).

(some of the benefit of using physical ROMs is lost if you have to sacrifice several MB of RAM to store the OS)

What benefits?
The protections from being corrupted by rogue software I would expect to have been reduced over the years.

Personally I think it’s about time we diverted resources to migration to C and newer standards, instead of maintaining legacy machines. Drop Iyonix as well.

After what’s been said previously in other threads, I wonder if this is said, tongue in cheek.

I wholeheartedly agree with the sentiment around resourcing and spending time moving the OS forwards.

Moving away from ROM builds doesn’t feel right. On the other side of the fence, I understand that Zlib has been adopted to compress the OS build. I lack the specific technical understanding here, but it feels like other operating systems are following what RISC OS has been doing for years.

My question is how much effort is needed to continue IOMD development?

Very little, since most of the time stuff “just works”. If people are writing C code then the compiler will take care of generating ARMv3-safe code. Assembler is a bit more annoying since you can’t assume newer instructions are available, but even if we dropped ARMv3+v4 we’d still have ARMv5 (Iyonix) and ARMv6 (Pi 1), along with a few variants of ARMv7+v8 to support.

(some of the benefit of using physical ROMs is lost if you have to sacrifice several MB of RAM to store the OS)

What benefits?

Lower RAM usage, and protection against corruption.

Currently if a ROM is compressed the OS will make a full copy of the uncompressed version in RAM. For machines with under 32MB of RAM, losing 5MB+ to a copy of the ROM would likely render the machine unusable.

But as you say, RAM modules are still available, so if someone’s “upgrading” to RISC OS 5 then maybe it isn’t too much to ask them to consider upgrading their RAM too.

Surely the lowest-hanging fruit that yields the biggest buffer is to punt Draw and Paint to the disc image?

I would say the simplest fix is to move the three main ROM apps out. There’s precedent – they already exist within !Boot in a loadable form for RISC OS 3.5.
Side effect – with them gone, there won’t be any need to have RISC_OSLib in ROM either, so more space saving.

I’m not sure compressed ROMs will fly since the A7000 can have as little as 4MB of RAM soldered to the PCB,

It’s that worth worrying about? It seems unlikely that a person with such a low spec machine would be interested in running 5 on it because… well… you’d be hard pushed to get any sort of worthwhile browser running on such a machine.
I gave up on using my 4MB A5000 for exactly the same reason. I wrote QuickVoy to provide a Voyager-like interface in 128K (or 32K for the basic version) because it simply wasn’t feasible to run Fresco for websites and the front end at the same time.
That was circa 1998.

I do not agree ditching the IOMD build (as rightly pointed out, emulators), but I do think we ought to set a minimum specification that allows for the possibility of softloading, should it become necessary in the future.

Amazon will sell you 64MB SIMMs (often 2×32) for about twenty quid…

I’d be personally happy to see Edit evicted from the ROM to disc, but realise that this may be a minority opinion. With Draw and Paint gone, the shared RISC_OSLib is redundant, and a statically-linked RISC_OSLib with Edit would use a smaller subset of that library too.

Having Edit in ROM is useful if your machine cannot boot from disc and you need to fix things by editing stuff.

Having Draw and Paint in ROM however is pretty useless unless you are in a very memory-restricted environment, and I agree with Rick that that is a true minority interest. Physical machine AND 4 MiB of memory AND interest in RISC OS 5 big enough to swap ROMs instead of just adding a larger SIMM – that sounds like a minority of 0 or 1.

Having Edit in ROM is useful if your machine cannot boot from disc and you need to fix things by editing stuff.

I would suggest being able to do that is a necessity! Must be kept in ROM.

However, I have never needed Draw or Paint in an emergency discless boot, and can see no need for them in ROM.

and a statically-linked RISC_OSLib with Edit

I hope so. The problem is that RISC_OSLib isn’t well designed. All of the functions in a certain “block” are in a big wodge of code. Consider if you want… what is it called… bbc_beep? To make a beep. Well, using that one function will require the entirety of the bbc library to be included.
Unlike DeskLib where many functions are individual so you generally get only what you actually use. (can’t speak for OSLib, but I’d be surprised if it wasn’t the same idea)

Still, less in ROM would be a good thing. Maybe look to see if some of the other ROM apps (Alarm?) could be evicted too. I mean, these days it’s all merged into “Apps” so where it is actually from shouldn’t be a big problem.

Thing are getting a bit tight then, this from a current IOMD32 ROM build.

romlinker: Warning: Insufficient space for ROM symbols
romlinker: Image has 2497 bytes spare (2.44K)

With Paint and Draw removed.

romlinker: Image has 73797 bytes spare (72.07K)

Do the Toolbox modules then need to be in ROM? They would need to be added to !System.

P.S Help uses the toolbox!

What is the size of the existing boot flash (on the machines that have it)? That sets a compatibility limit.

Of that list I’m pretty you could chuck LanManFS out; I doubt anyone’s booting using that and there’s a softloading copy inside Omni.

Normal use or recovery? It’s currently the only cross-platfrom file transfer tool in the IOMD32 ROM that is compatible with typical modern hardware. You can’t softload from a blank disc.

Perhaps it can be substituted or supplemented with a simple HTTP downloader.

For similar reasons the network card drivers should be added, one can’t rely on card resident drivers being RISC OS 5 compatible.

Can I add another voice for letting IOMD die?! And Iyonix!

I think the only real use-case here is using emulators (which might be some people’s only way into RISC OS or a handy compatibility checking tool).

So… Surely the sensible thing is to investigate emulation options which are not focussed around IOMD? Is there an emulator which can run the Beagle, Panda, iMX6, TiM or Pi ports? How usable is the Linux port? Could there be a Windows port?!

It just strikes me as odd to expend a single ounce of effort on ancient hardware. Surely anyone using a RISC PC or A7000 isn’t doing anything serious with any modern applications?!

I understand that retro is a thing. And that is great: the old hardware can run the old OS versions. Even up to 5.18. That’s enough!

Given how limited developer time is, I’d go with the option that requires least effort, which is simply don’t worry about the IOMD ROM size! No one with any sense is putting RO5 in physical machines and RPCemu accepts bigger ROM images, so just let it grow bigger.

(other than that, if you really must save space, drop Draw and Paint out to disc)

How about giving the downloader, the option of load both to either rom, or disc drive, if there’s space, on either, just a thought, though.

I think most emulating RISC OS on RPCEmu would be using RISC OS 3.7, unless they purchased a RO Ltd version of RISC OS.

I don’t – RedSquirrel does a decent enough job of 3.70.
The ROLtd versions probably run on VirtualRPC.

And RPCEmu? Most likely 5.something. I vaguely recall an issue preventing 5 from running on RedSquirrel (which is why I have both RedSquirrel running 3.7 and RPCEmu running 5 on my PC).

specific to emulating the RPi in an effecient way on high end computers

Which would be bad. Any future emulator ought to be a “platform” in itself, in order to allow the most efficient conversions between the RISC OS environment and the host. We had a discussion on this a few months ago.

We have a few Archimedes Emulators, though no RiscPC Emulators yet.

For RISC OS, no. But then it’s probably simpler to run Aemulor rather than trying to emulate a RiscPC (plus it puts things in the same environment).

On a PC? Well they’re pretty much all RiscPC emulators…

I appreciate devs like to test things under emulation, I’m one of them, I do all my development and testing under emulation. That is not however a justifiable reason to continue maintaining such old hardware in the OS.

Although the running maintenance time might be low as Jeffrey says, consider the impact to inflow bounties and future standards compliance, which have to factor in IOMD and Iyonix. Also consider the testing involved before stable releases and the amount of code that isn’t really maintained in the OS codebase for drivers.

If we’re seriously saying the OS devs should maintain legacy hardware drivers for an indefinite period of time, we’re clearly making decisions based on an emotion response and not reasons that make and form of business sense.

Now is a good opportunity to fix IOMD and set a date to remove its codebase from the OS. I would urge we do likewise for Iyonix, due to the dwindling number of working machines available.

If we’re seriously saying the OS devs should maintain legacy hardware drivers for an indefinite period of time, we’re clearly making decisions based on an emotion response and not reasons that make and form of business sense.

The alternative is for someone to write a new emulator.

The RPCEmu devs have made it very clear they’re only interested in emulating IOMD, so any new “RO5 for emulators” build that ROOL might produce would initially have no platform to run on. Unless there really is another dev team that are chomping at the bit for an “emulators only” build that they can write an emulator for…

Although the running maintenance time might be low as Jeffrey says, consider the impact to inflow bounties and future standards compliance, which have to factor in IOMD and Iyonix. Also consider the testing involved before stable releases and the amount of code that isn’t really maintained in the OS codebase for drivers.

You also need to consider the developer time and resource to create a new emulator which is as polished as RPCEmu, so that all those using RO5 under emulation can continue to do so. Only if that is less work in the timeframe that you’re talking about pashing out IOMD support (whilst continuing to fully support IOMD in the meantime) is it a better option.

I think most emulating RISC OS on RPCEmu would be using RISC OS 3.7, unless they purchased a RO Ltd version of RISC OS. While I am aware that some people do touch RO5 on occasion in RPCEmu, I would expect that they primarily use RO3.7 or a RO Ltd version.

You would think wrong in this case. RO5 on RPCEmu may account for around 50% of my RISC OS usage, and that’s a mix of development and “real” use.