Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Figuring out monitor_specs for an undocumented monitor  (Read 3505 times)

0 Members and 1 Guest are viewing this topic.

mazinger-z

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:January 03, 2016, 12:50:47 pm
Figuring out monitor_specs for an undocumented monitor
« on: February 03, 2012, 06:07:43 pm »
Is there a way to determine the specs of a monitor by trial and error? If a modeline with a horizontal frequency of 16.660 KHz works nicely, can I assume the monitor will always handle that frequency correctly (given the other values are within specifications, of course)?
In an earlier thread I got some kind help from Calamity but VMMaker still seems to generate many modelines that do not work with my monitor. I started a new thread mainly because the subject was about other stuff and because I think it'd be nice if we came up with a method to figure out the specs for any monitor.

There's something I don't understand about the monitor_specs string: sync pulse lengths and front/back porch lengths are given as fixed values and not as ranges of values. How's that? Since each modeline has its own syncs/porches, I would expect having to specify the limits for them, as we do for H & V frequencies.  :dunno

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #1 on: February 04, 2012, 10:15:48 am »
Is there a way to determine the specs of a monitor by trial and error?

Sure, but it's better to know what you're doig as there's a real possibility of smoking your chassis, this is specially true for some analog multisync monitors. (For fixed sync monitors, it's a good idea to connect your card through a j-pac.)

Quote
If a modeline with a horizontal frequency of 16.660 KHz works nicely, can I assume the monitor will always handle that frequency correctly (given the other values are within specifications, of course)?

Yes, that should be the case.

Quote
There's something I don't understand about the monitor_specs string: sync pulse lengths and front/back porch lengths are given as fixed values and not as ranges of values. How's that? Since each modeline has its own syncs/porches, I would expect having to specify the limits for them, as we do for H & V frequencies.  :dunno

That's because we're only interested in the minimum values.

As for the sync pulses, when generating 15 KHz modes we usually just pick the ones defined for the TV standards:
- H sync pulse: 4.7 microseconds
- V sync pulse: 3 lines (0.192 miliseconds)

These ones should always work, even if modern multisync monitors can work with lower values.

Horizontal porches are not critical for picture stability, they just need to be long enough so the borders are not cropped.

For vertical front porch is usually enough to use 1 line (0.064 miliseconds)

Vertical back porch is the most important value. It accounts for the minimum time the monitor needs for vertical retrace (the time it takes for the electron beam to return to the top of the screen and stabilize itself). Usually, 18 lines is enough (1.152 miliseconds). We usually prefer monitors with fast retrace (lower values).

So this is the theory. Post some of your problematic modelines to see if we can find a logic to the problem.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

mazinger-z

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:January 03, 2016, 12:50:47 pm
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #2 on: February 05, 2012, 06:28:26 am »
Here's a list of modelines that don't work. They all show vertical waves. I also added my manually adjusted version of each modeline for comparison. At the end are some more modelines I made for testing. The interesting thing is that another monitor of mine, totally different from this arcade monitor, behaves almost exactly the same. It's a Microvitec M1438s, supporting horizontal frequencies ranging from 15 to 40 KHz.

Apart from these, I found out something that's related to the modelines with more than 240 lines: the picture is overly dark unless I greatly decrease the Vertical Back Porch and the Horizontal Sync goes under 15.630 KHz. I can decrease the Vbp from 18 lines to 10 lines or less, and I still get a picture (a brighter one).

Code: [Select]
        Not working          ||          Working
--------------------------------------------------------------
232x224 60.000 Hz 15.660 KHz || 232x224 59.986Hz 15.656 KHz
dotclock 5011235             || dotclock 4884743
Hfp 4.79 Vfp 638.57   || Hfp 3.28 Vfp 638.72
Hsp 4.79 Vsp 191.57   || Hsp 4.91 Vsp 191.62
Hbp 7.98 Vbp 1532.56  || Hbp 8.19 Vbp 1532.94
H blanking 17.56             || H blanking 16.38
--------------------------------------------------------------
240x256 58.513 Hz 16.208 KHz || 240x256 58.524 Hz 15.802 KHz
dotclock 5445885             || dotclock 5182905
Hfp 4.41 Vfp 123.40   || Hfp 3.09 Vfp 126.57
Hsp 4.41 Vsp 185.09   || Hsp 4.63 Vsp 189.85
Hbp 8.81 Vbp 987.17   || Hbp 9.26 Vbp 569.56
H blanking 17.63             || H blanking 16.98
--------------------------------------------------------------
264x224 59.922 Hz 15.640 KHz || 264x224 60.000 Hz 15.660 KHz
dotclock 5880531             || dotclock 5512359
Hfp 5.44 Vfp 639.40   || Hfp 2.90 Vfp 638.57
Hsp 5.44 Vsp 191.82   || Hsp 5.81 Vsp 191.57
Hbp 8.16 Vbp 1534.56  || Hbp 7.26 Vbp 1532.56
H blanking 19.05             || H blanking 16.65
--------------------------------------------------------------
264x240 59.922 Hz 15.640 KHz || 264x240 60.000Hz 15.660 KHz
dotclock 5880531             || dotclock 5512359
Hfp 5.44 Vfp 127.88   || Hfp 2.90 Vfp 127.71
Hsp 5.44 Vsp 191.82   || Hsp 5.81 Vsp 191.57
Hbp 8.16 Vbp 1023.04  || Hbp 7.26 Vbp 1021.70
H blanking 19.05             || H blanking 15.96
--------------------------------------------------------------
360x224 59.971 Hz 15.652 KHz || 360x224 60.000Hz 15.660 KHz
dotclock 7888857             || dotclock 7516844
Hfp 5.07 Vfp 638.88   || Hfp 2.13 Vfp 638.57
Hsp 5.07 Vsp 191.66   || Hsp 5.32 Vsp 191.57
Hbp 8.11 Vbp 1533.30  || Hbp 8.51 Vbp 1532.56
H blanking 18.25             || H blanking 15.96
--------------------------------------------------------------
360x240 59.971 Hz 15.652 KHz || 360x240 60.000 Hz 15.660 KHz
dotclock 7888857             || dotclock 7516844
Hfp 5.07 Vfp 127.78   || Hfp 2.13 Vfp 127.71
Hsp 5.07 Vsp 191.66   || Hsp 5.32 Vsp 191.57
Hbp 8.11 Vbp 1022.20  || Hbp 8.51 Vbp 1021.71
H blanking 18.25             || H blanking 15.96
--------------------------------------------------------------
384x224 59.976 Hz 15.654 KHz || 384x224 60.009 Hz 15.662 KHz
dotclock 8390408             || dotclock 7643185
Hfp 4.77 Vfp 638.82   || Hfp 2.09 Vfp 638.48
Hsp 4.77 Vsp 191.65   || Hsp 5.23 Vsp 191.54
Hbp 8.58 Vbp 1533.18  || Hbp 8.37 Vbp 1532.35
H blanking 18.12             || H blanking 15.97
--------------------------------------------------------------
384x240 59.976 Hz 15.654 KHz || 384x240 59.981 Hz 15.655 KHz
dotclock 8390408             || dotclock 8015414
Hfp 4.77 Vfp 127.76   || Hfp 2.00 Vfp 127.75
Hsp 4.77 Vsp 191.65   || Hsp 4.99 Vsp 191.63
Hbp 8.58 Vbp 1022.12  || Hbp 8.98 Vbp 1022.03
H blanking 18.12             || H blanking 15.97
--------------------------------------------------------------
--------------------------------------------------------------
232x224 59.651 Hz 15.569KHz  ||
dotclock 4982016             ||
Hfp 4.82              ||
Hsp 4.82              ||
Hbp 8.03              ||
H blanking 17.66             ||
--------------------------------------------------------------
     || 232x224 59.549 Hz 15.542 KHz
     || dotclock 4973558
     || Hfp 4.83
     || Hsp 4.83
     || Hbp 8.04
     || H blanking 17.69
--------------------------------------------------------------
     || 232x224 58.486 Hz 15.265 KHz
     || dotclock 4884743
     || Hfp 4.91
     || Hsp 4.91
     || Hbp 8.19
     || H blanking 18.02
--------------------------------------------------------------
     || 232x224 60.095 Hz 15.685 KHz
     || dotclock 4893625
     || Hfp 3.27
     || Hsp 4.90
     || Hbp 8.17
     || H blanking 16.37
--------------------------------------------------------------
     || 232x224 59.549 Hz 15.542 KHz
     || dotclock 4973558
     || Hfp 3.22
     || Hsp 4.83
     || Hbp 9.67
     || H blanking 17.69
--------------------------------------------------------------

Thank you for your time!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #3 on: February 05, 2012, 10:25:10 am »
Here's a list of modelines that don't work. They all show vertical waves. I also added my manually adjusted version of each modeline for comparison. At the end are some more modelines I made for testing. The interesting thing is that another monitor of mine, totally different from this arcade monitor, behaves almost exactly the same. It's a Microvitec M1438s, supporting horizontal frequencies ranging from 15 to 40 KHz.[/Wquote]

Thanks for the hard work.

Well, the only thing that I can see is that you had to correct all modes so that total H blanking was below 17 microseconds. Can you check if this is consistent? Use Arcade_OSD to check that, try a random mode and go increasing either HFP, HSP, HBP to see if you get that issue at some point.

Quote
Apart from these, I found out something that's related to the modelines with more than 240 lines: the picture is overly dark unless I greatly decrease the Vertical Back Porch and the Horizontal Sync goes under 15.630 KHz. I can decrease the Vbp from 18 lines to 10 lines or less, and I still get a picture (a brighter one).

Yes that makes sense. You should use the lowest VBP value your monitor admits, here's a method you can use to find it:
http://forum.arcadecontrols.com/index.php?topic=116669.msg1245675#msg1245675

If you can use 10 lines instead of 16 or 18 without having issues at the top of the screen, that means your monitor has a faster retrace time: better.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

mazinger-z

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:January 03, 2016, 12:50:47 pm
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #4 on: February 07, 2012, 08:39:17 am »
Well, the only thing that I can see is that you had to correct all modes so that total H blanking was below 17 microseconds. Can you check if this is consistent? Use Arcade_OSD to check that, try a random mode and go increasing either HFP, HSP, HBP to see if you get that issue at some point.

I'm trying my best but couldn't get a satisfactory explaination yet. I'll post some information after further tests.

Yes that makes sense. You should use the lowest VBP value your monitor admits, here's a method you can use to find it:
http://forum.arcadecontrols.com/index.php?topic=116669.msg1245675#msg1245675
If you can use 10 lines instead of 16 or 18 without having issues at the top of the screen, that means your monitor has a faster retrace time: better.

Whoops... My screens were missing the top lines completely, didn't notice that because vertical size was set all the way up. Hopefully they're all fixed now.

mazinger-z

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:January 03, 2016, 12:50:47 pm
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #5 on: February 08, 2012, 07:29:10 am »
 :cheers:
Maybe I just found where the problem lies. I swapped the video card, and magically those modelines work nicely on both monitors! The card probably acted inconsistently with the settings shown. The thing that puzzled me most was that there were working modelines that pushed the geometry settings more than non-working ones.

The old card was:
GeCube Radeon R9200 AGP
Rev 1.1
Like this one:
http://www.hwupgrade.it/forum/showthread.php?t=1610757

The new card is a genuine ATi Radeon 9250 PCI 128 Mb.

Do you advice me against using a PCI card? I just use 2D games dated from the early 80's to 1998.

PS: There's something strange I noticed about ArcadeOSD. It sometimes retains my settings even if I leave the setup screen by pressing ESC. At this point it shows the old (saved) settings but uses the new settings. Rebooting ArcadeOSD doesn't help and I have to reboot Windows to get a consistent behavior.

Thanks!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: Figuring out monitor_specs for an undocumented monitor
« Reply #6 on: February 08, 2012, 07:56:35 am »
Oh I'm happy you fixed it, really. Finding unconsistent results at this point would make us question the whole modeline engine and the logic it's based on, so it's a good thing it turned out to be the card. I guess this could have happened because some of the dotclocks were't fully stable for the previous card, which is hardware issue.

BTW, I mostly use PCI cards these days, they work just the same.

The issue with Arcade_OSD must be some sort of bug, hopefully next version fixes things like that (not sure).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi