Idea/Proposal: ROM Headers for emulation

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

By albs_br

Master (199)

albs_br's picture

15-01-2021, 21:37

I'm late to this topic, but: the MSX ROMS already has an header, right?
Is it possible to use a part of it for this implementation? I'm not and expert, but the Header started by "AB" has the last 3 words "reserved". Could them bem used? Even if it were small space for all data, it can point to other address on ROM with more information.

Also: I don't understand well the iNes header. Is it ignored if ran on real hardware? Or must be removed before write to a cartridge?

By NYYRIKKI

Enlighted (5693)

NYYRIKKI's picture

16-01-2021, 12:00

albs_br wrote:

I'm late to this topic, but: the MSX ROMS already has an header, right?
Is it possible to use a part of it for this implementation? I'm not and expert, but the Header started by "AB" has the last 3 words "reserved". Could them bem used? Even if it were small space for all data, it can point to other address on ROM with more information.

Bad idea... Not all existing cartridges obey the "reserved"-status, so this would cause compatibility issues. At some point I was also thinking extended header after first 16-bytes, but that would not help with existing software either.

Quote:

Also: I don't understand well the iNes header. Is it ignored if ran on real hardware? Or must be removed before write to a cartridge?

Not ignored but interpreted to used hardware emulation. It is metadata, not code.

By albs_br

Master (199)

albs_br's picture

16-01-2021, 17:08

I know it is metadata intended to be used by emulators. What I don't understand is what happens if I record this on an EPROM, put it on a NES cartridge and try to run on a real NES console.

Does it crashes? The NES start to run the ROM by the first address?

By konamiman

Paragon (1099)

konamiman's picture

18-01-2021, 10:51

I think this is an interesting topic so I'll add my 0.02€. If we are to design a mechanism to add metadata to ROM files themselves I believe that:

1. It should be at the end of the file, not at the beginning. This way such metadata can be added to existing ROM files, and it's easy to strip it off in case it causes some trouble (e.g. a ROM loader might not be happy with a 128K+metadata size ROMs).

2. It shouldn't have a fixed size, but consist of a size indicator + the metadata "blob" itself.

3. It should consist of variable-size records, with the possibility of defining new record types in the future. This is achievable if all records have a common structure of size+type+info.

Here's an example of a possible structure for such a metadata tail:

METADATA_START:
    db 9 ;Record size (including record header)
    db 1 ;Record type = name
    db "Gradius"

    db 8
    db 2 ;Record type = publisher
    db "Konami"

    db 3
    db 3 ;Record type = mapper type
    db 3 ;3 means "Konami non-SCC"

    db C0h,04  ;Alternative size format: bit 7 is set meaning it's 2 bytes
               ;(so up to 32K) - 16K in this example
    db 80h,4   ;Also works for record types
    db ...  ;16K of binary data (e.g. a thumbnail image)

    db 0   ;A size of 0 indicates the end of the metadata
           ;(redundant as we have the full size, but useful for parsers)
METADATA_END:
    dw METADATA_END-METADATA_START  ;Full size of metadata
    db "MSX_METADATA" ;Label to detect the presence of metadata

This this would be parsed as follows:

1. Detect the "MSX_METADATA" label at the very end of the file
2. Get the metadata size right before that, locate its start on the file
3. Parse the metadata records, if any is unknown (or not interesting) it can be just be skipped

Worth noting that a given record type could have any kind of internal structure, including "subrecords". Overall I think this would be a simple yet powerful mechanism.

By NYYRIKKI

Enlighted (5693)

NYYRIKKI's picture

18-01-2021, 12:27

albs_br wrote:

I know it is metadata intended to be used by emulators. What I don't understand is what happens if I record this on an EPROM, put it on a NES cartridge and try to run on a real NES console.

Does it crashes? The NES start to run the ROM by the first address?

Typically this metadata is not stored in a same memory that acts as ROM. (ie. Flash, SRAM etc.), but it all depends of the hardware in question and can be stored there as well, but more likely it is stored in FPGA, latches or other components the cartridge has. This is all about hardware design. Typically the loader (software) is made by the same group, who designed the hardware, so user does not need to worry about this stuff. Typically there is no any kind of standard to handle this stuff either, but most likely hardware manufacturer has released the programming info to public. How ever this is typically not interesting unless you plan to write your own cartridge loader.

Even in the most simple case when there is just EPROM and wires, this data needs to be interpreted to see if this is even enough to implement this cartridge. If it is (no mappers etc needed) then the person building the cartridge can use other parts of this data to know how the wires need to connect to EPROM chip. Only the actual data (≠metadata) in this case is written to chip it self... Naturally the person building the cartridge can use Google or ask from other person having the original cartridge to check how it is wired, but the thing is that it is more easy if the hardware description is delivered with the software as the software can't work without required hardware regardless if the hardware is just wires or more complicated logic.

By ray2day

Hero (618)

ray2day's picture

18-01-2021, 16:42

Again an interesting topic!
I hope you MSX guru's (you know who you are... lot of respect for you guys!) can develop and agree to a standard for this.

If you ask me personally, I would disencourage headers for ROM detection. I think it is better to have a detection/identification before the ROM starts by a the loader (software wice).
[I am thinking something like Nyyrikki wrote for Sofarun as example]

I don't know how much mapper types there are for MSX? And I don't know if all ROMS are recognizable. But what about a standard database for ROM recogition (to be integrated in that kind of software). Recognition by checksum or something like that? Or would it become to massive/big? (just thinking out loud... I do not know if this is a good idea).

By FiXato

Scribe (1694)

FiXato's picture

18-01-2021, 18:20

I think that that is exactly what Vampier is trying to stop us from being dependent on: his rom database, because it requires a maintainer, not just for the data, but also to keep it online and accessible. :)

By ray2day

Hero (618)

ray2day's picture

18-01-2021, 21:56

Sorry, it some while ago I read the original topic... so I read it again.
So we have 37 mapper types?
I have no knowledge of it, but Is it not possible to add the mapper type and mapper type only, somewhere in the rom as meta data, just a code number (0 to 36) at the original ROM code where it will be skipped by real machines?

On the other hand IMHO lot of existing rom data bases (not Vampiers one) are a already a mess (different rom versions of one game, adapted roms, so called fixed dumps, translations etc. etc. including bad dumps) and I am afraid they will become even more messy when a new format is introduced.

By Manuel

Ascended (17513)

Manuel's picture

19-01-2021, 00:38

openMSX already supports 80 mapper types at this moment Smile

By NYYRIKKI

Enlighted (5693)

NYYRIKKI's picture

19-01-2021, 08:06

Manuel wrote:

openMSX already supports 80 mapper types at this moment Smile

I think better than this would be supporting a mapper description in XML... I mean roughly something like (press "QUOTE" to see):


          
           xyz.rom
          
          
            0x4000
            0x4000
            mem
            0x6000
	    data
            0xFF
            0x0
            0x07
            0
            0x4000
            
             xyz.rom
            
	  
          
            0x8000
            0x8000
            IO
            0x20
	    writevalue
            0xFF
            0xFC
            0x03
            0x20000
            0x4000
	  

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