Bally / Midway MCR games

[ghost]

libretro/mame2003-libretro#121

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

[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

[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

[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?

[dankcushions]

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

can you clarify how?

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

[dankcushions]

yeah like i said, different mame cores do it differently (libretro mame current does it the 2010 way also), and it might be the right way. maybe mame standalone is always dealing with an internal 60hz timing cycle, but then 'corrects' it later?

i'm leaning towards just going with the 2010 way and seeing what happens :)

[ghost]

Bally and Atari games are now working great (plus some others), I don't even notice the difference in sound quality.

Regarding the issue of some games playing at the wrong speed (i.e. Robocop) IMHO I think this should be corrected so that they play the speed it was intended. We shouldn't have to 'manually' change the 'audio timing skew' to correct this. This is the only MAME core that does it. It isn't even documented anywhere that you have to change the timing skew, only on Github.

[Wilstorm]

Bally and Atari games are now working great (plus some others), I don't even notice the difference in sound quality.

Do you have a list of ROMs that have been corrected or the ones you have tested?

I always wondered about the sample rate with arcade games. The speakers we use for playback are so crappy that I wonder if it really makes a difference. The sample rate for practical purposes determines the max frequency. A 44.1kHz sample rate is around 20 kHz maximum frequency (human hearing max) but some folks like a sonar tech or young people can go higher. Hence those apps kids use nowadays that use audible frequencies outside of adults hearing.

Anyway at 22kHz you're talking a frequency range of 10KHz. Basically it's worse than a 128kbps mp3 but hence small tinny speakers don't really capture full range audio very well anyway.

[ghost]

With the default timing skew Robocop plays at 60 Hz. It correctly reports it in the RetroArch menu as 57.4 but as soon as you start a game, it goes up to 60 Hz. You can hear the difference with the music, it's faster and the speech is a higher pitch. If you manually set the timing skew to 0.02 it corrects it but we shouldn't have to do this.

[Wilstorm]

I guess I was speaking audio in general. The setup I have on my PC packs a wallop for sure. I can rock the whole house. I am not sure why but Iron Maiden has been my go to these past few weeks. It changes week to week. I was really looking forward to some Rush 2112 in Ready Player One but it didn't happen.

Is there a general guide line on what it does use so we have some idea. Not that it matters but more for informational purposes.

I think if Zappa would share just the ROM list name of the games tested that would be very helpful in what games can be moved to the working list.

I trust your ability with programming completely. No need to discuss timing here. I am not sure what level of programmer Dank is but I suspect he can take a crack at fixing it since it wasn't quite the solution he was looking for. I was ok with the solution you proposed but talking mechanics of how something works and actually programming it are two different things entirely. It's the difference between 1's and 0's, night and day. peanut butter and jelly, Laurel and Hardy, ok so DUO's can go on forever... ;)

[dankcushions]

@ZappaUtopia if you don’t like retroarch’s default timing skew you should go to them about it - there’s a topic on this very subject that mark linked to somewhere.

we shouldn’t bypass the api for stuff like this. please drop it.

[Wilstorm]

I really dont know where Dan is coming from with this.

Oh his name is Dan. Ok so that just dawned on me. Hmmm...I am not sure but online you really never speak out loud and I always thought Dank.

[markwkidd]

This kind of situation helps justify mame2003-plus. Even ignoring bugs within mame 0.78 the mainline mame2003 has some hacks that need fixing but 1) lots of people use it every day in it's current form and 2) no developers who originally ported it to libretro are very involved these days, so there is a lack of institutional memory about some parts of the libretro interface in particular. It's good to have a proving ground for mame2003 where it has less impact if there is a regression.

[ghost]

@dankcushions I don't mean anything by it, it just means that we are all playing a lot of games at the wrong speed by default. I'll say no more about it.

@Wilstorm Sorry, I never kept a list. I used EmuLoader frontend on PC and MAME 0.78. I scanned my current romset and ordered the list by Manufacturer to see what I didn't have added. Basically it was nearly all the Bally, Atari and Cinematronics plus a few extra. Big Run, Cisco Heat and Green Beret (parent) were a few of the others.

[Wilstorm]

please drop it.

Ok, sorry, I'm not trying to ruffle feathers but I'm a huge advocate for freedom of speech in all forms and mediums even if it goes in a circle. Some new ideas will come from this I am sure. It takes two to have a conversation after all.

If Zappa feels a need to share or ask questions and it looks like Grant was trying to understand or get some clarity too and he understands it on a another level completely. To attempt a change on a project he and two others mainly do all the programming on no less so why not? I thought that was why mame2003_plus_libretro came to fruition in the first place. For these types of scenarios.

I get the part of not wanting to participate that makes sense I guess though so...I guess that's good enough.

@ZappaUtopia - Ok, no big deal, if I am looking to play a game it will work or not but you do need to set the sample rate to 22050 kHz to get them working?

[Wilstorm]

Oh, nice, thanks Grant! Hopefully will do some testing this weekend.

[markwkidd]

I've also been reading this thread about RetroArch's audio skewing feature to try to educate myself on what's happening https://forums.libretro.com/t/perfect-audio-video-synchronization/12072

[dankcushions]

I have said several times that it's not "my way" or anything like that. i'm just explaining why the api would normally want the correct fps being set via the av_info cbs. as we can see some other mame cores have just set this to 60, so perhaps that is the most sensible way. i've never said i wanted it a particular way - it's just the part i'm familiar with, and i can see an effect when we 'bypass' it.

you've lost me on the audio/sample rate stuff - i know next to nothing about audio programming but it sounds like the way we're interacting with the audio cbs has been wrong from the start and i would be surprised if there wasn't a 'correct' way of hooking in to the api, but i wouldn't know where to start with that, so do it the way you prefer!

[dankcushions]

this is neat and efficient - like it!

the <60 test will effectively always be timing.fps=60 so i'd personally just lock it 60 just for the sake of readability. Qbertis 61 fps thats why i put that in the audio will chop a little without it