Cool AppleSoft BASIC trick I never thought of before

From: Vintage Computer GAWD! <foo_at_siconic.com>
Date: Wed May 17 02:16:58 2000

On Wed, 17 May 2000, Pete Turnbull wrote:

> If I remember correctly, Applesoft BASIC is one of those that searches from
> the start of program every time it executes a GOTO or GOSUB. If I'm right,
> the easy way to preserve variables (and all the rest of the program state,
> including the GOSUB/FOR..NEXT stack) would be to POKE in the new start
> address and then GOTO 10 instead of RUN.

I think you'd have to do more than this since the interpreter won't know
the difference between Program A running and Program B. In other words,
the varibale A$ in Programs A&B will both point to the same variable
(hmmm...an interesting way to implement shared memory in BASIC!)

> If you do this, you better set LOMEM as well (but only once), or make sure
> the highest-loaded program is the first one RUN, so the variables start in
> a suitable place.

LOMEM does almost what you need: it moves the start of the variable data
pointer to the address specified with the command. However, I do believe
this initializes the variable space, which would not be good. I've never
devled into the way BASIC variables are kept but I am pretty sure that
they are searched for from the beginning of whatever LOMEM is to the end
(as given, I believe, by HIMEM). LOMEM and HIMEM simply set pointers in
the zero page that BASIC uses to keep track of the low and high memory
locations for variable storage. So manually keeping track of these and
POKEing them in for each swap should appropriately keep the variable
memory for each program in memory separate and intact.

I was just thinking that a sort of Multi-Tasking BASIC Operating System
(MTBOS) could be developed that would take care of all this for you.
Also, since the text screen on the Apple ][ can be defined by poking in
the left column, right column, top row and bottom row into the
appropriately zero page addresses, one can also specify a screen area that
each program is allowed to run in. This could be maintained by the MTBOS.

The MTBOS would basically reside somewhere in memory (a simple one could
probably be made to fit in $300-$3A0 which is the common unused space
where simple machine language utilities go) and can be CALLed from each
program running at regular intervals to allow a swap to the next process.
It would be sort of like Windows 3.0 :) (but probably faster).

I think when I have a couple hours to burn one day I'm going to build a
little demo of this for the hell of it. It would be a fun little exercise
and might end up making a cute VCF display of some sort.
Received on Wed May 17 2000 - 02:16:58 BST