byuu

Super Game Boy BIOS' header is marked as US, and the identical BIOS image is used in both the US and EU releases of the hardware. It will require a custom XML memory map that marks the BIOS as region PAL to override the internal header. It's an unfortunate case, the one example of a game violating the region-byte guideline required by all games.

If you mean for maximizing the window, probably not but we'll see. I would like to add fancy resizing that auto-snaps window sizing, but that's not easy to do on some OSes. Absolutely. Necessity is a powerful motivator, but it's always been my goal to achieve as perfect an emulation as possible. Hence why I just built my own RGB cables with zero soldering experience, so that I could better achieve this goal. No games need any more precision than I have, but I'll keep going anyway. My favorites are the intro to Battle Blaze and the sound effects from Earthworm Jim 2. Both require much more demanding emulation to do properly. You can also watch the Zelda 3 triforce spinning on the intro. In ZSNES, they stop spinning way sooner because the CPU is running ~40% faster than real hardware. But this does raise an interesting point. Most popular games seem to run okay in ZSNES and Snes9X because they rely on game-specific hacks. So when you load, say, Chrono Trigger, ZSNES will read the game name, see it's CT, and subsequently adjust the APU timing, modify the game code a little bit to work around a freezing bug, and so on. To you, the end user, the game appears to run in both emulators. But with ZSNES, it's been hacked around with to do so. It's cheating, and it's done behind your back. Now, most people probably won't care, sadly. But the problem with hacking around bugs on a case-by-case basis, is that the underlying problems do not get fixed. So when you go to play an unpopular game like Speedy Gonzales, you'll find that the game deadlocks in ZSNES on stage 6-1, making it unbeatable. You could lose 3 hours of gameplay to get there, to find the game deadlocks on the very last level. All because it's an obscure game that doesn't have hacks for it yet. So that's why it is important to always do everything right: you can't possibly know what every game does at every point ever. And anything you do wrong, no matter how small, has at least some potential to cause problems, up to and including making the game unbeatable.

For the SNES? Although synchronization is done at the lowest level, my PPU is not perfected. I don't always cache register settings at the exact correct cycle. There are literally zero games that rely on that: only Air Strike Patrol writes to the registers during screen rendering; but I'd like it to be perfect anyway. Moving on, the BS-X could use some love, but we are very limited there since the real Satellaview network is dead and gone, and most software for it has been lost or corrupted. Then there's a few obscure controllers: Miracle Piano, Exertainment Bike, Pachinko, Twin-Tap, etc. Outside of that, honestly I don't have any plans to write another emulator. This one took too many years from my life. I'm obsessed with preserving the games too (all of them, not just the ROMs), and have already spent over $10,000 buying them up, scanning and redumping them all. And that's only for the USA set. Still have all of Japan and Europe to go, without the benefit of flea markets to pick up cheap games from. I can't afford the time or money to give even 10% of the dedication to another platform. I don't really even have enough money for the other SNES games. The worst part is I have no desire to keep them. I just want to borrow, scan, dump, and return them. But given that I've only attracted 1-3% of the SNES emulation crowd, I've only really had a dozen games, and three dozen boxes/manuals donated. Getting the remaining ~2,100 foreign games will be nearly impossible at this rate. Would you believe me if I told you I don't really play games at all? Maybe one or two a year :/ That said, Sega Saturn is my all-time favorite system. Specifically for the Japanese games, the US missed out on most of them. But given my degree of perfectionism, and lack of trig/calculus math skills, I could never pull off a Saturn emulator. Add to that my zealotry with open source in the emulation field, and I'd have to say my favorite project to watch is Yabause. The SNES was a very complicated system due to the number of processors it used, and the Saturn just raises that bar by an order of magnitude. It is a marvel of a system. I like the challenge of such complexity more than simplistic designs like the NES and PS1. I am hopeful for a really good PSP emulator one day as well. That's a dream system for 2D JRPGs.

It will also halve on the MMX3 level select, but neither are really critical for playing at least. I now use GCC 4.5 for C++0x/lambda support. Unfortunately, OpenMP support is broken in the new releases. That means I can't multi-thread HQ2x anymore. Once it's fixed in the compiler, I will add this back. Why not? The SNES is more than one CPU. Also, bsnes only uses one core. It can't actually use more than one due to the overhead caused by user->kernel transitions. That only works on low-synchronization parallel processes, like video encoding or modern console emulation. I can promise you however, the code is as optimized as it can possibly be. The #1 determination of emulator performance is not the primary CPU processor speed, but rather how many times you synchronize components to each other. Compare ZSNES to bsnes: Synchronization primitives per second of emulation: S-CPU: 600,000 vs 21,477,272 (note: 3.58MHz is a measure of cycles; ZSNES syncs opcodes, bsnes syncs bus hold delays) S-SMP: 256,000 vs 24,576,000 S-DSP: 32,000 vs 24,576,000 S-PPU: 15,720 vs 21,477,272 Total: 903,720 vs 92,106,544 bsnes is literally, honest to god and no exaggerations, over 100x more precise. It cannot possibly be any more precise, period. That it is less than 10x slower despite being 100x more precise and in a higher-level language is a testament to the optimization work I have done. Please note that not even PCSX2 and Dolphin synchronize anywhere near as much as bsnes does. Does it matter? Not for newer consoles. But for the SNES? Yes, if you want 100% compatibility with zero bugs and zero hacks. Nothing less will do without breaking at least a half-dozen obscure games. You may not care about those games, and that's fine, you don't have to. Snes9X v1.53 is a great choice in that case, I highly recommend it. How many people keep FLACs instead of MP3s? JPEG photos instead of PNGs? DVDs instead of raw video? bsnes is basically the same thing. There's perfect, and there's close enough but efficient. I don't care or judge which you prefer, but please don't consider my software "less-than" just because perfection has monstrous requirements =) I'm interested in preserving the SNES long after it's gone, not in playing games today, although the latter is still quite practical on high-end CPUs. Nesticle ran at full speed on a 25MHz 486, back when the P166 was king. Nestopia is now the #1 emulator, and it requires 800MHz. Nintendulator is more accurate, and requires 1.6GHz, but suffers popularity issues because it is so highly Windows-dependent and less polished. Imagine if either were released back when a P166 was king? If you think bsnes takes flack now, oh boy. It's a common pattern. When your PC is fast enough for 60fps bsnes play, it's magical. Everything always, always just works. But when the framerate dips below 60fps even once, most people go on tirades on forums. Not saying you were, mind. Most people do though. They will say the emulator is too slow. But software has no intrinsic speed. Back when P166 was king, we never imagined a day when everyone could easily run Nestopia at 800MHz. The same will hold true for bsnes' requirements, eventually. True. This is a side effect of locking the window scale multiplier. I found more people were upset with trying to resize the window to perfect multiples by hand, than by not being able to run in maximized mode. The latter usually run fullscreen (hides taskbar) instead. But if you prefer maximized mode, v070 is better for that. Please see above. We may not think it needs those system requirements, but it does. If you cut anything out of bsnes, you will start breaking games. That doesn't even get into the debate of whether or not to emulate behaviors that commercial software never used. I believe that if you rewrote the code in pure non-portable x86 ASM, and sacrificed all source code readability (and thus maintainability), you may be able to eke out another 50% performance with identical accuracy. But you must also realize that the code clarity is a large part of how I managed to reach 100% compatibility in only seven years. Give someone an unreadable mess of black magic to improve and maintain, and you'd need someone with twice the IQ and five times as much time on their hands to make it all work as well.