🚀 go-pugleaf

    Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS
    calls recursively?

I've called a BIOS routine successfully from inside an RWABS handler, but I've
never been able to call a GEMDOS routine from there, presumably because
GEMDOS ==> RWABS ==> GEMDOS results in a recursive call on GEMDOS.  I'd
like to know how.

    I'm writing a multi-tasking kernel, and trying to find
    a safe way to allow multiple processes access to operating system functions.
    My understanding is that upon entry to the BIOS trap routines, registers
    are saved in savptr ($4a2).  However, the default save area contains enough
    room for only three levels of re-entrancy.  Can this situation be resolved
    simply by allocating a larger area of memory and setting savptr to point to
    it?

Yes, I think so, but I'm not convinced that that is the only problem.  I tried
expanding the save area once and the recursive call still crashed.  Of course,
maybe I didn't do it correctly...
    
    Also, does anyone know if any conflics may arise if a process were preempted
    in the middle of the BIOS, only to have another process make a BIOS call,
    possibly the same one that was interrupted?  The same question goes for the
    XBIOS and GEMDOS.  Thanks in advance for any help you can offer.

Interrupting a BIOS routine at an arbitrary point seems very unlikely
to work, The BIOS manipulates hardware control registers, then waits
for the actions to complete.  Interrupting in the middle would be
disasterous.  For example, if you interrputed a disk read between
the seek and the actual I/O operation and then did another read,
when you came back to the first one the head would be in the wrong
place.  To write a good multi-taksing kernel, you should rewrite
the BIOS to put the current task in an I/O wait state when I/O has
been initiated and then go back to the process scheduler to see
if another task can be run.  Completion of the I/O would then be
detected by an interrput rather than by busy-wait loops as in the
current BIOS.  The BIOS itself would then have to worry about how much
concurrency to permit and how to schedule multiple requests.  Short
of a complete rewrite, your best bet is probably to set a lock when
the BIOS is entered and to make sure not to switch tasks while the
lock is set.  The same thing will probably also be needed for calls
to GEMDOS, XBIOS, and perhaps also VDI and AES or at least the line A
graphics routines.

Then there is the memory fragmentation problem.  While you can write
your own memory manager, TOS will continue to use its own Malloc,
unless of course you *replace* the GEMDOS version with your own
and TOS is clean enough to always go through the trap vector when
calling GEMDOS functions.

Doing a multi-tasking kernel right is a big job.  Modifying a system
like TOS to make it multitasking is perhaps even harder than starting
from scratch, especially without access to the sources.  Good luck!

--Mike Fischer
  <fischer@yale.arpa>

-------