29.12.2012 Views

The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...

The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...

The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

ahead interrupt task bypasses this entry <strong>to</strong> inhibit calling @KITSK from the interrupt<br />

routine). <strong>The</strong>refore, if you want <strong>to</strong> interface a background routine that does disk I/O,<br />

you must chain in<strong>to</strong> @KITSK<br />

<strong>The</strong> interfacing procedure <strong>to</strong> @KITSK is virtually identical <strong>to</strong> that shown for Boot<br />

Initialization ICNFG Interfacing (except that FLAGS+31 through FLAGS+33 is used <strong>to</strong><br />

reference the @KITSK vec<strong>to</strong>r) and will not be repeated here. For the sake of clarity, you<br />

may want <strong>to</strong> write your background routine <strong>to</strong> start with:<br />

START CALL ROUTINE ;Invoke task<br />

LINK DB 'Roy' ;For @KITSK hook<br />

ROUTINE EQU $ ;Start of the task<br />

.<br />

RET<br />

Now that the procedure has been demonstrated, be aware of one major pitfall. <strong>The</strong> @KBD<br />

routine is invoked from @CMNDI and @CMNDR which is in SYS1/SYS. This invocation is from<br />

the @KEYIN call which fetches the next command line after issuing the "DOS Ready"<br />

message. If your background task executes and opens or closes a file (or does anything <strong>to</strong><br />

cause the execution of a system overlay other than SYS1), then SYS1 will be overwritten<br />

by that system module handling your request). When your routine finishes, the @KEYIN<br />

handler returns <strong>to</strong> what called it - which was SYS1. Unfortunately, SYS1 is no longer<br />

resident. You have just crashed the system!<br />

ANY TASK CHAINED TO @KITSK WHICH CAUSES<br />

A RESIDENT SYS1 TO BE OVERWRITTEN MUST<br />

RELOAD SYS1 PRIOR TO RETURNING.<br />

Okay, how do you accomplish this without knowing system code (point of information: if<br />

you are writing background tasks, you are writing system support code!)? You will be able<br />

<strong>to</strong> use the following code <strong>to</strong> reload SYS1 if SYS1 was resident prior <strong>to</strong> your task's<br />

execution.<br />

ROUTINE LD A,@FLAGS ;Get flags pointer<br />

RST 40 ; in<strong>to</strong> register IY<br />

LD A,(IY-1) ;P/u resident over-<br />

AND 8FH ; lay and remove<br />

LD (OLDSYS+1),A ; the entry code<br />

.<br />

Rest of your task<br />

.<br />

EXIT EQU $<br />

OLDSYS LD A,0 ;P/u old overlay #<br />

CP 83H ;Was it SYS1?<br />

RET NZ ;Return if not else<br />

RST 40 ;Get SYS1 per reg A<br />

; (no RET needed)<br />

Another method is <strong>to</strong> determine if the keyboard request originated from the command<br />

interpreter. While the command interpreter is fetching its command line via @KEYIN , it<br />

sets bit-2 in the CFLAG$ (see @FLAGS SuperVisor Call). Thus, if your KITSK routine<br />

discovers that bit set, then the command interpreter originated the line input. If you<br />

cause the system <strong>to</strong> load some other overlay in<strong>to</strong> the system overlay region, it is your<br />

responsibility <strong>to</strong> res<strong>to</strong>re SYS1!<br />

8-25

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!