Hacker News new | past | comments | ask | show | jobs | submit login
The Raspberry Pi Has Revolutionized Emulation (codinghorror.com)
426 points by dwaxe on July 24, 2016 | hide | past | web | favorite | 114 comments

I've had an arcade cabinet with a 9-year old computer in it that finally failed the other day. I tried the Rasberry Pi route awhile ago, it does fine on the oldest 80's MAME games, but has issues with most of the 90's era games of which I'm still quite fond. And as others have noted, it's prolly going to suck for NES/SNES emulation.

So when the arcade computer failed, I tried a different route. I realized my main desktop computer (a Core i7-4790k) is plenty powerful to do some arcade gaming on the side. A long VGA/USB/audio cable later, and my arcade is now running directly off a VM from my desktop. This works so much better than dealing with moving games on/off a SD card, and managing more physical things. It's easy to manage the VM, snapshot it, and change the config without even touching the arcade now.

With VT-d, PCI-passthrough, and the ridiculous amount of CPU cores everything comes with that this should be a more normal thing in the future. It'd be lovely to use those new multi-Gbit wireless standards instead of a cable though...

> And as others have noted, it's prolly going to suck for NES/SNES emulation.

It works great for NES/SNES emulation, and even N64 emulation with an appropriate video plugin.

Ah, is that the latest model of the RasPi? It was lagging quite abit on my older Rasberry Pi B model.

What emulator are you using? They have different features and run at very different speeds. You can run zsnes totally fine on something that has no hope of running bsnes/higan. Try some others.

Pretty sure ZSNES is written in x86 assembly, so it wouldn't run all that well on Raspberry Pi, which is using ARM CPU considering that you would need to emulate an emulator.

That's easy! Just use Bochs. Don't bother with recompilation, just use interpreted x86 :)

ZSNES hasn't been written in full asm since sometime after zsKnight died.

Snes9x is written in C++, IIRC. As is MESS' snes emulator.

Yea, I've had too many issues with imprecise SNES emulation, so I only wanted to use bsnes. I get why people skimp and go for a less precise emu that can handle their hardware, but its too frustrating to me to invest time into a game to be thwarted by emulation failures.

What games? Maybe I was too young or simply didn't care, but every game I tried that ran at all (without immediately obvious bugs) in ZSNES were playable and fun with modest hardware even in the 1990s. Of course I would use BSNES now, or just a real SNES. But back then it was like magic.

Depends when you used ZSNES. There have been times in its history when it's been broken on some very popular games, eg. Yoshis Island, Chrono Trigger, DKC2.

The really frustrating thing was that the bugs wouldn't show up until about halfway through the game, usually when some nonstandard transparency effect was applied. Right at the point when you'd really invested in the game, very annoying.

The other common one was timing problems (ultimately, they're all timing bugs.) Starfox for example used to run something like 20% faster than on hardware. It looked fine, and if you grew up with the PAL version you might assume that the speed increase was just down to version differences, but the game was unplayable.

> Starfox for example used to run something like 20% faster than on hardware/

Make that 200%. I own the original and it's indeed unplayable on zsnes.

Zsnes is a horrible SNES emulator all around. It was decent when it came out 15 years ago, but it mis-emulates so many things it's just not worth bothering with it anymore. Square games (Final Fantasy, Chrono Trigger, Rudra no Hihou) all have wrong sound effects; anything with SuperFX is totally broken; Tri-Star games crash and lock-up randomly (Tales of Phantasia, Star Ocean). And the list goes on and on.

It's sad, because zsnes really has the best UI of the lot, but in 2016 there is simply no reason to use it. Use either bsnes/higan (for 100% accurate emulation) or snes9x (if you want to run it on an underpowered tablet.)

It seems like a lot of the "lesser" emulators have improved now that higan/bsnes is around to show them how it ought to be done. There's a stronger focus on getting the little things right, even if higan-level accuracy isn't achieved (or even desired, given the performance cost and the hardware many of these target—like the Pi)

Is yours the original Pi or Pi 2? The Pi 2 is like 6x more powerful than the Pi, and the Pi 3 is about that much more powerful than the Pi 2.

I have the pi B and I can do SNES pretty decently with a little overclocking. I understand the Pi 2 can do SNES with ease, and N64 pretty well too. I can only imagine the Pi 3 will do N64 smoothly and more.

I use fceux on my raspi model b, and it works flawlessly.

Consider a Steam Link, http://store.steampowered.com/app/353380/ or similar system to mirror the content from your PC. It will handle sending video/audio to your TV/arcade and sending the inputs back the desktop.

I have one of those lying around, but the issue afaik is that the Steam Link kind of takes over the PC that is running the games to stream the system. Hooking up the speaker/controls/VGA of my arcade via a long cable directly to my PC, means Windows sees it as another screen with more devices.

Then I just tell VMWare Workstation that the arcade joystick USB should go directly to the arcade VM, and drag the VM window over to the arcade screen. This means I can use my computer directly as normal (I code in a linux VM on it), while the arcade is running independently. It works really well and lets me use a spare 4ghz core to run Hyperspin+MAME faster than my old arcade PC ever did.

How much latency does one of these add? It might be fine on a modern cinematic console shooter, but a large amount of the appeal of some old arcade games is their frame-perfect timing. I can't imagine that's helped by adding a round trip over the network, not to mention streaming the video back. That's gotta add 2-3 frames' latency at the very least.

The default settings have some noticeable latency (5-10ms), but changing the video encoding from "balanced" to "fast" drop it down to almost nothing. You can additionally plug the controller(s) into your PC to further remove any input delay. I can't vouch for emulated arcade games, but it works surprisingly well with a steam collection.

Axiom Verge was unplayable on any settings I tried.

You want to make sure that you have the Steam Link wired into your network, rather than on wireless, because that makes a huge difference.

Otherwise, it's gotten so they are pretty decent now. When the Links first came out, they were quite laggy and unstable, but after a hundred or so patches, it's settled down.

I'm modding my old iCade cabinet to make a bartop with an 8" LCD monitor, and I opted to use an Atom based stick PC. I'm going to use the stick PC for running retro emulation locally, and streaming from Steam via the Windows Steam client.

I'm also going to use an HDMI switcher so that I can connect it to a faster machine like my laptop as an option.

I am playing with a RetroPie based gaming system on an rpi3 and all nes and snes games I tried worked without any problem. It even works for PS1,though I only tried one game so far.

Dos games are hit or miss, and it does horribly for N64.

> Dos games are hit or miss, and it does horribly for N64.

Use an optimized video plugin, such as (shameless plug): https://github.com/tachiweasel/mupen64plus-video-videocore

I used to have problems on my Pi2 with N64, but enabling overclocking fixed those issues for me :-)

In regards to SNES / NES sucking.

I tried the retropie about a year ago on my Pi2 and there were no issues at all. Sega Genesis/Megadrive worked well too.

"Viewing angle and speed of refresh are rather critical for arcade machines, and both are largely solved problems for LCDs at this point"

This is true, but not for the cheap IPS LCDs he advocates. The important point is image persistence. Each frame is a sample of a single point in time. To accurately represent motion it needs to be shown for as close to a single point in time as possible. Most LCDs sample-and-hold, i.e. they set the pixel and keep it there until the next frame. This results in blurring when your eye tries to follow motion. See:


Modern gaming LCDs can strobe the image like a CRT, eliminating this blur. It causes noticeable flicker at 60Hz, but it's the only way to get sharp looking motion from these fixed framerate games (motion interpolation adds latency which is no good for games).

I wish someone would ressurect crt or come up with similarly cheap tech.

I own lots of monitors, but after I tried my CRTs again recently, I fell in love with them again, the image itself, and the motion is much better than any flat panel that is affordable. (Also my CRTs aren't high end even! they were medium range, or outright cheap when I bought them new, one is even 1024x768, that now feels too small, but the image quality overall is soooo awesome...)

SED(Surface Conduction Electron Emitter Display) was what I was most excited for, and it died before it got started. It's basically a matrix of tiny CRT monitors.


SED doesn't have the high quality motion of a CRT or a strobed LCD because it's PWMed. You will either see ghost images trailing motion, or sample-and-hold blur, depending on the PWM frequency.

... and Duck Hunt! :P

I don't know that arcade monitors from the 80s had zero ghosting or phosphor persistence. And a TN display is going to sacrifice so much on angle of visibility that I don't know if 120hz updates are worth it.

That said it is an interesting aside and there are a few more details here http://www.mameworld.info/ubbthreads/showflat.php?Number=305...

Oh great, that's just what we need, the return of flicker. Now my sister can get sick when attempting to play games again, just like the old days.

Besides which, I thought the particular way CRTs blur and ghost was part of the appeal?

In real life there is also blurring, because of the finite speed of the human retina. So perhaps CRTs are actually too sharp because they miss the blurring of the intermediate pixels (unless you can correct this in software).

No display device can bypass blurring caused by finite speed of the human retina because it is viewed by the human retina.

The blurring we are talking about takes place during "smooth pursuit" eye movement, where the eye tracks the moving object. During smooth pursuit a real moving object makes a static image on the retina. A strobed display makes a series of static images on the retina, and the human brain is very good at interpreting intermittent short images as motion (consider hunting a small animal through thick vegetation) so this also looks good. The sample-and-hold display presents a series of moving images on the retina when you are expecting a static image, and this is seen as blur.

CRTs are actually less sharp than real life because of non-zero phosphor decay time. A modern gaming LCD can be sharper than a CRT because LEDs can turn off faster than phosphors.

What I meant is the following. Consider two frames of a video. In the first frame, a colored dot is at position (0,0). In the second frame, a colored dot (same color) is at position (10,0).

The eye/brain interprets this as a dot traveling from the far left of the screen to the right by 10 pixels distance.

Now, to the eye, there are 9 pixels missing between the two dots. In reality, if a dot was moving, those 9 pixels would have been briefly lit up on the retina. Hence, you need some blurring to make a sequence of frames appear to be realistic.

Although higher framerate is preferable, the brain can easily interpret the motion despite the missing information. There is no blurring in reality, so adding blur only makes things worse.

I've long thought it would be interesting to make an education-oriented Game Boy Advance clone to teach low-level programming. I.e: Base it on the expired patent, but don't copy the copyrighted BIOS and don't bother being compatible with commercial game ROMs.

The conflict is that it sure looks like sourcing everything but the SoC (case, screen, controls, battery?) will cost more than a RasPi-like SoC capable of emulating a GBA. At that point the question becomes, What's more valuable inspiration-wise: Telling the kids "Your game is really running on the same physical hardware as a GBA" or telling them "in addition to GBA, this device can emulate a bunch of other devices and there's the whole RasPi ecosystem as well" ?

Disclaimer: I know nothing at all about sourcing hardware.

Teacher: "Your game is really running on the same physical hardware as a GBA!" Kids: "A what now?"

It might be hard to hear, but the "inspiration" factor of a Game Boy nowadays is minimal - the kids you're targeting have probably never seen one, and would be unimpressed if they did, having been reared on iThingies.


TI's educational graphing calculator line is the closest thing to ideal I've ever seen. It's nearly the perfect formula, lacking only a backing company committed heart and soul to openness. Graphing calculators are equipped with basically the same hardware as a Game Boy, plus they:

  *are standardised and mandatory in high school math
  *have a massive base of ticklish software and games
  *come with BASIC and support assembly
  *have a link port that enourages peer-to-peer sharing
  *are practically useful without requiring tinkering
(The last one is especially important. It's way better to support tinkering than to require it. To get people to actually buy and play with it, the device should stand alone.)

This formula works. An entire generation of low-level programmers was raised on these things. It got me into programming. They are the last surviving relic of the philosophy of the 80s microcomputer.

Those things are terribly outdated.

A modern Nintendo DS with a homebrew card is much much better and powerful, and all the low level you want or more, with better documentation than Graphing calculators(made by open source contributors).

If you don't care about low levelness any android smartphone have better capabilities.

I have smartphones and tablets with Ubuntu, that is without a doubt the best system for learning if you are serious into programming today.

Bonus, there's a huge community already around them.


Kids this days don't care about GBA at all. Why should they?

You have to understand that we emotionally connect with our past. You probably played with your friends on the GBA and shared great moments.

But kids today will make friends today with current hardware. For them GBA is obsolete.

Disclaimer: I volunteer teaching marginalized kids in immigrant and drug places. We do things like this: https://www.raspberrypi.org/magpi/super-gamegirl/

That we print ourselves with 3d printers. But the machine is the least important thing of all. The important thing is making those kids feel a great time with each other and teach them other worlds and give them hope.

We use machines for our purposes, that is making them not enter drugs, crime and prostitution, but it is just a tool.

I think that pocket CHIP would fit most of your requirements: https://www.nextthing.co/pages/pocketchip

It's not the same because the CPU is much faster than it needs to be for such primitive sound and graphics. A major appeal of fixed hardware is coding close to the metal to get the maximum performance out of it. The PocketCHIP is supposed to be programmed in Lua, which you could do anywhere. With the GBA you're probably going to learn assembly, and because it's ARM the skills will be useful for many other things.

There is the Arduboy¹, which is definitely a lot more primitive.


¹ — https://www.arduboy.com/store/products/arduboy

Arduboy sure is cute. But, there tiny then there's really tiny! 2.5k of RAM in the Arduboy is even smaller than I had in mind. I guess I'm thinking of something between that and this http://www.mouser.com/new/embedded-solutions/display-modules...

That is definitely a possibility and the best illustration of what I'm talking about. It's effectively a $10 SoC in a $60 case. Going lower to match the actual GBA hardware specs wouldn't significantly affect the cost of the device even if the SoC was free.

I'm being pretty idealistic, but I like the idea of "This is how actual GBA games were made." The GBA is a very beautiful architecture because pretty much all of it's capabilities were memory-mapped structs. You write to addresses and stuff happens. So, it's very simple yet powerful enough to get really good results even though you have a ridiculously low budget in terms of cycles/frame.

Writing Lua to call frameworks that maybe write to abstracted "ports" on what's effectively and Android from a couple years ago all to get half the screen-rez results compared to a GBA... That just doesn't seem to accomplish teaching low-level programming.

Any embedded programmers in the room? Does this sound actually useful at all? Or, is embedded getting to be more like coding on a RasPi than a GBA these days?

"Embedded" is a pretty wide spectrum these days - some is pretty close to an RPi, some is much closer to classic embedded systems.

The primary drivers are a) how much processing do you need to do? If it's lots, why not run Linux underneath since you need a relatively beefy processor anyway, and b) how cost-sensitive is the product? If it's not very high volume, the speed of development you can get by developing on top of Linux instead of bare metal or an RTOS is likely to outweigh the COGS difference.

The resolution is low and the touchscreen is a decade old, but it's got promise - we'll see what the community does with it.

Teacher: "Your game is really running on the same physical hardware as a GBA!" Kids: "A what now?"

It might be hard to hear, but the "inspiration" factor of a Game Boy nowadays is minimal - the kids you're targeting have probably never seen one, and would be unimpressed if they did, having been reared on iThingies.


TI's educational graphing calculator line is the closest thing to ideal I've ever seen. It's nearly the perfect formula, lacking only a backing company committed heart and soul to openness. Graphing calculators are equipped with basically the same hardware as a Game Boy, plus they:

are standardised and mandatory in high school math have a massive base of ticklish software and games come with BASIC and support assembly have a link port that enourages peer-to-peer sharing are practically useful without requiring tinkering

(The last one is especially important. It's way better to support* tinkering than to require it. To get people to actually buy and play with it, the device should stand alone.)

This formula works. An entire generation of low-level programmers was raised on these things. It got me into programming. They are the last surviving relic of the philosophy of the 80s microcomputer.

> For a budget of $100 to $300 – maybe $500 if you want to get extra fancy – you can have a pretty great classic arcade and classic console emulation experience.

...if you are OK with pirating games. Its a bit odd that for the number of times this article talks about how cheap and easy it is to get this setup going, they kind of handwave away the fact that even old games are still copyrighted with "Add additional ROMs and game images to taste."

With no legal way to purchase most of the games on these systems -- and certainly not in a way that the original creators would benefit -- most people would be O.K. with pirating games.

A lot of these older classics that you'd probably want to emulate are actually available in some form or other. For PS1/2 games, you can often purchase inexpensive digital copies on the Playstation Store, and for older Nintendo titles they offer digital copies through their Virtual Console service.

Additionally, just because a title isn't easily available for purchase, or available through your desired channels, that doesn't magically invalidate copyright.

> Additionally, just because a title isn't easily available for purchase, or available through your desired channels, that doesn't magically invalidate copyright.

I think most people understand that legal/illegal is only loosely correlated with right/wrong.

>A lot of these older classics that you'd probably want to emulate are actually available in some form or other.

And emulation is the reason those titles are available. Those titles are being emulated on other systems. Without the games having been pirated to begin with, the people sitting on the IP would have left them to rot. Piracy is a demonstration of demand. Do you think the iTunes Music Store would have come about without Napster?

>Additionally, just because a title isn't easily available for purchase, or available through your desired channels, that doesn't magically invalidate copyright.

"Information wants to be free." It doesn't invalidate the copyright, but it certainly lowers the 'perceived harm' in the mind of the end-user.

And the copyright holders, thankfully, don't seem to be very attentive. Coolroms and EmuParadise are still around, I was grabbing ROMs from there over 10 years ago.

I definitely agree that console emulation is a Good Thing from the standpoint of preserving the history of the medium. Hell, I've been working on my own Game Boy emulator in my spare time out of a mixture of technical curiosity and preservationism.

I also agree that a large, driving force behind the development of these emulators is the wider public's desire to easily play old games for free.

That said, it doesn't mean I condone the illegal redistribution of old games to play on these emulators. The fact that it's easy and largely overlooked by rights holders doesn't change the ethical equation for me.

> The fact that it's easy and largely overlooked by rights holders doesn't change the ethical equation for me

Which is fine, but ethics are essentially a personal thing. For example, I've pirated things I own on non digital medium. Or heck, even things I own on DvD because frankly double clicking 5 times is way more convenient than digging out the disc and sitting through unskippable shitty intro warnings etc.

In neither of those cases am I within the law, but I'm ethically comfortable with it. Similarly, I wouldn't feel bad using an emulator despite them necessitating the pirating of games.

AFAIK you can make copies of your owned disks or rip them, legally, as long as you don't distribute. So ripping a cd to listen to it is fine. Now instead of ripping it, youngot yourself a copy online. You have already paid for the material. (As long as you don't sell your physical media, that is).

At least, that is how it is in the Netherlands.

I condone the illegal redistribution of old games. In fact, I consider it a moral imperative. Social archiving is the only reason some things still exist.

Literature, music, video games -- all are artifacts of our cultural heritage. That lawmakers have decided to exceed the original copyright terms in the interest of whatever holding company batch-acquired the dead IP is unfortunate, but I don't derive any moral judgement from that.

You could buy an officially licensed emulator which gives you copyrighted ROMs. You are allowed to use your legally purchased ROMs however you want, including in other emulators.

It is possible in some cases but super fragmented, you can buy old Sega games on Steam for example. Probably best thing to do is pick the games you play the most and try to buy something from the parent company, if it still exists.

In the case of Nintendo and Sega, a large number of their games can be purchased through the Nintendo eShop on the Wii U and 3DS.

That number isn't all that large when you take into account the size of each console's library. Virtual console only carries the "top" titles and a small smattering of outliers.

Take the SNES for an example. 721 titles released in the USA, 1442 (with considerable overlap) in Japan. The VC only has 63 titles.

N64? 296 titles USA, 21 on VC.

NES? 679 USA, 92 VC.

Genesis? 729 USA, 73 VC.

So unless you want to leave roughly 90% of each system's library untouched, "piracy" is the only choice. I'd give just about anything to play Tetrisphere again (it's one of those games that doesn't emulate quite right) in a sane way, but Nintendo doesn't want to sell it to me.

Some games may never (for human-scale values of "never") be sold again, or only with unacceptable alterations, usually for licensing reasons. Goldeneye's[1] a big example of the former (Bond licensing), Crazy Taxi of the latter (music licensing—IIRC the only console release of it with the original music is on the Dreamcast, and it's unlikely that'll ever happen again).

Similar things happen with older TV, too, especially with music licensing. Failure to license for online/dvd distribution was common until pretty recently—I think Skins (UK) has that problem, for example. Only way to watch it as it originally aired is piracy.

[1] There was a "remake" released but it was an entirely different game. Basically a bad Call of Duty clone. Nothing at all like the original, and nothing like the excellent HD re-release of its successor Perfect Dark on the Xbox360.

I don't see who is hurt by this really. These games are long dead, companies that made them are often gone, and they've made 99% of the income they will ever make. It's difficult to obtain a copy legally even if you are willing to pay. And if you buy used, you don't benefit the creator either, so what does it matter if you pirate instead?

I've argued a lot in the past that copyright should only last 15 years. But at the very least there should be a fee to extend copyright longer than that. It shouldn't be infinite by default.

Flippant answer: Who cares?

Less flippant answer: In the vast majority of cases, the content literally cannot be purchased. Downloading ROMs does about as much harm as violating the speed limit to keep up with traffic flow. Some megacorp's lawyers might prefer I didn't do that, but see the flippant answer above for the response.

In addition to what others have said. If I were to actually /buy/ a cart, how would I rip it to my computer without knowledge of how the stuff works and (IIRC) expensive equipment. You're average Joe isn't gonna spend money on an actual cartridge (that won't benefit the authors in any way) and figure out how to dump it when someone else has already done that.

It's not gonna benefit the authors because they aren't making them anymore. Unless you somehow bought it directly from the authors or stores are still buying stock, there's no way for the money to go to the author. Carts are all pretty much second hand now.

I've attempted to do this. It's not as simple as Jeff Atwood states.

For starters, there is a lot more tinkering and messing around than is indicated in the article. You want to connect an old PS3 controller that's sitting around? Great...prepare to spend 3-4 days messing around with config file via SSH to get it just right. And even then, it fails intermittently and works in some games, but not others.

Secondly, while some N64 games do emulate reasonably nicely, most do not. There are either audio issues, or video issues. And on and on. PSX and Dreamcast games - I couldn't get those to work without lag at all.

Have you checked out RetroPie, the distribution mentioned in the article? In my experience, using a PS3 controller with that consisted of connecting the controller via a USB cable, selecting 'configure controller' from the main menu, and mapping all the buttons. All in all that took maybe a minute or two.

I've tried using RetroPie with the PS3 controller over bluetooth and it works.....50% of the time. The problem is that when it doesn't, there's literally nothing you can do, you have to log in through ssh and restart the Pi, and it's incredibly frustrating.

I did use RetroPie. That is true, PS3 controller is pretty easy to connect via the USB cable. I tried it to connect it wirelessly. That's where it gets tricky and unreliable.

Thanks to another comment in this article, I installed retroarch, and dug out one of my madcatz fight pad controllers (xbox 360 usb interface). The controller in question was one of the better options for something that would support sega genesis, and snes layouts... 2x3 on the top buttons, with left and right trigger.

Would love to see a UI front end that when you started it asked you to press any button on the controller 1... then start with only (dpad up, down, left, right, select, back) for the UI... then ask if there are more controllers... Once you import/scan your library, when you enter a new rom device type, it can then ask you to roll through the buttons with the original controller on screen, highlighting that button's original name/position.

From there, it would be far easier to play retro games (though arcade mapping would need to be per game).

Yes, it has gotten radically better in the last year or two, combination of Pi 3 hardware being quad core and much faster, and the RetroPie project iterating and improving rapidly.

Jeff, I've used a recent RetroPie (v3.3 afaik) and Pi2, which is only slightly slower that Pi3. I've also attempted to overclock it - it helped a bit, but not much.

pi3 is quite a bit faster:

Geekbench 2.4.2 results, Pi3 on left, Pi2 on right:

Overall 2086 / 1302 Integer 1641 / 998 Floating point 3353 / 2126 Memory 1204 / 729 Stream 978 / 631

Sunspider results, same arrangement:

2888 ms / 4705 ms

Not 2x faster, but pretty close! It's also quad core, though the above benchmarks, particularly sunspider, are absolutely single thread / core perf.

If you're interested in emulation, The Internet Archive also has something cool: https://archive.org/details/internetarcade

I used a pi2 and an LCD I got off Craig's list to build an old Mac emulator with Basillisk II and a lot of patience (took a while to get the right combo of compile options, settings and display environment). It's relatively stable and my 4 year old daughter has been playing kid pix, cosmic osmo and hello kitty on it for a while now. It's also fun to see the after dark screen savers when I go into her room.

Here's a possibly silly question. Is upscaling old games possible? In the past I have seen papers on upscaling algorithms that do amazing things to old pixel art and 8 bit sprites. Is it possible to run these in real time on something like a pi?

I ask because the suggestion of using 1080p resolution or higher for this sounded silly. But then I realized maybe it's not.

It's definitely possible to run something like hq3x in real time, and many emulators support that, though I'm not sure if RetroPie specifically makes it easy to configure that stuff. Though I'd argue that algorithmically smoothing out low res art frequently makes it look worse than the source material.

The various hqxx algorithms are still there, personally I don't like the look of them, but what's advanced a lot in recent times is TV emulation. A programmer called blargg has released several NTSC filters which really make games look how they did when you first played them, how they were intended to. They've been integrated into many emulators.

Have a look at the screenshots, to me they look way more attractive than traditional hq-style upscaling filters.


On the other hand, for anyone who grew up in a PAL region, these screenshots look appalling. They look nothing at all like my SNES (which I still keep connected to an old CRT TV.)

Yes, some emulators even allow for swapping in higher res assets. I know Dolphin in particular can do this.

Also an option in famous N64 games, they have fan produced higher res texture sets.

There are a lot of CRT emulation modes available, I am not sure if the fancy "enhanced detail" pixel up scaling modes are supported but I would be surprised if they are not at least for the more popular Nintendo emulators.

It says here https://en.m.wikipedia.org/wiki/Hqx used in nestopia which is included in RetroPie, so I am thinking yes.

One thing that's missing from a lot of arcade cab builds is that old games often don't run at a 60Hz refresh rate, and so you get a strange jittery effect as it has to skip or duplicate frames to display at 60Hz on normal LCD monitors.

FreeSync/G-Sync makes a tremendous difference, but unfortunately does this to the price as well :(

Edit: Or you can use a CRT :)

This is very neat. I want to have one, but don't want to have to assemble it. Any ideas about where I can buy one already assembled? (I wouldn't mind, say, paying a 20% surcharge over the prices mentioned in the article).


It's a joystick or a joystick+cabinet you plug a computer into, you could plug a pi into it no problem. Or a more powerful computer. They sell one that has no display, and you push it up in front of the TV when you want to play and stash it away when you don't.

The joysticks are cheap but the cabinets arent. Plugs right into USB though, easy.

I'll do it for you for the extra 20%

While I think its true that the rPi has been good for arcade emulation as a social phenomenon - i.e. the market has expanded drastically - I think its disingenuous to think of the rPi as the main driver behind emulation becoming mainstream. Devices such as the GP2X, Caanoo, GPH Wiz and Open Pandora gaming consoles have contributed immensely to the subject of game emulation, and these systems have been around far longer than the rPi - which did indeed benefit from all the work done to make emulation work on these machines previously (they use a similar class of device) ..

I know for sure that dynamic recompilation, which is key to the way emulators gain the performance needed to run on these small machines, was well and truly happening in the scene before the rPi came along.

In my opinion, the rPi just delivered the last 5% of the missing equation: cheap, broad availability.

Great article, but the tips about putting the Pi in a case and using heatsinks seem at odds with each other - especially if the Pi is going to be safely tucked away from danger inside some form of arcade cabinet. I just used self-adhesive PCB risers with mine and stuck it to the inside of the cab.

Now that I have had more time to mess with my Pis, you have a point. It's a solid 3 watts under load, when overclocking a bit more. I recommend a 20x20x15mm heatsink, and probably open air (I removed the top half of the case) too.

The little heat sinks the cases bundle are better than nothing, for sure, but get uncomfortable to touch under extended load. A bit more here


I love my Raspberry Pi.

A few months ago, I started a project to convert my dad's barely used iCade cabinet [1] into a full-fledged RetroPie cabinet.

I used a GPIO-to-USB converter (which allowed me to easily interact with the buttons and joystick on my Raspberry Pi), a speaker with a 3.5mm line-out, and a 7-inch screen I got off of Amazon.

Here's a video of it in action: https://youtu.be/EiNI2vXAomg

[1] http://www.ionaudio.com/products/details/icade

I guess it depends on what you consider good enough. I use my gaming PC to emulate and because it lets me use more accurate emulators and allows me to configure them to my liking. Output the video to a CRT video monitor and it's a fantastic authentic experience with liberties I could only dream of as a child. Heck, I don't even get the frame drops that are present on original hardware.

Heck, I don't even get the frame drops that are present on original hardware.

I hate that. It makes everything look too smooth and artificial. Frame drops are essential to the retro gaming experience. Try comparing the original release of Shadow of the Colossus with its HD remake. It just isn't the same without the frame drops, rendering jank, and texture and geometry pop-in.

The same goes for any modern "8 bit" "retro game" that doesn't start flickering or dropping sprites when the sprites-per-scanline limit is exceeded.

Does any RPi emulator do the nice slightly convex CRT emulation with scanlines, colour bleeding etc?

For me this is a big part of it. The game art is designed for these effects, and it kind of breaks the illusion if this isn't right (in a similar way to low FPS or delayed sound).

Yes, see https://www.youtube.com/watch?v=SCqQ7ciCHcI for a demo! Check out the actual video simulation for the games. The bezels are nice too :)


This advice on displays made me laugh:

> Absolutely go as big as you can in the allowed form factor, though the Pi won't effectively use much more than a 1080p display maximum.

See, I just used a RetroPi to test a new tv, and the games I reached for were very low res and extremely pixelated.

While the old emulated games have low resolution, there is support for various postprocessing options. There are many shaders that can be used to improve the experience and these are run at a higher resolution.

The raspberry pis aren't fast enough for running the more advanced shaders in 1080@60Hz, but many simpler ones work well.

What about the new Pi 3B? I know the 2B isn't fast enough for 1080@60, but is the 3B any better?

3B has pretty much the same GPU (it might be upclocked), so shaders won't work much better.

ARM really improved memory bandwidth from the A7 to A53 uncore bits, which probably helps as much as the CPU speed bumps... at the cost of it running quite a bit hotter.

I read an Anandtech article where they compared Samsung arm32 to arm64 chips, and the benchmark differences were actually quite similar to Pi2->3.

I wonder what affiliate links Jeff Atwood is shilling this time.

Rasberry Pi are slow as hell and don't emulate recent consoles.

"Why Perfect Hardware SNES Emulation Requires a 3GHz CPU" http://www.tested.com/tech/gaming/2712-why-perfect-hardware-...

That's "accurately timed emulation", it's still emulation, not simulation. Do you know the difference?

You can buy the latest greatest 18 core Xeon and some SLI GTX 1080s and still not be able to emulate PS3... even if it's fast enough there's no emulator that works. Does that mean there's no point in owning a computer at all since it can't even emulate PS3, a gasp last-gen console! It's not even current!

That's sort of like saying a car that can't tow the space shuttle is worthless. What a pointless thing to say. The pi also can't play The Witcher 3 in 4K VR. So? We still want to play Mario and Sonic and a million arcade games and TurboGrafx roms and dosbox.

Case in point: I run PCSX2 on my computer running a third gen Intel CPU with a GTX 950 and have to resort to quite a few hacks just to get the game to run at a "measly" 45 fps or so. What's "great" is that the game is designed to run at 60 fps. The timers in the game are all based on a second being 60 frames. So, despite having a good enough frame rate, the game runs at anywhere from 2/3 to 3/4 of the original speed I remember it being.

From early on in the article:

"The casual gamer who only plays the most popular twenty or so titles will see no visible differences between an emulator requiring 300MHz and another requiring 3GHz, so they will of course go with the former. Although I do respect and appreciate speed-oriented emulators, one concerned with accuracy can't help but lament the way this approach stalls progress."

I'd say that about sums the situation up. For the vast majority of people who just want to revisit some classics, low-fi emulation plus workarounds - the kind of emulation you'll get on an rpi - is just dandy. For purists, though, that might might not be good enough.

Meh. You do you, and I'll do me.

I'd argue purist gamers aren't emulating at all. The super accurate emulators really target a very small audience. If you're really into old games, then nothing can replace the actual hardware. And nowadays you can easily use an SD based flash cart to get the main plus of emulation: download any game you want off the internet.

Perfect is the enemy of good.

Sure, you won't get 100% game coverage, but you'll be able to play most games.

> Rasberry Pi are slow as hell and don't emulate recent consoles.

Yes, but there's a bunch of old titles which are still worth playing. The video games scene did not wait until the 2000s to be interesting.

They do a real good job on anything in the 16-bit generation (SNES, Genesis), and handhelds up to the DS, at least in my experience.

I'm not playing anything twitchier than ChronoTrigger, though. I use my Pi to play RPGs, primarily, although I've haven't seen any problems playing Genesis fighting games like Mortal Kombat or Street Fighter.

That pretty much covers most retro games I'd be interested in, tbh. For me, what needs improvement is controller detection and (re)configuration.

Use Lakka instead of Retropie. 360 and PS3 controllers work great (plugged in—Bluetooth remains, as in most applications other than actual game consoles, a flaky PITA from what I've seen). I find the 360's dpad and face buttons unacceptable for retro games, but some people are OK with it. PS3 controller's pretty good. You shouldn't ever have a reason to mess with the mappings for either of those under Lakka unless you disagree with the defaults (unlikely, except maybe in MAME or something). Bonus for the PS3 controller is that the Playstation button works to kick you back to Lakka's menu, while IIRC the 360's system button doesn't (not accessible as an ordinary input), so it saves you having to use a button combo for that.

Lakka boots into Retroarch, which provides a unified I/O API to the "cores" (emulators) compiled against it. Even if you do manually map, you should only have to do it once.

I bought 4 madcatz fight pads a few years ago for the purpose of retro gaming (360 usb interface), single dpad with 2x3 buttons on top, and two shoulder buttons... great layout for retro gaming. Since genesis and snes layout is a subset in both cases. I tried a couple of the retropad (sega saturn layout), but they were really cheaply built and didn't work or last long.

Spent a few hours last night playing with retroarch on windows, though will have to change to config per core, so that the layout is correct in the different cores.

Pi 3 can play most N64 titles, definitely the famous well emulated ones, and some PSX and Dreamcast as well. The perf jump from Pi 1 to Pi 2 to Pi 3 was large!

Most emulation is based on approximation, and while getting super accurate emulation is important from a preservationist standpoint, the reality of the situation is that these less accurate emulators work fine for the purpose of playing old games for entertainment

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact