Recent Posts

I think it might be hard for anyone who doesn't engage in a subtractive art like this to appreciate it fully.

True dat. The guy who made the viking that I copied also made some cute gnomes. Now take a wild guess which ones most people liked more 

I have been meaning to write a step by step of how to do this without soldering. This is not the best description but at least it can help someone. I still need to get on one of my cabs and copy up the full Arduino code. The previous Arduino code was for lighting up a single led but for my steps below, it lights up a full ws2812b strip when in first place.


No soldering needed at all. Code is mostly ready to go except you may need to change the number of leds or what led to start the lights at (since some of the leds are outside of the marquee and I don’t want them to light up). Using an arduino with pre soldered connectors, wires that connect directly to the arduino, and using a barrel connector that has screw terminals also helps make this solderless.


1) Unwind the whole ws2812b led strip (since we want the end of the strip wound up the most on the inside)
If you look at the strip, in between each led has an arrow pointing a single direction. This arrow should point up away from the bottom of the cable. In other words, the arrows will end up pointing from the Arduino toward the marquee end (data flows from Arduino toward the end of the led strip or from “RA in RAce leadER to the “ER” at the end of the leader word)
2) Insert a (male) wire into the bottom of the cable into the black piece so one wire goes into the hole where the white cable is and insert another (male) wire where the green cable is and then add on a female to female adapter at the end of both of those (so it can then plug into the Arduino).
3) Put the cable you added that continues the white cable and plug this into the gnd on the Arduino 
4) Put the cable you added that continues the green cable and plug this into D3 on the Arduino
5) Strip the ends of the white and red wires that dangle out of the end of the led strip
6) Put the white striped wire into the negative side of the barrel connector and insert the red wire into the positive side of the barrel connector (screw terminals)
7) Count out 40 leds (or a different number if desired) from the led strip cutting half way beteeen the copper pads after the 40th.
Connect a mini usb cable to the Arduino and plug this into your pc
9) Plug in the electrical outlet (connected to the barrel cable that has the red and white wires in it).
10) Download Arduino Ide, start it up, on top menu go to tools >  board > change to Arduino nano
11) Go to tools > port > change com port to your com port for the usb you just plugged in. (If unsure, unplug the usb and see which com number goes away in the menu and which one comes back after plugging back in). Note If you get an error about port conflict when uploading or later on in future steps, right click mamehooker (assuming you already installed it before step below) in your bottom right tray icon and close. Mamehooker takes over your com port.
12) Paste in the code below (code to be uploaded soon hopefully)
13) Click the checkbox near top left to compile and then click the right arrow icon to the right of that to load the program (sketch) onto the Arduino
14) In the ide, Go to tools > serial monitor > type in “3,1,x” without the quotes and hit enter. And then type in 3,1,x again and hit enter key . It should light up. If it does not, review the steps and verify you are on the correct com port in the Arduino ide and the Arduino sketch was uploaded to the Arduino. Also try turning the barrel connector slightly (one time I had to twist it slightly for some reason)

15) Download mamehooker by going to here (http://dragonking.arcadecontrols.com/static.php?page=aboutmamehooker) and hit control-f and find “mamehooker” and there is a download link on the right side of the web page
16) Install it (i installed to c:\mamehooker\*) and then right click mamehooker.exe and choose run as admin (MUST DO THIS FIRST ONCE! Ignore errors if any!)
AFTER YOU HAVE RUN AS ADMIN ONCE, go to bottom right system tray in windows and right click and close mamehooker and ignore any errors if any (first time run as admin is necessary for permissions).
17) Now open up mamehooker.exe again from bottom right Windows system tray WITHOUT running as admin option (from now on no admin needed as long as ran once)
Click options and allow auto find of parameters.
18) Go to your Mame folder that you have Mame.exe installed in and find the Mame.ini file (IF YOU HAVE <game>.ini files named as the game, you have to do change those ini files. as well) and update the ini so the line that says “output” is set to “windows”.
19) Open up Mame and open up a game that has outputs like sfrush and let mamehooker find the outputs. It should auto create a sfrush ini file
Change the mamehooker sfrush.ini to look like below (need to upload this as example as well but earlier posts may have it). I will also attach other mamehooker ini settings that I have.
20) Change the number 4 (4?) in these mamehooker ini files to the com port your Arduino took.
If desired, change the 3,1,x to start with another number (2,1,x for green. 4,1,x for blue, etc)
21) If desired, Download the non-commercial license Arcade1Up marquee 3D print and edit in 3D print software (I use Cura) to be 35% on the height and width (I kept length the same) and 3D print it.
22) Purchase a see through RACE LEADER marquee print from ArcadeGraphix if desired
23) Purchase the black see through plexi glass from Tap Plastics here (https://www.tapplastics.com/product/plastics/cut_to_size_plastic/black_led_sheet/668?gad_source=1&gclid=Cj0KCQiAgK2qBhCHARIsAGACuzmFTLacS1j_ct4d6jj8vSLcML676miM_Vqhu0mv0N58fzFFmexLrvcaAlp4EALw_wcB ) if desired for blacked out look when not on. Size info for my particular size marquee was “Chemcast Black LED Acrylic - Black 1/8 (.118)" Thick, 1-1/2 inches Wide, 17-9/16 inches Long, Color: Black
24) Get in 1st place and Enjoy!!

If you want to add custom race leader lights to games that don’t support it out of the box, see posts above.

For those interested, on Discord there has been updates to latest output blaster fork to get Outrun2 race leader lights working which I confirmed does work (after upgrading to latest Teknoparrot version and enabling output checkbox in TP after copying output blaster needed dll to the lower level game folder). They are also working on FnF Supercars (they have the memory region now) and possibly Mario Kart. Crusn Blast has a code snippet about race leader so not sure if that already works or will need to be created. So some great progress is being made!

Thanks, and it's no problem.

By the way, thanks for that reply ThatOneSeong. It was enlightening. I think choices like this get made earlier on in making a program and then get harder and harder to fix later on. So it just becomes the way it is.

Right.
Keep in mind that I'm not trying to be too harsh (even though I did just call it "dumb") - all the lightgun emulation code was, in all likelihood, developed all the way back in the mid-2000's - when most people already were running 4:3 displays/didn't have a PC lightgun solution at all at the time, so the issue wasn't as prevalent for the person implementing it to take action. I wouldn't be surprised to hear if there's some underlying tech debt left in MAME's code that makes it difficult to resolve--and/or just not enough interested persons around to fix the issue, probably from complacency in the PC light gun community... coughGun4irCough.

Regardless, glad to hear that RetroArch's been working for y'all!

(And for those of you who haven't used DemulShooter yet, yes, it relies on hooking directly into the individual mouse object - that's how it gets multi mice to work after all. So I'm guessing you'll want to load it up while your software is running? The -useSingleMouse option effectively just has DS use the general Windows cursor. I only know this because of having to use it as a workaround on Linux, since Wine currently does not expose individual mouse devices yet.)

Hi Yolo!

Well, I’m convinced after much testing Airborne’s steering re-centering is entirely different to hard/race/street drivin’. The centering encoder signals are completely ignored. For Airborne, when your car re-spawns after crashing, whatever the wheel position your steering wheel is in at that time becomes the new center (regardless of angle). The center position can also self adjust during play should you oversteer (Say that you rotate the wheel 3 times clockwise to go round a tight turn. You’ll only need to do roughly one anit-clockwise rotation for the car to go in a straight line again).

I came to the conclusion that this game can only really be enjoyed with a mouse/spinner. Even then it would need force feedback so you had a feeling of where the steering center is.

Then I had a thought which was followed by a hack which might help...

I modified hdc68k_wheel_r() for airborne. I took out the steering latching stuff. I’ve added a key ‘S’ that can hold to adjust your steering wheel back to center during play. Here’s how it works:

Say that you are playing the game, you want the car to go straight, your steering wheel is in its central position but the car is pulling to the right.  To fix this you need to turn your steering wheel left (Until the car is moving in a straight line), then press and hold the ‘S’ key,  then turn your steering wheel to its central position, and release the ‘S’ key. That’s it.

I know its not really an ideal solution, but it might improve the game experience and help us get better laps times

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, I've changed this line:-

Code: [Select]

PORT_BIT(0xfff, 0x200, IPT_PADDLE) PORT_MINMAX(0x000, 0x3ff) PORT_SENSITIVITY(100) PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Steering Wheel")
to this...

Code: [Select]

PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

Then in harddriv_m.cpp, replace the hdc68k_wheel_r() function with this...

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
// grab the new wheel value
uint16_t new_wheel, raw_wheel = m_12badc[0].read_safe(0xffff);
int wheel_diff = 0;
bool is_wheel_increasing = false;
static uint8_t wheel_snapshot = 0;
static uint8_t wheel_offset = 0;
static bool steering_enabled = true;

if (machine().input().code_pressed(KEYCODE_S))
{
if (steering_enabled)
{
popmessage("Steering disabled (Re-center your wheel now...)");
steering_enabled = false;
wheel_snapshot = (m_hdc68k_last_wheel+wheel_offset)&0xff;
}

return ((wheel_snapshot << 8) | 0xff);
}
else
{
if (!steering_enabled)
{
popmessage("Steering enabled");
steering_enabled = true;
wheel_offset = (wheel_snapshot - raw_wheel)&0xff;
m_hdc68k_last_wheel = raw_wheel;
}
}

// Work out which way the wheel is spinning
if((m_hdc68k_last_wheel < 0x400) && (raw_wheel > 0xC00))        is_wheel_increasing = false;    //Wrapped from bottom to top
else if ((m_hdc68k_last_wheel > 0xC00) && (raw_wheel < 0x400))  is_wheel_increasing = true;     //Wrapped from top to bottom
else if(m_hdc68k_last_wheel > raw_wheel)                        is_wheel_increasing = false;
else if(m_hdc68k_last_wheel < raw_wheel)                        is_wheel_increasing = true;

//Steering damping:
//Ensure we don't jump from one encoder value to another too quickly confusing the game
//The game is aware only of changes to m_12badc's lower byte. This means the game can get easily confused if you where to move
//the wheel very quickly from say position 0x800 to 0xC12 in one cycle (Which was perhaps physically impossible using the
//actual arcade encoder). The game would be under the impression the wheel has moved only 0x12 values, rather than 0x412 values.
//If we detect a large change, slowly feed that information back to the game in managemtble amounts.
new_wheel = m_hdc68k_last_wheel;
while(new_wheel != raw_wheel)
{
if (is_wheel_increasing)
{
if (new_wheel >= 0xFFF) new_wheel = 0x000;
else new_wheel++;
}
else
{
if (new_wheel <= 0x000) new_wheel = 0xFFF;
else new_wheel--;
}

//Lets say the encoder can't move more that 32 teeth per cycle...
if (wheel_diff++ > 0x10) break;
}

if (machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("wheel=0x%04X", new_wheel);
}

m_hdc68k_last_wheel = new_wheel;
return ((new_wheel+wheel_offset) << 8) | 0xff;
}


Hi Geecab,that is a really good solution for the Hard Drivin' Airborne off center bug. I'll need to try it out and see! I'm thinking it would be more responsive when turning the wheel compared to the EMA buffering code I'm currently using to stop it going off center because it adds a very slight latency to the wheel.

Just thought I'd mention this because you seem to be confused about Street Drivin's steering wheel behaviour. Street Drivin's steering is different from Race Drivin' Compact, Hard Drivin' Compact, the cockpit versions AND different from Airborne.

Street Drivin' doesn't have the "steering going off-center bug" when you crash or when you go offroad or even if you turn the wheel too fast etc, it never goes out of alignment. Only the compact versions have that and Airborne. The only reason it seemed to be happening in Street Drivin' before is because the steering range was the same as the others (0x010, 0xff0), when it was changed it to 0x000, 0x3ff it completely fixed the steering, it stops the bug that happens when you steer to the maximum left or right. The change of the PORT_MINMAX to (0x000, 0x3ff) fixed that bug for Airborne too but Airborne has the same bugs that the compact versions have but unfortunately your solution for the compact versions doesn't fix it for Airborne.

BTW I'm now sure that Street Drivin's ROM is actually a cockpit version and I'm even more certain of that now because if you look at the ROM's that get loaded into the main program memory it shares ROM's with Race Drivin' Panorama which on MAME is a cockpit ROM and not a compact. None of the cockpit ROMs are compatible with the compact except the sound ROM's and Jed Margolin even mentions that fact on his website. You can try it for yourself, Street Drivin' already plays perfectly!

Just thought I'd mention it because it could help narrow down the problem Airborne is having because they both have the same steering wheel range in common but Street Drivin' doesn't do the wheel edge/centering stuff the same as any of the others and that is why it doesn't have the bug you were experiencing on the compact versions or Airborne.

I noticed the first set of ROM's in the main program seem to be the ones that contain the test menu code. I was able to load up the Race Drivin Panorama version of the test menu in Street Drivin' by swapping the ROM's over but it made the screen garbled too. It was all readable and seemed to work but had strange values and the writing just looked weird like the resolution is set wrong or something.

I've gave up on my mission of trying to make Street Drivin' have gears by fiddling with the ROM's because today I found out that the Race Drivin' Panorama has the extra stock car track and even has the drone cars from Street Drivin' on it. The only problem i noticed with it was the frame rate even when using my overclock. I fixed this by loading up only the main PCB ROM's and not the left and right PCB ROM's using the Race Drivin' cockpit machine configuration and now the game plays smooth. I think it's because there is a hack in the MAME source code that's used to get the 3 screens in sync and even when you choose 1 screen only in the MAME video options it still seems to be using that hack and using the side PCB's.

Now, I've been using this for a while and have a few callouts to anyone who is thinking about designing a similar one.

1. If you're going to build a 4-player cab like mine, then 1 big mistake I made is with how the display is inset. This is more of a 3-player build now even though it supports 4 players. If you look closely, the display is about 4 inches into the cabinet. The IR LEDs then surround the screen. Well, the lightguns can only see all 4 IR LEDS if relatively in front of the screen. The ~4-inch inset of the display causes the sides to act like flaps that block the IR. So if you are too far off to the side, then only 3 sensors will be visible. Only 3 people can visibly stand in front of the screen and see all 4 LEDs.

I should have cut the sides in more so that they're flush with the edge of the screen.

2. soldering the gx16 was pretty tight since it needed to accommodate wire that was thick enough to handle 24v at ~3amps. Between the sockets, cables, and lightgun, it means that you're going to be soldering 16 tiny ends that barely fit into the casings, and then make sure that there are no shorts. I'd still do it again because I think it's worth it, but it's probably the most tedious part of the build. I'm looking to limit mine to 2 people only, but that's still something for me to consider If I ever wanted to add additional guns it's definitely something I should plan for on the front end of things.

3. I got the Streamdeck partially because I thought that I could use it for keyboard events as well. I.e., have all of the Dreamcast buttons available to navigate game menus and whatnot. Unfortunately, the thing does not support raw keyboard events. It sends system events. This means that emulators which rely on raw input (such as Flycast) cannot use the Streamdeck to send keys because it either support SDL or raw input, but not both. Emulators that support SDL are ok though.

Not too much, but I mostly wanted to call out #1 since it's a pretty important defect.
 
FINALLY, I've attached my sketchup plans to the original post in case anyone wants to use them as a base.

Thank you for taking the time to share and be so detailed with how your process went. I imagine I'm far from the only person who has been considering such a similar build and your sketchup file really breaks it down ( I had started doing something similar with graph paper and you just saved me probably weeks of time!) Additionally, I was curious about how the stream deck fit into your overall build. Finally, just want to say the finished product is truly a piece of art

Awesome, glad to hear it works.


I was anticipating a problem like that. But it would've been when clicking in off-screen and re-entering screen area before releasing the click could've caused reload to be stuck on.

But I figured out a way to handle that by releasing both left and right click. Which was a better way than how I first planned to handle it.

I didn't think of what you found but I agree probably not worth fixing atm.

Any more things to fix while I'm on a roll? lol 😆

Works great, I upped the X borders to 480 so shots in the black borders at 4:3 would be counted as off-screen too and that works fine. The only edge case issue I could find is if you hold down the trigger, enter the border/exit the screen, then return to the screen, it'll send a reload. But this is so minor it isn't even worth fixing, I doubt anyone would run into it and it doesn't cause any problems. No issues with forced scaling, maybe I'll wind up using DS more now, I think HotD3 might have some slight control issues for route selection without it.

Hi Yolo!

Well, I’m convinced after much testing Airborne’s steering re-centering is entirely different to hard/race/street drivin’. The centering encoder signals are completely ignored. For Airborne, when your car re-spawns after crashing, whatever the wheel position your steering wheel is in at that time becomes the new center (regardless of angle). The center position can also self adjust during play should you oversteer (Say that you rotate the wheel 3 times clockwise to go round a tight turn. You’ll only need to do roughly one anit-clockwise rotation for the car to go in a straight line again).

I came to the conclusion that this game can only really be enjoyed with a mouse/spinner. Even then it would need force feedback so you had a feeling of where the steering center is.

Then I had a thought which was followed by a hack which might help...

I modified hdc68k_wheel_r() for airborne. I took out the steering latching stuff. I’ve added a key ‘S’ that can hold to adjust your steering wheel back to center during play. Here’s how it works:

Say that you are playing the game, you want the car to go straight, your steering wheel is in its central position but the car is pulling to the right.  To fix this you need to turn your steering wheel left (Until the car is moving in a straight line), then press and hold the ‘S’ key,  then turn your steering wheel to its central position, and release the ‘S’ key. That’s it.

I know its not really an ideal solution, but it might improve the game experience and help us get better laps times

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, I've changed this line:-

Code: [Select]

PORT_BIT(0xfff, 0x200, IPT_PADDLE) PORT_MINMAX(0x000, 0x3ff) PORT_SENSITIVITY(100) PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Steering Wheel")
to this...

Code: [Select]

PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

Then in harddriv_m.cpp, replace the hdc68k_wheel_r() function with this...

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
// grab the new wheel value
uint16_t new_wheel, raw_wheel = m_12badc[0].read_safe(0xffff);
int wheel_diff = 0;
bool is_wheel_increasing = false;
static uint8_t wheel_snapshot = 0;
static uint8_t wheel_offset = 0;
static bool steering_enabled = true;

if (machine().input().code_pressed(KEYCODE_S))
{
if (steering_enabled)
{
popmessage("Steering disabled (Re-center your wheel now...)");
steering_enabled = false;
wheel_snapshot = (m_hdc68k_last_wheel+wheel_offset)&0xff;
}

return ((wheel_snapshot << 8) | 0xff);
}
else
{
if (!steering_enabled)
{
popmessage("Steering enabled");
steering_enabled = true;
wheel_offset = (wheel_snapshot - raw_wheel)&0xff;
m_hdc68k_last_wheel = raw_wheel;
}
}

// Work out which way the wheel is spinning
if((m_hdc68k_last_wheel < 0x400) && (raw_wheel > 0xC00))        is_wheel_increasing = false;    //Wrapped from bottom to top
else if ((m_hdc68k_last_wheel > 0xC00) && (raw_wheel < 0x400))  is_wheel_increasing = true;     //Wrapped from top to bottom
else if(m_hdc68k_last_wheel > raw_wheel)                        is_wheel_increasing = false;
else if(m_hdc68k_last_wheel < raw_wheel)                        is_wheel_increasing = true;

//Steering damping:
//Ensure we don't jump from one encoder value to another too quickly confusing the game
//The game is aware only of changes to m_12badc's lower byte. This means the game can get easily confused if you where to move
//the wheel very quickly from say position 0x800 to 0xC12 in one cycle (Which was perhaps physically impossible using the
//actual arcade encoder). The game would be under the impression the wheel has moved only 0x12 values, rather than 0x412 values.
//If we detect a large change, slowly feed that information back to the game in managemtble amounts.
new_wheel = m_hdc68k_last_wheel;
while(new_wheel != raw_wheel)
{
if (is_wheel_increasing)
{
if (new_wheel >= 0xFFF) new_wheel = 0x000;
else new_wheel++;
}
else
{
if (new_wheel <= 0x000) new_wheel = 0xFFF;
else new_wheel--;
}

//Lets say the encoder can't move more that 32 teeth per cycle...
if (wheel_diff++ > 0x10) break;
}

if (machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("wheel=0x%04X", new_wheel);
}

m_hdc68k_last_wheel = new_wheel;
return ((new_wheel+wheel_offset) << 8) | 0xff;
}