Page 6 of 11
VTUI library
Posted: Sat Feb 20, 2021 4:48 pm
by Greg King
On 2/18/2021 at 3:16 PM, JimmyDansbo said:
I think it is a very good idea to give the option of having print_str not convert anything, and I believe that it should fit. Thanks for the suggestion (I had actually thought of it, but forgot about it again).
edit: I have made the change, and it takes up only 2 bytes. ?
You can use the bit instruction to reduce the size of that macro. First, change the flag to be
.A = Convert string (0 = no conversion, $80 = convert)
Then, use
bit r2l
bpl +
You won't need to save the .Y register.
VTUI library
Posted: Sat Feb 20, 2021 5:24 pm
by Greg King
In the VTUI_BORDER macro, you have
lda r0h
sta VERA_ADDR_M
inc VERA_ADDR_M
You can increment the accumulator before you store it into that VERA register.
VTUI library
Posted: Sat Feb 20, 2021 6:58 pm
by JimmyDansbo
@Greg King thanks, I will look into it.
4 bytes saved, thanks again
?
VTUI library
Posted: Tue Feb 23, 2021 1:15 am
by desertfish
Did something break in print_str() in the 0.5 release? My test program now crashes if I use that function. It worked fine with 0.4. I made the change to load A instead of the Carry flag....
edit: looking at the code for it, I see there's a ldy r2h before the iny in the loop that looks like it should not be there?
VTUI library
Posted: Tue Feb 23, 2021 1:49 am
by Ender
30 minutes ago, desertfish said:
Did something break in print_str() in the 0.5 release? My test program now crashes if I use that function. It worked fine with 0.4. I made the change to load A instead of the Carry flag....
edit: looking at the code for it, I see there's a ldy r2h before the iny in the loop that looks like it should not be there?
Yeah, I noticed that too. The issue is, they removed "sty r2h" toward the beginning, without removing the "ldy r2h" toward the end. Removing that should fix it.
The calls to vtui_print_str in the examples also need to be updated to set A to $80 instead of 1, but that's a separate issue.
VTUI library
Posted: Tue Feb 23, 2021 8:06 am
by JimmyDansbo
6 hours ago, desertfish said:
Did something break in print_str() in the 0.5 release?
I was a bit premature in declaring the changes, Greg King suggested, a success
? We should be back to normal operation now. As stated, I have removed the ldy r2h and I have changed the print_str function to convert from petscii if .A=0
VTUI library
Posted: Tue Feb 23, 2021 9:12 pm
by desertfish
Sorry to nag again but I think there's another new issue regarding the decoding of petscii strings. Ignore the stuff below, the problem's caused by a bug in Prog8's string interning that I recently added and made a mistake in.
----
If I call the print routine like this (from prog8):
vtui.gotoxy(12,12)
vtui.print_str(@"Hello, world! vtui from Prog8!", $f2, $80)
vtui.gotoxy(12,13)
vtui.print_str("Hello, world! vtui from Prog8!", $f2, $00)
The first string is encoded in screencodes (because of the @-prefix) and will use the $80 parameter for print_str to not decode it.
The second string is encoded in petscii and will use the $00 parameter to let print_str decode it by itself to screencodes.
However something goes wrong now, have a look, it replaces/decode a lot of characters that shouldn't be touched...:
If I remove the first call to print_str, and leave the rest of the codeuntouched, the result is:
which is what I expected.
It seems that the routine has some internal state/status that carries over inadvertently across different calls.
VTUI library
Posted: Tue Feb 23, 2021 9:48 pm
by Greg King
13 hours ago, JimmyDansbo said:
We should be back to normal operation now. As stated, I have removed the "ldy r2h", and I have changed the print_str function to convert from petscii if .A=0
You should change the "INPUTS" description to show the new meaning of .A .
VTUI library
Posted: Tue Feb 23, 2021 9:56 pm
by Greg King
36 minutes ago, desertfish said:
It seems that the routine has some internal state/status that carries over inadvertently across different calls.
I don't see any persistence in that macro.
I think that the bug is in Prog8. It looks as though Prog8 converted both strings to screen codes! (Does Prog8 merge similar strings into a single copy?)
VTUI library
Posted: Tue Feb 23, 2021 10:14 pm
by desertfish
31 minutes ago, Greg King said:
It looks as though Prog8 converted both strings to screen codes! (Does Prog8 merge similar strings into a single copy?)
I am stupid, this is exactly what is happening! It's an optimization I recently added to the compiler and it looks like I made a mistake there
? Thanks Greg for pointing it out.
It works fine now after a bugfix there: