Raspberry Pi Full Size Cab w\Arcade Monitor

[CoryBee]

Worth the read 

http://arrifana.org/blog/2012/12/connection-a-raspberry-pi-to-an-old-15khz-arcade-monitor/

[yaksplat]

That's what I like to see.

Has anyone found the extent of what games will run on the PI?

[CoryBee]

That's what I like to see.

Has anyone found the extent of what games will run on the PI?

They mention this.....

A lot of roms work at full speed including great games like Shinobi, Megaman, Pang, R-Type, DoDonPachi, Bubble Bobble and many others.

But I would like to see a video of DoDonPachi on this "overclocked" piece of pie

[Jumpman64]

Interesting!  I especially liked where he said it was also running C64 & Amiga games full screen

[WindDrake]

If I ever build a multi-game lowboy, I think I'll look into this.

[kahlid74]

A lot of roms work at full speed including great games like Shinobi, Megaman, Pang, R-Type, DoDonPachi, Bubble Bobble and many others. This was accomplished by a combination of overcooking, Advance Mame compilation and optimization options, sound settings, optimal screen resolutions, and a lot of configuration tweaks.

Out of the box, the Pi will run a few games at good speed but a majority of them will run at an unplayable speed.  Boosting the Pi to ~900 is where the biggest bang for the buck is achieved.  The issue with this primarily is that you effectively shrink the lifespan of your Pi by doing this.  Just something to consider.

Another guy and I both posted threads on this before as far as how applicable the Pi is to arcade gaming.

[404]

That's what I like to see.

Has anyone found the extent of what games will run on the PI?

Let's put it this way. Most people can't play street fighter II on a pi without overclocking and still have slowdown issues. Essentially you can kiss most of your 90's era gameplay goodbye.

[yaksplat]

Perhaps a future Raspberry Pi II?

[paigeoliver]

Or just stick a dumpster PC in the bottom of the cabinet, save money by not buying the pi or the additional hardware they needed to buy in order to use the pi and have way better functionality and no framerate problems and maybe the games might actually fill up the whole screen then too.

Just because you can do something doesn't mean it makes any sense to do it.

[Nephasth]

Just because you can do something doesn't mean it makes any sense to do it.

I thought this same thing when I saw your Joust.

[CoryBee]

Just because you can do something doesn't mean it makes any sense to do it.

I thought this same thing when I saw your Joust.

[404]

Perhaps a future Raspberry Pi II?

developers are better off forking mame and optimizing the codebase for arm; something i personally don't see anyone doing simply because of the sheer amount of work it would involved in the original mame codebase and the sheer amount of work it would take to port to an already underpowered platform. You also have to take into account that most of the builds out there are basically advancemame which runs on the old, faster rendering base to begin with. One can only imagine how slow a bare bones port of modern mame would run like on the pi.

[Haze]

Perhaps a future Raspberry Pi II?

developers are better off forking mame and optimizing the codebase for arm; something i personally don't see anyone doing simply because of the sheer amount of work it would involved in the original mame codebase and the sheer amount of work it would take to port to an already underpowered platform. You also have to take into account that most of the builds out there are basically advancemame which runs on the old, faster rendering base to begin with. One can only imagine how slow a bare bones port of modern mame would run like on the pi.

Emulation is inherently cpu expensive, the pi doesn't have a good cpu.

Sure you can cut back on the emulation quality (or use old versions and effectively do the same) but there are very few *free* optimizations, speed is about compromise.

If you simplify codepaths you make the cores less functional, if you duplicate cores with only the functionality each game / hardware type needs you end up with an unmaintainable mess of copy+pasted+hacked code.

If you start to simulate cpus instead of emulate them you're starting to rewrite / port the game moreso than emulate it, which can work for a handful of games, but isn't really practical.

Hardware as weak as the pi simply isn't designed for something as open-ended and flexible as Mame where the project has been designed with future development in mind rather than something you can abandon once it ships.  The reason existing forks ended up dead in the water and unable to integrate any improvements is simply that, they'd forked and optimized themselves into a corner where making any actual improvements was impossible.

As already said, just because you CAN use a Pi for this, with some old version of Mame, which probably pre-dates Bubble Bobble having an accurate protection emulation and countless other things doesn't mean it's actually a good idea to do so and you're unlikely to find a single actual Mame developer who thinks it's even remotely a good idea.

[Grasshopper]

I've read Aaron Giles' justification for MAME's (sometimes quite dramatic) slowdowns over the years (link), and I've got two thoughts:

The first is that the slowdown problem could largely be eliminated by redesigning MAME to allow for the use of different plug in drivers. Users would then be free to choose between newer drivers that were more accurate but slower, or older drivers that were less accurate but generally faster. They could also choose a driver that offered an "optimisation point" for the games they actually wanted to play. For example, if you're building a Pac Man cab then you're not going to be interested in a version of MAME that has been optimised to play games from the late 80s, or later.

My second point is that I'm beginning to question the wisdom of MAME consisting of one monolithic bloated executable that can play (almost) all games from the late 70s to the present day. I wonder whether the original MAME Devs ever imagined that MAME would be expanded to the point where it could emulate 3d vector games. I haven't examined the source, but judging from Aaron's comments, I get the distinct impression that this monolithic approach now involves too many compromises being made. Perhaps the time has come for MAME to be split up in some way. For example by processor type , 8 bit era vs 16 bit, 2d sprite based vs 3d vector, etc. Each version of MAME could then be optimised for its own particular era of games.

[Haze]

I've read Aaron Giles' justification for MAME's (sometimes quite dramatic) slowdowns over the years (link), and I've got two thoughts:

The first is that the slowdown problem could largely be eliminated by redesigning MAME to allow for the use of different plug in drivers. Users would then be free to choose between newer drivers that were more accurate but slower, or older drivers that were less accurate but generally faster. They could also choose a driver that offered an "optimisation point" for the games they actually wanted to play. For example, if you're building a Pac Man cab then you're not going to be interested in a version of MAME that has been optimised to play games from the late 80s, or later.

My second point is that I'm beginning to question the wisdom of MAME consisting of one monolithic bloated executable that can play (almost) all games from the late 70s to the present day. I wonder whether the original MAME Devs ever imagined that MAME would be expanded to the point where it could emulate 3d vector games. I haven't examined the source, but judging from Aaron's comments, I get the distinct impression that this monolithic approach now involves too many compromises being made. Perhaps the time has come for MAME to be split up in some way. For example by processor type , 8 bit era vs 16 bit, 2d sprite based vs 3d vector, etc. Each version of MAME could then be optimised for its own particular era of games.

You're looking at it from the wrong angle.

A plug-in system would solve *nothing* all you'd get were broken incompatibilities and users moaning because a driver from a 5 year old verson didn't run with the current version.

There is no benefit to splitting things up.  It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.

The monolithic approach has been hugely beneficial to MAME in terms of making sure everybody working on MAME knows they have to write usable, CORRECT code, not code so limited in scope that it only works with one system.  Of course, that still happened, and one of the biggest jobs in MAME can be cleaning up such instances so they use a common correct implementation.

There is also no logical way to split things up, components, cpus etc. are shared across generations of platforms, one of the reasons Ville has had a lot of success with Konami 3D stuff is because the 2D side of it is almost entirely inherited from the previous generation of systems etc.

Unless you want to maintain a whole bunch of single game emulators, where improvements made in one place CAN'T benefit or affect drivers elsewhere unless you manually port said improvements to every driver then there really is no other way, and MAME would have died a LONG time ago if it was just a collection of single game emulators.  The more software, platforms and systems a core can run *without hacks* the more confident you can be that your emulation is actually good, and not just something which conveniently works for one use case.  When you're trying to provide a reference model, and something people can reuse with confidence to emulate any platform they want then that trust and confidence in the quality of the components is important.

Users tend to see things as much more simple than they actually are, this only gives further evidence to why a plug-in system would be *bad* because said users would attempt to mix and match all sorts of incompatible versions and just expect them to work, then report bugs without even beginning to consider that the 'super turbo 10 year old 68k core' they used might actually be to blame for random crashing in a game even if they're using the latest game driver.

We've seen other emus do plugin systems, and they've been without exception an unholy confusing mess.  Mame either works, or it doesn't.

[Grasshopper]

There is no benefit to splitting things up.  It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.

You're contradicting what Aaron says in his blog. According to him the slowdown is not just being caused by improved accuracy. He talks about an "optimisation point" which implies that the performance of older games is slowly being sacrificed so that code can be optimised (and simplified) for newer games. That implies to me that splitting up MAME would be beneficial for many games. Of course there's going to be some overlap between different eras. But that sounds to me more like an excuse than a reason. You're not going to convince me that Pac Man's code has much in common with Dead or Alive 2's code, even though both games are supported by MAME.

You also choose to make what I believe is a false distinction between a "driver" and a "core". I don't get that. Why can't you offer different plug in cores as well? Wasn't the whole point of re-writing the code in C++ to make it more modular?

Be honest now. The real issue is that you, and presumably most of the other current developers, just don't place any real value on execution speed. You're obviously free to develop the project in any way you see fit (just as others are free to fork it) but I personally think that ignoring performance is a big mistake. However fast processors get, they'll always be a range of different hardware out there, and many people like to re-use old computers for emulation purposes.

[Haze]

There is no benefit to splitting things up.  It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.

You're contradicting what Aaron says in his blog. According to him the slowdown is not just being caused by improved accuracy. He talks about an "optimisation point" which implies that the performance of older games is slowly being sacrificed so that code can be optimised (and simplified) for newer games. That implies to me that splitting up MAME would be beneficial for many games. Of course there's going to be some overlap between different eras. But that sounds to me more like an excuse than a reason. You're not going to convince me that Pac Man's code has much in common with Dead or Alive 2's code, even though both games are supported by MAME.

You also choose to make what I believe is a false distinction between a "driver" and a "core". I don't get that. Why can't you offer different plug in cores as well? Wasn't the whole point of re-writing the code in C++ to make it more modular?

Be honest now. The real issue is that you, and presumably most of the other current developers, just don't place any real value on execution speed. You're obviously free to develop the project in any way you see fit (just as others are free to fork it) but I personally think that ignoring performance is a big mistake. However fast processors get, they'll always be a range of different hardware out there, and many people like to re-use old computers for emulation purposes.

The optimization point applies to drivers and the core, the optimization point of the core moves to make driver development easier.

Old drivers had a lot of legacy cruft, dirty rectangle marking, manual timer handling, palette marking to squeeze things into 8-bit colours, code to manually do rotation.

Work like that, over time got removed/made unnecessary or moved to the Mame core, to make driver development easier for more complex systems, but at the same time moved the 'optimization point'

When it comes to programming MAME that makes things a lot easier, you can just get on with things, you can focus on EMULATING not coming up with a million and one ways to compensate for missing core functionality and limitations.

It also means you can't just mix and match old core versions with new drivers versions, it wouldn't work.  You can't just take the CPS3 driver and shove it in old versions, because it doesn't have a bunch of hacks to do palette marking etc.  (not to mention the SH2 core didn't exist in 0.3x, and you can't just backport the SH2 core to 0.3x because the recompilation engine didn't exist, and if you backport the interpreter it will be much slower anyway, and not work because the 0.3x framework has no timer system, everything had to do it manually back then, while the core instead relies on the timers..)  The same is true of everything else. legacy stuff tends to depend on legacy framework principals, modern stuff on modern principals but it's not black and white.

There is the MAME core, or rather framework, and then there are CPU cores, sound Cores etc. which would better be referred to as devices, then there are the drivers.

CPU Cores, Sound Cores, Video Cores tend to be used by a lot of game drivers.

The C++ stuff makes it more modular, yes, but that still doesn't mean you can just mix and match, for example the 6502 was just rewritten to be cycle accurate, because most drivers made assumptions before that it wasn't they too had to be updated inline with the new core because some things in them were wrong before.  You couldn't just mix the old / new 6502 with old/new drivers, it wouldn't work.

Sure Pacman might not share much directly with Dead or Alive, but it's code, running on a CPU, the concepts of memory maps, video updates etc. is just the same.  If you understand how one thing works it's easy to get a grasp on how the other works because of how MAME is coded, if you know how to use the debugger with one, you know how to use it with the other etc.  Splitting them wouldn't give any benefit at all.

Going back to the 6502, that's one case where you are going to see a performance decrease, and yes, only a marginal number of systems actually NEED a cycle accurate 6502, but of course, it's still progress, and Mamedev aren't going to decide to maintain 2 versions of the CPU core, and have to apply bug fixes to 2 versions of the CPU core, we go with the most accurate one and that's the only sane way to go.

As I said, we've seen emulators with plug-in systems, where you need an exact balance of various components to run specific games, it's a mess, it gives people and little incentive to actually emulate something properly when they can come up with a quickly hacked pluggable core.   The very thought of Mame doing something like that is horrifying.

[lettuce]

Its just a damn shame that the Raspberry Pi doesnt have pins on the pcb for , R,G,B, Sync, ground, and 9v+ so we could just make a harness up and connect it straight to a monitor or CRT display for RGB goodness. Would this be to much of an architecture change for such an idea to be added in a later revision of the Raspberry Pi, and maybe it could replace the crappy composhite connection!??? And may as an added bouns for it to be able to output a 15khz signal...but i think that might be asking to much of it!?

[ark_ader]

There is no benefit to splitting things up.  It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.

You're contradicting what Aaron says in his blog. According to him the slowdown is not just being caused by improved accuracy. He talks about an "optimisation point" which implies that the performance of older games is slowly being sacrificed so that code can be optimised (and simplified) for newer games. That implies to me that splitting up MAME would be beneficial for many games. Of course there's going to be some overlap between different eras. But that sounds to me more like an excuse than a reason. You're not going to convince me that Pac Man's code has much in common with Dead or Alive 2's code, even though both games are supported by MAME.

You also choose to make what I believe is a false distinction between a "driver" and a "core". I don't get that. Why can't you offer different plug in cores as well? Wasn't the whole point of re-writing the code in C++ to make it more modular?

Be honest now. The real issue is that you, and presumably most of the other current developers, just don't place any real value on execution speed. You're obviously free to develop the project in any way you see fit (just as others are free to fork it) but I personally think that ignoring performance is a big mistake. However fast processors get, they'll always be a range of different hardware out there, and many people like to re-use old computers for emulation purposes.

The Raspi is for students who cannot afford a PC but can afford a DVI-D or HDMI monitor or maybe Dad's TV to learn how to program.  Yes it can play UT3, XBMC and hopefully ICS but that is about it.  In no way is the $25 little guy is going to play a decent MAME build and we are not surprised that it doesn't.

It is pointless to argue that MAME is bloat to an ex MAMEdev Coordinator (yet you do make a good point) and not optimised in assembler.  But it is bunch of guys investing the time to create something we like to fire up every Christmas or when the other half is out with her girlfriends.  Odds are that we already have the hardware covered, on your xbox1 or phone, even trying to suggest anything different is a complete waste of time. 

My Raspi has been through every conceivable build out there including Android, and we have settled on Bodhi.  It looks nice, boots up fast and I can run Drupal on it.   

[paigeoliver]

I fail to see how an obscure geek toy that can't be purchased in a store, must be ordered off the internet and that requires a PC and extensive computer knowledge just to set up can in any way be targeted at impoverished students who can't afford a computer. I am pretty certain that almost none of them are being used that way and almost all of them are being used for little tricks like making them run mame. Pi makes no sense as a PC, you can pick a better PC out of the trash.

There is no benefit to splitting things up.  It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.

You're contradicting what Aaron says in his blog. According to him the slowdown is not just being caused by improved accuracy. He talks about an "optimisation point" which implies that the performance of older games is slowly being sacrificed so that code can be optimised (and simplified) for newer games. That implies to me that splitting up MAME would be beneficial for many games. Of course there's going to be some overlap between different eras. But that sounds to me more like an excuse than a reason. You're not going to convince me that Pac Man's code has much in common with Dead or Alive 2's code, even though both games are supported by MAME.

You also choose to make what I believe is a false distinction between a "driver" and a "core". I don't get that. Why can't you offer different plug in cores as well? Wasn't the whole point of re-writing the code in C++ to make it more modular?

Be honest now. The real issue is that you, and presumably most of the other current developers, just don't place any real value on execution speed. You're obviously free to develop the project in any way you see fit (just as others are free to fork it) but I personally think that ignoring performance is a big mistake. However fast processors get, they'll always be a range of different hardware out there, and many people like to re-use old computers for emulation purposes.

The Raspi is for students who cannot afford a PC but can afford a DVI-D or HDMI monitor or maybe Dad's TV to learn how to program.  Yes it can play UT3, XBMC and hopefully ICS but that is about it.  In no way is the $25 little guy is going to play a decent MAME build and we are not surprised that it doesn't.

It is pointless to argue that MAME is bloat to an ex MAMEdev Coordinator (yet you do make a good point) and not optimised in assembler.  But it is bunch of guys investing the time to create something we like to fire up every Christmas or when the other half is out with her girlfriends.  Odds are that we already have the hardware covered, on your xbox1 or phone, even trying to suggest anything different is a complete waste of time. 

My Raspi has been through every conceivable build out there including Android, and we have settled on Bodhi.  It looks nice, boots up fast and I can run Drupal on it.   

[lettuce]

Just reading up a bit more on the Raspberry Pi and notice this in the FAQ section...

"What display can I use?

There is composite and HDMI out on the board, so you can hook it up to an old analogue TV, to a digital TV or to a DVI monitor (using a cheap adapter for the DVI). There is no VGA support, but adaptors are available, although these are relatively expensive.

Why is there no VGA support?

The chip specifically supports HDMI. VGA is considered to be an end-of-life technology, so supporting it doesn’t fit with our plans at the moment."

They say that VGA is end of life tech yet they include a composite socket, VGA option is ALOT more versatile than just a signal composite socket not to mention Superior video quality, you can get VGA to Scart, VGA to VGA, VGA to CGA, VGA to DVI etc cables so i cant understand for the life of me why they have decided to leave out a basic connection type as VGA. Hopefully revision C will include at least pins or solder points on the PCB where you can get an R,G,B and sync signal from.