Extending RO3.1 OS_DynamicArea

[JonAbbott]

I'd suggest the following in the QTM shim modules:

Module init - Create a 0 byte DA
Module exit - Delete DA
Music load - Change DA to required size

ADFFS will handle reserving the max DA size if there's the potential for memory to overlap - which will be 16mb machines only. You don't need to track that or worry about it as it will be transparent. ADFFS will basically set a reserve level on the DA to ensure it doesn't resize down.

If possible allocate the bare minimum, but it sounds like you have the same problem I had with APD's where you don't know what size it will be. For APD's its allocating 900K and handing back any that's not used.

Try to avoid creating/removing the DA if the shim is still loaded as there's the potential for the memory to become slack if we implement anything that needs a 3rd DA. You can always set it to 0 and hand memory back if required.

One issue we will have is allocating memory whilst games are running in BASIC, for ADFFS I got around this by implementing *ADFReserveMemory. I'd suggest implementing something similar in the shims so memory can be pre-allocated during the boot script. To implement this you can either just allocate X bytes and track the fact its reserved, or we could implement a new SWI so you can tell ADFFS to handle the reservation.

Regards implement a new SWI, we could of course add a secret value to a register and call OS_ChangeDynamicArea with the delta to get to the reservation level - this would be more future proof as under ADFFS it could implement the reserve and on RO3.5+ it would simply allocate the correct amount. Obviously you'd have to ensure it never reduces though as ADFFS won't be handling it if it's RO3.5+

Hopefully all that makes sense!

[JonAbbott]

FYI This change seems to have broken ADFFS on RO3.5+, I'll try to get it fixed this week.

[JonAbbott]

FYI This change seems to have broken ADFFS on RO3.5+, I'll try to get it fixed this week.

Now fixed, module and source on dev site.

[JonAbbott]

I've had an email from Steve, who's tested ADFFS on a 16MB Arc and confirmed the same error I see under emulation when mounting floppies under the Wimp.

Having quickly checked the code (swi_OS_DynamicAreaRO31x), there's an outstanding action on my part to cap Appspace to 12MB.

Although I've not looked in detail, from the testing I've done today, ADFFS works correctly if the Wimp isn't loaded, so I believe the Wimp is swapping out all memory from 0-16MB when task switching - when it should be swapping out Appspace only.