SEPARATE USER/SUPERVISOR MODES
This when very important when advanced, fully protected operating systems are used. The User
program is usually in “User” mode. All the special (“Privileged”) instructions are only allowed
in “System” mode. This prevents a user writing code that causes a “whoopsie” in the system. In
user mods, the programmer is protected from modifying someone else’s data, or code. A program
jump to somewhere unknown does not the system. Instead, the system can return a message such
as “Not allowed, please try again… etc.).
System mode is used for all operating system code, where the special instructions are all
available (and hopefully de-bugged). Any transgressions by the user program are reported to the
system by “Trap” (see below).
An interesting by-product of this is being able to translate memory & I/O addresses, all
completely transparent to the user. If bit 2 of the trap control is set then any direct
I/O in user mode causes a “Privileged Instruction Trap”. The CPU jumps straight to the address
found at the contents of the “Interrupt/Trap vector pointer” +54H. Here we do the direct I/O
using en I/O conversion table, then return to the user program, using the new “RETIL” (return from
Interrupt long) instruction.
Similarly, the MMU can be “write protected” at a block of memory. Any access to this block of
memory causes a “Page fault Trap”. The CPU jumps straight to the address found at the contents of
the “Interrupt/Trap vector Table pointer” +4CH. Here we do the required address translation, or
anything else required, all transparent to the user, then return to the user program using the new
“RETIL” (return from Interrupt long) instruction.
It should be possible, using this method, to simulate my Z80 system. For example, Nascom 1/2
code can be made to run directly on the GM890 board, using the required I/O translation table and
256 BYTE CACHE
This I found was an extremely useful feature which considerably speeded up the running of the
program when it was in a short repeating loop. The cache is transparent to the user, it
continually loads instructions and date from the main memory during any time the processor
might have. This means that when the processor is ready to process its next instruction it takes it
from the cache rather than main memory thus cutting down on the number of external bus accesses.
The cache be enabled for data, instructions or depending on bits 5 and 6 respectively
of the “Cache Control register”. On reset, the cache is enabled instructions only. The PCACHE
instruction (purge Cache) invalidates the 256 byte on-chip cache. Instead of using the fast memory
as a cache, the 256 bytes can be used as 256 of extremely fast physical memory, so bus access
SEPARATE BLOCKS FOR PROGRAM, DATA & OPERATING SYSTEM
I have found when programming that due to the size and amount of variables I use that the data
takes up quite a lot of the 64K into which my complied code has to fit. Sometimes the data takes up
as much as half and then I still have to room for the run-time package. This then does not
leave a great deal of room for the program and what I generally have to do is split the program into
numerous parts and use overlays or chain to separate programs. How much better I have found this
new board, which allows me to have separate blocks each of 64K for the program, data and operating
system. This board also allows me to have more than one program block each using the same data
block. This feature is not enabled on reset. It must be enabled on the MMU.
THE INTERRUPT/TRAP VECTOR TABLE
The I/T vector table consists of of Master status register and Program counter words, one
pair for each interrupt or trap source.
The CPU contains an additional register, the “Interrupt/Trap Vector Table Pointer”. This
contains the top 12 bits of the physical address of the contents of the “Interrupt/Trap Vector
Table”. Any interrupt or trap, finds the address of its service routine from this table.