Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PRINT bug using CHR$(22) for inline positioning (*solved*)
#1
Bug 
It seems as if the compiler gets this wrong when the x coord is greater than 27. See example:
Code:
DIM a$, b$ AS String
CLS
a$=CHR(22,17,27,65,66) 'PRINT AT 17,27;"AB" - fine
b$=CHR(22,18,28,67,68) 'PRINT AT 18,28;"CD" - wrong location (19,0)
c$=CHR(22,19,29,69,70) 'PRINT AT 19,29;"EF" - wrong location (20,0)
PRINT a$;b$;c$
PRINT AT 20,28;"GH"                        '- fine
PRINT AT 18,0;"--"                         '- fine

At x=28 there is adequate space to print the two characters "CD" before the line wrap,  but strangely they end up being PRINTed AT 19,0 instead of AT 18,28. I presume it's because the compiler is forgetting that CHR$(22) and the following two special characters do not count towards the PRINTed length of the string. Will this error also occur for the other inline control codes for INK, PAPER, BRIGHT, OVER, etc.?

This error is present in the the latest stable release 1.13.2, and the betas for 1.14 (which I gather had some PRINT changes). Being able to set the coordinates and attributes inline like this is useful for manipulating pre-formed sprites.
Reply
#2
This might be a bug related to screen positioning (INPUT) we discussed recently. Let's review this.
PRINT is not that of the ROM. Hence not all corner cases has been tested (and thanks for that!),
I'll keep you updated with any fix.
Reply
#3
More test cases below:
Code:
DIM a$, b$ AS String
CLS
PRINT AT 0,0;PAPER 5;CHR(32)      '                    - fine
a$=CHR(22,1,27,65,66)             'PRINT AT 1,27;"AB"  - fine
b$=CHR(22,2,28,67,68)             'PRINT AT 2,28;"CD"  - wrong location (3,0)
c$=CHR(22,3,29,69,70)             'PRINT AT 3,29;"EF"  - wrong location (4,0)
d$=CHR(22,4,28,71)                'PRINT AT 4,28;"G"   - wrong location (5,0) - would have expected success here if the bug is char count
e$=CHR(22,5,29,71)                'PRINT AT 5,29;"G"   - wrong location (6,0)
f$=CHR(22,6,27,16,2,17,5,19,1,71) 'PRINT AT 6,27;"G"   - fine, so other control codes are not counted
g$=CHR(22,7,10,17,0,23,31,0,32)   'PRINT AT 7,10; INK 0; TAB 31; " " last char is wrong. Should be a space
PRINT AT 8,31;"-"                 'to measure the wrong positions
PRINT a$;b$;c$;d$;e$;f$;g$
PRINT AT 10,28;"HI"               'fine at same coords
PRINT AT 2,0;"--"                 'to measure the wrong positions
Reply
#4
Many thanks for your help! (really)

Here you are a potential fix!
http://www.boriel.com/files/zxb/zxbasic-...ta4.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta4.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz

Please, let me know if it works.
Reply
#5
I can confirm that beta release has fixed the positioning issues. However g$ still has the issue of CHR$(32) rendering as a backslash instead of a space in column 31. It's fine in column 0 though (see first PRINT statement).
Reply
#6
That one is related to TAB corrupcion. Let mi fix that...
Reply
#7
Photo 
I cannot reproduce the problem with "\" character.

EDIT: yes, it's a buffer corruption upon tab usage. Sad
This is what I get:
[Image: attachment.php?aid=309]
[image:attachment=309]


Attached Files
.png   screenshot.png (Size: 6.2 KB / Downloads: 323)
Reply
#8
It should be producing a black bar (black paper TABs) from column 10 to 31. I'm using FUSE emulator. Notice the red backslash character in what should be a space at column 31:
[Image: attachment.php?aid=308]

.png   CHR 32.png (Size: 3.69 KB / Downloads: 335)


I notice that 1.14beta4 re-introduces the PAUSE problems you had fixed in beta3. Are they completely separate test builds, or should beta4 include the fixes from previous betas?
Reply
#9
(12-30-2020, 10:34 PM)patters Wrote: It should be producing a black bar (black paper TABs) from column 10 to 31. I'm using FUSE emulator. Notice the red backslash character in what should be a space at column 31:

...

I notice that 1.14beta4 re-introduces the PAUSE problems you had fixed in beta3. Are they completely separate test builds, or should beta4 include the fixes from previous betas?

Okay, I think I've fixed it!
Can you try this version, plz? Rolleyes

http://www.boriel.com/files/zxb/zxbasic-...ta5.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta5.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
Reply
#10
Yes thanks that's fixed the erroneous backslash character for CHR$(32) in column 31.

However, PAUSE is still being skipped with this build when using INPUT. Is that expected?
Reply
#11
(12-31-2020, 12:47 AM)patters Wrote: Yes thanks that's fixed the erroneous backslash character for CHR$(32) in column 31.

However, PAUSE is still being skipped with this build when using INPUT. Is that expected?

Sorry, I sent you a version without previous fixes merged. Here you're one with all the fixes (the byref is still in progress, sorry):
http://www.boriel.com/files/zxb/zxbasic-...ta6.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta6.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
Reply
#12
Hi this 1.14beta6 build does appear to have fixed all the issues (including PAUSE one), however I notice some corruption in the PRINT function when the program runs for the second time, which wasn't the case before. I run my program repeatedly because I'm trying to perfect a randomised terrain generation algorithm so I need to verify its results.

Unfortunately I cannot reproduce the following issue in a simplified test program. My program clears the bottom line after an INPUT. What I see is that if I compile with 1.14Beta6 this works ok. My program ends with a STOP. If I simply run again (by re-invoking the Tape Loader by pressing Enter) that same PRINT statement doesn't clear the input line. If I deliberately enter a nonsense alphabetical input, instead of seeing my warning text "Entry Error" I see it garbled as if it is overwriting the INPUT question with OVER 1. But the first execution is fine. Only subsequent executions are bad. I will PM you my code.
Reply
#13
(01-02-2021, 07:43 PM)patters Wrote: Hi this 1.14beta6 build does appear to have fixed all the issues (including PAUSE one), however I notice some corruption in the PRINT function when the program runs for the second time, which wasn't the case before. I run my program repeatedly because I'm trying to perfect a randomised terrain generation algorithm so I need to verify its results.

Unfortunately I cannot reproduce the following issue in a simplified test program. My program clears the bottom line after an INPUT. What I see is that if I compile with 1.14Beta6 this works ok. My program ends with a STOP. If I simply run again (by re-invoking the Tape Loader by pressing Enter) that same PRINT statement doesn't clear the input line. If I deliberately enter a nonsense alphabetical input, instead of seeing my warning text "Entry Error" I see it garbled as if it is overwriting the INPUT question with OVER 1. But the first execution is fine. Only subsequent executions are bad. I will PM you my code.

Ok, I see the problem is you use OVER 1 at line #190.
When you exit the program to BASIC OVER 1 is still set. ZX Basic uses the same ROM variables as Sinclair BASIC. So if you use OVER 1 and exits to BASIC, OVER 1 will remain.

User OVER 0 at the beginning (or set OVER 0 again after the drawing), and that should fix it. Can you try, please?
Reply
#14
Yes that's fixed it. I feel a bit of an idiot now. Once I encountered some issues with the compiler, I guess I started to believe it was more likely that another bug had crept in, rather than my code being at fault. Very bad assumption!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)