Breaking the 64k barrier

nuc1e0n
Member
Posts: 49
Joined: Wed Jun 10, 2020 12:34 am

Re: Breaking the 64k barrier

Post by nuc1e0n »

I appreciate that mappers are the hardware within cartridges. I wouldn't expect every imaginable hardware configuration to be representable in some
hypothetical emulator cartridge file format. Only a means of specifying within the same file as the ROM data which mapper was used from the list of unique configurations that were used by commercially released games.

At present, it seems if folks want to produce a new MSX cartridge that uses the same mapper as an existing game, they need to include useless code to
bias the heuristic calculations that emulators have which selects the appropriate mapper to use. I was hoping for a means to specify this choice more directly.

I'm sorry if offence was caused as I didn't intend any.

A similar situation of different mappers being used for games exists on the NES. Indeed the problem seems far more acute for that system, as hundreds of
different mapper configurations were commercially used during the lifetime of that system.

For that reason, NES emulator authors created the iNES file format, which I found to be an interesting read (https://wiki.nesdev.org/w/index.php?title=INES).
A list of the more commonly used NES mapper numbers can be seen here (https://wiki.nesdev.org/w/index.php/Cat ... ES_Mappers)

Something similar conceptually for MSX cartridges is what I was hoping to see. I can see there is already a list of mapper formats for the MSX at
https://www.msx.org/wiki/MegaROM_Mappers.

If a developer of a new NES game wants to use a memory mapper, they can directly specify to use one of those used by an existing game, with no detection heuristics needing to be involved. If those developers come up with their own memory mapping system, emulators would still need to be updated to support it of course. However the capabilities needed would most likely also be available with an existing mapper number already supported by the emulator, so in this way further hardware divergence by homebrew releases would not be necessary.
Timmy
Well known member
Posts: 392
Joined: Sat Mar 10, 2012 4:18 pm

Re: Breaking the 64k barrier

Post by Timmy »

nuc1e0n wrote: Fri Feb 11, 2022 1:35 pm I appreciate that mappers are the hardware within cartridges. I wouldn't expect every imaginable hardware configuration to be representable in some
hypothetical emulator cartridge file format. Only a means of specifying within the same file as the ROM data which mapper was used from the list of unique configurations that were used by commercially released games.

At present, it seems if folks want to produce a new MSX cartridge that uses the same mapper as an existing game, they need to include useless code to
bias the heuristic calculations that emulators have which selects the appropriate mapper to use. I was hoping for a means to specify this choice more directly.
I'm not sure how or where you've read this from. The simplest procedure is still just make a game with any mapper (an existing one, or a new one), and then wait until the emulator supports it. This is probably not a big deal since there is only like at most 20 new games released a year with a mapper. This, if I remember correctly, was what was chosen in z88dk.

That being said, if you feel like including "useless code" is a big problem for you, then I think you really should consider writing z80 assembly directly. Using z88dk is, from my experience, basically just adapting my C writing style until the compiled executable fits into the available memory, every single time. But it's still a really good way, so I don't really care much about it.
I'm sorry if offence was caused as I didn't intend any.
I'm sorry if you feel sorry about it. I've read more of your posts now, and I don't think you can help it.
... the NES ...
Every solution has its own advantages and disavantages, and every platform makes their own choices.

For example, a lot of the games for the Spectrum is using the TZX format now instead of the TAP format we're still using. TAP files are fine and there is no need to change.
Post Reply