I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip?
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.
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?
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.
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)?
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.
while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release
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.
finally, is Nach missing in action? I tried to contact him with no luck about some code of his...
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.
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 wink )
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.
Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it.
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.
I'm trying to do a side-by-side execution comparison between bsnes and MESS
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.
