byuu says:
Re-added blargg's DSP, but this time I merged only spc_dsp and also
fixed the initial regs for Dual Orb II. Which restores the 5-10% speedup
on the compatibility and performance cores. Fixed the initial register
values for the fast CPU core, which fixes Armored Police and the other
Atlus game's title screen in the performance core. Added a missing
debugvirtual prefix to op_step, which fixes CPU stepping in the
performance core. I was using the description field for profile
identification in savestates, but that was of course the description for
the state manager. Whoops. Added a new field for profile name to the
save states, and fixed the state manager to work with that change.
Adjusted the about screen colors, which is how you can tell which core
you're using without it being annoying. Probably did some other stuff
too, meh.
byuu says:
Removed snes_spc, and the fast/smp + fast/dsp wrappers around it.
Cloned dsp to fast/dsp, and re-added the state machine, affects
Compatibility and Performance cores.
Added debugger support to fast/cpu, with full properties list and Qt
debugger functionality.
Rewrote all debugger property functions to return data directly:
- this avoids some annoying conflicts where ChipDebugger::foo()
overshadows Chip::foo()
- this removes the need for an extra 20-200 functions per debugger
core
- this makes the overall code size a good bit smaller
- this currently makes PPU::oam_basesize() inaccessible, so the OAM
viewer will show wrong sprite sizes
Used an evil trick to simplify MMIO read/write address decoding:
- MMIO *mmio[0x8000], where only 0x2000-5fff are used, allows direct
indexing without -0x2000 adjust
So end result: both save states and debugger support work on all three
cores now. Dual Orb II sound is fixed. The speed hit was worse than
I thought, -7% for compatibility, and -10% for performance. At this
point, the compatibility core is the exact same code and speed as v067
official, and the performance core is now only ~36-40% faster than the
compatibility core. Sigh, so much for my dream of using this on my
netbook. At 53fps average now, compared to 39fps before. Profiling will
only get that to ~58fps, and that's way too low for the more intensive
scenes (Zelda 3 rain, CT black omen, etc.)
It would probably be a good idea to find out why my DSP is so much
slower than blargg's, given that it's based upon the same code. The
simple ring buffer stuff can't possibly slow things down that much.
More precisely, it would probably be best to leave blargg's DSP in the
performance core since it's a pretty minor issue, but then I'd have to
have three DSPs: accuracy=threaded, compatibility=state-machine,
performance=blargg. Too much hassle.
Only code in the core emulator now that wasn't at the very least
rewritten for bsnes would be the DSP-3 and DSP-4 modules, which are
really, really lazily done #define hacks around the original C code.
byuu says:
Fixed bsnes launcher on Windows XP
Fixed Windows bsnes launcher internationalization support (emulator can
be in a folder with spaces and Japanese characters, and you can drag
a Japanese file name onto the launcher, and it will load it properly)
Moved fast CPU to use a switch table for MMIO, unfortunately for no
speed gain
Bus::read/write take uint24 parameters for address, luckily no speed
penalty
MMIOAccess gained a handle() function, and hid the mmio[] table. Makes
hooking it cleaner
Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0
error
Fixed a fairly large bug in the fast CPU IRQ handler, which fixes
Robocop et al
Forgot to bump revision to .24 in the compiled binaries, too lazy to
recompile or hex edit to change them
Unfortunately, in order to add nice battery usage, I have to add the
sleep calls to the video and audio wait loops. But they don't know
anything about the GUI and its settings, nor do I really want to make
them know about this setting. I do not want to force allow it. Even with
the media timer trick, Sleep(0) makes Vsync+Async fail a lot more
frequently than never sleeping at all. I would rather laptop users
suffer 100% utilization of a single core than for all users to not be
able to get good audio+video sync. Not sure what to do about that, so
I'll probably just remove the battery usage comment from performance
mode for now.
byuu says:
Since we're now talking about three splits, that's getting a bit out of
hand.
This WIP combines everything back into one project again. Added the
src/fast folder that has all the speed-oriented cores.
A slight slowdown to csnes from what it was before, I'm using blargg's
accurate DSP. I just don't like the idea of releasing a less accurate
DSP core than Snes9X v1.52 has. Plus the fast DSP core doesn't serialize
yet.
I moved back to snes_spc 0.9.0 because I care more about Tales and Star
Ocean than I do about Earthworm Jim 2. So if you try EWJ2 on csnes,
expect it to sound like it does on Snes9X. In other words, don't wear
headphones if you value your hearing.
The middle-of-the-road bsnes core uses blargg's accurate DSP, because
it's about 3% faster than mine which removes all of blargg's
optimizations. There is absolutely no accuracy loss here. bsnes v067.20
that is included should be equal to v067 official.
Performance:
Code:
asnes = 58fps
bsnes = 172fps +2.97x
csnes = 274fps +1.59x +4.72x
The binaries are not profiled, so that's an additional 15% slower from
the previous builds.
Save states only work on asnes, as I don't know how to serialize
blargg's cores yet. The copy_func thing is very confusing to me for some
reason. The debugger won't work anywhere.
Outside of that, please go ahead and bug test. Once I get the debugger
and save states working, I'll build some profiled v1.0 releases for all
three, and we can test that for a bit and then release.
Tim Allen