- Major source code cleanup
- Completely rewrote memory mapper to support runtime MMCs
- Updated S-DD1 MMC to use new memory mapping interface
- Improved S-DD1 emulation, thanks to information from orwannon
- Added support for SameGame -- load via "Load Special -> Load BS-X Slotted Cart" menu option
- Completely rewrote cartridge loader to support BS-X, BS-X slotted carts and ST carts
- Created custom dialog windows for multicart loading
- Improved generic memory mapper, which eliminates the need for cart.db [Nach]
- Added BS-X slotted cart detection to generic memory mapper [Nach]
- Linux port will now ignore keypresses when window is inactive
- Linux port will use much less CPU power when idle
- Added detailed compilation instructions to Makefile for Linux port
- Added "make install" target and PNG program icon for Linux port
- Switched Windows compiler to MinGW/GCC4
- Windows executable is now packed with UPX to decrease filesize
- Removed .ufo, .gd7 and .078 ROM extensions; added .bs extension
- Added preliminary support for the BS-X base unit, BS-X base cartridge + MMC, and BS-X flash I/O
Ok, _please_ be courteous to my webhost and only download this WIP if
you're going to test it on a processor that hasn't been tested thus
far.
byuu.org/files/bsnes_v018_wip4.zip
byuu.org/files/bsnes_tests.zip
This has two separate builds. Neither have PGO, SSE, SSE2, ZIP or JMA
support. They are identical except for the FAVOR_ flag define and
title of the program.
FAVOR_ACCURACY [bsnes_accurate.exe]:
- Always tests OAM RTO flags even on skipped frames
- Tests NMI/IRQ trigger every clock cycle
FAVOR_SPEED [bsnes_fast.exe]:
- Only tests OAM RTO flags on rendered frames (always
with no frameskipping)
- Tests NMI/IRQ trigger using ranges
If you'd like to test, please run demo_mode3.smc on both versions of
bsnes, turn off speed regulation, and report the framerate both with a
frameskip of zero and a frameskip of nine (max), along with your
processor speed.
The other test ROMs are just to verify that IRQ behavior is still
reliable in both versions. A blue screen indicates passing, they all
pass on both versions. Don't expect test_* ROMs to pass on other
emulators, but demo_* ones should.
Example (my main PC):
AMD Athlon 3500+
Accurate:
- 121.5 fps w/o frameskipping
- 171 fps w/max frameskipping
Fast:
- 146.5 fps w/o frameskipping
- 271.5 fps w/max frameskipping
-----
As you can see, there are _major_ speed differences on my
A64. Personally, I'm all for accuracy, but I also want people to
actually be able to use this program in the interim. Perhaps in the
future when a low end computer is a current low-end Core 2 Duo, we can
remove all of the "speedhack" code. And in the meantime, the full 100%
precision is there for people who have the CPU power to afford it.
-----
If anyone wants to try and help, heh.
src/cpu/scpu/timing/irqtiming_accurate.cpp and
src/cpu/scpu/timing/irqtiming_fast.cpp are the two versions of the IRQ
testing code. If you see any ways to optimize either (preferrably the
former, obviously), I'd greatly appreciate it. Understand that both
the CPU counters (VCOUNTER, HCLOCK) and the IRQ timing positions
(VIRQPOS, HIRQPOS) can wrap not only the horizontal clock position
(1362->0), but the vertical position as well (261->0). And also that
they are "misaligned" by 10 clocks (which is really more of an
internal CPU IC delay thing, we aren't entirely sure why the
difference is there). You probably shouldn't mess with the code if you
don't understand the implications of this on eg range testing :/
I began working on bsnes on October 14th, 2004. I am releasing bsnes v0.018 today to celebrate bsnes' two year anniversary. Please note that this release incurs a ~15% speed reduction since v0.017, due to IRQ and S-SMP timing improvements.
Changelog:
- Fixed many critical errors in IRQ timing, should be *very* close to real hardware now
- Corrected major CPU timing bug involving CPU I/O condition 4
- Corrected bug with generic HiROM / LoROM memory maps
- Corrected bug involving HDMA indirect channel termination [anomie]
- OAM address reset now occurs when screen display is enabled, per recent research
- Readded full DMA, HDMA and HDMA init bus sync timing
- Added preliminary emulation of S-SMP $00f0 TEST register (6 of 8 bits are supported)
- Readded emulation of known timing differences between CPU revisions 1 and 2
- Config file can now control scanline-based PPU render position. This will only be needed until a proper dot-based PPU renderer is added
- Removed core debugging hooks so that debugging console can remain in public releases, it now functions as a tracer and memory editor
- Config file paths once again work correctly even if missing trailing backslash
- Video configuration simplified, sorry in advance to those who enjoyed the profile mode used before
- Added new configuration screen to control some emulation settings
- Replaced bsnes program icon with a much nicer one [FitzRoy]
- Optimized memory speed detection algorithm
- Preliminary UPS soft-patching support (do not use this yet!)
- Decreased memory usage and optimized generic libraries used by bsnes (/src/lib)
- Now caching OAM by one line, somewhat similar to a real SNES. Fixes Winter Gold, but causes line rendering error in Mega lo Mania
- Lots more, as usual
The following games have been fixed since v0.017 by the above bugfixes:
- Battle Blaze (J, U)
- Circuit USA (J)
- F1 Grand Prix (J)
- Funaki Masakatsu no Hybrid Wrestler - Tougi Denshou (J)
- Jumbo Ozaki no Hole in One (J)
- Mahjongg Taikai II (J)
- RPG Tsukuru - Super Dante (J)
- Robocop Versus The Terminator (U, E)
- Sink or Swim (U, E)
- Street Racer (J)
- Touge Densetsu Saisoku Battle (J)
- Winter Olympics (U, E)
Ok, this WIP rewrites the input code and modifies the PAL clock speed.
Fairly major changes. Ideally, this will wipe out four bugs without
causing any new ones since wip37.
Bug fixes :
Earthworm Jim 2 (E) - adjusted PAL CPU clock speed.
Please test for *new* sound problems in PAL games
La Wares (J) + Galivan 2 (J) - no longer return 0 when
auto joypad is off for polling $4218-$421f
Super Conflict (J) - added anomie's new OAM RTO findings
to fix title screen
The input code was almost completely rewritten to simulate real
hardware more. As such, it's very possible there are new input bugs.
Ok, so then
byuu.cinnamonpirate.com/files/bsnes_v016_wip38.zip
Please only download if you intend to test games and report feedback.
This version is slower than normal, lacks ZIP+JMA loading, and has the
debugger enabled (that is only useful to me, it lacks a functional
user interface) which slows down emulation even more. eg you're better
off with v0.016 official if you just want to run games.
As always, please don't post this link anywhere else, or
I will be forced to remove the file to conserve bandwidth.
If anyone posts bugs that hasn't tested against wip37, can I please
have someone with wip37 verify/deny the bug presence in wip37 as well
as in 016 official? wip37 isn't on my website because I don't have a
lot of web space to spare.
Thank you to everyone in advance for helping.
Ok, I tried converting the switch/case table to a jump table for both
CPU+APU cores. Results? EXE is 70kb larger, compile time is 5-10%
slower, and speed is identical. Needless to say I reverted that change
back. I then tried narrowing down the cause of the PGO error. Found
out it was Dai Kaijuu Monogatari. If I don't run that, I can build
with PGO. Unfortunately, this is the ROM I use to stress optimize
color add/sub. So as a result, this game will run a little slowly now
(sort of like how Chrono Trigger's OPT title screen effects were
before). But, better one game than all, right?
byuu.org/files/bsnes_v016_wip27a.zip
Once again, please do not submit news about this to an emulation
site. The file will be removed if I notice anyone mentioning it
anywhere.
That will be 20-25% faster than wip27, but otherwise
everything is identical.
DSP1: there's either a bug in op02, op06, or in the getSr/getDr/setDr
functions. We have so far been unable to spot the error and correct
it. Help is always welcome, as always. Please consider DSP-1 support
as not being there at all. I doubt any games will work right with it
right now :(
This is how interlace works :
I call each frame a "field", meaning even or odd fields
on your television / monitor.
When interlace is off, I draw to the even fields every
time, so you don't notice anything.
However, when interlace is on, I alternate between which one I draw
to each field. So depending on your frameskip, this can cause serious
problems for interlace mode. I also only physically draw to "half" the
resolution each field, much like a real TV would. This makes 512x448
mode just as fast as 512x224 mode.
I can't think of an easy way to cheat the system with frameskipping.
Luckily, very very few games use interlace at all. Most use hires
512x224 and that's it.
