Silhouette is the product of internal Nintendo research over several years. In my opinion, the history of Silhouette is nothing short of fascinating, so please read this document at least once before you throw it in the trash. Originally developed under the code-name "Mirage" and designed to serve as a Super Famicom development environment, Silhouette has been modified into a working Super Nintendo emulation environment which rivals the best efforts of any public development. Adequate explanation of Silhouette requires a step back to the original days of Super Famicom development.

The first batch of games for the Super Famicom were developed around 1988 and 1989. Popular Super Famicom titles, like F-Zero and Super Mario World, were the most difficult for several reasons--if nothing else, the Super Famicom hardware specifications changed in small ways at least twice during the development project, requiring changes to existing code. (Trivia tidbit: the original Super Famicom plans called for much more extensive onboard 3D hardware--PilotWings was developed assuming that this hardware would be present, and since this chip was scrapped from the Super Famicom at the last minute, Nintendo was forced to include this 3D chip on the PilotWings board in order to keep the game on schedule.)

The other reason for difficulty in development is much less known, and very surprising--almost all the programming for these titles was done on the Apple IIgs! This seems ridiculous until you realize that both the Super Famicom and the Apple IIgs are based on the 65816 processor, a cheap toy with inadequate processing power that was stuck in the Super Famicom to smooth over the early development process (since it is backwards compatible with the 6502, the NES' processor). However, it was soon realized by the development teams that a reliable 65c816 development platform could not be found on the usual Nintendo platforms (most Nintendo devs at that time had a generic PC, excluding the art and marketing department which was mostly Macintosh and a few segments of the development team). Deadlines approaching, the Apple IIgs was chosen as a quick if inelegant solution--several C and assembly compilers were available, and testing and debugging was easier since we were able to use a native 65816 for testing.

However, the IIgs proved woefully inadequate for large projects. Most machines didn't even have hard drives! Compile times for even meager projects were horrendous, and keeping all the work on floppies was getting out of hand. And obviously, the graphics support on IIgs' was minimal, so testing out small programs required switching between a Super Fami prototype on the left and a IIgs on the right. Programmers, in general, hated the thought of Super Famicom development. Many continued to write 6502 code using the old NES development environment, choosing to ignore on the 16-bit advantages of the 65816 in order to complete the project without losing their sanity.

Nintendo soon pushed its efforts hard into developing a reasonable development platform for Super Famicom (and soon, the Super Nintendo). The project was codenamed Mirage, and several of the key designers of the Super Fami hardware were assigned to the project. Along with full 65c816 emulation, interrupt timing and memory management, the Mirage dev platform offered realtime debugging, code stepping, breakpoints, limited video support and almost instant compile times. Developers were happy, and Mirage proved to be an excellent way to write Super Famicom software in record times.

At first, Mirage was anything but a traditional emulator--the video consisted of squares on a black background (showing where sprites would be) and pages of debugging information. It did not run in real-time, there was no controller interface, no SPC700 chip emulation (required for sound), a text-based user interface. It was meant for programmers and used for writing code. Final testing was done on a real Super Fami unit.

However, over time, the Mirage project got more advanced. Of course, bugfix after bugfix was added, patching the code to make sure its output matched that of a real Super Fami. A team working on some tricky graphical effects added the first major patch, a separate window (originally forced onto a second monitor) which would render a virtual SNES screen. This process took several seconds on our original hardware--one could watch the screen slowly draw from top to bottom--but it worked, and it was more accurate than most of the emulators you see today. A second team optimized the code, and combined with computer upgrades around the Nintendo offices, this let Mirage run in pseudo-realtime, although it was a fraction of the speed of a real Super Famicom.

It soon became common to test games on Mirage more and more extensively. Developers found that the time needed to load their code from Mirage into the testing units (up to a minute for large games) was excessive, when with a click of the mouse they were able to immediately see the game running within Mirage. Of course, there were a lot of limitations, and nobody would argue that Mirage could replace a real unit, but it was a start.

This is where the story gets interesting. In late 1996, a high-level executive (who will remain anonymous) at Nintendo came to the Rare labs one day, and saw a coder working on his game using Mirage. (Trivia tidbit: Yes, Rare has many of its development labs within Nintendo of America headquarters nowadays -- they were always in bed together, now more recently they've even shacked up. Diddy Kong Racing -- shudder.) By now, computer hardware had advanced to allow Mirage to run at playable speeds on this guy's average desktop hardware. Suddenly the potential struck him -- Super Nintendo games on household PCs! Obviously there's a market.

Nintendo of Japan shrugged off the idea, but they always have -- NOJ is known for passing over potentially valuable markets, and focusing on selling elaborate junk to young children (Virtual Boy, anyone?). On the other hand, Nintendo 64 has not been the blockbuster that was hoped for in the US market; obviously the higher-ups overestimated the market for $79 games designed for kids when competing systems sell their games for $39. Regardless, the project Silhouette was spun off from Mirage in an attempt to broaden Nintendo's market to PC owners, especially those who liked SNES software. Silhouette had two main developers, myself being one of them; the Mirage team also worked on large portions. Silhouette was designed to be a subset of Mirage; its purpose was to play games, and be as optimized as possible for today's computer hardware, but be as accurate as possible. No debugging windows, no test modes, no compiler--just the emulated hardware, with the best possible gaming experience. Every attempt was made in Silhouette's course of development to obtain speed without sacrificing compatibility.

In many cases Silhouette was forced to expand to include features that Mirage did not cope with. For example, Mirage had no sound support whatsoever--Silhouette includes a full SPC700 APU emulator, designed by myself and my partner from the ground up. Original versions of Silhouette also included an encryption scheme to prevent customers from hacking the software and using ROM images other than the game included with the emulator; the version you have does not include this encryption, however.

An interesting note is that most employees at Nintendo had no idea that other people had already thought of SNES emulation until very recently. The entire SNES9X cancellation story is a huge mess of bad PR for Nintendo, but it couldn't be helped--if a Super Nintendo emulator were released as freeware (along with the heavy ROM piracy that is characteristic of the Internet), the market for Silhouette would be slim to none. Nintendo's efforts in combatting ROM image piracy have always been swift and effective, and frankly I feel nothing but satisfaction seeing ROM pirates get shut down. Try watching your colleague's or friend's hours and hours of labor get translated into a ZIP file and get spread across the Internet and see how it makes you feel. Piracy sucks, people--don't use Silhouette as a vehicle for piracy.

Unfortunately, as you can see, Silhouette did not make it into stores nationwide as planned. Within the past few months, Nintendo of America has undergone some extensive reorganizations and layoffs. Much of the blame for this rests with the current state of N64 sales (let's just say we're not doing so well; Sony destroyed us this Christmas). The high-level executive who brainstormed Silhouette lost his job in the red tape. After that, it was only a matter of time before the word came down from NOJ to axe the Silhouette project, still unfinished. That ended my career at Nintendo, since Silhouette had been my only major project at Nintendo for several months and I had nothing to do after the project was gone. I packed my bags and made sure to get a copy of Silhouette on Zip disk before taking off.

I'm pretty sure that Silhouette is dead at Nintendo. In fact, I wouldn't be surprised if they denied that it ever existed, at this point. But let the facts speak for themselves--here's Silhouette, now on your hard drive. Have fun. Due to the facts behind this program's development, and the confidential nature of Silhouette, my colleague and I chose to release Silhouette only under anonymity.

Most of all, please enjoy Silhouette! It's got a lot of hard hours of work invested into it, and although I know there's a lot of rough edges--transparency masking, for example, is all wrong, and the SPC700 really needed a little more testing--it really is the best out there. Special thanks to whoever drew these icons--I lifted them off another emulator in haste, since I am not an artist.

Future versions of Silhouette may emerge from time to time. No promises, and no release dates -- I have already gotten myself a new job where I'm extremely happy, but the days are long and you can only program for so many hours in a day. Have fun, and thanks for trying Silhouette!

-- Silhouette Public Release 1.0, 1/1/98

Related Links

Download Silouette emulation.net

Get Published!

If you've ever wanted to write a journalistic article about emulation, interview an author of an emulator, or write an editorial expressing new insights on the emulation scene, then perhaps you should submit an article to Archaic Ruins! The criteria for having your work published is that your work must show effort. Interviews must contain at the minimum, 10 questions. Editorials must be at least 2 to 3 pages and quotations from multiple sources to support your views and opinions. Humorous writings are also accepted! - The Archaic Ruins Staff

Site Information

Archaic Ruins FTP Site Editor's Choice Award Frequently Asked Questions New Additions to the Ruins Submit Updates

File Archives

Emulators Documentation Development Tools Hacking Utilities ROM Hacks ROM Images Translations Utilities

Departments

Articles Charts Features Geek Mail Message Boards News Reviews Site List Staff Pages

Other

archaicNET: Search Engine