Recent Posts

Unplugged my Golden Tee Fore Complete. After plugging back in, I get the following error:

161 - Real Time Clock Power Loss

I hit F1 to boot and then get an error saying "Non-System disk or disk error, replace and strike any key when ready"

Any thoughts?

Ah jeez, that doesn't sound good. I tested it with mouse and also a flight yoke. Have you made this change too...

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, change the ITP_PADDLE steering control for:
PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

When you say it not working,  is that even without pressing the S key at all?

Yeah i did that it just totally messes up the steering and makes it unplayable, a flight yoke has a much narrower range of movement than a driving steering wheel i guess thats the problem with the code? Pressing the S key doesnt help at all because the wheel goes out of alignment as soon as you start the game even on the menu where you choose to skip flight training it doesn't work just starts acting really weird. It goes way out of alignment even when not moving it fast at all and just acts really bugged tbh it's unplayable. If you can try it with a 900 degree wheel give it a go and see what happens. I made a account on the bannisters forum you linked here but it seems like the admins not going to approve it and it was 23 hours ago i made the account and it says if it's not approved in 24 hours it gets deleted.

Mame 149 is fully working. ( well  CHD's are extracting now) My first time working with CHD's. 6 days to download. (WOW, it all extracted. 47.3 gig)
Retroarch. Mame 2003 and 2010 work just as well.
no luck with ps1 yet. no luck with N64
T16 and SNES work fine.
this really is a beta set up.
I still want to try the steering wheel and PC games for low end computers. I have zero experience on actual PC games. 
Kodi still needs installed.

David the Trash Gnome

Ah jeez, that doesn't sound good. I tested it with mouse and also a flight yoke. Have you made this change too...

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, change the ITP_PADDLE steering control for:
PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

When you say it not working,  is that even without pressing the S key at all?

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