Commander X16

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.

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.

@Greg King thanks, I will look into it.

4 bytes saved, thanks again ?

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?

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.

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 

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.

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 .

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

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: