+- EmuNewz Network (https://www.emunewz.net/forum)
+-- Forum: Emunewz General Forum (https://www.emunewz.net/forum/forumdisplay.php?fid=75)
+--- Forum: Interviews (https://www.emunewz.net/forum/forumdisplay.php?fid=105)
+--- Thread: byuu, the author of bsnes (/showthread.php?tid=830)
byuu, the author of bsnes - nickblame - 04-03-2010
Hi byuu! this is emunewz.net. I'd like to congratulate you for your continuous efforts to write a really... i mean REALLY complete emulator for the snes.
I’ve been following your posts on your site for quite some time now and i have to admit that there are no other projects in the emulation scene like bsnes. both the percentages of compatibility and the lack of any hacks on the code are quite a piece of work.
Here are some questions that you could answer for us in order get some extra info about you and your project.
So here goes.
How old are you, and are you working as a programmer in real life? Studies?
26, and no. Self-taught.
When did you start working on bsnes?
October 14th, 2004.
Was that the first project of yours in terms of writing an emulator?
The first emulator I tried to write was StarSNES in 2000 or so, which ran about ten demos. I also wrote a Genesis emulator a few years later, again only running a handful of demos. But this was mostly having fun, and I was more interested in the CPU cores for ROM hacking purposes.
bsnes was the first really serious attempt at writing an emulator.
Can you give us a percentage of completion on the bsnes project?
There are things about the hardware that we don't even know about yet, so unfortunately I can't really say.
Compatibility-wise, we're in good shape at least. Right now, there are only three unplayable titles, and all three require their program ROMs to be dumped first. As for everything else, I'm not presently aware of even a single bug in any commercially-released game.
I mean I thought it was complete for like a year now and releases just keep coming (which is awesome btw)
Most of the recent releases have been about adding user interface features. Things like save states, rewind, movie recording, pixel shaders, 7-zip multi-archive parsing, etc.
The core changes I have planned will require me to have a vast amount of free time to dedicate solely to the emulator. I hope to start on those sometime in mid-2010.
If someone compares your work with other good emulators for snes the only thing that bsnes lacks is speed. Is there any chance that bsnes gets a polishing in terms of speed?
I've been working on it, with the help of Exophase and Cydrak. It's gotten a few 3-10% speedups here and there. But ultimately you have to consider that this emulator really does run at up to 32x the precision of other emulators. I don't believe it is possible to get bsnes more than twice as fast as it is now without sacrificing at least some accuracy.
bsnes synchronizes the S-CPU at effectively 10.74MHz, the S-SMP at 2.048MHz, and the S-DSP at 1.024MHz. All other emulators run the S-CPU at ~900KHz, the S-SMP at ~256KHz, and the S-DSP at 32KHz.
Note that synchronization and clock speeds are very different. This is a measure of the smallest unit of time allowed to pass before a processor will see a change made by another processor. bsnes uses the smallest possible timeslices for synchronization such that any additional precision would be completely unobservable to the software.
Ignoring all emulation overhead, modern computers are only capable of up to ~20MHz worth of synchronization between two threads, and even that requires a highly optimized cooperative threading model. Emulators for newer and faster systems avoid this by synchronizing components even less frequently. Quite honestly, it isn't needed for newer systems with games written in high level languages like it was in the old days with hand-written, fully-optimized assembler code.
The thing to understand is that emulation overhead is not based on the MHz rating of a processor, but how frequently the emulator has to switch from emulating one chip to another. On modern processors with 12-stage pipelines and tiny L1 caches, context switching absolutely destroys performance. This is why a Saturn emulator with its 10 slow chips is much more demanding than a Dreamcast emulator with its 2 fast chips.
Some refer to this as the difference between opcode-based and cycle-based emulators, but bsnes further emulates the bus hold delays during memory accesses between opcode cycles.
This is relevant to the previous question a bit. Is it possible for bsnes to port on other consoles? Of course ones that have the needed horsepower.
Yes, I believe the PS3 with Linux is more than capable of attaining full speed with bsnes. It should not even need porting, as the source is already fully portable.
For other platforms, I would strongly recommend Snes9X for now.
Well I do believe that the next question is one that pops on every mind that came across bsnes. Do you consider working on another platform by the time bsnes is 101% complete? Or even do you work on any other project currently?
I don't plan on working on an emulator for another system, but I do hope to find a group willing to work on a speed-focused and accuracy-oriented emulator one day. Just enough accuracy for full library compatibility, nothing extra.
I am working on different projects simultaneously: I'm about to begin work on translating Far East of Eden Zero to English with the help of Tomato, I've been developing a multi-target cross assembler for a while now, and I'm also developing something like a competitor to SDL for cross-platform audio/video abstraction.
How is your involvement in emulation programming working out for you as an experience? Is it worth it as a sport considering that there’s a real huge ammount of work needed to get results. Are you becoming a smarter programmer by reverse engineering consoles?
The SNES scene itself is great. Everyone is really nice, and very helpful. We all share our source code, so we all work together for one end goal; there's no pressure or competition involved.
It is fun to see the results of emulation, but that fades as compatibility continues to increase. At this point, the things left to emulate will only slow the emulator further without providing any visible benefits to gamers. It's very hard to explain to the casual gamer why preservation matters when they can't even see the difference.
I've learned quite a few new tricks while working on the emulator, but much of it is only useful for writing more emulators.
Do you thing that bsnes is overrated/underestimated?
A little bit of both.
I am disappointed that so few people know it exist. And that of the people who have the required processing power to use it, so few actually do. In the early days, I lacked a lot of common features; but these days I have them all and many original features, like Super Game Boy emulation, Xbox 360 controller support, 7-zip support, multi-archive support, UPS patching support, a full-fledged debugger, pixel shaders, etc.
But it's also not the be-all/end-all of accuracy. I still have a lot of work left to do to reach my ultimate goal.
The biggest issue right now is that the S-PPU video renderer is something of a hybrid between a scanline and cycle-based renderer. I want it to be fully cycle-based, but this will take years of effort and will no doubt require a massive performance hit. It's not just a matter of synchronizing after every pixel write, I could do that in ten minutes. The real challenge is reverse engineering how the two SNES PPUs accessed memory during each cycle. That will take months, maybe even years, of non-stop work. I intend to continue offering the current renderer for gamers, and the cycle-based renderer for preservationists.
Are you happy with the anticipation of people on your project?
I think the biggest problem is that people seek to constantly compare bsnes to ZSNES et al. They are completely different projects. bsnes aims to document every last piece of the SNES hardware, speed be damned, so that the information will be around for the future. Once the last SNES console dies, like the Game & Watch devices already have, what we have reverse engineered will be all that is left. I want to get as much info as we can, while we still can. ZSNES et al aim to emulate the minimum amount necessary to play the most popular games with the lowest system requirements obtainable. In my opinion, they are both very useful goals. Not all of us have fast computers.
Also, my goal is not to get everyone using bsnes. I honest to God do not care about popularity. I simply want to see the SNES scene as a whole continue to improve. I feel it has stagnated substantially: the last official SNES emulator released, other than bsnes, was SNESGT on May of 2007. Two and a half years ago. You can verify my sincerity by looking at the changelogs to ZSNES, Snes9X, SNEeSe, SNESGT and MESS. You'll find my contributions in all of them.
It bothers me that the SNES scene is stuck with ancient copier headers, dozens of ROM file extensions, voodoo magic memory mapping, a woefully inadequate soft-patching system with a 50% failure rate, ROM hacks that were designed in one specific emulator that won't run in any others, and bug reports that have been open for over a decade now.
I will lend my full support, time, knowledge and skill to any emulator author who seeks to better this situation and is also willing to share their research with the public.
Thank you for your time byuu! I hope we stay in touch and spam about bsnes more to the public
Visit byuu’s site for his blog. News posts and ofcourse downloads at http://byuu.org/