OK, it has been too long since I read this. I'll intersperse my
comments. Many thanks to James for taking this up.
James Waldby wrote:
wrote:
http://users.aol.com/DGoncz/Publications/Modes.gif
will show to you that many common video modes require only padding by 2
to be scanned diagonally without retrace.
Any questions, anybody?
Mainly why, both on a practical basis (your method is complicated
and it's not obvious that it would present a better picture,
require less hardware, be amenable to rasterization, or allow
random video adapters to work with random monitors) and a
theoretical basis (your emphasis on greatest common div's).
It will require less hardware. The drive for H and V is the same
circuitry operating at the same potentials. A conventional audio amp
can be used for drive.
Phase requirements can eventually be met to provide a clear picture.
The method *is* a raster method; the subblocks are not scanned. (In an
image processing analysis, I scanned the subblocks and applied
transforms. Good results comparing conventional sawtooth raster, full
raster diagonal, and sub-block diagonal at
ftp://users.aol.com/DGoncz)
If PowerStrip's flexbility is any indication, random adapters will work
with random monitors. Note that such a diagonal monitor is capable of a
nearly continuous range of modes starting with 4x6, through 480x640
(padded), on up to huge resolutions like 4096x4096 (padded), which can
be displayed with no flicker at low frame rates due to some
characteristics of the eye I have looked at.
Regarding gcd's, I don't see why a cell-based display would need
co-prime horizontal and vertical sizes. Correct me if I'm wrong!
Coprime H and V scanned without blanking padding produces a display
that doesn't loop. The presence of a *sole* common factor of 2 between
H and V allows looping. No retrace, no high voltage flyback. The cell
basis underlying the monitor idea is a minor refinement: transmitting
pixels in this order preserves something called adjacency, keeping
interruptions in transmission to small areas. Strangely enough, even
multidimensional blocks of data can be scanned diagonally with
subblocks to preserve adjacency.
Also, your program's "while" loop means that your Modes.gif does
*not* show anything about padding by 2, since it may have padded
by 4, 6, ... as well. You are right, but the program doesn't
show it.
Actually for the modes listed, padding by two (n=2) does cause the loop
to exit on the first try through the while. There's no point in padding
by one as below. The modes really need to stay even/even.
Here is some program output that does:
H V .. +. ++ .+ -+ -. -+ .- -- #. ## .# =# =. =# .= ==
640 480 160 1 1 1 1 3 1 1 1 6 2 2 2 2 2 2 2
800 600 200 3 1 1 1 1 1 1 1 2 2 2 14 6 14 2 2
1024 768 256 1 1 1 1 3 1 1 1 6 2 2 14 2 14 2 2
1152 864 288 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2
1280 960 320 3 1 1 1 1 1 1 1 2 2 2 2 6 2 2 2
1280 1024 256 1 1 5 1 1 1 1 1 2 2 2 18 2 18 2 2
1400 1050 350 3 1 1 1 1 1 1 1 2 2 4 2 6 2 8 2
1600 1200 400 1 1 1 1 3 1 1 1 6 2 2 2 2 2 2 2
1800 1440 360 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2
This is from http://pat7.com/jp/omni-di.c . In the headings,
I note that the 13th colum is all twos.
The 13th headder is ## (+2, +2)
So we agree. All the modes listed here can be padded by two to get a
sole common factor of two. All the modes (not an identical list) in
Modes.gif can be padded by two to get this same sole common factor. It
works. Yes, my program wasn't well written.
. means +0, + +1, - -1, # +2, = -2, for H or V in left/right
place. Eg: the .. column is value of gcd(h, v) [or, v/3 if
aspect ratio is 4:3] and the =# column is value of gcd(h-2, v+2).
As Don Nichols points out, there are a lot of different display
resolutions in use. Some VESA sizes [see items 35 and 36 in
http://en.wikipedia.org/wiki/Extende...ification_data
] a
720x400@70 Hz, 720x400@88 Hz, 640x480@60 Hz, 640x480@67 Hz,
640x480@72 Hz, 640x480@75 Hz, 800x600@56 Hz, 800x600@60 Hz
800x600@72 Hz, 800x600@75 Hz, 832x624@75 Hz, 1024x768@87 Hz
1024x768@60 Hz, 1024x768@70 Hz, 1024x768@75 Hz, 1280x1024@75 Hz
but VESA sizes aren't the whole story, because many people like
to set up custom modelines in their X Windows System config files.
It might be worthwhile for you to google Modeline and/or read
man XF86Config. Note that besides H and V display limits,
modelines also specify hsyncstart, hsyncend, vsyncstart, and
vsyncend.
Thanks very much, I should read up and PowerStrip writes modelines for
me now.
There are many more modes available with diagonal scan than
manufacturers have agreed on so far, and they are available in flexible
ways with little variation in screen results when rates are pushed.
As soon as I get a nag screen in PowerStrip I'll pay since I *am* using
it.
Here's the smallest diagonal mode that loops:
x a i h p q
w j b o g r
k v n c s f
l m u t d e
Where pixels 1-24 in the 4x6 block are label a-x.
The first pixel is one from the corner, but it's a loop, so that
doesn't matter....
Doug Goncz
Replikon Research
Falls Church, VA 22044-0393