Home Page Forums MAME MAME The SNES WIP topic

Star Fox:






Stunt Race FX:




Vortex:






byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?

I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.

- Stiletto

Incidentally, do you think those issues could be caused by mirroring where no mirroring is present, or having no mirroring where mirroring is present?

Basically, what I want to know is: if the SuperFX reads from a SuperFX memory address of 0x712345, does it actually read from index 0x2345 in the FX RAM buffer? If the S-CPU reads from 0x356789, is this the same as a read from 0x306789, which itself is a read from index 0x789 in the FX RAM buffer (due to mirroring)?

Thanks in advance.

while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release


?

we included the SFX core (uniquely based on your implementation) on the assumption it was original design and, hence, PD as most of bsnes

finally, is Nach missing in action? I tried to contact him with no luck about some code of his...

Just a question,
did you read http://byuu.org/bsnes/license/ ?
I don't understand English perfectly but reading this I think that bsnes is not Public Domain, not exactly...

ok, I've definitely chosen the wrong wording and it's not public domain (even if, since he started working on his emu, byuu himself defined Public Domain bsnes source for quite some time )

however, as byuu has stated many times, bsnes can be used freely as a base for implementation in other emu (and he already kindly donated to MESS part of the cart recognition code) and this kind of free reference implementation is what we need for MESS in this particular case

Grah. I'm trying to do a side-by-side execution comparison between bsnes and MESS, so as to track down the remaining issues, but for the life of me I can't compile bsnes. Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it. When I get home from work I'll see if I can find out exactly where.

Yes. The registers just return the current time. Don't give it localtime() info, or the "round clock to the nearest minute" feature of games won't work, and the time setting screens will be pointless. Plus it'll break in 2014, as you can't set the clock higher than that in FEoEZ.

All the extra code in bsnes is to let you specify whatever time you want, and update it as real system time passes. Plus it has to work around libc localtime()/mktime() issues with dates outside the system epochs (the S-RTC chips have no such limitation.) And lastly, I store a 4-byte timestamp no matter what (so the same .rtc state file works on 32-bit and 64-bit systems), and use some trickiness to work even beyond Y2K38. Fun stuff.

If you could, please keep compatibility with my .rtc file format. SNESGT uses the same. Snes9X stupidly appends it to the end of .srm files (causing all other emulators to erase it), and ZSNES just uses the current system time.


Not at all, sorry. For me, horrible crashing was usually due to opcode bugs, and I haven't had any of the other issues.

Are you handling IRQ communications between chips properly? Eg the GSU STOP command and such.


I would strongly advise you to handle the mirroring properly (per my map on the previous page.) But I couldn't say for sure, mirroring was one of the first things I did.


Yes, that is correct. I looked at the Snes9X and SNESGT implementations, but wrote it all myself. And had a dozen bug fixes provided by Jonas Quinn. As you no doubt know, integrating someone else's CPU core is very tough, as they tend to hook all kinds of external stuff: IRQ triggers, a custom memory mapping system, etc.


I haven't heard from him either. Both Nach and pagefault tend to disappear for months on end sometimes, though. Hard to say if anything is wrong or not. I certainly hope not.


It's kind of complicated. I defined all the special chip stuff as PD (except the modules I didn't write myself), but that was prior to SFX/SA1 support.

I don't mind if MAME or MESS use those cores, at any rate. In fact, I encourage it. If you guys use it, and then spot a bug, please let me know and we both end up benefiting. No need to reinvent the wheel, we aren't competing after all.


Ironically, the Windows port is the worst version of Qt. The OS X version is pre-compiled, and the Linux version is even easier: a single apt-get command.


The timing differences will make it very hard to compare line-by-line, but be aware of the disasm modules for all of my cores. You will have to hook calls to it yourself in the ::enter() routines, and put the data in files yourself. v048 may be better, it had part of a tracing interface. I'm in the process of redoing that for a debugger as of v049+, so it will be harder to work with there.

I think so:


It makes perfect sense for the IRQ flag to be set in SFR, but I wasn't able to track down where exactly the "irq" class member variable is used. It doesn't appear to have a purpose inside your Super FX core, and I didn't find anything referring to it in the rest of the emulator. Is this true?


No offense intended, but that was the entire reason why I asked those two questions.

I'm still having some trouble wrapping my head around where, exactly, a given byte write to a given address by the S-CPU goes in relation to what the SuperFX chip then gets back. Those two questions were carefully designed such that, when answered correctly, will give me most of the info I need to do that.

I'd hazard a guess that I probably have the mirroring correct now, though, or there would be far worse problems, since SRFX and Vortex are at least drawing most of their triangles, and SF is now drawing line "primitives" (but not triangles).


Are there no pre-compiled binaries of Qt 4.5.2 anywhere?


The timing differences are immaterial, as I would only be logging the opcodes executed by the Super FX chip. Also, I'm not interested in a diassembly, I'm interested in actually printf-ing the full register state after every single opcode, using some format like:


...and then make MESS output exactly the same thing. It'll produce a gigantic log file, probably a number of gigs in size, but that's not an intractible problem, I'd just use a binary diff program rather than visually diffing.

Trust me, this is how we tend to do things with MAME and MESS.

Eh? http://qt.nokia.com/downloads

Is byuu modifying Qt or something? I'm not familiar with his makefile...