jhenders@jonh.wimsey.bc.ca (John Henders) (01/15/91)
In <RALPH.91Jan14164600@orion.laas.fr>, Ralph P. Sobek writes: >The following line caught my eye. > > >I have already noticed this before with other programs. Why does a >background running program stop when one runs a TOS program such as >GULAM, and not when one runs a GEM program? Can this be avoided? > >I use FORMAT.ACC (Broddelformat) which unfortunately pauses when GULAM >is running, even if GULAM is just sitting there. > I think a lot of tos programs probably use Conin() to wait for input and this would effectivly stop any background process that was Gem-based from running. I think shadow works from the serial interupt, and therefor can over-ride anything that doesn't set the IPL higher. -- John Henders jhenders@jonh.wimsey.bc.ca Vancouver,B.C. or jhenders@wimsey.bc.ca or ubc.cs!van-bc!jonh!jhenders
steve@thelake.mn.org (Steve Yelvington) (01/15/91)
[ralph@laas.fr writes ... ] > The following line caught my eye. > > In article <20338@netcom.UUCP> seitz@netcom.UUCP (Matthew Seitz) writes: > | > | I prefer using STalker with Shadow. STalker without Shadow has two > | limitations: > | > | 1. Background downloading only works if the foreground program is a > | GEM program. > | If you run a TOS program, background downloading stops. > > I have already noticed this before with other programs. Why does a > background running program stop when one runs a TOS program such as > GULAM, and not when one runs a GEM program? Can this be avoided? Here's the deal: The ST basically has a single-tasking operating system. When a program is running, it has total control of the computer. GEM adds a gross and clumsy sort of multitasking capability. A GEM program is ``event-driven'' -- it usually knows how to respond to any of many possible events, such as a keystroke, a drop-down menu selection, etc. To accomplish this, a GEM application tells the operating system what event(s) it may be interested in, and hands control to GEM. Multitasking comes into play when GEM (actually the GEM AES Event Manager) has control of the system. It can dispatch event signals to more than one application. By cooperating, desk accessories can work in conjunction with primary applications. The DAs and the main program simply go to sleep (by calling the Event Manager) and wait for a ``wake-up call'' from GEM. In addition to physical events like a keystroke, an application can wait for a ``timer event''. This makes it easy to write a desk accessory that performs uploading and downloading in the background. The DA calls the Event Manager frequently, letting it parcel out bits of time to other applications. When it is activated, the DA checks the ST's serial buffers and processes any data that is queued up. But .TOS and .TTP applications such as Gulam, MicroEMACS, compilers, etc., aren't GEM applications, and they never hand control over to the Event Manager. They never ``go to sleep.'' If they want a keystroke, they don't bother with the Event Manager. Instead, they issue a direct call to the operating system that blocks other activity until it's satisfied. Therefore a DA such as STalker never has a chance to ``wake up'' and process background data. Fortunately, GEM isn't the only way to ``multitask'' under TOS. Another way is to take advantage of the ST's ``VBI queue,'' a list of routines that are executed every time the video display is redrawn -- about 60-70 times per second, depending on the monitor. VBI stands for Vertical Blank Interrupt. VBI routines are a little harder to write, which is why you don't see many of them, but they work the same way: They're ``awakened'' repeatedly and they have to do a little bit of work, then voluntarily ``go to sleep'' so the system can proceed. There are programs that perform background file transfers, spool printer output, etc., using the vertical blank interrupt, and they will work happily in conjunction with a non-GEM application. ---- Steve Yelvington / P. O. Box 38 / Marine on St. Croix, MN 55047 USA Editor of the MAST (Minnesota Atari ST Users) newsletter - $15/year INTERNET: steve@thelake.mn.org UUCP: plains!umn-cs!thelake!steve
jvt@its.bt.co.uk (John Trickey) (01/15/91)
In article <RALPH.91Jan14164600@orion.laas.fr> ralph@laas.fr (Ralph P. Sobek) writes: > >In article <20338@netcom.UUCP> seitz@netcom.UUCP (Matthew Seitz) writes: >| >| I prefer using STalker with Shadow. STalker without Shadow has two >| limitations: >| >| 1. Background downloading only works if the foreground program is a >| GEM program. >| If you run a TOS program, background downloading stops. > >I have already noticed this before with other programs. Why does a >background running program stop when one runs a TOS program such as >GULAM, and not when one runs a GEM program? Can this be avoided? > >I use FORMAT.ACC (Broddelformat) which unfortunately pauses when GULAM >is running, even if GULAM is just sitting there. GEM is multi-tasking (not in the unix way), TOS is not. As GEM does not have a scheduler which is interrupt driven it relies on calls to dispatch other processes. This gives the appearance of background running where in effect the background tasks are only run when the main application has made a GEM call (to get a char, update the screen etc) A shell uses only TOS calls so this cannot happen - hence no background tasks. However having said that, I notice that Mupfel occasionally allows my background clock to run. John -- John Trickey <jvt@its.bt.co.uk> || ..!mcsun!ukc!axion!its G4REV @ GB7SUT Voice: +44 21 333 3369 #include <std/disclaimer>