Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 400
Info-Atari16 Digest Monday, August 21, 1989 Volume 89 : Issue 400
This weeks Editor: Bill Westfield
Today's Topics:
Re: Multitasking on the ST
Re: Multitasking on the ST
Re : Names for ST's
Re: Meg upgrade.
Re: Curses for the ST
Re: Meg upgrade.
Re: Multitasking on the ST
Re: quickst, bigscrn
Re: VIP AND KUMA, HOW DO THEY COMPARE?
Re: Multitasking on the ST
----------------------------------------------------------------------
Date: 12 Aug 89 16:39:09 GMT
From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM ()
writes:
|In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
[]
|>I think two issues are being confused here, the need for per process
|>memory protection, and the possible to run processes 'simultaneously'.
|>Why should memory protection be a hotter item when parallel processes
|>are involved?
|
|Because of the potential for a single user program to cause the termination
|of all the processes in the system.
This is equally well possible in the current 'one-process-running-at-a-time'
scheme. Note that there are already accessory-based editors, batch
modem transfer programs, TSR print spoolers for the ST right now.
|Consider: You are a user of the Spiffy multi-tasking-but-no-
|per-process-memory-protection Machine. You fire up a ray-trace.
[etc. good example left out]
|
|On a machine with memory protection (OK and resource tracking) the MMU will
|prevent corruption of other processes address space, and the nasty process can
|be removed from the system cleanly.
I think you'll need a bit more than just an MMU for a secure system.
S'pose your nasty process alters some system vector (applying patch 271
to SAFEDOS). A pity that the last bug was not yet removed... My point
is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE
EXCELLENT SYSTEM. That safe system (which undoubtedly will have a
notion of privileges, users) is what you should start with in the first
place.
B.T.W. what do you do when a thunderstorm is coming up, but your
raytracer has yet to finish its last hour of calculations? Use a TMU :-) ?
[]
|I'm all for system robustness for ANY system. My point is that when you
|introduce multitasking, memory protection is more important due to the
|potential to disrupt other processes.
I heard this one before and I still won't believe it, unless a proper
argument is given.
|>[about VM]
|
|Sounds Good! But now you're wandering into the area of virtual memory and
|that's not what our original discussion was about. Thanks for the reply.
You bought an MMU but you don't want VM? Gee, that would be the first
reason I would buy an MMU for (and not for protection). As long as the
filesystems used are single-user, not write protectable, I don't care
much for safe core.
Leo.
------------------------------
Date: 12 Aug 89 14:26:05 GMT
From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg
Wageman) writes:
|In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
[some stuff left out]
|> If a process does a call that may involve some time, like
|>reading a character from the keyboard (Cconin(), Cnecin()), this
|>process only continues its call when there is a character available, so
|>it will not unnecessarily block other processes.
|
|Will you be trapping these interrupts so that you can potentially
|unblock tasks waiting on them?
Not quite, but to the same effect. What in fact happens, is that before
the process enters the real GEMDOS function (the handling of Cconin or
whatever) but after its context has been saved on its basepage and
stack, the system will look at what process to continue with (of course
this could just as well be the same process). Processes that are
waiting for some state change like a character from the keyboard
becoming available, or the printer being ready to receive further data,
are marked that way and will only be selected if the state they're
waiting for changes (the test for the changed state is just a simple
index comparision in most cases). Calls that can be safely assumed to
complete within a reasonable amount of time are not marked waiting
(although one could perhaps win something by switching out a process
that wants to write to disk when the disk is not yet available).
When no waiting processes can be served (no state changes) the other
processes are searched for the least served one (processes have a
priority and a 'serviced' number).
A few problem calls remain: Cconrs(), which reads an entire line from
the keyboard. One can at best test for the first character being
available, but the user could still take indefinitely to complete his
line. Shells that do command line editing, history completion etc.
generally won't have a problem, since they typically process their
input character by character. A solution would be to rewrite Cconrs()
to be re-entrant (no problem since I recently patched Cconrs() to
handle a history mechanism, command line editing and file name
completion).
[]
|I must admit the idea sounds like it has merit. However it's easy to
|try something like this when blissfully unaware of the pitfalls. The
|biggest one I see is that GEMDOS itself is not written to be
|re-entrant.
Sure, but a) GEMDOS is not being re-entered and b) in a special way,
GEMDOS IS re-entrant. After these stunning remarks, I'll have to make
myself clear 8-):
Consider a series of programs that call each other by a Pexec(), for
instance a shell starts make, which starts a compiler, which ...
Note that each of them only returns from their Pexec after the Pexec'ed
program has finished. That program probably did a lot of GEMDOS calls
---> there you have your re-entrancy (in a special way). The whole trick
is that, while one process cannot re-enter GEMDOS (it would at least
trash registers left on the basepage for the restore of the previous
call), multiple processes can very well all be in a GEMDOS call
(they're not yet performing their function, only saved their state).
|You will have to be careful when you implement time-slicing that you
|do not suspend a process while it is in the midst of a GEMDOS call.
[story about semaphores, critical sections left out]
But the time-slicing (implemented yesterday evening!) only takes effect
when the program was in user mode. This guarantees you're not
interrupting any progressing GEMDOS/(X)BIOS/GEM call. Small and
beautiful. In fact, my semaphore is the supervisor bit in the program
status word!
|There are probably thousands of such potential problems. I don't even
|want to think about the potential for trashing the disk due to
|simultaneous updating...
If there is a problem with this scheme, the problem can be reproduced
in the current (unmodified) TOS, so it was already there. As for
simultaneous updating, each GEMDOS call is completed before the next is
done. No trashing.
|Still, it sounds like fun to play with.
It sure is!! B.T.W. does that sound like an alpha/beta tester :-) ?
Cheers,
Leo.
P.S. The current version screamed for job control, signalling etc. so
that's being implemented right now (together with some system calls
like signal() and kill()).
------------------------------
Date: 22 Jul 89 20:04:32 GMT
From: attcan!utgpu!watmath!watdragon!watcsc!sleeve@uunet.uu.net (Stephen F.
White)
Subject: Re : Names for ST's
To: info-atari16@score.stanford.edu
STelllllaaaaaaaaaa!!!!
--
/***************************************************************************
* "Rock & Roll vegetable, vegetable stew!" * Stephen F. White, esq. *
* - Jazz Butcher * sleeve@watcsc.uucp *
------------------------------
Date: 22 Jul 89 13:32:56 GMT
From: mcvax!ukc!icdoc!gould!zmacu06@uunet.uu.net (F S Taylor)
Subject: Re: Meg upgrade.
To: info-atari16@score.stanford.edu
--
| Frank Taylor | Engineers often ponder upon the problem... |
| DoC 1 | Why do the girls with the most streamlined shape offer |
| Imperial College | the most resistance? anon. |
|--------------------+--------+-----------------------------------------------|
| JANET: zmacu06@doc.ic.ac.uk | All rights unreserved. |
------------------------------
Date: 22 Jul 89 12:01:35 GMT
From: jarvis.csri.toronto.edu!utgpu!watmath!watdragon!tiger!achowe@rutgers.edu
(CrackerJack)
Subject: Re: Curses for the ST
To: info-atari16@score.stanford.edu
>Speaking of curses, is there a *real* version of curses available
>for the ST? The only "curses" package I've seen is hardcoded for
>the ST/VT52 screen only. True curses supports any number of different
>terminal types with the termcap database. I know Fred Fish has
>written a PD termcap library that will compile on the ST, but I
>still haven't seen a real curses yet.
There is a curses library/source for ftp on him1.cc.umich.edu.
I used this package to port TETRIX about 2 months ago (which has since
been posted to the net).
- Ant
achowe@tiger.waterloo.edu | "Murdered by pirates is good."
__ _ | - The Princess Bride (movie)
/ _ _ _ |/ _ _ | _ _ |/ |
\__| `<_\<_ |\|= | ` \_/<_\<_ |\ | disclaimer...
------------------------------
Date: 22 Jul 89 13:58:06 GMT
From: mcvax!ukc!icdoc!gould!zmacu06@uunet.uu.net (F S Taylor)
Subject: Re: Meg upgrade.
To: info-atari16@score.stanford.edu
OOOOOOOPs there seems to have been a slight glitch, sorry about the
empty posting earlier! :-)
I did want to warn people of the dangers of a DIY upgrade (520 -->
1040). I did this very thing. The kit I bought was described in the
mag as an easy project that anyone (with a little experience) could
do. When the kit arrived it looked fine. In fact the fitting process
seemed quite simple, if a little labourious. The problems came when I
turned the machine on after re-assembling it. All I got was a blank
black screen! After much probing I could not find anything wrong with
it so off to the repairers it went. Eventually I got it back working
with a full meg, phewww.
The main problem with the kit was that you had to solder sockets onto
the board. These sat so closely together that it was nigh on
impossible to see if two pins had been soldered together (I suspect
that this was the problem with mine).
So, my advice to anyone trying to upgrade is, unless you *really* know
what you are doing when you pick up a soldering iron, get it done by
the dealer/upgrade supplier even if it costs 10-15 pounds more. It
would have saved me %40 pounds!
Frank.
--
| Frank Taylor | Engineers often ponder upon the problem... |
| DoC 1 | Why do the girls with the most streamlined shape offer |
| Imperial College | the most resistance? anon. |
|--------------------+--------+-----------------------------------------------|
| JANET: zmacu06@doc.ic.ac.uk | All rights unreserved. |
------------------------------
Date: 12 Aug 89 15:55:23 GMT
From: attcan!utgpu!watmath!watdragon!dahlia!swklassen@uunet.uu.net (Steven W.
Klassen)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <62828@linus.UUCP> rachamp@mbunix (Champeaux) writes:
>
>Now there's a point to debate. Do you really need memory protection on a
>single user multi-tasking computer. On a multi-user computer, memory
>protection is a necessity, since if one user's program crashes, you don't
>want to bring down the 50 other users. On a personal computer, where cost
>is an important factor, is it really necessary? (kind of sounds like the
>question "Is multi-tasking really necessary?" doesn't it?)
>It would, however, be really nice.
Here is a key issue in the multitasking debate: cost vs. performance.
While it is true that you are never going to match the performance
of a system designed (with hardware) for multitasking only through
software, one can come up with some pretty good compromises. Minix
is a good example of this, sure its not as secure as Unix but then
again, security isn't as much of an issue on a single-user system
as it is on a mult-user system. It seems reasonable to sacrifice
some security in order to keep cost down and performance up. (Still
it would be nice if we had the hardware to make it efficient, but
since we don't we must do the best that we can with what we have.)
As for the usefulness of multitasking, it extends not just to the
end user (running lots of programs), but also to the programmer.
Quite often in large applications it is useful to have portions of
the system running in the background.
Clearly it is more efficient and more secure to have this supported
by the OS rather than requiring the program itself to include all
the scheduling and security stuff.
ie. I would benefit (as a programmer) greatly even if only a limited
multitasking were allowed (system calls to provide low priority
background processes). Users would benefit from faster running
programs since the cpu would not have to be left sitting idle most
of the time.
Steven W. Klassen
Computer Science Major
University of Waterloo
------------------------------
Date: 22 Jul 89 19:16:42 GMT
From: mcvax!kth!sunic!kullmar!pkmab!daniel@uunet.uu.net (Daniel Deimert)
Subject: Re: quickst, bigscrn
To: info-atari16@score.stanford.edu
In article <512@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
>
>an informal survey we (me and Darek) conducted on GEnie showed users wanted
>a larger, faster version of Quick ST rather than a smaller, slower version. so
>we give them what they want. hell, Turbo ST is 40K.
>
>quick st can be made to use as little as 10K of memory, but it would be
>slower.
I agree with them. Why care about 50 kb more or less when you usually
got 1 Mb, and at least 512 kb. It's not a very big deal. Rememeber, there're
quite a lot of people with four Mb out there...
Better this way, make the program bigger and FASTER!
Wouldn't an option for use with BLiTTER be nice? (I get better results
on scrolling using QuickInf WITHOUT QuickST, but QuickST speeds up the
Cconws() etc several times)
By the way - someone who knows how to pay these ShareWare-money
from Sweden? I can't really send 30$ in an envelope...?! Please e-mail!
Daniel Deimert / / Internet: daniel@pkmab.se
Fridstav. 4 / / UUCP: ...
S-715 94 Odensbacken / / kullmar!pkmab!daniel
SWEDEN / / Phone: +46-19-52037, +46-19-111441 (BBS)
------------------------------
Date: 13 Aug 89 00:48:19 GMT
From: rochester!rit!ultb!clf3678@rutgers.edu (C.L. Freemesser)
Subject: Re: VIP AND KUMA, HOW DO THEY COMPARE?
To: info-atari16@score.stanford.edu
In article <ID2201.D890811.T141027.CHIASSA@UDEM> CHIASSA@UDEM.BITNET (Alyre
CHIASSON) writes:
>
> In a number of recent issues of ST WORLD "KUMA" has offered
> to VIP users a special price on K-SPREAD 3 plus K-GRAPH 3 if
> they send in their master VIP disks. Does anyone have any
> experience with either of these "KUMA" products in regards
> to what VIP has to offer? Is it worth the switch?
Well, I use LOTUS 1-2-3 at work (albeit a summer job). When I come home
and boot up VIP, I am given the EXACT SAME environment I have at work.
Ergo, VIP is for me! I have never used any other spreadsheet, but if
you use LOTUS on any regular basis, VIP is the way to go. Also, you
can mooch the LOTUS manuals from work and use them at home. :~)
Chris Freemesser, Rochester Institute of Technology | What I like :
BITNET: %clf3678@RITVAX GEnie: C.FREEMESSER | 1) My Atari ST
USENET: Just reply and hope it gets through | 2) My '77 Mercury
<This space available.......555-9092> | 3) Coke Classic
------------------------------
Date: 13 Aug 89 03:16:34 GMT
From: gem.mps.ohio-state.edu!ginosko!rex!hoang@tut.cis.ohio-state.edu (Dzung
Hoang)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
For those who would like to experience multitasking on the ST, I would
recommend looking at minix ST available from Prentice-Hall for $79. It's a
"mini-unix" operating system. Subscribe to comp.os.minix for more info.
Dzung Hoang
--
-----------------------------------------------------------------------------
hoang@comus.cs.tulane.edu hoang@rex.cs.tulane.edu
hoang@comus.UUCP hoang@rex.UUCP
tulane!comus!hoang tulane!rex!hoang
------------------------------
End of Info-Atari16 Digest
**************************
-------
