Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by JimmyDansbo

  1. 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...
  2. 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 For more information on passing CPU registers from BASIC, have a look at this page: https://www.c64-wiki.com/wiki/SYS
  3. That is from Release 37 of the ROM https://github.com/commanderx16/x16-rom/blob/master/README.md
  4. You could ensure that you empty the que every time you have read a character.
  5. 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.
  6. @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
  7. 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. Scrolling text within a "window" Getting a size-constrained string from keyboard Word-wrap at a specific length. 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
  8. 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.
  9. Finally decided that I wanted print_str to support not setting the color. Library updated to version 0.6
  10. 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)
  11. I have added it as a new function. That was actually a bit shorter than having fill_box check for the width For now, I have not bumped the version, but you can find the updated binary and source code on the github page.
  12. 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
  13. 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?
  14. I thought I had changed this. Can you point me to where I have missed it?
  15. 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
  16. @Greg King thanks, I will look into it. 4 bytes saved, thanks again
  17. 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.
  18. @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
  19. 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: https://github.com/JimmyDansbo/VTUIlib/tree/3e23f409272ed212ba312c7c36afa2ba60742799
  20. 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
  21. 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
  22. @Ender, thanks for the bugs. The same error was present in ca65-ex01.asm I have corrected both and removed the .org line in ca65-ex01.asm. Thanks again
  23. @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.
  24. VTUI updated to version 0.3 Now it uses zeropage registers r0 to r5
  • Create New...

Important Information

Please review our Terms of Use