Commander X16

Posted: **Wed Mar 03, 2021 3:43 pm**

Does anyone use the Acme or Ca65 include files for the VTUI library?

I ask because I am contemplating a restructure that probably will mean significant change in the include files...

Posted: **Wed Mar 03, 2021 4:24 pm**

I am using the assembled BIN file only, so no impact for me

Posted: **Sun Mar 14, 2021 9:15 am**

Library updated to version 0.7

Only real usage change is that print_str no longer accepts a zero-terminated string. Instead the length of string is provided in .Y also a lot of the functions can now skip color information if VERA stride is set to 2.

Posted: **Sun Mar 14, 2021 1:07 pm**

3 hours ago, JimmyDansbo said:

no longer accepts a zero-terminated string. Instead the length of string is provided in

aw... this now means for Prog8, that I have to iterate strings twice to print it (once to determine its length based on 0-termination, and then again in VTUI while printing it). It is what it is, I suppose. At least for constant strings I always know the lengths beforehand.

Posted: **Sun Mar 14, 2021 1:13 pm**

20 minutes ago, desertfish said:

aw... this now means for Prog8, that I have to iterate strings twice to print it

I am sorry for the inconvenience, but since print_str supports writing screen codes directly, we can not use a value as termination as all 256 bytes are occupied by characters.

@desertfish, I could possibly support zero-termination if the string is converted... Would that help?

Posted: **Sun Mar 14, 2021 2:57 pm**

1 hour ago, JimmyDansbo said:

we can not use a value as termination as all 256 bytes are occupied by characters

That makes sense... I actually don't have a proper way of dealing with screencode strings in Prog8 that require a zero character. It's always the terminator.

As for supporting it for converted strings: it would help a bit, but I think it's best to have a consistent API over sometimes supporting it and sometimes not supporting it (which could lead to confusion)

Posted: **Sun Mar 14, 2021 3:06 pm**

NULL is still NULL, there is no other control character mapped to zero. You should be able to use null termination, no problem. Doing a CHROUT with NULL has no effect.

Posted: **Sun Mar 14, 2021 5:22 pm**

2 hours ago, SlithyMatt said:

NULL is still NULL, there is no other control character mapped to zero.

When we are talking screencodes in VERA, 0 = @

So a zero-terminated string that is not converted from petscii to screencodes would not be able to write the @ sign.

Posted: **Sun Mar 14, 2021 7:16 pm**

1 hour ago, JimmyDansbo said:

When we are talking screencodes in VERA, 0 = @

Ok, it wasn't clear that you were talking about screen codes. Yeah, in that case you don't have a safe terminating character.

Posted: **Mon Mar 15, 2021 11:50 am**

20 hours ago, desertfish said:

That makes sense... I actually don't have a proper way of dealing with screencode strings in Prog8 that require a zero character. It's always the terminator.

As for supporting it for converted strings: it would help a bit, but I think it's best to have a consistent API over sometimes supporting it and sometimes not supporting it (which could lead to confusion)

A counted string that was converted FROM screencodes could be converted to one that was nul terminated. Then its the screencode converting routine that takes the count, not print_str.