Scor­pio News

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 screen driver.

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 is required.

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.