Cool AppleSoft BASIC trick I never thought of before - test-drb@ccmp.vtda.org

17 May 2000

On May 17,  0:16, Vintage Computer GAWD! wrote:
...
  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!) 
That's right; I just assumed you wanted to keep all the variables around
all the time.  If you want something more like a real mutitasking system,
and program independence (not to have to worry about variables in one
program sharing names with those in another) then you need to
save-and-restore all the relevant pointers: start of variable space, start
of arrays, end of numerics, start of strings.  Maybe more (I've not tried
it personally).

...
  > 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. 
No, it wouldn't be good, and the LOMEM comand probably does reset the other
pointers (I can't check, my Apples are both in store at the moment).  I
really just meant "set the LOMEM pointer".

...
  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. 
Yes, the variables aren't stored in any specially structured way (they are
in some other BASICs).  You probably want to keep track of the end of
string space as well (HIMEM, essentially) and make liberal use of FRE() to
minimise waste.

...
  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). 
Yes, probably :-)  Since you wouldn't need much code, and nothing on a
standard Apple uses interrupts, you could go one further and make it a
time-sliced system instead of a cooperative one, with a very simple circuit
(not much more than a 555 timer, though you might want it on a card with a
PROM to hold the code).

-- 

Pete						Peter Turnbull
						Dept. of Computer Science
						University of York