Home Page Forums MAME MAME The SNES WIP topic

Would anyone kick up a fuss if I just embedded the RGB PPU palettes in the source? It's not like it's possible to conventionally "dump" the internal PROMs, and AFAIK we don't even know how (bit order-wise) the data is stored inside the PPUs.

Yes, they would. It's dead frakking easy to access loaded ROM data in this era of named regions, and size doesn't matter (the palettes are unlikely to be smaller than the SPC700 IPL ROM, for instance).

That's not the objection I have, it's that we don't have any idea how the bits are arranged inside the PPU (unless someone's decapped one at some point?) Even the fact that there are 9 bits per color is no more than logical induction based on the range of colors seen in the five PPU types that have distinct RGB palettes.

Treating the PPU palettes as ROMs doesn't make any more sense to me than trying to turn, I dunno, the YM2143 fixed instrument parameters (or any of the other lookup tables used by the YM sound devices) into a ROM.

I don't understand what not knowing the final format has to do with how the data should be stored. If we ever find out for sure, change the files and the checksums. Big deal. And the YM2143 samples will eventually be converted to external load - it's on my todo list, albeit at a fairly low priority.

I actually agree with AWJ here. There is no indication of what the real format is at all.. The palettes have been reverse engineered, not 'dumped' Putting them in a ROM file just seems misleading.

We put stuff in ROM files on a fairly regular basis that isn't actually ROMs - the original Naomi keys, for instance. And then when we find out the real format, we replace the files.

fwiw Pachio-Kun Special (J) hangs soon after selecting the data to load / new game.
Another game to put into the timing crap.

EDIT:
#Shin Nihon Pro Wresling Kounin '95 Tokyo Dome Battle 7 (J) (executes bad code)
#Super Trump Collection (J)
<- another two games to put into the timing hell

I'm not sure the timing is as much of a problem as you guys are hoping. ZSNES doesn't even count cycles when executing the CPUs and it runs most if not all of those games cited. (It may be that eta's various attempts to enforce timing when we don't have any is ultimately harmful though).

According to some SNES devs on which I've talked in the past, the ZSNES has so many hacks and I wouldn't trust it at all due of that ...

And, btw, when I say "timing" I just list games that I wouldn't like to check as first ones, because the timing thing is almost surely the reason about why they don't work.

Nobody loves to lose time, in short

I don't follow you... which attempts are you referring to?
I have done no timing work at all until now.
I have only fixed drawing routines (because we were lacking many video effects), enabled HDMA in both directions and improved HDMA init and update procedures, and moved constants to a struct... none of these modified the SNES timing, which is still the same as last September...

EDIT: also, given the number of games which improves when you change cpu/apu clocks, maybe the timing is not the final solution to all the reported problems, but it can have a notice-able impact