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 abispac - Last post by abispac

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.
Sounds like I should keep the Angelina then, I really don't have an use for the stand. Im sending the acceptors today to a dealer that would update them to a regular non touchtunes firmware in order for me to use them as 12v pulse type.  Thats all that is left before I put it in a place to work.
The guy wants 600 DLLs for the virtuo wich is a great deal, but I don't have that kind a money right now.
Im hoping for a Christmas miracle on may hehehe

Started by fleskebacon - Last post by fleskebacon

I have noticed that my MAME starts having occasional small hiccups when it has been running for a few hours. I'm running regular MAME 0.263.

The hiccups are like small freezes, just a fraction of a second, maybe just like a frame or two. It seems totally random, not related to any input or anything that's going on i the game, and with 5-30 seconds random intervals. I've had this in several versions of MAME now, and it occurs in any game/rom, so reckon it's most likely not MAME itself causing this, rather some other stuff interfering with it. But I'm not quite sure, because if I restart MAME, the hiccups go away.

I'm on Win10 64 bit, running an i5-3350 and a GTX1050 with Gsync, which is very, very smooth when these hiccups don't occur. Vsync, triple buffer etc are off. I have turned off all power saving stuff I can find, but I'm a bit lost here. If there was something obviously wrong with my setup, the probem would probably be constant and more severe. But this seems to build up in magnitude as long as MAME is running, and disappears at once when it's restarted. Could resemble a memory leak, but I kind of doubt that MAME has had that kind of problem for several releases?

Any ideas what this could be, and how to fix it?

Started by abispac - Last post by lilshawn

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.

Started by JayBee - Last post by javiso85@gmail.com

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

Started by geecab - Last post by PL1

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




Scott

Started by geecab - Last post by geecab

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

:)

Started by 10yard - Last post by 10yard

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.   

Started by geecab - Last post by Yolo_Swaggins

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

Started by Rataplan626 - Last post by Rataplan626

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.

Started by abispac - Last post by abispac

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.
Pages: [1] 2 3 ... 10