Slashdot Mirror
Ask Slashdot: Understanding the SNES?
An anonymous reader writes "As a product of the 90s I grew up loving the classics that kids today know about from Wikipedia and pop-culture references. Games like Super Bomberman, Zelda: A Link to the Past, Donkey Kong Country I and III (II was a sellout, come on) are the foundations of my childhood memories. Now, though, as a fourth-year electrical engineering major, I find myself increasingly impressed by the level of technical difficulty embedded in that 16-bit console. I am trying, now, to find a resource that will take me through the technical design of the SNES (memory layout, processor information, cartridge pin layouts/documentation) to get a better understanding of what I naively enjoyed 15 some years ago. I am reaching out to the vast resources available from the minds of the Slashdot community. Any guide/blog series that you know of that walks through some of the technical aspects of the, preferably, SNES (alternatively, NES/Nintendo 64) console would be much appreciated."
http://wiki.superfamicom.org/ has pretty comprehensive technical documentation of the Super NES.
you're a 4th year EE student, why not just take one apart?
http://byuu.org/articles/
Byuu is the guy who wrote bsnes, which is a 100% accurate SNES emulator written specifically to emulate it as close to the hardware layer as possible for the sake of preserving the system.
The source code to a very good SNES emulator is available here: http://snes9x.ipherswipsite.com/
Slashdot's first reaction to VMware
http://nesdev.com/ Formerly nesdev.parodius.com This and Zophar are the who main places to go.
Even aims for cycle accuracy.
http://byuu.org/bsnes/
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
Especially interesting is the special circuitry that eliminated the need to blow air into the cartridges that plagued the original NES.
Be careful. A lot of that stuff at Zophar's Domain is way out of date. Much of it is based on speculation or trial-and-error emulator testing or is flatly incorrect.
Of all systems I looked into, I found the gameboy the easiest to understand. The underlying CPU is quite simple. The LCD display is quite simple to understand, there are not a huge amount of complex registers to understand, and it's not that timing critical. (Unlike the NES, which depends a lot on instruction timing)
console that I had ever experience in my lifetime. It tried to do the impossible possible at the time. Created pseduo 3-D with mode 7. Created real 3-D polygon games using the FX chip (where the FX2 chip 21 MHz, was 7x faster than the actual cpu!). Created some of the most beloved and classic RPGs and series of the time. Star Ocean, Bahamut Lagoon, Tales of Phantasia (all not released in the US unfortunately) and more. Last gen SNES looked more amazing than most first gen PS1 game, sometimes by a wide margin. 1 or 2 Last gen SNES cartridges were as big as N64 cartridges memory wise. Also can't forget DK that uses "ACM" techniques to create those models in the game.
I have programmed an assembler and written my own games for the SNES. I use this manual quite often:
http://www.romhacking.net/documents/226
It's a leaked dev manual. It doesn't have everything, but it's a great resource.
Because of things like this. Sometimes it's good to have a current, real-time discussion with a range of knowledgable people, rather than searching the entire fucking WWW and figuring out for yourself who got what right and wrong.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Your first step in reverse engineering aka total mastery of a device should be something a little simpler, like a 2600 or a PDP-8 or if you "demand" something modern, perhaps a very small (pun intended) microcontroller like the pic 10F family. You don't mention any previous experience with reverse engineering so I assume you have none.
Because they scale non-linearily, reverse engineering something simple and something hard doesn't take 200% as long as just reverse engineering something hard, it takes more like 100.1% longer, so the tiny extra investment isn't going to slow down the overall project too much. However the experience you gain figuring out the simpler thing Might dramatically reduce the time taken to figure out the hard thing.
The standard /. car analogy is you probably should start with learning how to change the oil before you try to rebuild the engine.
Its not a hazing thing or making fun of noobs, its just good practical educational advice. Trying something way beyond your level at best results in frustration, at worst in a sorcerers apprentice disaster.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
You can't really say that the SNES was pushed that hard when it used chips contained in the cartridges for the really impressive stuff.
Bible Adventures and other Color Dreams games on the NES used a charge pump circuit to send negative voltage pulses through the CIC's data pins until the CIC froze. Nintendo had improved the input protection on the Super NES version of the CIC, making it harder to defeat by reversing the polarity. So Super Noah's Ark 3D had a connector on the top like a Game Genie so it could pass the CIC signals through to an authentic game.
I thought that's what the SNES even more impressive that it could use co-processors while keeping the price the same as other games and no add-ons to the actual system. It gave the system a bit more freedom in pushing software and hardware specs around to achieve what the developers had in mind at the time. For example the developers of Star Ocean used the S-DD1 from wiki: http://en.wikipedia.org/wiki/Star_Ocean_(video_game)#Development "S-DD1 chip to to aid in compression of almost all graphics and map data" Even though it was using the 2nd largest cartridge of the time 48 megabits. (There's Metal Slader Glory which I believe is even larger) In fact SNES games were still being develop long after the SNES life has ended in the US and the PS1 and N64 came out until late 2000. http://en.wikipedia.org/wiki/Metal_Slader_Glory Here's a pretty solid list of impressive games that were developed SNES during it's life cycle. http://www.racketboy.com/retro/super-nintendo-snes-games-that-pushed-the-limits-graphics-soun
vsync might be nice for the user experience, and I'll be the first to admit that bsnes does not have all of the little user conveniences that some older (faster, less accurate) emulators have.
I personally prefer to still use a many-years-old version of ZSNES for actually playing emulated games.
But in terms of accuracy in its emulation of the SNES hardware, BSNES is unbeatable. Byuu-san was always disgruntled about the lazy approach that other emulator authors were taking, towards accuracy--using known-inaccurate techniques and lots of game-specific hacks to cover up any problems--but several years ago he decided to do something about it, and since then he has emerged as one of the most dedicated and careful (and innovative) of the small group of world-class developers reverse-engineering the behaviour of the SNES. Byuu has made literally dozens of unique findings about tiny, obscure behaviours of the SNES hardware--in many cases even things that *no known game even depends on*, but he spent the time and effort to devise theories and write tests and do experiments in order to get a deeper understanding of what was going on. And then incorporating those findings into BSNES in the clearest and most accurate way possible.
The result of this years of super-human effort, is an emulator (BSNES) that is a lot slower than certain other emulators, but also much more accurate in the precise details. It can run every known SNES game (thousands of them) very accurately, with absolutely NO game-specific hacks in it. Which is an amazing accomplishment, and a valuable resource for others to learn about SNES programming (either emulators or games), and I am positive that someday, BSNES will be a key piece of efforts to preserve the history of SNES games so that future generations can learn about them and play them.
vsync might be nice for the user experience
Even if your emulator generates an accurate sequence of bitmap images representing consecutive frames of PPU output, it is not very accurate to send half of one frame and half of another frame to the monitor.
I was able to distinguish between the game not booting and the system reset being held low by the CIC back in the day, apparently no sync is generated during reset or something along those lines because even though you get a black screen you can see it "free-running" and getting torn up horizontally, and newer TVs just blank out the video entirely like an invalid signal. I was even able to hear the difference by 'feeling' if the horizontal oscillator on the TV was free-running or locked. With a successful CIC handshake but bad program execution you get a black screen with proper sync which overrides video blanking on newer TV sets.
Correct - at least one document on Zophar's is wildly inaccurate (I know because I wrote it!)