Raspberry Pi MAME Arcade Project

[crippledlemming]

I posted some of this in another thread, but as I am doing this as a project, I thought a new thread is in order.

I am beginning a new project, I would like to end up with something similar to:



Except with a set of controls on each side of the table with a discrete display for each player that is mirroring the output from my Raspberry Pi.  This way it wont be too crowded on my couch when I want to play heads up against a buddy.


Phase I:

Setup Raspberry Pi

Get OS on Raspberry Pi

Get MAME emulator compiled and running

Verify ROMS will run

? Overclock Raspberry Pi

Get frontend for MAME and verify compatibility

Use keyboard to extensively test games

Phase II:

Get USB keyboard interface for controls

Get Joystick and buttons for the arcade

Wire up controls

Get USB keyboard interface to work with Debian

Test with MAME games

Phase III:

Find / Build coffee table to house setup

Flush mount monitor / controls

Wire everything up in new enclosure

Enjoy new MAME arcade

[crippledlemming]

At first I didn't realize that you have to install an image to the SD card.  This caused some confusion as I could not get the board to do anything other than light up a bit.  I tried using diskutil on my macbook air to flash the Debian image to the SD card last night, but I don't think it was successful since the Raspberry Pi still won't boot.  When I get home tonight I am going to re-try flashing the SD card.  Will keep y'all posted.

[crippledlemming]

So it looked like the img of Debian for Raspberry Pi didn't properly transfer to my SD card, when in fact it was just taking forever.  When I got home from work today and began work on the project again, I was pleasantly surprised to see that the RPI would actually boot from the card:



I am quite surprised with how quick this little credit card sized computer is.  Upon first boot the RPI booted into a setup program:



After setting my environment variables, disabling graphical interface start-up, running updates, and rebooting I was presented with a fully functional Debian powered beast.  The next order of business was getting a MAME emulator up and running on this ARM platform.  A quick check of the GCC and compiler environments and another pleasant surprise; they were already in place with all the required dependencies for me to be off and running.   As an aside, I was very impressed with the network transfer speed as well.  This little computer was consistently averaging 2.3 mbps from most of the locations I was downloading from online.  After wgetting advanceMAME src and compiling it, I was able to run advMAME and was able to get the Galaga ROM running with minimal issue (after setting up a proper config etc):

Unfortunately, the first run of this ROM was VERY slow and the audio was stuttering something fierce.  I had read about people overclocking these little boards with pretty good success, so back into the config files!  I settled so far on a 200MHZ overclock (up from the stock 700MHZ to 900MHZ) on the processor and a 100MHZ overclock on the memory (up to 600MHZ).  I was able to resolve the stutter and lag issues with Galaga this way and both Galaga and 1942 run flawlessly at this point:





If you've played with advMAME or a command line based MAME emulator at all then you know launching a game involves something like: ./advMAME galaga, this is not very user friendly at all and would be a huge hassle once I have this in an arcade cabinet (since this computer will run without a keyboard).  Luckily there are MAME front ends that I can utilize that will facilitate launching games etc.  Back out to the internet with a wget command yielded advMenu's src.  After compiling and installing advMENU I had a bear of a time getting it to recognize  that I had advMAME installed as an emulator.  I ended up having to manually add it to advMENU's config.  The result was a half working advMENU:



Yes the menu is working and it launches the ROMs, but it doesn't give a preview or artwork or anything in the right hand pane for the ROM.  I think this is due to missing files from unzipping the ROMs.  When I get home tonight my next round of work will center around making this look more acceptable.  The other good news about transitioning into phase II of this project is that I have two joysticks, buttons, wire, etc on order for the cabinet.  I am still unsure which direction I want to take the cabinet, but am currently leaning more towards a full sized cabinet than the original coffee table idea.  I will have to give it quite a bit more thought and figure it out before ordering graphics etc.  Stay tuned for phase II goodness!

[crippledlemming]

Got the iPac working with the Raspberry MAME last night.  Also got the ipacutil and ipacgui working with the Rasp-Debian as well.  What a PITA though, I was lost in dependencies hell for a short while.  As you can see in the video low horse power requiring ROMS the twin monitor setup for my coffee table idea seem to work just fine, but when I load a ROM that requires more horse power the left screen seems to flicker a bit.  I'll have to sort that out.  This project is getting very close to the needs an enclosure stage...

[pinballjim]

Why not use a VGA splitter if you're just mirroring the same output to both displays?

[crippledlemming]

The Raspberry Pi does not offer VGA out:



I'm using a HDMI to DVI adapter into a sinlge link dual DVI adapter.  I think the issue is with the power running through the Pi not with the horsepower of the Pi.  I'm going to try an upgraded power supply for the Pi tonight when I get home.  I am currently using a 750mA adapter, and people who have been overclocking the Pi are recommending a 1000mA or greater supply.

[Haze]

are you saying these things struggle to run Galaga without overclocking even when using a relatively ancient build like AdvanceMAME? or are you using a current build which is inherently more demanding due to various improvements.

If it's the former the Pi is even worse than I imagined....

[pinballjim]

If it's the former the Pi is even worse than I imagined....

 

Just... wow. 

[crippledlemming]

I'm using current source advancemame-0.106.1 for this project.  The Pi is an ARM architecture computer vs the i386 or i686 that you may be used to.  ARM is a cheaper/low power/mobile architecture not usually used in standalone computing solutions.  It is most frequently seen in mobile phones, PDAs, and some lower end tablets.  For $25 USD the fact that it can handle any of what I've put it through impresses me.

[crippledlemming]

Why not use a VGA splitter if you're just mirroring the same output to both displays?

After doing some additional research it looks like I might run the risk of damaging my board if I continue with my current adapter:

(from the Pi forums)

Note that adapters like these who do not come with a power supply, but draw power from the PI may work, for some time, but can indeed damage the PI, as its not designed to power such devices through its HDMI port.
In particular the diode D1, near the port is designed for 200mA (and all power to the adapter runs through it) but these devices easily use double that. The power output on a HDMI port is designed only to power a small EEPROM containing the monitors specifications, and such devices draw a maximum of 50mA only.

There have been several reports from users of these devices that they have had burned out D1 Diodes.
Also using it this way may overload your power supply!

Generally speaking, either modify your PI, and use a PSU that can supply the extra 500mA, or only use adapters that come with their own power supply.

[Mysterioii]

If it's the former the Pi is even worse than I imagined....

 

Just... wow.

Well, I'm still hoping that the code just needs to be optimized for the ARM processor... and that someone else will kindly come along and do it.     Because of the form factor I'm hopeful someone will get it running well with "vintage" (80s era) games, for now I'm just hanging back and keeping an eye on things.

[Haze]

If it's the former the Pi is even worse than I imagined....

 

Just... wow.

Well I knew the performance was bad, but it's not even comparable with the last gen of smartphones which could run the classics with ease even on a modern build and the advmame builds are ancient (as in from 2006) and the ARM based arcade xxx-in-1 games run the classics with a relatively modern build too despite having lower clocks than this thing.

I'd say that puts performance somewhere on par with my old 300mhz AMD k6 based system... were all compiler optimizations turned off when building it or something?

So yes..  just... wow at the woeful performance.  I'd like to say you get what you pay for, but I'm not even sure you get that.

[ark_ader]

It is designed for kids to learn about programming or to run a simple media client.

I really do not see the point in such a project when you can easily get a £10 Xbox and decase it.   

[paigeoliver]

Indeed Haze, my first mame cabinet ran a 300 mhz processor and mame .55 and there were very few games that had issues.

If it's the former the Pi is even worse than I imagined....

 

Just... wow.

Well I knew the performance was bad, but it's not even comparable with the last gen of smartphones which could run the classics with ease even on a modern build and the advmame builds are ancient (as in from 2006) and the ARM based arcade xxx-in-1 games run the classics with a relatively modern build too despite having lower clocks than this thing.

I'd say that puts performance somewhere on par with my old 300mhz AMD k6 based system... were all compiler optimizations turned off when building it or something?

So yes..  just... wow at the woeful performance.  I'd like to say you get what you pay for, but I'm not even sure you get that.

[danny_galaga]

I'm another that's perplexed by the performance. I experimented with an old 100mhz laptop for a potential project some years ago, and I was able to run games like Space Invaders and Galaga just fine. Granted, it was a pretty early version of MAME on it but still...

[paigeoliver]

Mame has gotten continually slower over the years. Version 106 is (in my opinion) about 50 versions too new to use on weak hardware. Version .55 has always been a real favorite of mine, no major bugs in that release and it supports almost everything anyone would want to play.

I'm another that's perplexed by the performance. I experimented with an old 100mhz laptop for a potential project some years ago, and I was able to run games like Space Invaders and Galaga just fine. Granted, it was a pretty early version of MAME on it but still...

[MonMotha]

MAME is also generally only hacked on by people looking to use it on x86 type CPUs.  Even if there's no inline assembly, some of the "performance tricks" in the code may only work well on x86 and may actually hurt on ARM (there are other "tricks" that can go the other way, of course).  Note that CPU ISA makes a huge difference in the performance of MAME: some backends run much faster on AMD64 than IA-32 even on the exact same CPU due to things such as number of explicitly named registers.  If somebody wanted to hack on MAME to make it run better on ARM 1176, substantial improvements are probably possible, but I'd suspect most of the work in the "MAME on ARM" department is going to be focused on Cortex-A these days for use on modern smartphones, Beagle/Panda, etc.

Also, it'll depend on what compiler you use some.  Presumably, ARM Linux MAME is being built with GCC.  GCC's ARM backend is decent, but it's not as good as its x86 backend.  clang/LLVM may do better (or worse).  It's also possible that whoever built the build people are testing on the RasPi did something like use an old compiler or may have even had compiler level optimization disabled entirely or perhaps set for "generic ARM" which will generate pretty crap code for an ARM1176JZF.

FWIW, I'm not really fond of the SoC used on the RasPi, but it should perform OK.  It's a somewhat older pipeline arch and ISA (about one major generation behind the current Cortex-A8/A9 being used on most smartphones), but at 700MHz+, it should do OK.  Probably comparable to a 300-400MHz Pentium II.  It's lacking in the RAM and cache department, though, so you'll have to keep the working set reasonable, which should generally be possible for classics in MAME.  Combine this with the "MAME is getting slower" phenomenon, and you may have the explanation for your performance issues right there.

I guess to be clear here, it IS slower than even the "previous generation" of smartphones (single core Cortex-A8 at typically ~1GHz, roughly 1-2 years old now) by a fair bit.  It's relatively old hardware.  Figure you get what you pay for at $25; a modern smartphone costs about $200-500 and sometimes upward of $800 for high end ones (remember, they're heavily subsidized in the USA on 2-year contract).  Obviously much of that is for things not on the RasPi, but you're still an order of magnitude cheaper for the Pi.  It's a decent little dev platform, but not much more.

[Haze]

yeah, I understand the reasoning behind it all, think it's a worthwhile cause and would love to be able to recommend it (I hate the locked down culture we have with every home system aside the PC today) it's just a shame it's so inadequate.

as difficult as it is to recommend something like compiling MAME for the original XBox due to the SDK legality issues and having to hack the device to run it, it sounds like the pi offers absolutely no *real* advantages over doing so and is likely to disappoint in equal measure even if some of the slightly speedier emulators such as FBA are ported.

[MonMotha]

If you want a low power, reasonably open (arguably more so than the Pi), faster platform, you might look at the Pandaboard (especially ES model).  It's a dual core Cortex-A9 at 1.0/1.2GHz with a gig of RAM.  The 3D video is probably slower, but you don't care in this case.  It does cost quite a bit more, though (~$180), and it's somewhat bigger.  The Gumstix products are actually smaller and also available with OMAP CPUs more powerful than the one used on the Pi.  The A9 used on the Pandaboard is actually faster than most of the Atoms with a properly optimized workload at something like 1/4 the power.  It's pretty cool.  There's also a pretty fully documented DSP for you to play with, which may actually be useful for MAME acceleration (if anybody ever cared to support it).  It's normally used for audio decode and some video offload features (the GPU also handles some video offload), but it's a general purpose DSP.

The SoC used on the Pi was actually intended for media players and as such is extremely video focused.  The CPU is only there to run the OS and basic UI.  It was done by a "video processor" group at Broadcom, which explains why the GPU actually boots the thing (which is why you need a binary blob to boot it).

[danny_galaga]

MAME is also generally only hacked on by people looking to use it on x86 type CPUs.  Even if there's no inline assembly, some of the "performance tricks" in the code may only work well on x86 and may actually hurt on ARM (there are other "tricks" that can go the other way, of course).  Note that CPU ISA makes a huge difference in the performance of MAME: some backends run much faster on AMD64 than IA-32 even on the exact same CPU due to things such as number of explicitly named registers.  If somebody wanted to hack on MAME to make it run better on ARM 1176, substantial improvements are probably possible, but I'd suspect most of the work in the "MAME on ARM" department is going to be focused on Cortex-A these days for use on modern smartphones, Beagle/Panda, etc.

Also, it'll depend on what compiler you use some.  Presumably, ARM Linux MAME is being built with GCC.  GCC's ARM backend is decent, but it's not as good as its x86 backend.  clang/LLVM may do better (or worse).  It's also possible that whoever built the build people are testing on the RasPi did something like use an old compiler or may have even had compiler level optimization disabled entirely or perhaps set for "generic ARM" which will generate pretty crap code for an ARM1176JZF.

FWIW, I'm not really fond of the SoC used on the RasPi, but it should perform OK.  It's a somewhat older pipeline arch and ISA (about one major generation behind the current Cortex-A8/A9 being used on most smartphones), but at 700MHz+, it should do OK.  Probably comparable to a 300-400MHz Pentium II.  It's lacking in the RAM and cache department, though, so you'll have to keep the working set reasonable, which should generally be possible for classics in MAME.  Combine this with the "MAME is getting slower" phenomenon, and you may have the explanation for your performance issues right there.

I guess to be clear here, it IS slower than even the "previous generation" of smartphones (single core Cortex-A8 at typically ~1GHz, roughly 1-2 years old now) by a fair bit.  It's relatively old hardware.  Figure you get what you pay for at $25; a modern smartphone costs about $200-500 and sometimes upward of $800 for high end ones (remember, they're heavily subsidized in the USA on 2-year contract).  Obviously much of that is for things not on the RasPi, but you're still an order of magnitude cheaper for the Pi.  It's a decent little dev platform, but not much more.

I'm not a tech expert so feel free to correct me, but I have a GP2X, and I thought that uses ARM processors. MAME works quite well on that, at a much lower frequency than this Raspberry machine. Of course there may have been more people working on the GP2X version, which draws on the strengths of a few versions. What I like about it is you can over/underclock individual games to conserve power. I think I had Space Invaders running at 88MHZ, and Asteroids at 166 for instance. And the menu can be underclocked too (I might have had it at 66 or summink) since it doesn't need that much to run (",)

[Haze]

MAME is also generally only hacked on by people looking to use it on x86 type CPUs.  Even if there's no inline assembly, some of the "performance tricks" in the code may only work well on x86 and may actually hurt on ARM (there are other "tricks" that can go the other way, of course).  Note that CPU ISA makes a huge difference in the performance of MAME: some backends run much faster on AMD64 than IA-32 even on the exact same CPU due to things such as number of explicitly named registers.  If somebody wanted to hack on MAME to make it run better on ARM 1176, substantial improvements are probably possible, but I'd suspect most of the work in the "MAME on ARM" department is going to be focused on Cortex-A these days for use on modern smartphones, Beagle/Panda, etc.

Also, it'll depend on what compiler you use some.  Presumably, ARM Linux MAME is being built with GCC.  GCC's ARM backend is decent, but it's not as good as its x86 backend.  clang/LLVM may do better (or worse).  It's also possible that whoever built the build people are testing on the RasPi did something like use an old compiler or may have even had compiler level optimization disabled entirely or perhaps set for "generic ARM" which will generate pretty crap code for an ARM1176JZF.

FWIW, I'm not really fond of the SoC used on the RasPi, but it should perform OK.  It's a somewhat older pipeline arch and ISA (about one major generation behind the current Cortex-A8/A9 being used on most smartphones), but at 700MHz+, it should do OK.  Probably comparable to a 300-400MHz Pentium II.  It's lacking in the RAM and cache department, though, so you'll have to keep the working set reasonable, which should generally be possible for classics in MAME.  Combine this with the "MAME is getting slower" phenomenon, and you may have the explanation for your performance issues right there.

I guess to be clear here, it IS slower than even the "previous generation" of smartphones (single core Cortex-A8 at typically ~1GHz, roughly 1-2 years old now) by a fair bit.  It's relatively old hardware.  Figure you get what you pay for at $25; a modern smartphone costs about $200-500 and sometimes upward of $800 for high end ones (remember, they're heavily subsidized in the USA on 2-year contract).  Obviously much of that is for things not on the RasPi, but you're still an order of magnitude cheaper for the Pi.  It's a decent little dev platform, but not much more.

I'm not a tech expert so feel free to correct me, but I have a GP2X, and I thought that uses ARM processors. MAME works quite well on that, at a much lower frequency than this Raspberry machine. Of course there may have been more people working on the GP2X version, which draws on the strengths of a few versions. What I like about it is you can over/underclock individual games to conserve power. I think I had Space Invaders running at 88MHZ, and Asteroids at 166 for instance. And the menu can be underclocked too (I might have had it at 66 or summink) since it doesn't need that much to run (",)

The GP2X versions are all based on the antiquated MAME4ALL, which is based on a truly prehistoric version of MAME, I really thought we'd moved on from there when the semi-recent smartphones started being able to run recent versions well, but it seems we've gone nowhere, or possibly even backwards if people are going to have to start running such versions again on the pi just to get acceptable performance.  It was a makeshift solution at best even then and the quality of the emulation offered by such old versions makes me shudder.

[404]

the biggest issue with the pi is that none of its gpu is documented. There is no source available for it and no documentation whatsoever on how to access it. Couple that with low cpu power, a build of mame which was never intended for an arm target and you have the mess that is AdvanceMame on the pi.

Concerning the GP and similar versions of mame on other platforms, the coders for those platforms have generally taken the liberty to optimize some code for that platform.

If your project involves anything with a 12" screen and larger, you are literally better off getting a cheap second hand via itx unit that has built in tv-out. They cost about the same and gives you tons of more options in terms of operating systems to run. There's no reason why you shouldn't be able to hide a measly sub-9inch board into your project.

[danny_galaga]

The GP2X versions are all based on the antiquated MAME4ALL, which is based on a truly prehistoric version of MAME, I really thought we'd moved on from there when the semi-recent smartphones started being able to run recent versions well, but it seems we've gone nowhere, or possibly even backwards if people are going to have to start running such versions again on the pi just to get acceptable performance.  It was a makeshift solution at best even then and the quality of the emulation offered by such old versions makes me shudder.

I guess what I'm saying is that the PI is obviously no supercomputer. Why does it need the latest, most CPU hungry version of MAME? I'm guessing there's a forum of tech geeks punching out stuff for the PI. Could they not take a leaf out of the GP2X book and look backwards? Maybe not  as far as the GP2X I guess. But like Paige said, v .55 is pretty good for a lot of arcade games. Why not compile something along those lines? People love to put MAME on everything, and this seems like a good candidate and should be powerful enough.

Oh, just read 404's post. Isn't the PI a hobbyists machine? Why on earth does it have undocumented parts? Were they cheaper or summink?

[MonMotha]

Heh, it's Broadcom.  I'm amazed they were even willing to give these guys the time of day much less authorize basically any documentation be released.  I don't think a full databook for the SoC hardware is even available, much less the programming reference for the GPU.  It's actually a rather closed platform that just happens to be running a relatively open operating system (Linux).

I think they did end up getting them pretty cheap, yes.  It's an older design, so they may have had a ton of them laying around at this point.

GPU documentation is in general really hard to come by.  AMD releases it usually within a few weeks or months of the hardware coming out (i.e. it's still somewhat relevant), occasionally pre-release even, and they help the opensource community some with driver development.  Intel releases rather complete docs and actively assists with driver development.  nVidia generally releases as little as they can get away with and still have the thing be usable at all without their drivers (basically, you get mode setting and minimal 2d acceleration).  Matrox used to be very open but now releases effectively no documentation.  PowerVR releases basically nothing, and they dominate the ARM SoC landscape.  The TI OMAP series has the same problem: the chip is rather fully documented except for the GPU.

What sucks about the Pi is that the SoC was basically intended to be used for its GPU.  The CPU is basically slave to the graphics processor.  Yes, this makes it a somewhat crummy dev platform.  I really wish they'd used a more industrial oriented SoC with full docs available, but the video capabilities on those things are usually pretty lackluster, and I think they wanted to get people excited over the whole "it's a computer" thing, which basically demands media playback these days for some reason.

[johncl]

Great work on getting the RPi running mame. Have you tried Donkey Kong? I assume since its running Galaga it should handle DK too? I basically only want to play the classics and have been fiddling with a Via Epia CN13000 in FreeDos with mixed results. If I can get the RPi to boot up mame and DK with sound and working with the IPac I would be very happy to try that, although it means hunting down a new 15" 4:3 monitor with DVI or video in (if I can find such a thing).

[kahlid74]

When I got my Pi's I ran into the same issues with Debian and advMame.  After being disappointed with the performance I rolled Arch Linux and proceeded to bash my head into a wall for several weeks.  In the end I somehow got xMame working on it and I got the performance you saw at 900Mhz only without overclocking.  I liked the results but I didn't have a clue as to what I did to get there, which I hate.  So I stopped working on it and started up my Battletech Pod build again.

Once my 3D printer comes and I can build a case to house my Pi and 7"inch Car monitor together for my son to watch movies/play games I'll revisit this.

[Grasshopper]

Wow, you guys really expect a lot for $35. I don't think you can really blame the RPi developers for MAME's general slowdown and bloat in recent years. I used to run MAME .36 (or thereabouts) on an AMD 225mhz processor and it ran all the classics just fine.

I was really excited about the Raspberry Pi about 6 months ago and got very close to buying one. However, a couple of things made me pause.

Firstly, there was the lack of RAM. At first glance 256mb seems more than adequate. However, it turned out that up to half of that was reserved for use by the graphics chip. 256mb is plenty for a small Linux distro. However, 128mb starts to look a bit iffy.

Secondly, the lack of open source graphics drivers was a real problem for a device so heavily biased towards GPU performance.

However, I've just been on the RPi site for the first time in ages, and it appears that new boards are now being shipped with 512mb of RAM, and Broadcom have also just open-sourced their drivers!

link

Strictly speaking the "binary blob" is still not fully open source because the firmware part of it remains closed-source. However, it's still a huge leap forward.

[Zobeid]

After waiting and waiting and beginning to wonder if I'd ever live to see the day, I finally got my very own Raspberry Pi in my very own little hands yesterday.  It's the original 256MB model with no mounting holes in the board, too.  Oh well...  I hooked it up with a phone charger and composite video to my TV and verified that it'll boot.  Yippee!  I'll wait until I get a HDMI cable for a real monitor before I do much playing around with it.

My thoughts on the Raspberry Pi and arcade cabinets.......   It really is poorly suited to running MAME, for a lot of reasons you guys have already talked about.  The ARM core is basically a tiny corner of the chip, with the rest taken up by that monster VideoCore GPU -- but even though the GPU interface is now open-sourced, the interface is pretty high-level, and the internals are still opaque, and there's probably no practical way to apply any of it to MAME's performance.  So, we've got a powerful chip, but it's just a really poor match for the task at hand.  (You might consider springing for an Odroid-X instead?  Then again, you can get all the refurbished Dell GX280 SFFs that you want off fleaBay for $50-60 each.)

However...  When running native code and flogging the GPU (with OpenGL ES), the Pi should be capable of amazing things.  I can definitely see building a cabinet around this device.  The question is, who's going to create those native games to run on it?

Maybe we should.  Or maybe we should hook up with some indie game coders who have the skills and interest in that sort of thing.  Maybe it's time to elevate our eccentric little hobby to the next level and start creating our own custom games to go in our custom cabinets?  Don't get me wrong, MAME has been great...  I've built a couple of MAME cabinets and love them, but I do think it would be cool to go beyond that eventually, and this seems like a good opportunity.  In the Raspberry Pi we now have a hardware platform that's inexpensive, standardized, compact and capable.  Shall we see what we can do with it?

[johncl]

I got a Pi as well but I havent really found the time to tinker and compile mame for it and all. I follow Shea Silvermans Blog as he has had success running the classics on the Pi and hopefully he will also make some images available at one point too:

http://blog.sheasilverman.com/

My DK bartop project is working fine now, but the hardware bit is really making the bartop case a bit small for my liking. Motherboard, Soundblaster, 3 power adapters, poweroutlet thingy, Ipac, amplifier... The Pi could for me seriously cut down the amount of hardware inside this thing. So if I get the Pi working with the Ipac (which acts as a keyboard really) and fullscreen DK, PacMan and other early classics - I will do the swap in notime really. It is likely a brilliant alternative for mini-arcades like the ones by Jigenjuke also.