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

image.png.ad7296af654a18d36f523d59f608f3af.png

If I remove the first call to print_str,  and leave the rest  of the codeuntouched, the result is:

image.png.12691bbf902da8469fc134d15bb13fb8.png

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:

image.png.48018952c7eadd2b627f45a4f001c3a7.png