Help requested - GM & ArcadeOSD unable to bring up a 240p picture

[buttersoft]

Hi all, I've been porting my emulators over to a Win10 build, and finally got around to the install and set up crt_emudriver and VMM. I'm using GM 0.170 as i've never updated, just dropped the working GM folder over to the Win10 build. I was using crt_emudriver 2.0 beta 8, now using crt_emudriver 2.0 beta 10 non-GCM, so i can have the interlaced filter. I grabbed my previously-used monitor.ini and user_modes.ini file and copied them across to the Win10 build. Using the same HD 6870 gpu in both cases, of course. Test mode is on for Win10 (I can see the watermark.)

The generated modes don't seem to work right in ArcadeOSD. 640x480@60i and 800x600@50i come up fine. As does 2560x480i. Nothing non-interlaced does, however - anything 240p, basically, though 2560x262p will eventually come up - in that ArcadeOSD doesn't bring up the coloured background or actually switch to that res *until* i tell it to set that mode to desktop. Once it fails to go to a mode (colour screen) it won't go to one again even for a fully working res. Until l restart ArcadeOSD, where everything starts again.

GM just generates garbage on the screen for any 240p game. GM log attached, along with mamei.ini (as mame.txt).

I have a strong feeling I've had this issue before, but i can't remember what i did to fix it

Does using my custom monitor preset affect the EDID emulation? Am i having some sort of issue interlace patcher can fix? Wtf are the lines in the log with +hsync +vsync in them for?

As usual, any help greatly appreciated

(i was also getting the vertically compressed screen issue, but disabling fast startup has fixed that, thanks calamity )

[Calamity]

Using a custom preset does not affect EDID emulation. Leaving apart ArcadeOSD, the polarity issue sounds like a version mismatch. Please test newest GM version, and the latest tools (even if using older driver for the filter). Besides, double check W10 has not overwirtten the Emudriver (check the signature of atikmdag.sys)

[buttersoft]

I will try all that and see what happens, thank you. Given the modes actually work, but ArcadeOSD is having trouble somehow, it does feel like a permissions issue. Like something else has control and doesn't let go properly.

I think the issue i was having before was this one - http://forum.arcadecontrols.com/index.php/topic,151623.msg1586319.html#msg1586319. I'm fairly certain that to fix it i stopped using cloned displays and built myself the switch-boxes i'm using now. Which might indicate it's a compatibility issue here as well.

[Calamity]

Are you using cloned displays?

[buttersoft]

No cloned displays this time, i was merely wondering about similar behaviour.

You were right about the mismatch tho, you're always right I can either use crt_emudriver beta 8 and GM 0.170  (or GM 0.194, in fact) or update to crt_emudriver beta 10 and GM 0.194. 90% of my selected romsets fail in 0.194 tho, i'll do a full upgrade later. I used the tools from beta 10 in the first case, and the tools from beta 12 in the second.

Oddly enough, no combination of the above drivers or tools (or tools from beta 8 ) fixes the issue with ArcadeOSD. Unless i failed to try beta 8 driver and beta 12 tools, can't remember.

[Calamity]

Then probably it's just that Arcade OSD is broken, finally. It's based on DirectDraw and Windows has been breaking it step by step since 7. I've been willing to update it to Direct3D for a long time.

[buttersoft]

Possibly a related question. I note that newer crt_emudriver builds (those with c-sync?) install CCC along with the driver. Unless windows is grabbing CCC by itself? I turned it off on my cabs, where system resources are at a premium. Would this have had any negative effect?

[Calamity]

Possibly a related question. I note that newer crt_emudriver builds (those with c-sync?) install CCC along with the driver. Unless windows is grabbing CCC by itself? I turned it off on my cabs, where system resources are at a premium. Would this have had any negative effect?

CCC is not in the CRT Emudriver package, so Windows must be grabbing it by itself, that's funny. I wouldn't say it has a negative effect apart from delaying system startup a little bit (CCC is built on .NET with the correspoding overhead).

[buttersoft]

Hmmm, does CCC itself allow use of c-sync on newer cards? Not that i expect you to know the answer, just spitballing

[Calamity]

It used to allow it, now the setting has been removed from recent versions (I believe since the Crimson release or so). VMMaker allows it using the same registry settings that CCC used (unfortunately the setting is broken in beta 12, I'll release beta 13 soon with the fix).