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: CabMame  (Read 50428 times)

0 Members and 1 Guest are viewing this topic.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #200 on: April 13, 2011, 01:51:49 am »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).

Sorry, I thought it was one of those LCDs.

Do you have any PCB so we can compare what your OSD says with what MAME/MAWS says?

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #201 on: April 13, 2011, 01:58:27 am »
The whole attempt at trying to get LCDs to run at any arbitrary refresh rate seems like it will never work consistently enough to be any sort of releasable system.

Normally, it should be video source that defines consistency, display should only fulfill minimum requirements to follow along with the given rhythm. But in any case, it's only with arcade games where this is a problem, otherwise refresh rates are pretty standard.

All the media is already converted in production to correct refresh rates for your region. As far as TVs are concerned this is all just about motion interpolation to compensate for large screens. Extras, such as 'frame rate scaler', that's just for NTSC/PAL conversion, and that's as far as REAL-TIME framerate conversion goes. 


But wait a second, if the MAXIMUM refresh rate of some LCD is 60fps, why would it not be able to do 57fps or 53fps?


Quote
I would imagine that there is a vast amount of variability between different LCD driver in as far as what frame rates they actually display.

Are you saying LCDs can't be driven by the rhythm of the video source, they have their own internal clock, and even if they made them tick at exactly 60Hz some LCDs still end up at 59.93Hz, some at 60.42Hz and so on?


Quote
I would also imagine that the rate at which it attempts to display frames, and the rate at which the actual liquid crystals can change is variable, as was suggested previously. Since monitor speeds are generally stated as 'gray to gray' i would also be lead to believe that there is variability in the speed at which different colours change to one another, again independent of what rate they are being instructed to change.

Variability in crystal response should not matter as long as they can satisfy some minimum to maintain internal refresh rate in worst case scenario. Maybe there will be impact and colors will go funny if you really go tough on them, but the framerate itself should not suffer because of it, more likely is that crystals would go bad if they can't cope with given refresh rate.


Quote
I doubt there is any technical reason why an LCD could not be updated at a fully arbitrary frame rate. In face I imagine there are probably ones on the market right now that would happily be fed a random refresh speed and display it just fine.

I think there is a reason, even if only economical, but I thought you suggested they have their own internal clock and work in some kind of non-cooperative and asynchronous mode completely independently from the rhythm given by the video source?


Quote
However, I would assume that most are going to simply ASSUME they will be run at ~60hz and happily drop frames that don't line up since 99.9% of the consumers will not only not care, but not even notice.

That sounds like truth.


Quote
In traditional CRTs the actual speed of the electron gun was being driven by the sync signal, which is why arbitrary rates were a non-issue.

Yes, so what drives the refresh rate of an LCD, the rhythm of the video source or the rhythm of an internal clock? But even if it's internal clock, why it would need to be fixed? I don't know, but it surely looks like LCDs come with completely fixed output refresh rates.

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #202 on: April 13, 2011, 05:51:07 am »
There's a fair bit of information in this article which might be worth reading:
http://www.xbitlabs.com/articles/monitors/print/lcd-parameters.html


bitbytebit

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: CabMame
« Reply #203 on: April 13, 2011, 08:08:09 am »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).

Sorry, I thought it was one of those LCDs.

Do you have any PCB so we can compare what your OSD says with what MAME/MAWS says?



Eventually I want to do that, get one of those 90 in 1 PCB's to play around with and compare to Mame, I have a WG7200 19" arcade monitor too and would be really interesting to go back and forth between all combinations of Mame/PCB/d9800/WG7200.  Probably not as soon as later, in the middle of getting ready to move right now, so both funding and have to wait till in the new place to even think of getting the WG7200 setup in some kind of table top testing rig.  It's at least in the future plans to do such things.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization