Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Save bug (*solved*)
#1
Code:
asm
jr ZXBASICBorielVersionEnd
db "ZX Boriel BASIC version 1.3.0-s979"
ZXBASICBorielVersionEnd:
end asm

SAVE "SAVETEST"CODE 49152,8192

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.
Reply
#2
*Confirmed*. This is a silly bug. The program name must be padded with spaces (not ASCII 0 chars). Sad
Try using "SAVETEST " (2 trailing spaces) as a workaround to see if it works. I will fix this ASAP. :roll:
Reply
#3
boriel Wrote:*Confirmed*. This is a silly bug. The program name must be padded with spaces (not ASCII 0 chars). Sad
Try using "SAVETEST " (2 trailing spaces) as a workaround to see if it works. I will fix this ASAP. :roll:

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.
Reply
#4
I think it's now fixed.
Can you Download Version 1.3.0s981 and check if SAVE now works as expected, please? :roll:
Reply
#5
I did just that and here are my results.

Code:
asm
jr ZXBASICBorielVersionEnd
db "ZX Boriel BASIC version 1.3.0-s981"
ZXBASICBorielVersionEnd:
end asm

'SAVE "SAVETEST"CODE 49152,8192
LOAD "SAVETEST"CODE

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.
Reply
#6
Hmm.
I guess I have to fix it in LOAD routine also. :oops:
Let me check it...
Reply
#7
I did:
LOAD "SAVETEST"CODE
LOAD "SAVETEST"CODE 49152,8192
LOAD "SAVETEST "CODE
LOAD "SAVETEST "CODE 49152,8192

None of it did work.
Reply
#8
Darkstar Wrote:I did:
LOAD "SAVETEST"CODE
LOAD "SAVETEST"CODE 49152,8192
LOAD "SAVETEST "CODE
LOAD "SAVETEST "CODE 49152,8192

None of it did work.
I think it's now fixed.
Can you Download Version 1.3.0s983 and check if LOAD now works as expected, please? :roll:
Reply
#9
Code:
asm
jr ZXBASICBorielVersionEnd
db "ZX Boriel BASIC version 1.3.0s983"
ZXBASICBorielVersionEnd:
end asm

CLS
SAVE "SAVETEST"CODE 49152,256

PRINT
PRINT "LOAD 1"
LOAD "SAVETEST"CODE

PRINT
PRINT "LOAD 2"
LOAD "SAVETEST"CODE 49152

PRINT
PRINT "LOAD 3"
LOAD "SAVETEST"CODE 49152,256

PRINT
PRINT "LOAD 4"
LOAD "SAVETEST  "CODE ' ten chars

PRINT
PRINT "LOAD 5"
LOAD "SAVETEST   "CODE ' 11 chars

PRINT
PRINT "LOAD 6"
LOAD ""CODE

PRINT
PRINT "LOAD 7"
LOAD "SAVETESTx"CODE

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.
Reply
#10
I have not tried to SAVE with 11 chars.
Reply
#11
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
    ERROR_SubscriptWrong    EQU     2
    ERROR_OutOfMemory       EQU     3
    ERROR_OutOfScreen       EQU     4
    ERROR_NumberTooBig      EQU     5
    ERROR_InvalidArg        EQU     9
    ERROR_IntOutOfRange     EQU    10
    ERROR_InvalidColour     EQU    19
    ERROR_BreakIntoProgram  EQU    20
    ERROR_TapeLoadingErr    EQU    26

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.
Reply
#12
Code:
CLS
SAVE "SAVETEST"CODE 49152,256

PRINT "LOAD 1"
LOAD "SAVETEST"CODE

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
SAVE "SAVETEST"CODE 49152,256

PRINT
PRINT "LOAD 1"
LOAD "SAVETEST"CODE

I suspect another bug.
Reply
#13
Code:
CLS
PRINT "HI!"
POKE 23739,111
LOAD ""CODE

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.
Reply
#14
Darkstar Wrote:
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.
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).
Darkstar Wrote:When saving with an empty string the original gives error message F while the compiled basic just
falls through to the next executable statement giving no clue at all.

Code:
    ERROR_Ok                EQU    -1
    ERROR_SubscriptWrong    EQU     2
    ERROR_OutOfMemory       EQU     3
    ERROR_OutOfScreen       EQU     4
    ERROR_NumberTooBig      EQU     5
    ERROR_InvalidArg        EQU     9
    ERROR_IntOutOfRange     EQU    10
    ERROR_InvalidColour     EQU    19
    ERROR_BreakIntoProgram  EQU    20
    ERROR_TapeLoadingErr    EQU    26
I'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).
Reply
#15
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.
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 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
SAVE "SAVETEST"CODE 49152,256
PRINT "LOAD 1"
LOAD "SAVETEST"CODE

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.
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)