iarocci@eneevax.UUCP (John Iarocci) (06/23/87)
Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS calls recursively? 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? 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. ------------------------------------------------------------------------------- | Bill Dorsey 'Imagination is more important than knowledge.' | | - Albert Einstein | | 'He who has imagination without learning has wings and no feet.' | | - Joubert | | ARPA : iarocci@eneevax.umd.edu | | UUCP : [seismo,allegra,rlgvax]!umcp-cs!eneevax!iarocci | -------------------------------------------------------------------------------
fischer-michael@YALE.ARPA (Michael Fischer) (06/24/87)
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>
-------dyer@atari.UUCP (Landon Dyer) (06/25/87)
in article <955@eneevax.UUCP>, iarocci@eneevax.UUCP (John Iarocci) says: > 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. The BIOS, XBIOS and GEMDOS are not re-entrant -- TOS is not a multitasking operating system. The functions below the trap handlers (which use temps in memory, twiddle bits in the hardware and so on) would have serious problems if they were called on multiple threads. -- -Landon Dyer, Atari Corporation {sun,amdcad,lll-lcc,imagen}!atari!dyer The views expressed here do not necessarily reflect those BUSINESS of Atari or the AI software that has taken over my brain. IS Yow! I am waiting for my warranty-expired interrupt! HELL
apratt@atari.UUCP (Allan Pratt) (06/25/87)
in article <955@eneevax.UUCP>, iarocci@eneevax.UUCP (John Iarocci) says: > I'm writing a multi-tasking kernel, and trying to find > a safe way ... > > | Bill Dorsey 'Imagination is more important than knowledge.' You sure are imagining... There are no safe ways to do *anything* with the current GEMDOS in terms of a multi-tasking kernel. If you want it, buy Beckmeyer or write your own OS. It can be done (we're considering it) but it ain't easy, and it is IMPOSSIBLE to force this on the current GEMDOS. How did Beckmeyer do it? He wrote his own OS. Sorry, kids. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/ (APRATT on GEnie)
iarocci@eneevax.UUCP (John Iarocci) (07/06/87)
In article <767@atari.UUCP>, apratt@atari.UUCP (Alan Pratt) says: > I'm writing a multi-tasking kernel, and trying to find > a safe way ... > > | Bill Dorsey 'Imagination is more important than knowledge.' >>You sure are imagining... There are no safe ways to do *anything* with >>the current GEMDOS in terms of a multi-tasking kernel. If you want it, >>buy Beckmeyer or write your own OS. It can be done (we're considering >>it) but it ain't easy, and it is IMPOSSIBLE to force this on the current >>GEMDOS. How did Beckmeyer do it? He wrote his own OS. Sorry, kids. >> >>/----------------------------------------------\ >>| Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. >>| reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt >>\----------------------------------------------/ (APRATT on GEnie) Maybe I was really imagining when I bought my ST and expected to be able to get technical support on occasion! The last thing I expected was a statement that what I want to do is impossible when it has already been done (micro- RTX). Of course, the, "Sorry kids," reference didn't help my self-esteem any either. By the way, Allan, I believe Mr. Beckemeyer did not re-write the BIOS, XBIOS, and GEMDOS routines in his Micro-RTX package. I am told he uses the existing OS functions, simply not allowing a context switch while the processor is in these OS functions. Therefore, there would appear to be no need to re-write the entire OS. Thanks again for the informative tips. ------------------------------------------------------------------------------- | Bill Dorsey 'Imagination is more important than knowledge.' | | - Albert Einstein | | 'He who has imagination without learning has wings and no feet.' | | - Joubert | | ARPA : iarocci@eneevax.umd.edu | | UUCP : [seismo,allegra,rlgvax]!umcp-cs!eneevax!iarocci | -------------------------------------------------------------------------------