Update to bsnes v037r01? release.

New WIP.

For Linux users, this adds a PulseAudio driver, using
<pulse/simple.h>. Debian / Ubuntu users will need to add libpulse-dev,
or remove "audio.pulseaudio" from the ruby= line in the Makefile to
compile now.

I wasn't able to test the driver at all -- I get "Connection refused"
when I call pa_simple_new(). It appears that despite having Xubuntu
8.04, it doesn't come with PulseAudio installed. Guess they lied about
it on their website or something ...
I could install the packages, but hearing horror stories from others
-- I'd rather not.

If anyone can test for me, that'd be great. Check the console for
error messages.

Next, I finally got around to re-doing the S-DD1 driver to eliminate
the need to hook DMA transfers inside the S-CPU core to recognize
decompression events. That violated my strict feelings regarding
separation of cores and avoiding enslavement, even when it adds
significant overhead.

I'm now going with a radically different approach, that's hopefully
much more like the real hardware. It explains the way $4800 / $4801
behave, as well as why fixed transfers are required, but it may not be
faithful.

What I do is have the S-DD1 chip spy on $43x2-$43x6, and cache the
values internally. Then, whenever you read from $c0-ff:0000-ffff, it
will test if $4800 & $4801 != 0. If that's the case, we look at the
address requested, if it matches one of the active S-DD1 channels (eg
$4800 & $4801 & (1 << channel#) != 0), then we hijack the read with
decompressed data.

In my implementation, I decompress the entire block on the first read,
then stream from the buffer. On real hardware, it most likely starts
streaming on $4801.dN enable, but that's not too feasible for a few
reasons for me. Most notably the S-DD1 lib requires a size parameter.
It doesn't really matter, since we know the size from $43x5,6; so it
doesn't suffer the same problems the SPC7110 did.

Anyway, once all the data is transferred, it will clear the channel
bit from $4801. There may be some hardware differences here -- can you
perform two transfers at the same time? What happens if HDMA
terminates the DMA channel? These things never happen in Star Ocean or
SFA2, so they'll have to be tested manually.

If no channels are active or there are no address fetch matches, it
invokes the MMC to return raw ROM data.

All of that gives a ~1.5% speedup both to regular games and S-DD1
games. The former because DMA transfers don't have to test for the
S-DD1 during every transfer; the latter because I'm using a quick
lookup table (slower per fetch) in place of re-mapping the whole banks
on writes to the MMC (very slow per write.) The latter was much
cleaner and simpler, but I need the former to hook the decompression
stuff natively.

Windows binary is included, I'd appreciate if anyone could play some
Star Ocean / SFA2 and look for regressions from v037a.

> I'm just so used to seeing everyone having a "Close" button in their
> configuration dialogs I figured bsnes would have one. It just now
> that I looked around that I realised that only some of the
> configuration "panels" actually have buttons.


Ah, I see what you mean. Sorry. I can add one if you want, I suppose.

[No archive available]
This commit is contained in:
byuu
2008-10-31 11:05:00 +00:00
parent 9b03874f32
commit 7236499e2f
Update to bsnes v037r01? release.

Diff Content Not Available
