bsnes v062 beta released - 模擬器

By Ethan
at 2010-03-14T20:24
at 2010-03-14T20:24
Table of Contents
http://byuu.org/
Major accuracy improvements have happened over the past few days. They easily
warrant a new beta release.
First, it turns out that every emulator to date; not only for the SNES, but
for the Apple II GS as well, incorrectly computed ADC (add) and SBC
(subtract) flags in BCD (binary-coded decimal) mode. At least fifteen years
of emulating the 65816 processor, at least five known investigations into
their behavior, and we all still had it wrong.
So I wrote some tests that dumped every possible combination of adc and sbc
with every possible input and every possible flag, and recorded both the
accumulator result and status flag register. From here, blargg figured out
the underlying trick: the CPU was computing overflow before the top-nibble's
BCD correction pass. With the routines rewritten, bsnes perfectly matches
real hardware now.
Next, some background. The whole reason I got into SNES emulation was because
I was tired of writing code that ran perfectly fine on emulators, but failed
miserably on real hardware. The number one problem was emulators allowing
video RAM to be written while the screen was being rendered. This single bug
has broken dozens of fan translations and ROM hacks. Some have been updated
to work around this bug, and many others are left in a permanently broken
state (such as the translations of Dragon Quest I & II and Sailor Moon:
Another Story, to name just two.) After asking emulator authors to fix this
since 1997, I finally had enough in 2004 and started on bsnes. For this
particular bug, I'm very happy to report that all but one SNES emulator now
properly blocks these invalid accesses. Although sadly one still offers a
configuration setting for backwards compatibility with these translations.
What an ironic shame ... emulating an emulator. And in the process, sapping
the motivation to ever go back and fix these titles to ever run on real
hardware. But I digress ...
The second biggest problem that causes software created under emulation to
break on real hardware has, without a doubt, been the hardware delays as the
S-CPU computes MUL (multiplication) and DIV (division) results. To date,
whenever you used this hardware functionality, emulators have immmediately
furnished the correct results. But on real hardware, multiplication requires
eight CPU cycles, and division requires sixteen. Each step computes one bit
of the source operand and updates the results. Reading the output registers
early thus provides the partially computed results.
This is obscure. It isn't well known, and many people writing software for
the SNES probably aren't even aware of this limitation. Because of the
partial computation results, outright delaying the computation would break
many commercial software titles. But by not emulating the delay at all, we
were causing a great disservice to anyone wishing to use an emulator for
development purposes.
Now, once again, thanks to blargg's algorithm help, he has determined the
underlying multiplication and division algorithms. Combined with my expertise
of SNES analysis and hardware testing, I was able to determine when and how
the ALU (arithmetic logic unit) stepped through each work cycle. Our work
combined, bsnes now also perfectly emulates the hardware MUL and DIV delays.
Again, this isn't going to fix commercial software titles. They would have
realized that they were reading back invalid MUL and DIV values, and fixed
their code. This is for all of the software developed using emulators. This
is an extension of my commitment to create a hardware emulator, and not a
video game emulator.
We also verified that the S-PPU multiplication interface does indeed return
instant results with no delay. So emulation of that interface was already
correct.
I'm only labelling this release a beta because it hasn't been tested. But I'm
fairly confident that it is stable, and I seriously recommend upgrading from
v060 or prior releases. This is easily one of the last major pieces missing
from emulation.
The last notable elements are: S-CPU auto joypad poll timing, S-CPUr1 HDMA
crash detection, S-CPU<>S-SMP port ORing, S-SMP timer glitching, S-DSP mute
pulse, and full cycle-level emulation of the S-PPU. With all of the
aforementioned items, I will consider a v1.0 release of bsnes ;)
Lastly, I'll post this screenshot just for fun. When d4s translated Breath of
Fire II to German, he added some code that relies on the incorrect emulation
of the DIV register to detect emulators. With this emulated properly, you now
see the following screen:
Sorry to spoil that, but the secret's already out, as the MESS team reported
on it publicly already.
I intend to add pseudo-randomness support shortly, which should eliminate one
of the last vectors possible to distinguish bsnes from real hardware :)
A million thanks to blargg for making this release possible.
--
Major accuracy improvements have happened over the past few days. They easily
warrant a new beta release.
First, it turns out that every emulator to date; not only for the SNES, but
for the Apple II GS as well, incorrectly computed ADC (add) and SBC
(subtract) flags in BCD (binary-coded decimal) mode. At least fifteen years
of emulating the 65816 processor, at least five known investigations into
their behavior, and we all still had it wrong.
So I wrote some tests that dumped every possible combination of adc and sbc
with every possible input and every possible flag, and recorded both the
accumulator result and status flag register. From here, blargg figured out
the underlying trick: the CPU was computing overflow before the top-nibble's
BCD correction pass. With the routines rewritten, bsnes perfectly matches
real hardware now.
Next, some background. The whole reason I got into SNES emulation was because
I was tired of writing code that ran perfectly fine on emulators, but failed
miserably on real hardware. The number one problem was emulators allowing
video RAM to be written while the screen was being rendered. This single bug
has broken dozens of fan translations and ROM hacks. Some have been updated
to work around this bug, and many others are left in a permanently broken
state (such as the translations of Dragon Quest I & II and Sailor Moon:
Another Story, to name just two.) After asking emulator authors to fix this
since 1997, I finally had enough in 2004 and started on bsnes. For this
particular bug, I'm very happy to report that all but one SNES emulator now
properly blocks these invalid accesses. Although sadly one still offers a
configuration setting for backwards compatibility with these translations.
What an ironic shame ... emulating an emulator. And in the process, sapping
the motivation to ever go back and fix these titles to ever run on real
hardware. But I digress ...
The second biggest problem that causes software created under emulation to
break on real hardware has, without a doubt, been the hardware delays as the
S-CPU computes MUL (multiplication) and DIV (division) results. To date,
whenever you used this hardware functionality, emulators have immmediately
furnished the correct results. But on real hardware, multiplication requires
eight CPU cycles, and division requires sixteen. Each step computes one bit
of the source operand and updates the results. Reading the output registers
early thus provides the partially computed results.
This is obscure. It isn't well known, and many people writing software for
the SNES probably aren't even aware of this limitation. Because of the
partial computation results, outright delaying the computation would break
many commercial software titles. But by not emulating the delay at all, we
were causing a great disservice to anyone wishing to use an emulator for
development purposes.
Now, once again, thanks to blargg's algorithm help, he has determined the
underlying multiplication and division algorithms. Combined with my expertise
of SNES analysis and hardware testing, I was able to determine when and how
the ALU (arithmetic logic unit) stepped through each work cycle. Our work
combined, bsnes now also perfectly emulates the hardware MUL and DIV delays.
Again, this isn't going to fix commercial software titles. They would have
realized that they were reading back invalid MUL and DIV values, and fixed
their code. This is for all of the software developed using emulators. This
is an extension of my commitment to create a hardware emulator, and not a
video game emulator.
We also verified that the S-PPU multiplication interface does indeed return
instant results with no delay. So emulation of that interface was already
correct.
I'm only labelling this release a beta because it hasn't been tested. But I'm
fairly confident that it is stable, and I seriously recommend upgrading from
v060 or prior releases. This is easily one of the last major pieces missing
from emulation.
The last notable elements are: S-CPU auto joypad poll timing, S-CPUr1 HDMA
crash detection, S-CPU<>S-SMP port ORing, S-SMP timer glitching, S-DSP mute
pulse, and full cycle-level emulation of the S-PPU. With all of the
aforementioned items, I will consider a v1.0 release of bsnes ;)
Lastly, I'll post this screenshot just for fun. When d4s translated Breath of
Fire II to German, he added some code that relies on the incorrect emulation
of the DIV register to detect emulators. With this emulated properly, you now
see the following screen:
Sorry to spoil that, but the secret's already out, as the MESS team reported
on it publicly already.
I intend to add pseudo-randomness support shortly, which should eliminate one
of the last vectors possible to distinguish bsnes from real hardware :)
A million thanks to blargg for making this release possible.
--
Tags:
模擬器
All Comments
Related Posts
Mame Plus Multi J.E.T v0.137

By Adele
at 2010-03-14T20:21
at 2010-03-14T20:21
Dolphin SVN r5194

By Bethany
at 2010-03-14T15:54
at 2010-03-14T15:54
三國戰記一代的版本

By Irma
at 2010-03-14T14:11
at 2010-03-14T14:11
剛破的FC GAME--明星之路

By Dora
at 2010-03-14T12:27
at 2010-03-14T12:27
(ROM application) GameDB v0.069

By David
at 2010-03-14T11:21
at 2010-03-14T11:21