mirror of https://github.com/bsnes-emu/bsnes.git
e370a35d7d
New WIP. The biggest news is that I've implemented what I was discussing earlier, and it worked perfectly. The S-PPU enslavement to the S-CPU is no more. As of this point, all four processor cores, and all three of their shared relationships, run completely independently of one another. This required moving the inline timing code from the absolute most timing-sensitive section of the emulator, to an entirely new external class. It also required logging more state data, adding ~100k/second more context switches, etc. It was unavoidable that the new approach would be slower, but I was able to greatly mitigate the speed loss. Right now, it stands at a ~6-8% speed loss from the previous release. But there is good news: 1) aside from SuperFX / SA-1 support, which will require additional processing inside the emulator core, no other changes should slow down the emulator again. It can only get faster from here. Most importantly, a range-based IRQ tester would offer a major speedup. 2) this approach will allow both a scanline-based and cycle-based S-PPU core to work with only one S-CPU core. No need to subclass and duplicate the timing code + scheduler as I was planning to before. 3) with this change, I was finally able to convert the scanline-based S-PPU renderer to a hybrid that I've talked about with FitzRoy in the past: this allowed me to finally cache OBSEL writes at (roughly) the appropriate position, while still rendering the screen at a different point. I render the screen at H=512, and cache OBSEL at H=1152. May not be hardware accurate, but it allows Adv. of Dr. Franken + Winter Olympics + Mega Lo Mania to all work as expected, all at the same time. It wasn't 100% exactly how I wanted to do things ... but I'm really happy about this de-coupling. I've always been a purist when it comes to implementing processor cores independently of one another, and it's always bothered me greatly the way the CPU controlled the PPU and its counters. With the above changes, I've eliminated the four ppu.hack config settings. I don't see much of a need for them. I've also embedded the readme and license text files. FitzRoy, I haven't had a chance to revise the readme as you were suggesting yet. Not ignoring you there, it's just low on my priority list right now. Lastly, I took FitzRoy's advice, and removed the WAV logger entirely. I'm also going to leave the screenshot capture out. At least for now ... the UI is starting to get a bit too bloated for my tastes. This is also the first uploaded WIP with the new debugging key- bindings (tracing and memory export.) I don't expect anyone here to have much use for them. Anyway, testing would be appreciated. It's very likely that the OBSEL cache position needs to be tweaked further. I recall LotR or something also had issues with caching in the past ... but I couldn't find the game at ::ahem:: the used game shop ... to test it. I think there were other games that had different behavior based on the old obsel_cache setting, too. Would be good to make sure they all work as expected. EDIT: Ah, "JRR Tolkein's LotR", bah. Yeah, no sprite flickering with the new WIP. Also, speed hit only seems to affect Core 2's. No frame drop on my Athlon. Probably something to do with locality of reference or somesuch. Modern processors are too damned complicated :P So then, assuming nobody spots any bugs ... how about a new release tomorrow? [No archive available] |
||
|---|---|---|
| src | ||
| license.txt | ||
| readme.txt | ||
readme.txt
bsnes Version: 0.037a Author: byuu ======== General: ======== bsnes is a Super Nintendo / Super Famicom emulator that began on October 14th, 2004. The latest version can be downloaded from: http://byuu.org/ Please see license.txt for important licensing information. ============== Configuration: ============== bsnes has two configuration files: bsnes.cfg, for program settings; and locale.cfg, for localization. For each file, bsnes will start by looking inside the same folder where the bsnes executable is located. If said file is not found, it will then check your user profile folder. On Windows, this is located at "%APPDATA%/.bsnes". On all other operating systems, this is located at "~/.bsnes". If said file is still not found, it will automatically be created in your user profile folder. If you wish to use bsnes in single-user mode, be sure that both files exist inside the same folder as the bsnes executable. If they do not, you can simply create new blank files and bsnes will use them in the future. If you wish to use bsnes in multi-user mode, simply delete these two files from the bsnes executable directory if they exist. If you wish to have multiple configuration profiles for the same user, you will need to make copies of the bsnes executable, and use each one in single-user mode. ==================== Known Limitation(s): ==================== S-CPU - Multiply / divide register delays not implemented - "Glitch" when reading joypad registers during auto polling not implemented S-PPU - Uses scanline-based renderer. This is very inaccurate, but few (if any) games rely on mid-scanline writes to function correctly - Does not support FirstSprite+Y priority - OAM / CGRAM accesses during active display not supported correctly - RTO flags are not calculated on frames that are skipped when frameskipping is enabled. This provides a major speedup, however it will cause in issues in games that test these flags, eg the SNES Test Program Electronics Test. Turning frameskipping off will allow RTO flag calculation on every frame Hardware Bugs - S-CPU.r1 HDMA crashing bug not emulated - S-CPU<>S-SMP communication bus conflicts not emulated =============== Known Issue(s): =============== On Windows, attempting to load a ZIP, GZ or JMA compressed archive with non-ANSI characters in the filename will fail. This is because Windows requires UTF-16 encoding, but these libraries only work with UTF-8. Note that loading uncompressed images (SMC, SFC, etc) with non-ANSI characters works properly on all platforms. ===================== Unsupported Hardware: ===================== SA-1 Coprocessor used in many popular games, including: - Dragon Ball Z Hyper Dimension - Kirby Super Star - Kirby's Dreamland 3 - Marvelous - SD Gundam G-NEXT - Super Mario RPG Super FX Coprocessor used in many popular games, including: - Doom - Star Fox - Star Fox 2 (unreleased beta) - Super Mario World 2: Yoshi's Island ST-011 SETA DSP used by Quick-move Shogi Match with Nidan Rank-holder Morita ST-018 SETA RISC CPU used by Quick-move Shogi Match with Nidan Rank-holder Morita 2 Super Gameboy Cartridge passthrough used for playing Gameboy games ============= Contributors: ============= Andreas Naive, anomie, blargg, DMV27, FitzRoy, GIGO, Jonas Quinn, kode54, krom, Matthew Callis, mudlord, Nach, neviksti, Overload, RedDwarf, Richard Bannister, tetsuo55, TRAC, zones