Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!paul.rutgers.edu!jac From: jac@paul.rutgers.edu (J. A. Chandross) Newsgroups: comp.sys.apple Subject: Re: multitasking, softswitch, etc. Message-ID: Date: 30 Mar 89 01:51:59 GMT References: <8903181259.aa27052@SMOKE.BRL.MIL> <10183@bloom-beacon.MIT.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 71 SASQUATCH@ALBION.BITNET ("Kevin O. Lepard 629-5511 x6668", 517) writes: > >Would it be possible to write a program similar to softswitch that could >automatically switch between applications, allowing something to run in >background? I've heard people talk about "heartbeat" interrupts. Couldn't >that be used somehow? Even if this cut the speed of the GS in half, it >would still be running as fast as a normal //e Dave Whitney (dcw@athena.mit.edu) >calling by using traps. As far as I know, the 65816 doesn't have a trap >mechanism (although, I suppose the COP instruction might get useful here...). You are forgetting about the BRK instruction. This causes a software interrupt. What you do is set a flag (ie global variable) and then execute the BRK. The semaphore tells the OS exactly what sort of interrupt you *really* wanted to generate. This is a nice way to expand the instruction set. An an article on how to do this appeared in Byte about 10 years ago. The basic idea is that you put the opcode of the fake instruction and it's data right after the BRK. When you get the interrupt your interrupt handler looks at the value of the PC on the stack (remember, all registers are saved by the interrupt) and grabs the instruction/opcode from memory, and simulates it. When the simulated instruction is finished it jumps to the address of the old PC + the size of the simulated instruction (including operands, etc.) Software traps for non-existant instructions are usually faster than a subroutine since the subroutine has to set up an activation record (at least for compiled code; assembly programmers are much craftier.) >Sorry to rain on your parade, but a multitasking OS is a physical impossibility >on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting >GNU C and GNU Emacs, and I'll be VERY VERY happy! Sorry to rain on *your* parade, but you are very wrong here. The early versions of Unix supported multitasking. Even in 1969. Even with no memory protection and memory management of any sort. Even in < 64K. So how did they do it? You make your system a total swapping system. Whenever you get the interrupt to change jobs you put the current contents of memory out on disk and load in the next job to run. The only "constant" code is the operating system. Now, a bogus pointer can still trash the OS, but this was a problem with early Unix too. (Basically, you don't allow anyone to test code while you are doing real work.) The only problem with a swapping on the ][+ is that all I/O is synchronous since the processor is doing it. This means that while one process is waiting on a disk access you can't run another because you would have to swap it in off disk, and that requires a disk access, which... But this isn't a real problem. It is very difficult for an Apple to support multiprogramming (ie more than one job in core at time same time) more complicated than of the TSR (Terminate and Stay Resident) variety because of limited memory. However, one could use it with a few small jobs (like 5 k apiece). An Apple with a RocketChip (plug, plug) or a Zip Chip, or a Transwarp, etc is a kick-ass machine compared to the early PDP-11's. The early 11's took tens of microseconds to add 2 sixteen bit numbers, and yet could still run a *real* operating system with *multitasking*. Given that you can put 8 megabytes in a ][+ (in 1 Meg increments), I don't think you should have any problems with a ][+ running a stripped down V7. Is anyone interested in this? If so, let me know. 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. Apple ][+ Unix -- wait till you tell mom. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac