Question about interpreting monitor scan ranges

[--james--]

Hi,

I've been lurking here for a while trying to come up to speed on all things CRT related, but I still have a question about understanding scan rates.

I have a monitor that has the following scan specs:
         
Horizontal scan range          30 kHz to 130 kHz (automatic)
Vertical scan range          48 Hz to 170 Hz (automatic)
Optimal preset resolution       1280 x 1024 at 85 Hz
Highest preset resolution       1600 x 1200 at 85 Hz
Highest addressable resolution    2048 x 1536 at 80 Hz
Viewable Image Size         14.3" x 11.5" (18.4")

It also has the following preset resolutions:
Mode         H Freq   V Freq   Clock
720 x 400      31.5 kHz   70 Hz      28.3 MHz   -/+
640 x 480       31.5      60       25.2       -/-
640 x 480       43.3      85       36.0       -/-
800 x 600       53.7      85       56.3       +/+
1024 x 768       60.0      75       78.8       +/+
1024 x 768       68.7      85       94.5       +/+
1280 x 1024    80.0      75       135.0    +/+
1280 x 1024    91.1      85       157.5    +/+
1600 x 1200    93.8      75       202.5    +/+
1600 x 1200    106.3    85       229.5    +/+

Here is my question:
Is it reasonable to expect that I can use Advance MAME or a similar tool to drive the monitor at any res combo in this range?

For example, can I run Pac-Man at 224 x 288 @ 121 Hz (H scan of about 30.1 kHz)?  Of course, this is mounted vertically (224 lines)

If I am understanding correctly, this would be exactly double the native resolution and lead to smooth and properly timed play?

Or is the solution to run it at 448 x 576 @ 60.6 Hz?

... one additional piece of info.  I understand that this won't look 100% authentic.  As much as I would like to own 2 or 3 genuine arcade monitors to play most of my childhood favorites, I think one PC monitor is going to have to work.  I am more concerned with smooth and realistic gameplay combined with a "decent" approximation of the original graphic look.

Thanks for all the good info on this forum ... I've already learned a ton.  You all have really put together a good repository of information.

james

[newmanfamilyvlogs]

I've been using Calamity's modified ATI drivers to drive my 31kHz arcade monitor using native resolutions scaled 2x, and running at their native refresh rates.
His VMMaker tool allows you to specify the limits of your monitor (as you mentioned earlier). It uses this to generate modelines in conjunction with an XML file it reads from mame.

AdvanceMame isn't maintained anymore. Go check out this thread:
http://forum.arcadecontrols.com/index.php?topic=110905.0

[--james--]

Thanks for pointing me to groovymame ... sounds like exactly the tool I am looking for.

I am still trying to figure out what exactly are the limitations of my monitor, and I still need to buy a graphics card that will work with all of this.  More research required I guess ...

It seems like many current manufacturers only post specifications about the maximum dot clocks or scan rates that they can handle, they don't say anything of the complete range.  Since we tend to be mostly interested in flexibility at the low-res end, that data would be good.

[newmanfamilyvlogs]

Running a 31kHz monitor, you probably won't run into issues with the low-end dot clock issues like you would on a 15kHz monitor. Almost all the resolutions you'll be running will need to be scaled 2x.

[Gray_Area]

I've been using Calamity's modified ATI drivers to drive my 31kHz arcade monitor using native resolutions scaled 2x, and running at their native refresh rates.

What does this mean?

[newmanfamilyvlogs]

I've been using Calamity's modified ATI drivers to drive my 31kHz arcade monitor using native resolutions scaled 2x, and running at their native refresh rates.

What does this mean?

My monitor does 30-40kHz hsync, 47-90Hz vsync.
since modes like galaga at 224x288x60.606061Hz work out to 14.58 kHz, i use 448x567x60.606061 which is 36.21 kHz.
Vmmaker generates 'template' resolutions based on the mame xml and your supplied monitor specs. groovymame matches the modes to the game at runtime. generates a new modeline for the games native resolution, updates the registry and switches to it.
At exactly double resolution it is visually indistinguishable from native.

[--james--]

I'm not exactly sure what the heart of your question is, but I'll try to take a shot at it.

Calamity's drivers allow windows users to create manual modelines.  Windows doesn't have any built-in support for this, so you need hacked drivers.  In short, modelines describe exactly how the raster scan is timed.  This determines the pixel resolution and refresh rate.

For a CRT monitor, the pixel resolution and refresh rate are flexible (within certain bounds).  Running an arcade game in any pixel resolution other than the one it was intended for (the native resolution) will cause distortion of the image.  Running it with a refresh rate other than the native rate will cause either tearing or skipping.  Both of these effects can range from barely discernible to completely unplayable.

There are limitations on what modelines a given monitor can sync with.  This is most easily described by a little arithmetic below.  Basically, a modern monitor scans too quickly to display the old arcade resolutions, so something has to give.  It seems like the most common solution is to double the pixel resolution and keep the refresh rate equal to the native rate.

Using an example from the most awesome game ever (Burgertime).

Native resolution is 240x240 pixels at 57.44 Hz

240 lines * 110% * 57.44 frames per second = 15164 ~ 15.1 kHz, which is right in the heart of the sync range for an arcade monitor, but well below the Hsync limit for most modern monitors.

Where does the 110% come from?  It's just a rule of thumb, not an absolute.  It takes into account the number of cycles required for the electron beam to sweep back to the right at the end of each line (the horizontal synchronization pulse), and the amount of time for the beam to reset to the top left corner after the last line is painted (the V sync).  If you ever write manual modelines, you can figure out exactly how many cycles are required.

To get burgertime up to the minimum scan rate that my monitor can display (30-130 kHz), I have to double the pixel resolution.

480 lines *110% * 57.44 Hz ~ 30.3 kHz.

The visual distortion caused by doubling the number of pixels is negligible (in my personal opinion).  If you use a non-integer scaling factor, it usually has very noticeable effects on low-res graphics

Running the game at 60 Hz on my LCD laptop monitor with triple buffering causes the hotdogs to skip around in a distracting way instead of waddling in their normal endearing manner.  Running the game with frame sync causes a noticeable speedup (4.5% faster).  While this doesn't totally kill Burgertime for me, it hurts the high scores a little bit.

There is a LOT more that can be said about all of the above.  If you are really interested in modelines, the old xwindows documentation is quite good.