Recent Posts

virtuo is okay.

early models have issues with black spots appearing on the LCD panels due to a manufacturing defect. later models have no panel issues... but some issues with bad caps on the  backlight inverters. newer ones have LED backlit panels and have issues with the caps going bad on the LVDS board. the later 2 being fixable... the spots, not at all other than panel replacement. good luck finding a panel to replace it....it's a weird size and wasn't available for long.

the computer is decent. it's output audio via regular headphone jacks so no messing around there. you will need a "red" DI box to convert the audio from the computer to the amp (amp accepts balanced audio over ethernet...the IO board does this so you'll have to sub the red DI box to do this.)

the card reader is worthless as it's been disabled due to new PCI credit card processing rules rules... making it non-compliant.

the stand should have woofers built into it... it should also have some satellite speakers attached to either side as well.

Hi Jay, how is going the project? Has you advanced on the board, I am very excited about it!

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...

Sounds like the optical data lines (A and B) are swapped, which reverses the axis.
- It could be your setup (not likely), settings, the connections in MAME (also not likely), or the axis reversal setting in MAME's Analog menu.   




Scott

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...

just want to say ive been following this thread for quite a while.

I have a spare RPI 4 8gb, and it's getting this ASAP.

now i've gotta build a baby dk cab too - really amazing work. I am head over heels for your project.

You mentioned your health and single malt - hope everything is ok and you take care of yourself, tons of old nerds need you now more than ever!

Thanks!
Health is good.  Still drink single malt whisky but also ran a Marathon earlier in the month. 

I put a lot of time into DKAFE recently, extending it to include console and computer ports, remakes and hacks of Donkey Kong.  Quick launching and playable with arcade controls.   I made an add-on pack available which includes over another 100 DK versions.  Windows build is out now and being tested.  If all good then I'll get this onto Pi soon.

DKAFE is built as an application and can potentially be ran independently of my image in a different environment.  I'll take a look at the link you posted re: CRTpi project and see if I can offer any help or advice. 

I'll post more info about my DKAFE progress here soon.   

Made some progress. Car seems to not go wonky after crashing in Hard Drivin's Airborne with this code and i can drive around untill the timer runs out and the wheels seem to stay straight  I've not tested it too much as in crashing with the wheel held all the way around to the left or the right because thats not how i play or anyone else i think? Been keeping my regular play style and if i forget to let go of the wheel when i crash theres a offset applied to the new_wheel output that keeps the centre point lined up with what the game is doing.

Original wheel edge bit latch code from harddriv_m.cpp here

Code: [Select]

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;
}
And this is the modification i made for Hard Drivin's Airborne to work better and stop going out of alignment so much.

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
    static const uint16_t g_latchpoint = 0x8000;  // Central point for wheel detection.
    static int16_t wheel_offset = 0;             // Cumulative offset to adjust the wheel position based on game events.
    static bool last_wheel_edge = false;         // To track the last state of crossing the center.

    // Read the current wheel position from the 12-bit ADC port.
    uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff) << 4;


    // Apply the cumulative offset to align with the game's perceived center.
    uint16_t new_wheel = new_wheel_raw + wheel_offset;

    // Edge detection logic to detect being at or crossing the center point using raw ADC data.
    if ((m_hdc68k_last_wheel < g_latchpoint && new_wheel_raw >= g_latchpoint) ||
        (m_hdc68k_last_wheel > g_latchpoint && new_wheel_raw <= g_latchpoint) ||
        new_wheel_raw == g_latchpoint) {
        m_hdc68k_wheel_edge = 1;  // Set edge flag when at or crossing the center based on raw input.
    }

    // Check if the wheel edge flag has changed from 1 to 0, as reset by the game.
    if (last_wheel_edge && !m_hdc68k_wheel_edge) {
        // Calculate the offset adjustment when the wheel is recalibrated.
        int16_t new_offset_adjustment = g_latchpoint - new_wheel_raw;

        // Apply the adjustment based on the current wheel position relative to the center
        if (new_wheel_raw > g_latchpoint) {
            // Wheel is to the left, need to decrease raw value towards the center
            wheel_offset += abs(new_offset_adjustment); // Use addition to adjust back towards the center
        } else {
            // Wheel is to the right, need to increase raw value towards the center
            wheel_offset -= abs(new_offset_adjustment); // Use subtraction if below the center
        }

        new_wheel = new_wheel_raw + wheel_offset; // Reapply the updated offset.
    }

    last_wheel_edge = m_hdc68k_wheel_edge; // Store the last known state of the wheel edge flag.

    // Display current wheel information for debugging.
    popmessage("Wheel Raw: %04X, Wheel Adjusted: %04X, Edge: %d, Offset: %X",
               new_wheel_raw, new_wheel, m_hdc68k_wheel_edge, wheel_offset);

    // Store the current wheel value for the next comparison.
    m_hdc68k_last_wheel = new_wheel_raw;  // Update last_wheel to the raw value to ensure proper comparison next cycle.

    // Return the processed wheel value, formatted as required.
    return (new_wheel << 4) | 0xff;

}
Seems to work fine in Street Drivin' too but that didn't have a wheel alignment issue after the last patch i did on it anyway and it doesn't set wheel edge to 0 when you crash so not a issue there or in any of the other ones really. This code might not play well with the compact versions because of how they do the wheel alignment I think you can just skip the wheel calibration setup and it should work anyway I applied a overclock in the source code for my own version of mame I'm testing and got the frame rate way higher in every one of them because i exceed the 400% limit on the GSP.

I made a dip switch that can toggle between 6 or 7 different types of wheel/sensitivity. I have my Logitech G923 wheel dialled in on it but not tidied the code up or labelled them appropriately yet i'll finish doing that later today or tomorrow after some sleep.

It's been a long while, but live struck me. I don't have any AMD or nVidia stuff anymore, so I can't troubleshoot or develop this any further. It seems to work fine for Intel iGPU, and I still use it on my cabs to great extent. I've had question from people using VRR and FreeSync with RatRefresh, but I don't have any of that fancy stuff so I don't know. I don't know if Mame has a implementation for such monitors to run at the correct rate, if not I still think RatRefresh might be beneficial as Mame can then sync to the set refresh rate.

Anyway, I think it's fair to conclude this tool is discontinued now. If there's any specifics I can help with, feel free to ask. AMD nVidia support is unlikely to ever get in because of lack of time and equipment.

So the old owner of the angelina, liked the juke so much, he is willing to trade it for virtuo with the base included, I believe the base is the speaker.... Should I do the trade?

Mr LilShawn, can you enlight me on the hardware difference, beside having a credit card reader and a bigger screen....

Thanks for your feedback.

So, if I'm understanding, the games don't have native wheel support and therefore don't have ffb. But, using the apps, you are able to get the steering wheel to work. Do those games support xbox controllers and rumble? If so, you can use 'wheel2xinput' which allows you to map your steering wheel as an xinput device. And it will provide ffb as long as the game provides native rumble to the controller. And this rumble can be adjusted within the wheel2xinput to provide a pretty satisfying ffb effect.

I'm currently using the iPac 4 in keyboard mode. I've also connected an iPac 2 via USB, and I'm aiming to integrate an extra set of 7 buttons into the system using the iPac 2.

Windows sees an IPac as a composite device that has a HID keyboard.

Windows can handle having a large number of keyboards plugged in at the same time with no problem.
- There are 3 keyboards and 3 mice when I'm using the pinball controller in my sig and a wireless keyboard.

Obviously, you'll want to reprogram the IPac2 to send different keystrokes than the IPac4.
- If you want to send the same keystrokes, you can just wire several button/joystick microswitches in parallel to an IPac input.

Something that might give you problems is if you change the "multikeyboard" setting in mame.ini.
- It's better to leave this setting disabled (0) and program the second IPac to send different keystrokes instead of dealing with possible Windows device renumbering problems.
- With multikeyboard set to enabled (1), MAME looks for a specific keystroke from a specific keyboard number.   

If you need to reprogram one of the IPacs, remember to unplug the USB on other one so the WinIPAC knows which board you want to program.


Scott