Fixed steering issues in strtdriv and hdrivair harddriv.cpp

[Madcadden]

Edited the PORT_BIT and PORT_MINMAX mask to stop wheel values going out of range and screwing up the centre point of the steering wheel so the vehicle doesn't pull to one side anymore. Vehicles still have the full range of motion on the steering wheel axis.

[angelosa]

1. 0x800 is for the default center position, iirc should throw an input warning to stdout/stderr. Should be changed to 0x200
2. the PORT_SENSIVITY is extremely high, I thought that clamps to 255?

[Madcadden]

The port sensitivity in the code is 400 by default for all the games in this driver i didn't change that. The centre position can't be changed from 0x800, even though the Port Bit mask has changed to 0x3fe the 0x800 is still the centre point of the 12 bit ADC port range. Changing it to 0x200 just stops the steering from working at all. I already tested it. The steering now works correctly.

[Madcadden]

2. the PORT_SENSIVITY is extremely high, I thought that clamps to 255?

I just realised i have the sensitivity on my Logitech wheels software is set really low, i will increase it to default and play the game and see how it feels, if it is too twitchy or glitches at 400 when the wheels set to a higher sensitivity in the Logitech software i'll try the 255 you just mentioned.

[Madcadden]

I just tested it with my Logitech wheel sensitivity set to default in it's software app, i had it set really low before to mitigate the steering wheel centring glitch in Street Drivin' and Hard Drivin's Airborne. With the sensitivity in the wheels software set to lowest it was a lot less likely to happen. Now that's fixed it actually feels much more responsive and better when I'm steering in the game with the wheels sensitivity at default, it feels like it should do IMO. I'm glad that others will now be able to play the games as they were intended! BIG respect to all the Atari staff who made these games and the MAME devs who made it possible for us to play these classics!

[Madcadden]

1. 0x800 is for the default center position, iirc should throw an input warning to stdout/stderr. Should be changed to 0x200

I went into the test menu and checked the values in the 12 bit adc ports and when the wheels in the centre the value = 200 so it's bang on even though it's set to 0x800 in the Port Bit mask which seems counterintuitive but works perfectly.

[cuavas]

If it’s working, it isn’t for the right reasons. The default value will be masked with the field mask, so setting it to 0x800 when the field mask is 0x3ff will have the same effect as setting it to 0x000.

You also seem to misunderstand how the various values are used. When you have an absolute analog axis control (e.g. your Logitech wheel) assigned to an absolute analog axis input (e.g. the steering in these games), the active range of the control will be mapped directly to the min/max range of the emulated input. The default value and sensitivity won’t be used at all.

The sensitivity is used when a relative analog axis control (e.g. a mouse/trackball axis) or digital controls (e.g. keyboard keys for increment/decrement) are assigned to an absolute analog axis.

The default value is used for auto-centring when you’re using the increment/decrement assignments (e.g. using keyboard keys to control steering).

The logic is described here: https://docs.mamedev.org/techspecs/inputsystem.html#updating-absolute-analog-fields

@angelosa is correct that the change is not correct as-is. The sensitivity likely needs to be reduced for the decreased range. You also need to test using the increment/decrement assignments.

I’d suggest something like:

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

[Madcadden]

If it’s working, it isn’t for the right reasons. The default value will be masked with the field mask, so setting it to 0x800 when the field mask is 0x3ff will have the same effect as setting it to 0x000.

You also seem to misunderstand how the various values are used. When you have an absolute analog axis control (e.g. your Logitech wheel) assigned to an absolute analog axis input (e.g. the steering in these games), the active range of the control will be mapped directly to the min/max range of the emulated input. The default value and sensitivity won’t be used at all.

The sensitivity is used when a relative analog axis control (e.g. a mouse/trackball axis) or digital controls (e.g. keyboard keys for increment/decrement) are assigned to an absolute analog axis.

The default value is used for auto-centring when you’re using the increment/decrement assignments (e.g. using keyboard keys to control steering).

The logic is described here: https://docs.mamedev.org/techspecs/inputsystem.html#updating-absolute-analog-fields

@angelosa is correct that the change is not correct as-is. The sensitivity likely needs to be reduced for the decreased range. You also need to test using the increment/decrement assignments.

I’d suggest something like:

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

Ok i get what your saying now i will test this some more, thanks for the clarifications!

[Madcadden]

I'm just trying the code you suggest to see if it still works. I made another code update that adds a virtual dip switch that didn't exist on the original machine to toggle between a steering wheel input and a controller input. I found that analogue controller was still bugged with the wheel fix i implemented so i modified it so that it works but now im thinking maybe it wasn't working with the analogue stick the same way the wheel did because i seem to have just winged it with the Port bit mask range and centre point etc. I'll test it out and see what happens and if i can remove the need for having a dip switch to toggle between controller or wheel. I added text to the input menu to let users know there is a toggle in the dip switch menu to change input type.

[Madcadden]

Ok, i used the code you suggested and i was able to play it with both the analogue stick controller and my logitech wheel with no issues other than the steering on the analogue stick is a bit twitchy and easier to spin out compared to the steering wheel. I don't think the dip switch thing is needed now lmfao.

[Madcadden]

I'm just having dinner and doing some more tests , your code is much more stable and im in the process of figuring out what the maximum PORT_MINMAX range i can have is because with my code going over 0x3ff wouldnt work now i just tried "PORT_BIT ( 0xfff, 0x280" with a PORT_MINMAX range of 0x000, 0x500 and it's still working fine. Once i figure out the maximum i will edit the code and remove the dip switch toggle i introduced as it's now not needed in any way shape or form thanks to your explanation of how this stuff works, thank you!

[cuavas]

I think there’s still some issue with the pedal ranges – attempting to calibrate gives an out-of-range error for the brake pedal:

[Madcadden]

I think there’s still some issue with the pedal ranges – attempting to calibrate gives an out-of-range error for the brake pedal:

Hi, i wasn't able to fix this error in the test menu and it isn't new but you can just ignore it and the brake still works as it should.

[Madcadden]

I think there’s still some issue with the pedal ranges – attempting to calibrate gives an out-of-range error for the brake pedal:

I'm attempting to fix this error now and I updated the steering wheel fix so that it fixes controller/joystick input too.

[Madcadden]

I noticed after calibrating the brake you need to reverse it for it to work properly. Going to try and fix that now.

[Madcadden]

I think there’s still some issue with the pedal ranges – attempting to calibrate gives an out-of-range error for the brake pedal:

You can now calibrate it without the error message but input has been limited between 32 and 240, because going below 32 or above 240 gives a "out of range" error. After calibrating i had to reverse the port in the mame analogue input settings for the brake to work correctly but it does work now and you can get past that screen without the out of range error, it's just a bit weird.

[Madcadden]

After you calibrate it in the test menu you have to reverse the brake in the analogue input adjustment menu for it to work properly in game. You can just skip it and the brake will still work regardless if it's "calibrated" or not in the test menu and there are no other calibration tests after it, nothing for the wheel or the gas pedal or anything else just this brake that cant go under 0x20 (32) or over 0xf0 (240) without it saying "out of range" and when you do calibrate it within that PORT_MINMAX it always says the new range is "21" which makes no sense because it should technically be 208 within that minmax range. The original prototype arcade machine must have used a custom hardware setup or something or had a mechanically limited brake pedal or the test menu just hasn't been completed and the test doesn't work properly. Nothing i change alters the behaviour. The important part is the brake is now working when playing the game and the steering works properly now too.

[Madcadden]

I have just noticed that if you use a Xbox one controller the analogue steering still glitches. I will have to lower the PORT_BIT mask and the PORT_MINMAX to make it able to work on sticks with a lower range of motion than the PS5 controller. I have been trying to find tech specs of the different Xbox and PlayStation analogue sticks but it seems it's all a "trade secret" and can't find any data on it specifically. I will change the code so that PORT_BIT and PORT_MINMAX are lower so all controllers can work and then see how it feels on the Logitech wheel after that. I'm still wondering if i should reimplement a Dip Switch toggle to select between controller/wheel PORT_BIT ranges or are the key delta and sensitivity able to take care of that difference? If the wheel seems to work ok then it wont be a issue i suppose so i'll give it a go now. I should probobly use the values you suggested to me earlier as a starting point! @cuavas

*Just had another read of your explanation on how the controls work and it's starting to sink into my thick skull now lol, i think i have just been creating my own issues because i didn't understand until now. I'll get the code changed back to what you suggested! I'm feeling a bit stupid just now but hey I'm learning stuff i had no idea about until now. I just wanted those games to work 😄

[cuavas]

Thanks for looking into this. I tried with the current code from this PR, and it seems the control ranges are correct now. As you noted, it seems strtdriv wants opposite control directions for calibration versus gameplay.

If you have reverse on for the brake pedal, calibration works as expected – press Start with the brake released, then fully depress and release the brake pedal. However, if you leave reverse on, the game behaves as if the brake is on when the pedal is released, and you need to depress it to release the brake.

If you have reverse off for the brake pedal, you need to hold the pedal down and press Start, then release and depress the brake pedal. However the brake works as expected in the game.

I think I’m going to remove PORT_REVERSE from the brake pedals and add a note about the calibration process.

[Madcadden]

Thanks for looking into this. I tried with the current code from this PR, and it seems the control ranges are correct now. As you noted, it seems strtdriv wants opposite control directions for calibration versus gameplay.

If you have reverse on for the brake pedal, calibration works as expected – press Start with the brake released, then fully depress and release the brake pedal. However, if you leave reverse on, the game behaves as if the brake is on when the pedal is released, and you need to depress it to release the brake.

If you have reverse off for the brake pedal, you need to hold the pedal down and press Start, then release and depress the brake pedal. However the brake works as expected in the game.

I think I’m going to remove PORT_REVERSE from the brake pedals and add a note about the calibration process.

@cuavas Can i ask what type of controller you used for testing? I am still having issues with my Xbox One controller. It seems to behave like it did before i fixed it for the steering wheel and PS5 controller.

When I tested it with the Xbox One controller the game starts the car with the wheels in the centre position then when i turn too far to the left or right the car will start going around in circles as if I'm still steering. It reminded me of when i fixed the steering for the wheel but had forgot to test it on a PS5 controller then realised the maximum PORT_MINMAX value that works on the steering wheel was too high for the PS5 controller so i lowered it to "PORT_BIT(0xfff, 0x280" and "PORT_MINMAX(0x000, 0x500)" and then that made the PS5 controller work and was the maximum values that could work without it glitching, going just 1 digit above this range resulted in the glitching that happened originally.

Today when i tested my Xbox one controller it didn't work the same as the PS5 did so i assumed i would need to just lower the PORT_BIT mask and the PORT_MINMAX the same way i did to stop the wheel/PS5 controller from glitching but it doesn't seem to work. I will experiment with it more. I have now successfully created a code that makes a virtual dip switch with 3 positions instead of just the 2 the default ones have and i think i can theoretically make more positions on the dip switch. Each position has it's own name and toggles different PORT_BIT masks and PORT_MINMAX ranges for different types of controllers. I can select "wheel" on the dip switch and the input options in the input assignment menu will change to reflect that it's a wheel you are assigning for steering and it will have the maximum PORT_BIT masks and PORT_MINMAX ranges for my Logitech G923 wheel.

If i select "Joystick" on the dip switch toggle it will do the same thing, it will change the input assignment menu to show that it's a joystick being assigned for steering and applies the lower PORT_BIT masks and PORT_MINMAX ranges for that input. I also added a 3rd option for a spinner wheel because i talked to a guy who plays it with one and he said it works fine for him on a spinner wheel on the older versions of mame but unfortunately he still has issues with the wheel apparently being too sensitive and making the wheels slide etc.

I'm doing all this because i think it would make the steering more accurate for every device type? I don't know if I'm wrong about that or not i just assumed having the maximum PORT_MINMAX range would be better than scaling it to a lower one? I was worried that it might not work with certain controllers now that i see the Xbox One controller is still having issues so my thinking is to find the best PORT_BIT masks and PORT_MINMAX ranges for different controllers and add them into the dip switch menu as pre-sets you can then setup in the input assignment menu. If you tell me what type of controller you were using i can try to add the values that worked for you to the dip switch input pre-set toggle i created and test that it works for you and i can try just now to see what the issue is with the Xbox One analogue stick that stops this patch being successful on it. I reckon if it doesn't work on the Xbox One controller it may not work correctly on others too.

Your feedback on this would be greatly appreciated and i can share the code modifications I'm talking about so you can see how i got them to work.

` PORT_START("mainpcb:SW1") /* 60c002 */

// Virtual DIP switches here
PORT_DIPNAME( 0x300, 0x100, "Toggle between Wheel/Joystick/Spinner inputs for steering" )
PORT_DIPSETTING(    0x300, "Wheel" )
PORT_DIPSETTING(    0x200, "Joystick" )
PORT_DIPSETTING(    0x100, "Spinner" )
/* Hardware DIP switches continue here */

---

PORT_START("mainpcb:12BADC.0")
/* 900 degree wheel - Logitech G923 */
PORT_BIT(0xfff, 0x400, IPT_PADDLE) PORT_CONDITION("mainpcb:SW1", 0x300, EQUALS, 0x300) PORT_MINMAX(0x000, 0x800) 	PORT_SENSITIVITY(100) 	PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Steering Wheel")
/* Joystick - PS5 */
PORT_BIT(0xfff, 0x280, IPT_PADDLE) PORT_CONDITION("mainpcb:SW1", 0x300, EQUALS, 0x200) PORT_MINMAX(0x000, 0x500) PORT_SENSITIVITY(100) 	PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Analogue Joystick")
/* Spinner wheel placeholder settings still needs to be tested! */
PORT_BIT(0xfff, 0x000, IPT_DIAL) PORT_CONDITION("mainpcb:SW1", 0x300, EQUALS, 0x100) PORT_SENSITIVITY(50) PORT_KEYDELTA(10) PORT_REVERSE 	PORT_NAME("Spinner")

`

[cuavas]

I’m using a pile of PlayStation-style and Xbox-style USB gamepads for testing, as well as mouse/keyboard.

The game won’t work with IPT_DIAL. It uses a wheel with fixed end stops and a potentiometer read through an analog-to-digital converter (ADC). This reports the absolute position of the wheel, and corresponds to IPT_PADDLE in MAME. IPT_DIAL is for incremental encoders that report relative movement of the wheel. The two are not interchangeable.

It makes no sense to have different input setups for different host control types here. The game expects a particular range, and the input needs to be configured to produce that.

What are your input assignments set to for the controller(s) you’re having issues with? Are you assigning the same controller axis to both the analog and increment/decrement inputs for an input? Doing that will cause problems.

If the game really is playable with different min/max ranges and centre positions, it suggests it’s self-calibrating somehow. When you test with each controller, are you moving it all the way to both ends of its range before starting a game to give it a chance to adapt to the range?

[Madcadden]

What are your input assignments set to for the controller(s) you’re having issues with? Are you assigning the same controller axis to both the analog and increment/decrement inputs for an input? Doing that will cause problems.

If the game really is playable with different min/max ranges and centre positions, it suggests it’s self-calibrating somehow. When you test with each controller, are you moving it all the way to both ends of its range before starting a game to give it a chance to adapt to the range?

I fixed it on my end i think i had mame setup wrong for that system with all the messing around i was doing before with different input setups. If i had just fixed the controller in the main mame system options menu for the inputs i wouldn't have went down the path of adding that dip switch with the different input types lol.