Memory Arrangement on the Psion 3a

The following information has been aquired by experimentation and interpretation of the documentation that has been freely released on the Internet, I can therefore not guarantee that it is correct.

Use it at your own risk.

General Memory Layout

The Psion 3a comes in various versions (512KB, 1MB and 2MB ROM). This amount of memory is not accessable as a whole to the NEC V30 (8086 clone), so it has been paged.

The lowest portion (0x0000:0 to 0x5FFF:F) of memory permanentely located, and contains in the Interrupt table, screen memory and presumabley the kernel data segment.

The next two segments are paged into the rest of memory, depending on the value set in A9BPageSelect6000 and A9BPageSelect7000. As the name suggests this is a byte register and setting it to 0x0A (for example) would make the memory range 0x6000:0 to 0x6FFF:F point to the 'real memory' at 0xA000:0 to 0xAFFF:F.

It appears that Psion originally planned for 4MB of RAM. If the PageSelect is set in the range of 0x20 to 0x3F the memory returns the address in the data, probably through week pull up/down resistors. Above 0x40 the memory repeats in blocks of 0x40, i.e setting 0x40 is the same as 0x00.

All memory accesses above 0x8000:0 are to system ROM. Segments 0x8000 and 0x9000 are paged (like the RAM), but seem to repeat in blocks of 0x20 (therefore only allowing 2MB of ROM.

Unfortunately (for us any way) the Page ROM Segments can not be made to point to the RAM and likewise the RAM page segements can't point to ROM. This will limit how the ELKS project will have to use the RAM.

The Rest of memory (0xA000:0 up) points directly to ROM.

Memory Managment.

We all know that a ELKS application will require two segments to execute (Code and Data), in the worse case these will both be fully occupied and therefore that application will require 128KB. This causes a problem as they will have to be aligned to a 64KB boundary to allow contiguous access.

As the Kernel Code and Data segments will be located in the low (fixed) memory a memory management system will have to be implemented to allocate, switch and handle the high memory. If the RAM is also being used for a RAM Disk then the memory manager will have to switch the pages inorder to load (or save) any files. (Perhaps this can be ignored for the time being and we can run soley from SSD's).

With SIBO the system memory is limited to 512K (PageSelect6000 and 7000 set to 6 and 7 respectively), this appears as a contiguous block. It has the advantage that most of the Code is located in ROM. I guess that the two page segments are used as a source and destiation to 'load' from the RAM disk.

Even with very crude memory management (i.e. allocating a whole 64KB segment) for each of the Code and Data segments, we would be able to have 12 processes running on the 2MB Psion (assuming no RAM disk) which only a little below the proposed limit of 15.

Memory Protection

The Psion 3a uses a very simple system for memory protection. Two limits are set (an upper and a lower), is an application writes outside theses an interrupt is generated and the EPOC OS halts the offending process.

I intend to use this as a simple check. It is also possible to check the settings for CS, DS and ES when a process is swapped out, to ensure that they aren't playing around. A watch dog timer is also present, which could trap crashed applications.