GREYELF@WPI.BITNET (03/22/89)
For people who have received a copy of my Shell program by now, in the instructions I mention that version 2.0, should I decide to release it will support multitasking. Actually, the currecnt version of Shell supports multitasking, it just doesn't include the multitasking driver. Unless one considers my clock programs multitasking. What I am waiting for now is for people to try out the shell program as it now exists. -- Michael J Pender Jr Box 1942 c/o W.P.I. greyelf@wpi.bitnet 100 Institute Rd. greyelf@wpi.wpi.com Worcester, Ma 01609 I wrote SHELL, please send bug reports to me.
cbdougla@uokmax.UUCP (Collin Broadrick Douglas) (04/06/89)
To tell you the truth, I would rathat have multitasking with Prodos
8 programs than Prodos 16 or GS/OS. What I'd like to do is run a BBS
in the background and still retain some productivity. I use a lot
of 8 bit software so the board would be up most of the time etc...
IS this just absolutely impossible to do? Like I said a while back, the
COCO III can multitask and I want to do it on my GS (especially now
that I've gotten used to UNIX and the Encore Multimax :) )
Collinsecrist@msdsws.DEC.COM ("Richard C. Secrist") (04/06/89)
Even the CoCo I can multitask under OS-9 but anybody who has ever tried it can tell you it was a real dog. Of course that was on a 0.8 MHz 6809E -- perhaps Transwarped or something on a // it might be a useful option... rcs
shawn@pnet51.cts.com (Shawn Stanley) (04/07/89)
cbdougla@uokmax.UUCP (Collin Broadrick Douglas) writes: > To tell you the truth, I would rathat have multitasking with Prodos > 8 programs than Prodos 16 or GS/OS. What I'd like to do is run a BBS > in the background and still retain some productivity. I use a lot > of 8 bit software so the board would be up most of the time etc... > IS this just absolutely impossible to do? Like I said a while back, the > COCO III can multitask and I want to do it on my GS (especially now > that I've gotten used to UNIX and the Encore Multimax :) ) The CoCo uses OS/9 for multitasking, which is an OS designed specifically with multitasking in mind. Multitasking on the Apple II is more difficult, first since there is no multitasking OS available, and second since in emulation mode you have to watch out for certain portions of memory, depending on what you're doing. You would probably find it difficult (if not impossible) to run anything from a favorite game to Appleworks at the same time you're running a BBS under ProDOS 8, since most software takes so much advantage of what's available here and there that it crowds out the possibility of multitasking. Michael Pender seems to have some software brewing that lets you do P8-type multitasking, but I have no idea what limitations it has or doesn't have. Michael? UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
GREYELF@WPI.BITNET (04/08/89)
> To tell you the truth, I would rathat have multitasking with Prodos > 8 programs than Prodos 16 or GS/OS. What I'd like to do is run a BBS > in the background and still retain some productivity. I use a lot > of 8 bit software so the board would be up most of the time etc... > IS this just absolutely impossible to do? Like I said a while back, the > COCO III can multitask and I want to do it on my GS (especially now > that I've gotten used to UNIX and the Encore Multimax :) ) > Collin Well Collin, Daemon will do that now, but unfortunately a minimum of an enhanced IIe is necessary.... -- Michael J Pender Jr Box 1942 c/o W.P.I. I wrote SHELL and Daemon, greyelf@wpi.bitnet 100 Institute Rd. send bug reports, suggestions, greyelf@wpi.wpi.com Worcester, Ma 01609 checks to me. People keep asking me if Shell or Daemon are compatible with the IIc, IIe. YES, I wrote them on my Laser 128. I mean, what would be the challenge to multitasking on a IIgs? I'll start writing dedicated gs programs when somebody sends me one in the mail.
ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (04/14/89)
In article <8904061416.AA20685@decwrl.dec.com> secrist@msdsws.DEC.COM ("Richard C. Secrist") writes: > Even the CoCo I can multitask under OS-9 but anybody who has > ever tried it can tell you it was a real dog. Of course that > was on a 0.8 MHz 6809E A Zip chip or something would make it worthwhile. My cycles are more important, and if I can avoid having to recreate my environment by letting the machine keep multiple instances around, then I'm happy. I think most of the CoCo's problem was a problem with the R/S disk controller. It's still not an Amiga, but where else can you multitask for less than $500? (C64 + GEOS, I suppose). Article 413 of comp.sys.m6809: Path: pt!rochester!ur-tut!sunybcs!boulder!hao!ames!ptsfa!ihnp4!ihwpt!knudsen From: knudsen@ihwpt.ATT.COM (mike knudsen) Newsgroups: comp.sys.m6809 Subject: Re: 16k Coco purchase query Summary: CoCo OS-9 IS TRUE MULTITASKING!! Just get the right disk controller. Message-ID: <1902@ihwpt.ATT.COM> Date: 12 Aug 87 17:39:31 GMT References: <1248@ius2.cs.cmu.edu> <668@csuchic.csuchico.UUCP> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 40 > OS-9 on the Color Computer is not a true multitasking system due to lack of > DMA and the NMI kludge of the disk controller. Too many interrupts can (and > do) get lost. I'm hoping the CoCo 4 (if Tandy ever gets off its ass) will > break away from the old CoCo mode and use the real 6809 hardware like the > 6829 (with 8 of them you can manage two megabytes of memory, or one meg and > memory protection!), DMA, and maybe even *gulp* multiple processors! > Ronald Cole | uucp: ihnp4!csun!csuchic!ronald Both Levels 1 and 2 OS9 can be made into true multitasking systems (edit one file while compiling another and printing yet a 3rd), IF you buy one of the two new floppy disk controllers coming out of Canada -- either Sardis Technologies in British Columbia or DISTO in Quebec (anyone in Alberta want to cover the middle?) Both of these cache up at least a sector at a time and transfer by nice simple software loops that don't block interrupts or do any other non-Ivy_League gaucheries. The 8K of RAM in the Sardis may someday be expanded by software into a real cache of the sort being discussed on this net. These new controllers cost about $150 US each. Whatever you do, don't buy a Radio Shack controller, since 3rd-party clones at least as good are available as low as $65 (see _The Rainbow_ mag.). The Shack's disk drives are also a ripoff. $170 Coco III $ 65 Disk controller $ 90 one DSDD-40 drive $ 80 OS9 Level 2 $ 70 case, power supply & cable for drive ---- $475 + your TV set or $90 mono monitor PS: Motorolas's old MMU chips (6829) waste a clock cycle on every RAM access. Tandy's new custom GIME chip does not. I posted months ago about how easily Tandy could extend the GIME to 2 Meg. Let's not wish Tandy back to obsolete off-shelf chips. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!" > > rcs -- - Ralph W. Hyre, Jr. Internet: ralphw@{ius{3,2,1}.,}cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)" --
m.tiernan@pro-angmar.UUCP (Michael Tiernan) (04/18/89)
Jonathan Chandross et al:
Adding to a message I posted to info-apple (Multitasking thought)
earlier, I think that for the most part if we were to approach this whole
thing with the open mindedness that we A) Can do it, and B) That
effectively, we are going to be writing an entire system that is (for the
most part) incompatable with what we now use for utilites and
applications. The reason that I say this is that while it's being
developed, unless we do get a piece of hardware that can manage the memory
usage and access, we are not likely (note, I didn't say won't) going to be
able to run our AppleWorks and desktop applications.
In his reply to Dave Whitney (dcw@athena.mit.edu), Mr. Chandross
points out that the BRK instruction will serve as a nifty TRAP
instruction. As a matter of fact, I do believe that I once saw a Merlin
macro called TRAP that helped set up such a psudo instruction. This is
true, the use of our new TRAP would work good for directly talking to our
running system.
Someone else pointed out that "...a multitasking OS is a physical
impossiblity on the II line. IT CAN'T BE DONE. ..." As I remember, some
whiz-bang at Hewlett Packard told one of their employees that you couldn't
make a profitable micro computer and that they weren't interested in his
design. Now what was his name.... Steve something... Damn, I keep
forgetting his name... ;-> And again, Mr. Chandross points out that in
the dark ages the earliest versions of UNIX ran on 64K machines. (I was
running one a number of months ago, I asked the guy I worked with and he
booted it up for me.) (I'm not sure what version it was but it ran
[walked] on a 64K PDP-11)
Now, down to the reason that I took pen to paper.... er.. finger to
key. I've read the Tannenbaum operating systems and design book and have
thought about how such a thing could be done. Now, this is limited in
it's depth and I haven't even tried to put it on paper yet but, if we
started one process (the mother hen as it were) and had it be the only
running process that talks to the operating system, then we could
implement a request que to it. It's job would be to handle all calls to
the operating system and to system resourses that aren't allocated (more
on allocation later). It would immediately spawn a second process that
would (for the time being) be our operator interface, our shell. I
realize that we wouldn't have a REAL shell type environment right away,
but it's a start. Now, instead of the shell talking to the hardware, it
ques requests for reads and writes to the request que and then go into a
wait state. This would give us our first level of multitasking but we
also need to implement a scanning process that would be able to trigger a
context switch on what we've got running and bring another into play.
This can be done with the heartbeat interrupt from the IIgs clock (or
another source if not on the gs). This will give us our second level of
multitasking, a time-slicing system.
Well, that's my rambling for awhile. I'm sure that none of it is new
but I thought I'd at least see if I can get a little more productive
posting done than the simple retoric in the vain of "Tastes great!" "Less
filling!". Let's see what else comes up!
P.S. Mr. Chandross, Re: I know of a stripped down Unix kernal that fit
in 32K on a Z-80. User applications ran in the other 32k. While this is
a small amount of code, it could run a shell, ed, and other simple
utilities.
Does it run on the Apple (MicroSoft CP/M)? If so, I would like to see
it!
<< MCT >>
BCS Apple/Boston Connection [MCT] (617) 893-5681
GEnie M.Tiernan
AppleLinkPE M Tiernan
BCS Net Michael Tiernan
obsolete!pro-angmar!m.tiernan@bloom-beacon.mit.edu
obsolete!pro-angmar!m.tiernan@bu-it.bu.edu
pro-angmar!m.tiernan@obsolete.uucp
m.tiernan@pro-angmar.cts.com
shawn@pnet51.cts.com (Shawn Stanley) (04/19/89)
I might point out that even on the mainframe level, massive amounts of memory
haven't been required for multitasking. Up until just a few years ago, a
company I worked for was running an IBM System/36 with over 20 users in 256k.
They received an update for 1 megabyte. :-)
UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn
INET: shawn@pnet51.cts.com