Recent Posts

I use an iPac 4 in my system that is full. Does anyone know if there is a way to add more controls by adding an iPac 2. What does the "enable expansion interface" check box do?

Hi.

Building a new cabinet using 2x seimitsu ls-40 01 joysticks. Got one hooked up to the pc running mame through a usb encoder using the 5 pin cable, works fine, configured in windows fine and this translates to use in my front end and games.

Problem I’m having is that the second stick won’t calibrate reliably. When plugged in to a second encoder board the windows calibration tool either doesn’t detect the stick and when flipping the 5 pin around detects it but it’s as if the crosshairs for the axis calibration is stuck in the right where it only moves when 2 of the direction microswitches are pressed (holding joystick in a diagonal manner) this again, translates to in game and is completely unusable. I’ve tried swapping out boards and using different cables both one way and another and nothing. The stick looks fine, no damage and was brand new. Trace/pcb look fine and microswitches look ok as far as I can tell. Just don’t understand why it won’t calibrate.

I’ve got in touch with the retailer but was wondering if maybe it’s something I’m doing wrong here? As the first stick was just plug and play. I’ve tried even removing all other buttons from that sides encoder board to just have the joystick but to no avail.

Any help would be appreciated, I’m pretty new to this!

I’ve tried searching the forum but can’t see anything close to what my problem is, and I’m at a complete loss!

Thanks for your time in reading this, appreciate any replies.

Dan.

Has anyone used UV prefinished plywood to build an arcade cabinet? How does vinyl do on it?

Hi there!

 Unfortunately, my mind is a bit hazy regarding my hard drivin' fix/hack but will try and help as best I can.

A few things off the top of my head:

1. My fix was to make hard drivin’ play ok with mouse/spinner, rather than a SteeringWheel/Joystick (that has a fixed centre). So I’m a bit concerned that porting whatever I did back in 2013 might not help much.

2. You’re probably already aware of this, but I’ll mention it anyway - My fix only worked for the Compact British version of hard drivin’ roms (That expects optical encoders for steering, and did the weird centre point latching thing). The full cockpit versions of hard drivin’ & race drivin’ used potentiometers for steering. I am guessing when you say hard drivin’ & race drivin’ are working fine for you, that you must be using the cockpit roms? I don’t suppose there are any street drivin’ or airborne roms available for cockpit cabinets are there?

I have to say, I am fascinated to know what’s going on with this steering/latching stuff again, so at some point soon I’ll get building mame again and try to recreate what you are seeing (I’d also like to have go at street drivin’ and airborne too 😊)!

Thanks for your reply, but I'm not sure that's the same problem.
1. Regular mame does not have the problem
2. When disabling modeline_generation it works at the correct speed

It seems to be a bug in switchres picking a wrong mode line for the game

Hi all,

I bought a 4 player ready arcade cabinet, which came with all the connectors for it to work. I wanted to build my own pc to work within the cabinet and did so. There were a couple of issues where the coin button for P1 and P2 were the same key along with a couple of conflicts with players 3&4. When I was trying to fix this I downloaded winIPAC V2, ever since installing this P3 & P4 buttons no longer register.

I've since plugged the JPAC board for P3 & P4 into another machine and ran winIPAC V2, a message: No board is shown. If, however I unplug the usb winIPAC closes as if it could see there was a JPAC there.

In windows JPAC is shown in the devices screen. Have I broken it or is there a way to reset it?

Thanks in advance,

Gary

Hi GEECAB!

 Thank you for the debrief which looks so good!!

Of course really looking forward to testing this update

Congratulations and thank you 

That's something that should be implemented on the gun side.

Sure, but what if it's not possible? I do think having a settable border where on-screen left clicks are treated as off-screen right clicks by demulshooter is useful for certain aspect ratios on any gun, in the modern day most screens are 16:9 which means shooting off-screen to the sides in 4:3 games requires extra movement.

Hot take: using right clicks for a different trigger pull action is incorrect behavior.
It should be able to function like MAME, RetroArch, and PCSX2 does, where the game/emu can differentiate left click/trigger pulls between on-screen and off-screen and change its behavior accordingly. Right-click to reload has always been kind of a dirty hack for emulators or games that failed to consider this, imo.

Do these emulators actually differentiate? I thought they just took an external secondary input, like right click, and mapped that to reload, which requires the gun software/hardware to send a different input for on-screen or off-screen trigger events. Right-click has become the de-facto standard for this, probably because it made sense for windows ports with mouse support.

Hi, sorry for replying to such a old thread but i have been trying to make a steering wheel hack for hard drivin's airborne i managed to stop the bug in the new version of mame that made the car do donuts and the same for street drivin' and i managed to get the brake input working on it so it's now playable but hard Drivin's Airborne does this weird thing where the steering goes out of alignment when you crash the car and hold the wheel left or right untill the car respawns. When you crash the car the wheel edge value gets reset to =0 and the game seems to use the position the wheel was in at that moment to set a new center point.

 I was able to make a code mod that applied a offset to recenter it when this happens but once the offset is greater than 127 the wheel starts pulling to one side badly again. I tried forcing the center value of the wheels port_minmax to be sent as the wheel position at the exact moment that wheel edge =0  and then watches for wheel movement going past the center point to set it to 1 again as usual but that code doesnt seem to work maybe because the game reads the wheel positions value too fast before the mame driver can intercept it? I've been told that Hard Drivin's Airborne uses a spinner wheel in the original prototype hardware and that this is the reason why only this game has this behaviour. All the other hard drivin's/race drivin's are working fine.

Street drivin would make the car go in circles and i modded the code for that and i fixed the brake input being mapped to the wrong 8 bit ADC channel and the steering fix works on airborne to stop the car going in circles too and it's been merged into the latest version of the mame source code on github but i've been trying now for a couple of weeks to fix this bug in airborne and cannot get my code to work it's close but the maths behind it just doesn't work. I googled some keywords to see if i could find more info and found this post from 2013 where you seem to have basically made a fix for the old version of mame that im sure could fix the wheel alignment problem in Hard Drivin's Airborne. I cannot work out how to get your older code to be modified correctly to work in the latest version of mame and was wondering if you could maybe have a look at it again?

I'll post my almost working code below. It's replacing the wheel latch code in the harddriv.cpp file. I'm using a Logitech G923 wheel.

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
    static const uint16_t g_latchpoint = 0x800;  // Central point for wheel detection.
    static int16_t wheel_offset = 0;             // Cumulative offset to adjust the wheel position based on game events.
    static bool last_wheel_edge = false;         // To track the last state of crossing the center.

    // Read the current wheel position from the 12-bit ADC port.
    uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff);

    // Apply the cumulative offset to align with the game's perceived center.
    int16_t new_wheel = static_cast<int16_t>(new_wheel_raw) + wheel_offset;

    // Clamping the wheel position to avoid overflow and keep it within expected range. I found out that this helped stop the steering drifting off center when you hit the 2nd last checkpoint on the mountain track.
    const uint16_t min_clamp_value = 0x063A; // Observed minimum value when wheel is turned all the way to the right
    const uint16_t max_clamp_value = 0x09C6; // Observed maximum value when wheel is turned all the way to the left
    if (new_wheel < min_clamp_value) new_wheel = min_clamp_value;
    if (new_wheel > max_clamp_value) new_wheel = max_clamp_value;

    // Edge detection logic to detect being at or crossing the center point using raw ADC data.
    if ((m_hdc68k_last_wheel < g_latchpoint && new_wheel_raw >= g_latchpoint) ||
        (m_hdc68k_last_wheel > g_latchpoint && new_wheel_raw <= g_latchpoint) ||
        new_wheel_raw == g_latchpoint) {
        m_hdc68k_wheel_edge = 1;  // Set edge flag when at or crossing the center based on raw input.
    }

    // Check if the wheel edge flag has changed from 1 to 0, as reset by the game.
    if (last_wheel_edge && !m_hdc68k_wheel_edge) {
        int16_t new_offset_adjustment = g_latchpoint - new_wheel_raw; // Calculate the offset adjustment
        new_offset_adjustment /= 1; // Significantly reduce the impact of each adjustment
        wheel_offset += (new_wheel_raw > g_latchpoint) ? -new_offset_adjustment : new_offset_adjustment;
        wheel_offset = std::clamp(wheel_offset, static_cast<int16_t>(-0xfff), static_cast<int16_t>(0xfff));  // Cap the offset to 3-digit hex range
        new_wheel = static_cast<int16_t>(new_wheel_raw) + wheel_offset; // Reapply the updated offset.

        // Re-clamp the wheel after offset adjustment
        if (new_wheel < min_clamp_value) new_wheel = min_clamp_value;
        if (new_wheel > max_clamp_value) new_wheel = max_clamp_value;
    }

    last_wheel_edge = m_hdc68k_wheel_edge; // Store the last known state of the wheel edge flag.

    // Display current wheel information for debugging.
    popmessage("Wheel Raw: %04X, Wheel Adjusted: %04X, Edge: %d, Offset: %04X (Hex), %d (Dec)",
           new_wheel_raw, new_wheel, m_hdc68k_wheel_edge, static_cast<uint16_t>(wheel_offset & 0xFFFF), wheel_offset);

    // Store the current wheel value for the next comparison.
    m_hdc68k_last_wheel = new_wheel_raw;

    // Return the processed wheel value, formatted as required.
    return (static_cast<uint16_t>(new_wheel) << 8) | 0xff;
}


Thanks Scott