MSXgl – A new C game library for MSX

Page 10/16
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15

By aoineko

Champion (441)

aoineko's picture

18-02-2022, 22:58

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.

jbikker wrote:

Really enjoying your library so far!

I'm glad it can be useful. Smile

By gdx

Enlighted (5477)

gdx's picture

19-02-2022, 08:17

aoineko wrote:

I think the multiplication of two 16-bits variable values should not be so fast in Z80 assembler.

Impossible to do faster than in assembler.

By aoineko

Champion (441)

aoineko's picture

19-02-2022, 09:32

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).

By jbikker

Rookie (17)

jbikker's picture

21-02-2022, 10:16

Thank you for the advice. I checked crt0_rom48.map, and it shows the following info:

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
_CODE                               00004000    000087C5 =       34757. bytes (REL,CON)

This size is confirmed by 'sizeof' in the program: I have a bit more than 27KB of data, so 34KB for the whole thing sounds reasonable. This should fit in a 48KB ROM right?

I will try what happens if I push it below 32KB, perhaps there's something that keeps me from using the 16KB above 32KB?

EDIT:

I got it to work as a DOS1 program. Joy. Smile

EDIT2: the ROM fonts are now overwritten by garbage, probably my garbage. Wink Not really an issue, but perhaps a relevant symptom.

By aoineko

Champion (441)

aoineko's picture

21-02-2022, 13:24

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.

By jbikker

Rookie (17)

jbikker's picture

21-02-2022, 14:10

Thanks for the detailed instructions. I am going to try this!

By aoineko

Champion (441)

aoineko's picture

21-02-2022, 21:54

jbikker wrote:

I am trying to create a 48K rom with about 30KB in a few global arrays. When I do this, I get a 4GB rom file

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).

By jbikker

Rookie (17)

jbikker's picture

24-02-2022, 20:09

I made a spinning 3D cube using your framework:

https://www.cs.uu.nl/docs/vakken/magr/cube3d.rom
(file kindly hosted on the servers of my university ;) ).

I'll prep a source repo if anyone is interested. The thing runs without any artifacts at 7Mhz, but at stock speed it's quite acceptable as well. Should work on MSX1. The technique is based on ARTRAGs work, with a few extra things to get rid of artifacts.

By ARTRAG

Enlighted (6840)

ARTRAG's picture

24-02-2022, 20:39

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

By salutte

Master (159)

salutte's picture

24-02-2022, 20:45

Hey it is super cool! I would be interested in the code if possible!

Page 10/16
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15