Finding end of progam memory/beginning of EPROM on non-BS1
Tom F
Posts: 59
I'm surprised that the BS2 doesn't have a progammatic way to find how much EPROM is not being used by the program.
If I'm collecting data, I want to know how much space I've got!
It seems sort of risky to depend on me f to periodically check the memory map to see if my program has grown and then change my source code so that it doesn't acccidentally overwrite my program space.
I was thinking that there must be a programmatic way to do this. Can I assume that EPROM is zeroed when a program is downloaded to it? If so, then when a program starts, it could start at the top of the EPROM memory and search until it finds EPROM that has non-zero contents. Wouldn't that be the end of the memory the program uses? And, having done so, it could put the result at the top memory location of the EPROM so it didn't search during subsequent runs.
(Depending on where DATA statements are stored, perhaps I could even put a "unique" bit pattern at the end of the last Data statement in the program and search for that. Might make the code more robust.)
Or is there a better way?!
If I'm collecting data, I want to know how much space I've got!
It seems sort of risky to depend on me f to periodically check the memory map to see if my program has grown and then change my source code so that it doesn't acccidentally overwrite my program space.
I was thinking that there must be a programmatic way to do this. Can I assume that EPROM is zeroed when a program is downloaded to it? If so, then when a program starts, it could start at the top of the EPROM memory and search until it finds EPROM that has non-zero contents. Wouldn't that be the end of the memory the program uses? And, having done so, it could put the result at the top memory location of the EPROM so it didn't search during subsequent runs.
(Depending on where DATA statements are stored, perhaps I could even put a "unique" bit pattern at the end of the last Data statement in the program and search for that. Might make the code more robust.)
Or is there a better way?!
Comments
And program code is loaded at the 'top' of memory. 'Data' is loaded from location zero up, while code is loaded from the maximum address, down.
And I believe there is a 'magic variable' value -- Jon can tell you what it is -- that indicates the lowest location used by your program.
And, it looks like a program always begins on a 16-bit boundry with at least one word with zeros. So I could search from the bottom of EPROM for those zeroes (assuming the tokenizer doesn't ever tokenize a word of zero.
Anyway, I'm just thinking outloud. If there is a magic variable or other way to go about this, great.
In fact, if there are other magic variables in addition to one for this, I'd love to know where they're documented. (I understand that all of this is probably platform and interpreter dependent... but that's better than depending on my memory!)
DATA 0(2048)
Then when you subsequently load a program, the unused memory will be a contiguous block of zeros starting at location 0.
The program itself STARTs at location 2047 and works down in memory. So the program's lowest address is actually the last instruction in the program.
The IDE downloads blocks of 16 bytes (128 blocks to make 2048). If the program uses part of a 16 byte block, the IDE will zero the remaining bytes in that one block.
There is AFAIK no single pointer to the end of the program/start of free eeprom. Are you working with an original BS2? The BS2p series has additional eeprom that is easy to access with less concern about running over or out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com