CORSE - Arcade Racing Cab Interface Board

This instructables was long due. I have an unconditional love for arcade machines, but racing cabinets... maaan, those exert pure gravitational attraction to me! The time had come to resurrect a project from a few years ago and give it some due fix and improvements.

Classic JAMMA cabinets have a whole bunch of commercial solutions to make them compatible with PCs, but this is not the case for racing cabinets. And for a good reason: racing cabinets are nowadays way more scarce than generic "joystick + buttons" cabs.

At the end of the 80's and first 90's generic "semi-JAMMA" racing upright cabinets were common in my country and as a little boy/teenager they were wery attarctive to me. Once, decades later, I got my hands on one of those beauties (beasts they are too...) I started thinking at how to manage the technical differences with respect to a classic joystick and buttons upright cabinet.

I first started handling analog inputs through a so called "joyhack", then, with the increase of emulator features and tinkerers softwares, the time arrived for outputs rumble motor and lamps managing.

And, believe me, outputs make an enormous difference in arcade racing games!

This instructables describes the later revision of my DIY interface for Arcade Racing Cabinets. This boards lets you interface a PC with a genuine, generic racing cabinet. With the correct softwares installed on the PC and adeguate to the load to drive driver boards , it makes possible wheel effects (rumble, not force feedback) and lamps handling.

In this instructables I will share with you both Gerber files to have the interface board and two driver boards PCBs manufactured at the best price around. I will share the needed firmwares to have the interface working. I will also give you some hint in order to have everything set up for first outputs tests.

Let's go! :)

Here follows the Bill of Materials for the interface board and the two driver boards.

CORSE Interface Board (BOM)

Qty, Value, Description

1, 1N4148, diode

8, W237-102, Wago screw clamp

1, W237-103, Wago screw clamp

2, 1/4W-1% 10Ω resistor

2, 1/4W-1%, 1000Ω resistor

1, 1/4W-1%, 4700Ω resistor

1, 100n, non polarized capacitor

1, 10K, trimmer

1, 10u, polarized capacitor

1, 220u, polarized capacitor

1, 22n, non polarized capacitor

1, 22u, polarized capacitor

1, 47n, non polarized capacitor

1, 4k6, RN04, resistor network

1, 5.1k, 1/4W-1%, 5.1KΩ resistor

3, 500 ohm trimmer

1, ARDUINO NANO

1, ARDUINO PRO MICRO 32u4

1, audio jack 3.5 mm

1, DB15/VGA right angle through-hole female connector

1, LM386N, low voltage audio power amplifier

3, TACT momentary micro switch

1, THS7374, 4-Channel SDTV Video Amplifier with 6th-Order Filters and 6-dB Gain

DB1000 Driver Board

Qty, Value, Description

2, 3mm, LED

4 , W237-102 wago screw clamp

2, 2000 ohm resistor

1 ULN2003, high-voltage, high-current darlington transistor arrays

DB3000 Driver Board

Qty, Value, Device

2, 3mm ,LED

4, W237-102, Wago screw clamp

2, 10K, resistor

2, 1K, resistor

2, 1N5400, diode

2, 220, resistor

2, IRL540/IRLZ44, HEXFET Power MOSFET

Main features of the PC-to-racing cabinet interface object of this Instructable are:

1) Simplifies the convertion of a "pseudo-jamma" racing cabinet into a emulators/PC racing cabinet

2) Lets you preserve the cabinet factory CRT monitor, with sync frequency check and block of potentially dangerous out-of-sync signals

3) On-board video and audio amplifiers

4) Lets you keep the cabinet factory wheel, pedals, shifter, buttons and other controls

5) It allows you to play any Xinput-ready game/emulator

6) It handles game outputs (2 rumble signals and 8 generic outs, i.e lamps, additional motors, etc.)

7) It's open firmware!

Let me stress the first point a little more: this is NOT a solution to interface a PC to those (gorgeous) 90's SEGA Model 2/3 cabinets. Here we are dealing with generic or pseudo-generic racing cabinets with low or medium resolution CRT monitor, a rumble motor (not force feedback) and lights (i.e start button light, marquee flashers, header lights etc.).

Outputs handling is a main feature here, because games with dead lights but expecially not working wheel effects (rumble) are way less fun and appealing.

Attached is a block diagram of the whole project. As you can see, hardware maily consists of two arduino boards, a video amplifier and an audio amplification circuit.

Arduino's are a pro-micro (ATmega 32u4) emulating an Xinput device for user inputs and rumble, and a nano v3 (ATmega168P, 5V) for sync frequency check and lamps outputs.

The video amplifier is a THS7374 SMD IC, most commonly used in consoles hacking. It's handy because it has four inputs that can be disabled "on the fly" with an adeguate logic signal.

(Please notice that the 2X gain the THS7374 provides could be not sufficient to gain a decent RGB amplification for some arcade monitors (i.e. Nanao). In such case a THS7375 (5X gain) could be a better choice. The amplified sync signal passing the IC should not exceed 5V (the peak output tension for the amplifier) even with a 5X gain set, but it's worth a check (you do not want to fry the monitor ASIC). Untested!)

Separate horizontal and vertical sync signals coming from the PC are mixed into composite via a (very simple) onboard "AND" circuit made of a diode and a resistor.

(Someone reported that it could not work with some arcade monitors (Nanao's in particular) because these expect a lower than 5V voltage sync signal. There's a 4.7K Ohm resistor to ground in the c-sync line out of the video amp circuit which makes a voltage divider with the final, 1K forward resistor: by decreasing the value, the c-sync signal amplitude can be lowened if necessary).

The attached block schematic misses the onboard monaural 0.75 W audio amplifier. The circuit from the Texas Instruments datasheet is attached. It's a simple circuit built around a LM386 amplifier I have succesfully adopted in (more than) a project of mine. It's incredible how this cheap, small boy intended for portable devices fits our application.

Audio amp gain is set to "20" with some bass boost.

Please notice that this amplifier is ok to drive a classic 3 W, 8 ohms arcade cabinet speaker, but could fry if you try to amp a lower impedance (i.e. 4 ohms) or higher power (i.e. 5 W) speaker. I have tested it with 3W 8 ohm speakers and 2x1W 8 ohm speakers in series.

Please notice that LM386 are NOT all the same! Buy only amps from thrusted manufacturer or it will likely not work properly (learned the hard way here...).

(Take a look at >>THIS<< nice instructables if you want more informations about the audio amplifier here adopted.)

A on-board PANIC! button force-disables rumble by software. This way one can deactivate rumble any time something weird happens while testing new softwares or settings (...and it always happens!).

Another button (VFE - Video Force Enable) toggles the video amp sync check "on" and "off". This is for debuggin pourpouses.

Three RGB colors trimmers are there for fine color tuning and output impedance adjustment. If you are using an arcade monitor, a value of some hundreds ohm ("200" is my optimum) is generally ok at the output of the video amp (at least with Hantarex and similar monitors...). If you are instead using a TV-CRT, the resistor value must be lower (75 ohms). There are also differencies from monitor to monitor due to ageing, connections, etc. etc. and those trimmers are sufficient to take care of such differencies.

Eight screw terminals can be used to send digital output signals to dedicated driver boards. There are no driver circuits installed on-board, but two PCBs will be described and shared later on.

Analog inputs (wheel and pedals) also have dedicated screw terminals for fast connection.

Even if not present in my prototype board, the shared PCB also has room for a third momentary switch, connected to the pro micro's reset button. This is because after an Xinput firmware has been installed, to update it the board calls for a hard reset while uploading. Pro micro boards have no built-in reset button, so a dedicated switch comes handy.

Please notice: this board cannot force the VGA video signal to CGA or EGA resolutions by itself, but special softwares like soft15KHz or CRT emudrivers are needed.

There's not a standard pinout for racing cabinets, even if generic racing games often adopted that wiring for video, audio, voltages and essential digital inputs (start button, coin switch, test and service switch).

This means that, whatever racing cabinet we are dealing with, some solder will need to be melted anyway. This is why I took the “poetic licence” to place all the other digital inputs except those cited before on the P1 side of the jamma fingerboard in the hope of a simplification of some sort.

The pinout for CORSE is the following:

Outputs (lamps, coils, rumble motor/s etc) and analog inputs are kept outside the fingerboard and have dedicated screw terminals.

Potentiometer based wheels (also known as "270° wheels") are supported and actually implemented in the current sketch. It would be possible to handle optical wheels too. A dedicated screw terminal is there to connect your genuine arcade wheel potentiometer.

Two analog inputs are assignable to brake and accelerator hardwares running on potentiometers. In case the cabinet uses momentary switch based hardware, no problem: these are simply push buttons with a different shape.

Generic outputs are 8 in total, so you can handle a start lamp, two flasher lamps (Chase HQ anyone?), and another 5 lamps (who said "view lamps"?). You are not limited to lamps, anyway! Motors can also be handled, depending on the software sending data to "CORSE".

Please, notice that no driver circuits are installed on-board! An adeguate driver board is in the need for any of the loads you want CORSE to control. CORSE only translates emulator outputs to handable digital signals, but the current it can erogate out of the screw terminals is minimal (some mA), not suitable to drive a load higher than a LED with adeguate series current limiting resistor.

Two external driver boards are described in a dedicated Step of this Instructables!

I could have placed outputs on the Player 2 side of the fingerboard eventually (left unused in the pinout), but these are not JAMMA compatible and screw terminals are sometimes more practical than soldering on the fingerboard.

There are two sketches, one for each microcontroller board.

Arduino Pro-micro Sketch

Arduino pro-micro/leonardo sketch uses Dave Madison (AKA dmadison)'s Xinput library to emulate an Xinput controller. This makes it compatible with a whole lot of games, but expecially with utilities like Boomslang's FF Plugin and Howard Casto's MameHooker.

It would be possible to emulate a direct input joypad, but we would loose the rumble function. It would also be possible to emulate a keyboard, or even a mixed joystick and keyboard HID (like I did in some of my previous arcade boards), but again we would loose rumble.

A total of 12 digital inputs are available, plus three analog inputs for wheel, brake and accelerator. Brake and accelerator can be defined as digital or analog. In case of digital brake/accel, they are managed as buttons (momentary switches) and they must be soldered on the P1 inputs part of the jamma fingerboard. In case they are analogic (potentiometer based) you must activate the analog handling in the sketch and connect the three wires coming from the potentiometer to the dedicated on-board screw terminals. Accelerator and brake pedals by default are assigned to right and left trigger respectively.

A common XInput device has two rumble motors, but your arcade cabinet has only one (if factory). The sketch keeps this into account and by default sends to the motor the strongest rumble value between the two recorded. Both rumble motors signals are received, anyway, and two rumble motors could be connected to the interface board (like in the case of a custom rumble system installed in your cabinet).

The sketch includes a "rumble debug" function (disabled by default). When active, a rumble signal will be sent to the screw terminal as soon as a control panel button is pressed. Useful for debugging motor issues.

The sketch includes a "rumble watchdog" function (enabled by default). Watchdog monitors the rumble out state and disable it if active for a too long time (3 seconds, by default). Watchdog re-enable rumble after a small "quiet" time (1 seconds by default). This comes handy with games with non optimized rumbles (i.e. SEGA Super Monaco GP, to avoid stuck high rumble when navigating menus).

Analog controls (wheel, brake and accelerator) have customizable ranges. This is to take care of the limited rotation range of arcade hardwares. Usable values are already defined (bsed pn my cabinet peropherals), but user can tune them accordingly to hardware needs.

To install xinput library, follow the official library instructions page. For more informations about the library and it's capabilities, see this post by the author.

Please, notice that after the first upload of an Xinput firmware to your arduino, the board must be manually hard-resetted after the next to upload it succesfully. This is because the XInput core removes the serial interface that is used to normally send the reset signal for upload.

Arduino Nano

Arduino nano receives serial messages from softwares like Howard's Mamehooker and send them "to the real world".

Up to 8 (digital) outputs are available which is more than enought for any generic arcade racing cabinet. In my cabinet (an european bootleg of Special Criminal Investigation), I use them for the start lamp and two marquee flashers. The five left out could be used for additional "view" buttons and a leader lamp, in example. As said, outputs are not overcurrent protected and a adeguate drive board is needed to drive loads higher than some mA.

The sketch also monitors if the horizontal sync signal is of an adeguate frequency and "mutes" the video amplifier in case it's not correct.

You can define which type of monitor your cabinet is equipped with (CGA, EGA, VGA) or bypass the frequency monitoring completely by disabling the function.

Sketches for both Arduinos are available >>HERE<< (Github).

Microcontroller boards are capable of outputting small current signals in the 5-20 mA range. These are far from the capacity any load bigger than a classic 3 mm LED would call for.

Take a power LED, in example. One of those LEDs you could use to flash chase lights in a classig game like Taito's Chase HQ. Common 3W LEDs are perfect for the task. They need a current in excess of 700 mA and by powering them directly from the microcontroller GPIO would kill them.

Without going so far, even a classic 5V incandescent bulb used to light the cabinet coin box would be too current hungry for a direct GPIO connection (150-250 mA).

So, here is where Driver Boards comes to rescue. Driver boards are placed in between the load (power LED, rumble motor, etc.) and the microcontroller GPIO. When the microcontroller GPIO actuates the driver board, the load is feeded from a dedicated power source, not the microcontroller. The microcontroller only determines when the external device must be actuated.

I have designed two driver boards. One is for low current loads (max 1A), the other for higher current loads (max 3A), such as flashing LEDS and small rumble motors.

LOW POWER LOADS DRIVER BOARD - DB1000

This driver board is built around a common transistor array: the ULN2003A. This integrated circuit can erogate 500 mA on each of it's seven channels (1A total maximum!), and up to 1A if more inputs/outputs are set in parallel.

The driver board I have designed handles two inputs and the circuit adopted is the most basic, common and well documented design possible, with the addition of two LEDs for monitoring output signals.

This driver board can be used for (non inductive) loads lower than 1A. It is intended to drive (e.g.):

• 5V incandescent bulbs
• low power LED bulbs
• low power actuators

Please notice: inductive loads (motors, fans, etc.) call for a adeguately dimensioned freewheel diode. This driver board has no built-in freewheel diode.

"HIGH" POWER LOADS DRIVER BOARD - DB3000

Relatively "high" loads can be driven with this second driver board. It is based on a robust logic level MOSFET transistor (IRL540 or IRLZ44) acting as a switch, with minimal extra circuitry.

The peculiar characteristic of these two ICs is to be able to accept logic type signals at their gate and therefore be saturated with a microcontroller GPIOs 5V signal.

These MOSFETs can handle a 30A maximum current, and it is possible to solder a freewheel diode for inductive loads.

This driver board is intended to drive (e.g.)

• small/medium rumble motors (inductive load!)
• medium power LEDs (3W max)

The freewheel diode for inductive loads could be a 1N400X (current rating 1A) if the motor is small (i.e. those used in rumble joysticks) and absorbs 300-350 mA at max. One could candidate 1N540X (current rating 3A) if the rumble motor at full speed is in the 1A ballpark of current absorption. We must move to more sophisticated protection systems for higher currents. Flywheel diode current rating and load operation current rating should not approach because in its kick/starting phase an inductive load absorbs much more than it's rating current (even 10 times as much!) and could burn the diode immediately. A burnt flywheel diode means that the driver circuit will soon be damaged too.

Just for reference: I am using this board to drive a brushed motor rated @22V DC, 3A with a 20g out-of-axis weight, powered @5V. Increasing the weight, the current consumption will increase, so take this into consideration when dimensioning your rumble system.

About power LEDs, I found very handy to use those common 3W LEDs also used by Sparkfun electronics for some board of theirs. They are robust (working current 700 mA) and cost nuts. When powered at 5V, the series current limiting resistor good practice calls for is so small (a little more than 1 ohm) it can be omitted all toghether and the driver board used as-is.

A signal input LED gives a visual feedback of the existence of incoming drive signals. In this case, LEDs are placed before the driver circuit, not after like in the low power driver board.

PCB power traces have been dimensioned for up to 3A (60 mil. width).

This driver board is made of two identical circuits, then a single board can handle two separate input signals. If you need only one half of the board, you are allowed to populate only the circuit of your interest (take a look at attached pics, where I populated one almost fully for two non inductive loads, half of another for my cabinet's rumble motor).

(I wrote years ago a long post about outputs and driver boards >>HERE<<. It's a forum in my mother language (ITA), but a good translator will be more than enought for a reading. Solutions to drive loads other than those here cited are there reported (e.g. the use of solid state relays), so take a look if you are interested ;).)

Disclaimer: use these driver boards if and only if you know what you are doing. Adopting them is 100% your responsibility. Even if I have tested them in my environment and circuits adopted are well proven, I cannot guarantee they will work in yours. If anything goes wrong, it's your business.

The video amplifier is a surface mount device with 0.65 mm pitch, so I must suggest you to purchase some soldering flux to help solder that microbe. I was used to those cheap "no-clean" Rosing Mildly Activated (RMA) pen with excellent results, but lately I am preferring more dense solder flux (those sold in syringe, you know).

There are different approaches on how to solder such microbes. For me applying solder to all pads (after a generous amount of flux), positioning the IC over, re-apply flux and pass the iron over the pads/legs with a clean iron tip works the best.

I made a short video-tutorial on how to solder an IC with small pitch: take a look if you are interested ;)

Find the way that works best for you and your gear, but consider to buy at least two video amplifiers such in case one goes bad (in my experience they are very temperature sensible).

A hot air gun is not mandatory and could even be detrimental if you are not used at it.

My suggestion is to solder the video amplifier IC first. You don't want to fully assemble the PCB and then realize the amplifier needs to be reworked or desoldered.

Being the amp IC the only difficult part to solder, before proceeding soldering all the other components, I suggest you to solder only those few components needed to test the video amplifier circuit (see attached picture). Then you can proceed with other components, starting from the smallest (resistors, diodes), IC sockets, non polarized capacitors, trimmers, push buttons and female pinheaders. Screw terminals and electrolitic capacitors will be last.

Solder female pinheaders to host your microcontroller boards. If you solder micros directly there will no way you can unsolder them, not even with professional tools (believe me...). This way if some issue will rise later on with the PCB or the microcontroller board itself you will replace one or the other without problems.

Having emulators adeguately configured for outputting messages is fundamental to test your hardware and wirings.

This Step collects some info in order to have your emus configured to output rumble and lamps signals at the most basic level. This approach will reduce the risk of evaluation errors and help you having your cabinet configured in less time.

Please notice: this Step is not intended to give you emulator or frontend's fine-tuning informations. Gathering specific configuration infos on your favourite emulators/frontend is left to you and your ability in the google-fu art.

Golden rule: during testing phases, launch your emus from .cmd files, not frontends or emulators GUI. This will make games access direct and hidden options in emulator configuration files bypassed. You will set your frontend up later, as the last thing, when everithing will be working.

During testing, you do not need the final load to be connected if your driverboards have monitoring LEDs. These comes very handy in case of problems in the output circuit.

In the following I have reported a set of batch (.cmd or .bat if you prefer) files for some of the most common emulators. Examples will assume you have your emulators executables in the following directories:

C:\MAME

C:\MODEL2

C:\SUPERMODEL

and ROMs in the "roms" subfolder:

C:\MAME\roms

C:\MODEL2\roms

C:\SUPERMODEL\roms

MAME

In MAME outputs are disabled by default. You have to activate them by launching the game via the command line argument:

-output windows

The whole batch file to launch game rom "outrun.zip" will look like:

@echo off
cd C:\MAME
mame outrun -output windows 

This will activate both lamps and rumble outputs, but even with them active no messages will be sent to CORSE.

Now it's time to configure MameHooker as per official tutorial (ENG) or this unofficial tutorial (ITA). Mamehooker must be running before the emulator. MameHooker will intercept output messages from the emulator (ANY output message) and send them to external hardwares via serial messages, parallel messages and others. CORSE nano's firmware is set up to receive serial messages in the form: output pin, output state, end of message (X). In example:

lamp1=cmw 4 3., cmw 4 %s%, cmw 4 x

This tells CORSE to send the variable state (%s%) of output "lamp1" to arduino nano pin 3 (serial communication via USB).

See >>HERE<< for more info (ITA).

If your joystick inputs are not recorded in emulator menu, check that it's enabled in mame.ini

joystick             1

Be sure to define the joystick provider option (dinput or xinpunt) accordingly to your actual hardware.

joystickprovider     dinput

(Yes, even if "xinput" is an actual MAME option, set it to dinput: it's more compatible).

Additional hint: If you plan to use keyboard emulating softwares like H2Seq, you want also to set the option "keyboardprovider" to "dinput".

SUPERMODEL

Command line arguments to activate outputs in Supermodel emulator are:

-outputs=win

and

-force-feedback

A batch file to run scud race with outputs enabled is:

@echo off
cd C:\SUPERMODEL
supermodel.exe .\roms\scud.zip -force-feedback -input-system=xinput -outputs=win -res=320,240

(notice that a very low resolution has been defined).

Thi is enought to activate rumble.

For lamps out you want to configure MameHooker as per official tutorial (ENG) or this unofficial tutorial (ITA).

ROMs need to be modified with the addition of an EPROM from one of the games that already supports FFB, or force feedback / rumble will not work.

As for MAME, the use of external plugins is not necessary at testing stage.

MODEL 2

Nebula Model2 emulator development stopped years ago and it has the poorer support for outputs and force feedback between emulators here considered. This is why we go straight with external plugins.

To activate lamps and force feedback outputs you must:

• copy OutputBlaster.dll (x86) and it's configuration file in the model2 emulator directory
• copy FFBPlugin and all it's dependencies in the model2 emulator directory
• copy lua scripts in the Model2 emulator's "scripts" directory

Nebula Model2 emulator is a 32 bit software, this means you must copy the 32-bit version of outputblaster.dll to have it working, not the x64 (64-bit).

Activate FFBPlugin outputs in FFPlugin.ini (not possible directly from GUI, as far as I know) setting:

EnableOutputs=1 

(it's 0 by default).

In EMULATOR.ini there exist an option to activate force feedback. It's obsolete, so leave it as it is (do not activate it).

EnableFF=0

A collection of Model2 lua language scripts can be found in "gameassets/nebula_m2_1.17scripts" directory of another project called Back Force Feeder.

For Daytona USA, use Daytona USA (Saturn Adds) rom.

An example of batch file to launch Daytona USA (Saturn Adds) follows:

@echo off
Cd "C:\model2\"
emulator_multicpu.exe daytonas

Now it's time to configure MameHooker as per official tutorial (ENG) or this unofficial tutorial (ITA). Mamehooker must be running before the emulator.

Check "power mode" in FFPlugin GUI for all games of your interest, or rumble will be barely noticeble (or not at all).

Utilities/Plugins

FFPlugin is a good choice to gain control over rumble parameters not only for Model 2 emulator, but also for MAME and Supermodel. This has a very nice graphical user interface (GUI) and a whole lot of options. In my setup I use Mamehooker for lamps outputs and FFPlugin for rumble.

FFBPlugin needs Visual C Runtime installed to work, or it will return various missing .dll errors. Don't ask how I know :). You can download VCR >>HERE<<

Please notice that from FFPlugin dev. 2.0.0.5 (tested up to 2.0.0.31) some issue has risen. In my case, inputs are no longer working after some time (tens of seconds). I rolled back to ver. 2.0.0.4 with no issues.

In fresh windows 10 installations I have sometimes noticed some difficulty in recognizing arduino clone boards. My impression is that by simply changing USB port most of the times solves such issues (initialization issue? I don't know, but this solved in three different PC's for me so it was worth mentioning ;))

Mamehooker asks for being run as administrator the first time. This is mandatory or execution errors will chime in. It's not necessary after the first run (in my experience it could even be detrimental later on).

This step adds nothing to the whole Instructable and will likely be read only by me. I like to spend some time to look back and see how my ideas and projects have evolved over time, so I am writing it anyway.

My racing cabinet is a Taito's Special Criminal Investigation bootleg I bought around 2010. It's a nicely made cabinet that arrived to my place with 25" CRT monitor (not factory, I suspect), a potentiometer wheel, a digital accelerator pedal and a common single-switch, two positions Hi/Lo shifter.

I bought it with no game board and some topsoil (... not kidding!) over it.

Cabinet wiring was mostly JAMMA. Power supply was a bulky Hantarex US250 switching unit. TAITO actually adopted a similar pinout for some of it's racing games (Top Speed, Chase HQ, S.C.I.), but video signals where not on the JAMMA fingerboard (see attached pinout). Probably, being this cabinet a bootleg, the PCB it was sold with had a modified pinout or, even more probable, the cab was later modified.

After adding a second pedal for brake and replacing the shifter with a sequential shifter for increased compatibility with games, I was almost ready to go. I installed a brushless motor with an eccentric weight in the wheel axis for a nice rumble effect and placed two 3W LEDs under the marquee.

This was, more or less my starting point, hardware-wise.

At the time I had already converted a classic, generic JAMMA cabinet with commercial interface boards and a decommissioned pentium 4 PC. Groovymame and other Calamity's softwares where already there and Soft15Khz someway "outdated" (a brilliant piece of software it is, anyway).

So, the problem was not how to force the VGA PC output to CGA frequencies, but:

• how to handle the analog wheel
• how to manage lamps

Chase HQ is one of my favourite arcade games, so I wanted to handle both small lamps such as the "Start" button lamp often used by SEGA, and two "chasing" flasher lamps in the marquee area.

In the following, the main setup changes of my beloved racing cabinet.

Setup #1

In my very first setup I adopted a JAMMASD interface in it's first "PS/2" protocol iteration. It had built-in audio amplifier (that circuit changed over the years) and sync frequency check. That product is born with classic arcade cabinets in mind, so it could not handle analog inputs, nor any output signal.

For the steering, I went the so called "joyhack" way: you take a gamepad with analog sticks, remove the chassis, desolder one of the stick potentiometers and place your arcade wheel pot in place. Very simple and one of the most ancient approach to arcade cabinets conversions.

By using a (wired) Xbox 360 gamepad I had access to rumble signals simply by desoldering one of the two rumble motors and interposing a driver board between that output (designed for lower than 500 mA loads) and a brushless motor installed in axis with the wheel.

As driver circuit I used a heat sinked DC-DC solid state relay, a big flywheel diode and a current limiting resistor (not sure why I adopted the resistor).

A second switching power supply was added to juice the "big" rumble motor and both power LEDs.

Power LEDs had their own perfboard driver circuits very similar to those described in the "Driver Boards" Step of this Instructable. They where even optoisolated!

Outputs signlas where taken directly from the LPT port of the PC with some due current limiting resistors and no other hardware.

This setup was already working good, but...

Setup #2

The use of two independent hardwares for inputs was struggling me and when arduino and its marvels became more obvious to me, I started working for a solution.

I already had tested the possibility to replace the JAMMASD all-toghether (take a look at my very first Instructables if you dare), and that same hardware could easily handle analog inputs and emulate a direct input HID.

I only had to take care of rumble (lost in the transition from Xinput to direct input) and lamps signals. The parallel port was starting to be a weak point because already almost abandoned by PC manufacturers and a USB replacement in the need.

I solved by using a second arduino (nano v3) to handle game output messages with the same special piece of software called MAMEhooker which made all possible with the parallel port before.

Going from Xinput to Dinput broke rumble compatibility with most PC-native racing games, but MAMEHooker took my favourite emulator (MAME) on track so it was not something that critical for me.

Setup #3

When Dave Madison Xinput library was released in 2019, it was time to rethink the whole project and make some improvement.

The arduino Xinput library was a fundamental element because it represents the link between extended games compatibility (Xinput) and total control over rumble signal managing (Arduino).

This means, in example, that even in an application like ours where a single rumble motor is present (and not two as per Xinput gamepad standard configuration) you could merge the two sent by the game and have they act like you prefer instead of rely on one of the two only.

Again, you can code auxiliary routines like a PANIC function to block any rumble activity, write debuggin codes... a whole lot of possibilities for fine tuning your custom application.

In the mean time, the so called FFPlugin was released, and a lot of arcade games saw a second life thanks to force feedback and rumble support. FFPlugin is Xinput ready, so it made adopting an Xinput HID emulation the obvious way to gain access to wheel effects without having to deal with force feedback/ rumble protocols.

In this reiteration of the project I also revisited the rumble motor driver board, finally adopting the circuit I posted in the "Driver Boards" Step of this Instructable.

In this setup I also removed the bulky Hantarex US250 and left a sigle switching power supply. It was more than enought to handle the currents needed and a waste of energy to keep both PSUs running.

With respect to setup #2, the arduino nano in charge for serial communication (lamps managing) was here in charge also for sync frequency check and video amplification block, freeing the pro-micro from the task.

Everything was realized on perfboard up to here.

Setup #4

All those wires from the perfboard and the JAMMA fingerboard were annoying me since day one, then as soon as I started toying with eagle CAD I had to develop a dedicated PCB. I actually realized two prototypes, with minor differences. The project was baptized with the name "CORSE" and for the first time pubblicy described in a forum.

Interface PCB and a mini driver board (analogous to the one here presented on Step #4 but with no feedback leds) for the start button were on dedicated fiberglass PCBs.

Driver boards for rumble motor and flashing LEDs where still on perfboard.

Up to here the audio amplifier was external to the interface board and based on a 14w TDA2030 integrated circuit.

Setup #5

This is the current setup, described in this Instructable.

It differs from setup #4 in the built-in audio amplifier and driver boards on PCB's instead of perfboard, and some minor modification (i.e. the video force enable button).

It also differs in a rethinking of the cabinet wiring (it was not-that-good before) and some improvement in the Xinput sketch.

From setup #4 I kept into consideration others solutions shared across the internet and gave a try to adapt some of them to this task (a generic, almost-JAMMA racing cabinet convertion). My intention was to push this project to a different level and use a single microcontroller board, if possible. I still found with my "two micros", "generic" Xinput way preferrable against the development of a more complex protocol-enhanced solution. Why? Well, because I someway fully understand it and I do not run the risk to end with something not working :)

Setup #6

Just kidding! There's not a sixth setup... yet ;)

Yes, I spent time and money on this project, but especially: YES, I LOVE MY RACING CABINET! :)

A special "Thank You" goes to those nice girls and guys at JLCPCB. It is at least two years I designed the first prototype of this interface board (I am not kidding!), but it had some flaws. This sponsorship made me put it back on track with the additions I had in mind (one for all: the built-in audio amplifier), some routing fixes and the design of the two driver boards.

JLCPCB is a high-tech manufacturer specialized in the production of high-reliable and cost-effective PCBs.

They offer a flexible PCB assembly service with a huge library of more than 350.000 components in stock. 3D printing has "recently" been added to their portfolio of services so one can create a full finished product all in one place!

Their customer service is responsive and helpful and PCBs a great value for the money.

By registering at JLCPCB site via THIS LINK (affiliated link) you will receive a series of coupons for your orders. Registering costs nothing, so it could be a nice opportunity to give their service a try ;)

Gerbers for both Driver Boards and CORSE Interface Board are available >>HERE<< (Github).

My projects are free and for everybody. You are anyway welcome if you want to donate some change to help me cover components costs and encourage the development of new projects.

>>HERE<< is my paypal donation page, just in case you want to push the development of new projects ;)