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...
It works great for NES/SNES emulation, and even N64 emulation with an appropriate video plugin.
Snes9x is written in C++, IIRC. As is MESS' snes emulator.
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.
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.)
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.
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.
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 also going to use an HDMI switcher so that I can connect it to a faster machine like my laptop as an option.
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 tried the retropie about a year ago on my Pi2 and there were no issues at all. Sega Genesis/Megadrive worked well too.
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 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...)
That said it is an interesting aside and there are a few more details here http://www.mameworld.info/ubbthreads/showflat.php?Number=305...
Besides which, I thought the particular way CRTs blur and ghost was part of the appeal?
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.
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.
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.
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
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.
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.
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:
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.
¹ — https://www.arduboy.com/store/products/arduboy
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?
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.
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.)
...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."
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.
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 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.
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.
At least, that is how it is in the Netherlands.
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.
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.
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.
 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'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.
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.
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.
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.
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).
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.
I ask because the suggestion of using 1080p resolution or higher for this sounded silly. But then I realized maybe it's not.
Have a look at the screenshots, to me they look way more attractive than traditional hq-style upscaling filters.
It says here https://en.m.wikipedia.org/wiki/Hqx used in nestopia which is included in RetroPie, so I am thinking yes.
FreeSync/G-Sync makes a tremendous difference, but unfortunately does this to the price as well :(
Edit: Or you can use a CRT :)
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 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.
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
A few months ago, I started a project to convert my dad's barely used iCade cabinet  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
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.
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).
> 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.
The raspberry pis aren't fast enough for running the more advanced shaders in 1080@60Hz, but many simpler ones work well.
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.
"Why Perfect Hardware SNES Emulation Requires a 3GHz CPU"
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.
"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.
Sure, you won't get 100% game coverage, but you'll be able to play most games.
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.
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.
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.
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.