#: 11572 S10/OS9/6809 (CoCo)
    01-Aug-91  10:36:23
Sb: #11571-Timer Thoughts
Fm: Kevin Darling 76703,4227
To: Kevin Darling 76703,4227 (X)



  "(Okay here's another place we need help with: we can use SWI or SWI3 as the
Tandy books says on 8-37, right?  Just stay away from SWI2? What should be "in"
the "user software interrupt routine" pointed to by register X when the F$SSWI
is issued?  Do we use RTI or RTS when ending this routine?)"

Alright, more detail: a SWI/SWI3 causes the 6809 to stack the current register
values.  SWI also sets the I and F interrupt flags, if that matters to y'all.
Then OS-9 maps in the system, jumps to the SWI/SWI3 vector, and that simply
jumps back to the _last_ user process map at the offset set by previous F$SWI
with the SP still pointing at your SWIx stackframe.  The kernel is now done.

Your user process now can look up parameters from the stacked register values,
and of course to return it can do either a RTI or drop most of the stack and do
an RTS.  This all assumes the user process does the SWI/SWI3 tho.

  "Well let's say once the timer interrupts, we "know" it's "us" who needs to
respond.  What to do?  Remember we're in system mode at this point, and the
user pgm probably is nowhere mapped-in right now.  In order to call the user
pgm's F$SSWI vector, we must "become" that task by saving then poking D.Proc
with the id of that task.  Then we can issue a matching SWIn 6809 instruction
right then & there.  Right?"

Sorry, the SWI/SWI3 stuff isn't quite that fancy (see above)... and if you did
one from a driver, then ummmm... maybe you could by with it if you did the
change to D.Proc and also an F$SetTsk to set up the user DAT mapping. Oh, and
also set up the P$variables such as the process timeout etc.

Ooops.  You'd be leaving the system set up for system state stuff tho, and a
stackframe on the system stack.  That might still be okay... not sure. Hafta
look.  In any case, I'd go for a driver right now and wait on F$SWI stuff... it
wasn't meant for this kind of thing. - kev