Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by JimmyDansbo

  1. I am by no means an expert on electronics, but first thing that comes to mind is that you might be able to use some EEPROMs to "program" your logic circuit and maybe save some of the propagation delay?

    Feel free to shoot me down if I am completely off base, I just remember Ben Eater saying that any discrete logic gates could be replaced by ROM (or something along those lines).

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


    10 LOAD"VTUI0.6A.BIN",8,1,$400
    20 SYS $400
    30 POKE 780,0
    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

    • Like 1

  3. You could ensure that you empty the que every time you have read a character.



    jsr GETIN

    beq WAIT_FOR_INPUT ; keep reading while GETIN returns 0

    sta Keyboard_value ; Store the first value


    jsr GETIN

    bne EMPTY_BUFFER ; Keep reading while buffer contains characters


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

  5. I have manged to free up an extra 50 bytes in the library, so I think it is time to try and add a feature or two.

    Looking through the posts in this subject I have found the following that is not yet implemented.

    1. Scrolling text within a "window"
    2. Getting a size-constrained string from keyboard
    3. Word-wrap at a specific length.
    4. Support for multiple character sets.

    I am afraid that option 1 is not doable within the 1KB range, but if that is the one you all point to, I will give it a shot.

    Which one would you guys most like to see added to the VTUI library? Have I missed something that is even more important?

    Let me know 

  6. When I wrote the mock-up of midnight commander, I needed a way to copy text from one place on screen to another, but without copying the color information. The new functionality in print_str is meant as a step on the way to achieving that. I may not be a stop in the right direction, in which case I will remove the feature again, but for now the option is there.

    In the future, new routines will be added to the bottom of the jump table. I had the exact same troubles when I updated my example code.

  7. 13 minutes ago, desertfish said:

    I saw the "midnight commander" demo appliction. Is that one of the examples in the repo?

    It is not one of the examples in the repo as the source was just thrown together to create interesting-looking images

    I am going to and from changing print_str to enable it to write strings without touching the color of the chars. - I have a very hard time deciding... (this is why I have not updated to 0.6 yet)

  8. 17 minutes ago, desertfish said:

    what is convenient though is still being able to specify the character and colors just like fillbox

    How about having fill_box clear the screen if width is set to 0 ?

    I think that requires less code in the library than having two separate functions

  9. A couple of revisions ago I removed the clear_screen function as the same can be achieved by the fill_box function, but I have been thinking about adding clear_screen back in as I believe there is room in the 1K and I can not think of any other function that could be added within the remaining ~100 bytes.

    What do you guys think?

  10. 6 hours ago, desertfish said:

    Did something break in print_str() in the 0.5 release?

    I was a bit premature in declaring the changes, Greg King suggested, a success 😮

    We should be back to normal operation now. As stated, I have removed the ldy r2h and I have changed the print_str function to convert from petscii if .A=0 

  11. 1 minute ago, VincentF said:

    One thing that I like to do with macros is, I define the regular routine the classic way, and the macro version is just a load-up-the-parameters-and-call-subroutine.

    I had actually startet doing that, but then I need to make the macros able to handle both absolute and immediate parameters and I startet to move away from the functionality in the generic library. As it is now, it is easy for the user to create their own macro or subroutine that sets up values and calls the library macro/subroutine.

  12. @desertfish I define the routines both as macros and sub routines to give the user the choice. If you only use the macros, your source could become quite large very quick, but I find it necessary to also provide the routines as macros to give the option of having it inline instead of JSR'ing to it. Some of the routines, like plot_char, are quite small and may just as well be used as macros.

     I think it is a very good idea to give the option of having print_str not convert anything and I believe that it should fit - Thanks for the suggestion (I had actually thought of it, but forgot about it again)

    edit: I have made the change and it only takes up 2 bytes 🙂

    • Thanks 1

  13. My plan is to provide basic functionality for people who do not know much about VERA, but also provide "helper-functions" for people that want to roll their own functions.

    Functions like set_bank, set_decr and set_stride are "helper-functions" that should make it easier to set those values without having to think about preserving other values in the VERA_ADDR_H register.

    In my own case, I would just as often do manual writing of characters to VERA as I would use plot_char, depending on if I needed the color attribute set.

    I had actually created a bunch of macros in the acme and ca65 includes to make it possible to print and draw without setting colors and stuff like that, but it became way to much work to keep everything equal when I made changes to the generic library.

    If you have plenty of time and don't mind reading sphaghetti-code you can have a look at this old version:



  14. Version 0.4 uploaded with bugfixes and custom border mode.

    I looked into supporting decrement in the library, but there simply is not enough room to support it for all relevant functions.

    To support it in plot_char alone would take up an extra 12 bytes, the same for scan_char and similar for print_str, hline and vline

  15. 5 minutes ago, calcmandan said:

    CP437 support.

    This seems like it is WAY out of scope for this library. I think your request would be much more appropriate for a ROM request. Or you could create the font and make it available to the community, X16 supports custom fonts 😉

    • Like 1
  • Create New...

Important Information

Please review our Terms of Use