K538915@CZHRZU1A.BITNET.UUCP (02/13/87)
An example that multitasking can be done quite well on a 68000 without MMU is
OS-9 (no, I haven't got it on an ST, but on a VME board). I personaly don't
think that it would be worth the trouble trying to write a real multitasking
kernel which GEM would run on top of (anyway there was some talk about DRI
writing a multitasking GEM). I think it would be more sensible to spend the
time writing a graphic user interface for MINIX or OS-9. One more word on my
comment to Beckemeyers background Kermit/XModem, I've got nothing against
things like a printer spooler etc. running in the background, but a fully
fledged Kermit is something different and one of the reason we buy small
computers is that we get better response times. Don't forget that something
that works ok on a terminal based system (like running Kermit at the same time
as editing a file on the VME system I mentioned (it does get very slow!)),
will not work as good on a bit-mapped system with no graphics hardware support
where editing is a major task (at least with GEM based editors).
Simon Poole
K538915@CZHRZU1A.BITNET
*-----------------------------------------------------------------------------*
* Definition: An optimist is a person which believes that there will be ROM *
* upgrades for the 520ST and 1040ST *
*-----------------------------------------------------------------------------*
hays@apollo.UUCP (02/16/87)
Now that a Standard Window/Graphics system is available -- How about
X Window (MIT) for the ST on top of MINIX and/or OS-9.
How about putting as much as possible into a ROM cartridge so that
it is available with the ability to switch between MINIX and TOS.
John Hays
--
=============================================================================
= MINE! THESE OPINIONS ARE MINE! YOU UNDERSTAND? MINE! =
=============================================================================
John D. Hays UUCP: ...!decvax!wanginst!apollo!hays
Consultant ...!uw-beaver!apollo!hays
Corporate Systems Engineering
Apollo Computer Inc. CIS: 72725,424 {weekly}
Chelmsford, MA GEnie: KD7UW {monthly}
=============================================================================
= MINE! THESE OPINIONS ARE MINE! YOU UNDERSTAND? MINE! =
=============================================================================ericr@hpvcla.UUCP (02/17/87)
I use a "multi-tasking" terminal emulator (Reflections III) on my HP Vectra with minimal degradation in performance--in fact, the download/upload will slow down in favor of my foreground application. While this may not be desirable with a pay computer service(or long distance) it is highly desirable in many other environments. When comparing overall CPU performance of the ST to the 8 Mhz 80286, I find that in general they are fairly close--therefore a multi-tasking Kermit is not necessarily a bad thing and I will be looking forward to seeing Beckmeyer's new package. Eric Ross ihnp4!hpfcla!hpvcla!ericr CIS: 72347, 2664 GENIE: E.ROSS
bandy@amdcad.UUCP (02/19/87)
Well, as you may know, Andy Tanenbaum has mentioned a number of times
that a friend of his is working on a port of minix to the ST. Well, I
was curious as to which method was being used (planned on being used? I
don't know how far along that port is), so I dropped a note off to him
and found out that when processes are loaded, they are relocated on the
fly -- apparently the same method that the Amiga folks use. When a
process forks, the child is "swapped" to somewhere in memory (wherever
there is enough room). When the scheduler starts the child, it swaps
out the parent (to somewhere else in memory), swaps the child to where
the parent is and starts running the child -- this way all the text and
data references are okay.
In most cases, the child will exec so the new process being loaded in
can go anywhere and the parent process can go back to where it
belongs. This all should happen within one scheduler tick, so you
won't have to do more than four copies of the parent's process image if
you're careful // however, if you're really careful, you could get away
with two copies (for the fork/exec case) -- copy the parent, run the
child (where the parent was), when the child execs, copy the parent
back to where it belongs You might be able to get away with not copying
the parent back *just shuffle the pointers), but with no read-only
pages (no mmu), you have no guarantees that the child hasn't scribbled
all over the data or text pages).
Yes, I know, this sounds gross, but it isn't too bad -- after all, if you do
want your machine to go faster, you can wait until one of the home-computer
manufacturers comes out with a cheap machine with an MMU and then run Minix
on it.
--
Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683jimomura@lsuc.UUCP (02/21/87)
In article <8702131709.AA28497@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET.UUCP writes: >An example that multitasking can be done quite well on a 68000 without MMU is >OS-9 (no, I haven't got it on an ST, but on a VME board). I personaly don't >think that it would be worth the trouble trying to write a real multitasking >kernel which GEM would run on top of (anyway there was some talk about DRI >writing a multitasking GEM). I think it would be more sensible to spend the >time writing a graphic user interface for MINIX or OS-9. One more word on my There is a lot of interest in a full multi-tasking window support system on the ST. I've had a lot of Usenet mail on OS-9 by itself and lately I've been looking into the possibility of windowing systems under (over?) OS-9. Please do NOT expect me to do this myself! I'm looking into it mostly out of curiosity, although if I can do something towards a solution, I'll do what I can. I'm *very* busy lately. Anyway, the options I've seen are as follows: 1. GEM calls from OS-9. This likely won't work. I don't *know* that they won't work, but GEM just wasn't designed for multi-tasking and I expect at the very least that interrupt handling may become contentious. I *think* that the graphics routines might be addressable, but that the actual window handling might have to be re-created. I'm mainly guessing at this however, since I don't know really what's going on inside GEM. 2. X-Windows. If X-Windows is going to be the big standard for Unix systems, why not port X-Windows to OS-9? It must already address the problems of multi-tasking. Data compatibility for networking would be wonderful (hook up ST's in the same system as VAX, Sun, Appollo, etc.) It looks like the money would be available to someone who would do the port. I was hoping to arrange to have sources posted to BIX, but an estimate of the size of the sources proved prohibitive (something like 10 Meg. in sourcefiles!). I have found there is strong interest in this approach, but it looks like a big job. 3. The CoCo Window interface (what-ever-it's-called). I haven't seen it yet. It should be on the market shortly. I hear it's wonderful. OS-9 has network support software available. OS-9 has a number of machines to network between which might be able to use this standard (my 68020 machine should arrive shortly--they've just started shipping them). I don't know how receptive Microware would be to the idea of allowing someone to port the software for them for this purpose (assuming it's Microware's code and not Tandy's). 4. Any other worthwhile approach? NEWS by Sun--I can't see any reason to favour this over X-Windows at this point. Sun claims that it's a superset of X-Windows. If this is so, then fine, I don't see any reason to think we couldn't upgrade it to NEWS later if we do X-Windows now. Intuition-like interface? I hear it's easier to program for than the Mac interface. I don't know what that proves really. In fact, I don't know at this stage if all these approaches are necessarily mutually exclusive. Cheers! -- Jim O.
grunau_b@husc4.UUCP (02/22/87)
Well, in follow-up to Jim Omura's list of available "options" for graphical windowing environments to run on top of multitasking UNIX-like OSs on the ST, I think my tentative vote is for X-Windows -- it's about time we had some sort of standard, both in OS (UNIX or look-alike) and windowing environment. I also think it would be nice to make X-Windows run with MINIX as well as (or instead of) OS-9. One thing, though -- the original XEROX PARC project which started this whole business was centred not on windowing per se but on OBJECT-ORIENTED programming. Something like the Mac's windowing environment is not a good implementation of this concept, which I think is a sound one. I assume X-Windows is more along these lines? In which case, it gets my vote even more enthusiastically. JJMG grunau@husc4.UUCP or --- !seismo----- \ --- !rutgers----- !husc6!husc4!grunau / --- !decvax!ihnp4 or BITNET hostname is "harvsc4".
drforsey@watcgl.UUCP (02/23/87)
>4. Any other worthwhile approach? NEWS by Sun--I can't see any reason >to favour this over X-Windows at this point. Sun claims that it's a >superset of X-Windows. If this is so, then fine, I don't see any reason >to think we couldn't upgrade it to NEWS later if we do X-Windows now. NeWs is an extensible window manager, you can define whatever protocol you like to a window by downloading code to the window manager (in Postscript). NeWS runs a postscript interpreter and uses multiple "light-wieght" tasks (processes) and message passing internally. This is why NeWS might be called a "superset" of X. How one would upgrade an X-system to NeWS is unclear. X is very painful to use over slower communications lines. NeWS has internally been ported to an Atari-ST and has reasonable performance over a 9600 baud line. What struck me as important about NeWS is that it is based on a high- level imaging model. It is not just a windowing package. Personally i find X to be rather massive and inelegant. All this is from a talk Gosling (yes the same one as emacs) gave at UCSC last fall. Last i heard it was coming out in march. US$1000 to universities including source. Apparently sun wants to make the protocols public and have "reasonable" licensing aggreements. Dave Forsey Computer Graphics Laboratory University of Waterloo
leo@sunybcs.UUCP (02/24/87)
In article <3322f272.18e6@apollo.uucp> hays@apollo.UUCP (John Hays) writes: >Now that a Standard Window/Graphics system is available -- How about >X Window (MIT) for the ST on top of MINIX and/or OS-9. > >How about putting as much as possible into a ROM cartridge so that >it is available with the ability to switch between MINIX and TOS. > >John Hays Hear, hear! Uh, one exception: How 'bout putting as much as possible of the MINIX kernel into rom, TOSsing the gunky into the trash can?! -- ----- Leo E. Wilson 364 West Delavan Avenue Buffalo, NY 14213 (716)883-7573(leo@buffalo.csnet)...!sunybcs[!npdp1]!leo
gordon@sage.UUCP (02/25/87)
In article <1588@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >In article <8702131709.AA28497@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET.UUCP writes: > >1. GEM calls from OS-9. This likely won't work. I don't *know* that they >won't work, but GEM just wasn't designed for multi-tasking and I expect at >the very least that interrupt handling may become contentious. I *think* But DR say it is designed so that they can add it later, they already have a version that allows you to switch between several 'processes' though only the top one is actualy running, and say they do intend to bring out a real multi tasking one later. (OK i admit it, a lot later probably).
dillon@CORY.BERKELEY.EDU.UUCP (02/26/87)
NEWS cannot be considered a superset of X. You can, however, impliment almost all NEWS functions in X (and thus, if anything, NEWS would be subset of X). -Matt