System memory map

I’ve been trying to get a picture of how the logical address space is laid out.

I wrote a program

REM >MemoryMap
REM Purpose: Print system memory map
REM License: Apache 2.0
REM Author: Julie Stamp
REM Date: July 2020
REM Version: 1.3

ON ERROR REPORT : PRINT ERL : END


REM Work out how many areas there are going to be

num_osmem% = FNnum_data(TRUE)
num_da% = FNnum_da(TRUE)
num_hal% = FNnum_hal(TRUE)
num_area% = num_osmem% + num_da% + num_hal%

REM Initialise area table

next_area% = 0
max_area% = num_area% - 1

DIM area_name$(max_area%)
DIM area_base%(max_area%)
DIM area_alloc%(max_area%)
DIM area_used%(max_area%)

REM Read in the OS_Memory areas

dummy% = FNnum_data(FALSE)

REM Read in the dynamic areas

dummy% = FNnum_da(FALSE)

REM Read in devices

dummy% = FNnum_hal(FALSE)

REM PROCdump_areas

PROCprint_sorted

END

DEF FNstring(s%)
LOCAL s$
  SYS "XOS_GenerateError",s% TO s$
= s$

DEF PROCadd_area(name$,base%,alloc%,used%)
  IF next_area% > max_area% THEN ERROR 0, "No more room in table"

  area_name$(next_area%) = name$
  area_base%(next_area%) = base%
  area_alloc%(next_area%) = alloc%
  area_used%(next_area%) = used%

  next_area% += 1
ENDPROC

DEF FNnum_hal(dry%)
LOCAL pass$, top%, second%, r%, enum%, device%, name$, base%, n%
  n% = 0
  REM Enumerate HAL devices
  IF dry% THEN
    pass$ = ", pass 1"
  ELSE
    pass$ = ", pass 2"
  ENDIF
  PRINT "Enumerating HAL devices"+pass$;
  FOR top% = 1 TO 5 STEP 1
   REM PRINT ".";
    FOR second% = 0 TO 255 STEP 1
      enum% = 0
      REPEAT
        REMPRINT top% second% enum%
        r% = (-1<<16) OR (top%<<8) OR (second%)
        REMPRINT STR$~r%
        SYS "OS_Hardware",r%,enum%,,,,,,,5 TO ,enum%,device%
        REMIF enum% <> -1 THEN   PRINT FNstring(device%!12) " : " STR$~device%!16
        IF (enum% <> -1) THEN
          name$ = FNstring(device%!12)
          base% = device%!16
          IF (name$ <> "") AND (base% <> 0) THEN
            IF NOT dry% THEN PROCadd_area(FNstring(device%!12),base%,0,0)
            n% += 1
          ENDIF
        ENDIF
      UNTIL enum% = -1
    NEXT
  NEXT
  PRINT""
= n%


DEF FNnum_data(dry%)
LOCAL num%, I%, A$
LOCAL base%, alloc%, used%
LOCAL DATA
LOCAL ERROR
  num% = 0
  ON ERROR LOCAL : = num%
  RESTORE
  REPEAT
    READ I%,A$
    PROCread_osmem(I%, base%, alloc%, used%)
    IF NOT ((alloc% = 0)) THEN
      num% += 1
      IF NOT dry% THEN PROCadd_area(A$,base%, alloc%, used%)
    ENDIF
  UNTIL FALSE
ENDFN

REM This is a multi-porpoise function,
REM when dry% = TRUE it just tells you how many DAs
REM there are, when dry% = FALSE it puts the enumerable
REM ones in to the area table
DEF FNnum_da(dry%)
LOCAL I%, da_number%
LOCAL name$, base%, alloc%, used%
  da_number% = -1
  I% = 0
  REPEAT
    SYS "OS_DynamicArea",3,da_number% TO ,da_number%
    PROCread_da(da_number%, name$, base%, alloc%, used%)
    REMPRINT da_number% name$ base% alloc% used%
    REM Don't put the free pool in
    IF (base% > 0) THEN
      I% += 1
      IF NOT dry% THEN PROCadd_area(name$, base%, alloc%, used%)
    ENDIF
  UNTIL da_number% = -1
  REM -1 tells you when the end of enumeration is,
  REM but it's also the app slot. But we've added one once
  REM through the loop each time so it works out
= I%

DEF PROCprint_sorted
LOCAL next%, found%, min%, I%, J%
LOCAL base%, alloc%, used%
LOCAL DATA
  PRINT "First", "Last", "Name"
  next% = 0
  FOR J% = 0 TO max_area% STEP 1
    found% = -1
    FOR I% = 0 TO max_area% STEP 1
      base% = area_base%(I%)
      alloc% = area_alloc%(I%)
      REMPROCread_area(I%, base%, alloc%, used%)
      REMPRINT "next" STR$~next% "base" STR$~base% "found" found% "min" STR$~min% "alloc" STR$~alloc%
      REMINPUT A%
      IF FNhs(base%,next%) THEN
        IF (found% = -1) OR (found% >= 0 AND FNhs(min%,base%)) THEN
          min% = base%
          found% = I%
        ENDIF
      ENDIF
    NEXT
    IF found% >= 0 THEN
      PRINT "&"STR$~area_base%(found%), "&"STR$~(min%+area_alloc%(found%)-1),  area_name$(found%)
      next% = min% + area_alloc%(found%)
      REM Devices have zero alloc, so nudge things on
      IF area_alloc%(found%) = 0 THEN next% += 4
    ENDIF
  NEXT
ENDPROC

DEF PROCread_osmem(I%,RETURN base%, RETURN alloc%, RETURN used%)
  SYS "OS_Memory",16 + (I% << 8) TO ,base%,alloc%,used%
ENDPROC

DEF PROCread_da(I%,RETURN name$, RETURN base%, RETURN alloc%, RETURN used%)
  IF I% <> -1 THEN
    SYS "OS_DynamicArea",2,I% TO ,,used%,base%,,alloc%,,,name$
  ELSE
    SYS "OS_ReadDynamicArea",I% TO base%,used%,alloc%
    name$ = "Application slot"
  ENDIF
ENDPROC


DEF FNhs(a%,b%)
  IF (a% >= 0) AND (b% < 0) THEN = FALSE
  IF (a% < 0) AND (b% >= 0) THEN = TRUE
= a% >= b%

DEF PROCdump_areas
  FOR I% = 0 TO max_area% STEP 1
    PRINT I% STR$~area_base%(I%), STR$~area_alloc%(I%), STR$~area_used%(I%), area_name$(I%)
  NEXT
ENDPROC

DATA 1, "Cursor/system/sound"
DATA 2, "IRQ stack"
DATA 3, "SVC stack"
DATA 4, "ABT stack"
DATA 5, "UND stack"
DATA 6, "Soft CAM"
DATA 7, "Level 1 page tables"
DATA 8, "Level 2 page tables"
DATA 9, "HAL workspace"
DATA 10, "Kernel buffers"
DATA 11, "HAL uncacheable workspace"
DATA 12, "Kernel 'zero page' workspace"
DATA 13, "Processor vectors"
DATA 14, "Debugger workspace"
DATA 15, "Scratch space"
DATA 16, "Page zero ""compatibility page"""

which when run on IOMD RISC OS 5.27 gives

*MemoryMap
Enumerating HAL devices, pass 1
Enumerating HAL devices, pass 2
First     Last      Name
&0        &3FFF     Kernel 'zero page' workspace
&4000     &7FFF     Scratch space
&8000     &1FFFFFFF Application slot
&20000000 &2FFFFFFF Module area
&30000000 &31FFFFFF System heap
&32800000 &32FFFFFF Screen memory
&33000000 &33FFFFFF System sprites
&34000000 &34FFFFFF RAM disc
&36100000 &364FFFFF Wimp_ClaimFreeMemory workspace
&36500000 &374FFFFF Wimp sprite pool
&37500000 &37CFFFFF Clipboard workspace
&37D00000 &3828FFFF ADFS Map (Drive 0)
&38290000 &3868FFFF ADFS Dir Buffer
&38690000 &3968FFFF PipeFS
&39690000 &3A68FFFF Toolbox
&3A690000 &3B68FFFF TextArea workspace
&3B690000 &3B69AFFF Theme resources
&3B69B000 &3BC2AFFF RAM Map (Drive 0)
&3BC2B000 &3C02AFFF RAM Dir Buffer
&3C02B000 &4002AFFF AWRender Crystal support
&4002B000 &4022AFFF Zap font cache
&4022B000 &4032AFFF LineEditor Buffers
&F8C00000 &F8BFFFFF Acorn VIDC20
&FA000000 &FA0FFFFF HAL workspace
&FA100000 &FA101FFF IRQ stack
&FA200000 &FA207FFF SVC stack
&FA300000 &FA301FFF ABT stack
&FA400000 &FA401FFF UND stack
&FA640000 &FA64FFFF Kernel buffers
&FA6E8000 &FA6EFFFF HAL uncacheable workspace
&FA800000 &FABFFFFF Level 2 page tables
&FAC00000 &FAC03FFF Level 1 page tables
&FAFF0000 &FAFF7FFF Cursor/system/sound
&FB000000 &FBFFFFFF Soft CAM

So:

1. I think ROM starts at &FC000000, but is there an OS call to find out how long it goes on for?
2. Is there anything higher than ROM? (I know on some systems the kernel workspace is at &FFFF0000)
3. There is a big gulf between the end of DAs (LineEditor buffers) and the start of devices (Acorn VIDC20). Does anything live there?

I think ROM starts at &FC000000, but is there an OS call to find out how long it goes on for?

If OS_ReadSysInfo 8 has the “OS runs from RAM” bit set, then you ought to be able to use OS_Memory 8 with flag 5 (so 8 + (5<<8) ) in order to read the space used by the ROM (or 8 + (3<<8) if it’s an actual ROM).
Note that the result isn’t a byte value, it’s a count of pages in R1 and the page size in R2 (probably 4096 bytes).

Is there anything higher than ROM?

I don’t think so, asides from high vectors. Unfortunately there doesn’t appear to be a memory map document.

There is a big gulf between the end of DAs (LineEditor buffers) and the start of devices (Acorn VIDC20).

First of all, expect to see huge gaps. The addressing range (&00000000 → &FFFFFFFF) covers 4GiB. The vast majority of machines do not have that. I think the “average” 32 bit amount is probably a gigabyte.
There may be huge gaps left around the Dynamic Areas to allow them to expand as necessary, Jeffrey will be able to better explain.
I don’t think, when trying to work out the memory map, that there’s much point in listing individual Dynamic Areas. Zap’s font cache will only appear if people are using Zap (or ZapRedraw), and it will probably be located in a slightly different place if you load it before AWRender, for example. Better, perhaps, to say “Dynamic Area space from X to Y”.

One thing I did notice, you don’t have any I/O space listed. Where’s the combi-I/O chip for IDE, floppy, serial, and parallel? You are using an IOMD machine, so where’s podule space? EASI space? The x86 co-processor? What about the IOMD devices (keyboard, mouse, IIC…)?

The RiscPC TRM is at 4corn. This should give you an idea where things may be located.

I can only find references to the old addresses such as IOMD at &03200000.
I think you’ll need to fiddle around to see where stuff actually is. OS_Memory 9 may help.

There’s a logical memory map in Kernel.hdr.KernelWS: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/Kernel-6_42/hdr/KernelWS#L244

So yes, currently the only thing above ROM is the high processor vectors (if enabled).

DAs are allocated address space starting from the bottom of the memory map, while IO memory is allocated from top down; so the gap between the end of the DAs and the start of the IO region is free space which one or the other could potentially claim.

You can use OS_Memory 8 to find how much IO address space has been allocated, but I don’t think there’s a call to tell you where the region currently starts.

I came across this thread again recently, and tried the MemoryMap program, as it looked useful. On This Titanium, running RO5.29, it shows nearly twice as many areas as the IOMD RO5.27 above. Shows how the OS has changed!

Then I looked at the program … and PROCprint_sorted struck me as rather complicated, and realised that it was because (a) the arrays were unsorted, and (b) the addresses are 32bit (ie can look negative to BASIC).

Thinking if my ArmSort was used, it could be reduced to just…

DEF PROCprint_sorted
  LOCAL J%
  *Sort 0 next_area% area_base%() area_alloc%() area_name$()
  PRINT '"First", "Last", "Name"
  FOR J% = 0 TO max_area%
    PRINT "&"STR$~area_base%(J%), "&"STR$~(area_base%(J%)+area_alloc%(J%)-1),  area_name$(J%)
  NEXT
ENDPROC

This stirred a plan from long ago to add an Unsigned sort facility to ArmSort … and lo, it is now added to v4.09, so if the above code is changed to…

  *Sort 0 next_area% area_base%(u) area_alloc%() area_name$()

So, thanks to Julie for a useful program, AND for provoking me to improve ArmSort.

One very minor bug: Any HAL devices show the Last address one byte before the First. This is because they get a base adddress but zero allocated length. I ‘fixed’ this by setting alloc%=1 so Last=First.
MemoryMap can be simplified further by over allocating the arrays so the ‘dry run’ can be avoided, and using elements 1 to num% instead of 0 to num%-1