2010-08-14 - bsnes_v067r21_xaudio2 (OV2, http://board.byuu.org/viewtopic.php?p=17941#p17941)
I finally had some free time again and decided to give it another go. Here is a new version with a custom xaudio2_ruby.h header file that requires nothing else (it includes only BaseTyps.h, which should already be in the mingw include dir). No additional linking should be required.
If this is acceptable I can reroll it once you've completed the current source changes.
Diff and source files

2010-04-05 - bsnes_v063_lockless Direct3D (Ver Greeneyes, http://board.byuu.org/viewtopic.php?p=13690#p13690)
New build is up, get it here as before!
This fixes some extremely minor synchronization issues and a possible race condition, but mainly it adds a mechanism to try and minimize the delay between bsnes pushing a new frame and it being rendered (during the next VBlank). It does this by simply keeping track of the minimum interval in between Present() calls returning and the maximum delay in actually rendering a frame. There's practically no overhead to doing this and as far as I can tell from my tests, the delay it sets is conservative enough to not lead to any missed VBlanks. Note that entering the menu -will- cause you to miss VBlanks and will lead to a more conservative estimate. The estimate will also be reset on any mode changes, such as changing to a different filter, switching to fullscreen or changing the scale factor.
There are a few things to note about this.
1) The difference in minimum latency is going to be very small, at most 5 milliseconds. Of course, latency -does- add up, but you're very unlikely to notice any difference. In fact, this change is more likely to benefit extremely intensive shaders, which might not have had enough time to complete rendering before. Come to think of it, I should cap the wait time to 0 for shaders that are so intensive that they can't run at 60fps.
2) Although this extends the window of opportunity for the renderer to pick up on a more recent frame, this does not mean that latency will necessarily be reduced. Consider a hypothetical situation where bsnes and the renderer run entirely in sync, and bsnes is pushing out frames right after every VBlank. In this case, you will still get ~17ms latency as the renderer will only be able to display these frames when the next VBlank rolls around. In reality there will always be some drift between bsnes and the renderer, which should give you latency between ~2.5 and ~19 milliseconds (assuming no other sources of latency), for an average of about 11ms.

2010-04-03 - bsnes_v063_lockless Direct3D (Ver Greeneyes, http://board.byuu.org/viewtopic.php?p=13621#p13621)
Alright guys, here's something for you to play with: my first attempt at a lockless Direct3D driver for bsnes. VSync is handled by D3D itself, and the DWM may very well get in its way, so although I'd appreciate it if you let me know how well VSync works in this version, fixing VSync is not its main purpose. This version -does- decouple bsnes' main processing thread from the driver, which should mean that periodic audio crackling is a thing of the past. Audio crackling may still happen if you get series of spikes in system latency though - there's not much I or anyone can do about that (well, maybe bsnes could try to make its audio buffer catch up, but I think that would involve some fairly heavy internal changes).
The build is available here in 7z or rar format. This build also includes all the HLSL shader work, the latest version of which has unfortunately not received much testing. I think I was able to work out all the synchronization-related stability issues, but let me know if you get any crashes! Note that VSync is always enabled in this build (unless you forcibly disable it driver-side, perhaps), so the Video Sync option does nothing.

2009-12-11 - bsnes_v058_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=9300#p9300)
SPC dumping version, 32-bit this time around. [Windows binary](http://kode54.foobar2000.org/bsnes_v058_spc_dump.zip) [source patch](http://kode54.foobar2000.org/bsnes_v058_spc_dump.patch.gz)

2009-11-04 - bsnes_v055_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=8062#p8062)
It's 64-bit! It rips SPC files! Woohoo!
It only took several hours to compile Qt with MinGW-w64, but it was sort of worth it. Especially to find all the pointer->int casts it makes. So, without further ado:
[binaries(http://kode54.foobar2000.org/bsnes_v055_x64_spc_dump.zip)] [patch for SPC ripping(http://kode54.foobar2000.org/bsnes_v055_spc_dump.patch.gz)] [patch for x64 building(http://kode54.foobar2000.org/bsnes_v055_x64.patch.gz)] [patch for making Qt build with MingGW-w64]
You can have a 32-bit version when I feel like compiling Qt all over again with a 32-bit toolchain.
Oh, and I'll get around to fixing libjma for 64-bit builds, I'm sure that will be appreciated as well.

2009-10-19 - bsnes_v053_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=6952#p6952)
The process terminates cleanly with the latest Qt SDK, 2009.04, which claims to be 4.5.3. The self-termination hack has been removed as it is no longer necessary.
I've bundled the included mingw binaries as well as a profiled SPC dumping build and related snesfilter/snesreader binaries.
[Qt runtime] [bsnes v0.053 Windows binary(http://kode54.foobar2000.org/bsnes_v053_spc_dump.zip)] [source patch(http://kode54.foobar2000.org/bsnes_v053_spc_dump.patch.gz)]

2009-09-29- bsnes_v052_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=6042#p6042)
SPC dumping v0.052 here: [Win32 binary(http://kode54.foobar2000.org/bsnes_v052_spc_dump.zip)] [source patch(http://kode54.foobar2000.org/bsnes_v052_spc_dump.patch.gz)]

2009-09-27- bsnes_v051_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=5884#p5884)
SPC dumping version: [binary(http://kode54.foobar2000.org/bsnes_v051_spc_dump.zip)] [source patch(http://kode54.foobar2000.org/bsnes_v051_spc_dump.patch.gz)]

2009-08-26 - bsnes_v050_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=4611#p4611)
SPC dumping build, in the usual place.
Windows binary(http://kode54.foobar2000.org/bsnes_v050_spc_dump.exe)
Source patch(http://kode54.foobar2000.org/bsnes_v050_spc_dump.patch.gz)
Oh, and just for the hell of it, although I don't use it in the above binary or patch, modified serializer.hpp which uses float/IEEE conversion functions lifted from libbinio, modified to read/write little endian. The results seem to be binary compatible with what the existing float routines write for x86/x64, not sure what PPC/PPC64 uses. The original library is LGPL, but at least the native to IEEE (writing) conversion functions appear to have been lifted from somewhere else and just have some "include this notice/warranty" requirement. Eh, there's probably a cleaner way to do this, such as converting Cx4 to use all integer math.

2009-08-22 - bsnes_v049_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=4492#p4492)
Integrated SPC dumping capability, and also amended it with a 10 second timeout on new notes, saving to the data directory if configured, and stamping names with full date/time like the screen shot feature. (I still think it's better to use the source game name for the SPC dump, and maybe also for screen shots, heh.)
Windows binary(http://kode54.foobar2000.org/bsnes_v049_spc_dump.exe)
Source patch(http://kode54.foobar2000.org/bsnes_v049_spc_dump.patch.gz)

2009-08-20 - bsnes_v048_k54: (kode54, http://board.byuu.org/viewtopic.php?p=4412#p4412)
Added screen shot hotkey, same place as the other. Saves PNG. [Windows binary(http://kode54.foobar2000.org/bsnes_v048_k54.exe)] [source patch(http://kode54.foobar2000.org/bsnes_v048_k54.patch.gz)]
(Argh, I didn't notice that QImage had a RGB555 format. I could have used that. Oh well, whatever.)

2009-08-18 - bsnes_v048_spc_dump (kode54, http://board.byuu.org/viewtopic.php?p=4366#p4366)
I've implemented SPC dumping as a configurable User Interface hotkey. You can download a source code patch here(http://kode54.foobar2000.org/bsnes_v048_spc_dump.patch.gz). Some of it could probably have been done better, (like for instance, making it abortable or have a timeout) but it works. I've profiled and uploaded a Windows binary here(http://kode54.foobar2000.org/bsnes_v048_spc_dump.exe), now go dump those games that won't run in either ZSNES or Snes9X. (Or does SnesGT support dumping as well? Hmm...)
Probably not too useful now that most games that can be dumped are already dumped.

2007-07-01 - bsnes021n (Nach, bsnes_thread)
Hi, I'd appreciate if I could have some testing done on a special build for me.
http://nsrt.edgeemu.com/bsnes021n.zip
First off, caveats:
May not work in Windows 2000
Might be slower than bsnes 0.021
Does not have icon or joypad image appear inside bsnes.
Pros:
More encompassing DB system.
Please test to see if any games now give issues which didn't under 0.021 or see if anything which did load incorrectly under 0.021 is now fixed.
Other issues do not concern me.
Games to test:
90 Minutes - European Prime Goal
ABC Monday Night Football
Actraiser
Air Management
Battle Dodge Ball
Derby Stallion 96
Dezaemon
Equinox
Fire Emblem - Thracia 776
Gemfire
Killer Instinct
RPG Tsukuru 2
Sound Novel Tsukuru
Ys III - Wanderers from Ys (U & J)
Any of course any other games you feel like testing.
Please play into each game and if applicable get to a save point and save, then load from scratch and make sure save is working.
Please remark on issues where game works in one version but not the other. Post CRC32 of game when doing so.
If you tested one of the above games thoroughly and no problems were found, post about that too.
More details will be furnished once more test results are in.