Home Page Forums MAME MAME The SNES WIP topic

Yes, it's something that happens from time to time, presumably due of timing issues in the CPU core.

Quickly checked out EarthBound:

C0A11E: A9 30 LDA #$30
C0A120: 8F F0 7F 30 STA $307ff0
C0A124: 1A INA
C0A125: 8F F0 7F 31 STA $317ff0
C0A129: CF F0 7F 30 CMP $307ff0
C0A12D: F0 0C BEQ c0a13b ($c) ;if not equal, copy protection failed

Tries to check a SRAM mirror in there, and, again, I don't know the mumbo-jumbo of SNES mappers, so leave it to Eta ...

cool. in the past two years nobody tried this specific game in MESS (given that last SRAM changes happened in Nov 2010)

tonight/tomorrow I'll see if I can fix this without breaking Donkey Kong Country, Super Metroid and Super Tetris 3...

Mario no Super Picross does something similar as well. Except that it accesses the SRAM at 0xb07ff0 / 0xb17ff0

Well, SNES only ever really had two very loosely defined "mappers", which don't actually relate to the hardware underneath, but it's actually only a problem for... something like 5 games, and all of THAT is only when using the 32K-oriented "mapper" aka LoROM.

From the address, you're looking at a classic "HiROM", so it's pretty straight forward how SRAM is masked:

x011 xxxx:011x xxxx xxxx should be bang on, if memory serves (banks 30-3F and B0-BF, address range of 6000-7FFF).

I'm a bit fuzzy on whether anything ever used or mapped banks 20 to 2F (and that implicitly maps A0-AF). If memory serves, that was at most a single board revision, and none of the games on it used that.

the low four bits of the bank are used to select 2K pages of SRAM as needed. SRAM repeats. If you have 2K, it repeats every bank. 4K, every other bank, and so forth.

It's pretty straight forward, from a hardware perspective: the mask is run through some NAND gates that control the enable line to the SRAM, so they aren't used for addressing the chip. Hook up only as many of the remaining address lines as needed, starting from the lowest.

If you'll notice, Kale's example is the exact same test as the Earthbound test, except A23 is set. This is perfectly normal, and one fix should work on both, if SRAM sizes are correct...

Well, my POV is that HW shouldn't be named by inexistant "modes", that's just an invention/simplification of whoever did emulate SNES first. And I know it's simple in the end, it's just that I don't want to bang my head on it because it contradicts my concepts of "faithful emulation".

the 0x30-0x3f <-> 0xb0-0xbf are not the problem, nor it is the 0x20-0x2f <-> 0xa0-0xaf... we match bsnes behavior, so I guess we are safe (and I'm pretty sure I had double checked two years ago)

it is the interaction between "SRAM repeats" and our current saving/loading procedure which is a PITA to handle correctly...

been busy tonight, I'll try to get a fix tomorrow

I think I have fixed this. After dinner I test DKC and if everything loads/saves properly, I will then commit the code

I have also decided that once I'm done with NES slot-ification, I will rewrite the memory handling for SNES because it is really awful to handle...

Fix added to svn. All my testcases work fine.


before 0.148 I will update the code to only save the actual SRAM size without the mirrors, saying goodbye to current 1M .nv saves and fixing the old bug #1742 (bugzilla is gone, but I haven't forgotten )

It turned out that Dezaemon had its (large) SRAM mapped in the wrong way for ages (maybe since the beginning?) and nobody reported earlier (IIRC) that it complained during selftest about a "S-RAM Break Down"

Thanks to PooshhMao's report, I finally got aware of that and I fixed it locally





will add it as soon as I understand if the glitches are due to some further mapping error...