Home Page Forums MAME MAME The SNES WIP topic

NVRAMs should be initialized with 0xff, cause of why Super Drift Out doesn't initialize it properly. Finding a solution for it...

EDIT: done:
r7795 /src/mess/ (11 files in 4 dirs): Added fill parameter to image_battery_load / image_battery_load_by_name, and fixed SNES NVRAM fill to be 1, fixes Super Drift Out SRAM data





Obviously you need to delete any "broken" .nv and probably recompile.

Mapping something beyond its own accessible address isn't so bad. You have to approach it from a hardware address line perspective.

Let's say you have a 16 byte space, and you have 11 bytes worth of unique data. How would you make such a board for real? Keeping in mind that virtually every ROM is a power of two ...
8 + 2 + 1 = 11

Now think about how you'd wire up such a board.
A3 == 0 ? ROM0 { A2, A1, A0 }
Else A1 == 0 ? ROM1 { A0 }
Else ROM2 { }

That would give you an interesting pattern:
0123456789AA89AA

0-7 = ROM0
8-9 = ROM1
A = ROM2

Of course, virtually all our sizes can be done with only one or two ROMs, so it's usually just very simple mirroring.

But we can make a simple algorithm to transform an address with the above mirroring.


It's a bit prettier in recursive form; but it's slower that way and some of my maps are dynamically modified through MMCs, so

byuu, I understood the ROM mapping when you first explained it two years ago (and MESS code works fine since then).

I'm now interested to understand in which way you handle WRITES to those areas, if there is cartRAM there (notice: RAM and not ROM )...
I think I'm doing it right (now, after 2-3 lines changed), but for some reason the code fails for some SuperFX mirroring... that's why I would still like to fully understand your code, which seems to cover those cases fine as well.

Apparently not, because there is no distinction between reads and writes in my explanation. And thus, no distinction between ROM and RAM.

In my example, if a read from offset 11 returns "B", then a write to offset 11 will overwrite "B". Thus, the next time you read from offset 10, 11, 14 or 15; you will get the new, overwritten value.

Of course, in practice, I have a granularity of 256 bytes; because a 128MB table of 64-bit pointers is a bit ... extreme. But that's more than enough for any official software.

thanks a lot for the answer, really

this unfortunately makes harder to find our SuperFX problem, but at least it rules out mapping as the main reason. I'm going to review our SRAM code, eventually to check once more that writes are handled properly...

once again, byuu, you're help is invaluable!!

Final Fantasy III (U) (V1.1)



Graphics corruption during intro screens.

SVN 7847 [32-Bit]

svn 7865

Earthworm Jim 2: Sound problem

At the very start of the cart he plays an accordion but you can't hear it just a few clicks.

Edit: I don't know if this is a known bug so just ignore me if it is this sound problem is also on zsnes???? hmmmm might be my cart

Edit 2: Nope not my cart as it sounds fantastic on BSNES


Also:

I tried Mr Do! on the snes and there is a graphics glitch in M.E.S.S.

this is the zsnes version



this is Bsnes




and the M.E.S.S. version - notice the EXTRA monster is missing from the top of the screen (see red arrows above)

Earthworm Jim 2 requires really, really good CPU<>SMP timing. It spools sound effect samples via HDMA. Same thing as Clayfighters: TE, d4s' music engines, and blargg's CD-quality audio test.

Has anyone else noticed a major sound regression in the SNES driver. From my compile, both background music and sounds are replaced by crackling?

Thanks

Yeah, eta can't do math. I'll fix it

Edit: Pull latest SVN and it's fine.