Question on code

[Dr.Venom]

Hi Calamity,

For testing purposes I'm trying to log this HZ_TO_ATTOSECONDS(best_mode->vfreq) value in GM on runtime. I'm trying the following near where it's used:

Code: [Select]

UINT64 v_freq;

v_freq = HZ_TO_ATTOSECONDS(best_mode->vfreq);
printf("vfreq: %I64u\n", v_freq);

Which returns a value in attoseconds (at least it seems so, it's quite a large number). But then when I convert it to a double by adding this code:

Code: [Select]

v_freq_float =  ATTOSECONDS_TO_DOUBLE(v_freq);
printf("vfreq_float: %f\n", v_freq_float);

then it returns me values like 9.223372. This doesn't seem right to me, because when I do "v_freq = HZ_TO_ATTOSECONDS(50);" then the vfreq_float in above code returns 0.02. (20 milliseconds.) I would expect the double for v_freq based on the (best_mode->vfreq) to return something similar, since the screen refresh is at about 50.15hz.  Do you maybe have an idea what I'm doing wrong? Some help/pointer would be greatly appreciated. 

[Calamity]

Have you tried logging the best_mode->vfreq value itself? This is not initialized unless you're using the -modeline option.

[Dr.Venom]

I'm not using the -modeline option (it's at "0"). If I try logging it direct, like this:

printf("vfreq_direct %f\n", best_mode->vfreq);

it returns 0.000000.

In case it's helpful, I'm looking at the following code:

Code: [Select]

if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && best_mode->hactive)
            target_ticks = m_throttle_last_ticks + HZ_TO_ATTOSECONDS(best_mode->vfreq / best_mode->result.v_scale ) / attoseconds_per_tick * m_framedelay / 10;
else
target_ticks = m_throttle_last_ticks + real_is_ahead_attoseconds / attoseconds_per_tick;
What value should the best_mode->freq contain in this case when modeline is set to 0?

I also tried to log the "best_mode->result.v_scale", but this will also return "0".  I don't have any problems with logging other parameters (like target_ticks, etc..)

[Calamity]

That's what I was thinking. It's not even initialized. Fortunately I reminded checking for best_mode->hactive, otherwise it would be dividing by zero just below.

I'm afraid to say that you haven't tested the -frame_delay option yet  It's my fault, I should have warned that you need to use the -modeline option in order to make the other one effective but I had too many things in my head. But that's the default option anyway, it's just possible to get disabled for testing purposes, but most of the GM's logic passes through the modeline option now.

As a note, it doesn't matter if you're using W7 and your modelines are not editable, W7 won't allow GM writting anything to the registry so it's safe to have the -modeline option enabled, if that's what worries you.

[Dr.Venom]

That's what I was thinking. It's not even initialized. Fortunately I reminded checking for best_mode->hactive, otherwise it would be dividing by zero just below.

I'm afraid to say that you haven't tested the -frame_delay option yet  It's my fault, I should have warned that you need to use the -modeline option in order to make the other one effective but I had too many things in my head.

No worries, it was for a reason that I was looking at the code. I wanted to make sure that it was actually effectuated, so I thought I'd try and implement a small high resolution timer on the actual throttle time. But then the first (trial) results seemed to point to the fact that the frame_delay wasn't influencing the throttle time, so I delved deeper into it with logging of all the individual variables. Strangely though it does seem to do *something*, because there's a material difference between a setting of 0 (too fast "bug" rears its head, as we discussed before) versus 1 (all machines work properly)... 

On the positive side, if it's already working this good without proper effectiveness of the frame_delay with the config used, then it can only get (even) better

I just tried with modeline at 1. Unfortunately  it doesn't change the values reported with the logging of the "HZ_TO_ATTOSECONDS(best_mode->vfreq)". It still returns 9.223372 (see first post), or 0.000000 if I try logging it directly.

Any idea? Could you possibly try to log the value on your machine/setup and see if the printf works correctly?

But that's the default option anyway, it's just possible to get disabled for testing purposes, but most of the GM's logic passes through the modeline option now.

Do you mean that the modeline switch is only there to turn it off for testing purposes, but that it really should always be "on"?

As a note, it doesn't matter if you're using W7 and your modelines are not editable, W7 won't allow GM writting anything to the registry so it's safe to have the -modeline option enabled, if that's what worries you.

No that didn't worry me. It's just that on the previous release it would not work with the Win 7 catalyst driver, so I turned it off (and quite happily proceeded with good results using soft15khz modelines tweaked by myself).

In case it's helpful I attached a log of the boot with modeline=1.

[Calamity]

Do you mean that the modeline switch is only there to turn it off for testing purposes, but that it really should always be "on"?

Yes, that's it.

You've been noticing a difference because the frame_delay has been allowing the throttling code to get executed, but just as the usual full-frame delay, so in a sense it's as if you had already tested with -frame_delay 9. What seems odd to me is that you didn't notice hiccups.

In case it's helpful I attached a log of the boot with modeline=1.

Well, there's something awfully odd in your log. Are you testing from a laptop or do you have two monitors attached? If you see, the modes retrieved by SwitchRes are not the same as the ones detected by DirectDraw. Now I remind you said you had two cards in there:

Video: Monitor 00010001 = "\\.\DISPLAY1" (primary)
Video: Monitor 00010003 = "\\.\DISPLAY7"

That's why the modeline algorithm is not finding your low-res modes. You guys have so complicated setups  I need some sleep...

[Dr.Venom]

Yes, that's it.

You've been noticing a difference because the frame_delay has been allowing the throttling code to get executed, but just as the usual full-frame delay, so in a sense it's as if you had already tested with -frame_delay 9. What seems odd to me is that you didn't notice hiccups.

Ah, that reassures me a bit, because the input response already felt exceptionally good. That I didn't notice hickups, could be explained by the fact that I've been extensively testing the MSX driver/games, which runs at 2250% unthrottled. I did notice some noticable hickups/slowdowns on the SNES games (Super Swiv, Space Megaforce) that weren't there in the previous release, but decided to test more later on, because of the new u3 release and the fact that the driver is still not marked as good. But given this, it seems more likely that it's related to the frame_delay mixup.

Well, there's something awfully odd in your log. Are you testing from a laptop or do you have two monitors attached? If you see, the modes retrieved by SwitchRes are not the same as the ones detected by DirectDraw. Now I remind you said you had two cards in there:

Video: Monitor 00010001 = "\\.\DISPLAY1" (primary)
Video: Monitor 00010003 = "\\.\DISPLAY7"

That's why the modeline algorithm is not finding your low-res modes. You guys have so complicated setups  I need some sleep...

I wouldn't call it complicated per se, it's more of a heavenly dual-monitor set-up Slot 1 has a Radeon 7870 (with LED @ 1080p), to play all modern high-end games, and slot 2 has the 4850 (CRT monitor), to play the oldskool and arcade stuff.  From a programmer's standpoint I understand it could be called an "exotic" setup, but hopefully not too complicated for GroovyMAME not running on it

Anyways, I'm off to some sleep also...

[Calamity]

I wouldn't call it complicated per se, it's more of a heavenly dual-monitor set-up Slot 1 has a Radeon 7870 (with LED @ 1080p), to play all modern high-end games, and slot 2 has the 4850 (CRT monitor), to play the oldskool and arcade stuff.  From a programmer's standpoint I understand it could be called an "exotic" setup, but hopefully not too complicated for GroovyMAME not running on it

Anyways, I'm off to some sleep also...

The key question here is: how are you telling MAME to run on the secondary device? Are you by any chance using the -screen0 option? I mean like this:

- screen0 \\.\DISPLAY7

This might be the issue, because GroovyMAME gets the target device from the general -screen option rather than the -screen# ones.

In other words, GM is reading the available resolutions for your LED TV instead of the CRT, that's why it prompts all of them as out of range and it doesn't return any working modeline.

If that is the case, use the -screen option instead. I guess the use of multiple devices is something I'd need to improve on next releases, it's just that till now nobody seemed to be using this stuff.

[Dr.Venom]

The key question here is: how are you telling MAME to run on the secondary device? Are you by any chance using the -screen0 option? I mean like this:

- screen0 \\.\DISPLAY7

This might be the issue, because GroovyMAME gets the target device from the general -screen option rather than the -screen# ones.

I was indeed using the -screen0 option. Changed it to -screen and now modeline selection works! Thanks It's now also reporting more sensible values when logging with printf, as mentioned in the previous posts. 

I guess the use of multiple devices is something I'd need to improve on next releases, it's just that till now nobody seemed to be using this stuff.

Yes I guess it could need some improvement still. I've logged one instance of running GM (see attached), and there you see at the beginning that it  tries to detect all soft15khz modes on the primary adapter (the 7870), which doesn't even have any 15khz modes installed.  After failing those, switchres fortunately still picks up on all the modes for switching on the 4850, but I guess something with the screenmode/adapter selection could still be improved.

While testing I ran into a few other things:

One thing I found is that GM reads the modeline refresh rates as integers, i.e. when real mode is 50.15hz, then GM reports 50.00. At least it's doing that on my soft15khz setup. That's also the value used in the "best_mode->vfreq", which will lead to some (unwanted) inaccuracy in the emulation timing. Is there something I could do to make it read and use the real (float) refresh rate?

Secondly, I'm using the following crt_range:

crt_range0                "15525-15800, 49-61, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 216, 294, 448, 576"

But somehow it reports all -interlaced- screenmodes as out of range (see log.txt), any idea what's causing that?

Lastly I would want to wrap a timer around some parts in the emulation, to get an idea of the time they're taking, also in the context of using -frame_delay. Basicly I want to wrap them around the different parts of the emulation flow, i.e.: (1)throttle + (2)emulate_frame + (3)wait_for_sync + (4)flip.

Now I managed to wrap a timer around the "throttle" time, by:

starting the timer after g_profiler.start(PROFILER_IDLE);  in src/emu/video.c (at about line 950)
stopping the timer after g_profiler.stop(); in src/emu/video.c (about line 990)

Which quite accurately show the real throttle time and how it changes for other values of -frame_delay.

But now I'm looking to wrap a timer around part (2) "emulate_frame", but I'm a bit at a loss where this is called from in the source code and where it ends. Do you maybe have a pointer on that? Any help would be appreciated..

[Calamity]

Yes I guess it could need some improvement still. I've logged one instance of running GM (see attached), and there you see at the beginning that it  tries to detect all soft15khz modes on the primary adapter (the 7870), which doesn't even have any 15khz modes installed.  After failing those, switchres fortunately still picks up on all the modes for switching on the 4850, but I guess something with the screenmode/adapter selection could still be improved.

Yes, I'll need to have a look at that. The routine which reads the current video mode points to the right device as defined by the -screen option. But I thought it would be a good idea to force the routine which reads from the registry to always pick the default adapter, this is because for dual head ATI cards you actually need to store the modelines in the registry key assigned to device #0, otherwise they don't have effect, that's with independence of which head you want to point the video. However this idea will fail as soon as instead of a two headed card you have two physical video cards installed in the system, and the one we want to use for GM happens to be the secondary device - and I swear I knew this might happen but it seemed to me it was a very unlikely setup!

Anyway, even when this is fixed in GM, or you decided to swap your cards from slot, GM won't still be able to read/write the registry in W7, this is because it has not the privileges to do it. I think you may give it the privileges running the app as administrator or something.

One thing I found is that GM reads the modeline refresh rates as integers, i.e. when real mode is 50.15hz, then GM reports 50.00. At least it's doing that on my soft15khz setup. That's also the value used in the "best_mode->vfreq", which will lead to some (unwanted) inaccuracy in the emulation timing. Is there something I could do to make it read and use the real (float) refresh rate?

This is the next consequence of GM not being able to read your registry modelines. The OS reports refresh rates as integer number (yes, someone thought it was accurate enough for the average man). This is a problem. Fortunately thanks to the use of registry modelines we can bypass the OS info and have an accurate knowlegde of the refresh rate a custom mode is going to have before setting it, this is used by GM to base its logic on. As long as you can't access that information (as is the case with ArcadeVGA 3000), you have to trust on the integer value the OS returns, as a mere aproximation of the real value.

Secondly, I'm using the following crt_range:

crt_range0                "15525-15800, 49-61, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 216, 294, 448, 576"

But somehow it reports all -interlaced- screenmodes as out of range (see log.txt), any idea what's causing that?

That's a good one. Someone decided that Windows 7 should return the refresh for interlaced modes as refresh / 2. There's some some logic to this: a full frame is only displayed after two vblanks for interlaced modes. However, this frustrates the use of interlaced modes for emulation as long as you intend to use v-sync for timing purposes. I remind Krick actually tested this and v-sync signals where actually reported for a refresh/2 rate.

Now, as you're telling GM your valid vfreq range is 49-61, a refresh reported as 30 will then be considered as out of range. I believe it won't work to change the lower value to 30 as the minimum allowed is 40.

Windows XP reports interlaced modes with their full refresh (i.e 50-60 Hz) and reports 50-60 real sync pulses per second.

As you see, most of the commented issues come from the fact of using W7. These are the little things that, imho, make XP more suitable for custom video than W7, and are too long to explain in a brief XP vs W7 discussion, but you end up stumbling over them as you start doing a serious use of it.

Trying to be fair, I'm not sure if that behaviour has to do with W7 itself or with the newer driver versions, or a combination (driver writters adapting to the new standard dictated by W7). Anyway I know from experience that getting too tied to a dead software technology drives you to ostracism. So after all I'm happy that you're testing this in W7, we might end up figuring out a way so that W7 doesn't suck.

But now I'm looking to wrap a timer around part (2) "emulate_frame", but I'm a bit at a loss where this is called from in the source code and where it ends. Do you maybe have a pointer on that? Any help would be appreciated..

I believe the right place to wrap the "emulate_frame" part is in the machine.c file, around the line 407 ( m_scheduler.timeslice(); )

Let me know how it works.

[Dr.Venom]

Anyway, even when this is fixed in GM, or you decided to swap your cards from slot, GM won't still be able to read/write the registry in W7, this is because it has not the privileges to do it. I think you may give it the privileges running the app as administrator or something.

Indeed, for reading/writing the registry you need admin privileges. It can easily be set for a program, I normally set it in the properties if needed. (See also: http://www.sevenforums.com/tutorials/11841-run-administrator.html)

I'd rather not swap my cards around (needing driver re-install, etc..). So I thought I'd try to hardcode the adapter in the source. This gives some interesting results:

- All modelines are read correctly
- But unfortunately seems to lead to some error while modifying the modelines. Both the Colecovision and SNES do start and run games, but show an error upon quit. Strangely both MSX2 and Genesis quit right away after the info screen. Log for all four attached.

The code I changed in src/osd/windows/switchres.c:
@ ~line 292

Code: [Select]

//while (EnumDisplaySettingsExA("\\\\.\\DISPLAY1", iModeNum, &lpDevMode, 0) != 0)
while (EnumDisplaySettingsExA("\\\\.\\DISPLAY7", iModeNum, &lpDevMode, 0) != 0)
iModeNum++;
@ ~line 530

Code: [Select]

    DISPLAY_DEVICEA lpDisplayDevice;
lpDisplayDevice.cb = sizeof(DISPLAY_DEVICEA);

    //if (EnumDisplayDevicesA(0, 1, &lpDisplayDevice, 0))
       if (EnumDisplayDevicesA(0, 6, &lpDisplayDevice, 0))
(I also added some code to get the DeviceName (\\.\DISPLAY7) displayed, not shown here.)

Did I maybe miss some additional places where the adapter is "hard coded", causing it to quit in the way as described above?

Now, as you're telling GM your valid vfreq range is 49-61, a refresh reported as 30 will then be considered as out of range. I believe it won't work to change the lower value to 30 as the minimum allowed is 40.

Thanks for the pointer. I just thought I'd give it a try and made an adjustment in monitor.c, lowering the limit to 20:

//#define VFREQ_MIN  40
#define VFREQ_MIN  20

And added an additional crt_range to the configs:

Code: [Select]

crt_range0                "15525-15800, 49-61, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 216, 294, 0, 0"
crt_range1                "15525-15800, 24-31, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 0, 0, 440, 580"
And now it reports all interlace screenmodes! Interestingly it shows them as "system modes", example:

Code: [Select]

Switchres: [ 42]  740x 574 @ 25: system mode
but then shows them properly with "i" lower in the log:

Code: [Select]

SwitchRes: [ 740]x[ 574]_[25=25.0000Hz]
   rng(0):  out of range
   rng(1):  740 x 574_25.000i 15.538 [fract] scale(1, 1, 1) diff(0.00, 23.51, -25.1590) ratio(1.285, 1.952)

That's a good one. Someone decided that Windows 7 should return the refresh for interlaced modes as refresh / 2. There's some some logic to this: a full frame is only displayed after two vblanks for interlaced modes. However, this frustrates the use of interlaced modes for emulation as long as you intend to use v-sync for timing purposes. I remind Krick actually tested this and v-sync signals where actually reported for a refresh/2 rate.

With regards to the interlace emulation in Win7. It works a bit different than in XP indeed, but all I can say from past discussion, is that it's quite possible to get a good implementation. Best example is the Amiga emulator WinUAE, which has proper interlace emulation and display on Win 7 with CRT, and even supports on the fly switching when the emulated Amiga is switching between them, for both DD and D3D. That's again in Win 7 with CRT. Not entirely sure, but from what I remember is that Win 7 flags whether it starts displaying the even or odd frame within an interlace frame, making it possible to sync a 50/60 progressive flow from the emulator to those flags. Another possibility is collecting 2 frames (even+odd) at a time within the emulation, before presenting them.

Trying to be fair, I'm not sure if that behaviour has to do with W7 itself or with the newer driver versions, or a combination (driver writters adapting to the new standard dictated by W7). Anyway I know from experience that getting too tied to a dead software technology drives you to ostracism. So after all I'm happy that you're testing this in W7, we might end up figuring out a way so that W7 doesn't suck.

I'm happy that you're willing to research and further improve this. It would indeed be great if we could get it to a point where W7 "doesn't suck"( ), or even better: get it to a point where it doesn't suck at all anymore.
 

I believe the right place to wrap the "emulate_frame" part is in the machine.c file, around the line 407 ( m_scheduler.timeslice(); )

Let me know how it works.

Thanks, I'll keep you posted.

[Calamity]

Hi Dr.Venom,

Forcing halved refresh rates to be accepted is going to fool the modeline routine, so that's not going to work. I guess it's a better approach to do this in get_available_video_modes (switchres.c):

Code: [Select]

mode[k].interlace = (lpDevMode.dmDisplayFlags & DM_INTERLACED)?1:0;
mode[k].hactive = mode[k].a_width;
mode[k].vactive = mode[k].a_height;
                        mode[k].a_vfreq *= mode[k].interlace?2:1;
mode[k].vfreq = mode[k].a_vfreq;
I haven't tested this but it should work. This will also fix the issue of these modes being read as 'system': it seems that Soft-15kHz is properly storing them with the full refresh rate, that's why there's a mismatch and switchres doesn't find the labels in the registry. Now that shouldn't happen. Of course this is W7, so some sort of OS version checking should be added for adding it to GM.

As for the hardcoded device values, it looks you got it right. It seems that it's crashing for some other reason. Try running it with -nomt param, it won't fix it but your logs will be more 'sequential' so you have more chances to find to exact point where it's crashing.

If you have any reference about the interlaced modes in W7 please point that to me, I haven't tested this stuff directly anyway.

EDIT: I fixed the code, you need to change the a_vfreq value too.

Just wanted to add that the problem with W7+interlace is not about emulating systems that originally run interlaced modes, because those are going to run already at 30 Hz. The problem is that we make an intensive use of interlaced modes for running vertical games on horizontal monitors, and for these cases we need the full refresh in order to sync.

[Dr.Venom]

I added the (fixed) code and now it indeed finds the interlaced modes from the soft15khz install (there are three soft15khz interlaced modes in total).

For some reason GM now selects an interlaced mode for the MSX2 resolution 570x294, while that progressive mode is available. See attached log. With the others it's doing it right.

As for the hardcoded device values, it looks you got it right. It seems that it's crashing for some other reason. Try running it with -nomt param, it won't fix it but your logs will be more 'sequential' so you have more chances to find to exact point where it's crashing.

I've turned off the multithreading, but unfortunately that doesn't seem to change anything in the log (see attached).

I've also attached the snes log without multithreading, but that also seems the same. Is there maybe a clue in that with the snes I can start and play a game (Super Swiv for this log), and the error only comes up after quitting the game. While with the MSX, it quits right after the UME info screen (shows a black screen where normally the MSX boot screen gets shown and then quits).

If you have any reference about the interlaced modes in W7 please point that to me, I haven't tested this stuff directly anyway.

I don't have them on top of my head, but I'll keep it in mind.

Just wanted to add that the problem with W7+interlace is not about emulating systems that originally run interlaced modes, because those are going to run already at 30 Hz. The problem is that we make an intensive use of interlaced modes for running vertical games on horizontal monitors, and for these cases we need the full refresh in order to sync.

OK, so if I understand correctly you want to be able to feed a say 60hz ("full refresh") stream into an interlaced display as if it were a 60 hz display,  effectively showing 30 odd and 30 even frames alternating? That should definitely be possible, as I know that the Amiga (and the emulator) doesn't really have 25/30hz interlace, but simply keeps video running at 50/60hz, while only toggling the odd and even (long and short frame) bit of the display chip, effectively displaying it as interlace.

[Dr.Venom]

As for the hardcoded device values, it looks you got it right. It seems that it's crashing for some other reason. Try running it with -nomt param, it won't fix it but your logs will be more 'sequential' so you have more chances to find to exact point where it's crashing.

Did some further tinkering. When I comment out the reset_video_modes() call in line 521 of switchres.c

Code: [Select]

set_custom_video_timing(mode);
}
//reset_video_modes();
return 0;
}
and the corresponding reset_video_modes function definitions in line 40 and 285-296, then it doesn't crash anymore. Interestingly for the MSX2 driver the info screen is still picked as interlace, but then it (correctly) switches to progressive. Looking at the log, everything seems to be working fine (see attached)? But I guess that cannot be. Hopefully this provides a clue to what's happening..



EDIT: I think I found the issue (and fix).

For some reason the EnumDisplaySettingsEx() function is causing the crash. Since the dwFlags parameter of EnumDisplaySettingsEx() isn't used in GM, I guess we can as well use EnumDisplaySettings() in this case. I changed it to the latter and now it runs like greased lightning!

EnumDisplaySettings function http://msdn.microsoft.com/en-us/library/windows/desktop/dd162611%28v=vs.85%29.aspx
EnumDisplaySettingsEx function http://msdn.microsoft.com/en-us/library/windows/desktop/dd162612%28v=vs.85%29.aspx

So the only change that I made is in the reset_video_modes function at line 285 of switchres.c, changing EnumDisplaySettingsExA to EnumDisplaySettingsA

Code: [Select]

static void reset_video_modes(void)
{
int iModeNum = 0;
DEVMODEA lpDevMode;

lpDevMode.dmSize = sizeof(DEVMODEA);

//while (EnumDisplaySettingsExA("\\\\.\\DISPLAY1", iModeNum, &lpDevMode, 0) != 0)
while (EnumDisplaySettingsA("\\\\.\\DISPLAY1", iModeNum, &lpDevMode) != 0)
iModeNum++;
}
(specific for my setup I'm not using DISPLAY1, but DISPLAY7)

I've attached the logs for genesis and MSX2. Everything seems to be working properly. 

[Calamity]

For some reason the EnumDisplaySettingsEx() function is causing the crash. Since the dwFlags parameter of EnumDisplaySettingsEx() isn't used in GM, I guess we can as well use EnumDisplaySettings() in this case. I changed it to the latter and now it runs like greased lightning!

That's great, so the crash is related to the reset_video_modes function. Whenever possible, I'd like to keep with EnumDisplaySettingsEx() as the other one is kind of deprecated. I've just noticed I'm not clearing the DEVMODEA structure before calling EnumDisplaySettingsEx(), so this is possibly the issue. Will you test this for me?

Code: [Select]

//============================================================
//  reset_video_modes
//============================================================

static void reset_video_modes(void)
{
int iModeNum = 0;
DEVMODEA lpDevMode;

memset(&lpDevMode, 0, sizeof(DEVMODEA));
lpDevMode.dmSize = sizeof(DEVMODEA);

while (EnumDisplaySettingsExA("\\\\.\\DISPLAY1", iModeNum, &lpDevMode, 0) != 0)
iModeNum++;
}
The problem with msx res has to do with not using a xres that's 8 multiple:

  rng(0):  570 x 294_50.159p 15.750 [fract] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(0.990, 1.000)

That [fract] there means that it's stretching the picture. The reason is that, internally, GM promotes horizontal resolutions to 8 multiples. So a request for 570 will become 576, but as your predefined resolution is 570 pixels wide, the calculated modeline doesn't fit (570 / 576 = 0.99, see the 'ratio' result).

This was intentional, but it's not a problem when you use VMMaker to create the modelines, because it follows the same criterion. However I see a potential problem here with manually created modelines as this case, so I'll have a look at it. By now it would work just defining that modeline as 576 pixels wide (not big deal).

Thanks again for your work.

[Dr.Venom]

That's great, so the crash is related to the reset_video_modes function. Whenever possible, I'd like to keep with EnumDisplaySettingsEx() as the other one is kind of deprecated. I've just noticed I'm not clearing the DEVMODEA structure before calling EnumDisplaySettingsEx(), so this is possibly the issue. Will you test this for me?

Yes, that fixes it. Works perfectly now with EnumDisplaySettingsEx.

The problem with msx res has to do with not using a xres that's 8 multiple:
[...]
This was intentional, but it's not a problem when you use VMMaker to create the modelines, because it follows the same criterion. However I see a potential problem here with manually created modelines as this case, so I'll have a look at it. By now it would work just defining that modeline as 576 pixels wide (not big deal).

OK. Is there a specific reason for using the 8 pixel multiples? The MSX2 mode has been created from using the Yamaha V9938 (MSX2 video-chip) technical data book, taking the proper timings and border values in account. I've also patched the MSX2 driver in UME with the same values for testing purposes. I guess it's because of the video-chips analog timings that they don't follow a 8 pixel multiple. Anyway, I adjusted the modeline to have 576 pixels and GM does indeed properly pick the progressive mode now.

Thanks again for your work.

My pleasure. I'm glad we could fix the issue. Currently enjoying the automatic refresh rate adjustments in GM .

Hopefully you can bring the non-hardcoded adapter selection into a future update. I now realise that Arcade_OSD might benefit from the same update? (As that's also showing the issue with only integer refresh rates and the "halved" rates for interlace on my setup.)

[Calamity]

Yes, that fixes it. Works perfectly now with EnumDisplaySettingsEx.

That's great, I'll include that fix for next release.

OK. Is there a specific reason for using the 8 pixel multiples? The MSX2 mode has been created from using the Yamaha V9938 (MSX2 video-chip) technical data book, taking the proper timings and border values in account. I've also patched the MSX2 driver in UME with the same values for testing purposes. I guess it's because of the video-chips analog timings that they don't follow a 8 pixel multiple. Anyway, I adjusted the modeline to have 576 pixels and GM does indeed properly pick the progressive mode now.

The reason that we're using 8-pixel multiples is that since the old days, on the low level, video cards work with 'characters' instead of pixels, when programming their internal registers. So if you want to have accurate timing for the different horizontal values, you need use blocks of 8-pixels. Indeed, you can pass the driver a modeline with arbitrary values and it will be accepted, but internally it seems to promote everything to 8-bit multiples judging the results, so I thought it was a better idea to work with that in mind, this prevents us from the risk of accidentaly introducing timing values that are too short as a consequence of rounding errors. I'm not sure, however, how the active pixels value is handled, I mean, that as a fact we can set 570 active pixels, and the drivers will create a frame buffer with that logical width, but internally I believe it still uses 576 pixels wide for timing. I have no idea of how MSX hardware worked, anyway.

Hopefully you can bring the non-hardcoded adapter selection into a future update. I now realise that Arcade_OSD might benefit from the same update? (As that's also showing the issue with only integer refresh rates and the "halved" rates for interlace on my setup.)

Definitely, and hopefully I can count with your help for testing this because I don't have a dual video card setup here.

[Dr.Venom]

Hopefully you can bring the non-hardcoded adapter selection into a future update. I now realise that Arcade_OSD might benefit from the same update? (As that's also showing the issue with only integer refresh rates and the "halved" rates for interlace on my setup.)

Definitely, and hopefully I can count with your help for testing this because I don't have a dual video card setup here.

Yes of course, that would be my pleasure.

[...] this is because it has not the privileges to do it. I think you may give it the privileges running the app as administrator or something.

Indeed, for reading/writing the registry you need admin privileges. It can easily be set for a program, I normally set it in the properties if needed. (See also: http://www.sevenforums.com/tutorials/11841-run-administrator.html)

With regards to setting admin priviliges for GM in Win7 (needed for the automatic modeline refresh rate adjustment),  I found a neat way of having it enabled by default just so that you don't have to manually confirm the UAC prompt everytime you start GM.

By following these two steps it effectively mimics WindowsXP behaviour, i.e. there's no prompt upon starting GM and it can read and write to the registry:

1. Set admin privileges for the GM executable as described in OPTION 5 from this link (as referred to earlier in the quote above): http://www.sevenforums.com/tutorials/11841-run-administrator.html  This will prompt you everytime you start GM to confirm that you want to allow admin priviliges for GM (allow reading/writing to registry).

2. This step allows programs (as configured in step 1) to run in administrator mode *without* bringing up the UAC prompt. Note that it will only allow this option to be set for the administrator account/user. The steps to follow are described on the microsoft forum here: http://answers.microsoft.com/en-us/windows/forum/windows_vista-security/uac-and-one-program-used-very-regulary/67bfc4b5-faff-4de4-be48-f395bf1c519d

 I guess this is another step in figuring out ways so that W7 doesn't suck

Forcing halved refresh rates to be accepted is going to fool the modeline routine, so that's not going to work. I guess it's a better approach to do this in get_available_video_modes (switchres.c):

Code: [Select]

mode[k].interlace = (lpDevMode.dmDisplayFlags & DM_INTERLACED)?1:0;
mode[k].hactive = mode[k].a_width;
mode[k].vactive = mode[k].a_height;
                        mode[k].a_vfreq *= mode[k].interlace?2:1;
mode[k].vfreq = mode[k].a_vfreq;
I haven't tested this but it should work. This will also fix the issue of these modes being read as 'system': it seems that Soft-15kHz is properly storing them with the full refresh rate, that's why there's a mismatch and switchres doesn't find the labels in the registry. Now that shouldn't happen. Of course this is W7, so some sort of OS version checking should be added for adding it to GM.

EDIT: I fixed the code, you need to change the a_vfreq value too.

On more positive notes for the W7 experience, I've been testing the Playstation driver and in *D3D* mode it runs interlace flawlessly and also does the realtime switching between the progressive and interlace playstation modes without problems now!!  DDraw on the other hand bombs out directly with an error when trying to open an interlace screen (see attached logs). Hopefully it can be fixed for DD also.

[Calamity]

Hi Dr.Venom,

With regards to setting admin priviliges for GM in Win7 (needed for the automatic modeline refresh rate adjustment),  I found a neat way of having it enabled by default just so that you don't have to manually confirm the UAC prompt everytime you start GM.

Oh that's very interesting, I guess we should write a little how-to post for W7 users as soon as the specific patches are adder to GM.

There's something that I'm not fully sure yet: are you really getting dynamic modelines working in W7? I mean, from your previous posts it seems that you've really observed it actually working. One obvious test case would be toki / snowbros, same resolution, quite different refresh, in case you can prove they're using the same video mode index and updating with the corresponding modeline. If this is true, then these are *very* good news indeed.

The next interesting thing would be to check if we can fool W7 to use magic resolutions. 

On more positive notes for the W7 experience, I've been testing the Playstation driver and in *D3D* mode it runs interlace flawlessly and also does the realtime switching between the progressive and interlace playstation modes without problems now!!  DDraw on the other hand bombs out directly with an error when trying to open an interlace screen (see attached logs). Hopefully it can be fixed for DD also.

I'm afraid that's the progressive/interlaced switch bug for DirectDraw, and unfortunately I don't believe we can fix that. You're running your desktop at a progressive resolution and that produces the crash when switching to interlace.

BTW, my good-old laptop died last week, I got a new one that comes with W7 (no ATI card unfortunately), anyway I now have system to test generic W7 stuff at least.

[Dr.Venom]

Hi Calamity,

Oh that's very interesting, I guess we should write a little how-to post for W7 users as soon as the specific patches are adder to GM.

That's a good idea. I'm definitely willing to give the how-to post a go once we're sure things are working the way they should.

There's something that I'm not fully sure yet: are you really getting dynamic modelines working in W7? I mean, from your previous posts it seems that you've really observed it actually working. One obvious test case would be toki / snowbros, same resolution, quite different refresh, in case you can prove they're using the same video mode index and updating with the corresponding modeline. If this is true, then these are *very* good news indeed.

I can confirm the very good news, dynamic modelines *are* working in W7 :-). Thanks for providing the testcase with toki and snowbros btw, it's a good testcase. To make it even a bit more extreme I bumped the 256x224 modeline to 62Hz to create an even bigger difference for Toki and especially Snowbros. I have attached the logs for both games. They both run of the 256x224_62Hz modeline, recalibrating correctly to 59.61Hz and 57.5Hz respectively. Both audio and video are fully smooth and the log shows speed at 100%, with no audio buffer issues. Good news indeed  

There are some non-trivial things though about getting the modelines setup properly. At first I was getting sort of random working/non-working resolutions. It was actually quite frustrating at the beginning, because I couldn't seem to find what was causing the erratic behaviour. After a lot of trial and error, I finally found out what steps need to be taken to get things working properly. Disclaimer of course applies, this is work/findings in progress, none of it is actually expected to work without creating new issues ;-) 

There are two non-trivial steps to follow:

1) The number of custom modelines to install must be > 16
If you install say 15 or 16 modelines, they will show up as installed resolutions, but GM will *not* (be able to) do any dynamic refresh rate adjustments. It attempts to switch them, but in fact it's just switching to the predefined soft15khz timings. So for any modeline list that contains =< 16 modelines, the dynamic modelines will not work. It will appear as if dynamic modelines just doesn't work in W7.

2) An extra step is needed for "Activating" the modelines/resolutions.
To get the list from step 1 really working, a number of extra "dummy" modelines need to be installed. It's pretty weird and I'm not sure what the logic behind it is, but for every few modelines that you install above number 16 (say three additional modelines 17-20), the first bunch of modelines from 1-16 become available for dynamic refresh rate adjustment. By adding more "dummy modelines" they all become available.

This probably needs an example. Suppose you want the following list of modelines activated for use with GM:

Code: [Select]

Modeline "256x224_62 15.65KHz 62.15Hz" 5.710 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x240_63 15.65KHz 62.65Hz" 5.710 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "280x224_62 15.66KHz 62.05Hz" 6.090 280 296 328 376 224 234 237 261 -hsync -vsync
Modeline "320x224_63 15.66KHz 62.71Hz" 6.940 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_63 15.66KHz 62.71Hz" 6.940 320 336 368 424 240 242 245 261 -hsync -vsync
Modeline "320x244_63 15.66KHz 62.65Hz" 7.040 320 336 368 424 244 246 249 265 -hsync -vsync
Modeline "352x223_62 15.66KHz 61.61Hz" 7.590 352 368 408 472 223 234 237 261 -hsync -vsync
Modeline "512x224_62 15.65KHz 62.26Hz" 10.920 512 536 584 672 224 234 237 261 -hsync -vsync
Modeline "512x240_62 15.65KHz 62.26Hz" 10.920 512 536 584 672 240 242 245 261 -hsync -vsync
Modeline "544x240_62 16.19KHz 62.05Hz" 11.660 544 568 624 720 240 242 245 261 -hsync -vsync
Modeline "544x242_63 16.19KHz 63.16Hz" 11.960 544 568 624 720 242 244 247 263 -hsync -vsync
Modeline "544x288_52 16.19KHz 52.41Hz" 11.660 544 568 624 720 288 290 293 309 -hsync -vsync
Modeline "656x296_52 16.20KHz 52.44Hz" 13.740 656 688 752 848 296 298 301 309 -hsync -vsync
Modeline "704x288_51 15.81KHz 51.17Hz" 14.800 704 736 808 936 288 290 293 309 -hsync -vsync
This sums to 14 modelines you want to install. As per step number 1, 14 < 16, so none of the modelines will work for dynamic refresh adjustment in GM. Now how to get them working? Answer: install additional "dummy" modelines.

The tricky part is that you just can't fill it up to 16 and have them all working. You actually have to fill it up more > 16. So adding a modeline nr 17 to the list will start to make the first resolutions from the 1-16 list available for dynamic refresh rate adjustments, starting with the smallest resolutions.  Add some more "dummy" modelines and more from the 1-16 list get "activated". (Note that the dummy modelines seem to need at least some resolutions that are larger than the largest ones in the "to be activated list".)

For example in my current modeline list I have added the following "dummies":

Code: [Select]

modeline "744x287_50" 14.21 744 772 840 908 287 290 293 313 -HSync -VSync
modeline "745x286_50" 14.21 745 772 840 908 286 290 293 313 -HSync -VSync
modeline "746x285_50" 14.21 746 772 840 908 285 290 293 313 -HSync -VSync
modeline "747x284_50" 14.21 747 772 840 908 284 290 293 313 -HSync -VSync
modeline "748x283_50" 14.21 748 772 840 908 283 290 293 313 -HSync -VSync
modeline "749x282_50" 14.21 749 772 840 908 282 290 293 313 -HSync -VSync
modeline "750x281_50" 14.21 750 772 840 908 281 290 293 313 -HSync -VSync
modeline "751x280_50" 14.21 751 772 840 908 280 290 293 313 -HSync -VSync
modeline "752x279_50" 14.21 752 772 840 908 279 290 293 313 -HSync -VSync
modeline "753x278_50" 14.21 753 772 840 908 278 290 293 313 -HSync -VSync
modeline "754x277_50" 14.21 754 772 840 908 277 290 293 313 -HSync -VSync
modeline "755x276_50" 14.21 755 772 840 908 276 290 293 313 -HSync -VSync
modeline "704x240_61" 14.80 704 736 808 936 240 242 245 261 -HSync -VSync
I wish there was some clear logic to it. At first I thought every resolution just needed a "shadow" modeline, or that there needs to be two refresh rates per resolution (50/60hz) etc. But it seems none of that.  Maybe these issues can be resolved by further findings/research, and/or adaption of GM, I don't know, but in any case I'm happy that we're having a real "proof of concept" for working dynamic modelines in W7!
 

The next interesting thing would be to check if we can fool W7 to use magic resolutions.

That sounds interesting. I'm not too familiar with the concept of magic resolutions yet. Are there any steps I can take to test it?

On more positive notes for the W7 experience, I've been testing the Playstation driver and in *D3D* mode it runs interlace flawlessly and also does the realtime switching between the progressive and interlace playstation modes without problems now!!  DDraw on the other hand bombs out directly with an error when trying to open an interlace screen (see attached logs). Hopefully it can be fixed for DD also.

I'm afraid that's the progressive/interlaced switch bug for DirectDraw, and unfortunately I don't believe we can fix that. You're running your desktop at a progressive resolution and that produces the crash when switching to interlace.

Ah yes, but I'm also running WinUAE on my setup (site: http://www.winuae.net/ , Git source: https://github.com/tonioni/WinUAE), and it has working progressive/interlaced switching for DDraw (and D3D). So there's a living example of it on my W7 machine. I spent some time in the past with the author testing it, to come out at fully working DDraw progressive/laced switching. It can even do it in realtime as the emulated machine calls for it by adding some lines to the configuration file, like in the example below.

displaydata=25.000000,t=lace,pal,lace,gfx_width_fullscreen=740,gfx_height_fullscreen=574,gfx_linemode=double,gfx_refreshrate=25,gfx_interlace=true
displaydata=50.000000,t=lof,pal,nlace,gfx_width_fullscreen=740,gfx_height_fullscreen=287,gfx_linemode=none,gfx_refreshrate=50,gfx_interlace=false   

So for me it's not a question whether the progressive/interlace switching can work on W7. Maybe we can revisit the topic some time in the future to see whether or not it could be made to work for GM also?

BTW, my good-old laptop died last week, I got a new one that comes with W7 (no ATI card unfortunately), anyway I now have system to test generic W7 stuff at least.

That's great news . Hopefully it will bring the W7 implementation one step closer to its XP counterpart.

Would it be an idea to make a post comparing GM's functionality in XP versus W7, feature wise? That would at least help us to get some idea of where it's lagging and what could possibly still be improved.

[Calamity]

Hi Dr.Venom,

Thanks a lot for your thorough tests, I really appreciate it.

I can confirm the very good news, dynamic modelines *are* working in W7 :-)

These are very good news indeed, that's the most important single feature in order to consider W7 as a real alternative to XP.

There are two non-trivial steps to follow:

1) The number of custom modelines to install must be > 16
If you install say 15 or 16 modelines, they will show up as installed resolutions, but GM will *not* (be able to) do any dynamic refresh rate adjustments. It attempts to switch them, but in fact it's just switching to the predefined soft15khz timings. So for any modeline list that contains =< 16 modelines, the dynamic modelines will not work. It will appear as if dynamic modelines just doesn't work in W7.

2) An extra step is needed for "Activating" the modelines/resolutions.
To get the list from step 1 really working, a number of extra "dummy" modelines need to be installed. It's pretty weird and I'm not sure what the logic behind it is, but for every few modelines that you install above number 16 (say three additional modelines 17-20), the first bunch of modelines from 1-16 become available for dynamic refresh rate adjustment. By adding more "dummy modelines" they all become available.

Well, that's the *exact* behaviour that we have in XP indeed:

http://forum.arcadecontrols.com/index.php/topic,116633.msg1237445.html#msg1237445

I'm quite excited about your findings and how they compare to XP. This 'dynamic' modeline feature is a bit of a mystery to me. The fact that it only works when more than 16 custom modes are defined makes me think that re-reading the registry definitions it's not exactly an intended feature but probably a lucky bug, who knows. But what's important is that the same underlying scheme seems to exist in both systems.
 

The next interesting thing would be to check if we can fool W7 to use magic resolutions.

That sounds interesting. I'm not too familiar with the concept of magic resolutions yet. Are there any steps I can take to test it?

You just need to create a modeline that your system recognizes as, e.g: 1234 x 224 @ 60

The key here is that when GroovyMAME finds in your system a video mode which width is exactly 1234, it assumes the width value is editable. And as the refresh rate is editable too, it turns out that you only need to store a single modeline per height. This allows us to cover most emulation needs with a mode list of just 20-30 indexes.

However the process to obtain a true, say 256 x 224 resolution, out of a 1234 x 224 resolution, although works incredibly well, is based on a rather dirty hack. For the HD 4xxx cards, it only seems to work for Direct3D. Older cards seem to support this trick for both DirectDraw/Direct3D.  I would be extremely surprised that this would work at all under W7.

You can try with a list like this:

Code: [Select]

Modeline "1234x240_60 15.71KHz 59.97Hz" 24.680 1234 1328 1440 1568 240 245 246 262 -hsync -vsync
Modeline "1234x248_60 15.71KHz 59.97Hz" 24.680 1234 1328 1440 1568 248 249 250 262 -hsync -vsync
Modeline "1234x256_60 16.20KHz 60.02Hz" 24.840 1234 1264 1376 1536 256 258 259 270 -hsync -vsync

You'll probably need to remove some of the "normal" modelines to avoid GM picking them.

Ah yes, but I'm also running WinUAE on my setup (site: http://www.winuae.net/ , Git source: https://github.com/tonioni/WinUAE), and it has working progressive/interlaced switching for DDraw (and D3D). So there's a living example of it on my W7 machine. I spent some time in the past with the author testing it, to come out at fully working DDraw progressive/laced switching. It can even do it in realtime as the emulated machine calls for it by adding some lines to the configuration file, like in the example below.

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.

If I remind right you run into issues when trying Arcade_OSD. It's just that it could be a good starting point to test mode switching with that app because it's fully DDraw based. If we can make it work there then it will work in MAME. In theory you only need to drag the app's window to your target monitor and select "Attach OSD...", let me know if it works.

The DirectDraw's code where the problem exists is part of main line MAME, so in case we find a fix for this we should submit the change.

[Dr.Venom]

There are two non-trivial steps to follow:

Well, that's the *exact* behaviour that we have in XP indeed:

http://forum.arcadecontrols.com/index.php/topic,116633.msg1237445.html#msg1237445

Good to know it's the exact same behaviour as in XP, very good news indeed

The interesting part is that I'm using the latest AMD driver for 4800 cards, version 12.6 for Windows 7 64-bit, as released on the AMD site : http://support.amd.com/us/gpudownload/windows/legacy/Pages/legacy-radeonaiw-vista64.aspx. This driver has also been released/updated for Windows 8 (http://support.amd.com/us/kbarticles/Pages/catalystlegacywin8.aspx), which could indicate that the use of dynamic modelines may even carry over to Windows 8.
 

However the process to obtain a true, say 256 x 224 resolution, out of a 1234 x 224 resolution, although works incredibly well, is based on a rather dirty hack. For the HD 4xxx cards, it only seems to work for Direct3D. Older cards seem to support this trick for both DirectDraw/Direct3D.  I would be extremely surprised that this would work at all under W7.

Unfortunately the magic resolutions indeed don't work on Windows 7, at least not with my HD4850 card. I've tested it for both DirectDraw and D3D. In both cases it switches to the 1234x240 resolution, but after modifying the 1234 modeline to 256x240 it still keeps the 1234 resolution open. So for example Snowbros is shown horizontally with a width of say only 1/5th of the screen (log attached).

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, but I'll open a separate thread for it.

The DirectDraw's code where the problem exists is part of main line MAME, so in case we find a fix for this we should submit the change.

Definitely. The good thing is that we already have a live case of DirectDraw and interlace working properly on Windows 7 (WinUAE). So in theory it's now only a matter of investing time and energy before tracking down the issue.

If I remind right you run into issues when trying Arcade_OSD. It's just that it could be a good starting point to test mode switching with that app because it's fully DDraw based. If we can make it work there then it will work in MAME. In theory you only need to drag the app's window to your target monitor and select "Attach OSD...", let me know if it works.

Switching to interlace with Arcade_OSD does not work. When trying to, it returns / keeps displaying the desktop.

With regards to Arcade_OSD functionality, dragging the app to the target monitor and "attach OSD..." does work, as does the refresh rate measurement functionality for all progressive screenmodes. What doesn't work is on the fly editing of the modeline. I'll open a separate thread for the Arcade_OSD functionality issues.

[Calamity]

The interesting part is that I'm using the latest AMD driver for 4800 cards, version 12.6 for Windows 7 64-bit, as released on the AMD site : http://support.amd.com/us/gpudownload/windows/legacy/Pages/legacy-radeonaiw-vista64.aspx. This driver has also been released/updated for Windows 8 (http://support.amd.com/us/kbarticles/Pages/catalystlegacywin8.aspx), which could indicate that the use of dynamic modelines may even carry over to Windows 8.

Ah, I see, they've moved those cards to a legacy support driver, they do that from time to time. In order to create the modded drivers I've always chosen the version right before this branching happens, as a way to get the most modern possible driver for the old cards and at the same time keeping support for the newer cards.

Unfortunately the magic resolutions indeed don't work on Windows 7, at least not with my HD4850 card. I've tested it for both DirectDraw and D3D. In both cases it switches to the 1234x240 resolution, but after modifying the 1234 modeline to 256x240 it still keeps the 1234 resolution open. So for example Snowbros is shown horizontally with a width of say only 1/5th of the screen (log attached).

Oh, those are sad news indeed. I guess they've added a sanity check to for the modeline definitions. I wonder at what point this was added.

I've been trying to recall some of the stuff related to the problem, they are I guess only pieces of the puzzle, but I'll open a separate thread for it.

Do you think the WinUAE creator would mind sharing this information with us?

With regards to Arcade_OSD functionality, dragging the app to the target monitor and "attach OSD..." does work, as does the refresh rate measurement functionality for all progressive screenmodes. What doesn't work is on the fly editing of the modeline. I'll open a separate thread for the Arcade_OSD functionality issues.

I have a slight idea of what the problem with on the fly editing may be, I'll have a look.

[Dr.Venom]

Ah, I see, they've moved those cards to a legacy support driver, they do that from time to time. In order to create the modded drivers I've always chosen the version right before this branching happens, as a way to get the most modern possible driver for the old cards and at the same time keeping support for the newer cards.

Ah yes, that makes sense, especially for single video card setups. Another possibility - in a dual video-card setup - is to install the legacy driver for the 4850 and install the latest driver for the newer video-card. I have the 12.10 driver currently installed for the 7870, and luckily this works like a charm.

I've been trying to recall some of the stuff related to the problem, they are I guess only pieces of the puzzle, but I'll open a separate thread for it.

Do you think the WinUAE creator would mind sharing this information with us?

No I don't think he (Toni Wilen) will mind sharing information with us. It's more of a question whether or not there's a definite anwer as in "do step A and B". These things can easily go back and forth a few times before pinning down the issue. That's why I preferably would like to run down some of the stuff I recollect from some of our discussions first, before approaching him. With any luck there's a clue in the other thread to get it working?

With regards to Arcade_OSD functionality, dragging the app to the target monitor and "attach OSD..." does work, as does the refresh rate measurement functionality for all progressive screenmodes. What doesn't work is on the fly editing of the modeline. I'll open a separate thread for the Arcade_OSD functionality issues.

I have a slight idea of what the problem with on the fly editing may be, I'll have a look.

Great, hopefully that idea proves to be the right one.

[Dr.Venom]

Hi Calamity,

But now I'm looking to wrap a timer around part (2) "emulate_frame", but I'm a bit at a loss where this is called from in the source code and where it ends. Do you maybe have a pointer on that? Any help would be appreciated..

I believe the right place to wrap the "emulate_frame" part is in the machine.c file, around the line 407 ( m_scheduler.timeslice(); )

Let me know how it works.

I've finally come around looking into this. Unfortunately wrapping a timer around the timeslice function doesn't return anything like a frame time. It seems to indeed only return "slices" of the frames, where the slices are mostly taking around 2 microseconds with an occasional 10 microseconds and a very occasional slice of a few milliseconds.

As an example a short piece of the output ("Frametime" is in milliseconds):

Code: [Select]

Frametime: 0.001637 slice nr: 311100
Frametime: 0.001364 slice nr: 311200
Frametime: 0.001091 slice nr: 311300
Frametime: 0.001364 slice nr: 311400
Frametime: 0.001637 slice nr: 311500
Frametime: 0.000818 slice nr: 311600
Frametime: 0.001637 slice nr: 311700
Frametime: 0.001637 slice nr: 311800
Frametime: 0.001091 slice nr: 311900
Frametime: 0.000818 slice nr: 312000
Frametime: 0.001637 slice nr: 312100
I've also been looking into schedule.c where it calls the timeslice function, but my programming skills are too minimal to track if/where it wraps for a complete frame. If you possibly have another idea how/where the frame would wrap then please let me know.  Thanks.