CRTEmuDriver for Windows 7 test results

[retrorepair]

The thing that ended up working, was an archive i have here called switchres.zip
Inside there's 3 files..
640x288.exe (i think)
640x480.exe
800x600.exe

Thanks a lot Sledge!

Those files are from Ultimarc indeed, they can be downloaded here: http://www.ultimarc.com/Switchres.zip

@retrorepair, before you test with the files pointed by Sledge, please check the new Arcade_OSD I've attached to this thread. Once you select a mode, there's a new option named "Set as default display mode", you need to select it and then make sure to select "Keep" before exiting the program*. I'm using a different method now to set the desktop mode just like the above programs do, hopefully now the modes stick.

*if for some reason you loose the program window upon mode switch, pressing "2" should bring it back.

Thanks Calamity, though it still won't stick  I set as desktop mode AND set as default display mode. Reset the machine and.. 1024x768 

I'm actually not sure those Ultimarc packages will work either since although they may force 640x480, I do wonder if it will be interlaced or progressive. I will try it now anyway.

[retrorepair]

I ran 640x480 while the LCD was connected, it goes out of sync, i switch to arcade, so far so good... shut down, restart,  GOLD! machine boots at 640x480 and it sticks..
Not sure where i got the files from originally, i can't find them now.. but i DO have them here...
There's another util called quickres (sits in taskbar and allows you to choose any of your supported resolutions by the looks), which COULD do the same thing, but i haven't tried..

So I tried it but as expected, when I ran it on the LCD all I got was 640x480 progressive. Even if it sticks it's not interlaced so it won't sync on my 15khz arcade monitor.

 

*EDIT* I restarted and yep, stuck with 640x480 but progressive so still won't sync on the arcade monitor.

[retrorepair]

Just a thought, would changing the monitor type in Windows help with this? http://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff568432(v=vs.85).aspx

It's clear that since the monitor isn't providing EDID info then windows is freaking out and defaulting to what it considers a standard safe resolution. An EDID override as described in your first link would be the answer, I just don't know how to do it or what to include in it.

[retrorepair]

Should I try adding the resistors to the RGB lines? Will that help? I'm running a JPac if that helps.

No sure it would help. I'd be an interesting experiment anyway. I'm assuming you're using the same output as in XP don't you?

Well guess what? With 75ohm resistors on each R, G and B line tied to ground it syncs in 640x480, 15khz every time connected to the arcade monitor! EVERY time!!

It does of course reduce the brightness quite a bit so it's not ideal. I guess it does prove it absolutely needs EDID info if this is what the resistors are supposed to circumvent.

I'd hate to see what it would look like without the RGB amplifier built into the J-PAC 

The other problem I am having of course is the issue with MAME and resolutions/refresh rates. Right now I have a ton of resolutions available but all are 60p so none of the refresh rates in MAME are correct. Your suggestion of the "super" resolutions only gave me a handfull of interlaced modes, no progressive modes or accurate refresh rates.

[Calamity]

Well guess what? With 75ohm resistors on each R, G and B line tied to ground it syncs in 640x480, 15khz every time connected to the arcade monitor! EVERY time!!

That's very good news! At least we now know it's a problem related to monitor detection. I think I already asked but do the other output have the same problem?

I guess it does prove it absolutely needs EDID info if this is what the resistors are supposed to circumvent.

Not at all. It does prove it is related to monitor detection. EDID info is a separate thing and not required at all as you're seeing. I do know this because I have a Soft-15kHz EDID dongle and it doesn't help when it comes to monitor detection.

The other problem I am having of course is the issue with MAME and resolutions/refresh rates. Right now I have a ton of resolutions available but all are 60p so none of the refresh rates in MAME are correct. Your suggestion of the "super" resolutions only gave me a handfull of interlaced modes, no progressive modes or accurate refresh rates.

Aren't you using GroovyMAME? Those modes are supposed to be used with it. GroovyMAME will recalculate the required refresh on the fly, you'll have the right refresh for all games. On the other hand the "super" resolutions just work, do check the modelines list to see what it's doing.

Now, in case you wanted to test any further: before you put the resistors, the issue seems to be (as it was in Sledge's case) that the system can't see the interlaced modes on boot (because your monitor is not detected and the system thinks they're not safe), so setting for instance 640x480@60i will be automatically reverted to 1024x768*. But I'd say that if you tried to set a 15 kHz progressive mode like 640x240 (or whatever other that you have but not a 31 kHz one!) with the new option "set as default display mode" maybe it would stick (in case it's working as it is supposed).

*1024x768 is the default resolution in W7. However you can force W7 to use a lower resolution by default. From an elevated cmd, run "bcdedit /set vga on" and reboot. At least this might force the system to fall back to a mode that is readable throught the j-pac.

BTW the EDID overrides wouldn't help here either (I might be wrong, if so let me know). The problem happens deep inside the display driver when it doesn't detect that a monitor is connected. The EDID override wouldn't be considered in this situation.

[retrorepair]

I think I already asked but do the other output have the same problem?

I have not checked but I will. I don't think it will display the desktop on the second output though?

It does prove it is related to monitor detection. EDID info is a separate thing and not required at all as you're seeing. I do know this because I have a Soft-15kHz EDID dongle and it doesn't help when it comes to monitor detection.

Yes I've been reading up, apparently it just bumps up the current draw so the card knows there is a monitor there. I guess since I am already drawing current I need to work out what value is actually required. This way I should be able to keep most of my brightness and extend the life of my gfx card.

Aren't you using GroovyMAME? Those modes are supposed to be used with it. GroovyMAME will recalculate the required refresh on the fly, you'll have the right refresh for all games. On the other hand the "super" resolutions just work, do check the modelines list to see what it's doing.

I did this as I did last time (in fact it's the very same VMMaker.ini) and now it's only finding 3 modes despite me making sure I copied your list exactly. When I run GroovyMAME now it tells me it can't open the registry entry, 2560x0 is not available and it couldn't find a mode to match my specs.

Now, in case you wanted to test any further: before you put the resistors, the issue seems to be (as it was in Sledge's case) that the system can't see the interlaced modes on boot (because your monitor is not detected and the system thinks they're not safe), so setting for instance 640x480@60i will be automatically reverted to 1024x768*. But I'd say that if you tried to set a 15 kHz progressive mode like 640x240 (or whatever other that you have but not a 31 kHz one!) with the new option "set as default display mode" maybe it would stick (in case it's working as it is supposed).

I can try that, sure.

[Calamity]

I did this as I did last time (in fact it's the very same VMMaker.ini) and now it's only finding 3 modes despite me making sure I copied your list exactly.

Use the attached file.

When I run GroovyMAME now it tells me it can't open the registry entry, 2560x0 is not available and it couldn't find a mode to match my specs.

You need to launch GM with ADMIN RIGHTS, it's the only way it can access the registry and to its stuff with the refresh rates.

[cools]

Are the duplicated lines in the file critical? I'll try a max resolution tomorrow, that makes sense although should the mode exist but crash rather than not exist at all?

[retrorepair]

Thanks for the file, it found 31 modes this time! I guess because the file was created on a Mac, it didn't like the formatting? Looked identical to me but obviously not!

So it looks like it's all working now! 

I will tell you guys right now as well, a bit of testing with mmpork's attract mode on both xp x64 and W7 x64, W7 is MUCH faster, I'd say a good 20% or more! Guess all this work is well worth it.

I'll do some more testing on some games I know can be a bit funny but I have high hopes 

Will let you know about setting the desktop to a progressive mode too. I guess it won't be practical but could lead to an answer. I can tell you before though when the desktop decided to default to 320x240, a reboot went back to 1024x768, though I guess I didn't set it again so I will try it out.

Thanks for all the help Calamity and everyone else, hopefully this will aid in making GroovyMAME even better 

[Sledge]

Some more messing about - I cannot get super resolutions to work whatsoever.

The only thing I can think off is that we're stumbling on a max dotclock value. May you try replacing the 2560x values by 1280x?

Except that if we are both using the same card.. HD4850.. that shouldn't be an issue...
What brand is yours Retro? Mine's Saphire..

That's very good news! At least we now know it's a problem related to monitor detection. I think I already asked but do the other output have the same problem?

But mine doesn't supply an EDID either...

[cools]

4350 here

[retrorepair]

I'm not sure cools is using a HD3850. In terms of dot clocks though, I have always found with this card that 8.5 is the best minimum to work with. Just remember to set it in mame.ini and VMMaker.ini

Not sure what make it is, it's this one here: http://www.ebay.co.uk/itm/ATi-Radeon-HD-4850-1GB-DVI-x2-TV-out-PCIe-gaming-graphics-card-CLEAN-amp-TESTED-/141313972643?ssPageName=STRK%3AMEWNX%3AIT&_trksid=p2047675.l2557&nma=true&si=kcOdkLEaZvTnfabjUz2hK8JtItY%253D&orig_cvip=true&rt=nc

BTW, I'm also suffering from green videos in hyperspin.

[Calamity]

Are the duplicated lines in the file critical? I'll try a max resolution tomorrow, that makes sense although should the mode exist but crash rather than not exist at all?

Not sure what you mean by duplicated lines...
Regarding the max dotclock, the modes could be discarded by the driver in the first place by checking against the max-min ranges taken from your video card bios.

[Sledge]

I'm not sure cools is using a HD3850. In terms of dot clocks though, I have always found with this card that 8.5 is the best minimum to work with. Just remember to set it in mame.ini and VMMaker.ini

Not sure what make it is, it's this one here: http://www.ebay.co.uk/itm/ATi-Radeon-HD-4850-1GB-DVI-x2-TV-out-PCIe-gaming-graphics-card-CLEAN-amp-TESTED-/141313972643?ssPageName=STRK%3AMEWNX%3AIT&_trksid=p2047675.l2557&nma=true&si=kcOdkLEaZvTnfabjUz2hK8JtItY%253D&orig_cvip=true&rt=nc

BTW, I'm also suffering from green videos in hyperspin.

That looks the same as mine..

re: green screen.. did you disable hardware acceleration through youtube vids? (firefox needed)

[Calamity]

Regarding the resistors, hopefully someone made something like this:

http://rumorscity.com/2013/12/06/how-to-create-dummy-plugs-for-your-graphics-cards/

... but that worked as a passthrough connector. It could be even cooler if it was integrated in a DVI-VGA connector.

[retrorepair]

It'd be easy to do, it's just a shame this needs extra hardware really.

Calamity, what are the specs of VGA and your typical arcade monitor? In terms of milliamps and volts?

[Calamity]

I was struggling with the green videos issue last week. It turns out it is HDCP, digital content protection stuff. These guys are having the same problem: http://www.monitortests.com/forum/Thread-AMD-ATI-Pixel-Clock-Patcher

Once you modify a single byte in the driver .sys, it disables DXVA. I guess this is by design, to make it hard to crack the driver to copy movies etc. Flash uses DXVA by default, so you must disable hardware acceleration through Firefox. Fortunately there are workarounds for most video acceleration issues derived from this. I was afraid the driver was intrinsically damaged due to the patches so games might suffer from this but it looks like it's just a "feature" after all.

[Calamity]

It'd be easy to do, it's just a shame this needs extra hardware really.

Calamity, what are the specs of VGA and your typical arcade monitor? In terms of milliamps and volts?

No idea, the only reference I've seen is this one (scroll down for the "If your PC does not sense your monitor" bit): http://www.geocities.ws/podernixie/htpc/cables-en.html

[cools]

Are the duplicated lines in the file critical? I'll try a max resolution tomorrow, that makes sense although should the mode exist but crash rather than not exist at all?

Not sure what you mean by duplicated lines...
Regarding the max dotclock, the modes could be discarded by the driver in the first place by checking against the max-min ranges taken from your video card bios.

480 and 496 are repeated in the file.

So vmmaker doesn't just insert mode lines into the registry, it actually calls the driver to add them, and records the results in modeline.txt?

Should have time to play some more tonight, I'll try with not so super resolutions

[cyb]

I have successfully installed the driver but I have not ran vmmaker or hooked up my crt yet.

I'll be using a sony PVM. In regards to resilist.txt:

Code: [Select]

640 x 480 @ 60.000000 desktop
do I need to change the refresh to 30 or leave it as is?

also, for the super resolutions. this one for example:

Code: [Select]

2560 x 240 @ 60.000000 superDo I need to change the h-res to 1280 or leave it at 2560?

I wasn't totally sure if these resolutions were only meant to be used on a 31k capable monitor or not...

My current setup is a little strange, I'm running two different video cards. My main card is a gtx 750ti and I also have the hd4350 installed for crt emudriver. I hope everything will play nice together. I will report back with my findings.

[Calamity]

Code: [Select]

640 x 480 @ 60.000000 desktopdo I need to change the refresh to 30 or leave it as is?

Not necessarily. Depending on the monitor preset you choose, that one will be done as 60i or 60p.

also, for the super resolutions. this one for example:

Code: [Select]

2560 x 240 @ 60.000000 superDo I need to change the h-res to 1280 or leave it at 2560?

You shouldn't need to do that for low vertical resolutions. Maybe the issue reported by Cools has to do with a combination of his using of high vertical resolutions (31 kHZ) with superwide modes and his particular card's BIOS. I never had an issue with superwide modes.

I wasn't totally sure if these resolutions were only meant to be used on a 31k capable monitor or not...

That list was meant to be monitor independent, then depending on the preset you choose some modes will actually be calculated and some will just produce a virtualized mode. With some testing you can trim that list so that only the actual super resolutions you need are created.

My current setup is a little strange, I'm running two different video cards. My main card is a gtx 750ti and I also have the hd4350 installed for crt emudriver. I hope everything will play nice together. I will report back with my findings.

Then make sure to edit vmmaker.ini to point to the right \\.\DISPLAY, use ArcadeOSD or the MAME log or whatever method to find out what \\.\DISPLAY# your hd4350 is mapped to, e.g. \\.\DISPLAY1, \\.\DISPLAY5, etc.

[Calamity]

480 and 496 are repeated in the file.

Ok I see it now My mistake.

So vmmaker doesn't just insert mode lines into the registry, it actually calls the driver to add them, and records the results in modeline.txt?

No, it only inserts the modelines into the registry, so it is possible that a modeline appears in modeline.txt but later during boot the driver simply rejects it.

[cools]

Gotcha. Okay, I'll try with both 15khz and 31khz and see what I find. I do see some very high resolutions in ArcadeOSD if I show unsupported modes, but I guess those are the ones baked into the driver.

I'm still very happy with how it works with method 1 though, I've got 120 modes in the registry and the only slowness is a 6 seconds freeze when Windows goes from the "Welcome" screen to the shell.

[cools]

Super resolutions using the standard 15KHz VMMaker monitor_preset line and the posted ReslList.txt work fine, as does Groovy. I also get these weird entries added that appear from nowhere:

Code: [Select]

Modeline "664x496_59 15.91KHz 59.04Hz" 13.860 664 696 760 872 496 499 504 539 interlace -hsync -vsync
Modeline "664x496_60 16.18KHz 60.06Hz" 14.090 664 696 760 872 496 499 504 539 interlace -hsync -vsync
Modeline "728x544_54 15.85KHz 54.02Hz" 15.110 728 760 832 952 544 547 552 587 interlace -hsync -vsync
Off to try some higher resolution stuff...

[Calamity]

Super resolutions using the standard 15KHz VMMaker monitor_preset line and the posted ReslList.txt work fine, as does Groovy. I also get these weird entries added that appear from nowhere:

Those are modes that couldn't be calculated through the current monitor_preset for being out of range and because of this are virtualized. Check the Modelist.txt file for details regarding the original mode.

[cools]

Aha, okay I see them. Would I be right in assuming I want to avoid those wherever possible and put modes in that do work?

Anyway, I'm done testing. You were correct regarding the dot clock maximum. Any time a resolution requires a dotclock > 100, it's rejected by the driver even though it appears in the ModeLine.txt. 2560 in 31KHz is a failure. It's just over the tipping point.

I think I'll stick with my 120 modes 31KHz setup. I temporarily set the monitor to arcade_15_25_31 for testing (with associated monitor_specs lines) and cringed whenever it resynced. I don't fully grasp how many modes should be in ReslList.txt for super modes to be effective with all the different refresh rates available in MAME, and the little freeze when Windows loads isn't in any way a problem.

[Calamity]

Anyway, I'm done testing. You were correct regarding the dot clock maximum. Any time a resolution requires a dotclock > 100, it's rejected by the driver even though it appears in the ModeLine.txt. 2560 in 31KHz is a failure. It's just over the tipping point.

Aah, yes... I forgot to fix this in VMMaker! It's just a problem with the dotclock value overflowing when it's higher than 100, but it's a problem with VMMaker, not the driver. I had already fixed this in the most recent versions of GroovyMAME, but still hadn't in VMMaker. Thanks for reporting this, I'll fix it as soon as possible. In the meanwhile if you want to use super resolutions, use Winmodelines to add the modes, just use the list generated by VMMaker in Modelines.txt and simply paste it inside the Winmodelines text box.

[cools]

  I'm happy enough for now. Just discovered that VMMaker uses both the XML AND the ReslList.txt at the same time, so by emptying the latter (except for my desktop 688x512@57 resolution, which is the largest 4:3 progressive mode my monitor can handle. It also centres and sizes 512p at the same as 480p, which is nice) I've got the list of modes down to 76 and the boot freeze is under 2 seconds.

[cyb]

I have successfully run vmmaker with the super resolutions. Groovymame is working well with the super resolutions when the PVM is plugged in by itself. It doesn't seem to play nice when I have other displays attached, either to the HDMI of my 4350 or my other video card. I dont really consider that a problem because I'm just using my pc as a test system. I will be configuring a separate computer for exclusive crt emudriver usage.

A few issues I've noticed so far:

Mortal Kombat 2 will not sync for me. log attached.

Street Fighter Alpha 3 has slight tearing in the scrolling player select graphic on the top of the screen when using d3d and frame delay. When using ddraw the tearing is gone but there is a slight stutter in the scrolling. I've attached the logs.

So far I don't think I want to go back to xp 64. You rock calamity! donation heading your way.

[Calamity]

Hi cyb,

First of all, make sure you run GM with ADMIN RIGHTS, otherwise it won't be able to access the Windows registry in order to use the required refresh rates.

Mortal Kombat may just be using a refresh (54 Hz) that is off in relation to your current monitor vfreq adjustment.

Regarding the tearing with frame delay & d3d, yes it does exist with high resolutions (although I haven't seen it yet at 240p). In order to use ddraw, maybe a value of 9 for frame_delay is too high, bear in mind ddraw is slower at scaling than d3d.

[juice84]

Sorry if this has been asked before elsewhere in these forums... I am having trouble getting this to work with my current setup.  Trying to get this setup for use with my New Astro City/MS29.  I have a radeon 4870 and fresh install of w7 x64, the drivers install fine and I'm now in test mode.   Ran VMMaker and initially ArcadeOSD let me switch to 320x240 but upon reboot my resolution goes back to 1920x1080, and none of the low resolutions are selectable in ArcadeOSD anymore.  Am I missing something for the install?, noticed it says update registry disabled.  Again sorry, I'm really new to the Arcade scene.  Thanks Calamity for all of your work on these drivers.

[cyb]

Hi cyb,

First of all, make sure you run GM with ADMIN RIGHTS, otherwise it won't be able to access the Windows registry in order to use the required refresh rates.

Mortal Kombat may just be using a refresh (54 Hz) that is off in relation to your current monitor vfreq adjustment.

Regarding the tearing with frame delay & d3d, yes it does exist with high resolutions (although I haven't seen it yet at 240p). In order to use ddraw, maybe a value of 9 for frame_delay is too high, bear in mind ddraw is slower at scaling than d3d.

Hi Calamity,

I totally forgot about running groovymame as admin. Thanks for the reminder! That solved my MK2 sync issue.
Changing frame_delay to 1 solved the tearing in SFA3 in d3d and the stuttering in ddraw. Is d3d preferable over ddraw in w7? I didn't really notice any input lag differences between the two.

Also, should I disable Aero?

[Calamity]

Hi juice84, set AnyCatalyst=1 in vmmaker.ini and remind running vmmaker with admin rights.

[juice84]

Hey Calamity, thanks for the reply.  Just read your post in regards to step 4.7 as well which I think I may have been the issue.  I'll give it another shot when I get home tonight, think everything should work though.  Thanks again

[retrorepair]

Just a quick one, now that the modes are all working properly, some games won't show the MAME config menu properly. It will come up but will be totally blank. I've noticed this so far with DoDonPachi Dai Fukkatsu and the other SH3 cave games, so I'd guess any game that runs in 320x240.

I'll take a look at other games tonight.

[cools]

Having some problems with D3D and frame_delay in CPS1 games that didn't happen with XP. Running them without frame_delay or running with DDRAW is fine, but with the combination games accelerate and decelerate randomly.

[Calamity]

Just a quick one, now that the modes are all working properly, some games won't show the MAME config menu properly. It will come up but will be totally blank. I've noticed this so far with DoDonPachi Dai Fukkatsu and the other SH3 cave games, so I'd guess any game that runs in 320x240.

I'll take a look at other games tonight.

Hi Retrorepair,

Thanks for reporting. Yes, I'm aware of this, and some stretching issues with the menus too, due to the weird aspect ratio caused by super resolutions. I'll focus on this and other issues for the next release.

[Calamity]

Having some problems with D3D and frame_delay in CPS1 games that didn't happen with XP. Running them without frame_delay or running with DDRAW is fine, but with the combination games accelerate and decelerate randomly.

Hi cools, this could actually be caused by enabling -frame_delay with a too low number. If a certain driver can be emulated very fast by MAME on your CPU, if you set -frame_delay too low a second or subsequent re-entry in the same vertical retrace period is possible. This will increase speed by 2 or just erratically. Check again by increasing -frame_delay a bit.

[cools]

Righto, I'll try bumping it up a bit.

[juice84]

Thanks again Calamity, everything is now working great.  Just a quick question, is there a way to make groovymame autofill the screen so there is no black borders on certain/most games?