Switchres: modeline generator engine

[Calamity]

mayne its a bug in the n version that doesnt show correct version but it is n

Yes, probably. Anyway, in your donpachi log:

SwitchRes: Entering switchres_modeline_setup (0)
SwitchRes: Monitor: D9800 Orientation: horizontal Aspect 4:3
SwitchRes: MonitorLimits 15250.00-15700.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,448
SwitchRes: Setup monitor limits min=184x108 max=0x608

... it says D9800 but you only have a range available ("monitorlimits"), you should have several ranges there. Then when selecting the resolution it's doing this:

SwitchRes v0.012m: [donpachi] (1) vertical (320x240@57.55)->(432x320@57.55)->(664x496@57.55)
SwitchRes: # donpachi 664x496@57.55 15.4523Khz

So it's virtualizing the resolution as if it was a cga monitor, however you have your 432x320 resolution available and ready for use:

SwitchRes: 432 x 320 -> 0.00 Custom Modeline

So it must be a silly bug, I'm sure this has worked for me before some time ago, if you feel like testing with older versions here they are:
http://mario.groovy.org/GroovyMame/0142/Archives/

anyway I'd wait until this can be fixed.

[bent98]

Ok

Tried it with version A of groovymam 142 and it works alot better but donpachi small center and small and still looked interlaced. dkong looks great but had some sound stutter.
 I guess ill wait for new version and i can test more.

[Calamity]

Sound stutter can be fixed with -soundsync enabled. However the fact that you have sound stutter means groovymame is not getting the right refresh for that particular game when it should be doing if you have a multisync monitor like yours.

[bitbytebit]

the D9800 is the problem, needs to be loewcase d9800.  it's defaulting to cga cause of that

[Calamity]

  good to hear that, I knew it had worked for me before!

[bent98]

Wow!!!

Everything works great now. I did not have to set pixel clock to 7.5 it works fine set at 0 default.

Do I have to also change to lowercase d9800 in the VMMaker.ini also?

Is there a way to get rid of nag screen before launch rom?

[bent98]

Also, I cant run Hyperspin. I knew there was a bug with it but I thought that was anything over then 120 modelines?


IS there a way to use less modelines so I can still use Hyperspin?

[Calamity]

Those are good news, so your X1950XT can work with low dotclocks, good to know.

VMMaker will convert all params to uppercase anyway so you don't need to change it.

I think there's an option in Mame.ini to get rid of nag screens, just need to confirm.

Yes, the Hyperspin issue... what matters is the total amount of video modes in the system, not just modelines, so CRT_Emudriver 6.5 was restricting anything but its modelines, so with 160 modelines Hyperspin will still load, but this 9.3 version is not restricting anything because its patch is different so it has its 120 modelines plus the native ones in the system. So you could play with the TotalModes param in VMMaker reducing it and recalculating modelines. But doing that many of your games will not use their best possible resolution. Probably Hyperspin needs to reserve more memory to store the total list of video modes in the system, Hyperspin author said he would check that for version 2.0.

[bent98]

Is there a way to remove native resolutions above 1024x768 in the 9.3 driver? My monitor is not capable of doing that and there is about 20+ resolutions I will never use? I can't use the 6.5 driver on my card.

Right now using the 9.3 driver I have to set number of modlines to 70 for Hyperspins to work and it runs sluggish. Hyperspin 2.0 is not going to be out for atleast another 4 months so I want to come up with a workaround before then.

[bent98]

I aso forgot to tell you. I tried Missile Command and monitor could not sync. Txt dump attached

[bent98]

Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file

[Calamity]

Is there a way to remove native resolutions above 1024x768 in the 9.3 driver? My monitor is not capable of doing that and there is about 20+ resolutions I will never use? I can't use the 6.5 driver on my card.

Well there's no way as the restricted resolutions via registry is disabled in 9.3 due to the patch, and I thought it can be handy to have them there in case someone needs to plug a lcd or even use the driver in a multi-monitor system.

Right now using the 9.3 driver I have to set number of modlines to 70 for Hyperspins to work and it runs sluggish. Hyperspin 2.0 is not going to be out for atleast another 4 months so I want to come up with a workaround before then.

I see, unfortunately there's nothing I can do about that, I wish I could, I even tried to patch Hyperspin myself but saw it would require a debugger and lots of hours of my time and maybe won't achieve it. Maybe the author could drop a quick fix for it if there's real interest.

I aso forgot to tell you. I tried Missile Command and monitor could not sync. Txt dump attached

That game uses 256x240 resolution, please try that one with Arcade_OSD to make sure it works, that one has a low dotclock.

[bitbytebit]

Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file

What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.

[bitbytebit]

Yeah I think that misslecommand resolution dotclock and that radeon card probably don't mix, would need to set a higher dotclock minimum probably.

[Calamity]

Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file

What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.

Well this is odd:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

I remember frogger used to work fine, will test again with this version.

[bitbytebit]

Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file

What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.

Well this is odd:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

I remember frogger used to work fine, will test again with this version.

It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

[ves]

Hello, bitbytebit, I've been watching what the wiimote, and I have compiled 140 with mame lightgun option works well, the only downside I've seen is that when setting the wiimote create / dev / input / eventX and if it does not recognize Xorg will have to restart X, or at least on ubuntu 10.10, not if it happened in Gentoo, these events are created when you configure the wiimote, and do not stay saved.

I've also tried to groovymame 142, I can compile but not work, I do not know C + +, you might look at you or Calamity?

I attached the files and modified.

Also attached the modified files mame normal 142, I think the problem is over here as I had to modify it to compile.

Code: [Select]

static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
   



Thanks.

[Calamity]

It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...

[bitbytebit]

Hello, bitbytebit, I've been watching what the wiimote, and I have compiled 140 with mame lightgun option works well, the only downside I've seen is that when setting the wiimote create / dev / input / eventX and if it does not recognize Xorg will have to restart X, or at least on ubuntu 10.10, not if it happened in Gentoo, these events are created when you configure the wiimote, and do not stay saved.

I've also tried to groovymame 142, I can compile but not work, I do not know C + +, you might look at you or Calamity?

I attached the files and modified.

Thanks.

Interesting, so this makes it work better with mame?  Yeah since mame moves so fast in the core infrastructure and API would doubt this will still work from 140 -> 142, a lot has changed .  I'll have to look at this, does the author of the changes plan on keeping it updated?  I'll have to see how intrusive they are, I keep my patches mostly outside in separate files from the main mame code, at least as little as possible, so updating the patches isn't as painful between mame versions.  At least reduces some of the trouble of updating, reapplying patches by hand, etc.  I'll look at this closer later and see how it works.

[ves]

I am attaching the files for mame 142 normal, to do the patch away from the rest as you say, so it will be better if someone just wants to suck the wiimote.

Have you asked the mamedev, if would be interested to deploy your patches in mame?

Code: [Select]

static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
  



Thanks.

[bitbytebit]

No my patches are not a patch that should go into or would be accepted into the main mame.  It's better for me since it's a work in progress, and the mame developers goals are not to focus on the output to arcade monitors.  Also by being in separate files, most other patches can fit right on top of mine easily since the line numbers should mostly match up still for patch utilities.

I am attaching the files for mame 142 normal, to do the patch away from the rest as you say, so it will be better if someone just wants to suck the wiimote.

Have you asked the mamedev, if would be interested to deploy your patches in mame?

Code: [Select]

static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
  



Thanks.

[bent98]

It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...

I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

Also I found setting in mame.ini to disable nag screen.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

[bitbytebit]

It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...

I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

Also I found setting in mame.ini to disable nag screen.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

Try frogger with the monitor type set to cga, instead of d9800.  I get a feeling it's possibly a horizontal frequency range issue.  Not all d9800 monitors are exactly the same tuning, basically Wells Gardner sets up the ranges in the factory and they can be off just slightly I guess.  So I am thinking that yours can't handle the 18khz area very well, mine can't handle the 20khz area, so it's at least near and mine does a similar thing in the 20khz area yours is doing around 18khz.  It's a guess at least, does pacman have issues there?  Try to find any other games that trigger the issue and see in the verbose output if what the khz is for them.  Definitely something I didn't fully expect, but the black hole area as I call it in the khz range may just be slightly different for  every d9800.  If your able, take the MonitorLimits lines for the d9800 (from the log outputs, there's 4-5 of them)  and use the groovymame -monitor_specs0 (there's 0-6 possible ones, similar to how the -resolution0 cmd line options work) options to put each of the ranges in manually.  Then you can change the ranges around, for the khz, and possibly move the 'blackhole' range. 


15250.00-18000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448
18001.00-19000.00,40.00-80.00,2.187,4.688,6.719,0.140,0.191,0.950,0,0,288.0,448
20501.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768
29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768
32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768
34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768

Basically those are them above, try changing or removign the 18001.00 one, even then after that lowering the 15250.00-18000.00 one to use 15250.00-17000.00 in the line. 

So in mame, you'd use...

 -monitor_specs0 15250.00-17000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448 -monitor_specs1 20501.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768 -monitor_specs2 29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768 -monitor_specs3 32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768 -monitor_specs4 34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768

That command line, converting it to mame.ini syntax, might be interesting.  Possibly you can squeeze down the range to only around 18khz and include 20khz there too, would be interesting to see exactly what your d9800 can do and compare it to mine.  Mine can't go above 38khz without getting weird, maybe yours can go all the way to 40khz, and the range is about 2khz off of mine (and mine can go below 15khz, to 14.9 actually, but I don't do that since it just seems wrong, but I think it can handle it, like it's shifted down and yours might not be).

[Calamity]

I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

The frogger issue is really strange as it works fine for me with the exact same resolution, so in my case the surface has the right size (see my logs) but not in yours, I have no clue of what can be happening.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

Yeah there is a way by using the DALRestrictedModes registry key but that one is disabled by the patch I did for the particular version 9.3 you're using, I remember there was a good reason for it, anyway I'll consider re-enabling it in a future version. As a general rule, there's nothing bad in having those modes that are the native ones of the driver, someone might need to use them, indeed I use those in my desktop computer where I have the same drivers installed. Anyway, the bug here is on Hyperspin side.

[bitbytebit]

Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

[bent98]

I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

The frogger issue is really strange as it works fine for me with the exact same resolution, so in my case the surface has the right size (see my logs) but not in yours, I have no clue of what can be happening.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

Yeah there is a way by using the DALRestrictedModes registry key but that one is disabled by the patch I did for the particular version 9.3 you're using, I remember there was a good reason for it, anyway I'll consider re-enabling it in a future version. As a general rule, there's nothing bad in having those modes that are the native ones of the driver, someone might need to use them, indeed I use those in my desktop computer where I have the same drivers installed. Anyway, the bug here is on Hyperspin side.

IS there anything else I should try for the frogger bug? I wasnt an issue with cabmame.

As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.

[Calamity]

Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

The interesting part is here:

My logs:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 224x256
DirectDraw: blit surface created: 224x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels

bent98's logs:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels

[Calamity]

As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.

Actually it does not work like that exactly, what I do is to use the DALRestrictedModes space to store my extra custom modelines, that's what it's convenient to get rid of that.

Well, if you really want to try it, I'll upload a modified version for you, be aware you'll need to reinstall the driver, I may have it today.

[Calamity]

As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.

Actually it does not work like that exactly, what I do is to use the DALRestrictedModes space to store my extra custom modelines, that's what it's convenient to get rid of that.

Well, if you really want to try it, I'll upload a modified version for you, be aware you'll need to reinstall the driver, I may have it today.

Yeah I remember now why it was necessary to remove the restricted modes functionality. I've tried to leave the restricted modes option enabled and each time I select a custom modeline I get a blue screen. To explain it simple: regular Catalyst let you define 60 Custom Modes + 60 Restricted Modes. What I do is to patch the driver so I have 120 Custom Modes + 0 Restricted Modes, modifying the relative pointers. It's a damned hack, but it works, as long as we don't need any Restricted Modes. But unfortunately 120 custom modes added to the native mode list turns out in an unusual amount of available modes in the system, that should not be a problem unless a given program does not reserve enough space to retrieve the system mode list and is overflowed by that (btw a bug that's really easy to fix in 15' if you have the source code).

So I'm afraid the only workaround for HS by now is to define less video modes and bear with the non-so-accurate results

I wish I could be of more help with this, I know HS is a great frontend and many people on this board are using it, and probably these people will refuse to use my drivers because of this.

[bent98]

Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?

[bitbytebit]

Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?

Just try the cga monitor type I guess, it doesn't seem to be anything to do with the other stuff I was thinking though.  It's confusing since Calamity saw that one difference in the log output so not sure what is going on.  It doesn't make sense that it's doing the odd resolution size at the end like that, but throughout the rest of the log it is right.  It seems to be something specific to the Windows OSD, at least I'm guessing that, Calamity might be able to see more of what exactly it's doing to have that odd resolution calculation for the blitting part.  Is the mame.ini freshly generated, just thinking that maybe there's some option setting that could cause it to change the blitting size, but still seems very unlikely that would be the cause either.   

[Calamity]

Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?

He means in mame.ini, you actually don't need to generate new modelines. It would be interesting to try h9110 monitor type in mame.ini, as that's my setup, where frogger works fine.

I'd like to be able to reproduce your frogger issue here. What's your desktop resolution?

Edit: The issue might be related with function compute_blit_surface_size(win_window_info *window) in drawdd.c.
After all I wanted to have a look at this at some point, as I couldn't fix the issue with ghouls when run with doubled resolution and I think there's a problematic aspect ratio checking hidden somewhere in the windows side.

[bent98]

800x600

[Calamity]

800x600

Good. Please change it to 640x480 and test frogger again... just an experiment.

[bent98]

DirectDraw: Mode selected =  640x 480@ 60Hz
DirectDraw: primary surface created: 640x480x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

when setting mame.ini to cga

[bent98]

800x600

Good. Please change it to 640x480 and test frogger again... just an experiment.

DirectDraw: Mode selected =  480x 480@ 60Hz
DirectDraw: primary surface created: 480x480x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
RawInput: APIs detected
Input: Adding Mouse #1: Microsoft USB IntelliMouse Optical
Input: Adding Gun #1: Microsoft USB IntelliMouse Optical


this is 640x480 d9800 setting

[Calamity]

this is 640x480 d9800 setting

Thanks a lot for testing. I wonder where those 472x957 come from. You won't happen to have a second monitor plugged? It's so strange.

[bent98]

no

[MonkeyJug]

new chassis on the way!

http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326

can't wait to start tinkering again!

hopefully this will resolve my polarity problems as well...

[Calamity]

new chassis on the way!

http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326

can't wait to start tinkering again!

hopefully this will resolve my polarity problems as well...

Great news!
Hopefully we have better luck with this one!