Recent Posts

I just unboxed it. the creases in the old cardboard  was stiff. just like a new book. pics will be coming soon.
yes I am excited about it. from my research . It will be close to a Pi 4 BUT it can run windows!

I trust your input Randy. thank you

who s the oldest person here.
I am 59 born March 18th 1965

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.

The big killer is usually heat, but age (drying out) will do it too.  If you are concerned, pull the heatsink and take a look. If it's still gooey, just put back.  Otherwise, clean well and replace.

Thanks for the info Randy, I ended buying the Creality V3 KE. My discount to myself was generous 

Reprinted a few parts for my project with some improvements.  I'm happy with the results:

Spiffy!  So, on the webs, did you tweak some things to deposit like that or were there more manual artistic shenanigans used?

It came in today. Still unboxed. I am downloading multi OS systems to try.
tiny window 7, tiny win 10, tiny win 11, androids, Linux, Batocera. to try booting from thumb drive fist.

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.