Recent Posts

Hi Geecab i just tried your code and it seems to be totally not working at all for me. The steering wheel doesn't behave normal at all and starts pulling to the side etc. How is it your testing this code? On a controller? It doesn't seem to work at all for a steering wheel. Maybe im doing something wrong?

Code: [Select]

    // Merge in the wheel edge latch bit
    if (m_hdc68k_wheel_edge)
    {
        result ^= 0x4000;
        printf("hdc68k_port1_r: merge latch result=%04X m_hdc68k_last_wheel=%04X\n", result, m_hdc68k_last_wheel);
        m_hdc68k_wheel_edge = 0;
    }


    m_hdc68k_last_port1 = result;
    return result;
}
   

uint16_t harddriv_state::hda68k_port1_r()
{
    uint16_t result = m_a80000->read();

   if (m_hdc68k_wheel_edge)
    {
        result ^= 0x4000;
        printf("hda68k_port1_r: merge latch result=%04X m_hdc68k_last_wheel=%04X\n", result, m_hdc68k_last_wheel);
        m_hdc68k_wheel_edge = 0;
    }

    return result;
}

uint16_t harddriv_state::hdc68k_wheel_r()
{
// grab the new wheel value
uint16_t new_wheel, raw_wheel = m_12badc[0].read_safe(0xffff);
int wheel_diff = 0;
bool is_wheel_increasing = false;
static uint8_t wheel_snapshot = 0;
static uint8_t wheel_offset = 0;
static bool steering_enabled = true;

if (machine().input().code_pressed(KEYCODE_S))
{
if (steering_enabled)
{
popmessage("Steering disabled (Re-center your wheel now...)");
steering_enabled = false;
wheel_snapshot = (m_hdc68k_last_wheel+wheel_offset)&0xff;
}

return ((wheel_snapshot << 8) | 0xff);
}
else
{
if (!steering_enabled)
{
popmessage("Steering enabled");
steering_enabled = true;
wheel_offset = (wheel_snapshot - raw_wheel)&0xff;
m_hdc68k_last_wheel = raw_wheel;
}
}

// Work out which way the wheel is spinning
if((m_hdc68k_last_wheel < 0x400) && (raw_wheel > 0xC00))        is_wheel_increasing = false;    //Wrapped from bottom to top
else if ((m_hdc68k_last_wheel > 0xC00) && (raw_wheel < 0x400))  is_wheel_increasing = true;     //Wrapped from top to bottom
else if(m_hdc68k_last_wheel > raw_wheel)                        is_wheel_increasing = false;
else if(m_hdc68k_last_wheel < raw_wheel)                        is_wheel_increasing = true;

//Steering damping:
//Ensure we don't jump from one encoder value to another too quickly confusing the game
//The game is aware only of changes to m_12badc's lower byte. This means the game can get easily confused if you where to move
//the wheel very quickly from say position 0x800 to 0xC12 in one cycle (Which was perhaps physically impossible using the
//actual arcade encoder). The game would be under the impression the wheel has moved only 0x12 values, rather than 0x412 values.
//If we detect a large change, slowly feed that information back to the game in managemtble amounts.
new_wheel = m_hdc68k_last_wheel;
while(new_wheel != raw_wheel)
{
if (is_wheel_increasing)
{
if (new_wheel >= 0xFFF) new_wheel = 0x000;
else new_wheel++;
}
else
{
if (new_wheel <= 0x000) new_wheel = 0xFFF;
else new_wheel--;
}

//Lets say the encoder can't move more that 32 teeth per cycle...
if (wheel_diff++ > 0x10) break;
}

if (machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("wheel=0x%04X", new_wheel);
}

m_hdc68k_last_wheel = new_wheel;
return ((new_wheel+wheel_offset) << 8) | 0xff;
}
I'm trying this on a Logitech wheel at 900 degrees for input and having no luck at all.

Hello Groovy MAME community,
I have a similar problem with my arcade cab. I bought a ultra wide LCD for my cab, to use it for displaying the marquees. It has a 1920x360 resolution.
I use a Radeon HD 4890 on Windows 10 with CRT Emudriver & CRT Tools 2.0 beta 15 (Catalyst 12.6) for Windows 7/8/10 64-bits. Everything is fine, as long as i only use the CRT in the cab.
The problems start, while using MAME with two screens. I plugged the (marquee) LCD into the HDMI output of the mainboard using the Intel 4600 Graphics of the CPU. I did this, because i wanted to avoid conflicts with the CRT Emu drivers and the 15khz resolutions. Sadly this does not work (at least not as expected). Either Windows 10 or MAME are not able to treat the screens with different resolutions. Starting MAME brings up a error window, claiming "switchres" can not find a suitable resolution for the LCD screen and then starts MAME in a window (not fullscreen) on the CRT and use (i think so) a super resolution for the LCD.

So basically i think the problem is to find a way to use only 1920x360 for the LCD and all the switchres magic for the CRT. I am desperate here .

In order to use the marquee feature, use a command line like this:

Code: [Select]

mame64 -numscreens 2 -screen0 \\.\DISPLAY2 -screen1 \\.\DISPLAY1 -view0 standard -view1 marquee -use_marquees bublbobl

Is there any way to configure this in the MAME.ini ?? So that this setup is used for every game, that would be cool.
Any help here, is very much appreciated.

Hi geecab i think im confused because of the code changes you made recently on the version your working on because it changes the behaviour of the emulated machine to be more accurate for the latchbit and there was another factor at play too.

I deleted my NVRAM and used the version of mame thats available for download just now and when you load up street drivin' and calibrate the brake then go into the game the car can do a full turn the steering appears not to be limited, i compared it to the arcade doing a full turn the car turns just as sharp there is a video on youtube of a car doing a full turn to the left at the start in hard drivin and if you compare that to what you see in street drivin the car turns the same as that video with the port_minmax set to 0x000,0x3ff and im using a logitech wheel set to 900 degrees. Car can crash and go offroad and does not exhibit the steering bug that was in the compact version of race drivin and hard drivin.

That is when the code in harddriv_m.cpp was like this so the behaviour you are describing would never have been seen by myself or others using the default code.

   

Code: [Select]

/* merge in the wheel edge latch bit */
if (m_hdc68k_wheel_edge)
result ^= 0x4000;

m_hdc68k_last_port1 = result;
return result;
}


uint16_t harddriv_state::hda68k_port1_r()
{
uint16_t result = m_a80000->read();

/* merge in the wheel edge latch bit */
if (m_hdc68k_wheel_edge)
result ^= 0x4000;

return result;
}


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;
}


There is another thing that was adding to the confusion. On my own build of harddriv.cpp  i still had a 0x400 range of steering but i was using 0x800 as the center point and and my code looked like this

Code: [Select]

PORT_BIT(0xfff, 0x800, IPT_PADDLE) PORT_CONDITION("mainpcb:SW1", 0x700, EQUALS, 0x100) PORT_MINMAX(0x600, 0xa00) PORT_SENSITIVITY(1) PORT_KEYDELTA(0) PORT_NAME("Original MAME")
Now this was being used in conjunction with the latch bit fixes you made in your previous code changes which resulted in my wheel never going off center even with a 0x400 range of motion and the default nvram because the center point was still 0x800..........

When i change my harddriv.cpp to have the 0x000 as the starting point and 0x400 as the end point and using 0x200 as the center AND your code fix for the latchbit behaviour i get exactly the same behaviour you describe. This is behavior still happens with your modified code even if i change this ((m_hdc68k_last_wheel & 0xc00) != (new_wheel & 0xc00)) to  ((m_hdc68k_last_wheel & 0xf00) != (new_wheel & 0xf00)) which is the default on mame right now because the latchbit behaviour above that part of the code was fixed by you in your version so now i understand what the discrepancy has been between what you observed and what i observed! 

I just spent some time trying to figure it out because something seemed off to me now it makes perfect sense!

Sony may also come to their senses at some point.  At they scale they produce things, it would be hard to sell me on the idea that they lose money at the price these are being offered at.  And the more they sell, the quicker they get a return on their tooling and setup investment, and the quicker they can start dropping the price to bring more PS5 owners into the VR fold.

When Sony was asked about potential PC compatibility, the answer was supposedly a vague "PSVR2 was made for the Playstation5", which doesn't exactly sound like a "never gonna happen".  I guess we will see eventually.

Called it.

David was a pillar of the community and pulled a thorn out of my paw once, don’t talk trash about gnomes, bro.

Hi Yolo!

>>that is a really good solution for the Hard Drivin' Airborne off center bug. I'll need to try it out and see! I
Cool, hope it helps

I have to say, I do think Street Drivin is a compact model (Uses 2 optical encoders). It recenters the steering the same as Hard Drivin and Race Drivin compacts. I can simulate it. The main difference is that Hard/Race Drivin Compacts have a CNTSPTRN value around 1024. Street Drivin has a CNTSPTRN value of around 512.

By having your control setup as IPT_PADDLE with PORT_MINMAX to (0x000, 0x3ff), starting at position 0x200, you'll never see Street Drivin try to recenter. You are limiting your turning values to -512 anti clockwise, +512 clockwise (Thus you are not allowing yourself to complete a 1 full rotation in either direction). You have to turn quite a bit beyond a full rotation to cause a recenter. I think this is why it appears setting PORT_MINMAX(0x000, 0x3ff) might have fixed things for you.

Another thing to remember with your Street Drivin setup, if your hdc68k_wheel_r is set to trigger a 'centre edge' only at 0x000, 0x400, 0x800 & 0xC00, you never see a center edge triggered within that control range you have specified. You could manually trigger one at 0x200 and watch your steering offset by -98 (because -98 is the default patcen for street drivin. Unless you've editted the nvram and changed patcen to 0 that is...).

You could do something similar with Hard/Race Drivin' and see the same thing IPT_PADDLE with PORT_MINMAX to (0x000, 0x8ff), starting at position 0x400, You are limiting your turning values to -1024 anti clockwise, +1024 clockwise (Thus you are not allowing yourself to complete a 1 full rotation in either direction). That is assuming you've got an nvram CNTSPTRN set to 1024 patcen set to 0.

I guess in the end though, it doesn't really matter, it nice to know what's going on behind the scenes, but what works for you works for you

Btw. New observation (Which desn't really help us but worth mentioning): I noticed when editing nvrams, I couldn't change street drivin's CNTSPTRN from 512 to 1024. Similarly, I couldn't change Hard/Race Drivin's CNTSPTRN from 1024 to 512 (The nvrams are loaded ok, but the new values are ignored). I summarised that the CNTSPTRN value can't be changed massively. Changing the CNTSPTRN works fine if you change them +/- say 100.

Btw. Another observation: I think the compact games don't 'have' to see a center edge always. With the original hardware it would be possible to miss that one single notch on the encoder disk (So the programmers wouldn't want the game to freak out if it were to miss one). Without triggering a center edge at all, the game would just calculate where the rotational center of wheel is based on its CNTSPTRN values, and it would assume the position of the wheel at first reading would be the center position.

When I plug the Ipac into my PC running windows and open WINIPAC software I can see that the 1 key is my shift key. If I open a shell session I can see 1 appears after I press and release my P1 Start button and from what I have read this indicates its in shift mode.

Almost right.  When you hold down P1 Start, the IPac is in shift mode.
- if you trigger an IPac input that has a shifted function before you release P1 Start, the IPac will send that input's shifted function keystroke.  For example if you press and hold P1 Start then press P1B1, the shifted function keystroke for Coin A (5) is triggered.
- If you release P1 Start without triggering an IPac input that has a shifted function, the IPac goes out of shift mode and sends the regular keystroke for the 1START input. (1)

Issue: I can't get the shift keys working in any game. Example; If I hold down P1 start and push the P1 joystick down nothing happens.
If I plug in a keyboard and hold down '1' and press the 'p' key the game pauses.
If I plug in a keyboard and hold down '1' and press the down arrow the game doesn't pause - but the game responds to the down press.

Shifted functions are generated by the IPac firmware when the right combination of IPac inputs are grounded.

The keyboard and the U360 are connected to USB -- not the IPac inputs -- so pressing keyboard keys or moving the U360 can't trigger shifted functions on the IPac.

In order to trigger the Pause shifted function of the IPac (keystroke "P"), apply ground to input "1START" on the IPac (press and hold the Start 1 button) then apply ground to input "1DOWN" on the IPac.

Since your U360 doesn't connect to the IPac 1UP, 1DOWN, 1LEFT, and 1RIGHT inputs, here are several approaches you can use to generate those shifted function keystrokes:

1. Dedicated admin buttons connected to the unused 1UP, 1DOWN, 1LEFT, and 1RIGHT inputs.
- Reprogram these currently unused IPac joystick inputs to send the desired keystrokes.

2. Shifted functions from player buttons.
- By default, the P1B1 shifted function is Coin A. (5)  Program the desired keystrokes as shifted functions of the other player buttons.  For example, you could program the P1B2 shifted function as Pause. (P)

There are advantages and disadvantages to both approaches.  Which approach is better?  That depends on your personal preferences.
https://wiki.arcadecontrols.com/index.php/FAQ#Number_of_admin_buttons


Scott

N00b here so please bear with me...

Issue: I can't get the shift keys working in any game. Example; If I hold down P1 start and push the P1 joystick down nothing happens.
If I plug in a keyboard and hold down '1' and press the 'p' key the game pauses.
If I plug in a keyboard and hold down '1' and press the down arrow the game doesn't pause - but the game responds to the down press.

Im expecting the default behaviour shown here: https://www.ultimarc.com/control-interfaces/i-pacs/i-pac-ultimate-i-o/

Setup:
Retropie on Rpie 4
Mame emulator
Ulitmarc Ipac ultimate IO with buttons wired to the board rather than the joystick
Ultimarc U360 joysticks plugged directly into the pie via USB
I haven't tried changing the mapping of any keys on the Ipac - Im just using the defaults it was shipped with.

When I plug the Ipac into my PC running windows and open WINIPAC software I can see that the 1 key is my shift key. If I open a shell session I can see 1 appears after I press and release my P1 Start button and from what I have read this indicates its in shift mode.

What am I doing wrong here? All of my standard buttons are working as expected on various emulators but I can't get shift keys without a keyboard. Please help!

I think it might be hard for anyone who doesn't engage in a subtractive art like this to appreciate it fully.

True dat. The guy who made the viking that I copied also made some cute gnomes. Now take a wild guess which ones most people liked more 

I have been meaning to write a step by step of how to do this without soldering. This is not the best description but at least it can help someone. I still need to get on one of my cabs and copy up the full Arduino code. The previous Arduino code was for lighting up a single led but for my steps below, it lights up a full ws2812b strip when in first place.


No soldering needed at all. Code is mostly ready to go except you may need to change the number of leds or what led to start the lights at (since some of the leds are outside of the marquee and I don’t want them to light up). Using an arduino with pre soldered connectors, wires that connect directly to the arduino, and using a barrel connector that has screw terminals also helps make this solderless.


1) Unwind the whole ws2812b led strip (since we want the end of the strip wound up the most on the inside)
If you look at the strip, in between each led has an arrow pointing a single direction. This arrow should point up away from the bottom of the cable. In other words, the arrows will end up pointing from the Arduino toward the marquee end (data flows from Arduino toward the end of the led strip or from “RA in RAce leadER to the “ER” at the end of the leader word)
2) Insert a (male) wire into the bottom of the cable into the black piece so one wire goes into the hole where the white cable is and insert another (male) wire where the green cable is and then add on a female to female adapter at the end of both of those (so it can then plug into the Arduino).
3) Put the cable you added that continues the white cable and plug this into the gnd on the Arduino 
4) Put the cable you added that continues the green cable and plug this into D3 on the Arduino
5) Strip the ends of the white and red wires that dangle out of the end of the led strip
6) Put the white striped wire into the negative side of the barrel connector and insert the red wire into the positive side of the barrel connector (screw terminals)
7) Count out 40 leds (or a different number if desired) from the led strip cutting half way beteeen the copper pads after the 40th.
Connect a mini usb cable to the Arduino and plug this into your pc
9) Plug in the electrical outlet (connected to the barrel cable that has the red and white wires in it).
10) Download Arduino Ide, start it up, on top menu go to tools >  board > change to Arduino nano
11) Go to tools > port > change com port to your com port for the usb you just plugged in. (If unsure, unplug the usb and see which com number goes away in the menu and which one comes back after plugging back in). Note If you get an error about port conflict when uploading or later on in future steps, right click mamehooker (assuming you already installed it before step below) in your bottom right tray icon and close. Mamehooker takes over your com port.
12) Paste in the code below (code to be uploaded soon hopefully)
13) Click the checkbox near top left to compile and then click the right arrow icon to the right of that to load the program (sketch) onto the Arduino
14) In the ide, Go to tools > serial monitor > type in “3,1,x” without the quotes and hit enter. And then type in 3,1,x again and hit enter key . It should light up. If it does not, review the steps and verify you are on the correct com port in the Arduino ide and the Arduino sketch was uploaded to the Arduino. Also try turning the barrel connector slightly (one time I had to twist it slightly for some reason)

15) Download mamehooker by going to here (http://dragonking.arcadecontrols.com/static.php?page=aboutmamehooker) and hit control-f and find “mamehooker” and there is a download link on the right side of the web page
16) Install it (i installed to c:\mamehooker\*) and then right click mamehooker.exe and choose run as admin (MUST DO THIS FIRST ONCE! Ignore errors if any!)
AFTER YOU HAVE RUN AS ADMIN ONCE, go to bottom right system tray in windows and right click and close mamehooker and ignore any errors if any (first time run as admin is necessary for permissions).
17) Now open up mamehooker.exe again from bottom right Windows system tray WITHOUT running as admin option (from now on no admin needed as long as ran once)
Click options and allow auto find of parameters.
18) Go to your Mame folder that you have Mame.exe installed in and find the Mame.ini file (IF YOU HAVE <game>.ini files named as the game, you have to do change those ini files. as well) and update the ini so the line that says “output” is set to “windows”.
19) Open up Mame and open up a game that has outputs like sfrush and let mamehooker find the outputs. It should auto create a sfrush ini file
Change the mamehooker sfrush.ini to look like below (need to upload this as example as well but earlier posts may have it). I will also attach other mamehooker ini settings that I have.
20) Change the number 4 (4?) in these mamehooker ini files to the com port your Arduino took.
If desired, change the 3,1,x to start with another number (2,1,x for green. 4,1,x for blue, etc)
21) If desired, Download the non-commercial license Arcade1Up marquee 3D print and edit in 3D print software (I use Cura) to be 35% on the height and width (I kept length the same) and 3D print it.
22) Purchase a see through RACE LEADER marquee print from ArcadeGraphix if desired
23) Purchase the black see through plexi glass from Tap Plastics here (https://www.tapplastics.com/product/plastics/cut_to_size_plastic/black_led_sheet/668?gad_source=1&gclid=Cj0KCQiAgK2qBhCHARIsAGACuzmFTLacS1j_ct4d6jj8vSLcML676miM_Vqhu0mv0N58fzFFmexLrvcaAlp4EALw_wcB ) if desired for blacked out look when not on. Size info for my particular size marquee was “Chemcast Black LED Acrylic - Black 1/8 (.118)" Thick, 1-1/2 inches Wide, 17-9/16 inches Long, Color: Black
24) Get in 1st place and Enjoy!!

If you want to add custom race leader lights to games that don’t support it out of the box, see posts above.