Recent Posts

My tiny client came in today.I have not unboxed it yet.
question. Would you replace thermal past right away? i am torn on this. 1 it has never been powered on. 2 it is over 10 years old.

So if you run the hard drivin compact roms, you should be able to successfully calibrate the wheel, but you must use a mouse. Moving the mouse for ages to the right will simulate 4 wheel rotations and the calibration should report:
    NEW CNTSPTRN 1024 PATCEN 0

Thus one complete wheel rotation amounts to 1024 (0x400) encoder values.

Note. You might want to hold the left shift key to get the encoder value spot on at the end of the calibration (when its working out the PATCEN thing).

In the game, the centre edge bit (That "result ^= 0x4000" stuff) will 'latch' each time the wheel does a full rotation (reaching its centre point). The encoder wheel value at these centre points will be one of 0x000, 0x400, 0x800 or 0xC00.

I think that just as your car re-spawns is the moment when the game works which one of the centre points is the most appropriate (nearest). Let say you started the game around the 0x800 position, then you crash after turning hard right (and say the encoder at that moment is 0xD50). Then once you re-spawn, the game doesn't expect you to wind back the steering all the way to the 0x800 centre point (0xD50-0x550 encoder values), you'll only be expected to wind back the steering to the 0xC00 centre point (0xD50-0x150 encoder values).

So now after you crash, when you get the car to go in a straight forwards direction and observe the encoder value (left shift), you should notice it'll always be around one of those those centre points (0x000, 0x400, 0x800, 0xC00). The game does have to be correctly calibrated in the service menu for this to work accurately.

I hope that what is happening!

Hi Yolo,

I think I might now have something that shows the centre latching stuff working... I'm tentative saying this in case I'm talking rubbish and I've just been lucky running a few tests lol! But its looking reasonable so far

I'll explain how (I think) its working in the next post, but first here's the diff of my changes:-

Code: [Select]

diff --git a/src/mame/atari/harddriv.cpp b/src/mame/atari/harddriv.cpp
index e0b25440ad7..2ff020056b9 100644
--- a/src/mame/atari/harddriv.cpp
+++ b/src/mame/atari/harddriv.cpp
@@ -1041,8 +1041,8 @@ static INPUT_PORTS_START( racedrivc )
  PORT_BIT( 0x0400, IP_ACTIVE_LOW, IPT_BUTTON4 )  PORT_NAME("3rd Gear")
  PORT_BIT( 0x0800, IP_ACTIVE_LOW, IPT_BUTTON5 )  PORT_NAME("4th Gear")
  PORT_BIT( 0x3000, IP_ACTIVE_LOW, IPT_UNUSED )
- PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_CUSTOM )  /* center edge on steering wheel */
- PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNUSED )
+ PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_CUSTOM )  PORT_NAME("Encoder Reset") /* center edge on steering wheel */
+ PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_CUSTOM )  PORT_NAME("Center Reset") /* center edge on steering wheel */
 
  PORT_START("mainpcb:8BADC.0")        /* b00000 - 8 bit ADC 0 - gas pedal */
  PORT_BIT( 0xff, 0x00, IPT_PEDAL ) PORT_SENSITIVITY(25) PORT_KEYDELTA(20) PORT_NAME("Gas Pedal")
@@ -1069,7 +1069,7 @@ static INPUT_PORTS_START( racedrivc )
  PORT_BIT( 0xff, IP_ACTIVE_LOW, IPT_UNUSED )
 
  PORT_START("mainpcb:12BADC.0")       /* 400000 - steering wheel */
- PORT_BIT(0xfff, 0x800, IPT_PADDLE) PORT_MINMAX(0x010, 0xff0) PORT_SENSITIVITY(400) PORT_KEYDELTA(5) PORT_NAME("Steering Wheel")
+ PORT_BIT( 0xfff, 0x800, IPT_DIAL ) PORT_SENSITIVITY(400) PORT_KEYDELTA(5) PORT_NAME("Steering Wheel")
 
  /* dummy ADC ports to end up with the same number as the full version */
  PORT_START("mainpcb:12BADC.1")
diff --git a/src/mame/atari/harddriv_m.cpp b/src/mame/atari/harddriv_m.cpp
index 856783e2fb6..e17d54bc4d6 100644
--- a/src/mame/atari/harddriv_m.cpp
+++ b/src/mame/atari/harddriv_m.cpp
@@ -9,7 +9,6 @@
 #include "emu.h"
 #include "harddriv.h"
 
-
 /*************************************
  *
  *  Constants and macros
@@ -246,42 +245,68 @@ uint16_t harddriv_state::hdc68k_port1_r()
  result = (result | 0x0f00) ^ (m_hdc68k_shifter_state << 8);
 
  /* merge in the wheel edge latch bit */
- if (m_hdc68k_wheel_edge)
- result ^= 0x4000;
+    if (m_hdc68k_wheel_edge)
+    {
+        result ^= 0x4000;
+        printf("hdc68k_port1_r: merge latch result=%04X m_hdc68k_last_wheel=%04X\n", result, m_hdc68k_last_wheel);
+        m_hdc68k_wheel_edge = 0;
+    }
 
- m_hdc68k_last_port1 = result;
- return result;
+    m_hdc68k_last_port1 = result;
+    return result;
 }
 
 
 uint16_t harddriv_state::hda68k_port1_r()
 {
- uint16_t result = m_a80000->read();
+    uint16_t result = m_a80000->read();
 
- /* merge in the wheel edge latch bit */
- if (m_hdc68k_wheel_edge)
- result ^= 0x4000;
+    /* merge in the wheel edge latch bit */
+    if (m_hdc68k_wheel_edge)
+    {
+        result ^= 0x4000;
+        printf("hda68k_port1_r: merge latch result=%04X m_hdc68k_last_wheel=%04X\n", result, m_hdc68k_last_wheel);
+        m_hdc68k_wheel_edge = 0;
+    }
 
- return result;
+    return result;
 }
 
 
 uint16_t harddriv_state::hdc68k_wheel_r()
 {
- /* grab the new wheel value */
- uint16_t new_wheel = m_12badc[0].read_safe(0xffff);
-
- /* hack to display the wheel position */
- if (machine().input().code_pressed(KEYCODE_LSHIFT))
- popmessage("%04X", new_wheel);
-
- /* if we crossed the center line, latch the edge bit */
- if ((m_hdc68k_last_wheel / 0xf00) != (new_wheel / 0xf00))
- m_hdc68k_wheel_edge = 1;
-
- /* remember the last value and return the low 8 bits */
- m_hdc68k_last_wheel = new_wheel;
- return (new_wheel << 8) | 0xff;
+    // grab the new wheel value
+    uint16_t new_wheel = m_12badc[0].read_safe(0xffff);
+
+    // hack to display the wheel position
+    if (machine().input().code_pressed(KEYCODE_LSHIFT))
+    {
+        popmessage("wheel new=%04X", new_wheel);
+    }
+
+    if ((m_hdc68k_last_wheel & 0x0C00) != (new_wheel & 0x0C00))
+    {
+        /*
+        Why the 0x0C00 mask? It checks if the new wheel position has moved into a new range.
+        NNNN 00NN NNNN NNNN     Thus range 0x0000 to 0x03FF
+        NNNN 01NN NNNN NNNN     Thus range 0x0400 to 0x07FF
+        NNNN 10NN NNNN NNNN     Thus range 0x0800 to 0x0BFF
+        NNNN 11NN NNNN NNNN     Thus range 0x0C00 to 0x0FFF
+        */
+        if(m_hdc68k_wheel_edge == 1)
+        {
+            //Already pending a latch. There is no point in doing 2 really quick latches,
+            //do nothing for the same effect.
+            m_hdc68k_wheel_edge = 0;
+        }
+        else
+        {
+            m_hdc68k_wheel_edge = 1;
+        }
+    }
+
+    m_hdc68k_last_wheel = new_wheel;
+    return (new_wheel << 8) | 0xff;
 }
 
 
@@ -445,11 +470,10 @@ void harddriv_state::hd68k_nwr_w(offs_t offset, uint16_t data)
 void harddriv_state::hdc68k_wheel_edge_reset_w(uint16_t data)
 {
  /* reset the edge latch */
- m_hdc68k_wheel_edge = 0;
+ //m_hdc68k_wheel_edge = 1;
 }
 
 
-
 /*************************************
  *
  *  68000 ZRAM access


I had tried something with the client commandline program but it didn't work. But I didn't know about it faking a tracker and maybe that's why

I tried messing around a bit with modifying the create_virtual_controller example file to generate a fake controller and move it roughly to the middle of my play field, it partially worked after swapping it with my headset but messing with both the offsets in OVRIE and directly writing them with the commandline didn't really generate the desired effect, the controller visually moves around the playspace and the calibration seems static to the fake controller, but adjustments don't make any changes. I think that what might actually be happening during the swap is that the headset gets confused and becomes stationary at its last position rather than swapping the tracking to the fake controller, so maybe it's not usable. Swapping a real tracker with the headset seems to work, maybe it's a limitation of the virtual device, and I'm unsure if the client can modify the position of real devices.

Looks really nice. I wish I had access to a 3D printer but if I bought one I know I'd only use it a couple of times a year, if that.  It looks like it provides options for things that would be too difficult to make by hand. Opens up a lot of possibilities.

I found this youtube before that gives a link in the description to a dll file linked on the github issues page:



It enabled me to use the offset menu and I think it may also fix the remapping but I didn't test that. I can see now how the offsets work as it is.

Unfortunately they didn't seem to provide any code and it's already compiled so it still leaves me to get it working.

But that github you sent could be very useful because I'll need to compile the program and use it to figure out exactly how the offsets work and if I can send a fixed position.

I had tried something with the client commandline program but it didn't work. But I didn't know about it faking a tracker and maybe that's why

This is a good idea. I did have a look at OpenVR Input Emulator and I had heard about it before with regards to changing the angle from the controller to the screen. It's open source which is good, but I read on there that people said it was out of date and that it wouldn't work. Did you have to downgrade SteamVR/OpenVR or anything like that to be able to use it?

I'd have to look into how it actually changes the pose etc and if it could do it for the whole position with virtual desktop picking that up

When I went looking earlier I found https://github.com/Louka3000/OpenVR-InputEmulator-Fixed, which works for the pose based stuff, I use it to realign my tracker to the gun barrel on the latest SteamVR. I couldn't get the input remapping side of things to work though, I think that was broken at some point. OVRIE seems to be offset based in that it takes the current position of the device and just moves and rotates it, I don't know if it can be used to send hard coded values, although you could maybe have a virtual tracked point as a spoofed controller/tracker (via the client_commandline protocols), and then switch the tracking between the headset and that fake tracker to position it precisely for VD recentering. One other thing of note is that either redirect or swapping 2 devices in the interface causes it to crash, I think swapping is the one that works while redirect causes crashes.

Hard Drivin'/Race Drivin' cockpit in the mame driver only has this.

Code: [Select]

PORT_START("mainpcb:a80000")
PORT_BIT( 0x0001, IP_ACTIVE_LOW, IPT_START2 ) PORT_NAME("Abort")    /* abort */
PORT_BIT( 0x0002, IP_ACTIVE_LOW, IPT_START1 ) PORT_NAME("Key")  /* key */
PORT_BIT( 0x0004, IP_ACTIVE_LOW, IPT_COIN3 )    /* aux coin */
PORT_BIT( 0xfff8, IP_ACTIVE_LOW, IPT_UNUSED )

But all the rest have this?

Code: [Select]

PORT_BIT( 0x4000, IP_ACTIVE_HIGH, IPT_CUSTOM )  PORT_TOGGLE PORT_NAME("Center Wheel Edge")  /* center edge on steering wheel */
PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNUSED )

I notice the highest memory address for these operations is on the steel talons/stun runner board that has this

Code: [Select]

PORT_BIT( 0xfff0, IP_ACTIVE_LOW, IPT_UNUSED )

Maybe the other function that could potentially be missing is lurking around within the 0x8000 to 0xfff0 range?

PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNUSED )  actually is used in Airborne in the debug menu..........

Wonder what 0x9000, 0xa000,0xb000 etc would do?

Oh man... I'm not sure we are out of the woods yet.

Last night I played about with setting IP_ACTIVE_HIGH for the Compact Hard Drivin' roms yesterday. I have to say, I kind of think the correct thing to do is leave it at  IP_ACTIVE_LOW...

Setting it active high means the 'Centre Edge' thing (Seen in the Service Menu) is constantly on (Green), the 'Steering Wheel' value is held at 0x0000, and steering calibration is not possible (Which can't be correct). While you can skip the service menu to play the game, and observe the car re-spawns always with centred steering (which is very good to know and well found by yourself), it feels to me like we are building on a side effect of doing something that we shouldn't be doing. Without fully understanding what should be happening...

Another spanner in the works is that I also think for these compact roms, the steering control should probably be an IPT_DIAL (which has unlimited rotation) rather than an IPT_PADDLE (that has limited rotation), to reflect the actual arcade hardware.

 

 
Thats why i only have it set high for racedrivc the others i left alone. It just makes the game playable. My feeling is that those functions you sent from the hard drivin' compact manual with memory addresses 404000,404000 and 408000 are not being used properly........i think that the devs have made the game only use one of them to do a job that the other one is meant to carry out when it reaches the centerpoint?

Code: [Select]

From the Race Drivin' Compact Manual, for the Main Board Memory Map, it says:
OPTO: Optical Steering Wheel Reader
400000 (R) OPTORD Read the Optical Counter
404000 (W) OPTORES Reset the Optical Counter
408000 (W) CENRES Reset the Optical Centre Flag
I have a hunch that only the middle one is being set or the last one? In mame when we press that wheel edge button to manually activate it the counter suddenly becomes 0000.........that sounds like it's activating the middle function which kinda makes it seem like it's doing it's job because suddenly the wheel will think thats the centerpoint?  Shouldn't it be activating the last one to be setting in stone what the actual centerpoint is? Where in the mame code is the other function? I only see the one wheel edge function mentioned in mame driver code? What if the wheel edge in mame is linked to the wrong operation in that manual? Wouldn't that be the cause of it all? I think theres meant to be 2 flags or operations working together and from what i see in the mame driver code is only one operation/flag being used. I might be completely wrong but it's all my brain can come up with.

Last week I went to play California Speed (using the latest versions of MAME and FFB), I noticed that FFB gave some "hiccups" even when the cart wasn't touching anything. Doing some tests I saw that this problem originates in the FFB plugin version 2.0.0.34. I concluded that the last best combination for Cal Speed is MAME 0.257 and FFB 2.0.0.33. I think it's possible that this problem could also be present in some other game, but I'm not sure. I hope this information can help someone.

EDIT: In this test I used the Logitech G29 steering wheel. I will soon test the Thrustmaster T300.

Today I did the test with the Thrustmaster T300 steering wheel and the "hiccup" was present. This time the games tested were: Ace Driver, Ace Driver Victory Lap, Cal Speed and SFRush 2049 SE. They all had the same problem (very discreetly in both Ace Driver's). I decided to roll back to MAME 0.257 and FFB 2.0.0.33.