VTUI library

[JimmyDansbo 153]

@Greg King Thanks. I am afraid that in the meantime things have changed again and I have actually updated both the source and the documentation.

If you find that I am overconfident, please let me know and show me once more.

Thank you very much for your interest and your help

[Greg King 65]

2 hours ago, JimmyDansbo said:

@Greg King Thanks. I am afraid that in the meantime things have changed again and I have actually updated both the source and the documentation.
If you find that I am overconfident, please let me know, and show me once more.

I know -- 0.6 version.  Those links are current -- try them.

Edited February 27 by Greg King

[JimmyDansbo 153]

12 hours ago, Greg King said:

I know -- 0.6 version.  Those links are current -- try them.

Ahh... Finally I see it. I had it mixed.

Here in Denmark we have a saying: The eyes are usually the first to go blind...

Anyway, I bumped the version to 0.6a as there are a few changes in usage. - See the downloads section or github.

Edited February 28 by JimmyDansbo
Give information about version-bump

[Jakebullet70 9]

I am a little confused here. (Normal for me) Can this be called from BASIC or only ASM programs at this point? 

[JimmyDansbo 153]

44 minutes ago, Jakebullet70 said:

Can this be called from BASIC or only ASM programs at this point?

The VTUI library is designed to be called from the likes of Assembler and C. It is not designed to be called from BASIC.

When that is said, it should be possible to call the library from BASIC by POKE'ing the needed values to 780-782 for CPU registers and 02-.. for zeropage registers and then calling the needed function with SYS

Quote

5 REM LOAD LIBRARY TO ADDRESS $400
10 LOAD"VTUI0.6A.BIN",8,1,$400
15 REM INITIALIZE THE LIBRARY
20 SYS $400
25 REM SET .A CPU-REG TO 0 FOR 40X30 MODE
30 POKE 780,0
35 REM CALL VTUI-SET-SCREEN
40 SYS $402

For more information on passing CPU registers from BASIC, have a look at this page: https://www.c64-wiki.com/wiki/SYS

Edited March 2 by JimmyDansbo

[JimmyDansbo 153]

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

[desertfish 323]

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

[JimmyDansbo 153]

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.

[desertfish 323]

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.

[JimmyDansbo 153]

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?

Edited March 14 by JimmyDansbo

[desertfish 323]

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)

[SlithyMatt 595]

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.

[JimmyDansbo 153]

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.

[SlithyMatt 595]

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.

[BruceMcF 288]

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.

Edited March 15 by BruceMcF

[JimmyDansbo 153]

Now there is an input_str function...

That took up a lot of space. Library size went from 900 bytes in 0.7 to 1008 now in 0.8

 

[kliepatsch 74]

Whohoo you did it! Now VTUI Library seems almost maxed out. Really impressive. Thanks!

[desertfish 323]

the input_str() routine, does it return the input string in petscii or in screencodes?

[JimmyDansbo 153]

2 minutes ago, desertfish said:

the input_str() routine, does it return the input string in petscii or in screencodes?

The string is returned in PETSCII. I will update the documentation to make that clear.

[desertfish 323]

Playing some more with input_str.... :

• entered string in buffer seems to be terminated by a zero byte (I like this!)
• ... this probably means you want to allocate 1 byte more in your input buffer to have room for this.  Maybe good to document this too
• after pressing enter, the cursor remains visible. I expected it to disappear
• i cannot enter petscii symbols (or capitals when in lowercase character mode) ?

[JimmyDansbo 153]

@desertfish

• String in buffer is NOT zero terminated. If you type a string an press backspace before return, you will see
• I actually meant to document my way out of the cursor not disappearing, but I may have to just use the 8 extra bytes and hide it before return
• input_str supports the same characters as print_str

[desertfish 323]

About zero termination, I'm a bit confused then, because I see this :

my input buffer at $0920 was fully filled with 20 question marks $3f,  I typed my name (and some garbage that I  backspaced), and those zeros really did appear

[JimmyDansbo 153]

12 minutes ago, desertfish said:

About zero termination, I'm a bit confused

I share your confusion. I am currently looking into why those 0's are added to the buffer.

[JimmyDansbo 153]

@desertfish, I figured it out. 

I store anything that is returned by the GETIN Kernal function in the buffer, but only if the character is within the allowed range is the length incremented. 

This means that so long as the user has not used all allowed characters, you will essentially have a zero-terminated string, but if the user uses the full allowed length, there is no zero added to the end of the buffer.

 

[JimmyDansbo 153]

I have been toying with the notion that maybe I could use a kernal function to do the conversion between petscii and screencodes. Unfortunately it seems that the only place the kernal converts from petscii to screencodes is in a function that also prints the character to the screen.

My next thought is that I could possible make use of kernal functions in the VTUI library instead of writing directly to VERA. I am fairly sure that if I change the library to use kernal routines, the size will be decreased a fair bit and it would most likely be better at converting between petscii and screencodes.

What are your thoughts? Would there be any problems in using kernal routines instead of writing directly to VERA?

Edited March 23 by JimmyDansbo
Add another reason to use kernal routines