gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/11/88)
In article <8806100851.aa03496@SMOKE.BRL.ARPA> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >Is there REALLY enough extra advantage to ProDOS ... >... to merit starting over from scratch? I don't know what your problem is. Removable media will boot whatever OS they happen to contain. Fixed media are definitely better off with ProDOS. Both my hard disks are set up as ProDOS file systems. ProDOS is so much closer to a real OS than DOS 3.3 that I virtually never use DOS 3.3 (except when booting some old stand-alone disk built with DOS).
terranova@vms.macc.wisc.edu (06/12/88)
In article <8075@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes... >In article <8806100851.aa03496@SMOKE.BRL.ARPA> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >>Is there REALLY enough extra advantage to ProDOS ... >>... to merit starting over from scratch? > >I don't know what your problem is. Removable media will boot whatever >OS they happen to contain. Fixed media are definitely better off with >ProDOS. Both my hard disks are set up as ProDOS file systems. ProDOS >is so much closer to a real OS than DOS 3.3 that I virtually never use >DOS 3.3 (except when booting some old stand-alone disk built with DOS). What?!? ProDOS is close (anywhere near) a real OS? Since when? Have there been that many major changes to ProDOS from when I used to use it all the time (a couple years ago)? Sure, ProDOS is a >>small<< step in the right direction, but it is meager, at best (sorry, Apple). Perhaps we don't agree as to what a real OS is. Let me enumerate: - multi-tasking (I guess this rules out most micros) - I/O re-direction - device independence - piping (this can be done without m-t) - virtual memory (on a 6502? yea, right) Anyone care to add to this list? It is interesting to note that I believe all of the above (except virtual memory) can be done on a //e/c. At one time (I'm talking just a few weeks ago) I was half tempted to implement a shell to overlay ProDOS and achieve most of the above. Two things stopped me: 1) I don't use a //c anymore (now it is my parent's) 2) I hate assembly language a. I have never seen any decent, cheap C/Pascal compilers Perhaps someone out there will pick up my fallen cause and get the job done. (Personally, I'd rather waste my time programming a Mac than a // [sorry]). I would love to be able to type something like: ls /bin>out | more on a // and have it function as expected. Well, enough of my ranting and raving. If anyone out there decides to give this a try, mail me. I'd love to share what I learned and give any tips or hints that I think may help. ------------------------+------------------------------------------------ John C. Terranova | I'd start a revolution, but I don't have time. CS, BS to be | --Billy Joel, "Close to the Boarderline" ------------------------+------------------------------------------------ I speak for myself as well as all those listed below. And no one else. 1) 2) 3)
tucker@unocss.UUCP (Greg Tucker) (06/13/88)
In article 3179 (Re:ProDOS vs. DOS 3.3 (was: SOFTSWITCH)) 366@dogie.edu states: > What?!? ProDOS is close (anywhere near) a real OS? Since when? > Have there been that many major changes to ProDOS from when I used > to use it all the time (a couple years ago)? Sure, ProDOS is a > >>small<< step in the right direction, but it is meager, at best > (sorry, Apple). I will grant you this much, though that step may be bigger than you think. > Perhaps we don't agree as to what a real OS is. Let me enumerate: > - multi-tasking (I guess this rules out most micros) > - I/O re-direction > - device independence > - piping (this can be done without m-t) > - virtual memory (on a 6502? yea, right) > Anyone care to add to this list? Sounds to me like you are looking for a UNIX shell on the Apple. No low end micro has added more than one of these features, you expect them added on an Apple? I hate to disappoint you, but... > It is interesting to note that I believe all of the above (except > virtual memory) can be done on a //e/c. At one time (I'm talking On a crummy little Apple? Even one program can barely run with only 128k of memory. Do you want 2 or 3 programs to? Besides, bank switching pretty well eliminates any hope of running a multitasking environment. What happens when you get an interrupt? > a. I have never seen any decent, cheap C/Pascal compilers I agree one hundred percent. Could Turbo Pascal run on the //ec? ProDOS has at least achieved device independence. Given the limitations of the hardware, ProDOS is NOT all that bad... BTW, I have heard about an MS-DOS shell that runs under ProDOS. Does it allow for I/O redirection, and is it worth getting? "The most impassionate song to the lonely soul is so easily outgrown..." -The Smiths -- ---------------------------------+--------------------------------------------- Gregory A. Tucker- Consultant | Internet: conslt05%zeus.dnet@fergvax.unl.edu Campus Computing | Bitnet: CONSLT05@UNOMA1 University of Nebraska at Omaha | UUCP: {ihnp4}!unocss!tucker
terranova@vms.macc.wisc.edu (06/14/88)
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: > >> Perhaps we don't agree as to what a real OS is. Let me enumerate: >> - multi-tasking (I guess this rules out most micros) >> - I/O re-direction >> - device independence >> - piping (this can be done without m-t) >> - virtual memory (on a 6502? yea, right) >> Anyone care to add to this list? > >Sounds to me like you are looking for a UNIX shell on the Apple. >No low end micro has added more than one of these features, you expect >them added on an Apple? I hate to disappoint you, but... > >> It is interesting to note that I believe all of the above (except >> virtual memory) can be done on a //e/c. At one time (I'm talking > >On a crummy little Apple? Even one program can barely run with only >128k of memory. Do you want 2 or 3 programs to? Besides, bank >switching pretty well eliminates any hope of running a multitasking >environment. What happens when you get an interrupt? > 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. 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. 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. 2) disk I/O - I believe ProDOS disables interrupts during disk I/O, so no fear of context-switching at a bad time. 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. 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.) 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 ** >-- >---------------------------------+--------------------------------------------- > Gregory A. Tucker- Consultant | Internet: conslt05%zeus.dnet@fergvax.unl.edu > Campus Computing | Bitnet: CONSLT05@UNOMA1 > University of Nebraska at Omaha | UUCP: {ihnp4}!unocss!tucker ------------------------+------------------------------------------------ John C. Terranova | I'd start a revolution, but I don't have time. CS, BS to be | --Billy Joel, "Close to the Boarderline" ------------------------+------------------------------------------------ I speak for myself and all those listed below. And no one else. 1) 2) 3)
kamath@reed.UUCP (Sean Kamath) (06/15/88)
[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!)
tucker@unocss.UUCP (Greg Tucker) (06/15/88)
In comp.sys.apple #3187 [Re: ProDOS vs. DOS (was: SOFTSWITCH)] John C. Terranova (terranova@vms.macc.wisc.e) wrote: > 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. At one time I did think about writing a DOS >< ProDOS switcher, with ProDOS in the main bank and DOS in the aux bank, using & commands to switch between the two. Though I never thought about making it multitasking... > 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. I don't remember anything like this in my //e reference manual that I read several years ago. Could you explain it to me in more detail... > 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. > 2) disk I/O - I believe ProDOS disables interrupts during disk I/O, > so no fear of context-switching at a bad time. > 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. > 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.) Don't forget the fact that you can only use 40 columns. The 80 column screen runs in both banks... > 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 ** Given the limitations, 40 x 12 screen, nothing useful could be written. Of all machines available, why would someone other than a hacker choose to write this on an apple? "Amid concrete and clay, and general decay, Nature must still find a way..." -The Smiths -- --------------------------------+--------------------------------------------- Gregory A. Tucker- Consultant | Internet: conslt05%zeus.dnet@fergvax.unl.edu Campus Computing | Bitnet: CONSLT05@UNOMA1 University of Nebraska at Omaha | UUCP: {ihnp4}!unocss!tucker
Mandel@BCO-MULTICS.ARPA (Mark Mandel) (06/16/88)
Doug Gwyn writes that there's no real problem:
"Removable media will boot whatever OS they happen to contain. Fixed
media are definitely better off with ProDOS."
That argument falls down when you try to pass data from one program to
another. I have a decent spreadsheet which runs under ProDOS and can
save to file in ASCII format, but my comm software uses DOS 3.3. If I
want to send a copy of a spreadsheet to another machine (which I have
wanted to do), I would have to convert it to DOS to use it: NOT
convenient!tgm@xroads.UUCP (Sloan Tash) (06/19/88)
Turbo Pascal has run on all the //'s for quite some time, but it runs under CP/M and is S-L-O-W... To the person flaming ProDOS: Look at ProDOS 8 (you sound like the last one use saw was 1.0.1). None of those features have been added on any PC, and I don't think any of that can be done on a //c. However, this is not the OS's fault.. Apple needs to build a more powerful machine that still ranks as a PC.. Hence, the GSPlus. ihnp4!crash!xroads!tgm -- \ / C r o s s r o a d s C o m m u n i c a t i o n s \/ (602) 971-2240 /\ (602) 992-5007 300|1200 Baud 24 hrs/day / \ hplabs!hp-sdd!crash!xroads!*