New GroovyMAME user :)

[MK]

Hello everyone,

Wow, it's been a long time since I last visited BYOAC.
I am pleased to see the forums are active and new software being developed such as GroovyMAME.
So, big thank you Calamity and everyone else involved in this nice little project.
I tried GroovyMAME for the first time yesterday and I am very happy with the results.

Before GroovyMAME I used AdvanceMAME 0.106, another excellent piece of software, but as you know quite outdated.
That was the reason I upgraded from Win98, Blade15 (with Trident Blade T64), AdvanceMAME to WinXP, CRT_EmuDriver (with Ati Radeon 9250), GroovyMAME.

I wanted to say THANK YOU and share with you a few (minor) issues after the upgrade.

My setup:
* Old PC with Ati Radeon 9250 AGP
* Generic 15.75 KHz arcade monitor (horizontally oriented)
* J-PAC as the interface for video and inputs.

First issue is about how GroovyMAME chooses the modeline for some games.
It happens with games which require more than 256 lines, for example with Ms Pacman which requires 288 lines.
I know these kind of games where designed for vertically oriented monitors and if my monitor had that orientation it would be easy for GroovyMAME to create the modeline. But on my setup it needs to rotate the image, which means it needs a modeline with 288 true lines at 60 Hz, which is not possible with the standard 15750 Hz horizontal frequency.
I first tried (with the monitor set to generic_15) and it created a modeline with 288 lines but at 51 Hz.
I wanted GroovyMAME to create a modeline with different resolution as long as it keeps the refresh rate at 60 Hz, and I did find a way to achieve that by customizing the "ProgressiveLinesMax" and "InterlacedLinesMax" presets (with the monitor set to custom).
Basically I limited the lines to 256 for progressive scan modelines and to 512 for interlaced scan modelines:

crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 256, 448, 512

Then I tried enabling and disabling the interlace option for the different results.
With interlacing disabled it looked quite bad (because of the low resolution of course) although the refresh rate was ok.
With interlacing enabled it was better (again with the correct refresh rate) but it lead to another problem which I knew it would happen and I'll explain next.

Second issue, about interlaced scan modelines and the flickering.
There is not much information about this on the Internet, and if it wasn't for AdvanceMAME I would have always thought the flickering was intrinsic to the interlacing technique, but it isn't.
The problem lies on how my arcade monitor (and probably many more) handle the interlacing.
Mine basically display the lines in the incorrect order, and AdvanceMAME had an option to overcome this problem.
You can read more about it in the AdvanceMAME documentation here: http://advancemame.sourceforge.net/doc-advmame.html#8.5.3
The option is called display_interlaceeffect and my monitor needs what AdvanceMAME tells "swap even rows" for the image to look good, ie. display_interlaceeffect even.
So, I would like to know if you knew about this problem, and if it would be possible for GroovyMAME to provide such feature.

As I said, I consider this minor issues. I'm very pleased with GroovyMAME as it is, but I wanted to share my experience and if one day GroovyMAME had such feature, it would make those of us (ok probably just me?) even more happy.

Thank you for reading and again thanks to everyone everyone involved in the development of GroovyMAME.
And thanks everyone who contribute to this awesome forum, too.

[krick]

It's not possible to 288 lines at 60Hz on a low-res arcade monitor (unless you go interlaced, which often looks bad).
Don't bother trying to create or modify the modeline.  You're wasting your time.

If you run at 51Hz and synchronize the emulation with the refresh rate, the game runs too slow and the music pitch will be wrong.
If you run at 51Hz and don't synchronize the emulation with the refresh rate, the music should be ok, but you can get visual tearing.

The solution is to run without sync, but enable triple buffering.

Try enabling multithreading.  This will enable triple buffering automatically when needed.

You can enable it globally in your mame.ini, or you can create per-game ini files and enable it as needed.

This assumes that your CPU has dual cores (I'm not sure if Hyperthreading alone is enough).

[MK]

Thanks for your reply but I don't want the game to run slower than intended. And I don't want GroovyMAME to stretch down the image either, so I guess the only possibility left is to crop the upper and lower parts of the screen.

I'll let you guys know if I can achieve it with a combination of settings.

About interlacing, beleive me that the flickering goes away with AdvanceMAME "display_interlaceeffect even" option, at least with my arcade monitor. Of course it doesn't look as sharp as progressive scan and the scroll in vertical games don't run as smoothly, but there is no flickering (at least what I understand by flickering).

[krick]

Just try something for me.  Create a clean mame.ini file by running...

groovymame.exe -cc

...Then open the mame.ini file in a text editor and change the multithreading setting to 1 and save

Then run pacman and let me know what you think.

Note that you will have to adjust the vertical size adjustment on your monitor so that the top and bottom of the image is entirely on the screen.  There's no way to avoid that.

[MK]

Ok tried it, interesting results.

The refresh rate is different but the speed of the game is ok.
I notice some frames are being dropped, making the game a little jerky, but probably better than my idea of cropping the image with a 256 lines modeline.

I would still like to compare both options, though. Because I'm not very comfortable with the idea of messing with the vertical size of the monitor. Besides it would not apply for games with more than 288 lines.

The only obstacle now is I am not being able to try my idea
I want to limit the number of lines to 256 maximum and disable shrink of the image.
Is this possible?

Thanks for your help krick!

[MK]

One more question.

Is it possible to tell GroovyMAME I want the refresh rate to have priority over the resolution?

Because for example for the game Terra Cresta it could have created a modeline with 240 lines at 60Hz rather than a 256 lines modeline at 57Hz, and only 16 lines wouldn't have been visible (not big deal).

Thanks!

[Calamity]

Hi MK,

Congratulations for figuring out the custom crt_range thing by yourself, things like this make me recover my faith.

Unfortunately GM is not exactly designed to do what you want, probably because its design is biased by my own opinion on how people should setup things.

Basically GM does never crop games. Its main premise is that the frame must fit in the resolution, otherwise it will stretch it until it fits. GM will always try to go for a progressive mode despite the refresh. If you want to priorize refresh then you must lower ProgressiveLinesMax, as you already did.

I'd say you can still use the internal ui to vsize the frame so it gets cropped up and down, but this must be done manually and there might be some nasty artifacts, not sure.

[MK]

Hi Calamity,

Congratulations to you for the job you've done with GroovyMAME.
Everything has been pretty much straightforward in terms of understanding how it works.
I would have expected different behavior when the perfect modeline can't be generated, but definitely not a major issue since there's no absolute truth about what's best.

If you ask me, I'd prefer GroovyMAME to choose the exact refresh rate rather than the resolution first, and I'd never shrink the image, or maybe offer some kind of tolerance on how many lines the user is ok with being left out, and decide to shrink or crop based on that tolerance, but that would probably be too complicated to implement.

Or, now that I think about it, why not have control over resizing? It'd be very powerful if one could switch it on and off for both possible scenarios (shrinking and enlarging). E.g. I'd always leave shrinking off and enlarging on. (Please refrain from taking that last sentence out of context, thank you )

But after all, what really bothers me is that if iterlaced modes didn't look so bad, we wouldn't be discussing any of this.
Are you familiar with the problem I described on my first post about the order of the lines being drawn incorrectly by some arcade monitors?
I'm beginning to suspect many arcade monitors have that problem and people incorrectly blame interlacing for the poor image quality.

[haynor666]

You could force GM to crop by switching to ddraw and disabling hardware stretch.

[MK]

Hey haynor666, it works.
The only problem is when GroovyMAME creates modelines with larger resolution in the X axis, which causes the image to be very narrow.
However it's interesting how using ddraw with hwstretch enabled blurs the image, it's an alternative to d3d and shrinking.

Thanks for your help.

[haynor666]

I use this method to cut picture in Battle Rangers (PCE game). This uses 1088x242 but it has black bar on left. I simply set 1024x240, ddraw and centered picture in mame menu and that's it.

The same maethod I use with cidelsa games where all games have enabled incorrect (in my opinion) stretching and should use 256x240 instead 294x294.

[krick]

I use this method to cut picture in Battle Rangers (PCE game). This uses 1088x242 but it has black bar on left. I simply set 1024x240, ddraw and centered picture in mame menu and that's it.

The same maethod I use with cidelsa games where all games have enabled incorrect (in my opinion) stretching and should use 256x240 instead 294x294.

Are these problems due to GroovyMAME picking the wrong resolutions, or are they a problem with core MAME having the wrong resolution coded in the driver?
Because if it's the latter, you might be able to change the code and compile your own GroovyMAME and get better results.

[Calamity]

MK, you can use the -aspect option to modify the width of vertical games. E.g -aspect 4:3 is normal, 3:3 is square, 3:4 is full screen, or any intermediate value.

[haynor666]

Cidelsa games are mame problem but pce (Battle Rangers) emulation is probably correct (console added black border on left to center picture on TV) so ither you play with black border or re-center game inside mame. Since my TV does not have option to resize horizontally (I know it's weird) I'm forced to find other methods forcing this game to work with lower resolution.

[MK]

In the end I'm most comfortable with the following changes to mame.ini:

monitor                   custom
interlace                 0
crt_range0                15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 256, 448, 512
multithreading            1
video                     ddraw
hwstretch                 1

It consists of the standard arcade monitor preset with the "ProgressiveLinesMax" set to 256, interlaced modes disabled, video set to ddraw and hardware stretch enabled.

In my opinion this is the best way to play vertical games rotated, because even though pacman (and every game with a number of lines between 256 and 288) look awesome progressive scan, the refresh rate is way off, causing the game to run slow/jerky, not to mention you need to adjust the monitor settings for the image to fit in the screen.

With the above customization, the slowliness/jerkiness for 288 lines games (pacman, ms pacman) or above is gone as groovymame realizes it's best to pick a low resolution at 60hz rather than a higher resolution at a slower refresh rate, and it's "almost" perfect for 256 lines games (donkey kong, terra cresta, raiden) because it creates a modeline with the exact resolution at slower refresh rate but not that slow (around 57hz) causing the game to be a little jerky but hardly noticeable.

The purpose of ddraw with hardware stretch enabled is for games with more than 256 lines to look better on lower resolutions, take for example pacman which has dots, with d3d on a 240p modeline it looks pretty bad, dots are not square and the characters look pretty bad... with ddraw and hwstretch it looks more blurry but better in my opinion.

It would be totally awesome if one could have control over the stretching options with d3d (for cropping) and most importantly to be able to tell groovymame if one prefers the refresh rate to have priority over the resoluton, but once again I want to say, groovymame rocks as it is (10/10)... if it supported something like that then it would be an 11 out of 10 because all this stuff I'm talking about is somewhat out of scope because I am expecting vertical games to look perfect on an horizontal monitor which is basically, impossible.

And then there is this problem with arcade monitors and interlaced scan showing lines in an incorrect order, which is either not that common or nobody cares... but I think of addressed, those of us with this problem would benefit from it either by groovymame taking care of it (something like advancemame's display_interlaceeffect option), or the video drivers taking care of it, which would be totally awesome since for the Windows it's more reasonable to use a high resolution like 640x480.

So, again thanks everyone for your help.

I hope the settings we shared here helps someone with the same preferences like me.

Cheers,
MK

EDIT: Forgot to include the multithreading customization in mame.ini

[big10p]

Interesting thread!

I bumped into this problem with interlaced modes, today i.e. they jiggle up/down badly, and look awful. A user on another forum has informed me it's an issue he gets with his Hantarex monitors (same as mine), but doesn't on his WG ones. Not sure what Hantarex monitors do differently, but there you are.

P.S. Thanks for the awesome groovyMAME, Calamity! 

[krick]

I bumped into this problem with interlaced modes, today i.e. they jiggle up/down badly, and look awful. A user on another forum has informed me it's an issue he gets with his Hantarex monitors (same as mine), but doesn't on his WG ones. Not sure what Hantarex monitors do differently, but there you are.

I have a Hantarex Polo 25 and was experiencing more-jittery-than-normal interlaced resolutions, but only when using my ArcadeVGA, and only with the ArcadeVGA drivers installed.  I reported this issue to Andy at Ultimarc and he released an updated driver that fixed the issue.

More info:  http://forum.arcadecontrols.com/index.php/topic,111107.0.html

[big10p]

I bumped into this problem with interlaced modes, today i.e. they jiggle up/down badly, and look awful. A user on another forum has informed me it's an issue he gets with his Hantarex monitors (same as mine), but doesn't on his WG ones. Not sure what Hantarex monitors do differently, but there you are.

I have a Hantarex Polo 25 and was experiencing more-jittery-than-normal interlaced resolutions, but only when using my ArcadeVGA, and only with the ArcadeVGA drivers installed.  I reported this issue to Andy at Ultimarc and he released an updated driver that fixed the issue.

More info:  http://forum.arcadecontrols.com/index.php/topic,111107.0.html

I don't have an arcadeVGA, unfortunately. I'm using a Radeon with CRT emudriver. I also just read that the issue can apparently be fixed with a resistor between the ground and sync pins; on a Polo monitor, at least.

[big10p]

Well, I tried various resistors between the sync/GND pins but it made no difference. 

I'd really love to get this issue sorted. As the Hantarex MTC 9000 is a very common arcade monitor, has anyone (without an arcadeVGA card) found a fix for this?

[Calamity]

Well, I tried various resistors between the sync/GND pins but it made no difference. 

I'd really love to get this issue sorted. As the Hantarex MTC 9000 is a very common arcade monitor, has anyone (without an arcadeVGA card) found a fix for this?

Well I'm familiar with that chassis and had never had an issue. However I remind seeing it on some friend's cab, also one MTC 9000 or 9110. There was a nasty comb effect with interlaced modes, using the same modelines that I use.

What I'd do is: launch an interlaced mode with Arcade OSD, enter the modeline edit menu, and try to play with the vertical values, specially with "vertical total". The reason for this is, interlaced modes are always calculated with an odd number of lines, as this is required to make sure both fields are shifted by 1/2 line. Try to increase the vertical total to an even value instead. If that works, I'll add that workaround to GM. If it doesn't work, it could be because ATI drivers are already promoting "vertical total" to an odd number internally so there's nothing that can be done from the software side. The only solution would be to reorder the lines by software as suggested above, a solution I'm a bit skeptic about and would be quite difficult to implement on current MAME.

[big10p]

Well, I tried various resistors between the sync/GND pins but it made no difference. 

I'd really love to get this issue sorted. As the Hantarex MTC 9000 is a very common arcade monitor, has anyone (without an arcadeVGA card) found a fix for this?

Well I'm familiar with that chassis and had never had an issue. However I remind seeing it on some friend's cab, also one MTC 9000 or 9110. There was a nasty comb effect with interlaced modes, using the same modelines that I use.

What I'd do is: launch an interlaced mode with Arcade OSD, enter the modeline edit menu, and try to play with the vertical values, specially with "vertical total". The reason for this is, interlaced modes are always calculated with an odd number of lines, as this is required to make sure both fields are shifted by 1/2 line. Try to increase the vertical total to an even value instead. If that works, I'll add that workaround to GM. If it doesn't work, it could be because ATI drivers are already promoting "vertical total" to an odd number internally so there's nothing that can be done from the software side. The only solution would be to reorder the lines by software as suggested above, a solution I'm a bit skeptic about and would be quite difficult to implement on current MAME.

OK, I'll give that a try. Thanks.

[big10p]

Some success! 

I changed the V Total for the following modes, which has much reduced the jiggling:
2560x448@60i - changed to 560 from the default of 521
2560x512@59i - changed to 570 from the default of 555
2560x544@55i - changed to 610 from the default of 587
2560x560@54i - changed to 620 from the default of 603

I've set V Total to even values but setting them to odd values (say 1 less than I've used), the jiggle is still gone. I also had to alter the Vertical Geometry to re-centre the modified modes.

There is still some slight jiggle/flicker, but I can't tell if this is the normal amount for interlaced modes, or if something is still slightly off.

What would be the easiest way to get GroovyMAME to use these modified modelines (I only use Super Resolutions)? Will I need to manually copy the modeline to an ini file for each game that uses an interlaced mode?

Thanks for your help again, Calamity. This issue has been bugging me for a while, now. 

[big10p]

There is still some slight jiggle/flicker, but I can't tell if this is the normal amount for interlaced modes, or if something is still slightly off.

Having inspected it more closely today, I think something is still slightly off. Looks like some horizontal scans are slightly too high/low, or something. Most noticeable on text - kind of looks like there's a blank scanline running through the text.

The H sync pin on my monitor is connected to the video sync on the edge connector, and the V sync monitor pin isn't connected to anything. I assumed this is because it was using composite sync on the H sync pin. Is this right?

[Calamity]

The H sync pin on my monitor is connected to the video sync on the edge connector, and the V sync monitor pin isn't connected to anything. I assumed this is because it was using composite sync on the H sync pin. Is this right?

That's only true if you're doing something to actually output composite sync (using a JPAC, using Winmodelines to enable c-sync for ATI cards, wiring both lines together, etc.).

[big10p]

The H sync pin on my monitor is connected to the video sync on the edge connector, and the V sync monitor pin isn't connected to anything. I assumed this is because it was using composite sync on the H sync pin. Is this right?

That's only true if you're doing something to actually output composite sync (using a JPAC, using Winmodelines to enable c-sync for ATI cards, wiring both lines together, etc.).

I'm using a JPAC so I guess my wiring is OK. Just wondered if it had something to do with the interlace problems I've been having.

So, what I describe in my above post is normal for interlaced modes? The pics don't show it very clearly, really. Some lines in the display flicker/jiggle slightly, while the majority are rock solid...

[Calamity]

I'm using a JPAC so I guess my wiring is OK. Just wondered if it had something to do with the interlace problems I've been having.

The composite output of the JPAC has good quality so that's not the problem.

So, what I describe in my above post is normal for interlaced modes? The pics don't show it very clearly, really. Some lines in the display flicker/jiggle slightly, while the majority are rock solid...

It's hard to tell from your pictures. All interlaced modes flicker and you can notice it more on single-line horizontal details, like the frames inside window dialogs, etc. You know your interlaced modes are not working properly when you can actually appreciate that the line order is altered, what causes a sort of nasty double picture. I'd say I can see it on the top of the "e" in "[Yres]", but I can't be sure if it's that or rather an effect of the picture.

Anyway, if increasing the "vertical total" did help to some extent, and it is not a matter of odd/even number of lines, I think I have a theory of what's going on. It might be happening that the components are aged and because of this the raster takes longer to reach the top of the screen at retrace time (longer than in my MTC 9110), and it also takes longer to stabilize once there before drawing the frame. Because the quality of the interlace relies on exact length of the first line, if this length is abnormal it might produce a disalignment of the fields.

If you want to use that modified timings in GroovyMAME, just create a customized crt_range using the H9110 one as a base and go incresing the vertical back porch until to see it works.

[MK]

Seems like big10p's arcade monitor has the same problem as mine (or similar).
If you want to confirm this, try AdvanceMAME customizing the display_interlaceeffect using its different options and see if the problem is solved.
On my monitor, AdvanceMAME with the setting "display_interlaceeffect even" makes the problem go away.
Unfortunately this feature is only available in AdvanceMAME, not in any other MAME derivative, nor any video driver that I know of (not even the SVGAWIN driver which was done by Andrea Mazzoleni).

[big10p]

So, what I describe in my above post is normal for interlaced modes? The pics don't show it very clearly, really. Some lines in the display flicker/jiggle slightly, while the majority are rock solid...

It's hard to tell from your pictures. All interlaced modes flicker and you can notice it more on single-line horizontal details, like the frames inside window dialogs, etc. You know your interlaced modes are not working properly when you can actually appreciate that the line order is altered, what causes a sort of nasty double picture. I'd say I can see it on the top of the "e" in "[Yres]", but I can't be sure if it's that or rather an effect of the picture.

That's it, exactly. You can also just see it on the top of the letters in "Mode Number". Sort of looks like the scanline here is scanned at the right position for one scan, and then one line too high up on the next scan. So, just the top line jiggles up/down slightly, while the other lines scanning the text are stable, with just the usual slight shimmer associated with interlacing.

Anyway, if increasing the "vertical total" did help to some extent, and it is not a matter of odd/even number of lines, I think I have a theory of what's going on. It might be happening that the components are aged and because of this the raster takes longer to reach the top of the screen at retrace time (longer than in my MTC 9110), and it also takes longer to stabilize once there before drawing the frame. Because the quality of the interlace relies on exact length of the first line, if this length is abnormal it might produce a disalignment of the fields.

That makes sense, although my monitor has had new caps and lopt at some point in it's life.

If you want to use that modified timings in GroovyMAME, just create a customized crt_range using the H9110 one as a base and go incresing the vertical back porch until to see it works.

Trouble is I will need a different vertical back porch value depending on mode. Unless I'm misunderstanding what you mean?

Seems like big10p's arcade monitor has the same problem as mine (or similar).
If you want to confirm this, try AdvanceMAME customizing the display_interlaceeffect using its different options and see if the problem is solved.
On my monitor, AdvanceMAME with the setting "display_interlaceeffect even" makes the problem go away.
Unfortunately this feature is only available in AdvanceMAME, not in any other MAME derivative, nor any video driver that I know of (not even the SVGAWIN driver which was done by Andrea Mazzoleni).

I'll give this a go as an experiment, and report back. Thanks.

[big10p]

I tried advanceMAME but the svgawin driver wouldn't load. Guess it's too old to be compatible with win7 and/or my GFX card. Without svgawin installed, I can still run games but changing the display_interlaceeffect had no visable effect.

[MK]

I tried advanceMAME but the svgawin driver wouldn't load. Guess it's too old to be compatible with win7 and/or my GFX card. Without svgawin installed, I can still run games but changing the display_interlaceeffect had no visable effect.

Sorry for not having been specific, you won't be able to achiveve the effect from Windows AFAIK.
The only way is with AdvanceMAME for DOS (or Linux but I've never tried it) so you need either DOS or Win95/98.
Or maybe it will be easier to just apply the effect to an image, display it full screen and see the result.
Effect is explained on the AdvanceMAME docs, see link on my first post.

[big10p]

I tried advanceMAME but the svgawin driver wouldn't load. Guess it's too old to be compatible with win7 and/or my GFX card. Without svgawin installed, I can still run games but changing the display_interlaceeffect had no visable effect.

Sorry for not having been specific, you won't be able to achiveve the effect from Windows AFAIK.
The only way is with AdvanceMAME for DOS (or Linux but I've never tried it) so you need either DOS or Win95/98.
Or maybe it will be easier to just apply the effect to an image, display it full screen and see the result.
Effect is explained on the AdvanceMAME docs, see link on my first post.

Ah, OK. TBH, I don't think these effects would solve the problem, anyway. Most of my display is fine, just the occasional scanline seems to jiggle from it's correct position, to one too high on the next scan. Can't really take a photo to show the exact effect, as it needs to be seen to appreciate it.

[MK]

Ah, OK. TBH, I don't think these effects would solve the problem, anyway. Most of my display is fine, just the occasional scanline seems to jiggle from it's correct position, to one too high on the next scan. Can't really take a photo to show the exact effect, as it needs to be seen to appreciate it.

The first screenshot you posted looks similar to my windows desktop at 640x480 (with some scanlines in the wrong order) and I see the jiggle as well so... I think there are two problems involved: 1) the scanlines order which can be solved; and 2) the jiggle which can't be solved but on my case is hardly noticeable once the first problem has been solved.

If I have some free time this weekend I'll try to look into this a little bit further.

[big10p]

Thanks for the offer MK, but I think Calamity is right saying an old/tired monitor component is causing this. What makes me so sure? Well, something strange happened just now when I went to my cab to test something...

So, I left my cab on today for several hours, with the back door in place, in order to test an overheating issue I have with my MAME PC's PSU. I left it running Robotron (in a progressive mode). When I came back to it, the screen had gone out of sync. I adjusted the H and V sync pots, but couldn't get a stable picture, so I quit back to the desktop (688x512i mode). Not only was the image stable, but the minor interlacing issues I had were gone - it looked great!   

I ran through all the interlaced modes in arcadeOSD and they looked fine, too! As a final test, I turned off modeline generation in GroovyMAME and ran DoDonPachi... it looked amazing! I can't even tell it's running in an interlaced mode unless I look VERY, VERY closely.

I can only conclude that the increased heat generated inside the cab has caused some component to start functioning fully. Which component it is, I have no clue. It can't have been adjusting the H and V sync pots that sorted it because that was the first thing I tried.

I'm betting when I turn my cab back on tomorrow when it's cold, the interlacing issue will be back (at least until it warms up for a good while). Anyway, looks like the mystery is solved... I think. 

[MK]

The only place I've found where they discuss something similar is in the advancemame-users mailing lists.
Nothing absolutely clear has been said but something could be useful for further investigation:

http://sourceforge.net/p/advancemame/mailman/message/9131015/

[big10p]

Seems like they figured it was a problem with the monitor, too. Someone had 3 identical monitors - 2 worked fine and 1 flickered in interlace mode...

Just wish I knew what component causes this.

[adder]

Just wish I new what component causes this.

randy fromm might have some ideas, but it might be a bit hard to get a response from a guy like that

[big10p]

<erroneous post removed>

[big10p]

Well, I've fitted new caps but it's made no difference.

Clutching at straws here, but wondering if the socketed controller IC could have anything to do with the bad interlacing? Seems it controls all the syncing etc. The one on my chassis is a Phillips TDA2595V9. There seem to be a few versions of this chip. Maybe mine's bad or I need a different chip? 

[frisnit]

Hmm, I see the same interlace-like problem and also have an MTC 9000 from what I can tell (with an old ArcadeVGA).

With DOS AdvanceMenu on my previous setup (PC broke, so new setup) it usually booted up with the jittering, but generally running a MAME game and quitting out would make the jittering go away (8/10) and I could play on.  But with GM, AdvanceMenu and games like Black Tiger and 1942 jitter constantly, whereas Bubble Bobble is always solid.

I tried various ini options and mucking about blindly with modelines in the Linux build to see if I could force a resolution, but no joy so far.

[frisnit]

Hmm, I see the same interlace-like problem and also have an MTC 9000 from what I can tell (with an old ArcadeVGA).

With DOS AdvanceMenu on my previous setup (PC broke, so new setup) it usually booted up with the jittering, but generally running a MAME game and quitting out would make the jittering go away (8/10) and I could play on.  But with GM, AdvanceMenu and games like Black Tiger and 1942 jitter constantly, whereas Bubble Bobble is always solid.

I tried various ini options and mucking about blindly with modelines in the Linux build to see if I could force a resolution, but no joy so far.

Just a note that my constant jitter went away once I upgraded to GroovyArcade-Arch2015.02.15-x86_64 (I had been using GroovyArcade-Arch2013.02.24-i686 as I didn't think the CPU was 64-bit!), so was possibly some arcade monitor/graphic card detection issue. It's thankfully now back to the occasional jitter as before (can usually cure it by start/stopping games until it fixes itself), but I'll dig further to see what that might be (mame cabinet has done it all the time I've owned it). Possibly monitor cap, IPAC  or monitor settings related.