Jump to content

Recommended Posts

@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

Share this post


Link to post
Share on other sites
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 by Greg King

Share this post


Link to post
Share on other sites
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 by JimmyDansbo
Give information about version-bump

Share this post


Link to post
Share on other sites
Posted (edited)
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 by JimmyDansbo
  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by JimmyDansbo

Share this post


Link to post
Share on other sites
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)

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by BruceMcF

Share this post


Link to post
Share on other sites

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

 

  • Thanks 2

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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

image.thumb.png.4d4122a4de4f4cc203e09ec0d564cb98.png

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 😉

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

 

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by JimmyDansbo
Add another reason to use kernal routines

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use