Entries filed under Unix

Hacking the 276 in 1 JAMMA board

TL;DR: Someone else has done this already go here.

My super wife bought me a modified Ms Pacman cabinet which has the 276 in 1 JAMMA board in it now. I noticed immediately it had an SD card on it and needed to know if it could be modified in anyway. This post will grow over time as I find new details.

Hardware info

The JAMMA board appears to have an ARM CPU based on the few binaries I looked at.

SD Structure

Three partitions. 1 is /boot, 2 contains some configuration and start up scripts, and 3 is / with a typical Linux file structure.

Partition 1


Partition 2

Lots of interesting things here

  • clsemuv – looks to be a build of the GP32 version of MAME
  • xemu – some sort of binary based on strings it seems to be a combination of sdlmame and pinmame
  • xhidev – another binary – looks like its used to control the other binaries
  • xrunmv – yet another binary – this seems to be a build of the LemonLauncher.
  • run.sh – tiny bash script which runs xrunmv
  • roms/ – symlink to /usr/roms – this directory is present on parition 3
  • nvram/ – directory containing .nv files for each ROM file
  • wavs/ – symlink to /usr/wavs
  • xrun/ – symlink to /usr/xrun

Partition 3

This seems to be the bulk of the Linux installation. It has all the usual unix directories here.

From some files in etc/ I think that partition 2 gets mounted at /sdcard during boot

Backing Up Your SD Card

The SD card has a special bootloader which needs to be “fused” with the SD card after it is imaged otherwise the system won’t boot.

To do this you need a few things:

  1. SD-Flasher: Get it from here: https://code.google.com/p/mini6410-debian/
  2. The correct SDBoot image for your JAMMA board. Some folks at the Arcade Museum forums have extracted these from their SD cards and posted them. There are 2 versions which I have uploaded here for your convenience. SDBoot 1.1 or SDBoot 1.21
  3. An image of your existing SD Card: Do this with DD or the imaging tool of your choice
  4. A new SD card – You might be able to use a larger or different SD card but I bought the identical card that came with my board on Amazon.

To do it:

  1. Image your arcade image on to the new SD card (I did this with dd)
  2. Start of SD-Flasher
    1. Pick the SDBoot bin file
    2. Click Scan!
    3. Pick the right card out of the list
    4. Click Fuse
  3. You’re done!

Previous Work

Some folks on the Arcade Museum forums have actually done all this work already. One of the members there summarized most of the work on this thread:


Using EZCap EzTV668 DVB+ receiver for SDR on Mac OS X 10.7

There has quite a bit of buzz about the RTL-SDR project that is going on over at reddit on the rtl-sdr subreddit. Most of it has been about using the RTL2832/e4000 devices under Windows and Linux. Since I primarily use Mac OS I decided to cobble together the various hints of other people who have successfully used the devices on Mac OS and document them in a gist on github:


Update: After some feedback on reddit for the previous gist I decided to revisit my build to that I would have a more up to date version of GNURadio. After much hacking I came up with these directions for getting GNURadio 3.6.0 working on 10.7:


After following those directions you’ll want to then install the rtl-sdr driver and then gr-osmocomm so that you’ll be able to use the RTL tuner with gnuradio.

Changing nginx’s worker process user on OS X

nginx defaults to running its master process as root and all workers as nobody.

You can tell nginx to run worker processes under different credentials by setting the user directive in nginx.conf.

On OS X, you need to specify a valid group as well, since nginx will default to looking for a group that doesn’t exist. You will see “nginx – getgrnam()” in the error log when this happens. The easiest solution I found is to assign the OS X staff group:

user userid staff

It probably bears mentioning that changing the runtime credentials won’t negate the need for sudo if you run your web server on port 80, since OS X (and all Unixes) will not allow nginx to use that port unless it runs as root.

Quitting Terminal app in Lion when the last console session ends

Lion’s Terminal app and its tabbed full-screen mode is a huge improvement for me. One thing that became a minor annoyance, however, is Terminal’s failure to quit when the last console session ends: Cmd-Q is still required to quit the app completely.

The workaround I chose takes advantage of existing muscle memory.  I had already configured an alias for exit, allowing me to type x to end a console session.

To solve the Terminal app problem, I repurposed x as a function in my ~/.bash_profile:
function x {
[ "$(w -h | grep "^$(whoami) *s[^ ]* *-"|wc -l)" -le 1 ] && osascript -e 'tell application "Terminal" to quit' || exit

The function checks for the number of active console sessions. When x is called and only one session remains, osascript is invoked to quit the Terminal app completely.

SSH Tricks #2: SSH as a proxy

We talked about port forwarding recently. This helps you get access to single resources but it requires a lot of planning and configuration. It would be pretty awesome if SSH had a proxy feature.

Lucky for us all there is the -D option for the ssh command. This option turns the ssh connection in to a SOCKS proxy on the remote server. The potential uses for this are huge. I often use this feature to gain quick access to my whole network.

Setting it up

superbox$ ssh -D 31337 someserver

Using it

Firefox SOCKS Proxy is set to localhost port 31337

To use this you will need to configure your applications to connect through the SOCKS proxy. Firefox is pretty easy to configure. The settings for the proxy live in the Preferences under the Advanced section in the Network tab. Click the Settings… button to bring up a dialog similar to the one on the right. Set the SOCKS host to localhost and the port to the one you chose when connecting.

Now that the proxy is setup you can test out that you’re proxy is working by visiting http://whatismyipaddress.com/ to check to see if it looks like you are accessing the site from a new IP address.

In the next installment of SSH Tricks we’ll talk about using ssh config files to save time and energy.

SSH Tricks #1: SSH Port Forwards

SSH is the ultimate tool for shifting bits around networks in a secure manner. This is the first of a series of articles on SSH tips. This article is all about the basics; as the tips progress, we will get trickier.


Port forwards are a way of mapping a TCP from one side of the ssh connection to the other. They are established using the -L and -R parameters to the ssh command. These stand for local and remote port forwards. A local forward takes a port on the local machine and connects it to an IP address and port from the remote machine. As you suspect, a remote forward takes a port on the remote machine and connects is to an IP address and port from machine you are connecting from.


You could forward port 80 from an  internal web server to port 8188 on the machine you are connecting from. This is a sort of poorman’s VPN. You can gain access to resources inside your network via SSH local port forwards. After connecting to your gateway machine you would be able to access the web server at http://localhost:8188.  To actually do this the command would look like this:

superbox$ ssh -L 8188:internalweb:80 homerouter

Another common use for this is securing VNC access. Many VNC servers offer the option to only accept connections from localhost. By combining this option with a ssh local forward  you can create an encrypted VNC session. This would be done by doing:

superbox$ ssh -L 5900:localhost:5900 vncserver

Remote port forwards are much less common. Lets say you have a local web server running on your workstation and you’d like your friend to take a look at an error on a hot new web app. you’re developing. The catch is you don’t want to let them login to your machine to do a local forward to gain access to your server. In this case you could use a remote port forward like this:

superbox$ ssh -R 8188:localhost:80 untrusted-friend

Your somewhat trustworthy friend could then access your web server at http://localhost:8188.

In the next installment of this series we will reveal a way to make your SSH connection behave even more like a VPN.