> Sam.A2Docn.Memory


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
  Valid page numbers are 0 .. (R1-1), and the total memory in the
  machine is R0*R1 bytes.

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.
