Print String Bug (*solved*) - Printable Version

Print String 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: Print String Bug (*solved*) (/showthread.php?tid=509)

Print String Bug (*solved*) - britlion - 11-12-2012

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 Smile

- It was the print line above! Not my fault!

Re: Print String Bug - boriel - 11-12-2012

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.

Re: Print String Bug - britlion - 11-12-2012

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 Sad

Re: Print String Bug - boriel - 11-12-2012

britlion Wrote: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:

Re: Print String Bug - boriel - 11-13-2012

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

Re: Print String Bug - britlion - 11-13-2012

I was going to say that your workaround didn't Smile

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

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

Re: Print String Bug - britlion - 11-13-2012

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.

Re: Print String Bug - britlion - 11-13-2012

Ack! I think it's my bad. I think the score really is 3108 Smile

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! Smile

Re: Print String Bug - boriel - 11-13-2012

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.

Re: Print String Bug - boriel - 11-17-2012

britlion Wrote: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?

Re: Print String Bug - britlion - 11-17-2012

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

You definitely did. Well done! Thanks, Boriel.

Re: Print String Bug - boriel - 11-17-2012

britlion Wrote: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 :|

Re: Print String Bug (*solved*) - britlion - 11-17-2012

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 Smile

Re: Print String Bug (*solved*) - boriel - 11-18-2012

britlion Wrote: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.

Re: Print String Bug (*solved*) - britlion - 12-08-2012

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!