3.2             **      Processor-Traps

 

The QDOS specific traps are used as follows:
 

• Trap #0         Enter the processors Supervisor Mode..
• Trap #1         Manager Traps, System maintanance, Memory management.
• Trap #2         I/O-(De-)Allocation.
• Trap #3         I/O-Usage.
• Trap #4         A0/A1 rel(A6) addressing.
• Trap #5 ... #15

User definable Trap calls. can be linked into the system with MT.TRAPV.

   

3.2.1   *       Trap #0

A service routine to safely entering the supervisor mode.
No parameters received nor expected.
The current stack pointer (SP) will point to the supervisor stack, if not already set.

The QDOS job scheduler, and thus all multi tasking, will be halted until return to the processors user mode, explicitely, or might be invoced once, each, by partially or non "atomic" routines, or by the different QDOS interrupts.

Another exception are those manager traps which do some re-scheduling, and any i/o-traps if being called with a finite timeout.

Re-scheduling manager traps:

MT.RJOB         4
MT.FRJOB       5
MT.SUSJB        8
MT.RELJB        9
MT.ACTIV      10 $0A
MT.PRIOR      11 $0B

An example for state independent routines, preserving the (new) arithmetic flags:
 

	move.w	sr,d0	fetch current state
	trap	#0	enter supervisor mode
	move.w	d0,-(sp)	store previous state
		... program in Supervisor Mode ...
	move.w	sr,-(sp)	store current status word
	move.b	2(sp),(sp)	fetch previous processor state to psw
	move.w	(sp)+,(sp)	discard unused word
	move.w	(sp)+,sr	fetch current flags, return to previous state

 

The 1st statement might lead to problems with incompatible processors, such as 68010+ due to them inhibiting even reading the status word while in the user mode. That silly behaviour was changed back, later, but cannot be relied upon. Therfore the more recent QDOS provide an "exception handler" which transparently takes care of those events, at the only (rarely noticeable) penalty of slightly slowing down the routines concerned.

A forced return to the user mode can be coded

and.w #$dfff,sr

but should NEVER be done by setting the psw explicitely - which was found being a most "reliable" source of, often very bad, program faults. The QDOS interrupts are all controlled by the processor's level 2 interrupt, which always should be restored to its previous state, whichever. Explicitely or deliberately manipulating the interrupt bits on return of a supervisor routine might confuse the entire host system. The only one sensical interrupt setting would be on entry, only, and level 2 type, for instance:

or.w #$0200,sr

which can safely be restored no other than from the previously saved psw.
 
 

3.2.2                   *            Trap #4

This trap can be used pior to an i/o allocation trap or an i/o manipulation trap (traps #2 and #3), to modifying internal access to A0 (trap #2) or to A1 (trap #3) to A6-relative. Its main purpose is easy access to the SBasic A6-relative addresses.

The call does not receive nor return any parameters, and does not modify any registers. It will valid for the next one trap #2 or trap #3, only, and reset access mode back to "normal", afterwards. - With the exception of a trap #2 call returning with  the ERR.NO (-6) error {1}.

Some (old, pre 1.93) MINERVAe require the trap #4 call in the same stack level as the trap operation to follow.

 

3.2.3                   *            Traps #5 bis #15

Any of those traps can be assigned to some special routines, by the user, and linked into the system by MT.TRAPV (1/7).
Unused trap vectors should then point to an RTE address.
 

A1 => 00     Address Error
          04     Illegal Instruction
          08     Division by Zero
        $0C     CHK
        $10     TRAPV
        $14     Privilege Violation
        $18     Trace
        $1C     Interrupt Level 7 (e.g. CTRL/ALT/"7")
        $20     Trap #5
        ...       user definable until
        $48     Trap #15
        $4C     End of table

A1 of MT.TRAPV points to the beginning of the above table, with NO EMPTY entries.
All those vectors should point to some routine, ending with, or at least pointing to just an RTE code.

No registers will be changed when passed into those routines, except

A6 being set to the base address of the system variables, and
A7 pointing to the supervisor stack (SSP)

There is no register that always might be used freely, and left unrestored.
The SSP is NOT a reliable means of data reference because of the many possible stack frames with the different processors and different situations, being handled quite inconsistently by the several 680xx processors!
The exception trap routines in particular should save and restore any registers that are used.
Registers in traps #5 .. #15, excluding A6 and A7, can be handled as required.

There is an example in the F6 Forth source, and certainly many more in many other programs...

 

=