CPS3 3rd strike incorrect core timing

[fabricioanciaes]

3rd strike is supposed to run at 59.583hz on original hardware.

Statistics overlay on retroarch while running 3rd strike through fbneo shows the core timing as 60.000hz

Source for the 59.583hz info: https://forums.shoryuken.com/t/3rd-strike-lag-speed-tests/167456

If you want to be absolutely sure about the refresh rate I can later verify with a OSSC (since it reports the actual refresh rate of the video signal) on real hardware with a friend.

[barbudreadmon]

MAME think it runs at 59.826105hz You think it runs at 59.583hz Who is right ? :)

@dinkc64 what do you think about this ?

[furiadeoso]

Perhaps @RagingNoob can tell something about this.

[barbudreadmon]

On a sidenote, i know some drivers in fbneo are rendering at 60fps despite the original refresh rate, but actually got their timing right (i.e they should stay in sync when comparing side by side with the original), it might be the case for cps3, in which case i'm not sure it would be a good idea to change this (especially from a libretro core POV : i heard several times that the libretro ecosystem handle 60fps content better).

[RagingNoob]

I did a basic comparison test last year with FBA vs CPS3 hardware running SF3. https://www.youtube.com/watch?v=4EAoqUHy5BI

Due to the core timing being exactly 60.000Hz this runs too fast compared to the actual CPS3 hardware. This also applies to FBNeo.

Some months after my tests a YouTube user "tengu" changed RA's refresh rate and did the following comparison with CPS3, Retroarch, OE & Shmupmame.

_"In Retroarch's config file (retroarch.cfg) I set "video_refreshrate = "59.299999" (retroarch randomly changes it to 59.333333)."

https://www.youtube.com/watch?v=4hk46tuP2NY

As with CPS1 (59.63 fps) and CPS2 (59.63 fps) core timings matching authentic hardware (when enabling GSync/Freesync), CPS3 needs to be corrected via the "Sync to Exact Content Framerate" option.

[RagingNoob]

@furiadeoso If you can extract the exact frame rate CPS3 runs at it via OSSC it would help to clarify the information and begin proper testings so the core framerate for that game can be adjusted.

[furiadeoso]

OSSC is "Open Source Scan Converter"? I don't have that hardware, sorry.

[furiadeoso]

As with CPS1 (59.63 fps) and CPS2 (59.63 fps) core timings matching authentic hardware (when enabling GSync/Freesync), CPS3 needs to be corrected via the "Sync to Exact Content Framerate" option.

What is that option? A RA video option?

[RagingNoob]

If you want to be absolutely sure about the refresh rate I can later verify with a OSSC (since it reports the actual refresh rate of the video signal) on real hardware with a friend. ^ Ask your friend!

FBA and FBNeo run cps core drivers which are used by RA. In RA you can force the video driver to run the core at the fps it was originally running on the actual hardware.

https://www.libretro.com/index.php/category/g-sync/

[barbudreadmon]

@RagingNoob So this setting prevent RA from trying to change framerate to 60hz ? Does it require gsync/freesync ?

[RagingNoob]

Thanks for the URL editing @barbudreadmon , I now understand external link codes hah!

I'm not sure I understand your question completely but I shall try to explain myself a bit more.

A standard LED monitor has fixed refresh rates 50/60/75Hz etc. A Gsync/Freesync supported monitor can have a dynamic Hz (adaptive sync).

Example:

FBNeo has CPS1 core speed @ 59.63Hz

• If you are using a standard 60Hz LED monitor with no Gsync/Freesync and you enable VSync then the CPS1 game on the PC will **run faster** than the actual CPS1 hardware, but the video output will render smooth with no screen tearing

• If you are using a standard 60Hz LED monitor with no Gsync/Freesync and you enable VSync but also enable adaptive sync then the CPS1 game will run at approximately 59.63fps but the video output will be jittering and may screen tear also.

• If you are using a Gsync/Freesync supported monitor and you enable VSync but also enable adaptive sync then the CPS1 game will run at exactly 59.63fps and the video output will render smooth with no screen tearing

The CPS3 core on RA runs at 60.000fps, but this is the incorrect speed. it is too fast. We need the correct value.

[barbudreadmon]

So you need a screen with gsync/freesync to play those games properly at their original refresh rate. Thanks for the explanation !

[RagingNoob]

In src/burn/drv/capcom/cps.cpp

`INT32 nMemLen, i;

if (Cps == 1) {
    BurnSetRefreshRate(59.63);
} else {
    if (Cps == 2) {
        BurnSetRefreshRate(59.63);
    }
  else {
    if (Cps == 3) {
        BurnSetRefreshRate(59.XXX);
    }
}`

Something like that yes?

[barbudreadmon]

https://github.com/libretro/FBNeo/blob/master/src/burn/drv/capcom/cps.cpp is for cps1/cps2 only (they are mostly the same hardware).

cps3 (totally different hardware) is located at https://github.com/libretro/FBNeo/blob/master/src/burn/drv/cps3/cps3run.cpp

[fabricioanciaes]

I've managed to find a picture of a OSSC hooked up to a cps3, the refresh rate reported is 59.56hz

[RagingNoob]

The OSSC is interesting and seemingly can have various results depending on how it has been connected. The OSSC converts SCART and Component to DVI/HDMI.

"SuperGun -> OSSC (CPS3): 265p 15.73khz 59.37hz SuperGun -> Extron-> OSSC (CPS3): 264p 15.72khz 59.56hz (I did see it as 262p 15.73khz 59.59hz for the 1st 5 seconds when I turned on the supergun)" Source

The Extron in this case was the CrossPoint Ultra 168 which is a 16x8 ultra-wideband matrix switcher

The values from @fabricioanciaes match with the results of this setup: CPS3 > SuperGun -> Extron-> OSSC = 264p 15.72khz 59.56hz

(IMPORTANT) bypassing the Extron resulted in: CPS3 > SuperGun -> OSSC = 265p 15.73khz 59.37hz

A YouTube video running CPS3 SF3 with OSSC states: "* 3S actually outputs at 59.6fps" Source

There are many conflicting results (59.826105, 59.6, 59.59, 59.583, 59.56, 59.37) which I really don't like so we need a definitive answer if possible.

There is also the following CPS3 Resolutions pixels: 384×224 (standard mode) / 496×224 (widescreen mode)

Does this also affect the results of the video ouput frequency?

[barbudreadmon]

There is also the following CPS3 Resolutions pixels: 384×224 (standard mode) / 496×224 (widescreen mode)

Widescreen mode is only available on sfiii2 (from service menu), however my understanding is that the screen for widescreen version was different, isn't it possible that the refresh rate was different too ?

As long as there are no definitive answers about all of this, it might be better to keep the current 60Hz, even if it's obviously wrong too ?

Also, mame changed cps3's screen rate from 60hz to 59.826105hz only recently, comments on that commit might be interesting : https://github.com/mamedev/mame/commit/a2f4131c8907b6b164b65239f92d5e4538fcc44d#diff-b7295a09783ff0178e3add3fe5cb5b84

[fabricioanciaes]

There are many conflicting results (59.826105, 59.6, 59.59, 59.583, 59.56, 59.37) which I really don't like so we need a definitive answer if possible.

This seems to be something related to the PSU then, I've heard about it actually hapenning in some regions in japan where the game ran a bit faster because of the power, but this was for CVS2 (naomi).

We need to find the actual result

also to clarify, my photo was the OSSC hooked up straight to the supergun via Component, nothing in between.

[fabricioanciaes]

I'm pretty certain that different power supplies are the cause for the inconsistent readings.

My cbox supergun uses one of those cheap chinese laptop power supplies, which are less than ideal condition to run arcade hardware, while running my Neogeo MV1FZ the OSSC reports 59.40hz which is supposed to be 59.19~hz. its pretty much agreed on that 59.19 is the default for MVS.

The variance on refresh rate is mostly because of that, I'm pretty confident on that.

I think we have 3 options: A) we figure the exact perfect condition for the cps3, the right ammount of power B) we average from a bunch of boards with a certain bias to the value that is most consistent C) we reach out to the creator of CPSHDMI, since the new board has CPS3 compatibility, he might have a lot of knowledge about the subject.

Keep in mind that different board revisions, different crystals, hardware degradation, quality of the power coming in, different power supplies, etc. can be a factor. I think its best to match the closest we can get to what you would expect from hooking up original hardware with somewhat correct voltages.

From the numbers we have 59.826105, 59.6, 59.59, 59.583, 59.56, 59.37 it seems to be around 59.6 since most values group very near that, which seems to match cps2 too.

[barbudreadmon]

@fabricioanciaes Did you look at the mame commit i linked ? Basically they did a reading of 59.59 a very long time ago but decided that value was unlikely and kept 60hz for years instead.

Imho, let's tag @p1pkin about this, he might be interested by your readings and could explain how the current mame value of 59.826105 was measured.

[p1pkin]

@barbudreadmon

explain how the current mame value of 59.826105 was measured.

you may look at CRTC registers docs https://github.com/mamedev/mame/blob/master/src/mame/drivers/cps3.cpp#L535 especially this part: (*) H Total value is same for all 15KHz modes, uses fixed clock (not affected by pixel clock modifier) - 42.954545MHz/6 (similar to SSV) /(454+1) = 15734.25Hz /(262+1) = 59.826Hz pixel clock and line rate was measured using precise logic analyzer device, so I'm pretty sure they are accurate. but sadly, used LA device was not able to sample full frame, so I'm not 100% sure in line count. in theory, actual VTotal value might be not +1 but +2, which will give us 15734.25Hz /(262+2) = 59.599Hz at this point we need someone with some trusteable device (oscilloscope, freq.metter, logic analyzer, etc) and CPS-3 PCB who can do precise measurements for us.

as of actual game speed - it may be affected by many factors, such as SH-2 CPU speed, various DMAs speed, sprite PPU (blitter?) speed. and nothing of this is even near to cycle-exact emulation -> gameplay recorded from real PCB expected to be slower here and where, if compared to emulation...

[p1pkin]

on a side note - it not worth to compare CPS1/2 with CPS3, because CPS3's GPUs seems was designed by 3rd party, and they have nothing in common with CPS1/2. in general, CPS3 clearly smells like Seta-made hardware.

[fabricioanciaes]

@p1pkin Makes sense, I thought it was a design choice.

For the next step, we need someone with the required equipment to measure the precise refresh rate. Any idea on who could help with this?

[p1pkin]

no idea

[WydD]

I measured it using my cheap oscilloscope. Hsync is 15.732kHz Vsync is 59.582Hz (last digit may not be precise enough so 59.583 is possible)

Edit: forgot to say that it is 3rd strike running on standard resolution.

[WydD]

Me again. By changing the scale I can get 59.594Hz so I definitely wouldnt trust my measure down to the last digit. If someone has something that is able to get more precise answer please confirm.

[p1pkin]

@WydD thanks, last result pretty close to expected value - OSC/6/(454+1)/(262+2) ~59.59949Hz

but I'm still a bit confused why OSSC says CPS3 video is 265p and 59.37Hz, perhaps buggy firmware/calculation ?

[fabricioanciaes]

but I'm still a bit confused why OSSC says CPS3 video is 265p and 59.37Hz, perhaps buggy firmware/calculation ?

Maybe its worth taking a look at the CPSHDMI newest revision that supports CPS3 for answers. I Unfortunately cant contact the OSSC Creator on twitter because I don't know his twitter handle.

[WydD]

He doesnt have a twitter. But his work on CPSHDMI for CPS3 is public. The source is here https://github.com/marqs85/cps2_digiav/tree/cps3 (it shows 59.60Hz actually).

[fabricioanciaes]

He doesnt have a twitter. But his work on CPSHDMI for CPS3 is public. The source is here https://github.com/marqs85/cps2_digiav/tree/cps3 (it shows 59.60Hz actually).

This matches the OSSC measure, why though?

[barbudreadmon]

So, is everyone ok with the 59.59949 value ?

[dinkc64]

sure

[fabricioanciaes]

So, is everyone ok with the 59.59949 value ?

Looks fine, makes sense, its close to real hardware. Has some information backing it.

[fabricioanciaes]

Also, should this be on standalone FBNeo too?

[dinkc64]

of course!

[barbudreadmon]

https://github.com/finalburnneo/FBNeo/commit/c88310fed474d1c9ec91fe1a131f67d3ef6c2241 I'll close !