Save bug (*solved*) - Printable Version +- Forum (https://www.boriel.com/forum) +-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12) +--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11) +---- Forum: Bug Reports (https://www.boriel.com/forum/forumdisplay.php?fid=15) +---- Thread: Save bug (*solved*) (/showthread.php?tid=536) Pages:
1
2
|
Save bug (*solved*) - Darkstar - 04-11-2013 Code: asm Heap size is 256 -O0 When saved to a blank .TAP file and that file is loaded back then the result is: "Bytes: SAVETEST??" This of course kills any possibillty of loading it back with: LOAD "SAVETEST"CODE The bug is present as far as I know in versions 1.3.0-s924, 1.3.0-s967 and 1.3.0-s979. Re: Save bug - boriel - 04-12-2013 *Confirmed*. This is a silly bug. The program name must be padded with spaces (not ASCII 0 chars). Try using "SAVETEST " (2 trailing spaces) as a workaround to see if it works. I will fix this ASAP. :roll: Re: Save bug - Darkstar - 04-12-2013 boriel Wrote:*Confirmed*. This is a silly bug. The program name must be padded with spaces (not ASCII 0 chars). Yeah, I thought that might be the case, not padding automatically with spaces and I am sure that the workaround will work or to write a routine myself and put it in a sub that will pad a string var of less than 10 chars in length to 10 chars with trailing spaces. Re: Save bug - boriel - 04-12-2013 I think it's now fixed. Can you Download Version 1.3.0s981 and check if SAVE now works as expected, please? :roll: Re: Save bug - Darkstar - 04-12-2013 I did just that and here are my results. Code: asm I did save it and then I loaded it back using the original BASIC or LOAD "SAVETEST"CODE from the "command" prompt and it worked. Then tried to do the same thing with the program above or to load it with LOAD "SAVETEST"CODE from compiled BASIC but it did not work. So I guess there is another bug in there. Re: Save bug - boriel - 04-12-2013 Hmm. I guess I have to fix it in LOAD routine also. :oops: Let me check it... Re: Save bug - Darkstar - 04-12-2013 I did: LOAD "SAVETEST"CODE LOAD "SAVETEST"CODE 49152,8192 LOAD "SAVETEST "CODE LOAD "SAVETEST "CODE 49152,8192 None of it did work. Re: Save bug - boriel - 04-13-2013 Darkstar Wrote:I did:I think it's now fixed. Can you Download Version 1.3.0s983 and check if LOAD now works as expected, please? :roll: Re: Save bug - Darkstar - 04-13-2013 Code: asm I did test it with the above code and it works and thank you for the fixes. It went through 1 - 6 and failed at #7 but I did expect #4 to fail and if not that then at least #5 but it did not. It works fine except for this odd behaviour. It is the same behavior as with the original BASIC but the original in case #5 accepts the load command but fails to load while the compiled BASIC loads it without a hitch, that is the only difference I see between the two. It does not make sense in my view to load with 11 chars when 10 is the maximum. I do not mind case #4. Re: Save bug - Darkstar - 04-13-2013 I have not tried to SAVE with 11 chars. Re: Save bug - Darkstar - 04-13-2013 Darkstar Wrote:I have not tried to SAVE with 11 chars.The original BASIC does not accept the command but comes up with: F Invalid file name, 0:1. The compiled BASIC accepts the command but truncates the last letter when saved to tape but I do hope that this does not lead to a buffer overflow of sorts. When saving with an empty string the original gives error message F while the compiled basic just falls through to the next executable statment giving no clue at all. Code: ERROR_Ok EQU -1 This could be mapped to error #9 but that would not be compatible with the original, I think file operations are important enough to add error message F. Otherwise this works fine. Re: Save bug - Darkstar - 04-13-2013 Code: CLS This was the code I came up with first but nothing got printed on the screen and I find that to be very odd. It was not until I add another PRINT line that something got on the screen or: Code: CLS I suspect another bug. Re: Save bug - Darkstar - 04-13-2013 Code: CLS The PRINT line here did work correctly, most probably this is a conflict with the "Start tape, then press any key." message that get's printed at the bottom of the screen. The POKE 23739,111 has been used to surpress the Bytes: header message from messing up the screen in loaders but this does not work in ZXB. Is there anyway to add this feature back in somehow? That would be really great. Re: Save bug - boriel - 04-13-2013 Darkstar Wrote:Yes, it always truncates to 10 Chars, to be compatible with original Sinclair BASIC, but ZXB could, in fact, allow any length.Darkstar Wrote:I have not tried to SAVE with 11 chars.The original BASIC does not accept the command but comes up with: F Invalid file name, 0:1. 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). Darkstar Wrote:When saving with an empty string the original gives error message F while the compiled basic justI've added ERROR_InvalidFileName EQU 14 The program will fail silently, as you said, when saving an empty string, but ERR_NR system variable will be set. And the error will be triggered if you exit to BASIC with that code set (try it, download latest version, 1.3.0s986). Re: Save bug - Darkstar - 04-13-2013 The version is still at 1.3.0s983. boriel Wrote:Yes, it always truncates to 10 Chars, to be compatible with original Sinclair BASIC, but ZXB could, in fact, allow any length. Code: HEAD1 EQU MEM0 + 8 ; Uses CALC Mem for temporary storage 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. Code: CLS 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. |