Home Page Forums MAME MAME The SNES WIP topic

Just saw that the SGB BIOS was dumped, neat.
http://www.its.caltech.edu/~costis/sgb_hack/

Reminded me of my old work on emulating the Super Game Boy. Unfortunately, I got stuck due to my limited knowledge of the Game Boy hardware. While I myself was using gambatte as the Game Boy core, I imagine MESS is in a great position to use their own core.

So, how interested would you guys be in working with me to emulate something new for the very first time, as opposed to simply adding all these old chips in?

My research notes are here:
http://byuu.org/files/supergameboy.txt

The problem I'm having is explained under the $7800 register section, and I'm also quite stumped on the purpose of $6001.

I've gotten far enough to have the entire SGB BIOS running, all Gameboy non-SGB games running perfectly with full video, audio and input; and I've gotten a few SGB-specific commands to execute, but again, that $7800 problem makes almost everything unplayable.

I took out the code from the core because it was too unstable (and because I wanted to modularize the GB portion to a DLL/SO library), but if anyone is interested I can post one of the public v045 WIPs that had the aforementioned support.

Note: I'm looking for more than suggestions, eg actual help: testing ideas directly and such. Someone familiar with the GB-side of things would be quite valuable.

Nice info there. I've been planning on removing the seperate supergb driver we have in MESS now and replace it with full snes+gb emulation so it can work more like the real thing did. But I have not done anything towards really adding it yet.

What I did notice is that after the initial sending the gameboy rom information the actual sgb games read back from ff00 and expect to not see the lowest 2 bits set. If both bits are set the games will not send any sgb games, otherwise they will. I don't think that explains anything about 6001 and 7800 though.

fixing a small mirroring problem gives us Star Ocean title screen



not sure still why it freezes when you press Start, however. I'm going to investigate SRAM in the afternoon, just to be sure the problem is not there.

otoh, it could well be a problem in our core emulation, since it's not the only game with this (annoying) behaviour


EDIT: you can play Star Ocean by underclocking maincpu below 50%! it's definitely a CPU sync issue. this means that S-DD1 is now supported in MESS

Maybe we need a " Thank You " button in the forum.

Thanks, etabeta78

Hey byuu, who do I need to get permission from to include SPC7110 in MESS?

byuu itself did most of the research with the guys mentioned in the source / docs. I think it is enough to provide due credits in this case.

neviksti was the one to crack the decompression engine, and I optimized a bit of that, removing some loops and generating a lookup table to de-interleave bits. I also emulated all the rest (data port, math, memory mapper, RTC units) by studying the hardware test.

neviksti said PD, as did I, so no credit needed as per the S-DD1, S-RTC and SuperFX modules.

And lastly, don't forget that you'll need proper S-RTC support: if you just give it the system time, you won't be able to pass the FEoEZ test program on startup without a hack.

Just be sure to keep compatibility with my .rtc save format if you port over my code. SNESGT and Snes9X WIP also use it. The crazy time_t handling is to allow it to work even after Y2k38 even on 32-bit time_t systems.

I'll burn that bridge as I cross it, for now I'm just trying to get Momotarou Dentetsu Happy working, I'll worry about FEoEZ later.


I'll look into it. My only worry is that the MAME and MESS architecture is very strict about how it handles saving NVRAM - the data is deserialized into an .nv file, and there are no methods provided for saving ancillary data streams in arbitrary files. I'm sure there's some way I can do it, I just can't think of any at the moment.

I fear at the moment we are strictly forced to save these data in gamename.nv. once MAME adds support for multiple nvram/sram files we may immediately add support for these .rtc files.

for the time being I fear we have to append the rtc content at the end of the sram

What's in the .RTC files and why is compatibility such a big thing? Honestly it's in everyone's interest to discourage emulator-hopping lest it cause weird bugs that don't otherwise happen.