You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't really an issue as much as an observation that can be easily overlooked.
OPTAB3
2963:FF 7F DW 32767 ; LENGTH RANGE
You might already be aware of this, but having this defined as a range 1 to 32767 for the L parameter, when you start at an even page boundary you will not get the last byte in the last page of memory that you might think you did.
To really save exactly 32K memory, the range would need to be 1 to 32768. Of course 32768 is 1 greater than "max int".
Thanks for the insight Tommy! I didn't realize there was an overflow / off-by-one bug lurking there.
Interesting "puzzle". Simple solution would be to use 3-bytes and fix the parser. If we are restricted to $FFFF then there are two conditions we need to check:
This isn't really an issue as much as an observation that can be easily overlooked.
OPTAB3
2963:FF 7F DW 32767 ; LENGTH RANGE
You might already be aware of this, but having this defined as a range 1 to 32767 for the L parameter, when you start at an even page boundary you will not get the last byte in the last page of memory that you might think you did.
To really save exactly 32K memory, the range would need to be 1 to 32768. Of course 32768 is 1 greater than "max int".
As examples:
BSAVE BIG,A$800,L$32767BSAVE BIG,A$800,L32767
BSAVE BIG,A$800,L$7FFF
These examples save memory from $0800 through $87FE (and not $87FF).
As a thought experiment, how would you ever designate you wanted to save all 64K of memory even with changing the value in OPTAB3 to 65535 (FF FF)?
[ Note: I edited this message to fix the first example. --Michael]
The text was updated successfully, but these errors were encountered: