Home Page Forums MAME MAME The SNES WIP topic

I agree with everything you just said, byuu I didn't realize Regen was also closed source though. At least there's a concerted effort to document Genesis h/w behavior in the open over at SpritesMind. Should get interesting once they're done with the YM2612 and move on to the VDP.

And yes, the real hardware doesn't care about the header. The hardware on the cart does the mapping, period.

I would suggest that if ZSNES bugs are hampering translations, then maybe translations groups should advertise prominently that their stuff only works on hardware or in bsnes or (hopefully) MESS.

I like your XML mapping stuff, it could very easily be included in MESS's XML software list.

yeah 'header magic' is bad, it can give an indication, but the reality is you need a better way of specifying it to be sure.

with the MESS software lists, I guess it can be specified in the game list XML, and that will translate to some setting in the code (as would be the case with any other header)

Of course if you want to keep the open-ended approach too then supporting an open format which includes such details will be needed as well, but as you've already seen, getting any kind of traction with new ideas is difficult.

This is why I prefer the MESS 'fixed list' (be it internal or external) approach. It's just essentially a database of what each game needs, it means you don't have to mess around with the roms, or rom formats. The database tells the emulator what to do, the roms are in their native format.

Yes, some people might not like having set names, but creating even more rom formats is probably just going to result in only a handful of people caring, and plenty of people confused as to why a new format is needed, and simply ignoring it.

I've heard this viewpoint espoused before with that FMV-playback thing, and I've also heard that it's really not true. This was mentioned to me by someone who has done actual SNES development back when games were still under active development for it - you certainly may put an 8-core Nehalem-EX inside a SNES cart if you want to, but good luck feeding it data fast enough or getting data off the cart fast enough. There's a pretty low ceiling on exactly how fast the DMA engine can shove data across the bus, and while you can bolt pretty much anything onto an emulated machine, I'll be very interested in seeing the issues that crop up if you ever actually try to implement an accelerator in hardware.

Well, byuu's got his "MPEG" module in software, so that's a start. Hopefully a hardware implementation comes along...

Right, but bsnes also implements the correct DMA bandwidth limits and yet they have working FMV, so

The point does stand that the base hardware limits the usability of what you can chuck into a cart though.

I don't know, I guess I'll believe it when I see it working on an actual SNES using an actual proper mass storage device.


Right, that was more what I was trying to get across.

He also had GPL code in the first few versions, but still didn't release his code. The worst possible case, benefiting from people who share whilst not returning the favor


Oh, it's much worse than that. The latest was a team who released a patch that only ran on ZSNES. When they found out it didn't work on hardware or other emulators, they espoused, "well, it doesn't really matter, just use ZSNES instead."

I was as polite as possible and offered to help debug and fix the issue for them, but they were very notably perturbed that people were upset with the patch.

It bothers me because one day we'll either have to:
a) create a ZSNES emulator, or
b) completely lose these gem translations for good

And now from the other side of the spectrum: when I released my DL translation, I had two people accuse me of hacking it to ONLY run on bsnes. Nevermind the fact that the original, unmodified Japanese game also locked up and crashed on ZSNES ...


My plan was to match the loaded SHA256 sum to the database, preferably with an O(log n) search. I can understand how calculating an SHA256 sum would be a problem for MESS on CD/DVD-based systems. But for ROMs, it's more fool-proof. Can't trick the system by renaming a file wrong, and rainbow attacks on SHA256 are pretty hard at the moment.


Okay, sure
http://byuusan.kuro-hitsuji.net/lunar.sfc

This is the Lunar: Silver Star Story MPEG opening, encoded at 240x160x8bpp @ 30fps along with 32KHz stereo sound output, running on the S-DD1 hardware.

The only way in which it cheats is by accessing 64MB through the S-DD1 MMC, whereas the ROM on a real cartridge was 6MB in size. However, someone took that file and cut it to 6MB and was able to run the first several seconds off his cart. I can try and find out who, but it was mentioned on the nesdev thread by smkdan about his video ROMs.

I am happy to go into the explanation, but I am beyond 100% confident that the above is fully and completely possible. It's actually really, really very easy to do.


Of course. My point was that the cartridge could have anything inside of it, not that the SNES could fully utilize what was there

You could for instance turn it into a really souped up DSP-1 if you wanted. Or have Deep Blue's chess algorithm going.

By saying you could put anything, of course it's a bit asinine since all commercial games ever made have been released. We have a fixed set of chips to support. I was more trying to represent that the chips inside the cartridge are not part of the SNES itself. Having DSP-1 support doesn't mean it's part of the SNES emulator, it's a DSP-1 chip emulator, or essentially a specific cartridge simulator at that point.

I had no idea things were that bad. Nobody should ever release a "finished" translation that doesn't run on hardware. You're starting with a game that runs on hardware, it's not that difficult to make sure it stays that way.

The thing is that most of these people don't have copiers or flash cartridges to test on hardware. So they use the most popular emulator to test as they go along. Naturally that emulator lets you do a million and one things real hardware won't allow, and they don't even notice.

The biggest one is that VRAM writes are not allowed during active display. To fix this, you add this code inside vram_write():
if(vcounter() < (overscan() ? 240 : 225) && !display_disabled()) return;

Won't break any known games, will actually *fix* Hook (U) garbage in the intro, an active bug since the very first release.

I was told some games were too timing sensitive, which I don't believe, but okay fine. Adjust the range. instead of 240/225, do 245/230. It's not perfect, but it'll give a lot of extra coverage for bad timing.

But nope, still not fixed. Just off the top of my head, it's broken the following fan translations:

Dragon Quest 1&2 Reprise - title screen graphic broken <broken forever, patch author is dead>
Dual Orb 2 - Yes/No menu broken [updated patch fixes it]
Mystic Ark - text is invisible [updated patch fixes it]
Sailor Moon - Another Story - intro text is corrupted <broken forever, patch author vanished>
Ys IV - no text is visible in dialog boxes [updated patch fixes it]

I've also hit this bug myself when I first found out about it in 2000 or so. I'm sure there are many more examples.

I've gotten at least three false bug reports on Sailor Moon, one on Mystic Ark, and two or three on ROM hacks. People see it working in ZSNES and assume the bug is on my side.

Another patch which works in zsnes or other emus which ignore vram restrictions is fusoya's Secret of Mana VWF font patch. (or at least i've been told it doesn't work on real hardware, I've never tried it) http://fusoya.eludevisibility.org/som/index.html
I keep hoping one day someone will fix that patch to work on real hardware (I wouldn't think waiting for vblank in the code before vram write would be very complicated, but it might royally screw up the rest of the code and do a million and one other horrible things)

LN