VTUI library

Greg King · Post by **Greg King** » Sat Feb 20, 2021 4:48 pm

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.

Greg King · Post by **Greg King** » Sat Feb 20, 2021 5:24 pm

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.

JimmyDansbo · Post by **JimmyDansbo** » Sat Feb 20, 2021 6:58 pm

@Greg King thanks, I will look into it.

4 bytes saved, thanks again ?

desertfish · Post by **desertfish** » Tue Feb 23, 2021 1:15 am

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?

Ender · Post by **Ender** » Tue Feb 23, 2021 1:49 am

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.

JimmyDansbo · Post by **JimmyDansbo** » Tue Feb 23, 2021 8:06 am

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

desertfish · Post by **desertfish** » Tue Feb 23, 2021 9:12 pm

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

Greg King · Post by **Greg King** » Tue Feb 23, 2021 9:48 pm

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 .

Greg King · Post by **Greg King** » Tue Feb 23, 2021 9:56 pm

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?)

desertfish · Post by **desertfish** » Tue Feb 23, 2021 10:14 pm

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: