Idea/Proposal: ROM Headers for emulation

Page 6/6
1 | 2 | 3 | 4 | 5 |

By wouter_

Champion (450)

wouter_'s picture

19-01-2021, 13:05

NYYRIKKI wrote:

I think better than this would be supporting a mapper description in XML...

It's a sensible idea, unfortunately I don't believe it'll work in practice.
There are various details still missing from your example (for some use cases these details can be ignored, for others they are important):

  • What's the initial value for the selected bank (for each region)?
  • Are the bank-select registers re-initialized on reset?
  • Bank-select address is often not a single address but a whole region (possibly non-continuous).

But even with these additions you can only cover a small fraction of all the mapper types. To cover more you'll have to make extensions to describe (S)RAM, flashROM, SCC, PSG, DAC, ...

  • Does the mapper contain RAM? How much? Is it backup-up by a battery (SRAM)?
  • How to select this RAM? Via a special bank-select value? Via a specific enable bit?
  • Is the RAM mirrored? (Often it's smaller than the ROM-bank-size).
  • Can the RAM be mapped read-only?
  • Is the ROM implemented as flashROM? Which manufacturer/device-ID? (Some games do query this).
  • Which regions (sectors) of the flashROM are re-flashable, which are write-protected?
  • Does the mapper contain extra sound-hardware? An extra PSG or a DAC? Which IO ports?
  • Does it contain a SCC? How is it mapped (typically the same as in a Konami SCC mapper, but not always, or not 100% identical).

And then there are various one-of special cases:

  • Bank-switch on reset rather than typical write-to-address. (You run a different game each time you reset).
  • Some mappers implement multiple mapper mechanism, and there is a control register to select between them.
  • Some mappers contain some form of copy-protection:
    • Could be extra hardware on IO ports. (Write a specific sequence, only then reading returns a value different from 0xff).
    • Could be a 'configurable' bit-scrambler. (Bits in a byte get shuffled/inverted, how exactly can be changed via some control register).
    • Could be return different values for opcode-fetches than for normal memory reads (by monitoring the M1 pin on the data bus).

I'm probably still forgetting many other details.

It might be possible to come up with a generic mapper description that covers (most of) the above, but it will be complex. I think the idea of this topic was that users should be able to create their own meta-data for their own ROM dumps. So maybe this generic mapper description is not best suited for that.

By FiXato

Scribe (1694)

FiXato's picture

19-01-2021, 17:20

konamiman wrote:
[…]
    db 3
    db 3 ;Record type = mapper type
    db 3 ;3 means "Konami non-SCC"
[…]

I guess this would thus be another list that needs to be maintained? Smile

By ducasp

Champion (400)

ducasp's picture

19-01-2021, 22:50

Would 256 variations help? If so, why not have a new file extension, instead of ROM, Rxx where XX is the hexadecimal mapper identification... It is simple, won't require adding/removing/stripping anything and will for all effects:

  1. Kill the need to maintain a database, who release the new ROM is responsible to rename it to R00 for SCC MegaBlaster or R01 for ASCII 316K or RCA for IREM Kung Fu Ninja Mapper
  2. File will still be compatible with any emulator, flash cartridge, etc... At most, need to rename it to .rom, that is it
  3. Anyone can code a simple software that get the current database and convert detected files to the new extension, making it easy to just convert your own collection for the new format, and still, just a ren *.r?? *.rom away of reverting back if needed

It won't have all gizmo of publisher, date, street price, black market price, etc... But hey, it should reach the ultimate goal of no longer needing to mantain a database, use the current to convert the actual files, and from now on, each developer is responsible to use the proper Rxx extension for it...

Maybe I'm just dreaming that it is something so simple, but I think this is backward compatible, do not require file contents modification and will make it possible to make loaders and emulators aware of the mapper to use for that file...

By FiXato

Scribe (1694)

FiXato's picture

20-01-2021, 11:09

One thing that could cause issues with this is that WinRAR used to use R01..R99 (and possibly higher using letters too?) for their split archives, and thus could cause file association confusion. Though I believe WinRAR has moved on from this to $filename.part01.rar format now.

Speaking of which, if 8.3 fileformat is not a necessity, then I guess you could also just do GameName.mapper1.rom or whatever.

By konamiman

Paragon (1098)

konamiman's picture

20-01-2021, 12:33

FiXato wrote:

I guess this would thus be another list that needs to be maintained? Smile

Yes, but that's unavoidable no matter what data format you choose. However with this schema it's easy to add new record definitions without breaking compatibility with existing "clients".

By ducasp

Champion (400)

ducasp's picture

20-01-2021, 12:42

FiXato wrote:

One thing that could cause issues with this is that WinRAR used to use R01..R99 (and possibly higher using letters too?) for their split archives, and thus could cause file association confusion. Though I believe WinRAR has moved on from this to $filename.part01.rar format now.

Speaking of which, if 8.3 fileformat is not a necessity, then I guess you could also just do GameName.mapper1.rom or whatever.

I thought of 8.3 so it would work on fat12 or fat16 without needing to zip files in any MSX. If R00 could be an issue, let's MSX it, M00, M01, etc... Tongue

Page 6/6
1 | 2 | 3 | 4 | 5 |