Despite having the final location of my eventual upright cabinet build cleared away, I had decided that it will be the bartop cabinet that I will approach first. Since this is going to be my first build, it makes sense to start small and then to further build upon that to complete the upright cabinet. These two cabinets both share a fair amount of common requirements, while having their own unique constraints and build challenges. Before starting to get in to actually starting to put things together, it would be beneficial to establish a number of requirements that I feel that I need to reach to accomplish successful milestones for each build.
Perhaps it is because I deal with requirements on a day-to-day basis, by trade, that I feel compelled to establish some that I need to satisfy my acceptance criteria. The software industry is full of buzzwords and quirky phrases, one of which being “analysis paralysis”. It is the point at which you spend so much time fixating about the ideal solution to a problem that you have no idea where to start. Considering the amount of time that I have been thinking about what I wanted to build, I have that same daunting feeling ahead of me. On the one hand, there is an urge to immediately jump in and just start doing. On the other, there is apprehension about going in without a plan and regretting the decisions that end up being made in haste. The purpose of this article is to bridge that gap, although admittedly, I have already begun some work prior to writing anything down.
Comparing the Systems
It would help to establish some of the basic parameters around each of the systems that are going to be built, even if only one of them is being started now. These items are subject to change, based on numerous factors. Seeing as the upright cabinet is further out, that one is more likely to change. Some of the materials and components I already have on-hand, due to repurposing or acquiring them specifically for these projects.
The most immediate difference is going to be in terms of hardware. For the bartop build, I have chosen to go with a Raspberry Pi 3 B. It is more than adequate for the types of games that I am looking to run and is at a price point (around $35 USD) that it is extraordinarily approachable. In choosing a Raspberry Pi for the bartop build, I have already acknowledged that I will need additional hardware to make it achieve what I expect out of it. The most notable area is that of audio, and the limited out-of-the-box options that come with a Raspberry Pi. Considering the cost, it is not surprising. It does offer digital audio, in the form of audio over HDMI. For reasons that will be more clear when it comes to sourcing a monitor, HDMI is unlikely to be a part of the equation. What that leaves is the onboard 3.5mm analog stereo output. The good news is that it works out of the box. Unfortunately, though, the audio quality is notoriously poor. Should I choose to go that route, it would mean that I would experience a large amount of hiss, cracking, and popping. So, in addition to the Raspberry Pi, itself, I will be adding a digital audio controller. This will enable me to connect the Raspberry Pi to a small amplifier to drive a pair of smaller speakers. On top of that, I will also need to (safely) operate line voltage from the Raspberry Pi to control power to the amplifier, the monitor, and the light for the marquee, plus I will want to be able to physically (and again, safely) power all of these items on or off through a single switch.
As to the upright build, I already have the hardware in-hand for that, as well. When I upgraded our HTPC in the living room, I had almost half of a computer left over from the old system. I had rounded out the components and put it into a small case, where it has been serving as a Kodi / light gaming rig in my office for the last several years. Specification-wise, it is a mid-range media PC. It is running an Asus Z87 chipset with a mid-range Core i7 processor. It has dual, low-profile ATI Crossfire graphics cards, 4GB of SDRAM, and a 1TB hard drive. I will ultimately end up facing some of the same challenges that I have for the Raspberry Pi, primarily in making a seamless experience where I do not have to turn multiple accessories on or off to get everything to the same power state. Ultimately, it will require some level of an automation solution, although I am not sure what that solution will be. Intuition tells me that an Arduino will be a logical choice (or even a NetDuino if they are still making them when I am ready).
One thing that will be more alike than different, in terms of hardware, is that I have chosen to use LCD monitors. While I understand that arguments that a “pure” experience can only be attained from an original arcade monitor or other CRT, there are severely limiting factors in committing to that choice. Foremost, there are the issues of cost and weight. A reasonable arcade monitor can run between $400 and $800 dollars, which is magnitudes greater than I intend on spending on a monitor. Then there is the weight issue to content with, as these are CRTs and have all of the bulk that goes along with them. They are hardly portable, and are subject more subject to breaking down and more troublesome to repair. For the bartop cabinet, I have already acquired a monitor – a Dell 1908FP. It is a 5:4 aspect and has analog inputs, in the form of a VGA connection. Additionally, it has a decent refresh rate and a surprisingly good black contrast ratio. The best part of that monitor is that it cost me $45, shipped, and was NOS (New Old Stock). At that price, should I ever have a problem with the monitor, it would actually be cheaper to replace it than to repair it. I plan on a similar approach for my upright build, although I have not yet settled on a monitor. The problem with LCDs is that 16:9 is the standard aspect ratio. There are some 21″ and 23″ 4:3 LCDs out there still, but they are pricier. In my mind, I am still debating what path to take with the upright, as it relates to this dilemma. One thing that I do have going for me with the PC hardware that I already have, is that ATI Catalyst will allow me to force a widescreen to only display 4:3 (or 5:4) by creating black bars on the sides of the monitors. It is not much different than how widescreen movies are fit onto older televisions, apart from the fact that we are trying to minimize the space used instead of maximizing it. That can be hidden with a bevel, as well. When I had done the math, I believe I had determined that I would only need to hide about 2.5″ on each side of the monitor for the 32″ 16:9 monitor that I was considering. Plus, it also has VGA input…
Why have I explicitly mentioned VGA inputs as a requirement for my monitors? For everything that the CRTs have going against them, the thing that is definitely in their favor is that games were developed specifically with that type of display in mind. If you have ever emulated a classic arcade game on a modern monitor, you will likely notice how washed out everything seems. The way that a CRT works is that a single line of pixels are projected on to the tube at a time. If you look closely enough, you will see that you have a rows of colored pixels and rows that are black, giving a distinct horizontal line pattern. For a given resolution, these colored lines and non-colored lines appear in the same place. I plan on emulating that through a VGA scanline generator. It is an inexpensive card that sits between a VGA input and output, and is usually configurable to provide several different hardware-emulated scanlines patterns to an analog signal. Since HDMI and DVI are digital signals, we will convert the digital signal to an analog signal, route it through the scanline generator, and into the monitor. It will not be pixel-perfect, but most people (myself included) will not notice it to the point it detracts from any enjoyment. The other thing that CRTs have that LCDs do not, is that CRTs have a curved screen. This causes a rectangular image to be “pinched”, effectively into the shape of a rectangle who has subtle arcs instead of straight lines. While there are some software solutions to emulate that, I do not plan on incorporating that. While I understand some people may want to, the curved aspect of a screen does not even register on my radar as something that I need to capture the arcade experience.
After understanding the differences in hardware requirements, it is quite obvious that these systems will be running very different software, as well. The Raspberry Pi build will be running a RetroPie distribution, which is a combination of Raspbian Jessie with the actual RetroPie software. I have chosen RetroPie because it is a well-established product that has a very active community. The prepackaged images that they supply will also mean that I can be up and running games in a very short amount of time. RetroPie, itself, provides a centralized means to configure and organize the various software that will be used for emulation. For a frontend, it comes with their own forked version of EmulationStation. As simple as EmulationStation is to use and maintain, it is not the frontend that I will be going with. I have spent several weeks on the PC that will form the basis of the upright cabinet, experimenting with different frontends. After ruling some in and some out, and looking what I can use on both a Raspbian/RetroPie solution, as well as Windows, I have settled on Attract Mode. It is simple, available for both platforms, has a decently active community, is open source, and theme creation is one of its strengths. In terms of themes, it also can utilize themes from both HyperSpin and MALA, increasing the number of available themes considerably.
The upright cabinet will be running Windows 10 Professional. Currently, it is already baselined, with Attract Mode and a moderately recent copy of MAME. I have already started applying machine policies to it, so that it will effectively operate in a “kiosk mode”. This involves hiding as much of Windows as actually possible, replacing the Windows shell with Attract mode, and providing remote access for administration. One of my favorite features of RetroPie is that you can connect a USB thumb drive to your Raspberry Pi and it will create a folder structure for you, to place ROMs, BIOS, and associated files on to the system. Once you place those files on the thumb drive and insert it back into the Raspbery Pi, RetroPie will automatically move them to the correct folders and generate game lists from that. Being a software architect, by trade, I already am anticipating writing something similar to run on the upright cabinet. That will likely be only the beginning, as I am sure that I can find other utilities to write to increase the suspension the disbelief that the cabinet is really just a computer.
Being arcade cabinets, it only makes sense that each will have arcade controls. To interface those controls, I will also be using a keyboard encoder. That will act as a go-between, bridging the physical controls and converting their analog signals into keypresses that will be sent to the respective systems, through a USB port. While the Raspberry Pi has GPIO functionality that I could leverage, my decision to use a digital audio controller (DAC) has limited the number of available pins that I will ultimately have access to. What pins are available, some will be used for power switching and device control, meaning that I physically will not have enough pins to handle the control layout. If I would have been fine with the on-board audio, this would not have been an issue. By no means, am I an audio snob, but the analog audio quality of the Raspberry Pi is anything but usable for me.
Controls, in general, is where the waters start to get a little murky for me. For the upright, I am still debating whether I want a two-player control panel or a four-player. I know that I want a trackball and a spinner, and I would like to have a pair of light guns. Beyond that, I have no clue how I would like to arrange them or the types of sticks and buttons that I want. For the bartop, things are a little more clear, but not written in stone, yet. I definitely am focusing on a one-player control panel that will include a trackball. For the joystick, I have settled on a balltop switchable stick that I can switch between being a four-way and an eight-way. Since I enjoy the true classics, like Pac-Man and Donkey Kong, playing with exclusively an eight-way would be an exercise in frustration. The controls will be offset to the left, so that I can incorporate a trackball on the right. I keep going back and forth on the number of buttons that I want to have, routinely bouncing between five, six, seven, or eight. There are arguments to be made for any of those configurations, and I think that my hesitation in finalizing is that I am still unsure if I want to play anything beyond classic arcade games, or not. In addition to those, I also need coin buttons, start buttons, basic administration buttons, and volume control buttons. Whether those all sit on top of the control panel or end up being on the face is still something that I will need to draft up, and likely build a mockup of.
As these tasks get further into the build process, the completeness of ideas gets further from being solidified. I have drafted a to-scale side profile of what the bartop cabinet will look like, which I did to ensure that the speakers, marquee, and monitor would have ample room for. From there, I abstracted a hypothetical control panel depth. I plan on making a full-sized mockup in cardboard, just so I can visualize it somewhere other than a computer monitor. As I begin acquiring parts for the control panel I will be able to determine if the depth is adequate and will be able to figure out the actual width. The minimum width is already governed by the monitor dimensions, and I anticipate that I can come up with a comfortable layout that is not any wider than the horizontal measurement of the monitor (plus a nominal amount for mounting an bezel sizing).
Also being a hobbyist woodworker, I am firmly set into choosing to use 3/4″ Baltic Fir plywood over MDF. While the MDF does provide an engineered true surface, it is the mechanical properties and weight of MDF that I do not like working with (not to mention how hard it can be on my tools). While I believe that wood glue is a wondrous glue, I do not trust if for applications that induce awkward vector forces or are subject to torque. Instead, I will use mechanical fasteners (screws and bolts), in addition to gluing. At least from how I have visualized the bartop cabinet, so far, there will be no fasteners used on visible surfaces. Furring strips and cross members will be either plywood or hardwood, depending on the weights and forces that will be required of them to support. At least in the drawing, furring strips have purposefully been drawn as 3/4″ square, assuming that I could easily rip them in quantity on the table saw, and easily do repeated angle cuts on the compound miter saw.
Finishing details are even further up in the air, if that is all possible. For the bartop, I would like to have white exterior panels and black interior panels, along with black t-molding. I am leaning towards laminates for the exterior panels, and paint for the interior panels, at least for now.
Player One, Press Start
While there are still many unanswered questions, there is still more than an adequate amount to start. That means that in my next article, I will do a walkthrough on setting up a Raspberry Pi with RetroPie, and getting ready to play games.