DA in Application space on a 16mb RO3.1 machine

Discuss ADFFS development and download test releases
Post Reply
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

DA in Application space on a 16mb RO3.1 machine

Post by JonAbbott »

Pre-allocating memory when there's more than 14mb in Application space isn't straight forward, due to the overlapping address space. A possible solution is:

Increase an official RO DA to 2mb (to ensure the top 2mb of application space isn't mapped)
Allocate 2mb to ADFFS
Decrease RO DA back to it's original size

Which DA to use though, System heap/stack seems the least intrusive.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: DA in Application space on a 16mb RO3.1 machine

Post by steve3000 »

Humm, that'll use 4Mb of someone's nice 16Mb machine... Ah well, I suppose they can afford it ;-)

Yes - system heap/stack would be the one to use - no game is going to place a requirement on its size and it goes up to 2Mb doesn't it?
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: DA in Application space on a 16mb RO3.1 machine

Post by JonAbbott »

steve3000 wrote:Humm, that'll use 4Mb of someone's nice 16Mb machine... Ah well, I suppose they can afford it ;-)
Only 2mb, as it will reduce the RO DA after it's allocated to ADFFS. And even then, it will only need to do this if 2mb hasn't already been allocated.

The only reason to allocate the memory in this way is to ensure there's no memory mapped at the top of the Application space. It's highly unlikely this will be the case anyhow, as with that much memory you'd probably have all the DA's maxed or at least set. If you have a network stack, you'd lose 1.5mb anyhow, so 2mb is easily consumed.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: DA in Application space on a 16mb RO3.1 machine

Post by JonAbbott »

Right...the plan is:

All calls to OS_DynamicArea (0) must have R5 set (maximum size of area) or they'll be rejected. OS_DynamicArea will then map memory away if required to ensure there's no memory in the area, which ends at the 16mb boundary and grows downwards by maximum area size on each DA allocation.

I won't be implementing any of the service calls as I don't believe they're required for our needs and it would be a lot of coding anyhow.

I will only implement OS_DynamicArea (0) and (1), the others won't be required as we don't need to enumerate or renumber DA's. (2) which returns information on a DA isn't required as we'll be tracking our own DA's anyhow - unless you want it coded of course.

There would be an issue should we have for example 3 DA's and the 2nd is removed, as it would leave a hole and potentially allow Application space to overlap the 3rd DA. This won't be an issue in our case, as we're only using DA's for ADFFS and QTM shims. Just something to be aware of.

EDIT: Forgot to add that OS_DynamicArea (0) must have R1 and R3 set to -1, so the DA number and logical address are allocated by ADFFS.
OS_DynamicArea 0
Creates a new dynamic area

On entry
R0 = 0 (reason code)
R1 = –1 (or new area number not in range 128 - 255; this is reserved for Acorn use)
R2 = initial size of area, in bytes
R3 = –1 (or base logical address of area; this is reserved for Acorn use)
R4 = area flags (see below)
R5 = maximum size of area, in bytes (–1 = total RAM size of the machine)
R6 = pointer to dynamic area handler routine (see page 5a-45), or 0 if no routine
R7 = pointer to workspace, passed in R12 on entry to dynamic area handler routine;
or –1 for RISC OS to instead pass base address of area; or 0 if R6 = 0
R8 = pointer to null terminated string describing dynamic area (e.g. ‘Font cache’)

On exit
R0 preserved
R1 = allocated area number
R2 preserved
R3 = specified or allocated base address of area
R4 preserved
R5 = specified or allocated maximum size of area
R6 - R8 preserved
Post Reply