I'm doing a little playing around with a simple hacky little assembly routine I would be calling from BASIC, and it just occurred to me that it would be nice if my routine could directly interact with (well, at least read) the value of an integer type variable that gets set by BASIC before calling the routine. I'll initialize that variable as the very first one used in the BASIC program, which means it would be directly after the triple-zed that marks the end of the BASIC program in memory.
Consequently, I need to know VARTAB (pointer for the start of variables in BASIC) so I can calculate the memory locations for the bytes holding the value.
I see 'basic.sym' included with the official emulator r38 release which tells me an address for VARTAB, but unless I'm mistaken that particular .sym file is the result of compiling this particular ROM version build. Glancing at the current repo of the rom source it seems clear VARTAB could (perhaps would?) change between builds and in the official version shipped with the release hardware. Even once the hardware is actually in circulation, if there's a facility for reflashing the ROM with updates or fixes or whatever, that could mean one probably shouldn't rely on this address as set in stone.
For now, I'm just going to hard-code in the current address for VARTAB as I go about experimenting with this, but if I wind up using this routine I'd be really reluctant to release the program with a hard-coded VARTAB that would break the program if the address for VARTAB changes in a future rom release.
Now, I suppose I can write a loop that runs through memory values from start of BASIC and stops when it finds three consecutive zeros and calculates VARTAB as the next byte after the triplet, but ... is there an easier way? Also, come to think of it... has there been any indication that things like VARTAB or other 'important BASIC addresses/pointers' that come up a lot in more advanced BASIC work would be normalized/standardized so they don't change once the final ROM is put to bed, even in the event of little ROM updates or whatever?
Question
Snickers11001001
I'm doing a little playing around with a simple hacky little assembly routine I would be calling from BASIC, and it just occurred to me that it would be nice if my routine could directly interact with (well, at least read) the value of an integer type variable that gets set by BASIC before calling the routine. I'll initialize that variable as the very first one used in the BASIC program, which means it would be directly after the triple-zed that marks the end of the BASIC program in memory.
Consequently, I need to know VARTAB (pointer for the start of variables in BASIC) so I can calculate the memory locations for the bytes holding the value.
I see 'basic.sym' included with the official emulator r38 release which tells me an address for VARTAB, but unless I'm mistaken that particular .sym file is the result of compiling this particular ROM version build. Glancing at the current repo of the rom source it seems clear VARTAB could (perhaps would?) change between builds and in the official version shipped with the release hardware. Even once the hardware is actually in circulation, if there's a facility for reflashing the ROM with updates or fixes or whatever, that could mean one probably shouldn't rely on this address as set in stone.
For now, I'm just going to hard-code in the current address for VARTAB as I go about experimenting with this, but if I wind up using this routine I'd be really reluctant to release the program with a hard-coded VARTAB that would break the program if the address for VARTAB changes in a future rom release.
Now, I suppose I can write a loop that runs through memory values from start of BASIC and stops when it finds three consecutive zeros and calculates VARTAB as the next byte after the triplet, but ... is there an easier way? Also, come to think of it... has there been any indication that things like VARTAB or other 'important BASIC addresses/pointers' that come up a lot in more advanced BASIC work would be normalized/standardized so they don't change once the final ROM is put to bed, even in the event of little ROM updates or whatever?
cheers, Snick.
Link to comment
Share on other sites
15 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.