Hi, great initiative and thanks for the effort! I bought the book and started reading. What I see is that the Fusion-C library could benefit from a more consistent naming convention for function names.

Most of them are camelcased and start with an uppercase character: FunctionName() but some start with a lowercase character and use underscores: function_name()

I would propose to unify it and make it consistent.

Also, what is the reason (other than style) to start function names with an uppercase? To keep it inline with other c-libraries and languages I would prefer to use a lowercase, like functionName() and not capitalize words like MSX and VDP: vdpFunction() and someMsxFunction(), but that’s just personal taste ;-)

Anyway thanks for sharing on github, am looking forward to contribute a bit.

First of all, thank you for this library, it's an amazing work!

I think I might have found a bug in the InputString(....) function when the msxdos2 extension is not loaded.

To reproduce it, I compiled the file print-input.c from the examples directory, and executed the resulting COM file in the OpenMSX emulator with the following results:

• If the 'msxdos2' extension was loaded, it works correctly as expected (both in MSX-DOS1 and MSX-DOS2).
• If the 'msxdos2' extension was not loaded, after entering the string, it is not correctly shown and sometimes the machine hangs and/or reboots.

Please let me know if I can provide further information :-)
Thank you!

Rename Working Folder to some other name without space characters. It's error prone for scripting. I like workspace which is common practice in several IDEs.

Hi. Thanks for such a fantastic package! Helps me A LOT. Keep it up.

Just wanted to point out that the docs says this:

Palette
typedef struct {
unsigned char color ; // color number 0..15
unsigned char R ; // 0..7 red brightness
unsigned char G ; // 0..7 green brightness
unsigned char B ; // 0..7 blue brightness
} ColRGB ;

and the source code says this:

/* Palette */
typedef struct {
unsigned char colour; // colour number 0..15
unsigned char R; // 0..7 red brightness
unsigned char G; // 0..7 green brightness
unsigned char B; // 0..7 blue brightness
} ColRGB;

I get compilation errors on "color" :)

IntBios and IntDos (IntDosBios.s), as well as dependent routines (like ReadMSXtype) don't work in ROM projects. They rely self-modifying code (they (try to) change ibcladr) and, being unable to set the proper routine address, they end up jumping to 0x0000 and booting the computer.

Noticed today something strange. When I compile my code with the supplied .rel my static variables don't initialise. When I compile the rel with the .s file all is well. My guess is that the .rel in your include folder is old and based on the initial version of Konamiman.

My code to check things:

#include "stdio.h"
#include "stdint.h"
#include "string.h"

uint8_t query[255];

void dosomething ()
{
  static unsigned char endquery[] = {0,0,1,0,1};  
  memcpy(query, endquery, 5);
}

/*---------------------------------------------------------------------------*/
int main(char *argv[], int argc)
{
  // check arguments
  if (argc==0)
    printf ("No arguments\r\n");
  else
    printf ("Arguments\r\n");

  dosomething ();
  printf ("%d,%d,%d,%d,%d",query[0],query[1],query[2],query[3],query[4]);
  return 0;
}

With the wrong crt0 it displays 255,255,255,255,255. With the right one it displays: 0,0,1,0,1

I patched the original Konamiman version by doing this:

        ;.area   _GSINIT      WAS HERE MOVED DOWN TO gsinext
gsinit::
        ld	bc,#l__INITIALIZER
        ld	a,b
        or	a,c
        jp	z,gsinext
        ld	de,#s__INITIALIZED
        ld	hl,#s__INITIALIZER
        ldir
gsinext:
        .area   _GSINIT
        .area   _GSFINAL

Problem was that the application calls gsinit at start. When area _GSINIT is before that it will be skipped. I moved it to gsinext. The crt0_msxdos_advanced.s of FusionLib when compiled also gives a good result. Only it does not include code for INITIALIZER. Don't know if this is still necessary though.

Fusion-C uses non-standard directory structure. include directory should be reserved for header (.h) types only, so that the SDCC -I parameter makes sense. All .lib and .rel files should go to the lib directory.

make fails after this output:

..•̀ᴗ•́)و .. sdcc  											 is Processing ... !
Invalid input and output values
usage: hex2bin [options]
	--help, -h: Print this help
	--input, -i: The input file to use (containing the hexadecimal characters).
	--output, -o: The output file to use.
	--limit, -l: Character limit per line (the value of the "start" option is not included).
	--start, -s: Adding a start offset per line.
	--printable, -p: Extracts and converts all printable characters.
	--extract_only, -e: Only extracts words from "start" to "limit".
make: *** [Makefile:83: test.com] Fout 1**

Using:

• OS: Linux 5.9.13-arch1-1
• SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.0 #11528 (Linux) with printf, sprintf, vprintf, putchar, getchar removed
• hex2bin: git://github.com/Keidan/hex2bin.git, master (commit a8de8c406ec4e4cdc08f646bd03f38377330854a)
• Fusion-C: master (commit 184582a)

Hi,

First of all thank you so much for this wonderful library! kudos on the hard work.

I've been using it for writing a small RPG, and so far things work great. At least until I tried to play some music.

I've tried to compile the Pt3Player-MSX2-Demo example, but the music never plays. I've tried with a lot of other different examples and they work as expected, I'm also using the library with my game and it's working. So I was wondering if maybe the code of this example is old or different from the actual executable file? I've tried with the .com file that is already generated and that one works as expected.

Thanks!

When I copy a part of the screen with the hmmm command and put in on a certain target location the location is off by 1 pixel. When I move it to the right with 1 pixel, it moves with 2 pixels. So it looks like there is a bug in the X coordinate.

Hi. Thanks for such a fantastic package, once again.

I can't get the function Exit(char N) to exit, the program just returns to program and continues.

Also, the documentation (pdf) says that the call is "void exit(char N)" - with a lowercase e, while in the code/headerfile uppercase is used.

Just wanted to let you know, so things could be updated in a future release.

If I understand well, at the end of a interrupt handler routine interrupts must be enabled again. I read it from several sources, this is one of them: http://map.grauw.nl/articles/interrupts.php

Current fusion c implementation does not call EI before RETI. From interrupt.s file:

; ---------------------------------------------------------
;	intr_handler
; ---------------------------------------------------------
intr_handler:
	push	af
	push	bc
	push	de
	push	hl
	push	ix
	push	iy
	exx
	ex		af,af'
	push	af
	push	bc
	push	de
	push	hl
	push	ix
	push	iy

user_intr_handler:
	call	dummy_handler

	xor		a
	or		l
	call	z, backup_keyint

	pop		iy
	pop		ix
	pop		hl
	pop		de
	pop		bc
	pop		af
	ex		af,af'
	exx
	pop		iy
	pop		ix
	pop		hl
	pop		de
	pop		bc
	pop		af
	reti

and, if I'm right, it should be:

; ---------------------------------------------------------
;	intr_handler
; ---------------------------------------------------------
intr_handler:
	push	af
	push	bc
	push	de
	push	hl
	push	ix
	push	iy
	exx
	ex		af,af'
	push	af
	push	bc
	push	de
	push	hl
	push	ix
	push	iy

user_intr_handler:
	call	dummy_handler

	xor		a
	or		l
	call	z, backup_keyint

	pop		iy
	pop		ix
	pop		hl
	pop		de
	pop		bc
	pop		af
	ex		af,af'
	exx
	pop		iy
	pop		ix
	pop		hl
	pop		de
	pop		bc
	pop		af
        ei
	reti

To reproduce the issue you can use the interrupt.c example file and comment the DisableInterrupt()/EnableInterrupt() calls from the main loop.

You will see that the interrupt handle is called only once, the first vsync, and will never be called again because interrupts are not enabled after the first interrupt handler call.

When trying to exit a .COM program, the Exit(...) function was ignored on MSXDOS1 while it worked on other MSXDOS versions and derivatives. Here is an example:

#include "fusion-c/header/msx_fusion.h"

int main(void)
{
    Exit(0);
    Print("unreachable\r\n");
    return 0;
}

And the result: