Live data from Hacker News

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

arstechnica.com

11–20 of 47 posts

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

#11
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.

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

#13
post #6
post #2

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…

> 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?

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

#14
post #2

This might be a lot easier on an FPGA.

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

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

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

#15
post #7

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 emul…

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)?

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

#16
"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.

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

#17

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 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

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

#18
post #7

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 emul…

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.

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

#19
post #13
post #6

Earlier quoted context omitted.

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…

> 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.

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

#20

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.

Post reply on HN