MSXgl – A new C game library for MSX

Hello jbikker,

There is a bug in the Build Tool when the ROM generated by the compilation is already bigger than the target size ROM.

In the example below, the Build Tool generates a 32 KB ROM. In the PACKAGE section we can see that the ROM addresses range from 4000h to 815Ch, which fits well into the 32 KB size:

┌───────────────────────────────────────────────────────────────────────────┐
│ PACKAGE                                                                   │
└───────────────────────────────────────────────────────────────────────────┘
Converting to binary...
HEX2BIN -e rom -s 4000 .\out\crt0_rom32.ihx
hex2bin v1.0.12, Copyright (C) 2012 Jacques Pelletier & contributors

Lowest address  = 00004000
Highest address = 0000815C
Pad Byte        = FF
8-bit Checksum = 3F
Succeed
Filling binary up to 32768 bytes...
Succeed

If the highest address was above C000h, the Build Tool would not be able to complete the ROM at 32 KB and we would end up with the same bug you describe (it generate very huge file).

I would add a test to display an error and stop the Build Tool, but the real solution is to reduce the size of your data and/or aim for a larger ROM format (one of the ROM mapper formats supported by MSXgl).

To see what takes up so much space, you can look in the crt0_rom48.map file in the /out/ directory.

Don't forget that in addition to your data, you have to store the code of the MSXgl library (the code generated by C compilers is often much longer than if it was written directly in assembly). You can remove the modules you don't use in the variable LibModules of the build.bat. There are also defines in msxgl_config.h that allow you to reduce the size of the library by selecting the features you want to use.

I'm glad it can be useful.

I'm not saying the opposite. I'm just saying that the solution he proposes, based on the multiplication of two 16-bit variables, will be much slower in assembler than the solutions I already use in MSXgl (based on simples operations).

When you boot to DOS, all the memory pages are mapped to the RAM slot.
As the default font is contained in the BIOS (slot 0 or 0-0), it is not directly accessible from the DOS.
However, you can use one of the many fonts provided with MSXgl.

Caution: The support of MSX-DOS in MSXgl is very limited. For the moment there is no wrapper to facilitate the management of DOS features (for example, files management).

If you use crt0_rom48, you have to know that only pages 1 and 2 of the ROM will be selected at startup and that by default, the C static data will be accumulated from address 4000h (page 1).
To use page 0 you must :
- Store data there by forcing the address to be in page 0 (for example: __at(0x0200) const u8 mydata[] = { /* ... */ }; )
- Access it with interslot functions (either by changing the slot of page 0 with the interrupts disabled, or by doing interslot reading).

You can also try crt0_rom48_isr which contains an interrupt handler (addresses 0000h to 01FFh are reserved) and which starts with pages 0, 1 and 2 selected on the ROM. With this crt0, you don't need to switch the page 0 which contains the game data.
On the other hand, of course, it is no longer possible to use the BIOS functions.
This is the crt0 I use for my tennis game Final Smash.

On the last version of MSXgl on GitHub, I added to the Build Tool an error message when the compiled ROM is greater than the target ROM size (the source of the 4 GB ROM bug).

Awesome! On plain msx 1 it spins smooth as silk
Congratulations!