RISC OS 5 memory map

Can anyone tell me what the maximum Wimp slot can be on RISC OS 5 when running on machines with 1GB RAM like the PandaBoard? This old web page written at the time of the Iyonix, says that in 5.02 the RMA is at &20000000 which will limit the Wimp slot to 512MB, but it says that it is likely to move higher to allow Wimp slots of 1GB.

Was this ever done? On my Iyonix, running 5.16, doing *modules it seems from the addresses shown that the RMA is still at the 0×20000000 mark.

What is the maximum dynamic area size?

The reason is that I need to load about 450MB of data into RAM and work on it, and still have room for quite a big Wimp slot. I’d rather not be chopping the data into smaller areas as that will complicate things.

On my PandaRO with 1Gb RAM, the RMA is still at the 0×20000000 range, so it is probably still to be done.

On my PandaboardES and with RISC OS 5.21 (07-Mar-2014) I can drag the ‘next’ slot to a maximum of 524256k although there is still 360812k shown as free. But then after using this for TaskWindow *Basic (starting with 536834300 bytes free) I can then open another TaskWindow *Basic (starting with 301461756 bytes free) leaving a free Wimpslot of 59Mbytes as yet unused.

Yes, 512MB is still the maximum wimpslot size. I think it’s possible to change it just by tweaking the AplWorkMaxSize value, although you’d obviously have to build your own custom ROM.

What is the maximum dynamic area size?

Technically the absolute maximum size available for dynamic areas is &FA000000 (high address IO memory) minus &20000000 (high end of wimp slot) = &DA000000 = about 3.5GB. However you won’t be able to create a dynamic area that big because some of the memory will have already been claimed (e.g. 256MB is reserved for the maximum RMA size, 128MB for the RAM disc, and any other dynamic areas that are part of a normal system). There’s also the IO memory allocations, which are allocated from &FA000000 down and so eat into the available space for dynamic areas. Expect maybe 100MB to be lost due to that.

So the max size you could reasonably expect (as long as we don’t bump the wimpslot up in size) would probably be 2.5GB.

However, there’s also a per-dynamic area limit which the kernel enforces, in order to avoid all of the logical address space being claimed as soon as a program creates a dynamic area with no size limit. This limit is controlled by OS_DynamicArea 8, and for RISC OS 5 there’s a file somewhere in the boot sequence which (IIRC) sets the limit to 128MB. (On previous OS versions I think it just relied on the default size clamps – i.e. the amount of RAM that’s fitted to the machine)

As modern machines have more and more RAM, maybe a first step towards a more dynamic wimpslot max size would be to have a CMOS option to control how big it is (in, say, 512MB units). It would also be a convenient option for developers to use to check that there isn’t any code which is storing flags in the top bits of pointers (e.g. FileCore – so don’t go moving the RMA above 2GB just yet!)

A better option for address space sanity would be to implement relocateable DAs – whose base addresses can move as a result of a resize.

Non relocateable DAs (ie all existing ones) get clamped and stuffed down the bottom, relaocateable ones are only ever clamped by available memory as they (all) move around to enable resizing. Stick them up at the high end and force ptr cleanliness at the same time!