Commander X16

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

CP437 support.

I'm an avid hobbyist of the bbs scene so... Obvious isn't it?

Sent from my SM-T720 using Tapatalk

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 ?

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

59 minutes ago, JimmyDansbo said:

looked into supporting decrement in the library

Well I was just using it because there is a set_decr() function.  What is that used for otherwise?  I can simply ignore it ofcourse.

Eager to try out the new version tonight

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

 

I was looking in the source code and have a question: what's the reason that in the asm source files the various functions are defined as macros and then immediately instantiated?

Also another suggestion:

Prog8 has compile time conversion to petscii and screencode strings. So the issue I had with the unconverted characters in print_str() could be solved by providing an additional function that simply accepts a string that's already in screencodes. It will then  just pokes the values without any conversion into the vera's.  What do you think? Would that fit?

 

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

Hey ! Just passing by ?

5 minutes ago, JimmyDansbo said:

If you only use the macros, your source could become quite large very quick

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.

Depending on your assembler, you can set a flag into your macro to figure out if the routine exist, and if not you include it dynamically.

11 minutes ago, JimmyDansbo said:

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.

I agree, sometimes this is useful when the code is used once / small enough ?

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.