🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.6809
Article #665

Re: System calls

#665
From: Kent D. Meyers
Date: Sat, 10 May 1986 20:59
56 lines
3091 bytes
 ingoldsby@calgary.UUCP (Terry Ingoldsby) writes:

>...  Are OS9 system calls allowed within the interrupt service routine
>of device drivers, ie.  the routine which executes when a device causes
>an interrupt.  The reason that I ask this question is because it would
>be convenient to debug device drivers by putting output statements in the
>interrupt driven routines.  Attempts to do this have not been successful.

 And dibble@rochester.ARPA (Peter C. Dibble) replies:

>System calls are legal in interrupt routines.

But,

>If you do I/O you will find that system state processes use system
>path numbers.

The path numbers that user processes see and employ are not the true
path numbers, but simply pointers to a sixteen byte (0-15) path table
which is local to each process. The following code will return the true
(System) path number for a running process' standard error path in ACCA:

  LDX  >D.PROC  Get Process Descriptor Address
  LEAX P$PATH,X Point to Path Table
  LDA  2,X      Get True Path Number

Standard Input (Path #0) would be at an offset of 0,X and Standard Output
(Path #1) would be at an offset of 1,X.

This translation is handled internally by IOMan for all user processes and
is completely transparent to the user. But device drivers and interrupt
handling routines run in the System State and access IOMan through a 
different set of vectors.  These entry points use the path number passed
in ACCA directly without doing the translation, assuming that it is a valid
System Path number. And that is what causes the problems! You must somehow
pass the true System Path to the routine.

Another approach for passing debug information from a device driver is to
utilize a part of memory which is invisible to OS9. The OS9 bootfile begins
loading on an even page boundary, but the chance that it will end precisely
at the last byte of a page is very slim indeed. This leaves an unused
in the range of 1 to 255 bytes. The start of this area is defined by
D.BTHI at locations $0068-69 on the Base Page.

So you have two ways to go. If you wish to use I/O calls in the driver or
interrupt handler itself, you can pass the System Path number via this 
protected memory. Or you can have the driver save its information in this
area for later retrieval by the test program.


Kent D. Meyers
PO Box 266
Le Roy, MN 55951

(507)-324-5836 (After 8:30PM CDT)              Net> ihnp4!chinet!draco
Technical Details
Message-ID: <324@chinet.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!linus!philabs!cmcl2!harvard!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!chinet!draco
References: <103@vaxb.calgary.UUCP> <17844@rochester.ARPA>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!linus!philabs!cmcl2!harvard!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!chinet!draco
From: draco@chinet.UUCP (Kent D. Meyers)
Newsgroups: net.micro.6809
Subject: Re: System calls
Message-ID: <324@chinet.UUCP>
Date: Sat, 10-May-86 16:59:14 EDT
Article-I.D.: chinet.324
Posted: Sat May 10 16:59:14 1986
Date-Received: Wed, 14-May-86 06:34:34 EDT
References: <103@vaxb.calgary.UUCP> <17844@rochester.ARPA>
Reply-To: draco@chinet.UUCP (Kent D. Meyers)
Organization: chi-net, Public Access UN*X, Chicago IL
Lines: 56
Keywords: Device Drivers