Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator | Hacker News Reader

Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator

arstechnica.com

176 pointsthehigherlife44 comments

"One of the fun aspects of a cartridge-based system is that you are literally plugging a PCB directly into your system. Thus, you can put extra coprocessors, often digital signal processors, right inside of the cartridge. This gives you an extra edge against your competitors' titles. The most popular SNES coprocessors were the SuperFX for polygon rendering and sprite rotation (used in Starfox and Super Mario World 2) and the DSP-1 for 3D math (used in Pilotwings and Mario Kart.)"

Very interesting. I never thought about this even though I've recognized the differences between games. I just attributed it to better game software, but it could literally have been better hardware available to certain games. You can't do that with CD/DVD/downloadable games.

This is why the NES had the insanely long life it did. Every game was able to provide custom hardware (called 'mappers') to offload computation. I've said for a while now that the next generation of consoles will go one of two routes: completely downloadable titles, or PCI-e-based cartridges. I'm inclined to think the latter, despite the evidence to the contrary. It's just such a huge benefit, and they love shipping physical items. This would also largely eliminate piracy.

The cost savings of downloads are just too ridiculously huge to really think about going back to manufacturing circuit boards. Beyond the marginal circuit board cost, there's a huge physical goods infrastructure that just doesn't have to exist when you go with downloads. Servers are a good bit easier to manage than manufacturing plants and shipping infrastructure.

Yah, but what if physical goods gave you that edge over your competition? That neat wow cool factor that all of the other 'download' devices don't get because they can't change?

"Neat, wow, cool" is insignificant compared to the advantages of digital distribution. Done right (see: valve, humble bundle, even xbox live to some extent) it enables you to slash incremental delivery overhead for each copy of a game, which means that the purchase price can become almost entirely profit margin. Which further means that you can cut prices down to levels that will massively increase the volume of sales and increase your total profits, especially on older titles.

Higher profit margins, lower operating costs, and the ability to massively extend the profitability window of a given game (from only a few months to a year to more than a decade) make digital distribution extremely advantageous for anyone who can take advantage of it properly.

But in a download-only world, physical goods would be perceived as rather inconvenient to obtain compared to the norm, somewhat negating the effect. (In PC gaming, this is arguably already true.)

No, that will never happen. Businesses don't work that way.

Sony thought servers would be easy to manage.

A general system expansion slot would make a lot more sense. Think the RAM expansion on the N64. It'd be silly for each new game to have to provide its own extra processors or RAM in its own (expensive) cartridge, and console piracy is close enough to dead already.

console piracy is close enough to dead already

What? When did this happen? Last I checked there were successful exploits for every major console on the market.

PS3s are only vulnerable with old firmware, and hacked ones can't play new games nor play online.

I've been follow Byuu's progress on BSNES for a couple of years, and I would like to state for the record that the amount of effort he had put into this project far exceeds the majority of "hobby" projects.

Just in the past few months, several SNES co-process chips that remained un-emulated for years, have been deciphered and fully emulated in BSNES. Without Byuu leading the charge into the last bastions of SNES emulation, I absolutely believe that some of these devices would be lost to history.

For anyone who is looking for some code to read with I would recommended BSNES. It isn't a huge code base and worth the trip. Read through most of it last year after finding it and found it most enjoyable.

You would think that the OEM's are leaving a fair amount of money on the table by not offering a true software emulator.

Have you heard of anyone from Nintendo getting involved (in a positive or negative way) with Byuu's project (or maybe they already offer one via the Wii--not sure)?

Nintendo offers the "Virtual Console" on the Wii and 3DS.

Unless my knowledge is out of date, Nintendo's business model revolves around licensing for publishing software for their hardware, so it's in Nintendo's best interest to sell hardware, and not to support emulation on other hardware.

On a related note, when Sony sued 'Bleem!', it argued that running the software on other hardware destroyed Sony's control over the player's experience, and as a result hurt their brand.

I believe Nintendo intends to profit via software licensing and hardware sales. The Wii was profitable at launch[1].

But I wonder how the Virtual Console works on the Wii. Does Nintendo have an SNES hardware-to-software conversion guide? Do their VC releases turn out perfect? I've bought a few, and while they're certainly faithful, I'm not enough of a connoisseur to spot the flaws.

[1] http://www.next-gen.biz/news/fils-aime-wii-hardware-profitab...

I'm under the impression that each Virtual Console download includes an instance of an emulator. If that's the case, they may tweak the emulator for compatibility with each game (or hack the game itself). If you want to look into it some more, the guys who do 'Virtual Console WAD injection' might have an idea. ROM Hacking and (NES/SNES) console development sites/forums might have some information, too.

I vaguely remember hearing of instances where games weren't emulated accurately (or even as well as on other emulators), particularly with regard to slowdown on PAL consoles.

Yeah, in the one case where I tried the wii virtual console with a game that was big in my childhood (Contra 3), it just doesn't feel quite the same. Noone's gotten an SNES controller quite right, either. So I hang on to a SNES to bring out every now and then.

http://www.retrousb.com/ has adapters to connect the original NES or SNES pads to either USB or a Gamecube/Wii. I've used their SNES-to-USB adapter and it works perfectly.

Oh awesome, thanks! I'm gonna pick one up just for zsnes...

I wonder if such accuracy is necessary for emulating newer systems. I don't think my PS3 games are updating the graphics hardware mid-scanline. If modern systems have more relaxed timing requirements, then a much simpler binary translation may be enough. You no longer have to model the hardware, just the abstraction layer that the game itself is written against.

This is the premise of HLE, or high-level emulation. You emulate the CPU (if it doesn't match the current one), and then implement all the APIs it hits. It's more like WINE than BSNES.

The one place where you may end up emulating something with precise timing is the audio processor; the Gamecube and Wii for instance used a custom DSP that had to be emulated fairly precisely, after the instruction set was revere-engineered.

This was indeed the case as early as the N64 - the technique was referred to as High Level Emulation (HLE).

http://en.wikipedia.org/wiki/UltraHLE

This might be a lot easier on an FPGA.

It is. I did a Sega system on an FPGA in 2003 as a one-semester senior design project. Using a modern HDL (bluespec, or something like the proprietary language my company uses internally) on current FPGAs, you could probably do a much higher level implementation in 1/10th that time.

An SNES would be much more annoying to do, but probably no more than an order of magnitude moreso, so I doubt it would take more than a semester, even for someone who'd never touched an FPGA before.

> I did a Sega system on an FPGA in 2003 as a one-semester senior design project.

The article was about achieving extremely high compatibility by emulating hardware quirks. What advantage would an FPGA be? Easier synchronization?

The hardware quirks, by and large (ignore things like the behavior of undocumented/unintentional instructions on the CPU -- these are a separate issue and easy to deal with), are due to the impedance mismatch you have of emulating hardware on software. When you're emulating old hardware on an FPGA, you don't worry about synchronization, you just have the cycle timing be a multiple of the original timing. This gives you "synchronization" in the same way the old hardware did -- these components are all running in parallel and pushing/pulling data at specific times, which happens implicitly in hardware.

FPGAs make this a complete non-issue. Of course, FPGAs bring in a whole host of issues when you want to make such a thing practical. One thing I've been considering for a long time is a super high-level HDL specifically for emulation like this, which can either be run on the CPU (slowly), synthesized for FPGAs, or burned into an ASIC. You could have a whole catalog of components and put them together just like building a real console.

FPGAs don't solve all the timing problems. In some cases, you have to accurately emulate the stalls that occur on one processor as computation or interrupts occur elsewhere.

Synchronization and timing issues are two different things, though, and synchronization is implicit if you get the timing right, unlike emulating hardware on software. The timing aspect of it is just a matter of properly emulating the behavior of the chip; not easy, but significantly easier to get right than synchronization in software.

But that said, FPGAs are by no means a silver bullet. There are a billion problems with them, mainly due to the terrible development tools, at least the ones that someone not doing this stuff professionally can afford.

I wonder if you could solve some of the issues by building each component in an FPGA and wiring up as appropriate to simulate the timing/sync better vs. emulating the entire system at once.

http://www.youtube.com/watch?v=onBmiHoOxGs

Replicate each component of the original SNES hardware? That has been somewhat done: you can buy hardware clones of the SNES in many stores.

The majority of the clones are using "NES On a Chip" or "SNES On a Chip" - they have the same issues as the original minimal requirements based emulators and are generally quite quirky.

Though it looks like at least one person is attempting to create a better one using FPGA: http://cegt201.bradley.edu/projgrad/proj2006/fpganes/

Yes, or replicate all of the original SNES hardware in one FPGA chip (and perhaps a few external passive components).

Citation needed, but pretty sure I heard of compatibility issus that the clones had.

As mentioned in other comments, some SNES cartridges themselves contain coprocessors and other hardware. A clone console doesn't need to do deal with this since you're still playing physical cartridges (versus pure software ROMs).

But clone systems do have issues with many games anyway...

I agree. Plus, I think if the goal is really to 'preserve history', making chips that replicate the original hardware is a lot better (and more accurate) way than trying to software emulate it.

A similar (and IMO, better written) story on emulating the TRS-80: http://queue.acm.org/detail.cfm?id=1755886

this makes me think of full brain emulation.

how far are we from an in silico silicon virtualization suite?

The best estimates I know of is Sandberg and Bostrom's 2008 Whole Brain Emulation Roadmap: http://www.philosophy.ox.ac.uk/__data/assets/pdf_file/0019/3...

And yes, this is pretty relevant - it demonstrates that perfect emulation is extremely expensive (in line with the critics of the idea of AI or brain emulation), but it also demonstrates how this doesn't matter in practice. (eg. I'd be happy to be a nigh-immortal upload if the price was a few glitches in an obscure memory I never think about.)

thanks for that link - very interesting.

i think the question in my post has been misunderstood. i'm wondering, when will it be possible to simulate a SILICON device - such as the super nintendo.

instead of emulating the functional profile of the snes, we could run a physics simulator (at some level of abstraction) that contains all of the silicon circuitry and so forth which actually produces the functional profile.

that seems like a milestone towards simulating neural "devices" like the human brain.

http://en.wikipedia.org/wiki/Blue_Brain_Project

This is very interesting. As the article states, most SNES emulators are inaccurate by quite a bit. Despite that the incompatibilities are mostly imperceptible. Perfect emulation of the brain and human intelligence may be a long way away. But perhaps something very closely resembling it is not nearly as far off as we think.

Very

I'm really impressed by the dedication of this guy. Kudos.

Reply on news.ycombinator.com