Re: Multitasking apple II

[mjmahon@aol.com (Michael J. Mahon)]

Roger Johnstone replied:

>In <20040917152504.17374.00000785@mb-m27.aol.com> Michael J. Mahon wrote:
>> Roy wrote:
>> 
>>>Softswitch by Roger Williams did this on a IIgs.
>> 
>> But did anyone do it on a //e with a RamWorks-type
>> or a "slinky"-type card?
>
>It could be done. You would have to trap the reset interrupt vector, 
>since this is the only interrupt a stock Apple II can generate from the 
>keyboard. Then you would need a safe place in main memory to hold a 
>small program that would switch banks, or at least switch to another 
>bank with the main switching program in it.
>
>The two problems are that most programs trap the interrupt vector 
>themselves and there is no such thing as safe memory on an Apple II ;o) 
>I understand Softswitch uses a classic desk accessory which solves both 
>problems.
>
>A simple hardware card like the copy cards that had an interrupt button 
>on them would make things a lot easier.

Since writing my question, I found at least one answer (that had
been pointed out by another poster earlier):  EXTRA.APPLE on the
EXTRA.K Beagle Brothers disk.

It uses page 3 for its switching code, and only swaps the main and
the auxilliary banks of a 128K //e.  It does not use an interrupt, but
requires the user to either 1) call the switch code, 2) use the ampersand
vector to reach the switch code, 3) use a "hot key" combination typed
at the keyboard (if an input hook can be connected), or, 4) BRUN the
EXTRA.APPLE program again, after possibly setting the current number
of the active Apple image.

As you point out, there is no "guaranteed" safe memory on an Apple II,
since anything that could be used could also be used by an application.
One way around this would be to use a small part of an I/O expansion
ROM.  Another would be to replace some sacrificable feature of the
monitor ROM.  Both of these solutions are somewhat intrusive, but
either could work.  Most of the code and required state information
could be squirreled away in one of the "upper" banks of a RamWorks-
type extended memory card or a "slinky"-type card, so it should only
take a small program to save enough state and get to the "real" code.

With this kind of approach, several virtual Apples could be supported,
and even several 128K //e's.

I suppose the remaining question is "How useful would such a program
switching facility really be?"  If it would be sufficiently useful, is anyone
sufficiently interested to write it?

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/