There are various changes to Arthur's dealings with the memory map.

SWI OS_ChangeDynamicArea has some changes:

Reason code 3 means change the size of the common sprite area.

The SWI now passes round a service call (Service_MemoryMoved [&4E]) at the end, immediately before the SWI returns. This service is always offered regardless of whether the call has done anything or not.

Bugfixes:

The value of r1 in the Service_Memory call has been corrected; it never used to be negative (i.e. it always indicated that the application space was about to be enlarged).

Out-of-range area numbers are rejected, instead of the SWI crashing.

Memory Map bashing

Arthur 2 has facilities for doing your own memory mapping. Fairly obviously, these are intended only for sophisticated users!

The memory consists of a numbered set of chunks, all the same size. These are referred to as "pages". These can be put at any pagesize-aligned address in the range 0-32M.

SWI OS_ReadMemMapInfo
Returns the page size in R0

          the number of pages in R1

SWI OS_ReadMemMapEntries
R0 pointer to list of 3-word entries, terminated by -1 Returns the list with each entry updated: word 1: page number (unchanged)
word 2: address page is mapped to
word 3: protection level. Only the bottom 2 bits are currently used;

          all others should be clear for future expansion. Meaning of the
          bits: 00 = readable & writeable by everybody
                01 = read-only in user mode
                10 = inaccessible in user mode

SWI OS_SetMemMapEntries
R0 pointer to list of page/address/protection level triplets, terminated by -1.

Any address > 32M means "put the page out of the way"; this also automatically sets the protection level to the minimum accessibility.

This SWI assumes you know what you are doing; it will move ANY page to ANY address, with no checks at all.

MOSes with this SWI also have another reason code for ChangeEnvironment, to allow setting of the application workspace size; if you have changed this (especially if you have shrunk the area), either be careful about what you let Arthur do, or update it's internal copy. The simplest form of "being careful" is stopping ChangeDynamicArea from ever doing anything; anything else needs an understanding of ChangeDynamic's view of the world, which (simply stated) is that it knows where all the continuous areas of memory are, and it knows their size. (This is also the view of SWI OS_ValidateAddress, so making it invalid will potentially lead to data aborts in places where a hard reset is needed to recover (e.g. OS_Fileing off ADFS).

Note that any users of these SWIs should not need to do anything on soft reset; the MOS tracks down any pages not in a sensible place and forces them into a continous application space.