Is there some calculator to find the porches for a given scanrate/refresh range?

[Gray_Area]

Mine are 15-48khz; 55-65hz.

[Calamity]

1. Why does one have to put in the porches and all that/why isn't the pixel clock (range) enough like it was in AdvanceMAME?

You don't need to put in any porches actually, you can just go with any of the monitor presets. Think of porches as the size of the picture's borders. By finding the correct values for your specific CRT, you make sure all the modes will get automatically centered.

AdvanceMAME didn't need this because it just worked based on predefined reference modelines. The porch values where "extracted" from these modelines to produce new ones, by interpolation. This usually resulted in nearly correct modelines, but that's not guaranteed when using this method.

The method used by VMMaker/GroovyMAME ensures that each element of the resulting modeline has the correct size, by checking these values individually.

2. How does one find out what the porches should be? Is there some calculator you can put in the scanrate and refresh and it'll spit them out??  (Mine are 15-48khz; 55-65hz)

The easiest way is to use Arcade_OSD to find the values interactively. One would start by displaying some standard arcade modeline, which will be more or less off depending on the case. Then, entering the geometry menus in Arcade_OSD and tweaking the modes until you get a perfect fit. Then, all the needed porch/sync values corresponding to this adjustment will be presented in a column on the right. Finally, you write this values down and use them as feedback to build the monitor_specs line that will tell GroovyMAME how to create modelines that are similar to the one you just adjusted.

For your particular case (15-48kHz), you'll probably need to divide that range in several intervals where different porch/sync values apply. What kind of monitor is that?

[Gray_Area]

1. Why does one have to put in the porches and all that/why isn't the pixel clock (range) enough like it was in AdvanceMAME?

You don't need to put in any porches actually, you can just go with any of the monitor presets. Think of porches as the size of the picture's borders. By finding the correct values for your specific CRT, you make sure all the modes will get automatically centered.

AdvanceMAME didn't need this because it just worked based on predefined reference modelines. The porch values where "extracted" from these modelines to produce new ones, by interpolation. This usually resulted in nearly correct modelines, but that's not guaranteed when using this method.

The method used by VMMaker/GroovyMAME ensures that each element of the resulting modeline has the correct size, by checking these values individually.

2. How does one find out what the porches should be? Is there some calculator you can put in the scanrate and refresh and it'll spit them out??  (Mine are 15-48khz; 55-65hz)

The easiest way is to use Arcade_OSD to find the values interactively. One would start by displaying some standard arcade modeline, which will be more or less off depending on the case. Then, entering the geometry menus in Arcade_OSD and tweaking the modes until you get a perfect fit. Then, all the needed porch/sync values corresponding to this adjustment will be presented in a column on the right. Finally, you write this values down and use them as feedback to build the monitor_specs line that will tell GroovyMAME how to create modelines that are similar to the one you just adjusted.

For your particular case (15-48kHz), you'll probably need to divide that range in several intervals where different porch/sync values apply. What kind of monitor is that?

This is similar to the manual method (xclock) to AdvanceMAME. I tried the manual method, but found the auto to work just as, well without the work. I was hoping GroovyMAME had gotten to this point. Hmmmmm.......

[Calamity]

Well, I admit that having some sort of 'auto' option would be an interesting add-on.

It's just that in the arcade world there's no standard specification you can trust. They used to have the same problem in the PC industry, that's why they created the VESA standard, where porch values and sync pulses are calculated out of some well defined formulas. There's nothing like that for arcade monitors.

Anyway it would be possible to gather a bunch of safe enough values for different frequencies, in order to build an 'auto' option as you suggest, that in the worst case at least produces a viable picture, provided the frequency is supported by the monitor.

This 'auto' option would work better or worse depending on how picky one monitor is. Probably some professional CRTs like the NEC Multisync may admit almost anything they're fed with, others definitely will need a big amount of manual tweaking if fed with 'standard' values (the reason behind custom monitor_specs is to eliminate the need for manual tweaking between modes in arcade monitors).

[Gray_Area]

I no longer have a page of info on this monitor, though I don't think it had porch data. The NEC XM preset might work, except that monitor goes up to 64khz.

[Gray_Area]

I tried this out, but I don't see how to make more than one mode - the desktop mode.

[Gray_Area]

I talked to someone at a company that used to distribute my monitor, and he had no porch/pulse width info. I also found my manual, and nothing there, either.

[Calamity]

Unfortunately that information is not always provided by manufacturers, and when provided it's most of the times very incomplete.  However you can start with some of the multisync presets, like the WG D9800, and tweak it if necessary.

BTW which brand/model is it?

These are the lines required for WG D9800, you just substitute the ones in mame.ini with these ones:

monitor_specs0    15250-18000, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 288, 448
monitor_specs1    18001-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 320, 448
monitor_specs2    20001-29000, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 384, 576
monitor_specs3    29001-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 576, 768
monitor_specs4    32001-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 576, 768
monitor_specs5    34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 600, 768

[Gray_Area]

But I run vectors at the max resolution of the monitor, 1024x768. Also, running the D9800 mode, games like DK run at 320x250. It's a Billabs.

[Calamity]

What resolution/orientation would you like DK to run at?

I've modified the D9800 lines so they fit your ranges 15-48 kHz, 55-65 Hz. Notice I changed the last one so it can reach a vertical resolution of 768 for your vector games. You'll probably need to set this resolution manually creating a vector.ini file. Also, if 1024x768 resolution is not created automatically, you'll need to add it to ReslList.txt and recreate the video modes running VMMaker.

monitor_specs0    15250-18000, 55-65, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 288, 448
monitor_specs1    18001-19000, 55-65, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 320, 448
monitor_specs2    20001-29000, 55-65, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 384, 576
monitor_specs3    29001-32000, 55-65, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 576, 768
monitor_specs4    32001-34000, 55-65, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 576, 768
monitor_specs5    34001-48000, 55-65, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 768, 768

[Gray_Area]

Those make some difference, but vertical games are still screwy. I'd expect them to be at 400x256, x288, etc, but instead they're at about 15.7khz/60.5hz, and look like I'm running some kind of effect. I know I'm not because I deleted them all, and made sure HLSL was '0'.

Also, horizontal games are running at a 'custom resolution' says my monitor OSD, instead of most of them running at 640x224.

A vector ini with what in it?...and put it where?

Last, why does it go interlace when I run MAME's OSD, and how can I stop this?  (I'm just using it for testing purposes, but I'd rather it switch resolutions only when loading and exiting games.)

[Calamity]

Those make some difference, but vertical games are still screwy. I'd expect them to be at 400x256, x288, etc, but instead they're at about 15.7khz/60.5hz, and look like I'm running some kind of effect. I know I'm not because I deleted them all, and made sure HLSL was '0'.

Probably you didn't create those resolutions first so GroovyMAME can't use them. That's done by running VMMaker with the same monitor_specs you use in GroovyMAME. That will install the required resolutions. Use the updated one attached to this post.

Anyway, please get me a log by typing:

groovymame.exe romname -v -md 4 >romname.txt

... that will provide me with all required information on your system setup so I can give some advice accordingly.

Also, horizontal games are running at a 'custom resolution' says my monitor OSD, instead of most of them running at 640x224.

AFAIK running custom resolutions is the expected behaviour and the aim of the whole thing. Using a 640x224 is a valid approach for 320x224 games but definitely wouldn't work as general solution for the hundrends of resolutions required by MAME.

A vector ini with what in it?...and put it where?

This is for MAME so it will go in its folder, in MAME's docs it's explained you can create a vector.ini with specific options for vector games. So I would add a line for the resolution you want:

resolution 1024x768@60

Anyway be aware that forcing resolutions doesn't work fine in GroovyMAME sometimes. The reason is that GroovyMAME was not meant for forcing stuff like that. However I can see it's required in some situations so it will get fixed when Windows setup part is rewritten (hopefully soon).

Last, why does it go interlace when I run MAME's OSD, and how can I stop this?  (I'm just using it for testing purposes, but I'd rather it switch resolutions only when loading and exiting games.)

Well, I guess it's because MAME (the official one), for some unknown reason, states that its empty driver (the one it uses when you specify no romname and brings the default OSD), uses a video mode of 640x480@30. Here, the '30' is assumed by the modeline generator as a request for an interlaced mode, so it's doing the right thing I'm afraid. I'll see if this can be patched at some point.

[Gray_Area]

Ahhhhhh. Thanks for the help. You're an intrepid soul. I'm going to wait until....or if.....it becomes a bit more automated and all.

[Calamity]

Ahhhhhh. Thanks for the help. You're an intrepid soul. I'm going to wait until....or if.....it becomes a bit more automated and all.

I have the feeling that GroovyMAME will never be enough automated for you, Gray_Area. 

[Gray_Area]

It may not. While it took me a while to figure out AdvanceMAME, I've been pretty spoiled with it, and HLSL in current MAME pretty much precludes interest in manual methods of native mode generation.