MEGGIN@vm.epas.utoronto.CA (David Megginson) (09/04/89)
Here is my modest proposal to bring some form of multi-tasking to the masses: The two multi-tasking systems currently available for TOS have not caught on because they are too difficult to use for non- programmers. What we need is a desk-accessory which will allow the simple user to run useful background programs. It should use dialogs and the file selector to manage processes, and should be smart enough to allow the user to enter parameters and environment variables. The accessory can either switch between applications using a timed interrupt, or switch every time there is an OS call. It should intercept all attempts to write to the screen using GEMDOS, XBIOS or BIOS and redirect them to files for all but the foreground program. It should kill any background process which attempts to use AES or VDI in any way (the user should not have tried to run them in the first place, but why not be more crash-proof?). Input should be handled in the same way (perhaps there can be some facility to pass input through the accessory). Messages from a process could also be displayed using alert boxes generated by the accessory. Setting priority, waking, suspending or killing processes should be handled in a friendly, GEM-typical manner in dialog boxes. Of course, a _really_ nice accessory would include a built-in chrontab. There is no reason that simple multi-tasking cannot be as friendly as the desktop itself. An accessory like this could become a TOS standard, and if it's good enough Atari might even make it official. BITNET: David Megginson <meggin@vm.epas.utoronto.ca>
glk01126@uxa.cso.uiuc.edu (09/06/89)
Can't that Switcher type program be modified to use a timer interrupt to do this? -Spieu!
daveh@cbmvax.UUCP (Dave Haynie) (09/06/89)
in article <8909040249.AA18031@ucbvax.Berkeley.EDU>, MEGGIN@vm.epas.utoronto.CA (David Megginson) says: > The accessory can either switch between applications using a > timed interrupt, or switch every time there is an OS call. This is much more difficult than it might seem. I don't know much about GEMDOS, but I suspect that none of the function calls are re-entrant. That means that interrupt driven (transparent, etc) multitasking is out. The second problem is how to manage the global data areas that a program uses, but if you're willing to create a new kind of program that's designed for multitasking, this gets much easier. The example of Apple's Multifinder shows one case where an operating system not designed for multitasking can support a limited form of multitasking. Multifinder swaps tasks when a particular function call is made -- it's not likely safe to swap tasks on any function call in such a system. Once you get tasks running together, the next thing that's necessary is control of task access to shared resources. For example, it should be OK for any number of tasks to read a single file, but only one should write it. > BITNET: David Megginson <meggin@vm.epas.utoronto.ca> -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
larserio@IFI.UIO.NO (LarsErikOsterud) (09/07/89)
Excuse me !!! BIOS, XBIOS and GEMDOS can be called from within themselves !! I do this in many of my TSR program (even call GEMDOS inside BIOS !!!!) Lars-Erik / ABK-BBS +47 2132659 / ____ ______ Osterud / larserio@ifi.uio.no / /___ / ____________/ _______________________/ ____/ /
david@bdt.UUCP (David Beckemeyer) (09/07/89)
In article <8909040249.AA18031@ucbvax.Berkeley.EDU>
MEGGIN@vm.epas.utoronto.CA (David Megginson) describes
a desk accessory idea for multi-tasking TOS. See referenced
article for details.
This is exactly the kind of thing I was talking about with respect
to a "general audience" RTX application. So who wants to finance it?
I will dontate RTX to the project and I will make hacks as necessary
to add new functions if necessary. RTX probably has most of low level
task switching needed for such a desk Accessory.
So what do you say David, are you interested? Anyone? Somebody
that knows GEM write a nice App with RTX hooks. I'll help with
the system interface / design.
We don't need Atari to make this happen, although I think it's
foolish of them not to help us all do it.
--
David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have
Beckemeyer Development Tools | a breath mint."
478 Santa Clara Ave. Oakland, CA 94610 | Bart - "The Simpsons"
UUCP: {uunet,ucbvax}!unisoft!bdt!david |uace0@uhnix2.uh.edu (USENET Administration) (09/07/89)
In article <CMM.0.88.621125609.larserio@kyrre.uio.no> larserio@IFI.UIO.NO (LarsErikOsterud) writes: >Excuse me !!! >BIOS, XBIOS and GEMDOS can be called from within themselves !! >I do this in many of my TSR program (even call GEMDOS inside BIOS !!!!) > > Lars-Erik / ABK-BBS +47 2132659 / ____ ______ > Osterud / larserio@ifi.uio.no / /___ / >____________/ _______________________/ ____/ / EXCUSE ME!!!!!!!!!!!!!!! GEMDOS *is not* reentrant. If you are not using a semaphore on your GEMDOS calls, you *will* crash the system if it is called reentrantly. BIOS and XBIOS are only reentrant to 3 levels, so you are safe there, but you should still have some kind of 'counting' semaphore. - mike vederman Double Click Software -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Support BBS: (713)944-0108 | SHADOW | DC FORMATTER | DC UTILITIES | and others
apratt@atari.UUCP (Allan Pratt) (09/08/89)
larserio@IFI.UIO.NO (LarsErikOsterud) writes: >BIOS, XBIOS and GEMDOS can be called from within themselves !! >I do this in many of my TSR program (even call GEMDOS inside BIOS !!!!) This statement both incomplete and partly false. There are restrictions on re-entering BIOS and XBIOS, and YOU CAN NOT REENTER GEMDOS. You can *enter* GEMDOS (from BIOS, for instance) but if GEMDOS calls BIOS and your handler calls GEMDOS you will be in BIG TROUBLE. I can go into gruesome detail about why this is true, but face it: it only takes one non-stack-type access to bestow non-reentrancy, and there are a LOT of them when you're entering and exiting GEMDOS. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
david@bdt.UUCP (David Beckemeyer) (09/08/89)
In article <CMM.0.88.621125609.larserio@kyrre.uio.no> larserio@IFI.UIO.NO (LarsErikOsterud) writes: >Excuse me !!! >BIOS, XBIOS and GEMDOS can be called from within themselves !! >I do this in many of my TSR program (even call GEMDOS inside BIOS !!!!) > > Lars-Erik / ABK-BBS +47 2132659 / ____ ______ > Osterud / larserio@ifi.uio.no / /___ / >____________/ _______________________/ ____/ / I'd suspect that your TSR has to do something special to do this, no? You cannot just blindly make GEMDOS calls, while some foreground program was in the middle of a GEMDOS call. The standard GEMDOS has one, read one, basepage pointer to the currently running process. It resets the stack to a hardcoded address. GEMDOS also has a lot of static (hardcoded) variables and structures. This is *not* how you write re-entrant code. Programs that don't "know" they might be used re-entrantly cannot be expected to do the things your TSR must do to save and restore the GEMDOS context. While this could be done by some scheduler (probably something that the GEM task switchers must do), it isn't just built into GEMDOS (not that Atari ever claimed GEMDOS would do this). GEMDOS keeps one process Pexec/Pterm parent/child linked list. There cannot be muiltiple parents without hacking. You cannot run a program that makes GEMDOS calls, suspend that program while in the middle of a GEMDOS call, and run another program which makes a GEMDOS call, and expect that the first program will still work, unless you know what context information internal to GEMDOS must be saved and restored. GEMDOS can be called re-entrantly *if* in my program I remember to save all important GEMDOS data areas (including the stack), and put it back the way it was when I'm done. That's a lot different from saying GEMDOS is re-entrant. -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." 478 Santa Clara Ave. Oakland, CA 94610 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
larserio@IFI.UIO.NO (LarsErikOsterud) (09/08/89)
Yes, its very easy to do.... First you intercept the normal BIOS/GEMDOS/XBIOS vetctor, then you changes the returnadress on the stack and do what you want, and jump to the call, when return you can do somthing else (in user-mode) and then you can jump to the normal program than called the GEMDOS. Have a small program that fixes redirection of I/O. (> file.ext) for all programs.... Will post it some day - its very handy for BBS-systems (LHARC does not have redirect built in) Lars-Erik / ABK-BBS +47 2132659 / ____ ______ Osterud / larserio@ifi.uio.no / /___ / ____________/ _______________________/ ____/ /
larserio@IFI.UIO.NO (LarsErikOsterud) (09/08/89)
Of course my TSR's save registers, status etc (I ripped this from the 1.0 ROM disassembly - it CAN be useful !) Lars-Erik / ABK-BBS +47 2132659 / ____ ______ Osterud / larserio@ifi.uio.no / /___ / ____________/ _______________________/ ____/ /
eezprandolin@qut.edu.au (09/10/89)
In article <7845@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <8909040249.AA18031@ucbvax.Berkeley.EDU>, MEGGIN@vm.epas.utoronto.CA (David Megginson) says: > >> The accessory can either switch between applications using a >> timed interrupt, or switch every time there is an OS call. > > This is much more difficult than it might seem. I don't know much about > GEMDOS, but I suspect that none of the function calls are re-entrant. That > means that interrupt driven (transparent, etc) multitasking is out. The > second problem is how to manage the global data areas that a program uses, > but if you're willing to create a new kind of program that's designed for > multitasking, this gets much easier. The example of Apple's Multifinder > shows one case where an operating system not designed for multitasking can > support a limited form of multitasking. Multifinder swaps tasks when a > particular function call is made -- it's not likely safe to swap tasks on > any function call in such a system. > > Once you get tasks running together, the next thing that's necessary is control > of task access to shared resources. For example, it should be OK for any > number of tasks to read a single file, but only one should write it. > >> BITNET: David Megginson <meggin@vm.epas.utoronto.ca> > -- > Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > Too much of everything is just enough Not Really, most people assume that re-entrancy is the only way of ensuring multitasking works, however there are other ways. 1. Trap AES calls and initiate all event waits from the M/T kernel distributing those events to all apps waiting. 2. Do not task switch while in Gemdos. This is easy in ROM systems the return address from the timer interrupt is FXXXXX ! ( this guarantees mutex on Gemdos ) 3. Add new messages for multitasking gem programs for disk I/O etc Given the kernel dispatches periodic event calls ( with timer ) the kernel can control all applications access to Gemdos. File locking can be implemented at a primative level by using the R/O flag. Using this method TOS will THINK that only the Kernel is running on the system each of the gem applications running will only be known to the kernel. Ie no two programs will use TOS at the same time (kernel controlled) applications calling the kernel/GEM (or is it TOS ?) can be identified by code segments or app id (as required) Many of us lose sight of the fact that GEM is a co-operative multitasking OS DA's are actually run round robin style and you can actually do things in your event loop ( if you call event timer (and event timer didn't have bugs :-) )) Therfore gem programs must be written to be co-operative MULTITASKING programs. This will ease integration considerably. If there is enough interest in the project I would suggest a council of sorts ,there are a lot of issues here, ( How to M/T Disk I/O , the dialog redraw/screen hogging problem and numerous others), Implementation of the Kernel is the EASY bit . BOB