DirectDraw interlace screenmode switching on Win 7

[Dr.Venom]

Carrying on from our discussion in the other thread (http://forum.arcadecontrols.com/index.php/topic,129025.msg1326033.html#new), about mainline MAME / GM not being able to switch from/to interlace screens with DirectDraw on Windows 7.

I've been having a look at WinUAE's source, and at first sight I can't see he's doing anything special for setting up DDraw, if you know something about any change that was required in order to allow progressive/interlaced mode switching under W7 please point me in the right direction.

I've been trying to recall some of the stuff related to the problem, they are I guess only pieces of the puzzle and some might be appropriate for D3D only, but here goes:

- A flag needs to be set that says screenmode is interlaced when enumerating modes. I.e. "i" after resolution string.

- D3DSCANLINEORDERING enumeration needs to set D3DSCANLINEORDERING_INTERLACED properly as documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb172604%28v=vs.85%29.aspx. Note that this enumeration is available in Direct3D 9Ex only.

Code: [Select]

D3DSCANLINEORDERING_INTERLACED
The image is created using the interlaced method in which odd-numbered lines are drawn on odd-numbered passes and even lines are drawn on even-numbered passes.

- Syncing odd and even fields between source and output. When D3DSCANLINEORDERING_INTERLACED is set, frames with the uneven lines (odd field) and frames with even lines (even field) are alternating. So for a typical 60hz refresh (30Hz interlaced) there will be 30 odd fields and 30 even fields alternating, having a total of 60 "progressive" fields per second. To be able to match source and output odd and even fields, one needs to know whether the output (monitor) is currently displaying the even or odd field. Use the D3DRASTER_STATUS structure (http://msdn.microsoft.com/en-us/library/windows/desktop/bb172596%28v=vs.85%29.aspx) to get the actual scanline status. If the field is even it will report: ... <vblank>46 48 .. 616 618 <vblank>, if the field is odd it will report <vblank>47 49.. 617 619 <vblank> ..., thus knowing whether the next field will be odd or even.

- For some screenmodes (like 640x480) both 30Hz interlaced and 59Hz and 60Hz progressive may be available. Calling it with the "default" refresh rate may result in unpredictable behaviour, because default refresh may not match with the interlace/progressive screenmode flag. Thus preferably interlaced screens are opened while explicitly specifying the target refresh rate, e.g. "30i".

I'm not sure if it would help re looking at the WinUAE source code (not sure if it is possible to look at revision), but in any case the changes for interlace seem to have been around the time of winuae_2400b15:

Beta 15:
- Append "i" to PC resolutions that are interlaced. (TV Out, VGA + Soft15Khz hacks etc..)
- Low latency Amiga interlace mode odd/even fields are now in sync with output's odd/even fields, if output resolution is also interlaced.

Not that it will be of much help I guess, but even in case there would be a tiny clue in it, as example (part of) the log of WinUAE's display mode enumeration looks like:

26: !640x480, 16-bit (!59,!60)
27: !640x480, 32-bit (!59,!60)
28: 640x496i, 16-bit (30i)
29: 640x496i, 32-bit (30i)
38: !720x480i, 16-bit (!29i,!30i,!59,!60)
39: !720x480i, 32-bit (!29i,!30i,!59,!60)
40: !720x576, 16-bit (!50)
41: !720x576, 32-bit (!50)
42: 744x287, 16-bit (50)
43: 744x287, 32-bit (50)
44: 744x574i, 16-bit (25i)
45: 744x574i, 32-bit (25i)

Where basicly the ones with the exclamation marks are system modes. As an example in the GUI the 744x574i mode has a refresh panel where it says "25Hz PAL (50i)" (see attached snapshot).

Hopefully in any the above there is some information/lead as to why DirectDraw interlace switching isn't working in MAME on Windows 7.

[Calamity]

Hi Dr.Venom,

Thanks for the information above. Before we go on, it would be of great help to know which exact DirectDraw function is failing. Unfortunately the log you passed me on the other thread of DDraw crashing on interlaced mode switching does not provide much information regarding this, that's a bit strange as the ddraw.c module is supposed to log errors. Anyway it would be good to get a new log with the -multithreading option disabled in order to get a more sequential result.

I've done a test build of Arcade_OSD with a debug window, hopefully it will tell us which function is failing. Please test an interlaced mode and check the window for errors.

[Dr.Venom]

I have recreated the log for the psj driver without multithreading (see attached). Upon attempt to switch to interlace it logs the following:

Code: [Select]

Video: Monitor 00010001 = "\\.\DISPLAY1" (primary)
Video: Monitor 00010003 = "\\.\DISPLAY7"
DirectDraw: Using DirectDraw 7
window_proc: WM_NCACTIVATE
blit_lock = TRUE
DirectDraw: Configuring device ATI Radeon HD 4800 Series
DirectDraw: Error 80004001 attempting to set video mode 648x484@58 call
window_proc: WM_NCACTIVATE
window_proc: WM_DESTROY
blit_lock = TRUE
Switchres: restoring DALDTMCRTBCD648x484x0x58 - Modeline "648x484_58 15.98KHz 59.95Hz" 13.55 648 680 744 848 484 487 492 533 interlace  -hsync -vsync
Unable to initialize DirectDraw.
  002827D8: 01C74115 (not found)
  002828D8: 01C71C88 (not found)
  00282A48: 01C6E70E (not found)
  00282BB8: 024D43F3 (not found)
  00282C68: 024D5467 (not found)
  0028F8B8: 0240B98B (not found)
  0028FB38: 02777258 (not found)
  0028FE88: 01C70490 (not found)
  00351708: 02A71C50 (not found)
  00351728: 00359FC0 (not found)
Unable to complete window creation
The arcade_osd_test_00 logs the following two lines when switching to interlace:

SetDisplayMode error
ActivateMode: DDrawInit error

Hope this helps. Let me know if I can test anything else..

[Calamity]

Interesting, both errors are on the SetDisplayMode function, that narrows it quite a lot. The error 80004001 means NOT IMPLEMENTED. That's rather strange.

Just to clarify, I guess Arcade_OSD is reporting the interlaced refresh rates as halved, does it? On the other hand GM is requesting the "full" refresh, as you had patched it for that.

This is interesting:

Switchres: [ 17]  648x 484 @ 58: DALDTMCRTBCD648x484x0x58 - Modeline "648x484_58 15.98KHz 59.95Hz" 13.55 648 680 744 848 484 487 492 533 interlace  -hsync -vsync
Switchres: [ 18]  648x 484 @ 60: system mode

What happens if you try the second one on Arcade_OSD?

[Dr.Venom]

Just to clarify, I guess Arcade_OSD is reporting the interlaced refresh rates as halved, does it?

Yes it reports them as halved, see attached picture.

On the other hand GM is requesting the "full" refresh, as you had patched it for that.

Yes, indeed.

This is interesting:

Switchres: [ 17]  648x 484 @ 58: DALDTMCRTBCD648x484x0x58 - Modeline "648x484_58 15.98KHz 59.95Hz" 13.55 648 680 744 848 484 487 492 533 interlace  -hsync -vsync
Switchres: [ 18]  648x 484 @ 60: system mode

What happens if you try the second one on Arcade_OSD?

Well Arcade_OSD doesn't show any 648x484 @ 60, but it does show 648x484@30 (see attached picture again). If I select the @30 then it results in the same two lines be logged as before.

Just to be sure, both 648x484i modes are opened correctly when called by WinUAE in DDraw mode.
 

[Dr.Venom]

I'm thinking maybe it needs a specific Vista and later enumeration of modes? This is provided by DXGI and there's specific mention of listing interlaced modes:

DXGI Overview: http://msdn.microsoft.com/en-us/library/windows/desktop/hh404534%28v=vs.85%29.aspx

"The first Microsoft Direct3D runtime version to use DXGI is Microsoft Direct3D 10. Windows Vista and later client operating systems support Direct3D 10 and later. Windows Server 2008 and later server operating systems support Microsoft Direct3D 10.1 and later."

IDXGIOutput::GetDisplayModeList method: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174549%28v=vs.85%29.aspx
mentions a specific option to include interlaced modes (DXGI_ENUM_MODES_INTERLACED;).

Shot in the dark, but maybe the information is valuable in some way.

[Dr.Venom]

A shot in brighter daylight, maybe?

In the ChangeDisplaySettingsEx function (Windows) documentation http://msdn.microsoft.com/en-us/library/windows/desktop/dd183413%28v=vs.85%29.aspx it says you can use any of the following members of the DEVMODE structure:

Member                      Meaning
dmBitsPerPel               Bits per pixel
dmPelsWidth               Pixel width
dmPelsHeight              Pixel height
dmDisplayFlags               Mode flags
dmDisplayFrequency     Mode frequency
dmPosition                  Position of the device in a multi-monitor configuration.

Looking up the possible flags for dmDisplayFlags in the DEVMODE structure http://msdn.microsoft.com/en-us/library/windows/desktop/dd183565%28v=vs.85%29.aspx, near the bottom of the page it lists the following:

dmDisplayFlags

Specifies the device's display mode. This member can be a combination of the following values.
   
    Value                           Meaning
    DM_GRAYSCALE             Specifies that the display is a noncolor device. If this flag is not set, color is assumed.
    DM_INTERLACED          Specifies that the display mode is interlaced. If the flag is not set, noninterlaced is assumed.

Possibly this DM_INTERLACED flag is not being set in MAME, causing the SetDisplayMode to fail for DirectDraw on interlaced screens?

[Calamity]

Hi Dr.Venom,

The thing here is that the IDirectDraw7 interface has remained unchanged for years, and WinUAE seems to be using the same interface as us, and as long as the error happens when calling the SetDisplayMode method, we first should try to find which exact parameters WinUAE is using to invoke this method, then try to replicate the call on our code.

Do you have any experience compiling WinUAE? If only we could add a log right before the SetDisplayMode is called, in od-win32\dxwrap.cpp, HRESULT DirectDraw_SetDisplayMode function:

Code: [Select]

getvsyncrate (freq, &dxdata.vblank_skip);
dxdata.vblank_skip_cnt = 0;
write_log (_T("IDirectDraw7_SetDisplayMode(%d,%d,%d,%d)\n"), width, height, bits, freq);
ddrval = IDirectDraw7_SetDisplayMode (dxdata.maindd, width, height, bits, freq, 0);

Regarding the ChangeDisplaySettingsEx, you could try something else. In Arcade_OSD, try to set an interlaced mode. Instead of pressing "1", press "2", this will enter the menu without setting full screen on, then select "Set as desktop mode". This option invokes the ChangeDisplaySettingsEx API which is independent from DirectDraw.

[Dr.Venom]

The thing here is that the IDirectDraw7 interface has remained unchanged for years, and WinUAE seems to be using the same interface as us, and as long as the error happens when calling the SetDisplayMode method, we first should try to find which exact parameters WinUAE is using to invoke this method, then try to replicate the call on our code.

Unfortunately I don't have experience compiling WinUAE. I did notice a guide recently that apparently makes it easier to do so. It's in this post here: http://eab.abime.net/showpost.php?p=847432&postcount=18. I don't have MSVC (but am using CodeBlocks with the "MAME" GCC package), which seems to be needed for succesful compilation, but then again I haven't tried it yet.

I was looking at some code at the GIT though and noticed these ddraw_fs_hack_free and ddraw_fs_hack_init routines. Interestingly the ddraw_fs_hack_init first calls the ddraw_fs_hack_free routine and then seems to create a fallback for when opening a directdraw screen fails. At first it calls it like this:
       

Code: [Select]

hr = ddraw->SetDisplayMode (dpp.BackBufferWidth, dpp.BackBufferHeight, t_depth, dpp.FullScreen_RefreshRateInHz, 0);
but if that fails, does it like this:
       

Code: [Select]

hr = ddraw->SetDisplayMode (dpp.BackBufferWidth, dpp.BackBufferHeight, t_depth, 0, 0);
and if that fails calls ddraw_fs_hack_free again

These routines are at line 117 and 135 respectively in the direct3d.cpp, which can be viewed here: https://github.com/tonioni/WinUAE/blob/master/od-win32/direct3d.cpp#L113

Regarding the ChangeDisplaySettingsEx, you could try something else. In Arcade_OSD, try to set an interlaced mode. Instead of pressing "1", press "2", this will enter the menu without setting full screen on, then select "Set as desktop mode". This option invokes the ChangeDisplaySettingsEx API which is independent from DirectDraw.

I tried this, but it makes no difference whether I use the "1" or the "2" method. Also, for both methods the logs returns the earlier reported two lines (SetDisplayMode error & ActivateMode: DDrawInit error).

[Calamity]

I was looking at some code at the GIT though and noticed these ddraw_fs_hack_free and ddraw_fs_hack_init routines. Interestingly the ddraw_fs_hack_init first calls the ddraw_fs_hack_free routine and then seems to create a fallback for when opening a directdraw screen fails. At first it calls it like this:
       

Code: [Select]

hr = ddraw->SetDisplayMode (dpp.BackBufferWidth, dpp.BackBufferHeight, t_depth, dpp.FullScreen_RefreshRateInHz, 0);
but if that fails, does it like this:
       

Code: [Select]

hr = ddraw->SetDisplayMode (dpp.BackBufferWidth, dpp.BackBufferHeight, t_depth, 0, 0);
and if that fails calls ddraw_fs_hack_free again

Yes, I saw that before, I think he's using DirectDraw in for mode setting inside the Direct3D code, that's very interesting as I once tried something similar and didn't work, I'll need to have a look at it at some point. Anyway, although that's not the part of the code we're looking for, the same scheme seems to happen in the DirectDraw part, see:

Code: [Select]

freq = getrefreshrate (width, height);
write_log (_T("set_ddraw: trying %dx%d, bits=%d, refreshrate=%d\n"), width, height, bits, freq);
ddrval = DirectDraw_SetDisplayMode (width, height, bits, freq);
if (SUCCEEDED (ddrval))
break;
olderr = ddrval;
if (freq) {
write_log (_T("set_ddraw: failed, trying without forced refresh rate\n"));
DirectDraw_SetCooperativeLevel (hAmigaWnd, dxfullscreen, TRUE);
ddrval = DirectDraw_SetDisplayMode (width, height, bits, 0);
if (SUCCEEDED (ddrval))
break;
}

So this might be the way to do it: passing refresh as 0. So you can try this quick hack in MAME code, src/osd/windows/ddraw.c

   // full screen mode: set the resolution
   if (window->fullscreen && video_config.switchres)
   {
      //result = IDirectDraw7_SetDisplayMode(dd->ddraw, dd->width, dd->height, 32, dd->refresh, 0);
      result = IDirectDraw7_SetDisplayMode(dd->ddraw, dd->width, dd->height, 32, 0, 0);
      if (result != DD_OK)
      {
         mame_printf_verbose("DirectDraw: Error %08X attempting to set video mode %dx%d@%d call\n", (int)result, dd->width, dd->height, dd->refresh);
         goto error;
      }
   }

I tried this, but it makes no difference whether I use the "1" or the "2" method. Also, for both methods the logs returns the earlier reported two lines (SetDisplayMode error & ActivateMode: DDrawInit error).

I didn't mean "1" or "2" would make a difference, it is the result of "Set  as desktop mode" what is interesting, to see if the issue is with ChangeDisplaySettingsEx too.

[Dr.Venom]

So this might be the way to do it: passing refresh as 0. So you can try this quick hack in MAME code, src/osd/windows/ddraw.c

High five, it works!!

I didn't mean "1" or "2" would make a difference, it is the result of "Set  as desktop mode" what is interesting, to see if the issue is with ChangeDisplaySettingsEx too.

Using "2 [edit]" and then "Set as desktop mode" does absolutely nothing, it doesn't switch the screen (or seems to attempt to) and the log shows no messages upon doing so.

[Calamity]

 

That's great! Then it seems that the ChangeDisplaySettingsEx is at the bottom of the problem, I *believe* the old DirectDraw's SetDisplayMode acts as a wrapper of ChangeDisplaySettingsEx API, and some changes in the later due to new W7 features have screwed the normal behaviour, i.e: the new flags required by this one to enable interlaced modes are not properly managed internally by the old DirectDraw interface, although they are indeed supported by the updated Direct3D one.

Only problem is that we will only be able to store a single refresh for each interlaced mode, otherwise we won't have control on which one is selected.

Now it's time to add the fix for MAME.

[Dr.Venom]

That's great! Then it seems that the ChangeDisplaySettingsEx is at the bottom of the problem, I *believe* the old DirectDraw's SetDisplayMode acts as a wrapper of ChangeDisplaySettingsEx API, and some changes in the later due to new W7 features have screwed the normal behaviour, i.e: the new flags required by this one to enable interlaced modes are not properly managed internally by the old DirectDraw interface, although they are indeed supported by the updated Direct3D one.

Luckily there's this workaround. DirectDraw is also for some time not recommended for use anymore (http://msdn.microsoft.com/en-us/library/windows/desktop/gg426115%28v=vs.85%29.aspx), but for emulation it still seems the best choice, at least that's my preference. I'm very much unfamiliar with all the different API's, but maybe DGXI / Direct2D (http://msdn.microsoft.com/en-us/library/windows/desktop/dd370990%28v=vs.85%29.aspx) is the preferred DirectDraw successor for W7 and higher systems?

Only problem is that we will only be able to store a single refresh for each interlaced mode, otherwise we won't have control on which one is selected.

I guess this is only a problem for mainline MAME? I.e. since we dynamic refresh rate adjustment in GM it doesn't matter which of the available refreshes it picks since it will always be able to modify it on the fly?

Now it's time to add the fix for MAME.

Great

[Calamity]

Luckily there's this workaround. DirectDraw is also for some time not recommended for use anymore (http://msdn.microsoft.com/en-us/library/windows/desktop/gg426115%28v=vs.85%29.aspx), but for emulation it still seems the best choice, at least that's my preference. I'm very much unfamiliar with all the different API's, but maybe DGXI / Direct2D (http://msdn.microsoft.com/en-us/library/windows/desktop/dd370990%28v=vs.85%29.aspx) is the preferred DirectDraw successor for W7 and higher systems?

IMHO Microsoft should have never deprecated DirectDraw and tried to push everyone to the unnecessarily complicated Direct3D API. Direct2D looks like the unspoken late recognition of this fact.

I guess this is only a problem for mainline MAME? I.e. since we dynamic refresh rate adjustment in GM it doesn't matter which of the available refreshes it picks since it will always be able to modify it on the fly?

Yes, but we still need to check that dynamic refresh adjustment is really working for this particular case.

[Dr.Venom]

IMHO Microsoft should have never deprecated DirectDraw and tried to push everyone to the unnecessarily complicated Direct3D API. Direct2D looks like the unspoken late recognition of this fact.

Indeed.

I guess this is only a problem for mainline MAME? I.e. since we dynamic refresh rate adjustment in GM it doesn't matter which of the available refreshes it picks since it will always be able to modify it on the fly?

Yes, but we still need to check that dynamic refresh adjustment is really working for this particular case.

Would you know on top of your head a good interlace testcase, like the one with toki/snowbros for progressive? (It's just that testing with the playstation driver isn't the best one, because it it switches screens a lot.) Or would it also be a good testcase to just force toki/snowbros to run on an interlaced screen through the crt_range setting?

[Calamity]

You can force all games to run at interlaced modes by doing this:

crt_range0 15625.00-16200.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,0,0,448,576

So you can try installing a modeline like 512x448i and try again snowbros/toki in this new scenario.

[Dr.Venom]

OK, I forced snowbros to run on 680x496@60Hz and dynamic refresh rate adjustment for the directdraw interlaced screenmode works!   Both video and audio are fully smooth and emulation speed is at 100% (config and log attached).

Interestingly when I first installed this 680x496i modeline through Soft15Khz, the dynamic adjustment would *not* work, not with ddraw or d3d. I needed to install an extra "dummy" interlaced modeline through Soft15Khz before it would work. This further confirms what we talked about earlier in the other thread (http://forum.arcadecontrols.com/index.php/topic,129025.msg1325851.html#msg1325851).

So as a rule of thumb (to keep it easy) it seems that for every modeline for which you want dynamic refresh rate adjustment to work, an extra "dummy/shadow" modeline needs to be installed that has at least an equally large resolution. I guess it might still work a bit differently, but as a rule of thumb it is simple and it seems to work consistently. Of course this "rule" is on top of the rule that at least > 16 modelines need to be installed before some become available for dynamic refresh adjustment.  So again generalizing to a simple rule of thumb (not wanting to be exact, but something that can be easily explained to newcomers): if a user wants 16 working modelines, he needs to install 32 modelines, of which the second 16 modelines (17-32) are dummy/shadow modelines that have at least an equally large (or to be safe: larger) resolution. Does that also make sense given your experience with XP?

[Calamity]

All right, so we have the dynamic modelines working for interlaced modes too 

Now we just need to add a fall-back condition in the DirectDraw's side of MAME to deal with the interlaced case, and possibly submit the patch when you feel it's stable enough.

However, the behaviour you're describing is definitely different in Windows XP. At least it is for the drivers I'm using. Once we store more than 16 modelines then everything is fine. No need for dummy modelines. Now I understand why you were adding strange 7xx modelines at the end of your list. That's too bad because in practice you're cutting by two the total number of simultaneous modelines you can store, and being 60 the maximum number that the Catalyst drivers have historically supported, that means we can only have 30 useful dynamic modelines. Combined with magic modelines not working in W7, it ends up being a bit disappointing.

[Calamity]

This could be the patch for MAME (untested, may contain errors):

Code: [Select]

// full screen mode: set the resolution
if (window->fullscreen && video_config.switchres)
{
result = IDirectDraw7_SetDisplayMode(dd->ddraw, dd->width, dd->height, 32, dd->refresh, 0);
if (result != DD_OK)
{
mame_printf_verbose("DirectDraw: Error %08X attempting to set video mode %dx%d@%d call\n", (int)result, dd->width, dd->height, dd->refresh);
mame_printf_verbose("DirectDraw: Retrying without forced refresh rate\n");
IDirectDraw7_SetCooperativeLevel(dd->ddraw, window->hwnd, DDSCL_SETDEVICEWINDOW | DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE);
result = IDirectDraw7_SetDisplayMode(dd->ddraw, dd->width, dd->height, 32, 0, 0);
if (result != DD_OK)
{
mame_printf_verbose("DirectDraw: Error %08X attempting to set video mode %dx%d call\n", (int)result, dd->width, dd->height);
goto error;
}
}
}


[Dr.Venom]

Now we just need to add a fall-back condition in the DirectDraw's side of MAME to deal with the interlaced case, and possibly submit the patch when you feel it's stable enough.

That's fine with me. Will you be making the fallback in GM at first? That way we can test and then possibly bring it over to mainline MAME when its working as expected?

However, the behaviour you're describing is definitely different in Windows XP. At least it is for the drivers I'm using. Once we store more than 16 modelines then everything is fine. No need for dummy modelines. Now I understand why you were adding strange 7xx modelines at the end of your list. That's too bad because in practice you're cutting by two the total number of simultaneous modelines you can store, and being 60 the maximum number that the Catalyst drivers have historically supported, that means we can only have 30 useful dynamic modelines. Combined with magic modelines not working in W7, it ends up being a bit disappointing.

Ah you made me realize something, it's definitely not as bad as that. When I talk of dummy/shadow modelines that was purely about focusing on how to get the first sixteen modelines working. I just did some tests and the interesting thing is that the "shadow" modelines (16-32) that are needed for the first 16 to work, work with dynamic refresh rate adjustment themselves also. So basicly if you install 32 (or more) modelines,  they will *all* work with dynamic refresh rate adjustment. Much better news I guess

Sorry for the confusion. It's just that I started out with only a few modelines, and got of sort obsessed with the 1-16 modelines and what the "algorithm" is to get them to work (which is still not fully understood, but alas). Bit of a myopic focus I need to say. If I would have -started out- with a generic 32+ modeline list, e.g. as generated by VMMaker, I would have probably never noticed the issue with the 1-16 modelines. Ah well...

Anyway, given all this, we can make the rule of thumb (for newcomers) a bit easier: to get dynamic modelines working in Windows 7, at least >32 modelines need to be installed. Since most modeline lists automatically range from low to high(er) resolution I don't think we have to care about some specific requirements for the resolution build-up of such a list.   

With regards to the magic resolutions not working, I'm not sure whether that's being caused by Windows 7. It could well be the driver (since I'm using the quite recent 12.6 legacy driver). Possibly with one of the older drivers it will work? I guess the best test would be to install a driver version that is more comparable to the driver you're using on your XP machine and see if that changes things. Maybe I'll give that a go someday, but to be honest, it's all working so well now that I'll stick with this setup for the time being.


Edit: Ah, I see you made a patch for MAME. I'll give that a test later.

[Calamity]

Ufff, that's a relief 

Now, that makes me think... did you test the magic stuff with more than 32 modelines???

The patch will go in next GM patch, then we'll consider submitting it.

[Dr.Venom]

Now, that makes me think... did you test the magic stuff with more than 32 modelines???

I've just also tested it with more than 32 modelines, but magic modelines don't seem to work with the W7 / 12.6 driver combination.

I guess somewhere down the road it would be useful to know what driver versions for Windows XP and Windows 7 (if at all) support the magic resolutions. I see on the AMD site that the "previous" driver section for XP shows downloadable drivers from 8.1 to 12.6. For Windows 7 (and Vista) they also range from 8.1 to 12.6.  To get to know whether or not the magic resolutions are depending on the driver instead of the OS, I guess we should do a test for both, i.e. someone who'll be trying the 12.6 driver for XP and see if magic resolutions still works and someone who'll test the 9.3 driver for Windows 7. I'll probably give the latter a go sometime, but in case someone else feels up to testing (either XP or Windows 7), I'm listing the "previous driver" download pages here:

Previous Catalyst™ Drivers and ATI Multimedia Software for Windows XP Professional/Home Edition
http://support.amd.com/us/gpudownload/windows/previous/Pages/radeonaiw_xp.aspx

Previous Catalyst™ Drivers for Windows XP Professional x64 Edition
http://support.amd.com/us/gpudownload/windows/previous/Pages/radeonaiw_xp64.aspx

Previous Catalyst™ Display Drivers for Windows Vista and Windows 7 (32 bit)
http://support.amd.com/us/gpudownload/windows/previous/Pages/radeonaiw_vista32.aspx

Previous Catalyst™ Display Drivers for Windows Vista and Windows 7 (64 bit)
http://support.amd.com/us/gpudownload/windows/previous/Pages/radeonaiw_vista64.aspx

Possibly if we would gather enough test results on the various driver versions for both XP and Windows 7, it could in the end be part of an appendix to the GroovyMAME/UME manual, showing GM's feature level with the different drivers and operating systems. I guess not as a project to spend much time on, but more of a when someone has some time to do a test, they'll post it here, and it's added to the manual.

The patch will go in next GM patch, then we'll consider submitting it.

That's great

There's another thing on my mind. Since we have dynamic modelines working on Windows 7 now, would it be possible to have VMMaker support writing/installing modelines to the registry in Windows 7? (So that instead of using Soft15Khz, users can skip the soft15khz step and use VMMaker instead for both modeline generation and installation, simplifying the installation steps for both regular users and newcomers.)

[Calamity]

Hi Dr.Venom,

Thanks again for your tests, it definitely looks like something that's common to the driver's version rather than an OS limitation. It's not a big problem, after all the 'magic' resolution stuff was suggested as a workaround for the HS issue, but because it allows us to get perfect results with very few modelines it indirectly makes driver patching unnecessary, that's why I was interested in that, because driver patching is a horrible task that I'd rather not to undertake again (I mean pathing to remove the 60 total custom modes limitation).

Anyway, with the aim of releasing a new GM's patch that's W7 compatible, as soon as possible, I've prepared this test version of Arcade_OSD that implements a non-hardcoded detection of the "master" device registry key* and refresh rate correction for interlaced modes, based on the version of Windows, as well as the fix required to display interlaced modes through DirectDraw on Win7. Please help me testing this, as these changes will be ported inmediately to the new GM's patch.

* It turns out that dynamic modelines only work when editing the modelines stored in registry key assigned to the "master" device of a video card. I don't say "primary" because from the OS point of view there's just a primary display device and it's the one that holds the main desktop. So if you think of your particular setup, where the HD 4xxx is the secondary device, this means that for the OS, both outputs of that card are considered as "secondary". This is a problem because there's no ortodox way to determine which of the outputs is the, say "master" and "slave". And we really need to know because the "master" key is where we have to edit the modelines. So some heuristics have been required to solve this. Your setup is not a problem on this regard because your probably using the "master" device already (was it \\.\DISPLAY7 ??) so it should just work by explicitly targeting the right device. The problem would be if you wanted to use the "slave" output of that card, hopefully the new method will work even in this case.

[Dr.Venom]

Hi Calamity,

Thanks again for your tests, it definitely looks like something that's common to the driver's version rather than an OS limitation. It's not a big problem, after all the 'magic' resolution stuff was suggested as a workaround for the HS issue, but because it allows us to get perfect results with very few modelines it indirectly makes driver patching unnecessary, that's why I was interested in that, because driver patching is a horrible task that I'd rather not to undertake again (I mean pathing to remove the 60 total custom modes limitation).

Ah I see. I can imagine the amount of work involved in patching these video drivers, and the benefit of having magic resolutions working from that perspective also. Even in the face of the work, are you possibly considering patching drivers for Windows 7 somewhere down the road? (Not that I would be in need of 60+ modelines myself anytime soon, especially given that dynamic refresh is working now..)

Anyway, with the aim of releasing a new GM's patch that's W7 compatible, as soon as possible, I've prepared this test version of Arcade_OSD that implements a non-hardcoded detection of the "master" device registry key* and refresh rate correction for interlaced modes, based on the version of Windows, as well as the fix required to display interlaced modes through DirectDraw on Win7. Please help me testing this, as these changes will be ported inmediately to the new GM's patch.

Many thanks for the update. It does show the correct attached \\.\DISPLAYs (Display1 for 7870 and Display7 for 4850). It also shows all custom mode variables (hor/vert rates, porches etc..) on the 4850, the interlace screen switching works without problems, but the only thing that does not seem to work is the "on the fly" edit&testing of the screenmode parameters. I can change port values and edit the modeline values for each screenmode, but when I press "Test" it switches the screen but the changes have no effect.  I've attached some pictures so that you can see what's working.

* It turns out that dynamic modelines only work when editing the modelines stored in registry key assigned to the "master" device of a video card. I don't say "primary" because from the OS point of view there's just a primary display device and it's the one that holds the main desktop. So if you think of your particular setup, where the HD 4xxx is the secondary device, this means that for the OS, both outputs of that card are considered as "secondary". This is a problem because there's no ortodox way to determine which of the outputs is the, say "master" and "slave". And we really need to know because the "master" key is where we have to edit the modelines. So some heuristics have been required to solve this. Your setup is not a problem on this regard because your probably using the "master" device already (was it \\.\DISPLAY7 ??) so it should just work by explicitly targeting the right device. The problem would be if you wanted to use the "slave" output of that card, hopefully the new method will work even in this case.

Thanks for explaining. Possibly this has something to do with that edit&testing the modelines doesn't work on the fly?  If you could output the debug log to the cmd from which I start arcade_osd I could make a full log to a textfile. Now it opens a separate window, it doesn't show all information but I've attached a snapshot of the debug console. It currently only outputs to the debug console on startup of arcade_osd, after that there are no messages after that.

[Calamity]

All right I think I know what the problem is, I'll upload a new file in a while...

[Dr.Venom]

OK..

[Calamity]

One question, in your working version of GM, function reset_video_modes(void) (src/osd/windows/switchres.c), which display name is used, \\.\DISPLAY1 or \\.\DISPLAY7?

[Dr.Venom]

\\.\DISPLAY7

Code: [Select]

while (EnumDisplaySettingsExA("\\\\.\\DISPLAY7", iModeNum, &lpDevMode, 0) != 0)
iModeNum++;
note that I also changed "0" to "6" in get_device_key in switchres.c:

Code: [Select]

//============================================================
//  get_device_key
//============================================================

static int get_device_key(void)
{
DISPLAY_DEVICEA lpDisplayDevice;
lpDisplayDevice.cb = sizeof(DISPLAY_DEVICEA);

        //if (EnumDisplayDevicesA(0, 0, &lpDisplayDevice, 0))
if (EnumDisplayDevicesA(0, 6, &lpDisplayDevice, 0))

[Calamity]

That's a bit strange because in theory the program must be actually passing "\\.\DISPLAY7". Anyway try this new version, now I have replicated exactly the code in your GM build, but for passing the display name as a param instead of hardcoded. The name passed will appear in the log whenever you update the mode, so have a look to check if its \\.\DISPLAY7.

[Dr.Venom]

It passes \\.\DISPLAY7 everytime I do "test", but unfortunately it still doesn't work.

Hmmm... I'm thinking of something that may or may not be related. 

When I start e.g. the snes driver with GM and in the snes driver ini I have a crt_range. Upon first start GM will correctly do the dynamic screen geometry/refresh adjustment based upon the crt_range in the ini.  Quitting/starting GM multiple times in a row will make no difference, each time it correctly modifies the screen to the crt_range values from the ini.

But suppose I want to try out some new porch values. I quit GM/SNES and do an edit of the crt_range in the ini. If I then start GM again then the new crt_range values from the ini will have no effect on the real screen (even while I see in the log that it does request a modeline according to the new values). Instead, it will still modify the real screen according to the old crt_range values.

The solution to getting the changes to the crt_range in the ini file applied, is to do a reboot of the PC. After the reboot the changes to the crt_range values will -really- get applied to the visible screen. 

Could that somehow be related to the current issue?

[Calamity]

The solution to getting the changes to the crt_range in the ini file applied, is to do a reboot of the PC. After the reboot the changes to the crt_range values will -really- get applied to the visible screen. 

Could that somehow be related to the current issue?

Damned, that means it's not working at all

But you did test snowbros/toki one after the other without rebooting didn't you?

[Dr.Venom]

Let's be careful that we don't get any misunderstanding

Yes I did test them *without* rebooting. They both have their own ini files, and both correctly modify the installed soft15khz *62hz* modeline to respectively 60Hz and 57.5Hz, just as was shown in the log. All within one session. So to be clear, they are sharing -one- installed modeline and GM does the modification on the fly from 62Hz installed rate to 60 and 57.5 Hz.

So this is one gameplay session:
start Snowbros -> 256x240_62Hz installed -> 57.5Hz 'on the fly', quit
start Toki -> 256x240_62Hz installed -> 60Hz 'on the fly', quit
start Genesis -> 256_240_62Hz (and 320x240_62) -> 60Hz 'on the fly', quit
start MSX2 -> 544x288_52Hz -> 50.16Hz 'on the fly', quit
start SNES -> 512x240_62Hz -> 60Hz 'on the fly', quit
Etc...

Note that none of the 'on the fly' refresh rate exist in my soft15khz installed modeline list. (That's why I changed all soft15khz installed modelines to 62Hz+, to be very sure the refresh rate does indeed get modified correctly.)

Edit: all above cases run at very close to 100% with practically zero soundbuffer overflows. So these are working correctly (without the dynamic adjustment a difference of 2Hz would lead to 40-50 overflows with a few seconds..)
 

[Calamity]

If the snowbros -> toki -> snowbros -> toki sequence works, then why wouldn't work changing the crt_ranges in the same way??  We're just updating the modelines, the driver shouldn't behave different in both situations, *unless* the driver is refactoring the modelines internally, which sounds like a scary possibility. As a test, you can write down the modelines that GM calculates and uses for both toki/snowbros, then by means of Arcade_OSD, edit modeline menu, enter those values manually and check the refresh change. If that works then there's something truly interesting going on there.

[Dr.Venom]

Hmm.. I'm afraid that in Windows 7 GM can modify each available resolution only *once* 'on the fly' per session. After that it sticks at the modified refresh rate for the session, until a reboot

It is something that I have overlooked in the previous tests and can't be noticed by %speed or soundbuffer values.

This is what happens after reboot:
1. 256x240_62 is at refresh 62.199 (the soft15khz installed value)   
2. Run GM/Snowbros -> 256x240_62 gets correctly modified to 57.499  (log_speed% shows 100%, movement fully smooth, sound smooth)
3. Run GM/Toki -> 256x240_62 seems to get modified to 59.61 but actually is sticking at the earlier snowbros modified speed 57.499 (log_speed% shows 100%, movement *not* fully smooth (there are occasional pauses in the scrolling), sound smooth.

Turning the sequence around, this is what happens after reboot:
1. 256x240_62 is at refresh 62.199 (the soft15khz installed value)   
2. Run GM/Toki -> 256x240_62 gets correctly modified to 59.61 (speed 100%, movement fully smooth, sound smooth).
3. Run GM/Snowbros -> 256x240_62 seems to get modified to 57.499 but actually is sticking at the earlier toki modified 59.61Hz speed (log_speed 100%, movement fully smooth, sound *not* smooth, i.e. regular "clicks" )

On the other hand, you won't notice any problem with the GM dynamic adjustment when you run different console/arcade drivers in one session, that all use different resolutions. They will all get properly modified. So running for example snowbros, snes, colecovision, odyssey2, msx2, pc-engine in succession is not a problem in one session, all will get properly dynamically adjusted.

I tested what you asked, editing the values for 256x240_62 to the snowbros or toki generated modelines values in arcade_osd. Unfortunately that doesn't replicate the GM behaviour. It will not adjust the screenmode on the fly, also not after a fresh reboot.

I did notice something peculiar though. If I list the 256x240_62 mode in arcade_osd after reboot then it shows in "edit_modeline" the proper values belonging to the 62Hz modeline, and testing the refresh shows 62.199Hz. If I then quit arcade_osd, then run snowbros, quit snowbros, then start arcade_osd again, then for the 256x240_62 modeline it shows all the properties that belong to the 62.199Hz modeline, but if I test the refresh it gives me the snowbros refresh 57.499Hz!  See attached pictures "256x240_62_before" and "256x240_62_after_running_snowbros". The same happens when after a reset I run Toki first before running arcade_osd, then the 256x240_62 screenmode will show it's own _62Hz properties, but testing the refresh speed will give the toki refresh speed of 59.61Hz. I'm puzzled  .

Basicly that makes me conclude that GM can currently in windows 7 modify each resolution only *once* per session. After this modification the screenmode is stuck at the modified refresh rate for the session, even though the modeline -seems- properly restored. This is definitely one for Sherlock...  At least I'm happy to understand now why it can easily show either correct GM behaviour or "erratic behaviour" when running various games within one session.

Edit: uploaded correct snapshot now for "256x240_62_after_running_snowbros".

[Calamity]

That's a very surprising result, I wish it didn't work like that, really.

I quite don't get the part where the game you run in the second place still runs at 100%. This shouldn't be the case. Are you possibly using the -frame_delay here? By using the -syncrefresh option only, the speed should adapt automatically to the refresh rate.

At first I thought that it could be that the first time the resolution is used, the values are read from registry and never updated, but since you said that you have measured the speed before (62.199) and after (57.499) then the modeline is read at least twice. Why wouldn't it be read more than twice? Mystery.

If this is the case, then Arcade_OSD should be capable of adjusting geometry at least once? But it doesn't....

Now I don't even know if the 'dynamic' stuff could not be a side effect of patching the drivers...

I want to thank you again for your detailed tests, they're of great value.

[Dr.Venom]

I quite don't get the part where the game you run in the second place still runs at 100%. This shouldn't be the case. Are you possibly using the -frame_delay here? By using the -syncrefresh option only, the speed should adapt automatically to the refresh rate.

Yes, I'm using the frame_delay. See attached log.

At first I thought that it could be that the first time the resolution is used, the values are read from registry and never updated, but since you said that you have measured the speed before (62.199) and after (57.499) then the modeline is read at least twice. Why wouldn't it be read more than twice? Mystery.

I'm not sure what you mean by the highlighted line?

Now I don't even know if the 'dynamic' stuff could not be a side effect of patching the drivers...

I'm getting the feeling that the dynamic stuff -is- indeed a side effect of patching the drivers. I did an additional test that made me realize how things might actually be working..

I turned things once again around from the previous post where arcade_osd would read the 256x240_62 refresh right after a reset as 62.199, but after running snowbros it would show the snowbros refresh rate (even though showing all the _62Hz modeline parameters).

So my hypothesis is that the -first- time a screenmode resolution is opened, the video driver is putting the modeline parameters for the specific resolution in a temporary structure and is sticking with these values for the rest of the Windows session. They will as such be unmodifiable for the rest of the session also.

So another way of testing the hypothesis is to first open the 256x240_62Hz screen with arcade_osd and then run snowbros. If the hypothesis is correct, then with this sequence of first opening the screen with arcade_osd and then starting GM, it will not be able to modify the refresh for snowbros to 57.5Hz. So I did run it in this sequence and indeed it confirms the predicted behaviour, see the attached log:

Average speed: 108.17% (41 seconds)
Sound: buffer overflows=160 underflows=0

The speed at 108.17% is an *exact* reflection of snowbros running at 57.5Hz and the screen "stuck" at 62.199Hz (62.199/57.5=108.17%). 

With these and the previous findings it seems to be becoming quite clear what is happening.  Basicly the video driver is putting all opened screenmode resolutions during a session in a "shadow/temporary" structure, which it calls upon again when the -same- screenmode is opened again during the session. For these resolutions it does that instead of re-reading the registry.

This seems to perfectly explain all observed behaviour and why it's possible that arcade_osd (after first starting snowbros) will show all correct modeline parameters for the 256x240_62Hz screenmode, while actually testing the refresh will result in the refresh of 57.5Hz. So in detail this is what happens.

Run Snowbros:
1: GM modifies the modeline to 57.5Hz
2: Video driver opens the resolution with the 57.5 modeline values and puts the 256x240 resolution in its "temporary" structure with the modified refresh / modeline parameters. Snowbros runs at the correct 57.5Hz modeline speed.
3: close GM -> GM restores the original _62Hz modeline to the registry.

Next run Arcade_OSD:
Open the 256x240_62Hz resolution. Two things happen:
  1:  Arcade_OSD reads the modeline values for 256x240 from the registry -> finds the _62Hz modeline characteristics and shows these values in edit modeline
  2: The video driver bypasses the registry modeline values, because the screenmode has been opened previously during the session, and *thus* calls the 256x240 resolution from the "temporary" structure, opening the screenmode with the earlier created 57.5Hz refresh parameters!

This results of course in arcade_osd measuring the 57.5Hz refresh, even though reading the registry values would suggest otherwise. Of course at this point, once a specific resolution is put in the drivers' "shadow / temporary" structure, reading values from the registry is futile.

So basicly, if this is how things are (approximately) working, the only solution would be a hack of the video driver which enables GM to "reset" or clear  the "shadow / temporary" structure at the same time when it restores the modeline. I'm not sure, but possibly you have seen similar behaviour like this when patching/hacking the driver for XP?

In any case if this would make sense and you would ever want to take a stab at the Windows 7 *64-bit* video driver, there's a particular thing to note. In Windows 7 64-bit all drivers are enforced to be signed with a valid certificate. I'm not sure what is involved in hacking the driver, but I can imagine that it would break the signature/certificate validation. Luckily there's a way around this. The solution  is to put Windows 7 64-bit  in "test mode", which allows the installation of unsigned drivers. The tool to put it in test mode can be found here:

Driver Signature Enforcement Overrider 1.3b
http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=826

I understood that you're not very much looking forward to hacking a driver again. But if you were to take a look at hacking again then hopefully you'll consider looking at the 12.6 legacy driver. Basicly because it has a number of benefits:
- it's the final (very) stable release for HD 2000/3000/4000 cards;
- it has a release for both WindowsXP, Windows 7 AND Windows 8, making it futureproof (compatible with new hardware) for the foreseeable future;
- because it's a separated driver it will work very well with dual gfx-card setups, making it possible to additionally install the very latest video-card and driver, creating the ultimate combination of oldskool CRT arcade/console emulation and "newskool" PC gaming, all from one machine.

Possibly because it's the same driver version for XP, 7 and 8 (some of) the hacks, once done for one driver, can be ported over to the drivers for the different platforms? I guess this would involve quite a lot of work still, but the benefit would be having one final set of hacked drivers, that will show the same behaviour across platforms, and not having to be updated ever again (i guess that will be of major importance).

I want to thank you again for your detailed tests, they're of great value.

Thanks. It's definitely my pleasure to be of help in this great project. I really appreciate all of the effort and dedication that you've been putting into bringing (CRT) perfection to the already insanely great mainline MAME/MESS/UME project.

[Dr.Venom]

Hi Calamity,

By accident I ran into something that might be interesting in view of the things we have been discussing.

With the recent updates (SVN) to the Playstation driver I've been doing some testing with Playstation games and ran into an error that accidentally showed some weird behaviour regarding the modelines.

In short what happened (and this can be reliably repeated) is that I was running Gradius Gaiden in the PSJ driver, which runs the main game mode in 320x240_60Hz. GroovyUME uses my 320x240_63Hz mode, which is the *only* 320x240 mode that I have in my system, to modify it to the correct refresh. Then I thought I'd change the game and by accident picked a CD image that isn't supported by UME, resulting in a crash. I then rebooted my PC and guess what had happened: the 320x240_63Hz mode was gone from my system and strangely enough there were *two* new 320x240 modes in my system. The one is 320x240_60 and the other is 320x240_59.

Since this can be reliably repeated (of course after first installing the old modelines list with soft15Khz) I made a snapshot of arcade_osd showing the resolutions before and after the crash (and rebooting the  PC). In "arcade_osd_screenmodes_before.png" you can see there's only the 320x250_63Hz mode.

In attached log you'll see that I made UME crash, by selecting an unsupported CD image, while UME was displaying the 320x240 screenmode. The  320x240_63Hz modeline as a result doesn't get restored. I then again rebooted the PC. The snapshot "arcade_osd_screenmodes_after" show that the 320x240_63Hz mode is gone and has been replaced by -two- new 320x240 modes: 320x240_60 and 320x240_59, both marked as native.  Just to be sure there are none of these modes in my system with a fresh modeline.txt install with soft15Khz and omitting the 320x240_63 modeline, I tested just this and indeed there were -no- 320x240 modes in my system after reboot.

I'm not sure what to think of this, is there possibly a clue in this as to how Windows 7 is managing the 'on the fly' modeline modifcation? (Which as we found out earlier only works the very first time a screenmode is opened).  If I look at the log I see that it modifies the _63Hz mode to _60Hz, so that would be the expected mode to appear after named crash and reboot. But why is the second mode 320x240_59Hz added?

Maybe you have an idea as to why this happens, or maybe there's a clue in it regarding the dynamic modeline changes in Win 7?

In any case I thought I'd mention it to you. Maybe it's useful in some way (or maybe not...)

[Calamity]

Hi Dr.Venom,

At first I thought that it could be that the first time the resolution is used, the values are read from registry and never updated, but since you said that you have measured the speed before (62.199) and after (57.499) then the modeline is read at least twice. Why wouldn't it be read more than twice? Mystery.

I'm not sure what you mean by the highlighted line?

When I wrote that I was under the belief that you were actually seeing two effective refresh rates per sesion: I thought you were testing the resolution with Arcade_OSD first before launching it with GM, and getting two different refresh rates, that was puzzling me. But it wasn't until your later experiment when you described you had actually tested with Arcade_OSD before, and then you got a much more logical result.

I agree you, the drivers just read the registry modelines once, at the time the video mode is requested by the OS the first time. After that the modeline is cached and never updated again in that session.

I'm getting the feeling that the dynamic stuff -is- indeed a side effect of patching the drivers.

I'd like to believe it, but I have the feeling there's something more. Unless the patch produces some sort of overflow that magically makes the driver "forget" the previously read modelines... unlikely.

I then rebooted my PC and guess what had happened: the 320x240_63Hz mode was gone from my system and strangely enough there were *two* new 320x240 modes in my system. The one is 320x240_60 and the other is 320x240_59.

Well this makes some sense and connects to something I read some time ago:

http://support.microsoft.com/kb/2006076/en-us

The custom mode definitions used by Soft-15khz and GM consist on two parts, the first one is just a "label": e.g. 320x240@63, the second one is the modeline itself. For Windows XP & older drivers, the link between label and modeline has been happily deterministic, now it seems it is not anymore.

My guess is that when the driver finds the label 320x240@63, then it goes to the corresponding modeline definition, but it makes some sort of calculation to check that the modeline's refresh matches the label. As this is not the case, it just drops the modeline, and decides to cook one by itself. And by default it offers two flavours: 59.94 Hz and 60 Hz.

This is not the behaviour we had before, at least with Catalyst 9.3, the one most of us are using. There was no checking of the modelines, you could indeed use some crazy values provided the checksum was right, that's what makes the magic resolutions trick possible.

Last week I did some testing with Catalyst 12.4 and a Radeon HD 6450 (this was before you wrote suggesting 12.6). I'd prefer 12.4 rather than 12.6 because it covers the whole HD 4xxx - HD 7xxx range, as it wouldn't make much sense to spend time hacking a version that is worse  in every single aspect that I've tested as compared to 9.3*, if we can't at least gain compatibility for some newer generation of cards. Anyway.

* I mean the aspects related to modelines, CRTs and stuff, (3D performance, I don't care).

The fact is that the results with 12.4 and HD 6xxx where just catastrophic. I bought this card some time ago just for testing, but hadn't had the time/mood to do it. I knew there was going to be some ---steaming pile of meadow muffin--- to deal with, because I had read Sailorsat's own experience with these cards. But I couldn't imagine it was going to be sooo bad. I'll talk about this soon, but let's say that unless a miracle happens, under Windows, we're going to be stuck with HD 4xxx forever.

Ironically the HD 6450 works *perfectly* under Linux.

Before we go on, why do you need exactly 12.6? Is it that 9.3 will not coexist with newer versions of Catalyst?

[Dr.Venom]

I agree you, the drivers just read the registry modelines once, at the time the video mode is requested by the OS the first time. After that the modeline is cached and never updated again in that session.

That's it indeed, too bad really.

I'd like to believe it, but I have the feeling there's something more. Unless the patch produces some sort of overflow that magically makes the driver "forget" the previously read modelines... unlikely.

I guess you're right, that was a bit too much assumption from my side 

Well this makes some sense and connects to something I read some time ago:

http://support.microsoft.com/kb/2006076/en-us

The custom mode definitions used by Soft-15khz and GM consist on two parts, the first one is just a "label": e.g. 320x240@63, the second one is the modeline itself. For Windows XP & older drivers, the link between label and modeline has been happily deterministic, now it seems it is not anymore.

My guess is that when the driver finds the label 320x240@63, then it goes to the corresponding modeline definition, but it makes some sort of calculation to check that the modeline's refresh matches the label. As this is not the case, it just drops the modeline, and decides to cook one by itself. And by default it offers two flavours: 59.94 Hz and 60 Hz.

That makes sense. I logged a session of GM right after the crash, but before rebooting the PC. It shows this line:

SwitchRes: [ 320]x[ 240]_(63=59.9577Hz)
   rng(0):  320 x 240_60.000p 15.600 [fract] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(0.500, 0.500)

So indeed the label and the refresh don't match. Which, as you pointed out, causes the driver after rebooting to cook one by itself with the default flavours 59(.94) and 60.  Interestingly it only does that after rebooting, not during the session.

Would there be possible routes (within reach) to further improving the GM experience on W7 in your opinion, or for a better question: did we reach the point where it "doesn't suck" anymore?

I have to say I'm -very- happy with how things are working right now, but I would be interested in your opinion.

[Dr.Venom]

The fact is that the results with 12.4 and HD 6xxx where just catastrophic. I bought this card some time ago just for testing, but hadn't had the time/mood to do it. I knew there was going to be some ---steaming pile of meadow muffin--- to deal with, because I had read Sailorsat's own experience with these cards. But I couldn't imagine it was going to be sooo bad. I'll talk about this soon, but let's say that unless a miracle happens, under Windows, we're going to be stuck with HD 4xxx forever.

It indeed seems to be the case. That's a shame, but at the same time, I created a route for myself that makes me care less about that, see below.

Before we go on, why do you need exactly 12.6? Is it that 9.3 will not coexist with newer versions of Catalyst?

Well it has to do with the previous issue. I like to run everything from one PC, so that's emulation, modern gaming, etc. It doesn't only take less space in the home, but it save me a heap of time not having to maintain multiple machines, with different OS's, hardware, drivers etc...  But, I *don't* want to be stuck with a HD 4850. That's why I've explored the route of installing a mainboard that can take more than one videocard. Just so that I can have the 4850 in there, but at the same time being able to upgrade the other slot with the very latest graphic cards (HD 8000+ in a few years etc.) Now opposing to what most people were telling me (in the shops) that works like a charm, if you take a little care installing the video driver(s).

Now, why my preference for the 12.6 legacy driver? At first I was working with the 11.x to 12.x drivers, which worked fine. You install -one- driver and both cards are working fine. That is, as long as the card is supported by the driver. But then I started realizing that working with an older driver would at some point break the compatibility with newer video cards.  Then I would be stuck with -not- being able to upgrade to the latest video-card again some day in the future!

Then came the split with the legacy 12.6 driver, which only supports up to HD 4800. But guess what, IMO this has actually been a blessing in disguise (*especially* when HD 4000 will really turn out to be the last card to support custom modelines and the like, which it more and more seems to be the case). Because it's a split driver it will coexist happily with the very latest driver from AMD, meaning that you'll be be able to always run a  HD2000-4000 together with the very latest videocard AND the very latest driver. So when HD8000 comes out  you can upgrade your hardware and even keep up-to-date with the very latest driver updates, while at the same time being able to also run the emulation through the HD4800, all from a single PC. Currently I have the HD4850 installed, which is running of the 12.6 legacy driver and a HD7870, which runs of the 12.10 driver. Catalyst Control Center is also the very latest.

I guess the only step for people to take is to buy a motherboard that supports multiple video-cards, and most of these boards do so today. It will set you back anywhere between 100-250 euro. But after that you'll never have to worry again about HD 4000 being the last cards to really support custom modelines, or worry about maintaining multiple PC's, multiple OS's etc, and at the same time keep at the forefront of the latest GPU's released if you would desire to do so of course.

I do see an issue though, it's that I'm running Windows 7 (SP1) which has quite good multi gpu/monitor support, and I'm not familiar with the way XP deals with it.

So the bottom line why I would be in favour of the 12.6 legacy driver, is that it fully supports dual video-card set-ups *in a future-proof way*, which makes it possible to keep  your PC up to date with the very latest developments in (video-card) hardware,  while at the same time being able to run all things that are great in emulation (GroovyUME and WinUAE ), all from one system.

Hopefully that makes some sense. Other points of view are of course also appreciated.

I guess the main question is whether you want to support the single video-card setups in the best possible way (thus using one of the pre 12.6 legacy drivers), or whether you want to support the dual videocard setups in the best possible way. I wish it would have all been a bit easier, but unfortunately it's not. I guess in the end we should all move over to Linux... but for me, I've just invested too much time in Windows 7, it's a modern OS and it's working very much how I like an OS to work, so stepping over to Linux would be a too big a step for me at this point in time...



Edit: sorry, I might not have been clear on the co-existing part:

Before we go on, why do you need exactly 12.6? Is it that 9.3 will not coexist with newer versions of Catalyst?

No indeed, in my experience it doesn't. It seems that when drivers have overlap in the cards that they support, they will fight over which one gets installed -for both cards-. I tried to have the 11.x driver (for HD4850) and the 12.x  drivers (back then for HD6870) coexist, but it would only cause trouble.

Also, I guess you're using the 9.3 as an example, but to be clear anything up-to the 10.x drivers has preliminary/poor Windows 7 support. The older files are provided on the history page, but if you read the readme files, than for example the 9.3 driver for Windows 7 isn't even officially approved by AMD, it's explicitly preliminary. So that means for Windows 7 you would at least need to go with a much newer driver.