Live data from Hacker News

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

arstechnica.com

41–47 of 47 posts

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

#41
post #19
post #13

Earlier quoted context omitted.

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

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.

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

#42
post #3

this makes me think of full brain emulation. how far are we from an in silico silicon virtualization suite?

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.

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

#43
post #35
post #32

Earlier quoted context omitted.

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.

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

#44

Earlier quoted context omitted.

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.

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

#45
post #19

Earlier quoted context omitted.

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

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.

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

#46
post #33

Earlier quoted context omitted.

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

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

#47
post #19
post #13

Earlier quoted context omitted.

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

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

Post reply on HN