04-13-2013, 03:55 PM
The version is still at 1.3.0s983.
You are already halfway there with the overhead of the error message and the check for empty string, another check for greater than 10 chars
would not break the bank to give error F or #14 [+1]. To allow any length you say, are you sure that the original ROM would support it, with the
MEMCALC area or support it in general? Can you load it back through the Orginal Basic? If no then you can only load it back through ZXB and then with
potentialy large headers compared to the standard 17 bytes. It means that is you are going to remove the limitation of 10 chars in the future then you only
have to change the truncate value to say, 255. But does it make any sense? Not in TAP files because you have the PC name and then the contents of the
TAP file. Spectrum disks are another matter so let's say that this limitation will get removed at some point. What will happen if you try to SAVE 11+ file
name in a code intented for the original Sinclair Basic? It would fail. Then an error message would be better than the illusion that every thing went
acccordingly and ALSO if the file name exceeds 255 chars, it does not matter the length the message has to be there. #Pragma CompatSave could be
used to change out the number 255 to 10 in the right places.
The code could be refactored so you have a generic save routine that works according to these conditions accross all devices and on all platforms, then
the only thing that woud change is the specific hardware routines and ROM calls DIRECTLY relating to those routines. Maybe I am confusing MEMBOT
(Calculator's memory area; used to store numbers that cannot conveniently be put on the calculator stack.) with CALC Mem but those routines that
you have are NOT DIRECTLY related to the SAVE/LOAD routines. It's a hack to save memory but it makes this a nighmare to refactor and to maintain and
strictly speaking I do not see the need for them, why not use the heap? And in the end I doubt that it will produce ANY memory savings at all. Just a
duplication of code when one version will just do fine or the heap routines. So you can use those savings for the 10/255 char test. Issues like these are
direcly related to memory management, not the individual routines and that makes things simpler.
Here the text never get's printed.
I am now looking into ways to hack up "load.asm" so the LOAD command does not pull the print routines in to surpress the "Bytes: filename" message
and to save memory, those PRINT rottines are REALLY big.
boriel Wrote:Yes, it always truncates to 10 Chars, to be compatible with original Sinclair BASIC, but ZXB could, in fact, allow any length.
The problem is, the more compatible with the original ROM, the more code I have to copy in the asm library (so your program will take more memory).
Code:
HEAD1 EQU MEM0 + 8 ; Uses CALC Mem for temporary storageYou are already halfway there with the overhead of the error message and the check for empty string, another check for greater than 10 chars
would not break the bank to give error F or #14 [+1]. To allow any length you say, are you sure that the original ROM would support it, with the
MEMCALC area or support it in general? Can you load it back through the Orginal Basic? If no then you can only load it back through ZXB and then with
potentialy large headers compared to the standard 17 bytes. It means that is you are going to remove the limitation of 10 chars in the future then you only
have to change the truncate value to say, 255. But does it make any sense? Not in TAP files because you have the PC name and then the contents of the
TAP file. Spectrum disks are another matter so let's say that this limitation will get removed at some point. What will happen if you try to SAVE 11+ file
name in a code intented for the original Sinclair Basic? It would fail. Then an error message would be better than the illusion that every thing went
acccordingly and ALSO if the file name exceeds 255 chars, it does not matter the length the message has to be there. #Pragma CompatSave could be
used to change out the number 255 to 10 in the right places.
The code could be refactored so you have a generic save routine that works according to these conditions accross all devices and on all platforms, then
the only thing that woud change is the specific hardware routines and ROM calls DIRECTLY relating to those routines. Maybe I am confusing MEMBOT
(Calculator's memory area; used to store numbers that cannot conveniently be put on the calculator stack.) with CALC Mem but those routines that
you have are NOT DIRECTLY related to the SAVE/LOAD routines. It's a hack to save memory but it makes this a nighmare to refactor and to maintain and
strictly speaking I do not see the need for them, why not use the heap? And in the end I doubt that it will produce ANY memory savings at all. Just a
duplication of code when one version will just do fine or the heap routines. So you can use those savings for the 10/255 char test. Issues like these are
direcly related to memory management, not the individual routines and that makes things simpler.
Code:
CLS
SAVE "SAVETEST"CODE 49152,256
PRINT "LOAD 1"
LOAD "SAVETEST"CODEHere the text never get's printed.
I am now looking into ways to hack up "load.asm" so the LOAD command does not pull the print routines in to surpress the "Bytes: filename" message
and to save memory, those PRINT rottines are REALLY big.