VTUI library

Cyber · Post by **Cyber** » Tue Feb 16, 2021 11:39 pm

Yeah, looks appealing to me as well!

JimmyDansbo · Post by **JimmyDansbo** » Wed Feb 17, 2021 5:07 am

Please let me know when you find typos, errors and bugs. It seems I quickly "go blind" when looking at my own text and source.

desertfish · Post by **desertfish** » Wed Feb 17, 2021 9:10 am

I was reading the rather excellent documentation and found this:

"Addresses used are $22 - $2D this is to avoid using the ABI registers used by the new Commander X16 functions. "

Why did you choose this? There are sixteen Cx16 ABI registers, more than enough I would think to (re)use them yourself?

If they're only used for arguments or return values for the VTUI's functions there shouldn't be any issue to just use a couple of the r0..r15 registers for that? The code has to set them anyway to call a routine in rom or library either way, I think

I'm zooming in on this one in particular because as it is currently, I won't be able to use the library in Prog8. Prog8 assumes a certain fixed free block of zero page to store its own variables, and it is only aware of the ZP space taken up by the cx16's abi virtual registers and the reserved block from $80 upwards...

kliepatsch · Post by **kliepatsch** » Wed Feb 17, 2021 10:59 am

+1 Good point. I think even the initialization routine would be perfectly fine running from within the r0 to r15 registers. No need to use up additional ZP space, as far as I can tell, anyway.

JimmyDansbo · Post by **JimmyDansbo** » Wed Feb 17, 2021 2:26 pm

5 hours ago, desertfish said:

Why did you choose this? There are sixteen Cx16 ABI registers, more than enough I would think

I have not looked into using the new ABI in the kernal and therefor I decided to just leve those registers alone to ensure that I did not interfere with something that would use those registers. The ABI registers are plenty of space for the VTUI library and I have no issue moving it to use r0, r1, r2 and so on.

desertfish · Post by **desertfish** » Wed Feb 17, 2021 5:15 pm

Should be good as long as you're not storing global variables in them, I suppose, only temporary function arguments/returnvalues

Thanks for considering the modification

JimmyDansbo · Post by **JimmyDansbo** » Wed Feb 17, 2021 8:17 pm

VTUI updated to version 0.3

Now it uses zeropage registers r0 to r5

desertfish · Post by **desertfish** » Thu Feb 18, 2021 1:35 am

Fantastic work @JimmyDansbo ; also on the documentation: even now for this early version it's already super clear and detailed.

It allowed me to easily interface to the library from Prog8 and I've been playing with it for a bit! Got it to work quite smoothly (mostly):

Without a doubt you'll notice a few of the letters are weird. This is because I was attempting to use vtui with upper+lowercase charset. The petscii translation routines seem overly restrictive with the characters that they accept... I was attempting to print "Hello, world! VTUI from Prog8!".

Here's my list of findings so far:

question: any particular reason fill_box() require the character to be in R0H ? This complicates things a little bit for me because Prog8 treats the R-registers strictly as words. Suggestion: Can't this parameter be in A, like the mode for border()?

question: any particular reason fill_box(), border(), save_rect() and rest_rect() require the dimensions to be in a single R1 register rather than splitting the width and height across say R1L and R2L? (same reason for me as #1 above)

suggestion: add a few more box types that look nice with the Upper+Lowercase characters charset. Currently only border mode 0 and 1 are ok in this case. Perhaps also provide a way to specify the exact box character?

suggestion: let the initialize function also immediately set the 'sane' / most used default settings for vera stride and increment, without requiring screen_set() ?

suggestion: the petscii-to-screencode translation and vice versa, is now quite restrictive. My "Hello, world! VTUI from Prog8!" is printed as "Vello world! VVVV from Vrog8!" as you can see in the screenshot. Can we perhaps improve this to map more characters

bug: calling initialize twice makes other calls crash

bug in doc: rest_rest() documentation is incorrect in the register table, 'Purpose' column seems copied from save_rect()

bug: a set_decr() with C=1 (decrement) seems to misalign character+color output for instance when using print_str() afterwards in an attempt to print in reverse. This is visible in the second text line in the screenshot.

I'm willing to help improve the library for things like this and add PR's on github if you want?

JimmyDansbo · Post by **JimmyDansbo** » Thu Feb 18, 2021 7:05 am

@desertfish thank you for your kind words. The documentation part is the hardest ? It is great to see that you have been able to interface with library.

Let me address your points.

Not really any particular reason other than at the time of writing the function, it seemed easier to pass the variable that way. - On my TODO.

Again, no particular reason other than keeping parameters tight. I see no issue changing it to just use the low part of the 16bit registers - On my TODO.

At the moment, the library only supports the default character set, but the addition of a custom character for border is a good idea.

The initialize function only exist in the generic library, not the include files and only has to do with initializing the jump table. I would like to keep the functionality of the different flavors the same. If the initialize function were to change settings in VERA as well, someone coming from the generic library to one of the include files might run into issues.

The conversion functions pet2scr and scr2pet (also used in print_str) are very limited, that is again because the library only support default character set at the moment.

I will look into this - On my TODO

Good catch, will fix - On my TODO

None of the library functions are designed to function with the decrement bit set and all expect the increment to be set to 1

As you know, I am aiming at a library size below 1K in order to have it reside in Golden RAM. This restriction means that error detection/correction has been omitted it also means that it might be hard to add much more functionality.

I thank you for your kind offer to help. For now I would like to try and figure this out my self as this is still a learning experience for me. If you find that I am too slow or going in the wrong direction, feel free to let me know.

Ender · Post by **Ender** » Thu Feb 18, 2021 8:07 am

Looking good! A couple of minor things I see:

Line 27 in acme-ex01.asm is "lda 0", you probably want "lda #0".

The ".org" line in ca65-ex01.asm is unnecessary, the "CODE" segment already handles putting the code at the correct address.

Can't wait to see more stuff use this, your screenshots look good.