Bally / Midway MCR games

[ghost]

https://github.com/libretro/mame2003-libretro/issues/121

[ghost]

It might be worth making a build from this point in the project which is before alot of the major changes to the input handling were done, and then testing the MCR games to see if they now work correctly.

i'd do it myself but well i dont own any of the platforms this arcade core works on :)

https://github.com/arcadez/mame2003-plus-libretro/tree/7da127055ce603d5c1bba81127a994ae6c8ee9e7

[markwkidd]

Do you have some kind of device that can run RetroArch other than your xbox. No kind of desktop, laptop, or tablet?

I took a minute to try to build an old version and I'm running into my own stupidity probably because make isn't working as I expect.

git clone http://github.com/libretro/mame2003-libretro
cd mame2003-libretro
git checkout 7da127055ce603d5c1bba81127a994ae6c8ee9e7
make -j4

All I get is make: Nothing to be done for 'all'.

I'll try this again when I have more time.

[ghost]

Ah i forgot that you can make a RetroArch PC build, i'll need to look into what tools would be needed sometime as i'd like to run a few debugs with the current core to see what is happening exactly with those Midway MCR games eg why some of them lock into service mode on boot while some others actually start but refuse to coin.

Plus im keen to see if the games would actually work in an older version of this core as it will help to rule in or out a hunch i have of what might might be causing the problems as alotta these games are bona fida classics and it would be good to get em playable.

[markwkidd]

It's very easy to use RetroArch on PC. Glad to help if I can. Download RetroArch here: http://www.retroarch.com/?page=platforms

At this point you can start RetroArch and install the most recent mame2003-plus binary via the "Online Updater" which downloads cores that the buildbot has compiled.

If you want to compile directly for the PC version of RetroArch I should be able to help you get going there if you like. There are also pretty good docs on compilation here https://docs.libretro.com/ although I don't know if you will need all that information since you have experience already

[ghost]

Thanks for the links i will get around to this at some point but im busy with another project at the moment backporting the latest Taito C-Chip MCU code for a number of games.....

[img]https://mamedev.emulab.it/haze/2018/03/20/now-you-c-inside/[/img]

[markwkidd]

ah hah! no rush, but let me know if I can be your RetroArch helper -- it's the least I can do after all your backport work

[ghost]

whats your hunch on this one arcadez?

[ghost]

Hmm i seem to have it in my head either rightly or wrongly that some corewide input changes are to blame here as the games are locking into service mode on boot or refuse to coin this to me points to an input problem as dips and inputs are closely aligned.

These games tend to have their inputs and coins handled by the main CPU in this case a Z80 via the pia6821 machine emulated device the problem could lie here right enough. im gonna take the latest source and rollback the input changes to before july 2016 and see if i can then make a test build.

[ghost]

I'll do after work arcadez compiling on i7 with ssd on takes a few seconds

[ghost]

ok got it compiled arcades mc3 or mcr2 what games you need tested?

[ghost]

well changes i can tell you is rampage now goes to a black screen but you can use the tab menu. tapper goes to that pallete screen that rampage goes to after the inpt.c and h from the other thread. I think it is related to this code doesnt mean a 100~% it is though will need looked into more i imagine

[ghost]

one note of interest this is from the tree branch

[libretro INFO] osd_fopen (buffer = [/media/grant/empty/Download/Emulation/roms/arcade/MAME2003 None Merged//mame2003/nvram/tapper.nv]), (directory: [/media/grant/empty/Download/Emulation/roms/arcade/MAME2003 None Merged//mame2003/nvram]), notice the double // for the nvram that could be causing the problems as well

[ghost]

that in itself is probably easy enough to fix somthing else is calling osd_get_path_info with ".zip" as filename will need to check out if this is normal behaviour or not

[ghost]

well i took it back to basics i reverted too git reset --hard 82ef12f78c this is 2012 and the input system was as it should have been then and tapper accepts credits. The inptport.c and .h should be messed with as little as possible driver level assignments for input ports are defined here. I think all the changes that need made would be better made in libretro/input.c and leave the original input code as is.

you might have trouble getting roms to load just do this

strace -o logfile -e trace=file /home/grant/ra/usr/local/bin/retroarch (path to your retroarch)

try start tapper

close reatroach

less logfile | grep tapper.zip

copy the rom where it should be and enjoy it working

[ghost]

oh yes rampage works as well :). I not touching this one at all I know there is going to be big discussions on default setups ect.

I personally think we should just define the retropad buttons in mame something like button 1 = retropad a button 2= b in some config file and do an onload config change for sf2. Just my 2 pennies worth

[ghost]

this is where we broke midway input system https://github.com/libretro/mame2003-libretro/commit/497e5173bfbd10c1514c0e8c669c261adf02e784

[ghost]

Nice work tracking down the cause!! alotta folks will be happy to hear about this.

[dankcushions]

strange, that commit doesn't seem to have anything to do with input, but rather audio?

could be something to do with the info->timing.fps change?

[ghost]

well the input comes from the audio cpu maybe the timing is off and we are loosing chunks of data or its just out of sync. Its hard too keep up with all the changes in the input system. I would need more time to see if the other changes cause effects as well and i dont have much of that anymore with work

[ghost]

I looked at the code more didnt want to compile and say yes I followed what the osd_audio stuff was doing. I think that machine driver is internal to the game and we shouldnt be using it could explain the timing problems see src/cpuexec.c

[ghost]

/***** *

• Machine drivers

• *****/

/ Core MCR3 system with no sound / static MACHINE_DRIVER_START( mcr3 )

    /* basic machine hardware */
    MDRV_CPU_ADD_TAG("main", Z80, 5000000)
    MDRV_CPU_CONFIG(mcr_daisy_chain)
    MDRV_CPU_MEMORY(readmem,writemem)
    MDRV_CPU_PORTS(readport,writeport)
    MDRV_CPU_VBLANK_INT(mcr_interrupt,2)

    MDRV_FRAMES_PER_SECOND(30)
    MDRV_VBLANK_DURATION(DEFAULT_REAL_30HZ_VBLANK_DURATION)
    MDRV_MACHINE_INIT(mcr)
    MDRV_NVRAM_HANDLER(mcr3)

    /* video hardware */
    MDRV_VIDEO_ATTRIBUTES(VIDEO_TYPE_RASTER | VIDEO_UPDATE_BEFORE_VBLANK)
    MDRV_SCREEN_SIZE(32*16, 30*16)
    MDRV_VISIBLE_AREA(0*16, 32*16-1, 0*16, 30*16-1)
    MDRV_GFXDECODE(gfxdecodeinfo)
    MDRV_PALETTE_LENGTH(64)

    MDRV_VIDEO_START(mcr3)
    MDRV_VIDEO_UPDATE(mcr3)

MACHINE_DRIVER_END

[ghost]

think this could be linked to the change that was made that broke mcr3

https://github.com/libretro/mame2003-libretro/issues/75

in line 911 in mame.c I dont think we should be doing this at all the buffer should be handling its own under and over runs to keep it close to what it should be might be ok though im pretty sure the emulator changes these values to sync up when it all goes wrong

[dankcushions]

think this could be linked to the change that was made that broke mcr3 libretro/mame2003-libretro#75

can you clarify how?

[ghost]

I think the audio sync problem is the way we are handling the in the osd_audio_update the mame core. I dont know much about the retroarch api at all though. Im just pushing some thoughts the only place i really see needing set to the game refresh rate is already done at

./src/mame.c:717: params.fps = Machine->drv->frames_per_second;

for the mame core that is

[ghost]

Im going to catch some zzs before work will try looking into this propely when i get some days off. Ill need to compile the core at the point it works again and test them games and see if the video is good. That change on 2012 was to fix the mk sound so if i test my buffer theory there at that point ill know for sure

[ghost]

//============================================================ // osd_update_audio_stream //============================================================

int osd_update_audio_stream(INT16 buffer) { // if nothing to do, don't do it if (Machine->sample_rate != 0 && stream_buffer) { int original_bytes = bytes_in_stream_buffer(); int input_bytes = samples_this_frame stream_format.nBlockAlign; int final_bytes;

    // update the sample adjustment
    update_sample_adjustment(original_bytes);

    // copy data into the sound buffer
    copy_sample_data(buffer, input_bytes);

    // check for overflows
    final_bytes = bytes_in_stream_buffer();
    if (final_bytes < original_bytes)
        buffer_overflows++;
}

// reset underflow/overflow tracking
if (++total_frames == INGORE_UNDERFLOW_FRAMES)
    buffer_overflows = buffer_underflows = 0;

// update underflow/overflow logging

if (DISPLAY_UNDEROVERFLOW || LOG_SOUND)

{ static int prev_overflows, prev_underflows; if (total_frames > INGORE_UNDERFLOW_FRAMES && (buffer_overflows != prev_overflows || buffer_underflows != prev_underflows)) { prev_overflows = buffer_overflows; prev_underflows = buffer_underflows;

if DISPLAY_UNDEROVERFLOW

    usrintf_showmessage("overflows=%d underflows=%d", buffer_overflows, buffer_underflows);

endif

if LOG_SOUND

    fprintf(sound_log, "************************ overflows=%d underflows=%d\n", buffer_overflows, buffer_underflows);

endif

}

}

endif

// compute how many samples to generate next frame
samples_left_over += samples_per_frame;
samples_this_frame = (UINT32)samples_left_over;
samples_left_over -= (double)samples_this_frame;

samples_this_frame += current_adjustment;

// return the samples to play this next frame
return samples_this_frame;

}

from the original mame source

[dankcushions]

yeah the libretro api has to handle the audio and visual syncing so the translation to that is likely where the issue is.

we had an issue in that resampler code with the MK driver, although it was fixed a few months ago, for that specific case.

[ghost]

I dont think this code is the code that is stopping the mcr working. I think the original setting should be put back so much has changed since then though now you get an unresponsive gui with osd toggle with rampage. It could still just be that one setting that needs put back

[dankcushions]

which original setting?

[ghost]

info->timing.fps = videoConfig.fps;

[ghost]

is there anywhere the api is documented whats the difference between timing.fps and

struct retro_system_timing t = { Machine->drv->frames_per_second, 32000.0 };

like mame2000 does i cant seem to find the api docs at all just a brief emulator example

[markwkidd]

The API docs are not very detailed yet.

libretro.h is supposed to be self-documented but that only goes so far: https://github.com/libretro/RetroArch/blob/master/libretro-common/include/libretro.h

The fastest way to get an answer to that specific question is probably to ask in the #programming libretro Discord channel: https://discordapp.com/channels/184109094070779904/419255960465309700

Would you like me to pose it there?

As far as model cores: skeletor is a very simple libretro core created by one of the primary developers: https://github.com/fr500/skeletor

FreeIntv is a complete-ish Intellivision emulator that is native to libretro and therefore much simpler: https://github.com/libretro/FreeIntv/tree/master/src

[ghost]

cheers mark should be enough to get me started apreciated

[ghost]

I asked them myself they were helpful with the timing information they are both the same thing. It time to get debugging . Tthey said we might be setting the fps too soon. I can start digging my teeth into this soon but sleep after work first. Going to do some print debugging done like they suggested to see whats going on with the new setting and find out if its the sample or fps im pretty sure its the fps though,. The number one rule is dont assume anything lol

[ghost]

Well made some progress got bally games working the mame200 osd_code. I still think the underun/overun code needs added the bally framerates are off but its working

[ghost]

Would your fix also fix some of the vector games and a few others that have the same symptoms (just hang with a volume bar at the bottom or can't coin up) like Atari games Battlezone & Star Wars ?

[Wilstorm]

@ZappaUtopia - I think the Bally/MCR games are more like Kick, Tapper, Tron, Spy Hunter, Journey and Demolition Derby (one of the few games besides vector based games I have in AdvMAME along with Xenophobe) since it's the only emulator that runs them.

[ghost]

Yeah I know, but some Atari games and a few others give the same problem when starting (can't coin up or hang with a volume bar at the bottom). I was just asking if the fix implemented will also fix these. (Journey works anyway). (MAME2010 runs all the games you listed I think).

[ghost]

@arcadez ill need to update this seperatly for us as it will change out libretro.c im just going to run mk3 for 20 minutes to see if all is ok there shoudl be really but helps to make sure then ill pass the changes along

[Wilstorm]

@ZappaUtopia - I was wondering if the comment was based on symptoms. I am not sure if it's correct way to look at it but I always think of the driver they are working on and what games it affects. If it's a different driver then a separate issue might help them track it properly. Unless it was global or something like samples...nice catch! You probably already know but AdvMAME really shines when it comes to vector based games like Battlezone & Star Wars. Nothing really compares at this point but I think Mark has a keen eye for a fixer.

[ghost]

this will be a global issue its not completely fixed the sync needs tightened on the audio. Thats why games like robocop and mcr2 are out of sync well you will be able to see better now we are getting the data we need to get the games to start

[ghost]

@grant2258 I followed the thread that @windale reported over a year ago that you posted about here https://github.com/libretro/mame2003-libretro/issues/75 . It was about some games playing at 60 Hz when they weren't supposed to (Robocop was one of them which should be 57Hz) and it makes the game and sound play slightly too fast. Their workaround rather than solution was to set audio_max_timing_skew = 0.02. It seemed most people were in favour of playing them at the wrong speed but smooth 60Hz. I personally prefer the accurate speed like windale. Is this what it's all about or something completely different ?

[ghost]

well the audio handling is what throwing the fps timer off with robocop. The code still has to bee changed to fix this 100%.

The main thing is to get the inputs workings againand we know where the syncing issues are now. if you disable the audio cb robocop will runs at 57 fps. The mortal combat fix was just part of the mame code above i posted implemented. Unless there are other timing issues this will be fixed the mame code is available if someone beats me to it

[ghost]

@arcadez I made the changes here try the games your having input problems with. There is still a fps issue in some games but thats not an issue added its always been there.

Please only report games with sound that did work on mame 2003 and doesnt now. I dont think there will be any but never say never.

[dankcushions]

@ZappaUtopia

@grant2258 I followed the thread that @windale reported over a year ago that you posted about here libretro/mame2003-libretro#75 . It was about some games playing at 60 Hz when they weren't supposed to (Robocop was one of them which should be 57Hz) and it makes the game and sound play slightly too fast. Their workaround rather than solution was to set audio_max_timing_skew = 0.02. It seemed most people were in favour of playing them at the wrong speed but smooth 60Hz. I personally prefer the accurate speed like windale. Is this what it's all about or something completely different ?

it's not a "workaround", it IS the solution that specific issue. you must understand that it is simply how libretro works (probably its best feature, even) - it handles audio/video sync. as part of that, it is able to skew the framerate to match up with your display refresh rate so you don't get judder (within the tolerance specified by audio_max_timing_skew) and resample the the audio in tandem. if you don't want it to do that, you simply set audio_max_timing_skew to something lower/0.

there is no fix to be done to the cores for that issue, nor should any libretro callbacks be avoided to bypass this, or similar functionality (not sure if that's what you've done, @grant2258 ?).

[ghost]

i havent avoided any callbacks at all you can see the code ive changed. If i did it would be running the right fps

[ghost]

@dankcushions Just out of interest, when you say there is no fix to be done to correct the fps, how come MAME 2010 plays them at the correct speed (Robocop etc.) ?. Just curious.

[ghost]

@ZappaUtopia thats not what he is saying he is saying dont avoid calls because it could mess up the timing system. The timing system cant be hacked at all. The samples can be handled within the osd_audio_update and not main core changes it could mess other games up

[dankcushions]

@dankcushions Just out of interest, when you say there is no fix to be done to correct the fps, how come MAME 2010 plays them at the correct speed (Robocop etc.) ?. Just curious.

assuming the retroarch configuration is the same in both setups, maybe mame2010 is failing to update info->timing.fps when it loads a games with a fps that is not 60? in the code it appears this value defaults to 60: https://github.com/libretro/mame2010-libretro/blob/545acf2ef0031ef6f76acbaab4e37737b6fa8084/src/osd/retro/retromain.c#L764 and https://github.com/libretro/mame2010-libretro/blob/545acf2ef0031ef6f76acbaab4e37737b6fa8084/src/osd/retro/retromain.c#L68

it looks like it's attempting to update it here: https://github.com/libretro/mame2010-libretro/blob/545acf2ef0031ef6f76acbaab4e37737b6fa8084/src/osd/retro/retromain.c#L394 - but i'd have to debug it to find out if it's getting the expected values.

hmm, also it is using the RETRO_ENVIRONMENT_SET_GEOMETRY callback which may not be sufficient to update timings. i think it might need to call RETRO_ENVIRONMENT_SET_SYSTEM_AV_INFO instead. interesting!

if you lower the skew it will play the games at the correct framerate in mame2003.

[ghost]

the timing changes when something is out of sync in the retro_run

robocop should be running at 57fps go into the retroach menu in mame2003 leave it sit there for a while no samples will be playing and it will settle at 57fps (leave the fps counter on) play again and itll change it is all about the update_audio that is casuing the need for scewing