Compressed ROM images

I do not think the Basic TWIN command should be misused, sorry. In fact, I suggest it is removed from Basic! It has had no practical use for many years, and should not be in part of Basic anyway. Indeed, perhaps the EDIT command should also be removed from Basic. We have surely moved from single-tasking machines (where TWIN and EDIT were useful) to Desktop use?

At the moment RISC OS boot on RPi is fairly instant (didn’t measure it at the show, but I’d guess under 5s). It’s rather unfortunate if we have to load a big chunky ROM image, because that slows down the boot for everyone even if they don’t use the desktop. But I appreciate that’s where we are at the moment.

Once we have an SDFS, a default boot-to-BASIC that holds off running !Boot might be an idea. Though it would need some means of *Configure Boot/Language (no CMOS, don’t forget) so it’s possible to force a desktop boot every time.

The live ROM isn’t really intended for everyday use though, is it?

Once a proper install is done, the usual ROM would be used.

(Is the structure such that the only the part equivalent to the main ROM could be loaded by issuing different load parameters?)

(no CMOS, don’t forget)

But surely on the Raspberry Pi a file on the SD card called ‘cmos’ can do what is required, being fatloaded at the same time as the file ‘riscos’ containing the RISC OS ROM.

But surely on the Raspberry Pi a file on the SD card called ‘cmos’ can do what is required

Absolutely, that is my understanding too.

being fatloaded at the same time as the file ‘riscos’ containing the RISC OS ROM.

… and that’s one of the ways to achieve it; not the only way, but it was the first I tried before I started work on the SD reading/writing code. fatloading it worked immediately.

I do not think the Basic TWIN command should be misused,

Perhaps the token for ‘TWIN’ should be used for a keyword ‘DESKTOP’ which issues the necessary command from BASIC started up with noboot to do a boot and enter the desktop (*RUN !Boot, *DESKTOP ?).

In fact, the Iyonix flash ROM tool also patches the NVidia module before writing the ROM to flash

I’ve never understood what that’s all about. Presumably if there are several subtle differences in the NVidia cards out there then the BIOS ROM must be different on each (so the PC pokes the subtle bits in some subtle manner).

Therefore, just do a CRC16 of the BIOS ROM (which gets mapped in somewhere in PCI memory space) and use that to select from a table of corresponding poke differences in the NVidia module. Simples.

It looks like the only information that gets poked into the NVidia module is one word per fitted card, corresponding to the correct value to write to the NVSTRAPINFO2 register. The comments in NVidia.s.Module (line 62) suggest it’s because some cards get confused on startup and report the wrong configuration information, while the comments in NVidia.c.Post (line 624) suggest that poking the right value fixes the pyjamas issue. Interestingly, although Post.c contains a lookup table of card types to STRAP values, the PostDevice() function which uses that table to write the STRAP value to the card isn’t being used at all, so the module is relying purely on the STRAP values that have been poked into the module during softload/ROM programming. We don’t have any real CVS history for the module, so I’m not sure why the table in PostDevice() was abandoned.

Long story short: For now I think I’ll avoid rocking the boat too much and just move the poked values into a simple HAL device contained in the HAL. This will avoid me having to modify the softload & romflash tools to deal with uncmpressing/recompressing compressed ROM images.

Long story short: For now I think I’ll avoid rocking the boat too much and just move the poked values into a simple HAL device contained in the HAL.

Seems entirely reasonable! Perhaps the full log could be retrieved from the original repository to see what the motivation was. Presumably RAM loading modules are therefore a bit non-sensical if it’s expecting to find a poked table at the start of the module.

As the NVidia module is only used on the Iyonix (at present) and there’s always >= 256 bytes of EEPROM there, why not just use one of the CMOS bytes to store a card sub-type? That would eliminate the need for any hokey pokey patching (bytes 240-255 are unallocated because they normally overlap the clock but the Tungsten motherboard has a seperate clock chip).

Presumably RAM loading modules are therefore a bit non-sensical if it’s expecting to find a poked table at the start of the module.

It copes with that by finding the ROM version of itself and reading the values out of there.

As the NVidia module is only used on the Iyonix (at present) and there’s always >= 256 bytes of EEPROM there, why not just use one of the CMOS bytes to store a card sub-type?

That would work, although it would be a bit nasty if your CMOS was reset.

Presumably RAM loading modules are therefore a bit non-sensical if it’s expecting to find a poked table at the start of the module.

It copes with that by finding the ROM version of itself and reading the values out of there.

Ew.

why not just use one of the CMOS bytes to store a card sub-type

That would work, although it would be a bit nasty if your CMOS was reset.

Perhaps this is a situation where using the NVMemoryFlag_ProtectAtEnd flag in the HAL is justified, so that the config can be set once but doesn’t get zapped on a delete-power on?

For those interested in the low-level details, I’ve added a Compressed ROMs page to the wiki, and updated the OS image header description with details of the new OS header format. I’ve also checked in the first version of the ROM compression tool (‘rompress’), but you won’t be able to do anything with it yet until 5.18 is out and I can safely check in the kernel/HAL changes.

More progress:

• I think I’ve successfully taught the softload tool about different sized ROM images, and how to detect compressed images. It’s a bit fudgey in places (even more than usual!) but seems to work OK. When loading a compressed image it’ll try to find an area of RAM big enough to hold the uncompressed version, which could help to simplify the implementation of HALs, as well as helping to make sure that you’ve actually got enough memory available to load the image. It’ll also prefer to decompress the image before booting it, but this is optional, and gets skipped on 26bit systems anyway (the tool relies on the decompression code held in the ROM image, but the image will have been loaded into a DA, above the 64MB PC limit).
• Since the softload tool is taking care of ROM placement I’ve successfully managed to boot compressed IOMD & Tungsten images, without having made any HAL changes yet. However I did need to let the softload tool decompress the Tungsten image and patch the NVidia module; without that patching the ROM didn’t seem to boot at all. Something for me to investigate tonight, although ultimately irrelevant once I’ve moved the patch region into the HAL.
• I’ve also made some tweaks to the OMAP HAL (use DMA for relocating the ROM image, go to full CPU speed sooner) which shave about 1.3s off of the compressed live image boot time.

gets skipped on 26bit systems anyway [as] the image will have been loaded into a DA, above the 64MB PC limit.

Given the low level nature of the softload tool, can you just set the 32 bit mode bit in the CPSR and run it anyway? The target must be ARM6 MMU or later hence should have 32 bit mode.

I did think of it at the time, but now that you’ve made me think again I’ve seen a way around the problem that was stopping me from implementing it. Cheers!

(The problem was that the decompression code gets given a pointer to an IMB function, which is really just a wrapper around OS_SynchroniseCodeAreas. Calling a SWI in 32bit mode on a 26bit system is likely to be a no-no, but I didn’t realise that I could just drop back into 26bit mode around the SWI call)

However I did need to let the softload tool decompress the Tungsten image and patch the NVidia module; without that patching the ROM didn’t seem to boot at all. Something for me to investigate tonight, although ultimately irrelevant once I’ve moved the patch region into the HAL.

It turns out this is because the HAL patching wasn’t being applied, so the softload-unaware RAM clear code went ahead and nuked the ROM image.

Now that I’ve taught the Tungsten HAL about softloads and differing image sizes the compressed image will boot (with working video), but there’s the slight problem that you get blasted with a brief burst of noise during the HAL initialisation. Strangely this doesn’t happen when booting the uncompressed image, so I’m not sure what the problem is, as the HAL should be behaving in pretty much the same way for both images, and the softload tool should be dumping the images into the same area of RAM each time.

Rather than worry about it too much I think I’ll just make the softload tool turn off sound before booting the image.

Next up will be teaching the IOMD HAL about compressed ROMs, which could be a bit tricky since the RAM isn’t in guaranteed to be in one or two big chunks like on the other platforms.

Would it be of any advantage to use compressed ROM for the RPC?

ie can different combinations of ROM’s be used in a RPC – by setting links?
Perhaps using one ROM or more common/cheaper ROMs.

I’m not sure how many different ROM sizes the RiscPC supports. I think RISC OS 3.5 was squeezed into a 2MB image, but the only size I’ve heard of being used since then has been 4MB.

It’ll be a while before we overflow the current 4MB IOMD ROM image; there aren’t any USB or SCSI drivers included so there’s tons of space compared to the other ROMs. So we might never need to use compressed IOMD ROMs on a regular basis. I’m mainly adding IOMD support for completeness sake. Maybe it would be useful if we made an IOMD live image.

Maybe it would be useful if we made an IOMD live image.

An IOMD live image would be really useful. Currently trying RO5 would require a lot of changes to a RiscPC class machine, which could easily be inappropriate for many systems, and RO 5 might not even support the hard drive controller anyway.

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

RO 5 can access the hard disc, it’s only the lack of networking which is any sort of problem and that won’t change with a live image!

The only changes needed are to !Boot so it can cope with the OS in rom or the softloaded OS.
See this Thread https://www.riscosopen.org/forum/forums/5/topics/899

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

I would hope you’d be able to use it to see what it does in 64MB. I suspect you’d want 96 or 128 for it to really work properly.

RO 5 can access the hard disc

Only if it is on the motherboard interface, as far as I am aware.

The only changes needed are to !Boot so it can cope with the OS in rom or the softloaded OS.

That appears to refer to the ROOL boot, which is fine if you are prepared to replace the original system. But RO 5 on an RPC isn’t really very viable as anything other than a taster yet. The original system needs to remain.

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

It all depends on how much you’re trying to squeeze into it. With the OMAP live image the idea is to sell RISC OS to non-users, so you’d need a big image with the full disc image and some bundled software. But for IOMD machines you’d already be softloading ontop of a working RISC OS installation, so all you’d really need is the core boot sequence.

Without network drivers I’m not really sure what the purpose of an IOMD live image would be. Perhaps as an easy way for application developers to check that their software works under RISC OS 5? Or for OS developers to check that the IOMD ROM still works.

Once ROOL have found a way of creating the live images without relying on the hacky LiveDisc component there’s a fair bit of work that could be done to strip out unecessary data from each image. E.g. removing any modules from !System which are already in ROM, dropping high-res sprites from images destined for low-memory machines, etc.

Without network drivers I’m not really sure what the purpose of an IOMD live image would be. Perhaps as an easy way for application developers to check that their software works under RISC OS 5? Or for OS developers to check that the IOMD ROM still works.

They are the two obvious ones for a developer.

But it would give ordinary RPC users the same chance to try RO 5 as non RO users would get on OMAP devices.

e.g. try it out on a club machine.

One !Boot does Pretty much the same as another! With what I have added to the ROOL !Boot, if I don’t select the softload then everything works under RO4 as it did with the RO4 !Boot.

Who know’s in time there may be things you can only do using RO5!

My experience with RO5 on a RPC is that everything breaks. My disc is full of crufty non-32-bit software, and my boot sequence the same, so I get errors all over the place (eg when application !Boot files try running things that aren’t 32 bit). Having a known-good image that I can easily drop in over RO3/4 is handy. Then I don’t need to mess about with moving !Boot out the way, trying to merge ROOL’s stuff into ROL’s !Boot, etc etc.

I think I’ll have a go at completely rewriting the RAM detection code that’s in the IOMD HAL. The basic code (to determine the size/arrangement of RAM in a DRAM bank) is pretty simple and will stay the same, but everything else around it to deal with splitting banks into contiguous chunks will be rewritten. This is the easiest way I can think of updating the code to fully deal with compressed ROMs, and to get rid of the issues people have been having with softloads not working. Plus it should be pretty easy to write a BASIC testbed that runs through all the different RAM combinations and makes sure the code won’t fall over.