Using a DG600F Coin Acceptor to Control EmulationStation Gaming Software

A group at the local STEM school has a project to build a gaming system. They are running EmulationStation on a Raspberry Pi which works very nicely. Everything is controlled by a joystick and pushbuttons. They are building into a wood console they cut on a CNC router.

They called me to help them integrate a coin acceptor into the game. The design and implementation of the coin acceptor was documented here


Interfacing DG600F Coin Acceptor to Arduino

So we have a signal coming into the RPI that is HIGH when there is time left and LOW when the time runs out. They needed to somehow not allow gaming to start until the signal goes HIGH and terminate it when it goes LOW.

First we looked at EmulationStation. They are using an IPAC-4 controller to convert the controls into keyboard keystrokes. There are a few connections there for a coin acceptor; however, we could find no documentation on how to make those work with EmulationStation. Since we only had 4 hours left to complete the program we had to move on.

Since we could not find any other method of using a coin acceptor I will document our solution. It is not elegant, but it works.

We decided the best course of action was to trap the call to EmulationStation. We would not execute the gaming software until $$$ was input and the control signal went HIGH. Then when the signal went LOW we would reboot the RPI.

The kids don’t know anything about linux outside of getting the gaming software installed. Searching the internet, we could not figure out what was causing EmulationStation to fire up.

Finally we found /etc/profile had been modified to start the program during boot up. We commented that line out.

We need to read GPIO4 pin, so we made the following configuration changes to the system:

sudo echo 4 >/sys/class/gpio/export
sudo echo in >/sys/class/gpio/gpio4/direction

We then used this scriplet to verify the pin was going high/low when we expected it:

while true;do
    cat /sys/class/gpio/gpio4/value
    sleep 1

The final step was to create a script that starts when the user pi logs in. This script waits for coins to be dropped, plays the game, and then reboots the RPI when the time runs out.


#these shouldn't be necessary every time, but they keep problems from cropping up for the kids down the road
sudo echo 4 >/sys/class/gpio/export
sudo echo in >/sys/class/gpio/gpio4/direction

echo GamePlay Monitor. Waiting for coins....

while [[ $(cat /sys/class/gpio/gpio4/value) == '0' ]]; do
    sleep 1

echo Starting Game

#start game as separate process
emulationstation &

while [[ $(cat /sys/class/gpio/gpio4/value) == '1' ]]; do
    sleep 1

sudo reboot

this file was named gameplay. It had its permissions change to allow it to be executed. Finally, the last line of .bashrc in the pi users home directory had the line added:


This is not pretty, but it works reasonably well. And we got it done with time to spare for them to work on some of the other parts.

As I was driving home I realized that rebooting the RPI was overkill. Instead of issuing a reboot, a killall emulationstation probably would have worked as well and not required an entire system boot.




This entry was posted in c-rpi. Bookmark the permalink.

10 Responses to Using a DG600F Coin Acceptor to Control EmulationStation Gaming Software

  1. Dave says:


    Thanks for the post, it is the only on this topic.

    Just a question: when you do “sudo killall emulationstation” will it go back to “Gameplay Monitor. Waiting for coins…” to start all over again?


  2. Dan TheMan says:

    If you use killall, you will need to then restart the script. This could be done by having an infinite outerloop that starts at the clear command and ends with the killall.

    I didn’t test this so I don’t know for a fact killall will clean up everything completely, but it seems it would.

  3. Dave says:

    Thanks. I will try it out and let you know

  4. Dave says:

    I tried it out and it works, though I had to tweak with permission a bit to make it work. Just to confirm that replacing sudo reboot with killall works too.

    However I still have a problem. The “killall” (or reboot for that matter, though I haven’t actually tested with reboot) only works when we are in the emulationstation menu (i.e. selecting games). During gameplay, it doesn’t work until you exit the game (and come back to emulationstation menu). Any idea how to fix this?


    • Dan TheMan says:

      Unfortunately I no longer have access to the system any longer. We didn’t actually try killall, it just occurred to me as a possibility after the fact. Normally, killall works fine on about everything I’ve tried (including XWindows). We did use reboot and that definitely worked.

  5. Dave says:

    Thanks for your answer anyway. I am thinking that there should be other processes that need to be killed besides emulationstation as well. Will try to work it out. Your blog has been of much help. Cheers.

    • Dan TheMan says:

      Let me know what you find. You could look at output of pstree and see if there is something else in the process tree that will work. Or perhaps you need to find the pid and just kill that.

      • Dave says:

        Hi Dan,

        Using pstree, I can see that the “gameplay” process is: init—login—bash—gameplay, which is fine.

        When playing MAME games, I see that there is also another branch: init—sh—–—–mame—–5*[{mame}] which cannot be killed by “killall”.

        Any idea how I can terminate this branch?

        I am still new to Linux so this is all new to me.
        Thanks in advance.

      • Dan TheMan says:

        Hi Dave,
        I went looking for anyone else trying to killall mame and I see you are asking on stackexchange. Perfect, as they have a much better likelihood of answering the question than I.

        The answers there are largely what I would come up with (like using killall -g), and regressing thru the tree structure killing all processes.

        when you do the pstree, you can use the -p option to get the pid of each process. I would manually do that and see if using kill works. If so (and it really should), then it is a matter of making a script that does the same thing (which is not as easy as killall, but doable).

        If kill won’t work, then I’m stumped. REBOOT manages to kill them, so it must be doable, I just don’t know how.

  6. Dave says:

    Found out that for the major emulators, there is another process called retroarch that should be killed. Make sense, because emulationstation is just the frontend and retroarch is what is running underneath.

    But for MAME, I still have not found what is responsible and should be killed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s