Path: utzoo!attcan!uunet!husc6!bbn!rochester!cornell!uw-beaver!tektronix!reed!kamath From: kamath@reed.UUCP (Sean Kamath) Newsgroups: comp.sys.apple Subject: Re: ProDOS vs. DOS 3.3 (was: SOFTSWITCH) Message-ID: <9562@reed.UUCP> Date: 14 Jun 88 20:00:14 GMT References: <369@dogie.edu> Reply-To: kamath@reed.UUCP (Sean Kamath) Organization: Reed College, Portland OR Lines: 122 [can we keep the included material to a minimum, folks?] In article <369@dogie.edu> terranova@vms.macc.wisc.edu writes: >In article <299@unocss.UUCP>, tucker@unocss.UUCP (Greg Tucker) writes... >>In article 3179 (Re:ProDOS vs. DOS 3.3 (was: SOFTSWITCH)) 366@dogie.edu >>states: >>[discussion of OS, and what one "really" is.] >> >>[statement about the size of the Apple ][ series] > >An Apple //e/c have parallel banks of 64K ram. Two programs which each >fit into one bank can run independent of each other. They have their >own stack and their own zero-page. BASIC and ProDOS can be copied >into the auxiliary bank. You then have, in effect, two 64K computers. A better way would be to make MAIN the resting place of the OS. Put all ProDOS stuff there, all memory management stuff, make it the loading buffer (you can load in segments, data or whatever, then do a memory move), etc. THis way, you have a platform to build on. >Context-switching can be handled by a small VBL interrupt routine. >The routine can switch contexts every 10-20 ticks to give each process >time to get some work done. A good way to do it. All you need is some sort of constant interrupt. >Potential problems that I see: > 1) interrupts - interrupt routines must run in main mem so require > all processes that need interrupts to run in main. This means > that two of them CANNOT run together. Well, not really. All that a process really need to do is make sure that follows some rules, primarily thos that ProDos already requires, i.e. that you call the interrupt manager. In this way, the primary interupt, the context switcher, is called, which (at the proper time, i.e. number of 'rupts) switched what needs to be switched. All programs would rely on the dispatcher to return their own interrupt. This really shouldn't be so hard. The context switcher would either switch in a set of INT vectors, or just increase the size of the table. Basically, there is one problem. So, two programs want an INT on the serial port. Ok, this would make for a real problem. How about two programs using the same interrupt source for counting. Well, if it's for timing, it's all short to hell. Get the point? Otherwise, the controler would decide who was running at the time of the interrupt, and call their set of checkers. Otherwise, you could just let whoever wants it have it. > 2) disk I/O - I believe ProDOS disables interrupts during disk I/O, > so no fear of context-switching at a bad time. All OS disable interrupts when writing to disk. The only thing is, on the big babies, you don't turn them off very long. Mostly because you don't actually write to the disk. Fer instance, on a scsi card, you should be able to say "write this to disk" and then continue from there, letting the disk controller do the actual writing. For a 5.25, you can't do that. I might be fun to make a card that would do things right for the 5.25 drives. > 3) screen contention - the screen bounds can be convienently set so > that a program writes to only it's window (eg top half). With > two programs one get the top half, the other gets the bottom. I got a better idea. The controlling program could retain control of the screen. Think of it this way. The program doesn't do direct screen store. It calls the normal screen routine. It get's shunted to the controller. It decides who's being "shown" at any given time. Then it maps in that processes window. If you really think this is a problem, I suggest you do this on any unix machine: sleep 10 & cat /etc/passwd When you watch (preferable at 1200 baud, though you can make the "sleep 10" into a "sleep 10 ; banner "hi" &) as the password file goes by, you'll see a "[1] done xxxx". The point is, people think it'll be a problem, but it isn't, you just have to worry about "awake" and "background" processes, and which stream goes where. > 4) keyboard contention - make a slight modification to the kbrd input > routine to check for special key combinations to designate which > half of the screen (which program) gets the input. (This routine > would probably have to disable interrupts during execution.) No way. You should never *ever* try to input from the keyboard like this. You shoulsd only have one "active" process at a time. On UNIX, if a program wants input, it get's stopped, with the message "xxx stopped: TTY input" or somesuch. I'm afraid that trying to get two processes working simultaneously *with* screen output at the same time is a bit silly. If you want something like that, you have to go to a real windowing environment. >These problems, really, don't seem to be too terribly difficult to >overcome. Unless someone can think of more problematic problems, or >have reasons why these are more serious than I think they are, I will >stick by my original claim: multi-tasking can be done on a //e/c!! >** with only two processes ** Well, why does anyone want multi-tasking in the first place? I mean *REALLY*? Think about it. When I wait for "spacewar" to compile on the vax, I read news. When I wait for Apencode to compile (It's gotten to seven files, almost $1000 byes, and takes a few minutes to complile :-), I go get more coca-cola. The only time I really want to use the computer and can't is when I print, and we *all* know how to fix that. Ok, sometimes I want to have my //e call up the vax and download a file or something silly like that. Then I would have two processes, one doing the download, the other at my disposal. Or maybe I want to compute a mandlebrot, and also hack at same time. Again, two processes. Also, let's not confuse the concept of "shell" and "multi-tasking", and what each one is supposed to do. >>-- >>Gregory A. Tucker >John C. Terranova Sean Kamath PS If you really want three programs at once, just think "three times slower". At least. -- UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@PSUVAX1.BITNET ARPA: reed!kamath@PSUVAX1.CS.PSU.EDU US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!)