How does Emulator choose Memory mapping model for ROM

[bazz]

If one wanted to create new and intriguing memory map model for ROM, normally a cartridge has the hardware to handle such things. How do emulators know that a certain ROM image is expecting a certain memory model? I ask this question because, if I had wanted to make a certain memory model for my game, how would the emulator know to load my specific model?

[lidnariq]

ISTR that bsnes supports some description of "map X bytes at file offset Y starting at page W and address Z within ending at page U and address V", but I think all the other (much more ancient) emulators only support things that vaguely resembled the layouts used during the original commercial life. (AIUI, they do this by looking for the internal header, and based on where they find it and what it says)

That said, what are you specifically hoping to extend?

[bazz]

Mostly learning having fun.

[bazz]

"map X bytes at file offset Y starting at page W and address Z within ending at page U and address V",

Um, in trying to decode this, it does not seem to have an idea of what to map from where. What I'm saying is, what determines these variables? Surely if I introduce a new memory model, the emulator would not understand, ne?

[3gengames]

What?

A mapper would change the layout of ROM. Emus will understand. Your ROM will also have the extra information, if applicable. It's reflected somewhere, somehow.

[Ramsis]

To my knowledge, emulators indeed do rely on the internal ROM header information to determine whether an opened file is LoROM or HiROM.

Something like this:

- check the word at file offset $7FDC (= LoROM ROM checksum complement), XOR it with $FFFF and check if result matches the word at $7FDE (= LoROM checksum). If it matches, the ROM is presumably LoROM, if not, go to the next step
- check the word at file offset $FFDC (= HiROM ROM checksum complement), XOR it with $FFFF and check if result matches the word at $FFDE (= HiROM checksum). If it matches, the ROM is presumably HiROM, if not, then go to the next step
- ... (e.g. do some ExLo/HiROM check, print an error message to the screen, or whatever)

Since all (?) commercially released games have an intact ROM checksum & complement, this is a very reliable, albeit not 100% fool-proof, method of determining whether a file is LoROM or HiROM.

Maybe byuu or nocash would like to elaborate on this?

[Bregalad]

A hirom cart could have by pure chance the word at $7FDC be the inverse of the word at $7fde. Unlikely, but not that much, for example a table with two $00 followed by two $ff or something in the like...

[Near]

Maybe byuu or nocash would like to elaborate on this?

That's the basic idea, yes. But the reality is things get a lot more elaborate.

Some games have completely valid and normal looking headers in one spot, and a corrupted looking one in another. The corrupted one is the real one. Anti-copier tricks? Incompetence? Who knows, but we have to deal with it.

So by far the most pivotal test of any modern SNES emulator is to look at the first instruction pointed to by the reset vector at $7ffc, $fffc and $40fffc. If it's sei, clc or xce, then we almost definitely have the correct mapping mode. If it's brk (00) or adc $ffffff,x (ff), it's most definitely not the correct mapping mode.

Once we know the basic mode, we apply a few other hacks. Like we determine whether to mirror SRAM into the low-half of the $7x banks based on the size of the ROM. That's not part of any official rules, it just so happens to work for Ys 3 and Fire Emblem: Thracia 776.

> Um, in trying to decode this, it does not seem to have an idea of what to map from where.

bsnes' manual mapping layout looks like this (example is LoROM):

Code: Select all

board type=1A1B revision=04,05,06
  rom name={rom.name} size={rom.size}
  ram name={ram.name} size={ram.size}
  map id=rom address=00-1f,80-9f:8000-ffff mask=0x8000
  map id=ram address=70-7d,f0-ff:0000-ffff

I don't really expect any homebrew to use this, unless they're doing something that no other emulator can support through heuristics. It's mostly used to get perfect mapping for commercial games (I make the maps myself), or for new homebrew like d4s' Super Road Blaster (a 600MB game) or the Campus Challenge / Powerfest boards.