Page 2 of 2

Re: I made a Pi-powered arcade cabinet

Posted: Wed Jul 31, 2013 2:05 am
by Gerbil20
Okay, I have all the parts ordered and on their way (buttons, joysticks, I-Pac2, RPi, hard drive power supply, SATA to USB), and I just had a couple of more questions.

What gauge wire did you use? I've looked around and it looks like most people use 22 gauge wire.

Also, did you use copper or steel wire? Would there be a big difference between one or the other?

Lastly, did you solder everything? Or did you just use crimps on most of the stuff?

Re: I made a Pi-powered arcade cabinet

Posted: Wed Jul 31, 2013 2:12 am
by tinkernaut
Gerbil20 wrote:Okay, I have all the parts ordered and on their way (buttons, joysticks, I-Pac2, RPi, hard drive power supply, SATA to USB), and I just had a couple of more questions.

What gauge wire did you use? I've looked around and it looks like most people use 22 gauge wire.

Also, did you use copper or steel wire? Would there be a big difference between one or the other?

Lastly, did you solder everything? Or did you just use crimps on most of the stuff?
Pretty sure it was 22 gauge copper wire. I really doubt there would be any worthwhile reason to use steel wire in this application. And I crimped quick disconnects to all of the wires. I figured it would be easier to swap out buttons or replace them if I ever needed to.

If you need more info anytime just let me know!

Re: I made a Pi-powered arcade cabinet

Posted: Sun Aug 04, 2013 4:29 pm
by Gerbil20
Hey, I've been configuring my Raspberry Pi for the past couple of days, and I thought I'd share some information with anyone who would need it.

A previous poster said he was having problems with his gamelist.xml file in emulation station, and that can be fixed fairly easily by using the "es_scraper" script that is included in the Retro-Pie setup folder. This script will look through all of your roms and add boxart and descriptions for any games you might have. It gets a decent amount of false-positives, though. This just means you will have to manually fix the box art and descriptions yourself. I'd say it has about an 80% success rate, which is more than worth it, especially if you downloaded a large batch of roms.

Re: I made a Pi-powered arcade cabinet

Posted: Tue Nov 19, 2013 8:02 pm
by imzadi3015
Congratulations, and I am so jealous of you.
I have been trying to do this very thing. We acquired an old Taito Jungle Hunt that does not work.
I have simultaneously been working on 2 methods - Raspberry Pi and "traditional" motherboard using any Linux based operating system that will boot from a usb drive.

I am told the x-arcade joystick is a lot easier to configure, since the system treats it as a usb-keyboard. The specs look like it will replace the current "joystick shelf" on my unit.

My wife wanted me to build this for her. Myns neighbor wants me to build him one to sell. I just want to build one that will actually work.

Your story inspires me to believe mine will happen.

Re: I made a Pi-powered arcade cabinet

Posted: Wed Nov 20, 2013 3:37 pm
by tinkernaut
imzadi3015 wrote:Congratulations, and I am so jealous of you.
I have been trying to do this very thing. We acquired an old Taito Jungle Hunt that does not work.
I have simultaneously been working on 2 methods - Raspberry Pi and "traditional" motherboard using any Linux based operating system that will boot from a usb drive.

I am told the x-arcade joystick is a lot easier to configure, since the system treats it as a usb-keyboard. The specs look like it will replace the current "joystick shelf" on my unit.

My wife wanted me to build this for her. Myns neighbor wants me to build him one to sell. I just want to build one that will actually work.

Your story inspires me to believe mine will happen.
Have some confidence! I didn't know very much about how to build this thing before I started to dig into it. The cabinet build for me was the hardest thing. If you need some help configuring the software, just let me know.

Also, you could go with the x-arcade joystick, though I wouldn't recommend it. If you use a keyboard encoder like I did, then your system will also treat it as a usb keyboard and it will be easy to configure. Check out the I-pac2. I have to say that building your own controller panel is very rewarding, and not terribly difficult. You can pick out joysticks that you really like, pick a button layout that you like, and space them custom to the size of your hands.

I used this guide for laying out my controller panel: http://www.slagcoin.com/joystick/layout.html. I'd recommend printing them out, placing your hands on them and seeing how your wrist feels. You would be surprised at how uncomfortable on the wrist some of those layouts can be.

Re: I made a Pi-powered arcade cabinet

Posted: Thu Nov 21, 2013 4:13 pm
by Cia91
Every time someone use an Ipac with Raspberry a GPIO die :x

However, nice work ;)

Re: I made a Pi-powered arcade cabinet

Posted: Thu Nov 21, 2013 4:28 pm
by tinkernaut
Cia91 wrote:Every time someone use an Ipac with Raspberry a GPIO die :x

However, nice work ;)
Hah.

I felt pretty bad about going with the "off the shelf" solution of an Ipac, but I ended up needing 28 inputs for the control panel. That, plus I didn't want to have to poll for GPIO input because that would have reduced performance in a situation where the PI is already going to be CPU intensive. All that aside, I would probably hack apart a PS2 controller or something next time to create a custom joystick and get my hands dirty :D

Re: I made a Pi-powered arcade cabinet

Posted: Tue Dec 24, 2013 2:18 pm
by pacioccofmg
Hi tinkernaut,

Your arcade cabinet is awesome!
I decided to build my own arcade cabinet, but i'm a very very beginner in this kind of stuff, so i would like to ask you something before i start, just to be sure that i can complete my project!

About the joystick, i want realize a 2 player joystick and the configuration should be something like that:
https://plus.google.com/photos/10413707 ... 1747949025
(sorry about the quality of the picture)

For player 1 and player 2, we have the same things:
- 4 movements (up, down, left, right).
- 4 action Buttons ( B1, B2, B3, B4).
- 5 command Buttons (esc, start, load/save, Coins Button, Player Button).

I would like to using it with RetroPie.
The save button is for example for SNES games, which if there is the possibility to save the game will be very very fantastic.

Everything it should be attached on a IPAC2 as you did.

Right now my questions are :

1) what do you think about save and load game, should it be possible?

2) Can you give me some tips about button configurations on retroarch?

Thanks in advance, i hope my english is comprensible enough and that i wasn't too boring.

Re: I made a Pi-powered arcade cabinet

Posted: Tue Dec 24, 2013 6:16 pm
by tinkernaut
pacioccofmg wrote:Hi tinkernaut,

Your arcade cabinet is awesome!
I decided to build my own arcade cabinet, but i'm a very very beginner in this kind of stuff, so i would like to ask you something before i start, just to be sure that i can complete my project!

About the joystick, i want realize a 2 player joystick and the configuration should be something like that:
https://plus.google.com/photos/10413707 ... 1747949025
(sorry about the quality of the picture)

For player 1 and player 2, we have the same things:
- 4 movements (up, down, left, right).
- 4 action Buttons ( B1, B2, B3, B4).
- 5 command Buttons (esc, start, load/save, Coins Button, Player Button).

I would like to using it with RetroPie.
The save button is for example for SNES games, which if there is the possibility to save the game will be very very fantastic.

Everything it should be attached on a IPAC2 as you did.

Right now my questions are :

1) what do you think about save and load game, should it be possible?

2) Can you give me some tips about button configurations on retroarch?

Thanks in advance, i hope my english is comprensible enough and that i wasn't too boring.
Hi! First off, thanks for the compliments on my arcade cabinet. I don't think there will really be any problems with what you are trying to do. I believe that most (if not all) of the emulators within retropie support save states. Of course, the normal save functions in games will work out of the box for you. I see no reason, though, why you couldn't have buttons dedicated to saving/loading savestates. You would just have re-map the key for each emulator. Some of the emulators run through retroarch, and others don't, so you'll be digging through a lot of documentation figuring out how to configure anything on a case-by-case basis.

As far as advice, nothing comes to mind, but if you have specific questions about configuring your setup, I can look at my config files and help you out.

Good luck on your build!

Re: I made a Pi-powered arcade cabinet

Posted: Wed Oct 29, 2014 11:36 pm
by djdtime
It looks awesome! :D , I as well working in something very similar, I am too using Ipac2, I have MAME and NeoGeo, they map without problem, but SNES, genesis and Atari do not respond to the key mapping, I had been trying different things, I had spent more than forty hours on it, without results. I tried to modify /all/retroarch.cfg and even the individual ones on the Super Nintendo and Genesis, when I do map it, I get this; RetroArch [WARN] :: Key name lalt not found.
Do you have any idea of what the problem may be?
Here is a copy of my configuration.


## Skeleton config file for RetroArch

# Save all save files (*.srm) to this directory. This includes related files like .bsv, .rtc, .psrm, etc ...
# This will be overridden by explicit command line options.
# savefile_directory =

# Save all save states (*.state) to this directory.
# This will be overridden by explicit command line options.
# savestate_directory =

# If set to a directory, Content which is temporarily extracted
# will be extracted to this directory.
# extraction_directory =

# Automatically saves a savestate at the end of RetroArch's lifetime.
# The path is $SRAM_PATH.auto.
# RetroArch will automatically load any savestate with this path on startup if savestate_auto_load is set.
# savestate_auto_save = false
# savestate_auto_load = true

# Load libretro from a dynamic location for dynamically built RetroArch.
# This option is mandatory.

# Path to a libretro implementation.
# libretro_path = "/path/to/libretro.so"

# A directory for where to search for libretro core implementations.
# libretro_directory =

# Sets log level for libretro cores (GET_LOG_INTERFACE).
# If a log level issued by a libretro core is below libretro_log_level, it is ignored.
# DEBUG logs are always ignored unless verbose mode is activated (--verbose).
# DEBUG = 0, INFO = 1, WARN = 2, ERROR = 3.
# libretro_log_level = 0

# Enable or disable verbosity level of frontend.
# log_verbosity = false

# Enable or disable RetroArch performance counters
# perfcnt_enable = false

# Path to core options config file.
# This config file is used to expose core-specific options.
# It will be written to by RetroArch.
# A default path will be assigned if not set.
core_options_path = /opt/retropie/configs/all/retroarch-core-options.cfg

# Path to content load history file.
# RetroArch keeps track of all content loaded in the menu and from CLI directly for convenient quick loading.
# A default path will be assigned if not set.
# game_history_path =

# Number of entries that will be kept in content history file.
# game_history_size = 100

# Sets the "system" directory.
# Implementations can query for this directory to load BIOSes, system-specific configs, etc.
system_directory = /home/pi/RetroPie/roms/../BIOS

# Sets start directory for menu content browser.
# rgui_browser_directory =

# Content directory. Interacts with RETRO_ENVIRONMENT_GET_CONTENT_DIRECTORY.
# Usually set by developers who bundle libretro/RetroArch apps to point to assets.
# content_directory =

# Assets directory. This location is queried by default when menu interfaces try to look for
# loadable assets, etc.
# assets_directory =

# Sets start directory for menu config browser.
# rgui_config_directory =

# Show startup screen in menu.
# Is automatically set to false when seen for the first time.
# This is only updated in config if config_save_on_exit is set to true, however.
rgui_show_start_screen = false

# Flushes config to disk on exit. Useful for menu as settings can be modified.
# Overwrites the config. #include's and comments are not preserved.
config_save_on_exit = false

# Load up a specific config file based on the core being used.
# core_specific_config = false

#### Video

# Video driver to use. "gl", "xvideo", "sdl"
# video_driver = "gl"

# Which OpenGL context implementation to use.
# Possible ones for desktop are: glx, x-egl, kms-egl, sdl-gl, wgl.
# By default, tries to use first suitable driver.
# video_gl_context =

# Windowed xscale and yscale
# (Real x res: base_size * xscale * aspect_ratio, real y res: base_size * yscale)
# video_xscale = 3.0
# video_yscale = 3.0

# Fullscreen resolution. Resolution of 0 uses the resolution of the desktop.
# video_fullscreen_x = 0
# video_fullscreen_y = 0

# Start in fullscreen. Can be changed at runtime.
# video_fullscreen = false

# If fullscreen, prefer using a windowed fullscreen mode.
# video_windowed_fullscreen = true

# Which monitor to prefer. 0 (default) means no particular monitor is preferred, 1 and up (1 being first monitor),
# suggests RetroArch to use that particular monitor.
# video_monitor_index = 0

# Forcibly disable composition. Only works in Windows Vista/7 for now.
# video_disable_composition = false

# Video vsync.
# video_vsync = true

# Attempts to hard-synchronize CPU and GPU. Can reduce latency at cost of performance.
# video_hard_sync = false

# Sets how many frames CPU can run ahead of GPU when using video_hard_sync.
# Maximum is 3.
# video_hard_sync_frames = 0

# Inserts a black frame inbetween frames.
# Useful for 120 Hz monitors who want to play 60 Hz material with eliminated ghosting.
# video_refresh_rate should still be configured as if it is a 60 Hz monitor (divide refresh rate by 2).
# video_black_frame_insertion = false

# Use threaded video driver. Using this might improve performance at possible cost of latency and more video stuttering.
video_threaded = true

# Use a shared context for HW rendered libretro cores.
# Avoids having to assume GL state changes inbetween frames.
# video_shared_context = false

# Smoothens picture with bilinear filtering. Should be disabled if using pixel shaders.
video_smooth = false

# Forces rendering area to stay equal to content aspect ratio or as defined in video_aspect_ratio.
# video_force_aspect = true

# Only scales video in integer steps.
# The base size depends on system-reported geometry and aspect ratio.
# If video_force_aspect is not set, X/Y will be integer scaled independently.
video_scale_integer = true

# A floating point value for video aspect ratio (width / height).
# If this is not set, aspect ratio is assumed to be automatic.
# Behavior then is defined by video_aspect_ratio_auto.
video_aspect_ratio = 1.33

# If this is true and video_aspect_ratio is not set,
# aspect ratio is decided by libretro implementation.
# If this is false, 1:1 PAR will always be assumed if video_aspect_ratio is not set.
# video_aspect_ratio_auto = false

# Forces cropping of overscanned frames.
# Exact behavior of this option is implementation specific.
# video_crop_overscan = true

# Path to shader. Shader can be either Cg, CGP (Cg preset) or GLSL, GLSLP (GLSL preset)
# video_shader = "/path/to/shader.{cg,cgp,glsl,glslp}"

# Load video_shader on startup.
# Other shaders can still be loaded later in runtime.
# video_shader_enable = false

# Defines a directory where shaders (Cg, CGP, GLSL) are kept for easy access.
video_shader_dir = /opt/retropie/emulators/RetroArch/shader/

# CPU-based video filter. Path to a dynamic library.
# video_filter =

# Path to a font used for rendering messages. This path must be defined to enable fonts.
# Do note that the _full_ path of the font is necessary!
# video_font_path =

# Size of the font rendered.
# video_font_size = 32

# Enable usage of OSD messages.
# video_font_enable = true

# Offset for where messages will be placed on screen. Values are in range 0.0 to 1.0 for both x and y values.
# [0.0, 0.0] maps to the lower left corner of the screen.
# video_message_pos_x = 0.05
# video_message_pos_y = 0.05

# Color for message. The value is treated as a hexadecimal value.
# It is a regular RGB hex number, i.e. red is "ff0000".
# video_message_color = ffffff

# Video refresh rate of your monitor.
# Used to calculate a suitable audio input rate.
# video_refresh_rate = 59.95

# Allows libretro cores to set rotation modes.
# Setting this to false will honor, but ignore this request.
# This is useful for vertically oriented content where one manually rotates the monitor.
# video_allow_rotate = true

# Forces a certain rotation of the screen.
# The rotation is added to rotations which the libretro core sets (see video_allow_rotate).
# The angle is <value> * 90 degrees counter-clockwise.
# video_rotation = 0

#### Audio

# Enable audio.
audio_enable = true

# Audio output samplerate.
audio_out_rate = 44100

# Audio resampler backend. Which audio resampler to use.
# Default will use "sinc".
# audio_resampler =

# Audio driver backend. Depending on configuration possible candidates are: alsa, pulse, oss, jack, rsound, roar, openal, sdl, xaudio.
# audio_driver = sdl

# Override the default audio device the audio_driver uses. This is driver dependant. E.g. ALSA wants a PCM device, OSS wants a path (e.g. /dev/dsp), Jack wants portnames (e.g. system:playback1,system:playback_2), and so on ...
# audio_device =

# Audio DSP plugin that processes audio before it's sent to the driver. Path to a dynamic library.
# audio_dsp_plugin =

# Will sync (block) on audio. Recommended.
audio_sync = true

# Desired audio latency in milliseconds. Might not be honored if driver can't provide given latency.
# audio_latency = 64

# Enable audio rate control.
# audio_rate_control = true

# Controls audio rate control delta. Defines how much input rate can be adjusted dynamically.
# Input rate = in_rate * (1.0 +/- audio_rate_control_delta)
# audio_rate_control_delta = 0.005

# Audio volume. Volume is expressed in dB.
# 0 dB is normal volume. No gain will be applied.
# Gain can be controlled in runtime with input_volume_up/input_volume_down.
# audio_volume = 0.0

#### Overlay

# Enable overlay.
# input_overlay_enable = false

# Path to input overlay
# input_overlay =

# Overlay opacity
# input_overlay_opacity = 1.0

# Overlay scale
# input_overlay_scale = 1.0

#### Input

# Input driver. Depending on video driver, it might force a different input driver.
# input_driver = sdl

# Joypad driver. (Valid: linuxraw, sdl, dinput)
# input_joypad_driver =

# Keyboard layout for input driver if applicable (udev/evdev for now).
# Syntax is either just layout (e.g. "no"), or a layout and variant separated with colon ("no:nodeadkeys").
# input_keyboard_layout =

# Defines axis threshold. Possible values are [0.0, 1.0]
# input_axis_threshold = 0.5

# Enable input auto-detection. Will attempt to autoconfigure
# joypads, Plug-and-Play style.
# input_autodetect_enable = true

# Directory for joypad autoconfigs (PC).
# If a joypad is plugged in, that joypad will be autoconfigured if a config file
# corresponding to that joypad is present in joypad_autoconfig_dir.
# Input binds which are made explicit (input_playerN_*_btn/axis) will take priority over autoconfigs.
# Autoconfigs can be created with retroarch-joyconfig, manually, or with a frontend.
# Requires input_autodetect_enable to be enabled.
# joypad_autoconfig_dir = /opt/retropie/emulators/RetroArch/configs/

# Enable debug input key reporting on-screen.
# input_debug_enable = false

# Sets which libretro device is used for a player.
# Devices are indentified with a number.
# This is normally saved by the menu.
# Device IDs are found in libretro.h.
# These settings are overridden by explicit command-line arguments which refer to input devices.
# None: 0
# Joypad (RetroPad): 1
# Mouse: 2
# Keyboard: 3
# Generic Lightgun: 4
# Joypad w/ Analog (RetroPad + Analog sticks): 5
# Multitap (SNES specific): 257
# Super Scope (SNES specific): 260
# Justifier (SNES specific): 516
# Justifiers (SNES specific): 772

# input_libretro_device_p1 =
# input_libretro_device_p2 =
# input_libretro_device_p3 =
# input_libretro_device_p4 =
# input_libretro_device_p5 =
# input_libretro_device_p6 =
# input_libretro_device_p7 =
# input_libretro_device_p8 =

# Keyboard input. Will recognize letters ("a" to "z") and the following special keys (where "kp_"
# is for keypad keys):
#
# left, right, up, down, enter, kp_enter, tab, insert, del, end, home,
# rshift, shift, ctrl, alt, space, escape, add, subtract, kp_plus, kp_minus,
# f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12,
# num0, num1, num2, num3, num4, num5, num6, num7, num8, num9, pageup, pagedown,
# keypad0, keypad1, keypad2, keypad3, keypad4, keypad5, keypad6, keypad7, keypad8, keypad9,
# period, capslock, numlock, backspace, multiply, divide, print_screen, scroll_lock,
# tilde, backquote, pause, quote, comma, minus, slash, semicolon, equals, leftbracket,
# backslash, rightbracket, kp_period, kp_equals, rctrl, ralt
#
# Keyboard input, Joypad and Joyaxis will all obey the "nul" bind, which disables the bind completely,
# rather than relying on a default.

input_player1_a = Lctrl
input_player1_b = Lalt
input_player1_y = space
input_player1_x = Lshift
input_player1_l = z
input_player1_r = x
input_player1_start = 5
input_player1_select = 1
input_player1_left = left
input_player1_right = right
input_player1_up = up
input_player1_down = down

input_player2_a = a
input_player2_b = s
input_player2_y = q
input_player2_x = w
input_player2_l = i
input_player2_r = k
input_player2_start = 2
input_player2_left = d
input_player2_right = g
input_player2_up = r
input_player2_down = f


# Two analog sticks (DualShock-esque).
# Bound as usual, however, if a real analog axis is bound,
# it can be read as a true analog.
# Positive X axis is right, Positive Y axis is down.
# input_player1_l_x_plus =
# input_player1_l_x_minus =
# input_player1_l_y_plus =
# input_player1_l_y_minus =
# input_player1_r_x_plus =
# input_player1_r_x_minus =
# input_player1_r_y_plus =
# input_player1_r_y_minus =

# If desired, it is possible to override which joypads are being used for player 1 through 8.
# First joypad available is 0.
# input_player1_joypad_index = 0
# input_player2_joypad_index = 1
# input_player3_joypad_index = 2
# input_player4_joypad_index = 3
# input_player5_joypad_index = 4
# input_player6_joypad_index = 5
# input_player7_joypad_index = 6
# input_player8_joypad_index = 7

# Joypad buttons.
# Figure these out by using RetroArch-Phoenix or retroarch-joyconfig.
# You can use joypad hats with hnxx, where n is the hat, and xx is a string representing direction.
# E.g. "h0up"
# input_player1_a_btn =
# input_player1_b_btn =
# input_player1_y_btn =
# input_player1_x_btn =
# input_player1_start_btn =
# input_player1_select_btn =
# input_player1_l_btn =
# input_player1_r_btn =
# input_player1_left_btn =
# input_player1_right_btn =
# input_player1_up_btn =
# input_player1_down_btn =
# input_player1_l2_btn =
# input_player1_r2_btn =
# input_player1_l3_btn =
# input_player1_r3_btn =

# Axis for RetroArch D-Pad.
# Needs to be either '+' or '-' in the first character signaling either positive or negative direction of the axis, then the axis number.
# Do note that every other input option has the corresponding _btn and _axis binds as well; they are omitted here for clarity.
# input_player1_left_axis =
# input_player1_right_axis =
# input_player1_up_axis =
# input_player1_down_axis =

# Holding the turbo while pressing another button will let the button enter a turbo mode
# where the button state is modulated with a periodic signal.
# The modulation stops when the button itself (not turbo button) is released.
# input_player1_turbo =

# Describes the period and how long of that period a turbo-enabled button should behave.
# Numbers are described in frames.
# input_turbo_period = 6
# input_turbo_duty_cycle = 3

# This goes all the way to player 8 (*_player2_*, *_player3_*, etc), but omitted for clarity.
# All input binds have corresponding binds for keyboard (none), joykeys (_btn) and joyaxes (_axis) as well.

# Toggles fullscreen.
input_toggle_fullscreen = f

# Saves state.
# input_save_state = f2
# Loads state.
# input_load_state = f4

# State slots. With slot set to 0, save state name is *.state (or whatever defined on commandline).
# When slot is != 0, path will be $path%d, where %d is slot number.
# input_state_slot_increase = f7
# input_state_slot_decrease = f6

# Toggles between fast-forwarding and normal speed.
# input_toggle_fast_forward = space

# Hold for fast-forward. Releasing button disables fast-forward.
# input_hold_fast_forward = l

# Key to exit RetroArch cleanly.
# Killing it in any hard way (SIGKILL, etc) will terminate RetroArch without saving RAM, etc.
# On Unix-likes, SIGINT/SIGTERM allows a clean deinitialization.
input_exit_emulator = escape

# Applies next and previous shader in directory.
input_shader_next = m
input_shader_prev = n

# Hold button down to rewind. Rewinding must be enabled.
# input_rewind = r

# Toggle between recording and not.
# input_movie_record_toggle = o

# Toggle between paused and non-paused state
# input_pause_toggle = p

# Frame advance when content is paused
# input_frame_advance = k

# Reset the content.
# input_reset = h

# Cheats.
# input_cheat_index_plus = y
# input_cheat_index_minus = t
# input_cheat_toggle = u

# Mute/unmute audio
# input_audio_mute = f9

# Take screenshot
# input_screenshot = f8

# Netplay flip players.
# input_netplay_flip_players = i

# Hold for slowmotion.
# input_slowmotion = e

# Enable other hotkeys.
# If this hotkey is bound to either keyboard, joybutton or joyaxis,
# all other hotkeys will be disabled unless this hotkey is also held at the same time.
# This is useful for RETRO_KEYBOARD centric implementations
# which query a large area of the keyboard, where it is not desirable
# that hotkeys get in the way.

# Alternatively, all hotkeys for keyboard could be disabled by the user.
input_enable_hotkey = escape

# Increases audio volume.
# input_volume_up = kp_plus
# Decreases audio volume.
# input_volume_down = kp_minus

# Toggles to next overlay. Wraps around.
# input_overlay_next =

# Toggles eject for disks. Used for multiple-disk content.
# input_disk_eject_toggle =

# Cycles through disk images. Use after ejecting.
# Complete by toggling eject again.
# input_disk_next =

# Toggles menu.
input_menu_toggle = f1

# Toggles mouse grab. When mouse is grabbed, RetroArch hides the mouse,
# and keeps the mouse pointer inside the window to allow relative mouse input
# to work better.
# input_grab_mouse_toggle = f11

#### Menu

# Menu driver to use. "rgui", "lakka", etc.
# menu_driver = "rgui"

#### Camera

# Override the default camera device the camera driver uses. This is driver dependant.
# camera_device =

# Override the default privacy permission for cores that want to access camera services. Is "false" by default.
# camera_allow = false

#### Location

# Override the default privacy permission for cores that want to access location services. Is "false" by default.
# location_allow = false

#### Netplay

# When being client over netplay, use keybinds for player 1.
# netplay_client_swap_input = false

# The nickname being used for playing online.
# netplay_nickname =

# The amount of delay frames to use for netplay. Increasing this value will increase
# performance, but introduce more latency.
# netplay_delay_frames = 0

# Netplay mode for the current user.
# false is Server, true is Client.
# netplay_mode = false

# Enable or disable spectator mode for the player during netplay.
# netplay_spectator_mode_enable = false

# The IP Address of the host to connect to.
# netplay_ip_address =

# The port of the host IP Address. Can be either a TCP or an UDP port.
# netplay_ip_port = 55435

#### Misc

# Enable rewinding. This will take a performance hit when playing, so it is disabled by default.
rewind_enable = false

# Rewinding buffer size in megabytes. Bigger rewinding buffer means you can rewind longer.
# The buffer should be approx. 20MB per minute of buffer time.
rewind_buffer_size = 10

# Rewind granularity. When rewinding defined number of frames, you can rewind several frames at a time, increasing the rewinding speed.
rewind_granularity = 2

# Pause gameplay when window focus is lost.
# pause_nonactive = true

# Autosaves the non-volatile SRAM at a regular interval. This is disabled by default unless set otherwise.
# The interval is measured in seconds. A value of 0 disables autosave.
# autosave_interval =

# Path to XML cheat database (as used by bSNES).
# cheat_database_path =

# Path to XML cheat config, a file which keeps track of which
# cheat settings are used for individual games.
# If the file does not exist, it will be created.
# cheat_settings_path =

# Directory to dump screenshots to.
# screenshot_directory =

# Records video after CPU video filter.
# video_post_filter_record = false

# Records output of GPU shaded material if available.
# video_gpu_record = false

# Screenshots output of GPU shaded material if available.
video_gpu_screenshot = true

# Block SRAM from being overwritten when loading save states.
# Might potentially lead to buggy games.
# block_sram_overwrite = false

# When saving a savestate, save state index is automatically increased before
# it is saved.
# Also, when loading content, the index will be set to the highest existing index.
# There is no upper bound on the index.
# savestate_auto_index = false

# Slowmotion ratio. When slowmotion, content will slow down by factor.
# slowmotion_ratio = 3.0

# The maximum rate at which content will be run when using fast forward. (E.g. 5.0 for 60 fps content => 300 fps cap).
# RetroArch will go to sleep to ensure that the maximum rate will not be exceeded.
# Do not rely on this cap to be perfectly accurate.
# A negative ratio equals no FPS cap.
# fastforward_ratio = -1.0

# Enable stdin/network command interface.
# network_cmd_enable = false
# network_cmd_port = 55355
# stdin_cmd_enable = false

Re: I made a Pi-powered arcade cabinet

Posted: Thu Nov 20, 2014 8:08 pm
by mike0mike
Hi everyone,

I am starting this journey of building my own MAME cabinet. Does anybody know what advantages/disadvantages there are to connecting the controls panel (joystick, buttons) via an I-PAC Versus, using this kit which connects the controls to a USB interface? http://www.ultracabs.co.uk/usb-interfac ... -109-p.asp

Re: I made a Pi-powered arcade cabinet

Posted: Fri Nov 21, 2014 1:16 am
by tinkernaut
They seem to be practically the same concept, except that kit sounds like it shows up to the system as a controller rather than a keyboard. It would probably work just as well, but there are a lot of people on the forums who have trouble with controllers as opposed to keyboards.

Re: I made a Pi-powered arcade cabinet

Posted: Sun May 03, 2015 8:08 am
by mycarleaks
I'm interested to know a bit more about the connection between the RPi and the ipac.

Did this work straight away? Where additional drivers required?

I've got an older version of the ipac with a ps/2 connection rather than usb, and I'm having trouble connecting it to the RPi.

I'm using a ps/2 to usb adapter, however I can't get the ipac to fire up.

Thanks

Re: I made a Pi-powered arcade cabinet

Posted: Sun May 03, 2015 8:36 pm
by panik
Re: I-PAC

Another option to have arcade buttons and joystick control the Pi, is to use a programmable microcontroller that connects to the Pi or computer/laptop as a USB HID [device].

The AVRPi-32U4 I'm selling plugs nicely onto the Raspberry Pi and is programmable as a USB keyboard with the Arduino library (from the Raspberry Pi itself). A good starting point could be the Pimoroni Picade firmware https://github.com/onandoffables/avrpi- ... cts/picade.

If you want it to identify itself as a USB Joystick or (analog/digital) USB Gamepad there's Dean Camera's LUFA library, which also runs great and without additional drivers on the Raspberry Pi.

Link to the website for the AVRPi-32U4 board and software: http://www.onandoffables.com/index.php?m=avrpi32u4

Note that you may want to consider soldering screw terminals on a piece of protoboard and plug that into the female headers, so it does require some (light) soldering.

Ontopic: That's a mighty impressive cabinet you built there, @tinkernaut !

Edit:
mycarleaks wrote:I've got an older version of the ipac with a ps/2 connection rather than usb, and I'm having trouble connecting it to the RPi.

I'm using a ps/2 to usb adapter, however I can't get the ipac to fire up.
Maybe this info helps?: viewtopic.php?f=26&t=37547