mirror of https://github.com/bsnes-emu/bsnes.git
bccc5b5a12
I wish I could post the new WIP, I really need it tested. But it looks like vstech.net (cinnamonpirate.com's host) got sucked into a black hole, literally. You can't even nslookup it. So ... sorry. What I did today was: - remove an unnecessary ternary condition in HDMA CPUsync (no visible effect on emulation or speed.) - move controller ports from settings to system. - rewrite SPC7110 decompression engine from scratch. The last one obviously the most important. I took neviksti's most recent decompressor code, made the essential variables static, added a bool init parameter you can use to start a new decompression sequence, and built up a dual-indexed (read+write cursor) ring buffer to stream byte sequences. I set the buffer to >= 32 bytes at a time. I also simplified a few parts, like the swap sequence for pixel ordering; and I took out the end of each function that computes length, since that's no longer needed (nor is bot.) The result is you can stream an infinite number of bytes safely from decompression, and nothing will ever go out of bounds of the data ROM. Speed results on Core 2 Duo E6600 @ stock 2.4GHz: FEoEZ cart riding sequence - 91fps (was 40fps) MDH title screen - 111fps (was 29fps) SPL4 title screen with players running across screen - 118fps (was 35fps) For comparison, Star Ocean in-game gets ~95fps. I didn't think we would need that many optimizations to get SPC7110 support running at full speed (how complex could a low-cost IC from 1995 be?), good to see I was right. As soon as vstech comes back (hopefully tomorrow), I'll post the PD / BSDL source, and get it sent over to GIGO. Hopefully he can add it to SNESGT. Speaking of which ... neviksti: In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15, but it should be 30. I'm guessing it runs fine in isolation (memory initializes to zero and all that), but when mode 2 ran and set contexts up to 32; only clearing 15 was resulting in corrupted graphics all over. No big deal, just mentioning it. > I don't really understand your (or byuu's) point. If the game does > indeed works on 99.9% of units...on what do you base yourself to say > their programming suck or that the game is "broken"? I mean, it > works, it works right? This is the problem I have with the black-and-white "bug" label ... it implies a game is broken to a casual observer, or there is at least noticeable corruption on at least one screen. In truth, bsnes has a few visible bugs. Street Racer will flicker one frame on the title screen, but only one time, and only once every ~4-8 runs. Adventures of Dr Franken and Winter Olympics show one black scanline because the games update OBSEL at very unusual points mid- frame. And there are countless "anti-bugs", eg Battle Blaze on the fighter select screen is supposed to show some garble up at the top due to mid-scanline PPU writes. Because bsnes renders an entire scanline at once, you don't see this. Lots and lots of games will have 1-16 pixels on one scanline at the left (usually not even visible on TVs) that flicker due to writing PPU regs past the end of hblank. BoF2 German detects emulators by reading the division register early. Since no emulator supports that, you don't see the anti-piracy splash screen. All of those could be considered bugs to varying degrees. I suppose what would be nice is a bug severity ranking system. "Severe" if it's game ruining, "Moderate" if it's more than one scanline / frame that glitches graphics or something, and "Minor" for the stuff 95% of people probably won't even notice. Or something like that. My point is that it doesn't make a lot of sense to work on the minor stuff. Most of that will probably go away with a cycle-based PPU anyway, and the rest will probably continually appear and disappear with infinitesimal timing changes. [No archive available] |
||
|---|---|---|
| src | ||
| license.txt | ||
| readme.txt | ||
readme.txt
bsnes Version: 0.033 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 Limitations: ================== S-CPU - Multiply / divide register delays 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 ===================== 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 ======================== Unsupported Controllers: ======================== Mouse Super Scope Justifier Multitap (4-port and 5-port)