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
Received on Wed May 17 2000 - 15:26:46 BST