Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
1–10 of 57 posts
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#2source: http://byuu.org/bsnes/accuracy
this is also awesome, posted a while back: http://byuu.org/articles/emulation/snes-coprocessors
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#3Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate.
So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television. Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisions (especially analog CRTs) have quite a bit of emergent behavior in processing the display input that is not easily captured and replicated by your typical frame buffer. Interlacing is a major such phenomenon; most emulators still simply treat the 60 fields per second as 60 distinct frames rather than interlacing them. (And younger players are used to seeing the games that way, never having played on original console and TV hardware.)
The ultimate example of this effect occurs in emulating games that originally used a vector CRT. An emulator writing to a raster frame buffer simply can't replicate the bright, sharp display of a real Asteroids or Star Castle or Battlezone machine.
TV behavior even goes beyond electronics. Consider the characteristics of the phosphor coating and the persistence time between refreshes. Some games made use of effects where that characteristic mattered, so if you want to emulate that with high fidelity, yes that will take a lot of CPU cycles.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#4Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation?
Performance is far easier to achieve there.
The devices aren't exactly expensive either.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#5Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
FPGAs not expensive? Please let me know where you shop...
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#6Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
FPGAs not expensive? Please let me know where you shop...
Well for small sized dev boards you can usually find them for about $100-$150. What I don't know is if this would have enough capability to do anything like this with it. I'd imagine the 6502 would be doable, but i don't know about the snes.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#7Lots of conversation from when this was posted 9 months ago: https://news.ycombinator.com/item?id=2864531
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#8Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television . Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisio…
That particular problem isn't a case of emulating the television, but rather accurately emulating the console's video hardware and its interactions with the rest of the system. If one were simply interested in emulating the television's behaviour then you could construct a frame buffer based on the visible sprites and postprocess that (possibly in conjunction with several preceding fields).
If the console allowed sneaky things to be done on each raster line (like changing the colours) then constructing that frame buffer becomes considerably more resource intensive, as it must now probably be done line by line with the correct timing wrt. the rest of the emulation.
If you could pull tricks mid scanline (presumably through careful timing after an interrupt) then the problem will be a whole lot worse, though I'd guess it can be reduced by recording changes to the relevant hardware registers along with timestamps in the emulation so that the timing of your scanlines' construction becomes less of an issue.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#9Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
FPGAs not expensive? Please let me know where you shop...
It depends on the size. Big FPGA's are amongst the most expensive chips that you can buy ($10K and up), but small ones are affordable. The amount of logic in an 80's era game computer should be within the gate budget of a small to mid sized FPGA.
See http://www.fpgaarcade.com/ for many examples of this.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#10Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
if you're going to add hardware you might as well just get a real SNES from eBay and use a memory cart.