Issue with selection of 15khz mode for CRT use

[z00p]

I'm using the RetroArch CRT EmuDriver options on a Sony multi-sync monitor. Getting px68k to display 15khz (240p) mode is hit and miss. Currently (with Dx10 or Dx11 driver + CRT enabled) X68k will start in 720p mode for the X68000 boot and in game. To get into 240p mode I need to switch into the px68k menu using F12, then when I go back from the menu into the game it switches to correct resolution (240p) and looks amazing.

[gingerbeardman]

Switching in and out of F12 is enough? You don't do anything whilst in there?

[z00p]

Right. The process of going in and out of the PK68k menu switches the video from from 720p (set when the emulator starts) to 240p (480i).

Sent from my iPhone

On 16 Sep 2018, at 21:26, Matt Sephton notifications@github.com wrote:

Switching in and out of F12 is enough? You don't do anything whilst in there?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gingerbeardman]

Something must not be getting initialised correctly. I'll try to take a look this week.

[ghost]

menu is 800x600, dos prompt mostly triggers @ 768x512. some games are 256x256 or x2 of that with others at 768x512.

im revamping the core (for personal use, i hate this ever changing screensize and a compromise of fixed 800x600 window geometry works for me best-letterbox or borders does not bother me if its main screen is big enough, frames are still rendered natively)

how does the crt-driver work with height larger than 256? and does it need to be equal or less than that.

[negativeExponent]

i hope i had a CRT and a way to connect to it. anyways does using core overrides and running core at a fixed frame helps in any way?

[Tatsuya79]

I was wondering about the screen ratio when switching video mode, which is a bit related to that. I could see some examples on real machine where it goes like what would maybe be 1:1 in retroarch.

In Racing Champ: https://youtu.be/cSPK2hnVyOE?t=86 By the way, that game runs a lot better on px68k than with xm6 type-g. Still has a bit too many black artifacts?

Or games like Cameltry: https://youtu.be/QdEwjLT2sB8?t=2517 Even 3:4 or 9:16 looks better in game.

[negativeExponent]

is this late resolution switching still an issue on latest commit? is it reproduceable without this CRTRes thing? maybe forcing CHANGEAV = 1 at start will remedy this?

[riggles1]

@negativeExponent I'm not entirely sure. It does perfectly select the 2560 superres 256p55Hz mode with CRTSwitchres (needs a CRT capable of 55Hz vertical sync and geometry adjustments to display all 256 lines of graphics properly).

But selecting other modes within games that support them doesn't seem to work, for example the 240p mode (60Hz) in Cotton, or the 15-25-31kHz selections in Keeper, which is an oddball game that displays 240p60 instead of 256p55.

I just ended up turning off auto CRTSwitchres (INI>OFF) and forcing the required mode manually, saving the config for the specific game.

But ultimately someone that has all 15-25-31kHz modelines should chime in. I'm just able to do 256p 55Hz and other 15kHz total scanning frequency modes (caps out at 16.2kHz or so).

[Tatsuya79]

I'm noticing a sync issue I'm having. I use gsync with "sync to exact content framerate" but when I'm starting a game, like chourensha here, I'm at 61.45Hz already while booting, and still at that speed in game.

I have the "adjust frame rates" core option disabled as I want the original machine refresh. If I enable it and then disable it, it stays at 55.45Hz then.

Did something change in the core regarding that? I tried a 2 years old version of retroarch and it acts the same. I think it was working before.

Also in Chourensha screen 0x0002 should switch to 61.45 but it stays at 55.45 ("adjust frame rates" on or off).

int VID_MODE = MODE_NORM; / what framerate we start in / Shouldn't this be MODE_HIGH to start at 55.45Hz?

edit: @negativeExponent all that is working fine on your core from your repo, don't know what went wrong here.

[negativeExponent]

yeah, this is indeed int VID_MODE = MODE_HIGH; / what framerate we start in / in my port. if it works fine this way in your end, then lets just make this as default then.

edit: huh, i may have remove a VID_MODE check when i was refactoring crtc in recent commit. lemme restore it if it fixes it.

update: see latest commit if it fixes it.

[Tatsuya79]

Great, that fixes it. 👍

I'm still noticing a case where the timing is wrong: when you load a save state made at a different refresh than the default.

Like you go screen mode 2 in chourensha for 61.45hz, do a save state: when you'll restart the game later and load it you'll end up at 55.45hz with a slowed down game.

[negativeExponent]

can you add SFVAR(VID_MODE), to crtc StateRegs and see if this helps?

nevermind. adding timing change will make runahead go bunkers

@Tatsuya79 see if this PR helps https://github.com/libretro/px68k-libretro/tree/fix_framerate_on_loadstate

[Tatsuya79]

This is working. 👍 Run ahead seems to be performing the same comparing before/after.