@pizzapower: What kind of changes did you make? I could add it to the gklib.
First, I dislike PascalCase (or camelCase) in my C code, so all my V9990 functions use snake_case. You are welcome to rewrite their names as you see fit. I wrote new functions since g9klib was a bit lacking when using P1:
put_pattern_a() and put_pattern_b() put a pattern on screen (on layer A and layer B respectively) because SetPattern() expects a layer parameter which does unnecessary branching. I know at compile time what layer I want to write the pattern to. So it doesn't need to be a runtime parameter.
function set_layers_palette() sets the palettes on patterns A and B in a single call, since g9klib doesn't provide that.
function set_layers_priority() sets layer priority directly (which layer is on the top on a 64x64 block matrix) in a single call. This is useful for register-based horizontal split screen.
put_object_{a|b}() and put_slice_{a|b}() put software sprites (block of tiles) on layer A and B respectively. put_object_{a|b}() draws it completely in one go while put_slice_{a|b}() is used to render a vertical section of the block of tiles at the edge of the screen while it scrolls. The huge aircraft carrier is rendered this way, since it is too big for sprites.
jepmsx wrote:
Nice work!
V9990 has so much potential!
Besides g9klib, are you using other C libraries like Fusion-C or MSXgl?
Thanks. I use the g9klib bundled with Fusion-C. So it's mostly g9klib and some FCB (file reading) functions that I use.
@pizzapower I think that your improvements of the g9klib C wrapper will certainly interest EricB, the creator of Fusion-C.
For MSXgl, V9990 support is still work in progress.
That's one of the things I'm working on right now.
The support of P1 and P2 modes is almost complete (see my sample) but I still have a lot of configuration to make accessible and the support of the VDP command.
I'm trying to stick to C code because of the recent changes in SDCC that broke Fusion-C recently (__atoi or _atoi, calling conventions etc.). I get lots of warnings and errors if I try to use post-4.1.2 SDCC. How does MSXgl manage?
I don't use any of the standard library functions in MSXgl, so I don't have these problems.
That said, with the passage of SDCC to version 4.1.12 I had to rewrite all my inline assembler functions to take into account the change of calling convention. It was a lot of work, but it's worth it because of the significant performance gains.
The current version of MSXgl comes with SDCC 4.2.0, but I regularly test the snapshots to make sure I keep the compatibility.
That said, if you want to use a recent version of SDCC with the old calling convention, there is a solution. You have to get the z80 libraries from version 4.1.11 (the last one with the old calling convention) and compile your code with the --sdcccall0 option.
