Save and Restore BASIC Variables (8-bit 6502 BASIC)

[Coeus]

This idea comes from discussion in viewtopic.php?p=374918#p374918. Shaun had a use for saving those BASIC variables that held assembler labels in order to do assembly with the BBC BASIC built-in assembler in two parts. Julie M said that saving the heap to disc and then patching the pointers on re-load was too complex and instead produced a program that would write a file that could subsequently be *EXECed to re-establish the variables. It also had some specific adaptations to this particular use.

I remained convinced that saving and restoring the heap was doable and presented a first attempt in the thread above. It turns out I had glossed over a complexity in that strings also have an embedded address, i.e. the value of a string variable is actually a string control block that contains a pointer to the actual characters. Then string arrays add yet more complexity.

For all that, I believe I have a working version of a pair of programs that enable all BASIC variables to be saved to a file then re-loaded into another program. There is a GitHUb repository: https://github.com/SteveFosdick/vsave where the README has more information and where you can, of course, browse the source code. I also attach an SSD with what I believe are the useful files on it. There are two BASIC programs SETUP and CHECK. SETUP sets up some variables and prints their values to a *SPOOL file, then saves them to a file with *VSAVE. CHECK loads the variables from the file with *VLOAD then prints them to a second *SPOOL file. These can then be compared to check all the values are correct after the re-load.

EDIT: SSD Updated to deal with FN/PROC pointers - see viewtopic.php?p=378837#p378837

[gfoot]

Nice! I did something similar in my build tools that I posted about here: viewtopic.php?t=24745

This wasn't to share them between build units - it was just to capture a symbol table for debugging purposes. I saved page 4 and the heap, then used a separate program to load them in and dump the variables. Actually i seem to recall I did also use a helper function at build time to look up the value of a variable, I don't recall why though.

[julie_m]

Well, I'm impressed!

For somebody to set out along the path I had already rejected for what seemed to me like cast-iron reasons, and then make good on it anyway ..... That's got to be worth a

The loading process is "clean" (or at least, about as clean as anything that stomps on internal pointers can ever be); and it even works with arrays, and values outside the range &0000 - &FFFF, and fractions -- i.e., all the stuff I deemed not important, just for persisting labels between assembling code segments.

I can see how this will have other use cases of its own.

[gfoot]

Merging them in with existing variables would be a neat trick too. I think you could still load the entire blob at the end of the heap and then adjust the linked lists. It'd be good to then also compact the heap, removing wasted space.

One thing to beware of is cached procedure/function pointers. I didn't check but maybe the code already clears those out.

[Coeus]

For somebody to set out along the path I had already rejected for what seemed to me like cast-iron reasons, and then make good on it anyway ..... That's got to be worth a

Thanks.

I can see how this will have other use cases of its own.

I didn't think through all possible use cases but I did want to do something that was more general than the assembler labels as that was an already solved problem. One that comes to mind is a program that uses a lot of static data to which it requires random access. or which relies on loading arrays with an initial state, and sets this up by using DATA statements and reading the data into arrays. This has the disadvantage that the data takes up space twice, once in the DATA statements and once in the heap. If memory is tight this could be alleviated by having one program read the DATA statements and set up the arrays, then save the heap, chain a second program that re-loads the heap, then uses the data previously set up.

[Coeus]

Merging them in with existing variables would be a neat trick too. I think you could still load the entire blob at the end of the heap and then adjust the linked lists. It'd be good to then also compact the heap, removing wasted space.

Merging would be a neat feature. The simplest way I can see to do this would be to load the parts of the saved file in the reverse order so the heap from the old program is loaded at the end of the heap of the new program. That means calculating the amount to load from the file size rather than the value embedded in the saved page four. Then the old page four can be loaded last. Finally, each of the lists needs to be merged.

I don't think there is anything there that is impossible to do but a merge version of the re-load program would then be quite a bit bigger and the current re-load program is pretty tight for space where I have chosen to load it. I wanted this to be tube-compatible so writing it as a service ROM to run on the I/O processor wouldn't achieve that. Loading it just under HIMEM would be another possibility. That is different on the 2nd processor and also according to screen mode on the I/O processor. Perhaps there could be two versions, one for HIBASIC and one for mode 7 on the I/O processor.

One thing to beware of is cached procedure/function pointers. I didn't check but maybe the code already clears those out.

That's a very good point. My original plan was to avoid re-loading those, so the bit of page four saved stops before these pointers, but then when I ran out of space and had to load some of the code at the end of page four that will have overwritten those pointers with code. I may be able to fiddle with what is where in the final file so zeros are loaded there. Hopefully BASIC will then build the cache afresh.

[Coeus]

I have updated the load program to load zeros into the PROC/FN list pointers. The changes are in GitHub and a new SSD in the first post.

[julie_m]

Merging variables directly into the database is going to be a bit of a headache. You'll have to check the name of each variable you are importing against the names already in the database and if it matches, overwrite the value that is already there; if not -- or if the new value for an existing string variable won't fit -- you will have to extend the chain.

Now you can see why I cheated