Home Page Forums MAME MAME The SNES WIP topic

Yeah, the libs come in the download for Windows, I'm not sure what the issue is

To be fair, you guys'd get pretty pissed if users just started downloading random crap off the Internet and then complaining about how they can't compile MESS, when there are guides around that supposedly tell you exactly how to compile it. In this case, http://board.byuu.org/viewtopic.php?f=3&t=74

ETA: For what it's worth, "configure" does seem to be working, it's just taking a long time to configure everything. I think it took about 10 minutes to get through network.pro, and that's on a 1.86GHz Core 2 Duo.

Aha. Since LDW/LDB/STW/STB were changed to shunt around memory buffering for testing purposes, they weren't setting cpustate->ramaddr. SBK relies on cpustate->ramaddr. Now that they set ramaddr properly, there's a slightly larger amount of happiness:

The firework particles at the beginning of Vortex now show up properly:



Also, Stunt Race FX is considerably improved, including the tires now rotating the right direction on the car-select screen, and actually being able to get in-game and play. There are still some issues, though: The cars keep "popping" upward in the car-select screen, and bits of the scene geometry keep dropping out.

regs.sfr.irq is used by the SuperFX MMIO registers at $30xx. cpu.regs.irq is checked by the S-CPU core (in timing.cpp IIRC) to trigger an external IRQ event.


I can't answer your question in that case
I'd rather not break the mirroring in my own emulator to see what happens, heheh. Anyway, sounds like you got most of it figured out now, hoorah!


You'll need them to be for GCC 4.x as well. For whatever reason, last I checked Qt was only officially supporting 3.x. But it still builds fine with 4.x anyway.


You never know, if it loops polling a value from the CPU to be set, the logs won't line up.

Then again, I was using FuSoYa's closed-source Snes9X SFX tracer (don't want anyone stealing those fprintf statements I guess) and generating ~40MB worth of logs to compare to. A warning if you do, there's a bug somewhere in his tracer, I think it was involving ROMB. If you run DOOM with the tracer on, all the graphics get corrupted.

And my disasm thing spits out the register values as well. But you may as well dump them in binary format or whatever.

Well, whatever works for you. Just mentioning it.


Yeah, it's a huge library. Very slow to build. The tutorial thing on my page lets you turn a lot of stuff off, I can usually configure and build in about ~15 minutes with it.


Ah, I remember that. Took quite a while to figure it out.

Looks like progress is coming along great. Let me know when SMW2 is working good. I'd like you to test something.

---

Anyway, sign up at my forum and post your user name here. I'll give you access to the dev forum. You can do searches for SuperFX and find some common bugs + fixes from me and Jonas Quinn.

Registered, as my typical MG handle.

I've been doing some investigation of the polygon drop-out in Vortex, it seems like the color that it's getting via either GETC or COLOR is messed up.

Argh, I'm a dumbass. It just now clicked that "regs" contains the SuperFX registers, but "cpu.regs" corresponds to the S-CPU registers. Grah.

ETA: Hmm, no. No, hooking up the S-CPU IRQ didn't seem to actually affect anything.

ETA2: Dammit, I reimplemented RAM and ROM buffering based on bsnes's spec, and it also isn't affecting anything. At least we're narrowing things down here.

ETA3: byuu, do you have a copy of this? bsnes_v046_wip13.tar.bz2

As it turns out, HIB checks against 0x80 for the sign bit and not 0x8000. Oops.

There are clearly still some problems lurking, as all games suffer from random culling and Z-buffering issues, but now Star Fox is ostensibly playable, and Vortex is not far behind once I hook up some mirrors:





















More pics, not inlined because UBB is lame:

http://moogle-tech.com/mess/superfx/9-3-2009/sf10.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf11.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf12.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf13.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf14.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex6.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex7.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex8.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex9.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex10.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex11.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex12.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex13.png

cool!

Argh, thought it was more important. It has to be used *somewhere* ... hmm. I know the SA-1 games use almost every last feature (except timer IRQs). Some features are used by only one game.

The SA-1 is better for adding little by little. Just cloning the S-CPU core is enough to get almost half the titles running, had that up in a day.


That one had a big impact on timing in Winter Gold for me. All the skiers were flickering before I added it.


Sure, I have everything from v019 and above. Accidentally formatted the hard drive with the earlier versions.

http://byuu.org/temp/bsnes_v046_wip13.tar.bz2


Ah, so then you aren't using copy/paste for your opcode core. Perhaps I'll do a once over tomorrow to see if I can spot anything obvious.

You should try some SuperFX2 games. The only difference is the memory timing.

Overall, looking really good!

Awesome, thanks! And that's correct, I'm not doing a direct copy/paste. I'm pretty much looking at your code and translating it to MAME-ese on the fly, but every so often I'll inadvertantly miss something.


Unfortunately, none of them boot in MESS, presumably because of cart mapping issues. Neither Doom nor SMW2 even attempt to access the SuperFX chip before hanging.


Thanks, and thank you for writing such a good reference emulator!