So here goes the test:
- System: Windows XP-32bits
- CRT_Emudriver 9.3 XP-32bits
- Powerstrip 3.90
- Juddertest 1.1
Test monitors:
- CRT, 15" LG (late 90's)
- LCD-1, 17" HP 1740 (pre-2005)
- LCD-2, 20" Dell 2007WFPb
This will show how we can test custom refresh rates on the fly only using CRT_Emudriver + Arcade_OSD. For the first test, I'm setting 640x480@60 using Arcade_OSD. We already have a 640x480 custom modeline that overrides the equivalent system mode (that's why the edit menus are highlighted):
The quickest way to create a custom refresh rate is by editing the vertical geometry, so we enter this menu:
First we need to disable the vfreq lock, then we will increase front and back porches by the same amount of lines. As we do that, we'll notice how our precalculated vertical refresh goes down. We are going to try with a refresh around 55Hz, so when we get close to that figure, we'll press P1 or Enter to accept the new timings, then the screen will blink for one instant as the monitor syncs to the new timings. Now we press 5 to measure the real refresh rate. We'll see an scrolling pattern for some seconds while the refresh value is measured. Scrolling is perfectly smooth as we're using a CRT and screen updates are synchronized to our video card's vblank signal. Resulting refresh turns out to be 55.076 Hz (very close the the refresh used by many Irem games):
Then we enter our monitor's OSD, to check that the input signal has the expected vfreq. Unfortunately this old CRT only shows integer values for refresh rate:
Now, without exiting this menu, we switch vga cables, now hooking the HP LCD to the vga output. The picture blinks for a instant as the monitor adjusts for the custom timings. OSD shows 55.1Hz as the input signal. We press 5 again to see that the scrolling pattern is perfectly smooth, no judder at all:
Now we repeat the process with the Dell LCD. Its OSD only shows integer values too (55). But now, when we press 5, the scroll is full of choppiness and judder:
Its interesting to notice that in these three cases, calculated vfreq turned out to be 55.076 Hz, so its obvious that our output signal is not altered by switching monitors.
For the next tests, we are going to use Powerstrip as the method for working with custom timings. We won't edit those timings directly through the Powerstrip user interface, but using Juddertest instead which uses Powerstrip API to handle custom video timings. So we need to install Powerstrip, reboot, and execute it, and we'll be ready for using Juddertest.
First of all, we're going to set the desktop to the video mode we want to test, as Juddertest can't change the video mode dynamically. We'll use Arcade_OSD for that. In the mode list, we notice there's an interesting system's native mode: 800x600@56Hz. We'll select this one and set it as our desktop mode:
Now, we'll measure its vfreq, to make sure it's the right one:
Vfreq measured by Arcade_OSD is 56.250 Hz:
We'll notice that the edit menus are disabled for this mode. This is because it's a driver's native mode, not at custom one, so we can't have access to its timings with the methods used by Arcade_OSD. Fortunately, Powerstrip allows us to edit the timings of any video mode, as it can access hardware directly using its own driver.
So it's time to run Juddertest. This program will read the timings of the active video mode getting them from Powerstrip's hidden window. If we look at the vertical geometry column, we'll notice the refresh rate is the exact same one that Arcade_OSD measured: 56.250 Hz
Now we get into the test itself and enter the OSD to check the signal's refresh is the right one. The vertical bars scroll smoothly as expected for a CRT:
Now, let's switch to the HP LCD. We do this without exiting or stopping the test, so no cheating is possible:
Unlike with the previous video mode, now the OSD only shows the video mode formatted without decimals. I believe this is because this time the monitor recognizes the resolution as we haven't tweaked it. As for the judder, there's nothing but a perfectly smooth scrolling, no choppiness at all.
Now, let's switch to the Dell LCD. As soon as we plug the cable and the picture stabilizes, we notice that the scroll is not smooth any more, it's full of little jumps and even tearing:
Dell's OSD shows the right refresh anyway.
Finally, we are going to test a 57 Hz mode. For this test, we are going to start enabling the native standard 800x600@60 built in the driver. We plug our CRT again and from Arcade_OSD we select the mode:
What we're going to do is to tweak this mode and reduce its refresh to something around 57 Hz. This time we'll use Juddertest's interface for doing that:
As we did before, we'll increase both vertical porches until we reach the frequency we want, 57.390 Hz:
Once we press Apply and the new mode is on the screen, we can enter the test. Again, our OSD shows the right frequency:
Now we switch to the HP LCD, and a beatiful 57.3 figure is shown on its OSD, as the scroll rolls smooth as silk:
We think its enough for a day and don't feel like plugging the Dell monitor as the scroll is going to be crap anyway, but hey, let's do it for the sake of science:
Oh my... Surprisingly, now the Dell also shows an incredibly smooth scroll with this 57 Hz frequency.
This reinforces the idea that LCD devices have some predefined ranges for the input signal where they are able to update the panel at the original signal's refresh provided the input falls within that range, rather than a "fixed" frequency. This range may be wider or narrower depending on the model, even possibly be several different ranges, but its likely to be a feature related to accompanying board harware rather than some fundamental property of the panel itself.
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Thoughts on new 9000 Series LCD from Wells Gardner? (Read 21073 times)
