Hell, alt.math, sci.math, and sci.electronic.design.

I have put my machine tool interests on the back burner and am pursuing
a monitor, video, and data format I think I may have come up with
originally, although some of it is known.

What I want to do is build some wave files and display them on my Tek
541 oscilloscope to start with.. They will have x and y values between
the extremes of plus and minus 15 bits (+- 32,767) at CD audio rate
(44.1 kss) on the left and right audio channels. I will use Mathcad to
compute the values to be converted from digital to analog audio.

x and y have some constraints. The will either be coprime or have a
sole comon factor of 2. My method of omnidiagonally serializing the
elements of the x by y bitmap, which I repeat may not be original, is
to start at a corner, or adjacent a corner, choosing by whether x and y
are coprime or have that common factor of 2, respectively, then to
trace the diagonal to a side, move along the side one increment, and
"reflect" the trace in that way.

While there are no upper bonds on x and y other than the 16 bits
available in most D/A converters, the atomic scan modes and bitmaps are
specific: they are 3x5 and 4x6. 3x5 is the atomic open serialization,
and 4x6 the atomic closed serilization. The open serilization begins
and ends in a diagonally opposite corners. The closed serialization
forms a continuous loop, and closed serilizations seem suitable for a
monitor design. So you can see that unlike conventional rasters, the
frequencies are in proportion to the aspect ratio, given square pixels.

I believe I can break into the electron microscope and medical monitor
field with this notion. Computer hardware is a more resistant and
well-developed market where backward compatibility is essential, and I
also do not know if there will be a convergence problem with any
attempts to produce color.

CRTs are required for this method. It's not relevant to plasma or LCD
displays, although an extension to video compression could be
implemented in software and compressed video displayed on CRT, LCD,
plasma, or any other display. Also, it might be fun to produce a
display for Microsoft Media Player or another player using this method,
deflecting the trace normal to its direction of movement.

Does any media player you know of accept drop-ins or plug-ins that
provide a display to accompany audio?

One advantage of this notion for CRTs is that the display always stays
centered. The deflections are simple triangle waves. The actual drives
to a conventional coil-yoked electromagnetically-deflected CRT are
somewhat involved as there is an impedance in the circuit. A Hammond B3
organ or emulator might come in handy for development, with its
approximations to musical intervals in the form of wheels and gears. My
Tek scope is electrostatically deflected. We'll have to see what works.

Another advantage is zoom ability. When the display is centered, and
stays that way, merely "turning up the volume" gives a zoom.
Conventional integrated amplifier volume controls provide some 70 db of
"zoom". That's a lot more than a monitor would need.

Are there any methods to prevent reflection of an electron beam from an
envelope when a raster is zoomed larger than the screen?

Would a slightly different envelope shape avoid the reflections usually
seen when a monitor is severely overscanned?

Where do these reflection occur and how?

I have given disclosure in the past so this method is not patentable.
You may consider it open source and I would like some advice on using
the GNU intellectual property licensing method, should I or we develop
anything of significant value.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

(I) wrote:
Hell(o), alt.math, sci.math, and sci.electronic.design.

I have put my machine tool interests on the back burner and am pursuing
a monitor, video, and data format I think I may have come up with
originally, although some of it is known.

What I want to do is build some wave files and display them on my Tek
541 oscilloscope to start with.. They will have x and y values between
the extremes of plus and minus 15 bits (+- 32,767) at CD audio rate
(44.1 kss) on the left and right audio channels. I will use Mathcad to
compute the values to be converted from digital to analog audio.

CRTs are required for this method. It's not relevant to plasma or LCD
displays, although an extension to video compression could be
implemented in software and compressed video displayed on CRT, LCD,
plasma, or any other display. Also, it might be fun to produce a
display for Microsoft Media Player or another player using this method,
deflecting the trace normal to its direction of movement.

Does any media player you know of accept drop-ins or plug-ins that
provide a display to accompany audio?

Here's what I found.
http://msdn.microsoft.com/library/de...enderabout.asp

Doug

wrote:

snip

Does any media player you know of accept drop-ins or plug-ins that
provide a display to accompany audio?

Can't help you with any of the rest, but Google "audio visualizer". Winamp,
XMMS, and Windows Media Player are three, but not the only three. This
kind of thing is big in the DJ world--plug in a projector and you have a
nice lightshow.

snip

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

wrote:
Hell, alt.math, sci.math, and sci.electronic.design.

I have put my machine tool interests on the back burner and am pursuing
a monitor, video, and data format I think I may have come up with
originally, although some of it is known.

What I want to do is build some wave files and display them on my Tek
541 oscilloscope to start with.. They will have x and y values between
the extremes of plus and minus 15 bits (+- 32,767) at CD audio rate
(44.1 kss) on the left and right audio channels. I will use Mathcad to
compute the values to be converted from digital to analog audio.

x and y have some constraints. The will either be coprime or have a
sole comon factor of 2. My method of omnidiagonally serializing the
elements of the x by y bitmap, which I repeat may not be original, is
to start at a corner, or adjacent a corner, choosing by whether x and y
are coprime or have that common factor of 2, respectively, then to
trace the diagonal to a side, move along the side one increment, and
"reflect" the trace in that way.

While there are no upper bonds on x and y other than the 16 bits
available in most D/A converters, the atomic scan modes and bitmaps are
specific: they are 3x5 and 4x6. 3x5 is the atomic open serialization,
and 4x6 the atomic closed serilization. The open serilization begins
and ends in a diagonally opposite corners. The closed serialization
forms a continuous loop, and closed serilizations seem suitable for a
monitor design. So you can see that unlike conventional rasters, the
frequencies are in proportion to the aspect ratio, given square pixels.

I believe that you are talking about raster-per-character way of making
a video display.

If you open a Signetics or TI logic databook from the early 70's I
believe you will find pre-programmed ROM's that let you do this, along
with some sample circuits.

I think some Tek scopes (the ones that can put numbers up on the CRT's
along with waveforms) used this techniquie through at least the 80's
(maybe early 90's).

This was also used in the famous Tek storage scope computer terminals
of the early 70's, like the 4010 and 4014, although not as a continuous
raster (because of course it was a storage scope!). As each character
was drawn you saw a square blink as the beam swept across in the
character raster and was modulated to store the character on the
screen.

I have given disclosure in the past so this method is not patentable.

It probably was patented in the 60's (if at all). Let me dig out my
late 60's/early 70's books on raster display generators and see if I
can find some names/brands/part numbers/patents for you.

I always liked the vector character generators myself.

Tim.

writes in article . com dated 15 Feb 2006 03:15:14 -0800:

What I want to do is build some wave files and display them on my Tek
541 oscilloscope to start with.. They will have x and y values between
the extremes of plus and minus 15 bits (+- 32,767) at CD audio rate
(44.1 kss) on the left and right audio channels. I will use Mathcad to
compute the values to be converted from digital to analog audio.

Apparantly you're re-inventing vector graphics.

Vector graphics were used in computing until the late 1980s. The main
advantage was that you don't need as much RAM for a high-res display,
because instead of keeping pixel colors in RAM you keep line segment
endpoints. When RAM got cheap, the bottom fell out of the vector graphics
market, and everybody went raster.

One problem I had with the Sanders Graphic-7 displays I used was that if I
displayed too much data at one time there was a visible flicker, because the
controller could only re-paint so fast. If you want a 60-Hz refresh rate
from your sound card, you can only display 683 lines at a time. I'm not
familiar with modern scopes, maybe yours doesn't require that high a rate to
avoid flicker.

Have fun building your prototype, it sounds like an interesting project.
But don't quit your day job.

When you get to the point where you want to display text, look for some free
"stroke fonts".

--Keith Lewis klewis {at} mitre.org
The above may not (yet) represent the opinions of my employer.

["Followup-To:" header set to alt.math.]
On 2006-02-15, wrote:

Does any media player you know of accept drop-ins or plug-ins that
provide a display to accompany audio?

XMMS, (prolly many others too)

One advantage of this notion for CRTs is that the display always stays
centered. The deflections are simple triangle waves. The actual drives
to a conventional coil-yoked electromagnetically-deflected CRT are
somewhat involved as there is an impedance in the circuit. A Hammond B3
organ or emulator might come in handy for development, with its
approximations to musical intervals in the form of wheels and gears. My
Tek scope is electrostatically deflected. We'll have to see what works.

Another advantage is zoom ability. When the display is centered, and
stays that way, merely "turning up the volume" gives a zoom.
Conventional integrated amplifier volume controls provide some 70 db of
"zoom". That's a lot more than a monitor would need.

Are there any methods to prevent reflection of an electron beam from an
envelope when a raster is zoomed larger than the screen?

turn it off?

Would a slightly different envelope shape avoid the reflections usually
seen when a monitor is severely overscanned?

Where do these reflection occur and how?

I have given disclosure in the past so this method is not patentable.
You may consider it open source and I would like some advice on using
the GNU intellectual property licensing method, should I or we develop
anything of significant value.

The main problem I see is that you need to scan in two dimensions at high
speed whereas with a conventional setup only one dimenstion is scanned
rapidly

Bye.
Jasen

No way am I reinventing vector graphics, Tim and Keith.

This is a diagonal *raster*, not a vector display. I didn't write much
about how the atomic serializations can be expanded, and I will soon,
but I am tired, and it's almost 3 AM, so I am going back to bed. I
don't sleep well.

Basically, you start with 6x4, you embed 3x5 in each pixel to get
18x20, you do it again with 5x3 to get 90x60, and you pad 90x60 with
sync/blanking bits to get something even and otherwise coprime, which
is topologically equivalent to 4x6. That is, it is a raster format that
can be displayed diagonally in a continuous loop. Then you do it again
to take 90x60 up to 1350x900 and pad again. Or you include every even
and otherwise coprime pair with aspect ratio suitable to your CRT to
offer a range of resolutions. It's finite math. I hope it's not
numerology!

I'll try to expand tomorrow night.

Doug

wrote:
No way am I reinventing vector graphics, Tim and Keith.

No, I never thought you did. (Although I think in general vector
character generation is way cooler, and even more so are mask character
generators, but we're getting off your subject :-) ).

What you seem to be re-inventing is subrasterization. Maybe not
re-inventing, as previous subraster dispalys did it for a specific
purpose (efficiency of character generation, efficiency of not stroking
over parts of display that will never have anything interesting etc.)
Your method seems to have a generality that defies all purposes :-).

This is a diagonal *raster*, not a vector display. I didn't write much
about how the atomic serializations can be expanded, and I will soon,
but I am tired, and it's almost 3 AM, so I am going back to bed. I
don't sleep well.

Basically, you start with 6x4, you embed 3x5 in each pixel to get
18x20, you do it again with 5x3 to get 90x60, and you pad 90x60 with
sync/blanking bits to get something even and otherwise coprime, which
is topologically equivalent to 4x6. That is, it is a raster format that
can be displayed diagonally in a continuous loop. Then you do it again
to take 90x60 up to 1350x900 and pad again. Or you include every even
and otherwise coprime pair with aspect ratio suitable to your CRT to
offer a range of resolutions. It's finite math. I hope it's not
numerology!

I think the gotcha here is that magnetically-deflected CRT's deflect
reliably only when you're sweeping in the same direction each time
through, and this method will be hard to adapt to magnetic deflection.
If there were some advantage (maybe application-specific) to your
method then I'd be more likely to see how it works.

Electrostatically-deflected CRT's aren't so much afflicted by this
(although D/A and sweep repeatibility and beating with interference
that is harmonically related to deflection can still exist in all but
the most benign environment.)

Again, the applications that I inow of that use subrasterization did it
for specific purposes (and did it pretty well too.) I'm not saying that
all such applications have been discovered :-).

Tim.

Thank you, Tim.

Indeed, the electrostatically-deflected CRTs associated with electron
microscopy offer a promising market for such complex deflection
geometries. I will see what I can do with the Windows Media Player SDK
on the one hand, and the Tek scope on the other.

I think that the difference between electrostatically-deflected and
electromagnetically-deflected CRTs is the difference between C and L,
simply put. We have ways of generating high potentials accurately, but
current foldback is less available. Thus, as you wrote,
magnetically-deflected CRT monitors usually sweep the same way each
time. This is more a characteristic of the driving circuitry than the
CRT itself, in my opinion.

Doug

writes in article .com dated 15 Feb 2006 23:48:54 -0800:
No way am I reinventing vector graphics, Tim and Keith.

I jumped to that conclusion based on your statement about using the X
and Y inputs on your scope. Sorry.

--Keith Lewis klewis {at} mitre.org
The above may not (yet) represent the opinions of my employer.

In article . com,
wrote:

Thank you, Tim.

Indeed, the electrostatically-deflected CRTs associated with electron
microscopy offer a promising market for such complex deflection
geometries. I will see what I can do with the Windows Media Player SDK
on the one hand, and the Tek scope on the other.

I think that the difference between electrostatically-deflected and
electromagnetically-deflected CRTs is the difference between C and L,
simply put. We have ways of generating high potentials accurately, but
current foldback is less available. Thus, as you wrote,
magnetically-deflected CRT monitors usually sweep the same way each
time. This is more a characteristic of the driving circuitry than the
CRT itself, in my opinion.

Not entirely. The inductance of the deflection coils is significant,
and prevents fine modulation of the position of the electron beam fast
enough to matter.

Joe Gwinn

According to Joseph Gwinn :
In article . com,
wrote:


[ ... ]

I think that the difference between electrostatically-deflected and
electromagnetically-deflected CRTs is the difference between C and L,
simply put. We have ways of generating high potentials accurately, but
current foldback is less available. Thus, as you wrote,
magnetically-deflected CRT monitors usually sweep the same way each
time. This is more a characteristic of the driving circuitry than the
CRT itself, in my opinion.

Not entirely. The inductance of the deflection coils is significant,
and prevents fine modulation of the position of the electron beam fast
enough to matter.

Typical deflection coils have a serious problem with fast vector
graphics, but there are (or were) custom one, made by Celco (Mahwah
N.J.) explicitly for such purposes, with rather elaborate mounting for
special CRTs, giving very fine adjustment capability for all elements of
yoke position.

I just checked -- they are still in business, and you can start
checking he

http://www.celco.com/ElectronOptics/

In particular, you may want to start he

http://www.celco.com/ElectronOptics/HighSpeedRaster.asp

and note the ones which are specifically listed as "fast settling" and
"low inductance".

However, given the nature of the applications, and the lack of
listed prices, I suggest that you be sitting down when you call them to
get that information. :-)

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

Typical deflection coils have a serious problem with fast vector
graphics, but there are (or were) custom one, made by Celco (Mahwah
N.J.) explicitly for such purposes, with rather elaborate mounting for
special CRTs, giving very fine adjustment capability for all elements of
yoke position.

I just checked -- they are still in business, and you can start
checking he

http://www.celco.com/ElectronOptics/

In particular, you may want to start he

http://www.celco.com/ElectronOptics/HighSpeedRaster.asp

and note the ones which are specifically listed as "fast settling" and
"low inductance".

Enjoy,
DoN.


Boy does that bring back memories. I used Celco yokes on many a job
in a previous "incarnation" :-) at a R&D place in PA. I did a lot
of CRT circuit design for various IR systems. Even made a trip to
Celco to coordinate a special design once. Great people to work
with, at least back in dim dark ages of 1960s.
Thanks for the reminder.
...lew...

According to Lew Hartswick :
DoN. Nichols wrote:

Typical deflection coils have a serious problem with fast vector
graphics, but there are (or were) custom one, made by Celco (Mahwah
N.J.) explicitly for such purposes, with rather elaborate mounting for
special CRTs, giving very fine adjustment capability for all elements of
yoke position.

[ ... ]

Boy does that bring back memories. I used Celco yokes on many a job
in a previous "incarnation" :-) at a R&D place in PA. I did a lot
of CRT circuit design for various IR systems. Even made a trip to
Celco to coordinate a special design once. Great people to work
with, at least back in dim dark ages of 1960s.


Hmm ... IR systems. Did you ever wind up dealing with the U.S.
Army Night Vision Labs? That is where I first encountered IR systems,
with the first being a scanned single sensor printing onto 4x5 Polaroid
film -- made by Barnes, IIRC.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

According to Lew Hartswick :
DoN. Nichols wrote:

Typical deflection coils have a serious problem with fast vector
graphics, but there are (or were) custom one, made by Celco (Mahwah
N.J.) explicitly for such purposes, with rather elaborate mounting for
special CRTs, giving very fine adjustment capability for all elements of
yoke position.

I just checked -- they are still in business, and you can start
checking he

http://www.celco.com/ElectronOptics/

In particular, you may want to start he

http://www.celco.com/ElectronOptics/HighSpeedRaster.asp

and note the ones which are specifically listed as "fast settling" and
"low inductance".

Enjoy,
DoN.


Boy does that bring back memories. I used Celco yokes on many a job
in a previous "incarnation" :-) at a R&D place in PA. I did a lot
of CRT circuit design for various IR systems. Even made a trip to
Celco to coordinate a special design once. Great people to work
with, at least back in dim dark ages of 1960s.
Thanks for the reminder.
...lew...


--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

According to DoN. Nichols :
According to Lew Hartswick :
DoN. Nichols wrote:

Typical deflection coils have a serious problem with fast vector
graphics, but there are (or were) custom one, made by Celco (Mahwah
N.J.) explicitly for such purposes, with rather elaborate mounting for
special CRTs, giving very fine adjustment capability for all elements of
yoke position.

I just checked -- they are still in business, and you can start
checking he

http://www.celco.com/ElectronOptics/

In particular, you may want to start he

http://www.celco.com/ElectronOptics/HighSpeedRaster.asp

and note the ones which are specifically listed as "fast settling" and
"low inductance".

Enjoy,
DoN.


Boy does that bring back memories. I used Celco yokes on many a job
in a previous "incarnation" :-) at a R&D place in PA. I did a lot
of CRT circuit design for various IR systems. Even made a trip to
Celco to coordinate a special design once. Great people to work
with, at least back in dim dark ages of 1960s.
Thanks for the reminder.
...lew...

It looks as though I lost the body of my response. Let's see
whether I can recover it.

Nope -- time to recreate it!

I asked whether your place had dealt with the U.S. Army "Night
Vision Labs". That was where I first encountered IR imagers. The first
was a single detector scanned across the subject while a modulated light
beam wrote the image onto a 4x5 Polaroid film sheet. That one was made
by Barnes, IIRC.

Of course, later there were a lot of other (much faster)
technologies used.

Enjoy,
DoN.
--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Here's something, with thanks to John, Tim, Keith, Tim, Joseph, DoN,
Lew, and Jasen, that y'all might get a handle on.

Mode Common Factor Pad Result Common Factor
640x480 160 2 642x482 2(I think)
1280x768 ?

Perhaps one of you more equipped (my Mathcad is on another machine) can
continue this list. The idea is you can present any standard mode by
padding a few pixels on the border and scanning it diagonally. This
reduces retrace overhead, making somewhat better use of available
bandwidth, and allows zooming (on a CRT) using analog control. The
example pads 1 pixel on either side, er, on every side. Smaller modes
on the order of 100x100 pixels might display well on laser galvanometer
scanners. I have a pair set up with a small laser. They are deflected
by a headphone level drive. The laser is powered from a PS/2
mouse/keyboard port.

I will check out the Windows Media Player SDK with Visual C++ 6.0 which
*is* on this machine. I am thinking of a 4:3 Lissajous pattern made
with triangle wave deflection functions showing intensity of sound as a
wider or brighter trace, or both, and I'd like to put a metronome in
there to lock to the beat of music, when music is the input, just as a
start, to popularize the idea.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

According to :
Here's something, with thanks to John, Tim, Keith, Tim, Joseph, DoN,
Lew, and Jasen, that y'all might get a handle on.

Mode Common Factor Pad Result Common Factor
640x480 160 2 642x482 2(I think)
1280x768 ?

Perhaps one of you more equipped (my Mathcad is on another machine) can
continue this list. The idea is you can present any standard mode by
padding a few pixels on the border and scanning it diagonally. This
reduces retrace overhead, making somewhat better use of available
bandwidth, and allows zooming (on a CRT) using analog control. The
example pads 1 pixel on either side, er, on every side. Smaller modes
on the order of 100x100 pixels might display well on laser galvanometer
scanners. I have a pair set up with a small laser. They are deflected
by a headphone level drive. The laser is powered from a PS/2
mouse/keyboard port.

I've not been following this very carefully (other than the
mention of the Celco deflection yokes), but here is the list of
resolutions available from the framebuffer (unix term for a graphics
card) on my current system:

================================================== ====================
1024x768x60
1024x768x70
1024x768x75
1024x768x77
1024x800x84
1152x900x66
1152x900x76
1280x800x76
1280x1024x60
1280x1024x67
1280x1024x76
960x680x112s (stereo)
960x680x108s (stereo)
640x480x60
640x480x60i (interlaced)
768x575x50i (interlaced)
1440x900x76 (hi-res)
1600x1000x66 (hi-res)
1600x1000x76i (hi-res)
1600x1280x76 (hi-res)
1920x1080x72 (hi-res)
1920x1200x70 (hi-res)
================================================== ====================

The third parameter is the frame rate. The ones marked
"(stereo)" alternate frames between two different views, and an output
signal selects which half of a special pair of glasses you can see
through at that moment.

Feel free to calculate your parameters with those. Note that
the default resolution for most Sun machines is the 1152x900 at one or
the other of the scan rates.

I will check out the Windows Media Player SDK with Visual C++ 6.0 which
*is* on this machine. I am thinking of a 4:3 Lissajous pattern made
with triangle wave deflection functions showing intensity of sound as a
wider or brighter trace, or both, and I'd like to put a metronome in
there to lock to the beat of music, when music is the input, just as a
start, to popularize the idea.

Anything Widows based will not be popular with *me*. :-)

Enjoy,
DoN.
--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

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).

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!
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. 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,
.. 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.

-jiw

ftp://users.aol.com/DGoncz/Publications/1152x864.gif

shows that my Creative Labs Graphic Blaster RIVA 128ZX has accepted a
new definition of the rarely used NeXT mode 1152x864. This was done
with Power Strip.

My redefinition is:

Direction H V Pixel
Rate 60 Hz 69 KHz 69.315 MHz
Pixels 1152 864
Front Porch 0 pixels 0 lines
Sync 8 pixels 2 lines
Back Porch 0 pixels 0 lines

and these are all minimums for the front and back porch, but the sync
vertical must, of course, be a multiple of 2, while the sync horizontal
is the minimum. So this mode doesn't pad by two in available hardware
and it does look like James Waldby was right about my factoring. That's
a lot of pixels for about a 70 MHz pixel clock, but the zoomability is
key, not the lack of retrace.


No conventional analog CRT can display this mode, but I intend to build
or configure one to do exactly that. I will need a stereo audio amp,
two signal generators with trigger or phase lock, and either my Tek
scope or a monitor I can pull apart, at the minimum.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

Hello, all.

Hell, J. Clarke, Tim, Keith, Joseph, DoN, Lew, Jasen, and James, in
particular.

ftp://users.aol.com/DGoncz/Publications/1152x864B.gif

shows a slightly modified version of the redefinition in the referenced
post, but this seems to be a more correct timing calculation. Here is
the modeline and associated information:

(Monospaced Font as before)

PowerStrip timing parameters:
1152x864=1152,0,8,0,864,0,1,1,60268,0

Generic timing details for 1152x864:
HFP=0 HSW=8 HBP=0 kHz=52 VFP=0 VSW=1 VBP=1 Hz=60

VESA detailed timing details:
PClk=60.27 H.Active=1152 H.Blank=8 H.Offset=-16 HSW=8 V.Active=864
V.Blank=2 V.Offset=0 VSW=1

Linux modeline parameters:
"1152x864" 60.268 1152 1152 1160 1160 864 864 865 866 +hsync +vsync

Now you must understand this is designed to be displayed *diagonally*!
The second active pixel in the first scan line will show, with the
correct deflection waveforms, at screen coordinates (2,2), using a 1
basis for the origin in the upper left, that is, an origin of (1,1). I
have not checked common factors for this "mode".

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

ClearEdge VM wideband velocity modulation improves the definition at
picture edges, creating sharper images by slowing the CRT (cathode-ray
tube) beam's horizontal scanning during demanding work--say, when
rendering transitions from light to dark parts of an image--and
speeding it up when scanning easily rendered sections, like broad dark
areas.

From a Sony WEGA blurb....

So it seems there are some possiblities for other than standard
constant velocities in raster scanning.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

(I) wrote:

No conventional analog CRT can display this mode, but I intend to build
or configure one to do exactly that. I will need a stereo audio amp,
two signal generators with trigger or phase lock, and either my Tek
scope or a monitor I can pull apart, at the minimum.

I would do this by running the sync signals into the line inputs and
writing a program to synchronize wave outputs or perhaps MIDI outputs
to the amp if it there were any reason to keep the hardware compact and
PC based. There would be some drift and constant correction because the
video and audio use separte clock crystals.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

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

I wrote:
(I) wrote:

No conventional analog CRT can display this mode, but I intend to
build or configure one to do exactly that. I will need a stereo
audio amp, two signal generators with trigger or phase lock, and
either my Tek scope or a monitor I can pull apart, at the minimum.

I would do this by running the sync signals into the line inputs and
writing a program to synchronize wave outputs or perhaps MIDI outputs
to the amp if it there were any reason to keep the hardware compact
and PC based. There would be some drift and constant correction
because the video and audio use separte clock crystals.

I noticed some kind of adjustable pixel clock in PowerStrip and wonder
if any pixel clock is the same as or can be locked to the sample rate
of an audio stream.

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

On 2006-03-11, Doug Goncz wrote:
I wrote:
(I) wrote:

No conventional analog CRT can display this mode, but I intend to
build or configure one to do exactly that. I will need a stereo
audio amp, two signal generators with trigger or phase lock, and
either my Tek scope or a monitor I can pull apart, at the minimum.

I would do this by running the sync signals into the line inputs and
writing a program to synchronize wave outputs or perhaps MIDI outputs
to the amp if it there were any reason to keep the hardware compact
and PC based. There would be some drift and constant correction
because the video and audio use separte clock crystals.

I noticed some kind of adjustable pixel clock in PowerStrip and wonder
if any pixel clock is the same as or can be locked to the sample rate
of an audio stream.

you'd be hard pressed to find any pixel clocks below 500Khz, (most are well
over 5Mhz) but audio can possibly be resampled or interpolated to get a
similar effect.


Bye.
Jasen

wrote:
Hello, all.

Hell, J. Clarke, Tim, Keith, Joseph, DoN, Lew, Jasen, and James, in
particular.
Aw, hell, I meant, "Hello".

ftp://users.aol.com/DGoncz/Publications/1152x864B.gif

shows a slightly modified version of the redefinition in the referenced
post, but this seems to be a more correct timing calculation. Here is
the modeline and associated information:

Linux modeline parameters:
"1152x864" 60.268 1152 1152 1160 1160 864 864 865 866 +hsync +vsync

That's the best I can do with PowerStrip. What I need is, of course:

"1160x866" 60.268 1160 1160 1160 1160 866 866 866 866 +hsync +vsync

How frustrating.

I have written a Mathcad worksheet using what I call the "snarl
transform", which is 1-to-1, to load the R, G, and B planes with X, Y,
and Z data. It takes a minute to run, but it does what it is supposed
to. The display will be imperfect if I don't get the modeline above to
work under Windows 98.

I suppose I could live with an imperfect display, but for any real
potential to be had from this monitor design, I need an unblanked
display mode that simply streams pixels out at variable rates in a
frame with even edges but no other common factor between edges.

*sigh*

Is this a hardware or a software limitation?

Doug Goncz
Replikon Research
Falls Church, VA 22044-0394

Doug Goncz wrote:
wrote:
Here is the modeline and associated information:
Linux modeline parameters:
"1152x864" 60.268 1152 1152 1160 1160 864 864 865 866 +hsync +vsync

That's the best I can do with PowerStrip. What I need is, of course:

"1160x866" 60.268 1160 1160 1160 1160 866 866 866 866 +hsync +vsync
....
Is this a hardware or a software limitation?

Until I looked at http://www.gameprogrammer.com/3-tweak.html
(which mentions a tweaking program that might be useful to you)
I thought that typical PC display hardware requires a bunch of
those numbers to be multiples of 8; however, that web page
mentions resolution 360x270 so I now don't know what the hw limit is.

BTW, I think "X Windows System modeline" would be a bit better
phrase than "Linux modeline", and that you should attach
an [OT] marker to the subject for rec.crafts.metalworking.

-jiw

[R.C.M removed from followup]

On 2006-03-31, James Waldby wrote:
Doug Goncz wrote:
wrote:
Here is the modeline and associated information:
Linux modeline parameters:
"1152x864" 60.268 1152 1152 1160 1160 864 864 865 866 +hsync +vsync

That's the best I can do with PowerStrip. What I need is, of course:

"1160x866" 60.268 1160 1160 1160 1160 866 866 866 866 +hsync +vsync
...
Is this a hardware or a software limitation?

Until I looked at http://www.gameprogrammer.com/3-tweak.html
(which mentions a tweaking program that might be useful to you)

I thought that typical PC display hardware requires a bunch of
those numbers to be multiples of 8; however, that web page
mentions resolution 360x270 so I now don't know what the hw limit is.

for width it should be multiple of 8 (or with some hardware 16)
for height pretty-much any number will work.

BTW, I think "X Windows System modeline" would be a bit better
phrase than "Linux modeline", and that you should attach
an [OT] marker to the subject for rec.crafts.metalworking.

Actually "X Window System"

Bye.
Jasen

DoN. Nichols wrote:

Hmm ... IR systems. Did you ever wind up dealing with the U.S.
Army Night Vision Labs?

Don,

Did you work for Dr. B at Belvoir?

Kevin Gallimore


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

According to axolotl :
DoN. Nichols wrote:

Hmm ... IR systems. Did you ever wind up dealing with the U.S.
Army Night Vision Labs?

Don,

Did you work for Dr. B at Belvoir?

If you mean the one who I am thinking of -- whose first name is
"Rudi", I did in a sense -- he was in charge of Night Vision Labs for a
few years. But I did not work directly for him in the same lab prior to
that time.

And yes -- this was at Belvoir.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

If you mean the one who I am thinking of -- whose first name is
"Rudi"

That's the man. He used to bring the Starlight Scopes around to the
local schools for show and tell. He eventually ran most of the stuff up
here before he retired (again). We still have a lot of ex-NV guys.

Kevin Gallimore



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

According to axolotl :
DoN. Nichols wrote:

If you mean the one who I am thinking of -- whose first name is
"Rudi"

That's the man. He used to bring the Starlight Scopes around to the
local schools for show and tell. He eventually ran most of the stuff up
here before he retired (again). We still have a lot of ex-NV guys.

Hmm ... are you close to Ft. Monmouth?

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

Hmm ... are you close to Ft. Monmouth?

Within commuting distance...

Kevin Gallimore

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

From: "axolotl"

DoN. Nichols wrote:

Hmm ... are you close to Ft. Monmouth?

Within commuting distance...

Kevin Gallimore


LOL - That was phun, wasn't it ? ;-)


--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp