Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

Recent Posts

Pages: [1] 2 3 ... 10

Started by danny_galaga - Last post by RandyT

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.

Started by danny_galaga - Last post by danny_galaga

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.

Started by Trusty - Last post by RandyT

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.

Started by geecab - Last post by Yolo_Swaggins

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.

Started by danny_galaga - Last post by RandyT

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.

Started by geecab - Last post by Yolo_Swaggins

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!
 :notworthy:


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! :applaud:




Started by danny_galaga - Last post by danny_galaga

2.6 times the size of Texas

Started by rogerxyz - Last post by psakhis

That game is 384x256@55hz.
Probably your tv isn't changing to PAL mode.

Started by Trusty - Last post by Trusty

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

10   GroovyMAME / Re: crt_emudriver stopping mid-scanline?on Today at 12:42:36 am

Started by rogerxyz - Last post by rogerxyz

Hi Zebidee, thank you for the reply!

I don't think this is an overscan issue - the last scanline is nowhere near the bottom of the screen. I've adjusted the vertical height way down so we can be sure there's no cropping on the top and bottom, and I'm going through the video modes in arcade OSD here:

https://drive.google.com/file/d/19tWdLeG8p_jrBBt_NsxS0sWWoReADpQX/view?usp=sharing

We can see that in some modes, for instance, 320x224@60 (15.66khz), the full image is drawn, you can see the bottom white border. Whereas the very close 320x248@59.97 (16.13khz) doesn't reach the bottom white border, and in fact, you can see that it in fact stops mid-scanline here...

My first thought is that anything over 15.6kHz can't be displayed by this Sony KV-XXX, but then 336x224@60 (15.66kHz) works fine but one at a little lower frequency 384x240@59.98 (15.65kHz) does not work.

Is there something here I can adjust in the range when generating modes, or the service menu, that could assist with these couple modes that appear not to be drawing the whole image? Or is maybe something else going on here - failure to sync is one thing, it obviously can display these modes, but cutting off scanlines is
something else...

My preset is

monitor "roger", "Sony KV-20FS100", "4:3"
        crt_range0 15625-16750, 56.0-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 170, 262, 448, 526


I did just replace my modelines with the ntsc preset, rebooted, and it doesn't seem to have done anything.

Is this what foldover looks like? I thought foldover looked like the image "bouncing" off the top or the bottom and drawing again over top of itself, like it had been folded at the edge, but I could have a misconception.
Pages: [1] 2 3 ... 10