Print String Bug (*solved*)

[britlion]

Confirmed - this demonstrates it. zxb 1.3.0-s928

Code:

DIM score as uLong


SUB displayScore(amount as ulong)
    ink 2
    dim a$ as string
    a$="000000"+STR$(amount)
    print at 12,12;a$(LEN a$-7 TO);"#"
END SUB


FOR score= 0 to 1000000 step 10
displayScore(score)
NEXT score

Should print a string, followed by a # - but the # ends up printing OVER the prior string, not after it and then on the next line and all over the place - the printed string seems to print beyond where it should. Seems to work on some numbers - so perhaps it's a STR$ bug? Though I think I've seen it on non STR$ stuff.


I just spent ages recompiling Berksman trying to find where on earth it was printing blank data across half the screen - It was the print line above! Not my fault!

[boriel]

This bug is related to string slicing.
Try this:

Code:

print at 12,12;a$(LEN a$-7 TO LEN a$ - 1);"#"

and it will work.

[britlion]

Good to know there's a workaround - but it's a reversion fault (and no longer Sinclair basic compatible). The released version of Berksman uses that code above, and it works perfectly.

What if you don't know the length of the String? Got to always use LEN to work it out and list it specifically? That would be bad

[boriel]

Good to know there's a workaround - but it's a reversion fault (and no longer Sinclair basic compatible). The released version of Berksman uses that code above, and it works perfectly.

What if you don't know the length of the String? Got to always use LEN to work it out and list it specifically? That would be bad

It's a bug. I'm fixing it.
It's pretty strange: I detected a bug in it, and fixed it, introducing this new one. :oops:

[boriel]

I think I got it!
Please, download Version 1.3.0s934 and tell me if it works, please :?:

[britlion]

I was going to say that your workaround didn't

(I was playing Berksman, which adds score in units of 10, and then noticed my score was 4552. Where did that 2 come from?!

I'll try the new version. Thankyou. (What was the bug?)

[britlion]

Hmm.

Nope. Playing Berksman, and I still have a score of 4554. Something's not right there. If you can't see it, I'll see if I can make a test case for it.

[britlion]

Ack! I think it's my bad. I think the score really is 3108 Something went wrong in the ghost eating score bit somewhere.

I think you fixed the issue with Print! Very well done.

What was it?



EDIT: I found it. I was sending the "addScore(amount as uByte)" function numbers like 400. 400 > byte, and truncation made for some unexpected numbers. Doh!

[boriel]

A problem with "string slicing" asm routine. Basically, when using a$(X TO Y) if Y > len(a$), it should be converted to A$(X TO LEN(a$) - 1). This is done very fast internally, in asm with few instructions. But I forgot to subtract the "-1" (needed because we are using 0-index based strings). This was making the routine to misbehave and sometimes even doing the wrong truncation.

[boriel]

Ack! I think it's my bad. I think the score really is 3108 Something went wrong in the ghost eating score bit somewhere.

I think you fixed the issue with Print! Very well done.

What was it?



EDIT: I found it. I was sending the "addScore(amount as uByte)" function numbers like 400. 400 > byte, and truncation made for some unexpected numbers. Doh!

So I could mark it as "*solved*", couldn't I?

[britlion]

Oh yes - when I said it seemed to be fixed, I meant that

You definitely did. Well done! Thanks, Boriel.

[boriel]

Oh yes - when I said it seemed to be fixed, I meant that

You definitely did. Well done! Thanks, Boriel.

Ok! One less.
I'm also doing some FP optimization within the compiler, BTW
I understand why FP is slower in ZX Basic than in Sinclair BASIC (twice slower), and I'm afraid it's going to be hard to fix it, since using the ROM FP calculator from the "outside" requires many hacks :|

[britlion]

You could consider pulling apart tobos compiler for maths algorithms?

That's scary fast for FP. Faster than some integer compilers!

I'm not that much of a math head, so working from disassembly to how it works really isn't my forte - despite hacking up some sqr stuff

[boriel]

You could consider pulling apart tobos compiler for maths algorithms?

That's scary fast for FP. Faster than some integer compilers!

I'm not that much of a math head, so working from disassembly to how it works really isn't my forte - despite hacking up some sqr stuff

Thanks for the info!!
I've read TOBOS uses a shorter (less precise) FP format. ZX Spectrum uses 5 bytes (4 bytes for mantissa + 1 byte for exponent). This one uses a different (shorter) format of 4 bytes. I will look for FP routines to see if I could make my own or even rip (permission needed?) TOBOS' ones.

[britlion]

I didn't know that.

I wonder how much overhead you'd need to go from 5 byte to its 4 byte system and back?

I think many of these routines will be needed in the long run to keep the compiler fully functional for other computers - can't rely on the rom always!