[C] 32K ROM limitations in openMSX

Pagina 3/4
1 | 2 | | 4

Van MattyT

Rookie (26)

afbeelding van MattyT

16-04-2022, 04:51

I naively got the MSXgl 32K and 48K ROMs rel files assembled and then tried linking them into my game in the same place that Danilo's msxromcrt0.rel would normally go, and made new ROMs to load into OpenMSX. They didn't work.

The whole slot thing and Z-80 assembly is not my area of expertise. I do want to keep using Danilo's msxbios library and I want any ROM *.rel file that I can link in to give me the maximum amount of space for writing programs in C, and continue to code without knowing anything about low level slot calls. The ROM that is made ideally works the same on real hardware as well as in OpenMSX. Any advice is welcome. As long as the program I write is smaller than a code segment of about 20,000 bytes the msxromcrt0.rel, and msxbios.rel approach works fine. However it'd be nice to be able to use all the space in a 32K or 48K ROM.

Van aoineko

Champion (445)

afbeelding van aoineko

16-04-2022, 10:13

If you want to avoid having to manually manage the slots, you will be limited to the 32 KB cartridge. For standard MSX use, you will need the BIOS to be present in the first memory page (0000h-3FFFh) and RAM in the last page (C000h-FFFFh). This leaves 2 pages for your game for a total of 32 KB (4000h-BFFFh).
The 48 KB cartridges usually switch the content of the first page between the BIOS and the cartridge (which is not "simple").

If you send me your C code, I could try to make a working crt0 for you. The version I use for a 32 KB MSXgl ROM is 81 bytes so you will have 32687 bytes left for your game. You can contact me on the MSXgl's Discord or by e-mail with my nickname at free.fr.

Van Timmy

Master (188)

afbeelding van Timmy

16-04-2022, 17:46

MattyT wrote:

* The whole slot thing and Z-80 assembly is not my area of expertise.
* I do want to keep using Danilo's msxbios library and
* I want any ROM *.rel file that I can link in
* to give me the maximum amount of space for writing programs in C,
* and continue to code without knowing anything about low level slot calls.
* The ROM that is made ideally works the same on real hardware as well as in OpenMSX.

As long as the program I write is smaller than a code segment of about 20,000 bytes the msxromcrt0.rel, and msxbios.rel approach works fine.

I also want to chime in to say that, if you do not want to do Z-80 or slot things, and you want to use your current setup, then 20000 bytes is your limit. This is not a bad thing, it just mean you have to stop making large games, of use "magic" to fit more things into those 20000 bytes like everyone else does. This can be hard for you since C is also not your expertise (there are tricks for writing C for machines with 64K that don't apply for PCs). Unfortunately I can't help you there since I don't use SDCC, but perhaps you could ask someone else.

There are other options, if you want to create your own ROM files, learn how the machine works, or learn assembly (or let someone else create it for you) then you can have about 32K space to put in everything. This is still the theoretical limit for you (and not larger), since you want to use the BIOS and RAM (they already used 32K combined), and because both OpenMSX and real hardware can be really picky for anything larger than 32K.

Once in a while I get requests from people who has no idea how MSX works and still wants to make 48K ROMs or 64K ROMs or even new kinds of MegaROMs that can't be easily supported by emulators and hardware. And I think z88dk supports them now too, despite me voicing my concerns (you'd still need to learn about assembly and banks and the msx hardware and emulators, but those "game developers" don't seem to care.) Oh well, at least I've got 2 games in last years MSXDev, and both fitted easily in 32K (one even in 16K).

EDIT: Apologies for the rant.

Van aoineko

Champion (445)

afbeelding van aoineko

16-04-2022, 23:48

@MattyT, I recompiled your game with the MSXgl tools chain. The problem is that the generated ROM is more than 32 KB... so it's "normal" that it doesn't work.
However, looking in the .map file, I could see that the last address of your code is at 9476h (so you still have plenty of space). I think that your problem comes from an XDATA segment that is assembled after your data in RAM... so after C000h.
I'll check to see how to fix it.

Van MattyT

Rookie (26)

afbeelding van MattyT

16-04-2022, 23:35

Sorry, Your Majesty Timmy

Why is the ~20,000 bytes the limit in the emulator with MSX1 machine BIOSes, and not 32Kb when it still works with the C-BIOS and on real hardware? The ROM is still 1/3rd padded out with FFs. Seems like a reasonable question.

Van aoineko

Champion (445)

afbeelding van aoineko

17-04-2022, 00:11

Found!

In vdp_graph1.s line 239, you have an 8 bytes of data under the label _px8bits that you put in a _XDATA segment. But this segment is not well placed by the linker (linker place it after RAM data so after C000h).

Two solutions:
- Leave this data in the _CODE segment (it is static data so it is their place imho). Just delete .area before and after _px8bits.
- Or put the _XDATA segment in the ROM part of the crt0 (just after _CODE for example).

I have a working version of your game that use 21644 bytes out of 32768 possible.
It works with the MSXgl tools chain, but the corrections I suggest above should also work with Danilo's tools.

Van MattyT

Rookie (26)

afbeelding van MattyT

17-04-2022, 00:29

aoineko wrote:

Found!

In vdp_graph1.s line 239, you have an 8 bytes of data under the label _px8bits that you put in a _XDATA segment. But this segment is not well placed by the linker (linker place it after RAM data so after C000h).

Two solutions:
- Leave this data in the _CODE segment (it is static data so it is their place imho). Just delete .area before and after _px8bits.
- Or put the _XDATA segment in the ROM part of the crt0 (just after _CODE for example).

I have a working version of your game that use 21644 bytes out of 32768 possible.
It works with the MSXgl tools chain, but the corrections I suggest above should also work with Danilo's tools.

vdp_graph1.s shouldn't be linking in, That code is from the Fusion libraries. I was experimenting with linking in small parts of the Fusion library, but i thought I had removed it all. I'll delete all of the Fusion stuff from my source dirs and try again.

If you could zip up your solution and send to me I'll be thankful.

Van aoineko

Champion (445)

afbeelding van aoineko

17-04-2022, 00:38

Okay, I'll send it to you.
Works fine on OpenMSX with:
- Panasonic CF-2700 (both primary & secondary slot)
- Phillips NMS 8235
- Canon V20
- C-BIOS MSX1 & MSX2

Van Manuel

Ascended (18788)

afbeelding van Manuel

17-04-2022, 01:40

Can you be more specific where 'openMSX is picky'? Can you send me an example where openMSX is behaving unexpectedly? Then I can investigate a bit.

Van MattyT

Rookie (26)

afbeelding van MattyT

17-04-2022, 02:22

Thanks to Aoineko and DamnedAngel for the offline help. I can now build my game with MSXgl, still using the MSXbios library from DamnedAngel (if I copy in stdint.h from sdcc sources into my local directory as msxbios.h needs it).
It is back to running in my Panasonic CF2700 in openMSX and I have a bit more space to fit the rest of my game into.
(I should go and fix Blastoid so it runs a bit better in emulators too)

Pagina 3/4
1 | 2 | | 4