Jump to content

VTUI library


JimmyDansbo
 Share

Recommended Posts

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

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

  • 2 weeks later...
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.

Link to comment
Share on other sites

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

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

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
Link to comment
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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use