Recent Posts

You're right about death being cheaper in general. Say you accidentally hit someone with your car. Often you'd be better off killing the person than causing a major injury like spinal damage, for which you could be liable for a lot more (medical & recuperation, pain & suffering, etc).

Insurance companies know this.

But yeah, Queensland is bigger than it looks on a map and has a lot of remote areas that are (realistically) only accessible by plane or helicopter. Especially in the far north and west, but coastal regions too (there are many islands). It takes about 3 days driving to get from Brisbane to Cairns, 2 days only if you really push it. In addition to going from A to B, people use helicopters to herd cattle and track crocodiles, visit islands and perform rescues, and hundreds of other things.

There was a famous crocodile wrangler that died in a helicopter accident in 2022, has a court case attached, but unfortunately and inconveniently for us, that happened in the Northern Territory (next door).

Most of the data actuaries use is in public domain if you care to look for it (in one of my hats I am a data analyst, but have better things to do unless someone wants to pay me). But going on my gut feeling, as I also grew up in Queensland and know motorbikes, is that ultralights seem a lot safer. Even tail-draggers.

After having a think about how the machine works, and this is just me thinking out loud having no actual experience with one of the machines in it's testmode and only working with it on the mame emulator is that we need to split the "PORT_MINMAX" of the wheels range in mame into 8 virtual segments meaning it would need to be a port_minmax range that can be divided into 8 segements with no remainder etc? Then what we would need to do in the code is maybe trigger 2 flags each time it hits or passes one of the 8th's.........like each time it passed one the flag for  "404000   (W)   OPTORES Reset the Optical Counter" would need to be triggered once to reset the wheel position to 0000 and at the same time trigger the "408000   (W)   CENRES Reset the Optical Centre Flag" so that it knows that was just 1 full rotation of the emulated wheel in mame based off the port_minmax range being given to it? Depending on how these actualy work you might only need to use the "408000   (W)   CENRES Reset the Optical Centre Flag" when it reaches the middle 8th of the wheels range in mame.......so it would be at 4/8ths...........to let the game know this was the middle we reached.

Hopefully you can understand what i mean by this! I think it would allow the machine being emulated in mame to do the correct maths or functions when the car crashes in airborne or you go offraod untill the timer hits 0. it would know in it's memory at what point the wheel was actually at more in line with the real hardware? I could be totally wrong but it's been annoying me for a while that i got the game to work but there couple of small bugs kinda ruin it if your not aware that you need to let go of the wheel as soon as you crash the car or just before your offroad timer reaches 0  I seem to have fixed or heavily mitigated the "wheel going out of alignment when turning the wheel fast" in my own version of the game but my guess is you would need to plug in the appropriate port_minmax values that work for your specific wheel or input device. if a calibration menu could be added to mame for this purpose it would be pretty cool, it could normalise the input of anyones wheel/controller to work with each game better.

Trying not to sound too grim here, but caskets are a lot cheaper than extended medical stays.  And aircraft are much more costly than cycles.  Two things which probably get factored into the premiums in a substantial way.  So insurance costs probably aren't really great indicators of safety either, regardless of how good their estimations of use happen to be. 

IOW, insurance companies are MUCH more concerned with the fiscal aspects than human life and limb. You'd probably need to get ahold of some of those closely guarded internal numbers to get a real feel for what they believe with regard to actual safety of the activity.

Agreed. Insurance companies use very complicated math to come to their conclusions. In fact, if you are an actuary, high level physics is no big deal. Certainly is interesting that my insurance will cost about $1000 more than the exact same plane that has a wheel at the front, instead of the back. Makes sense of course, had I thought harder about it when buying the kit, I might have gone tricycle. But tail draggers just LOOK cooler 😀 . And of course have a little less drag. And keep your rudder skills sharp.

Trying not to sound too grim here, but caskets are a lot cheaper than extended medical stays.  And aircraft are much more costly than cycles.  Two things which probably get factored into the premiums in a substantial way.  So insurance costs probably aren't really great indicators of safety either, regardless of how good their estimations of use happen to be. 

IOW, insurance companies are MUCH more concerned with the fiscal aspects than human life and limb. You'd probably need to get ahold of some of those closely guarded internal numbers to get a real feel for what they believe with regard to actual safety of the activity.

Actuaries have their methods. And it's reflected in the premiums- a light plane costs a lot more to insure than a motorbike, so I guess really riding a bike is safer. But PERSONALLY I feel safer in the air than on a motorbike.
Incidentally, what type of plane it is effects your premium too. Mines not quite ready to insure but I know that because my plane is a tail dragger, the premium is roughly $1000 a year ON TOP of premium. If I had built the tricycle version of my kit, I'd save $1000 a year on insurance. Why?They fly exactly the same. But tail draggers are more likely to have accidents on the ground when taking off or landing. Usually a ground loop. Not normally resulting in any injury, but can cause damage to the plane.

Heya folks - New here! I was wondering if you guys had some example of using large arcade sticks with musical keyboard stands? I was shown this one recently, https://www.amazon.com/Liquid-Stands-Keyboard-Stand-Attachment/dp/B0BRQNQQNY?th=1 and I think id be able to attach a monitor arm to the higher lateral bar, and have the ability to tate the monitor for my shmups, but I am wondering if anyone has done anything similar and how sturdy it would end up being lol

Will it work?  Yes, but with some caveats.  Keyboard stands are stable for keyboards, where you might be adjusting some dials and smashing keys.  But there is one critical difference in activity between arcade controls and keyboards.  The joystick.  That's basically a lever at the tippy-top of the entire structure.  And with a monitor on top, that top-heavy structure would probably get even worse.

Unless you play somewhat gingerly, you would at minimum need to sandbag the bottom, or better yet, bolt it to the floor.  Otherwise, it may feel pretty rickety in use.  I can't imagine trying to play a bullet-hell game on one, honestly.

My wheel center point button can be used to turn the wheel all the way to the left then i hit the button twice and in the input menu you now see the value of the wheel going from 0000 to 0702 when you turn it to the right. I'm just going to change my port_minmax to see if i can get this thing to tally up and alter the code if i need to.

Ok i just tried editing the port_minmax and now when i turn the wheel all the way to the left and hit the wheel edge toggle button i made it starts reading the wheel values properly from 0000 all the way on the left all the way up to 0058 on the right which in decimal = 72. if it needs flipped the other way it can be easily done. Just going to check the behaviour of the wheel in game.  I think that button for wheel center has to be triggered to activate every time that the wheel reaches the right(0058 in hex 72 dec)? Or left if it's the wrong way around? Either way it sounds closer to the original game. I would need to see what the values were on a real machine to make it accurate because we don't know how the machine was scaling these numbers. It was using a 12 bit ADC port so thats why it's a 4 digit hex value. Seems like a waste of hardware for a wheel that only had to read 72 notches? Maybe the wheel edge detection in the other harddriv_m.cpp file just needs the value for the edge detection to trigger to be tweaked to match the real hardware in there they have it set to 0xf00.

That is pretty large.  Land mass really isn't that much if an indicator though.  People don't travel on long trips like they used to before Skype, Covid, etc. But people do still commute, go to the store and visit friends locally.

If you really want to know how safe an activity is, you have to do what insurance companies attempt to do, which is determine the number of hours on the road/ in the sky and compare that to the fatality record.  Good luck coming up with accurate numbers though.  Flight logs probably make this easy for aircraft, but there are no accurate records of that nature for cycles.

Sounds good to me, great stuff

I'm still catching up. I've managed to get mame built from github and I can run hard drivin' (compact) and airborne. I've just not hacked the code yet (But I think that's what I need to do to get a feel for what is happening). I'll start experimenting with my wheel at the weekend.

Something that has always bugged me with the compact roms, is that it is not possible (yet, I think) to successfully calibrate the wheel using the service menu. I went and did some reading/investigation, trying to work out what values to expect (When viewing the "Control Inputs" service menu) from a successfully calibrated wheel. I didn't get very far. Thought I'd post my notes as they might be of interest/help:-

Code: [Select]

Compact harddrivin service manual (HDC_TM-329_2nd.pdf):
041787-02 Steering Encoder Disk.
043807-02 Centering Encoder Disk.

HDC_TM-329_2nd.pdf, From the "Control Inputs" service menu:
As you turn the steering wheel clockwise, the hexadecimal number should increase and change to zero once every turn.
As you turn the wheel counterclockwise, the number should decrease. Everytime the steering wheel passes the center position,
the words center edge should change from blue to green.

HDC_TM-329_2nd.pdf, from a section near the end about installing a new encoder wheel:
Install the steering wheel with the center spoke down. Make sure the single hole on the centering disk is between the opitcal reader on the centering
PCB so the steering wheel will be correctly centered.

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 found a picture of a 041787-02 Steering Encoder Disk, and counted 72 holes. Based on this, I don't think we should see a steering value (When viewing the "Control Inputs" service menu) reported that exceeds 72 (Or maybe 144 if we are counting teeth passing as well has holes). Thus, when turning clockwise you'll see 0 increase to 72 then back to 0 etc... When turning anticlockwise you'll see 72 decrease 0 then back to 72 etc... In mame, I think we see values much greater than 72, this might cause strangeness. I think I'll try and hack things so that I force these 'ideal' values to occur at calibration.

Something odd I noticed, is that in mame when viewing the "Control Inputs" service menu and turning the wheel clockwise, I see the hexadecimal number decrease, not increase...

Wow that is the info we have been looking for!
 


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

Does this part have any relation to this code in the harddriv.cpp file?

Code: [Select]

PORT_START("mainpcb:a80000")
PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_CUSTOM )  /* center edge on steering wheel */
I hacked the code about a month ago so that when i press a button i assign in the input assignment menu in mame it activates this function. When i press the button you see the center point indicator light up and the wheel reset back to 0000...............

There is no wheel calibration in street drivin or in hard drivin's airborne like the other games do. It only has the menu that shows the output value of it when your moving it around. I was thinking if i set the port_minmax from 0 to 71 or 143 ( if the games code counts 0 as a value) then trigger the code above to activate each time this reaches the centerpoint the same way it does when i push the button with this code i "hacked"

Code: [Select]

PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_CUSTOM ) PORT_TOGGLE PORT_NAME("wheel centre1")
Maybe then it will function correctly........then all we would need to do is implement the proper scaling for a 900/720/270 degree wheel etc so that it only goes up to the max value when you turn it whatever direction it should go like 71/72 or 143/144 for clockwise/counter clockwise max then the opposite for the other direction. I probobly explained that in a confusing way lol.

I'm having another mess around with it today. I made some other code that was implementing the stuff i was doing in the other code i sent you plus it buffers/smooths the wheel output and truncates the last digit from the hex value you so it doesnt fluctuate as quickly when you turn the wheel around and it seems to have fixed the wheel going out of alignment when you turn it fast, that was another issue you could kinda stop from happening if you made smoother wheel turns physicly but sometimes just not possible if you want or need a sharp turn. The recentring logic i did before doesnt work as well in the new code though i dont know if it's because im messing with the values before i apply the offset. Now that i have the info you provided i don't think any of that is even going to be needed lol

Code: [Select]

#include <numeric>  // For std::accumulate

// Function to calculate the Exponential Moving Average (EMA)
uint16_t harddriv_state::calculate_ema(uint16_t new_value) {
    static float ema_wheel = 0.0;  // Persistent storage of EMA across calls
    static const float alpha = 0.05;  // Smoothing constant

    ema_wheel = alpha * new_value + (1 - alpha) * ema_wheel;

    return static_cast<uint16_t>(ema_wheel);
}

// Main function to handle wheel input and apply adjustments
uint16_t harddriv_state::hdc68k_wheel_r() {
    static const uint16_t g_latchpoint = 0x8000;
    static int16_t wheel_offset = 0;
    static bool last_wheel_edge = false;

    uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff) << 4;
    uint16_t ema_wheel = calculate_ema(new_wheel_raw);
    uint16_t new_wheel = ema_wheel + wheel_offset;

    // Set wheel edge to 1 if at or crossing the center and it is not already set
    if (!m_hdc68k_wheel_edge &&
        ((m_hdc68k_last_wheel < g_latchpoint && new_wheel_raw >= g_latchpoint) ||
         (m_hdc68k_last_wheel > g_latchpoint && new_wheel_raw <= g_latchpoint))) {
        m_hdc68k_wheel_edge = 1;
    }

    // Handle wheel edge reset and offset adjustment
    if (last_wheel_edge && !m_hdc68k_wheel_edge) {
        int16_t adjustment = g_latchpoint - ema_wheel;
        adjustment = (adjustment / 0x10) * 0x10;  // Normalize adjustment to remove last digit
        wheel_offset += (new_wheel_raw > g_latchpoint) ? -abs(adjustment) : abs(adjustment);
        wheel_offset = (wheel_offset / 0x10) * 0x10; // Normalize wheel_offset to remove last digit
        new_wheel = ema_wheel + wheel_offset;
        new_wheel = (new_wheel / 0x10) * 0x10;  // Normalize new_wheel to remove last digit
    }

    last_wheel_edge = m_hdc68k_wheel_edge; // Store the last state of the wheel edge
    m_hdc68k_last_wheel = new_wheel_raw;   // Update the last wheel value for comparison in the next cycle

    // Continuously show the debugging message
    popmessage("Wheel Raw: %04X, EMA Wheel: %04X, Adjusted: %04X, Edge: %d, Offset: %d",
               new_wheel_raw, ema_wheel, new_wheel, m_hdc68k_wheel_edge, wheel_offset);

    return (new_wheel << 4) | 0xff;
}

Thats where i was last night before i woke up and saw your reply today, i actualy had a look yesterday but none of it was sinking in as i had no sleep for a couple of days lol. I'll get back to you if it's been improved any. Cheers!

2.6 times the size of Texas