Re: Extending RO3.1 OS_DynamicArea
Posted: Thu May 16, 2013 6:33 pm
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!
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!