Compressed ROM images

presumably that would mean Kinetics would work? (I am under the impression that they don’t, is that right?)

Will you need people to run you basic testbed on various machines?
(I have a Kinetic, an SA and a 7500.)

Would an NC be of any use to develop IOMD RO5?
(I have several, sitting unused)

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.

Theo I’m hoping to add in support for OS 3.6 & 3.7 this weekend, although I’ll only be able to test those on RPCEmu. I can email you a working dual booting !Boot for 4.02 and 5.19 if you like?

Is there enough interest for it be worthwhile for me to submit it to ROOL?

presumably that would mean Kinetics would work? (I am under the impression that they don’t, is that right?)

Kinetics might half work with a softload, but I don’t think anyone’s tested it. I think there are three different things that would need doing for us to have full Kinetic support:

• Kinetic card initialisation (low priority, since it’ll only be needed if someone burns an IOMD ROM)
• Kinetic RAM detection (possibly something I can add without having access to a Kinetic card)
• Tweaking the OS to understand what the Kinetic RAM can and can’t be used for. Since we currently don’t have DMA support in the IOMD ROM, I think the only things which we’d need to avoid putting in the Kinetic RAM would be the sound and cursor buffers (and the display buffer, if you don’t have any VRAM)

Will you need people to run you basic testbed on various machines? (I have a Kinetic, an SA and a 7500.)

The purpose of the testbed is to avoid having to get hundreds of different people to run the code. However I might knock up something you can run to help me to find out where the Kinetic RAM is meant to be.

Would an NC be of any use to develop IOMD RO5? (I have several, sitting unused)

Maybe it would be useful later on, but for now I think the main goal is to get the IOMD ROM working properly on RiscPC’s and A7000’s.

Is there enough interest for it be worthwhile for me to submit it to ROOL?

I think ROOL are planning on producing a universal boot at some point, but I’m not entirely sure when that’ll happen or how it’ll be distributed (e.g. as a seperate download or part of the main disc image). I’d say it’s definitely worth sending your changes in to see if it’ll help at all.

> Would an NC be of any use to develop IOMD RO5? (I have several, sitting unused)
Maybe it would be useful later on, but for now I think the main goal is to get the IOMD ROM working properly on RiscPC’s and A7000’s.

I was assuming they are virtually the same as an A7000 (or at least more so than say a Mico).

The way I thought they might be of use is if the machine doing the building shared the location it the softload was generated in the correct manner (FTP I think), then an initial test of the build would just be turning the thing on.

If this is a viable scenario and any developers would like one, I can get them to London.

I think ROOL are planning on producing a universal boot at some point, but I’m not entirely sure when that’ll happen or how it’ll be distributed (e.g. as a seperate download or part of the main disc image). I’d say it’s definitely worth sending your changes in to see if it’ll help at all.

It’s only helpful if they’re changes to source components (with specific reference to which revisions of the source components). It’s not particularly helpful if it’s just a monolithic dump of boot sequence because that’s only about 1% of the work. Getting it all to build from source from CVS is the bit that matters.

Ok Steve, looks I might have to get to grips with CVS then! Anyway to give you an idea of what I’ve done is to create some ROxxxHook folders and associated obey files, along with some additions to Boot:Utils. These consist of some RO5 modules and obey files and a Basic *Hon from the Acorn Uni!Boot.

If anybody would like to try out my efforts let me know and I’ll email you a copy. Some feedback would encourage me to pursue this :)

Ok Steve, looks I might have to get to grips with CVS then

Great! Take a look at our wiki, in particular how to do builds. The ‘Disc’ build is the one that currently generates the HardDisc4 image. It’s quite a learning curve, but if you’re interested in getting involved in RISC OS 5 delopment (ROMs and disc stuff) then this is a very handy set of skills to acquire. And there’s always help and advice on the forums.

Kinetics might half work with a softload, but I don’t think anyone’s tested it. I think there are three different things that would need doing for us to have full Kinetic support:

If you want the loan of a Kinetic card Jeffrey we can send you one. We have both standard Kinetics and Kinetics that have their OS on the card in flash. I’m not sure if we have a 256MB SODIMM but we certainly have 64MB & 128MB n.b. 256MB SODIMMs needs 4.39 in ROM! if interested email me at chris@cjemicros.co.uk

If you want the loan of a Kinetic card Jeffrey we can send you one

Thanks for the offer; I might take you up on that at some point. But for the moment I think I’ve got enough other things to keep me busy.

Getting back on topic, I think I’m done with the compressed ROM work. I just need to wait for the all-clear to be able to check everything into CVS.

5.18 is out of the door so I think you’re safe to start hammering CVS again… ;)

Yep; I checked in the source changes over the weekend. Sometime in the next day or two I’ll check in updated tool binaries (softload tool & rompress), and enable compression for the OMAP & Tungsten ROMs (With the Tungsten ROM size bumped up to 5MB, since there’s under 5K of space left at the moment).

Unless anyone has any objections, I’ll go down the route of only doing the ROM compression during the release_autobuild stage. That way people building ROMs for local testing won’t have to put up with longer build times or having to manually decompress the ROM to look at the disassembly, etc.

Unless anyone has any objections, I’ll go down the route of only doing the ROM compression during the release_autobuild stage. That way people building ROMs for local testing won’t have to put up with longer build times or having to manually decompress the ROM to look at the disassembly, etc.

That sounds sensible to me, ta. Could you also set up the OMAP3Live build to be compressed?

All done.

There wasn’t an OMAP3Live autobuild script in CVS, so I’ve set up a simple one based around the existing OMAP3Dev one. So you’ll probably want to tweak the readme a bit once the live image is ready to go live, so to speak.

If anybody would like to try out my efforts let me know and I’ll email you a copy. Some feedback would encourage me to pursue this :)

Andrew, I’d be interested in giving this !Boot a whirl. Could you email me on w.blatchley AT yahoo DOT com ? Cheers!