Hi all, thank you for sharing this article here! It is technically a "laymen's" version of <a href="https://byuu.org/articles/edge-of-emulation" rel="nofollow">https://byuu.org/articles/edge-of-emulation</a> (submitted here earlier), meant for a wider audience, but it does elaborate on some new discoveries such as the digital video output testing mode.<p>In the off chance anyone is able to help with this, I've set up a Discord channel (#ars) for coordination here: <a href="https://discord.gg/Fx7TfKh" rel="nofollow">https://discord.gg/Fx7TfKh</a><p>Every member of the bsnes-emu project is on said server.<p>Thanks so much!
Interesting tangent from the article:<p>>Today, SNES emulation is in a very good place. Barring unusual peripherals that are resistant to emulation (such as a light-sensor based golf club, an exercise bike, or a dial-up modem used to place real-money bets on live horse races in Japan), every officially licensed SNES title is fully playable<p>I had to look up the 'dial-up modem' reference - apparently it's a Japan-only peripheral called the "Famicom Network System" that did in fact have software available that allowed for bets to be placed on live horse races.<p><a href="https://en.wikipedia.org/wiki/Family_Computer_Network_System" rel="nofollow">https://en.wikipedia.org/wiki/Family_Computer_Network_System</a><p><a href="http://niwanetwork.org/wiki/JRA-PAT" rel="nofollow">http://niwanetwork.org/wiki/JRA-PAT</a>
The linked story about Higan's NEC uPD772x emulation being used by Stephen Hawking is pretty amazing, both as a story in its own right and as a parable about the value of open source and code getting used in wildly different contexts from what it was originally designed for: <a href="https://www.sfchronicle.com/bayarea/article/The-Silicon-Valley-quest-to-preserve-Stephen-12759775.php" rel="nofollow">https://www.sfchronicle.com/bayarea/article/The-Silicon-Vall...</a>
It's sad that Nintendo doesn't seem to see this as an opportunity to earn free press and goodwill by simply releasing all the design documents, mask images, etc.<p>The community is going to get there eventually without their help, but they could probably make it much faster and cheaper to get there.<p>Doubly so because they sell products which almost certainly benefit from these open source emulation efforts.
<i>And so the final, most extreme approach, would be to expand upon our decapping efforts. We have 20x die scans, but the resolution is not enough to make out and reconstruct individual logic circuits from them, such as was done with the Visual 6502 project.</i><p>That was done with the NES too:<p><a href="https://github.com/SourMesen/VisualNes" rel="nofollow">https://github.com/SourMesen/VisualNes</a>
If you found this interesting, the author's website has a number of informative, in-depth articles about emulator development & console architectures: <a href="https://byuu.net/" rel="nofollow">https://byuu.net/</a>
I just want to say that some of the most fun I’ve ever had on the PC has been in a SNES emulator. The sheer variety, depth, hours of content, ease of accessibility, and great music has been nearly unmatched on most other platforms.<p>I highly recommend anyone with an interest in games to grab a bunch of ROM packs (including Japanese exclusive games and fan translation hacks) and spend some of your quarantine on the SNES.
On the last extreme idea, it seems one thing to do for starters is to get the 100x magnification of the PPUs from someone and put it in the GitHub repo.<p>Then anyone who has the ability to start converting that to VHDL or any sort of identification of components can start on part of it and contribute to the repo.<p>With some started, it may be possible for less expert people who have a little bit of VHDL or whatever to contribute to some degree with expert supervision.
Is there any SNES emulator that runs on arm?<p>I've got retroarch v1.3.6 on Stretch on aarch64. It has crashed with a "file not found" and "bus error" for bsnes. Higan segfaults when I try to run it.
Error in the article: 32x32bit multiply (i.e. 2^64 bits) is not a "heat death of the universe" thing.<p>It's a lot, yes. Not practical for these purposes. But there's a reason we don't use 64bit encryption.<p>64bit encryption is easily brute forced.<p>If you want to keep it in a table, sure that's 18 exabytes (multiplied by element size in bytes), but that's <i>before</i> compression. I imagine multiply output compresses <i>very</i> well. And that's a lot of RAM. But not anywhere near "heat death of the universe" amounts.<p>I bet FAANG easily have that much RAM. Each of them.
Has Nintendo released officially, or leaked, the RTL for any of the processors in the SNES? If someone could get their hands on that, then the emulation authors should be able to achieve perfection.
I'm sure that I was playing Zelda Link to the Past and Super Metroid without any problems about 20 years ago. What's changed since then? I thought this was already solved :) apologies for my ignorance
Nintendo Switch Online subscription includes an "official" SNES emulator. How does it compare to BSNES, and would a decompilation of the emulator help with resolving the PPU issues?
It is interesting to me how some systems are easier to emulate than others, and the ease of emulation seems to correlate somewhat with ease of programming model. The infamous example which comes to mind even far beyond the SNES is of course the Sega Saturn, while on the other end of the spectrum, Dolphin has support for multiple consoles at once.