Retro Gaming With Raspberry Pi 106
coop0030 writes "Thanks to the affordable Raspberry Pi and some clever software, anyone can re-create the classic arcade experience at home. Adafruit brings the genuine 'clicky' arcade controls, you bring the game files and a little crafting skill to build it. Classic game emulation used to require a well-specced PC and specialized adapters for the controls, so it's exciting to see this trickle down to a $40 system. Also, a video of the game system is on YouTube."
Accurate game emulation still requires a hefty PC (Score:4, Informative)
If folks want to continue using a hacked-to-hell version of MAME from over a decade ago, or some port of a crappy old version of SNES9x that lacks all of the improvements in emulation accuracy (and the corresponding increase in CPU load) that have been discovered in that same amount of time, that's fine.
However, let's not be ignorant and claim that these old-ass emulators being ported to the Pi are in any way as accurate as modern versions of MAME, or bsnes, or Nestopia, yeah?
Re:Accurate game emulation still requires a hefty (Score:5, Informative)
For Those that lack Woodwork skill/tools.. (Score:4, Informative)
I built a MAME cabinet from a pre-fab unit from Rec Room Masters https://www.recroommasters.com/ [recroommasters.com] for my wife as a Christmas present. It was very easy to assemble (just bolts which are provided) To this shell, you add a controller (Tankstick) from X-Arcade http://www.xgaming.com/ [xgaming.com] . Lastly you add a monitor, computer, drive space for ROMS and speakers. I spent some extra for side arcade art and illuminated Marquee. As a front end for selecting games, I use Hyperspin http://hyperspin-fe.com/ [hyperspin-fe.com] . It's an amazing machine and is pretty affordable, especially if the Raspberry Pi can run the games.. My wife and I have spent countless hours on this. I also grabbed ROMS for almost every older home console ever made and play them on this as well..
I don't have the tools, space and skills required to build a cabinet from scratch. The hardest part is finding the ROMS which work with the MAME version that you use.
Use RPI Chameleon for retro gaming!! (Score:4, Informative)
Skip all the Raspbian instructions. Instead, use the RPI Chameleon distribution for retro gaming on the Pi. Users are presented with a nice console-style menu screen after the system powers on with a ton of different emulators for not just consoles and arcade games but computers, too.
Check it out here: http://chameleon.enging.com/ [enging.com]
Re:Accurate game emulation still requires a hefty (Score:5, Informative)
Maybe not that powerful, but close.
Because the weaker the console, the more performance it takes to do it accurately. The best way to do it is a cycle-accurate emulation because a lot of code written in those days took advantage of oddball features and oddball timings to work properly. For a "dumb" emulation like MAME, most of the time it works, but some games don't work requiring various patches and such in order to settle down the game.
It's not just the CPU, but also the timing of the other chips, and often things happen within a clock cycle as well that gets taken advantage of.
It's why emulators like bsnes require specs close to your PC, but run games basically perfectly with no hacks or patches required to get them to work.
The need for cycle accurate simulations ended sometime in the PS2 era - before which things like the PSX often made such cycle timing tricks necessary. Especially since the modern processor is superscalar, has caches everywhere and is heavily pipelined, making cycle counting impossible (especially caches since it made memory access timing unpredictable).
Heck, that still doesn't rule out the possibility some game took advantage of the way the system hardware glitched, requiring not just cycle accuracy, but behavior accuracy as well - perhaps some instruction caused some data line to glitch which caused RAM to gitch and it achieved the desired effect.
Re:Accurate game emulation still requires a hefty (Score:4, Informative)
The GPU of the Pi is as powerful as the GPU of the original XBox. The CPU, however, is as fast as a Pentium II (I forget what MHz rating).
The GPU has all sorts of issues though, namely due to the crappy binary only drivers (ugh, yeah, even the Pi has that problem). The Pi uses a broadcom SOC while the Xbox uses a weird nVidia card that Linux never really supported quite right with any drivers.
The CPU on the Pi clocks to 700 mhz but can easily be overclocked. Running at 800 mhz rarely causes problems. Running up to 1 Ghz may cause issues occasionally if you've got a weak USB power charger but the Pi will perform surprisingly well for lightweight task at 1 GHz. By contrast, the original Xbox had a 733 mhz CPU. Remember though, the Pi uses an ARM chip while the Xbox used a custom CPU that was sort of a cross between a Celeron and a Pentium III.
The Pi has a few other features the Xbox lacked. It uses USB 2.0 while the Xbox used USB 1.1 (the controllers were basically modified 1.1 ports. You could easily splice controller cables and USB extension cables together and if you plugged flash drives in the Xbox saw them as memory cards). The Pi also sports HDMI. The Xbox only had 64 MB of RAM while the Pi has 512 MB.
Re:Accurate game emulation still requires a hefty (Score:4, Informative)
p>Because the weaker the console, the more performance it takes to do it accurately.
That's a misrepresentation of the truth.
What you're referring to is the culture of "hacky" code that evolved to overcome the limitations of hardware. For example, sprite multiplexing. Early graphics devices with hardware sprites had a very limited number on-screen - on a business system, there might only be one for the mouse pointer. In order to overcome these limits, programmers would use raster interrupts to track the screen refresh and switch out the sprite banks so that they could draw the full limit of sprites in the top section of the screen, and then the full limit again below; doubling, tripling or quadrupling the number of available sprites. This means that the emulator has to do cycle-exact graphics, whereas a system with unlimited sprites (whether in hardware or software) doesn't need to have any notion of a moving cathode-ray beam to follow.
The more advanced the hardware, the less likely that software interfaces with the hardware as bare metal, instead relying on APIs that abstract it out, making hardware-specific timing often unnecessary.