Recent Posts

Yeah, get it online joined and play tournaments with like.. 70 new courses.

I’ll check them out.  The price actually went down on shipping slightly for this latest batch from pcbway.

In other news, I’ve been pondering making a PCE to TG16 adapter.  The only difference between the two is the order of 8 pins are reversed on the edge connector.  TG16 carts also have some rudimentary region protection that’s defeated by grounding a pin on a PC Engine.

With that edge connector I linked previously and some tweaking of these PCBs, I feel like we’re close to being able to do this.  Here’s an adapter on eBay that shows how simple this is..







 

Adapter

Hello everyone.

I sent several personal emails to Paul (GREENMAN).
Paul does not receive my personal emails because I have no answers.
If anyone knows him, could you be so kind as to let them know?
If an administrator reads this message, could you be so kind as to notify them?

Bonjour chez vous.
Jill

You will have a lot of fun with that setup.

Enjoy!!

Hi Yolo!

Thought I'd post my hack of the  hd68k_wr2_write() to read steering wheel force feedback. If you're interested, just replace the existing hd68k_wr2_write()  function with this one, and when holding the 'F' key in-game you can see the feedback trying to do its thing. Something that is pretty cool is watching the attract mode and viewing the force feedback, you can see how the game is trying to rotate the wheel when it hits the corners (You do need to enable the Steering During Attract Mode option for that though, I explain how to do that in the massive comment in the function).

Code: [Select]

void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data)
{
    /*
    Observations
    ============

    The 'data' repeats every 4 times this function is called.
    Offset always seems to be zero.
    Combining the 1st and 3rd byte of data gives you the steering
    wheel force feedback.

    When the game does not want to rotate the wheel in any direction,
    0xE000 is read.

    When the game wants the wheel to rotate clockwise, you see this:
        0xE000 increment to 0xE01F,
        then jumps to 0xE100 which increments to 0xE11F,
        then jumps to 0xE200 which increments to 0xE21F,
        then jumps to 0xE300 which increments to 0xE31F,
        etc...

    When the game wants the wheel to rotate anticlockwise, you see this:
        0xE000 jumps to 0xFF1F which decrements to 0xFF00,
        then jumps to 0xFE1F which decrements to 0xFE00,
        then jumps to 0xFD1F which decrements to 0xFD00,
        then jumps to 0xFC1F which decrements to 0xFC00,
        etc...

    Bits 0 to 7 never go above 32 (0x1f). Thus Bits 5 to 7 are unused.

    If bits 12 to 15 are 0xE this indicates the game is trying to turn
    the wheel clockwise. If they are 0xF, it is trying to turn the
    wheel anticlockwise.

    Shifting bits 8 to 11 right 3 places, gives you a value that
    increments/decrements logically.

    Testing
    =======

    In service mode, view the OPERATOR SCREENS and go to the 2nd page
    where there are 2 interesting options:
        Steering During Attract Mode
        Steering Wheel Force

    When Steering During Attract Mode is enabled, when you watch the
    attract mode, you'll see the the m_wheel_force change value as the
    game attempts to move the steering wheel while the car is moving around
    the track.

    When Steering Wheel Force is set to 'Very light' you'll see
    m_wheel_force in the range -70 to 70. When set to 'Stiff' you'll see
    m_wheel_force in the range -127 to 127.
    */

    static unsigned int static_count = 0;
    static uint8_t static_data[4];

    //printf("wr2 offset=%04X data=%04X\n", offset, data);

    //Store the data in this array (Must be a better way to do read this stuff...)
    static_data[static_count] = data;
    static_count++;
    if (static_count > 3)
    {
        uint16_t force_combined, force_shifted;
        int m_wheel_force;

        static_count = 0;

        //Combine the force (1st and 3rd byte)
        force_combined = ((static_data[2]<<8)&0xff00) | (static_data[0]&0x00ff);

        //Shift the force so that it logically increments/decrements
        force_shifted = (((force_combined)>>3)&0x01f0) | (force_combined&0xf01f);

        //Use the force
        if ((force_shifted&0xf000) == 0xe000)
        {
            m_wheel_force = int(force_shifted&0x0fff);          //Clockwise force (+ive number)
        }
        else
        {
            m_wheel_force = int(force_shifted&0x0fff) - 511;    //Anticlockwise force (-ive number)
        }


        if (machine().input().code_pressed(KEYCODE_F))
        {
            popmessage("wr2 wheel=0x%04X force=%d", m_hdc68k_last_wheel, m_wheel_force);
        }
    }
}


Sure, what you said is correct, but using 3.3V at the spinner is worth a try

So I'm messing with this for the first time. I've used CRTEmudriver for a while but never used it to run modern PC games. So I'm just trying out a few games and was recommended this thread.

Instead of adding a modeline for every resolution, I saw a comment from 2020 that said to download a standalone version of Switchres. Is that still the recommended way to do this in 2024?

Yes, standalone switchres works perfect.

Thanks for the response. I gave Retroarch a try, and sure enough, the gun mapping is fine for the standard MAME core, and probably the offshoots too for games that run better through them. The other console cores (NES, PS1) I've tried have all been fairly easy to setup through RA, so I'll probably stick to those going forwards.

I think all I've got left is Dolphin, which I haven't tried setting up yet, and a few native PC versions of games. Aside from CXBX everything else looks like it's working fine.

I put in a request to join as well. Wouldn't mind getting mine up to speed.

Sent from my SM-S908U using Tapatalk