SVGA Monitor Set-up for GroovyMAME

[Jason125]

I really appreciate the outstanding support on this site, especially for 15 KHz monitors.

In addition to a couple NTSC Sony Trinitron televisions, I have a couple SVGA monitors I have been experimenting with GroovyMAME 147u2 running under Windows XP 64. I would really appreciate any help in understanding how to achieve the best possible use of these CRTs under GroovyMAME.

I have extensively searched the forums for information about either double resolutions or ultra wide resolutions, but I am a bit confused about which technique to use. My goal would be to determine if this SVGA monitor can achieve good (not perfect) image quality. I've attempted to use the VGA monitor setting in VMMAKER and the VESA modes in GroovyMAME. In both cases, it seems it is simply doubling the pixels, making it no better than running vanilla MAME with any other computer LCD or CRT.

Please help me understand if it is possible to achieve a similar 15 KHz appearance using this 31 KHz monitor?

The monitor I'm using is a Cornerstone P1750, 22-inch with the attached specifications.

Thank you!

[cools]

My personal preference for that - shove "effect scanlines.png" into your mame.ini file as a starting point.

[Jason125]

Cools,

Is there any way to leverage the 120 Hz rates to somehow "double" the resolutions without seemingly doubling the pixels? I am not sure I am making much sense. Given a 31 KHz SVGA monitor with those ranges listed, is there a way to achieve a similar (albeit imperfect) image to the 15 KHz native resolutions? I would prefer not using HLSL or fake scanlines.

What would the VMMAKER and Mame INI files look like?

I still have the Trinitrons (32" and 24", NTSC only) connected to a TC1600 via VGA to Component on an HD4670, and STILL trying to achieve a good modeline for 240 and 256 line modes at 15 KHz. I really need an expert who has already figured these systems! In the meantime, it would be nice to determine how an SVGA monitor might work, if at all, at 31 KHz.

[cools]

Outside my knowledge. I've used 120hz modes on older emulators and the result looks nothing like an arcade CRT, but almost acceptable on a 13 or 14 monitor.

[Calamity]

Hi Jason,

I agree Cools, using hardware scanlines on a 22" svga monitor won't look very good, because of the fine dot-pitch. I've always used it with "small" monitors, 15" and such. They are also good for 31 kHz arcade monitors, in case they can support 120 Hz.

Anyway. Let's say you start with a preset that creates resolutions for the 31 kHz range:

crt_range0 31400-31500, 49.50-65.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 384, 480, 0, 0

This sample is the default arcade_31 preset. Your particular monitor frequency range is muuuuch wider, but let's use this one for illustration. Now, if you use this preset, you'll notice that GM line-doubles low resolutions... why? This how GM validates modes:

1.- GM first tries to fit the vertical resolution into the ranges we define. In this case, the progressive minimum and maximum lines allowed are: 384-480. So, for a typical 224p@60Hz game, GM will notice it's out of range, and will scale the height until it gets into the range. In this case: 224 x 2 = 448 (line-doubling); 448 turns out to be between 384 and 480.

2.- GM then checks that 60Hz is within the vertical range: 49.50-65.00 -> It is.

3.- Finally, GM checks that 448@60Hz is within the horizontal range: 31.4-31.5 KHz -> It is.

So it validates the mode.

Now, what do we need to force GM to use double refresh rates, and still use 31 kHz? Easy: we halve the number of lines, and we double the vertical refresh range. We know this modification preserves the horizontal frequency:

crt_range0 31400-31500, 99.00-130.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 192, 240, 0, 0

1.- 224p is within [192, 240]? -> Yes
2.- 60 Hz is within [99, 130]? -> No. Here is where frequency scaling happens. GM will try integer scaling of vfreq. It turns out that 60 x 2 = 120 Hz is within the range.
3.- 224p@120Hz is within [31.4-31-5]-> Yes

However, you probably want to keep the possibility to use higher resolutions for some games when required. So what we do is to create two ranges, one for low resolutions and another one for high resolutions:

crt_range0 31400-31500, 99.00-130.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 192, 240, 0, 0
crt_range1 31400-31500, 49.50-65.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 384, 480, 0, 0

That's all you need for mame.ini side (also, remind to set 'monitor custom' for these ranges to work)

Defining the ranges in GroovyMAME is easy, but notice that if you do so, GroovyMAME expects 192p - 240p resolutions to actually exist in your system, otherwise the range defined for those heights will be ignored. So you need to create the required modes first with VMMaker. The problem is, VMMaker is not updated yet to use the new crt_range format, so we need to define the ranges in a slightly different way:

monitor_specs0 15600-15800, 49.50-65.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 240, 384
monitor_specs1 31400-31500, 49.50-65.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 480, 768

Notice this will actually create 15 kHz resolutions for the low-res modes. Don't panic. GM will transform those into 31 kHz on the fly, when you use the crt_ranges above. It's just that we need to specify the range like this to persuade VMMaker to generate these low resolutions. I'm sorry it's a somewhat cumbersome process, hopefully I'll update VMMaker soon to use the same convention as GM and it will be much easier.

[Jason125]

Calamity,

Thank you very much for the detailed explanation. I am still a bit confused about the second modeline (49.50-65.00)  for GroovyMAME. With both modelines enabled, games like Metal Slug run in 640x480x59. The image is too sharp and essentially looks like any version of MAME with no scanlines and blocky graphics. However, if I disable the modeline with "49.50-65.00" then all games run with beautiful scanlines and look almost arcade perfect! In the case of Metal Slug, the modeline generator is choosing (320x224@117). Mortal Kombat runs at (1280x240p@109.630) with medium scanlines, but the image is somewhat compressed.

As you probably know, this seems to apply the "doubled refresh rate" to everything, rendering games like Macross Plus or Pac Man really ugly. I've also tried other vertical games like 1945k III and they include the scanlines (progressive) and appear to be almost square in dimensions. This is going to sound confusing, but when I re-enable the second modeline, 1945k III stretches properly top-to-bottom (856x480p@60) and looks almost perfect, with a faint smoothing effect (not blocky or too sharp).

Soooo, in an ideal scenario we would use the (99.00-130.00) modeline when an authentic arcade-like image is desired (after tweaking, I presume). The second modeline needs to be adapted to allow vertical games like 1945k III to use than instead. Is this only a situation with vertical games? It needs to be modified to force games like Metal Slug to use the first modeline, otherwise they run at (640x480p@59). Strangely, games like Mortal Kombat (mk) look good even with the second modeline enabled, running at (856x480@54.71) and the image appears to be almost aliased. Perfect geometry all around, which has been an elusive goal using the NTSC television.

I hope this makes sense. I really do appreciate all your time and willingness to help. As much as I struggle to learn the science behind all of this, I really am looking forward to being done "tweaking" and actually enjoy playing some games someday.

[Jason125]

Ok, after more testing I am absolutely impressed with how well these modelines are progressing. Thank you Calamity for posting them!

This seems to be a relatively inexpensive, easy method to achieve near-arcade image quality using common SVGA computer monitors, assuming they support the higher frequency. I'm especially impressed I have not needed to mess with any geometry settings at all, despite launching various games with different requirements.

For horizontal games which are under 640x480, I am finding that I must disable the "crt_range1" modeline for GroovyMame 147u2 to display the game with scanlines. I had to step back when I saw this, as I am so used to being up close to the CRT for computer use, as the scan lines look large until you step back a few feet then they look amazing. I can't wait to find a real arcade monitor someday, it really is the holy grail! both 240 and 256 line modes look fantastic, although I am still torn whether Mortal Kombat looks better with or without scanlines.

For vertical games, disabling this second modeline nearly always results in a terrible image. Enabling both modelines results in a fantastic image for these games, including tdragon2 (400x384 @ 56) and pacman (856x480 @ 60.61). I wish I had a capability to take pictures, but the resulting image has faint  scan lines which I presume are similar to how a "real" arcade monitor should look.

As a result of these two extremes, it would be absolutely fantastic if there is a method to allow the great scan line modes for horizontal games from the first modeline (99-120) with the excellent image quality for vertical games provided by the second (49.5-65).

Strangely, after making some small tweaks, most games seem to be cooperating with both modelines enabled, for both horizontal and vertical games:
crt_range0 31000-38000, 99.00-130.00, 0.940, 3.770, 1.990, 0.349, 0.064, 1.017, 0, 0, 192, 240, 0, 0
crt_range1 31000-38000, 49.50-65.00, 0.940, 3.770, 1.890, 0.349, 0.064, 1.017, 0, 0, 384, 480, 0, 0

I am still seeing some strange behavior with some games like R-Type, running at 856x480 @ 55.02 using the above lines. Although the image looks much better than vanilla MAME running on a LCD (blocky), the image seems to exhibit a SuperHQ sort of aliasing or blurring. Not terrible, but not exhibiting the more "authentic" appearance with larger scanlines apparent when disabling the second crt_range. The image is perfectly centered on screen, so really happy to see that after struggling to get my Trinitron to evenly cut the image! The image quality after disabling this second crt_range is quite nice, running at 1280x240 @ 110.04. But still a mystery how we might achieve this "scanline-enabled" mode for all horizontal games below 640x480, but not for vertical games

Thank you!

[cools]

R-Type doesn't scale 2x to <480 lines.

[Jason125]

Cools, not sure what you are referring to. Using the two modelines above, I obtain different images on this SVGA multisync monitor, each generated differently by the GroovyMAME modeline generator. In the case of R-Type, the two resolutions mentioned are selected by GM depending on whether I disable the second modeline or not.

It is apparent that lower resolutions do generate some nice hardware scanlines, which is great for many horizontal games. But for others, especially vertical games, this results in a terrible image. Enabling the second modeline somehow allows many of these to display nicely, without the lower resolutions producing hardware scanlines on this monitor.

A compromise is needed, if possible, to support both. The image quality is really nice! I could see how this could be put into a cabinet as a cheaper alternative to an arcade monitor if desired.

Thanks!

[cools]

Neither of the modes you've mentioned are suitable for rtype, because it runs in a resolution that has more than 240 lines.

[Jason125]

Sorry Cools, forgot to mention I didn't choose those resolutions. They were chosen by GM directly based on enabling one or both of the modelines Calamity posted. Believe it or not, both look pretty good on this SVGA multisync monitor, and everything fits. So further refinement of the modeline would be great to help those using 31 KHz SVGA monitors in their cabinet. But My real goal is to get my Sony Trinitron TVs to display the native resolutions properly.

I have two I'm seeking help configuring with the best modelines for 240 and 256 line games. a KV-32FS100 (BA-5D chassis) and a KV-24FS100 (BA-6 Chassis). Both connected to a TC1600 with component cables, and VGA to a VGA/DVI adapter on my HD 4670 card using Windows XP 64, GM 148u2. Would love to achieve a complete monitor specs (like other arcade monitors) to build modelines which will display all types of games in their native glory!  Will update my other thread as I work through this.

[Calamity]

Hi Jason,

Cools is pointing you in the right direction. The aim of my post above was to provide you with the basic concepts so you can progress with the crt_ranges (NOT modelines!!) until you find the right ones. Those crt_ranges (specs, for short) are not by any means complete, they were a starting point.

See that 256 lines is not contained in either one of them: [192, 240] ,  [384, 480]. It falls somewhere in the middle of both.

So you need to extend the first range so it contains 256, for instance: [192, 256].

crt_range0 31000-38000, 99.00-130.00, 0.940, 3.770, 1.990, 0.349, 0.064, 1.017, 0, 0, 192, 256, 0, 0

[Jason125]

Cools and Calamity,

Thank you for trying to help me understand this, and guiding me in the right direction.

So I am slowly absorbing the basics of how GroovyMAME (and VMMaker) operate, and it really seems like pure genius. Using my 31 KHz CRT as a guide (and the specs above), it seems as if the CRT_Specs line is simply "describing" the video characteristics of the CRT to the modeline generator in GM. In a perfect scenario, if the correct CRT information is entered, all modes generated *should* appear on the screen in their native glory, assuming the CRT is capable of displaying the full range.

For a 31 KHz computer CRT like this one, we've been really fortunate with the CRT_specs line above which uses a vertical refresh range of 99.00-130.00. With only this mode enabled, the correct resolutions are being selected, while doubling the vertical refresh. So with the change suggested, and disabling the other CRT_Specs line, R-Type launches with a native resolution of 384x256 @ 55.02 but the switchres generator creates 384x256 @ 110.04, exactly double as you stated.

What is interesting about this CRT is how lower resolutions display hardware scanlines (right term?). I still need to experiment to determine exactly what the cutoff is (maybe below 640x480?), and also determine how to adjust the CRT_specs so vertical games do not use the resolutions which result in hardware scanlines, as they look pretty bad. As a test, I enabled both crt_specs lines in mame.ini and 1942 (native 224x256 @ 60) starts with 400x256 @ 120. As this is below the proposed 480 vertical limit, it does still have scanlines. However, 1945kiii (native 224x320 @ 60) results in 856x480 @ 60.

Am I on the right track? I'd like to practice on this SVGA monitor, then adapt my newfound knowledge to the Trinitrons when completed. IT seems very apparent I need some detailed information about the CRT and processing in those models to provide the correct crt_specs line to GroovyMAME. I will scour the forums for a walkthrough of how to proceed with this process (unless you can point me there sooner). I think the reason why a SVGA multisync monitor seems more flexible is we have the option to double vertical frequency, whereas an arcade monitor (or just TV) is much more limited in allowable frequencies, and therefore flexibility.

Thank you!

[cools]

I've got no knowledge of the internal bits of Groovy, but if you're using a genuine 31Khz monitor you're stuck at 480lines or less.

If it's SVGA then you're likely to be able to go above 31K, and therefore be able to get 512lines and flawless R-Type.

Knowing the specifications of the monitor is the key part. 31Khz = 480 lines, there's no getting around it. The line Calamity has given you is from 31khz-38khz.

[Calamity]

Hi Jason,

I've been testing my SVGA CRT monitor today and came up with these ranges:

crt_range0 30000-70000, 100.00-160.00, 2.201, 0.275, 4.678, 0.063, 0.032, 0.633, 0, 0, 192, 320, 0, 0
crt_range1 30000-70000, 50.00-80.00, 2.201, 0.275, 4.678, 0.063, 0.032, 0.633, 0, 0, 400, 1024, 0, 0

These allow vertical games up to 320 pixels wide (lines when rotated) to display with hardware scanlines (double refresh). A good exaple is donpachi.

Vertical games that result in 384 lines height, like mazinger, are moved to the second range here, so they are displayed with normal refresh, but fortunately they get beyond the 30.00 kHz lower boundary so there's no need for line doubling and they look natural.

Interestingly enough, my monitor won't accept 384-line resolutions. That's why I have the gap there from 320 to 400. So I need to use resolutions above 400, where 384 lines fit leaving black borders up and down. Then the resolution can easily be adjusted using the monitor's OSD to make it fit the screen.

So those two ranges are enough to show any game at the intended resolution in my system.

Your monitor allows much higher horizontal frequencies (up to 140 kHz!!). However, there won't be much benefit in defining such high frequencies for gaming purposes.

There's a drawback however in the double frequency technique. You won't get smooth scrolling anymore. Well, the real problem is that scroll doesn't look smooth because displaying each frame twice introduces motion blur. A good test case is szaxxon.

We've been experimenting in the last months with black frame insertion, a trick that restores smooth scrolling to its full glory when using double refresh rates. Have a look at this thread: http://forum.arcadecontrols.com/index.php?topic=130710.0

Black frame insertion is a required complement if you're serious about running your games at double refresh rates. You can try with a test build we did: http://www.aburamushi.net/calamity/groovymame32_0.148_120Hz.rar

Be aware that this build assumes you're running everything at double refresh rates, so it's just of use in that case (i.e. if you run a game at 60 Hz it will run at 50%).

Just make sure to enable -syncrefresh if you're going to test this version.

We still don't support black frame insertion officially in GM, however it will be added as an option in future builds.

You'll notice a slight flicker and the picture will get somewhat dimmer, but it definitely looks more authentic.

[Jason125]

Thanks Calamity!!

I modified the first monitor spec to add 384 lines, just as a test:

crt_range0 30000-70000, 100.00-160.00, 2.201, 0.275, 4.678, 0.063, 0.032, 0.633, 0, 0, 192, 384, 0, 0

The native specs for mazinger are 240x384 @ 57.55 and GM chose 432x384 @ 115.10. It worked well, but I did need to adjust my OSD to shift the picture up to center. I'm having a similar problem with other games with these settings, where the picture is shifted a bit too much to the left. I think I can play with things in ArcadeOSD to determine the right Horizontal settings to include in the CRT_specs to shift everything to the right.

[Jason125]

Calamity, forgot to ask whether I should modify the VMMaker specs too, or leave them as is and use these spec lines in mame.ini only?

Thank you!

[Calamity]

Hi Jason,

You don't have to run VMMaker again unless you miss some resolutions that should be there. Otherwise, GM will be enough to modify the timings dynamically to your specs.

[Jason125]

Calamity,

Almost everything runs perfectly, thank you!

I am having a problem with Tekken (and maybe others I haven't tried yet). This game is running at 172 percent for some reason. Log attached, and mame.ini.

[NightSprinter]

As far as the screen for some games being too far to the left, you'll have to adjust the horizontal front and back porches as Calamity had me do in Linux.  He's better at explaining it than I am.

[Jason125]

Thanks NightSprinter. I just tested another game which I hadn't before, Darius (and some sequels). All of them seem designed for three monitors lined horizontally. Each appears to be 288x224 @ 60, but lined up, GM tries to use 1024x768 to accommodate all of them, resulting in a very clear, but vertically squished image (attached).

I don't think any crt_spec will help me with this one!

[NightSprinter]

I think the team was also working on extra features for down the road like this and system linking (as some arcade games could link up or had to be linked up for multiplayer).

[Jason125]

Calamity,

In light of the new 148u5 release, are there any suggested changes to the spec lines for VMM or GM? You mentioned the workaround earlier, just wanted to see if this release changes that.

Thank you!

[Maccy]

Black frame insertion is a required complement if you're serious about running your games at double refresh rates. You can try with a test build we did: http://www.aburamushi.net/calamity/groovymame32_0.148_120Hz.rar

Be aware that this build assumes you're running everything at double refresh rates, so it's just of use in that case (i.e. if you run a game at 60 Hz it will run at 50%).

Just make sure to enable -syncrefresh if you're going to test this version.

I've tried it and GrovvyMAME pick the correct resolution, 512x224@120,19 in wboy case, but the game runs at 200%. I've enabled syncrefresh and disabled throttling and multiprocessor support. Is there any other setting to check before diving deep in logs and monitor/crt specs analysis?

[Calamity]

Hi Maccy,

Are you really using the special build linked above, and enabling the -strobe option?

[Maccy]

Hi Maccy,

Are you really using the special build linked above, and enabling the -strobe option?

I think so...At the moment I cannot check, later I will try again. In any case the build downloaded from this site works as expected:

http://www.blurbusters.com/software-based-black-frame-insertion-improves-motion-clarity-in-mame/

Meanwhile I've done several experiments on another front: since I play only a few MAME games, I've removed all the custom resolutions produced by CRT_emudriver via WinModelines (since I've not discovered how to force switchres to generate a "doubled" refresh rate) and I'm redoing them from scratch but I don't understand why I cannot adjust them via ArcadeOSD and no, I'm not trying to adjust vertical size , just horizontal size/position and vertical position. I tried to increase-decrease front-back porch but it doesn't seem to make any difference, even using "extreme" values. Obviously I'm doing it on supported (resolutions not supported are set to hide) custom resolutions. Is there any requirements in software/hardware configuration for using ArcadeOSD?

Thank you in advance

[Calamity]

Hi Maccy,

I know it sounds odd, but dynamic modelines don't work unless the drivers are "loaded" with at least 17 custom modelines. I bet this is the problem you're seeing. Try creating extra dummy modelines until you get a list of 17 or more, and you'll be able to edit modelines dynamically with ArcadeOSD again.

[Maccy]

Hi Maccy,

I know it sounds odd, but dynamic modelines don't work unless the drivers are "loaded" with at least 17 custom modelines. I bet this is the problem you're seeing. Try creating extra dummy modelines until you get a list of 17 or more, and you'll be able to edit modelines dynamically with ArcadeOSD again.

You're right, it worked! There is some special case like 856x640@122hz that won't move/resize but, until now, it is the only case where it didn't work.

Thank you

[Calamity]

You're right, it worked! There is some special case like 856x640@122hz that won't move/resize but, until now, it is the only case where it didn't work.

Thank you

Maybe 856x640 is currently used by the desktop?

[Maccy]

Maybe 856x640 is currently used by the desktop?

The desktop is set at 800x600@120.

[Maccy]

Another difficulty that I've encountered is when I've tried to define different refresh for the same custom resolution. ArcadeOSD let me set size and position for all the resolutions and all the refreshes without problem, but MAME seems to ignore the additional refreshes for the resolution defined. Example: I've defined 256x224@118, 256x224@119,  256x224@120 and MAME accept only the latest defined (latest in time terms, as if it was available only one refresh for a custom resolution and every new refresh added overwrite the previous one). Before producing the custom resolutions from scratch and doing something wrong again, is there any limit that I must consider? Should I define 256x224@120, 258x224@119, 260x224@118 or something like that?

Thank in advance

[Calamity]

Hi Maccy,

This happens because as long as GroovyMAME can override your defined refresh with its custom settings, which is the case with custom resolutions made by VMMaker, it's just the same for it to pick either 256x224@118 or 256x224@120, because it will override the refresh with its own settings anyway. It will just happen to pick the first one that's reported by Windows. That's the idea behind "dummy" resolutions, the ones you create with VMMaker when you use a dynamic mode table: you just need to define one instance of each resolution with a dummy refresh.

[Maccy]

ok, thank you very much and keep up the very good word.

[Maccy]

Wonderful. I've tried several values of back/front porch in MAME.ini and I've managed to "abandon" ArcadeOSD, MAME strobe build by BlurBuster and static custom resolution approach: now I use GroovyMAME with switchres and it's very cool.

There is one thing left that is not running at 120hz and it's asteroid. I've attached the log. I wanted to run it 640x480@120hz. Is it possibile?

P.S. Do you think you will update GroovyMAME to 0.150 with strobe patch (just to use new HLSL feature on vector games)?

[Calamity]

Hi Maccy,

Yes, GroovyMAME is picking 720x768 because that provides a better resolution for vector games, and from GroovyMAME's point of view (which is shared by me ) this is a better choice. If you want to force 640x480@120 Hz, it is still possible by using an .ini file:

Code: [Select]

resolution 640x480@60
You can name it 'asteroid.ini' to apply it just to this game, or 'vector.ini' for all vector games.

Notice that I wrote 640x480@60 rather than 640x480@120. That's not a mistake. You must use the mode marked as 'custom' whatever its label is. GroovyMAME will do its job by promoting it to 120 Hz.

[Maccy]

Since I'm using strobe patched GroovyMAME 720x768@60hz causes Asteroid to run only at 50% so this is why I need to run it @120hz. Ok, I will try to force it in vector ini since Battle Zone has the same problem.

Thank you as usual, i will report here the results of my tests.

[crispux3]

3.- Finally, GM checks that 448@60Hz is within the horizontal range: 31.4-31.5 KHz -> It is.

I've been reading a lot about timings and trying to learn as much as I can to try to calculate timings for my monitor, but I'm not understanding how 448@60Hz is within 31.4-31.5 Khz. Could you explain this? Is the formula 448x60x1.05? This would give around 28-29 Khz wouldn't it? I'm confused. Help is appreciated.