Moving Variable Data and Gaining Memory

Basic and Machine Language

Moderator: Moderators

Post Reply
User avatar
GreyGhost
Vic 20 Nerd
Posts: 525
Joined: Wed Oct 05, 2005 11:10 pm

Moving Variable Data and Gaining Memory

Post by GreyGhost »

I had this idea pop into my head today and wanted to ask the experts. It seems possible to move variable storage out of free RAM and have it some place else. I was thinking @ $a000. If this could be done, then all of Basic memory would be just for code. This would take away the myth that $a000 can only be used by ML prgs or data storage. One question would be, would this work for string storage as well?

Code: Select all

poke45,1:poke46,160:clr:rem**start of variables**
This would take care of numeric but I notice that string storage is not at the same place in memory. String memory starts at the end of Basic memory and work its way up.

Code: Select all

poke51,0:poke52,192:clr:rem**string storage**
Does this sound like it would work? Any hardware reasons why it wouldn't? This idea could even be used with the cassette buffer on unexpanded machines.
Rob
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Moving Variable Data and Gaining Memory

Post by Mike »

You can gain an extra byte at the start by POKEing POKE45,0:POKE46,160:CLR.

The top of string space in 51/52 is (re-)set from 55/56 if you do CLR, so it's better to do POKE55,0:POKE56,192:CLR.

Of course, all four POKEs are necessary for this technique (i.e. a single CLR at the end of the 4-POKE-sequence suffices), which comes handy when the program leaves less than 8K for variables in the "standard" BASIC range up to $7FFF. And yes, this works. Only thing, when SAVEing BASIC would attempt to take the end of the program from the start of the variables, and that would save character ROM and I/O along, which you wouldn't want. You'd have to run some kind of OLD/RENEW routine before SAVE to correct 45/46.

In MAXIGRAFIK, one option of the config. program was to put the entire BASIC workspace (including user program) into the range $A000..$BFFF. The VFLI panning viewer/slideshow also puts the room for BASIC into BLK5. (SCNR :mrgreen:)

Cheers,

Michael
malcontent
Vic 20 Hobbyist
Posts: 129
Joined: Sun Dec 26, 2010 1:51 pm

Re: Moving Variable Data and Gaining Memory

Post by malcontent »

GreyGhost wrote:This idea could even be used with the cassette buffer on unexpanded machines.
I'm curious if this would work too.
User avatar
GreyGhost
Vic 20 Nerd
Posts: 525
Joined: Wed Oct 05, 2005 11:10 pm

Re: Moving Variable Data and Gaining Memory

Post by GreyGhost »

malcontent wrote:
GreyGhost wrote:This idea could even be used with the cassette buffer on unexpanded machines.
I'm curious if this would work too.

I may have been a little hasty saying that about string variables, not understanding that their memory location is actually set by the bottom of memory, but it absolutely works with numeric variables.

Run this short program in VICE and then check the cassette buffer with the monitor.

Code: Select all

10 poke45,60:poke46,3:clr
20 a=36879:b=36878:c=36877:d=36876
30 print a,b,c,d
I would think the best way to get some usefulness out of this would be to use a loader program. Define custom characters, declare constants and variables and dimension arrays then load the main program. Would issuing a run command reset these pointers as well? Has anyone tried issuing a 'goto10' command in the keyboard buffer instead of run after a load?(mind wondering again).
Rob
Post Reply