Bringing vector graphics displays back to life

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi guys,

I have been reading this group for a while and I have determined that you
bunch are probably the most capable group on usenet to answer some of my
questions.

I wasn't born yet in the era of the vector graphics display, and probably
many of those present here too.  So I will give a short explanation, as far
as I am qualified to do this.  Vector graphics terminals are computer
graphics displays that draw lines instead of bitmapped images.  They were
used en masse in the 1960's and 70's.  A vector graphics display is basicly
a computer controlled oscilliscope.  [ref: http://www.cca.org/vector /]

Now I am exploring the possibility of connecting an oscilloscope with X, Y
and 'intensity' inputs to some controller, creating a configuration that can
demonstrate the principles of the operation of a vector graphics display.  I
already have access to the right oscilloscope.  But what controller is most
suitable for this task?  I was thinking I would need something with two or
three 12 or 16 bits D/A analog outputs, running at least at 8MHz.  I could
modify an existing 68000 SBC by inserting D/A circuits, or connect a 8051
controller with some D/A hardware through it's parallel output ports, or
should I acquire a new and complete controller?  Any advice would be greatly
appreciated!

Boudewijn



Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it

Perhaps you could find an old video game board, such as Omega Race or
Asteroids.  These boards used low end CPU's (6800?) to run those games, so
if they could manage it, an AVR or a modern 8051 derivative should be able
to no sweat.


Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

Asteroids65%02, Omega Race=Z80. Both had a digitial vector generator that
generated the lines.

Quoted text here. Click to load it

Check out http://www.zektor.com .

-->Neil



Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it

Ah, in that case if you can find one of these boards, you could
scrounge that, maybe.  Of course, finding the documentation could be
interesting...

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

Just get one of these.

http://zektor.com/zvg/index.htm

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

At $239, I'll pass...

Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it



We chose AVR's as the controllers since they were the only small 8 bit processor
that had fast enough timers.  Most micros *really* want to divide their CPU
clock by 2 or 4 before feeding it to the internal timers. AVR can use the CPU
clock directly for their timers.

We went with an analog vector generator that works like this:

Place an analog switch between the output of the DAC and a capacitor to GND,
then place another analog switch between the output of the DAC and a resistor
and then to the same capacitor:

                             |\
 [DAC]-+-[START-SW]--------+-| >---> to X or Y channel of Vector display.
       |                   | |/
       +-[END-SW]----/\/\/-+
                           |
                          ---
                          ---
                           |
                          ---
                           -
                           .

duplicate the circuit for the X and Y channels.

The start of the vector is selected by setting the DACs to the vector start
positions, then turning on the START_SW's, the DACs charge quickly to the
vector's starting position.

START_SW's are turned off, and the caps act like sample and hold circuits.

The DACs are then set to an ending voltage (that is way beyond the real ending
voltage of the vector's endpoint), and then the END-SW's are turned on, the
Z-axis is also turned on, the capacitors begin charging to their new values and
the vector length is very precisely timed, and then both the END-SW's and the
Z-axis are turn off -- before the caps actually reach the ending voltages of the
DACs.

That's the block diagram overview, however the ZVG is much more complicated than
that. In order to refresh a 1000 endpoints at 40 to 60 frames per second, we had
to use an ECP parallel port interface (the serial port doesn't even come close),
so also embedded in the ZVG is IEEE 1284 compliant firmware to communicate with
the PC. We also had to write DOS IEEE 1284 routines for the PC. The 1284
protocol is used to send/receive the ZVG low level commands used to indicate the
starting and ending points of the vectors being drawn. Since the ECP ports were
still not fast enough, the command set compresses the vector information,
removing redundancies between sequential vectors.  This instruction set was
carefully worked out between me and Neil (the guy that wrote the message I'm
replying to.), his Arcade Emulator (Retrocade) was the first to support the ZVG.

Another thing is that we drive yoke based vector monitors, which add another
level of complexity to the Vector Generator.  The yokes create pincushioning
effects that must be compensated for using analog multipliers, also the images
bloom near the edges of the CRTs which is corrected for using variable gain
amplifiers.

There's also a subtle, but pain in the ass problem with driving yokes, that does
not exist with oscilloscopes. There is a delay between the time you start the
vector moving and the yoke responds, (caused by the yoke's inductance), there is
also a delay between the time you stop the vectors movement and the trace stops
moving. These times are not symmetrical.  So you must start the vector movement,
wait for an amount of time that is based on the yokes specs, turn on the Z-axis,
finish timing the vector length, turn off the vector generator, wait for the
yoke spec's amount of time, and then turn off the Z-axis.  (It actually gets
worse, for small vectors: Start vector movement, time vector length, Stop vector
movement, wait, start Z-axis, time vector length + yoke delay, turn off Z-axis,
since the delay can be such that the vector is fully drawn before the yoke
starts to respond.)

These timings need to happen with the resolution of an 8mhz clock to handle the
various timings needed to emulate all the 80's vector arcade games, on the
vector monitors used at the time. This means a *lot* of cycle counting in the
firmware with IRQ's disabled. There was no way to do this and run a 1284
compliant interface, so we used two CPU's, one for the I/O code (and timing
calculations) and another's whose only purpose is to precisely time the Vector
length and Yoke delays.

The ZVG is probably a bit overkill for what you (you - as in the original
poster) would want (actually you were looking for a project, not a solution ;-).

We don't make any money selling ZVGs (We support ourselves by manufacturing
Audio/Video switching equipment), at $239 (similar to the price of a high end
video card) it will never pay for it's development costs, but it will most
likely (*hopefully* ;-) pay for the parts and labor involved in having them
manufactured.  (Of course if someone wants to buy a 1000 of these, we can talk
about a $100 / board price! ;-)

We built the ZVG (www.zektor.com/zvg) simply because *I* wanted one!  Running
all the 80's Vector Arcade games on one vector monitor is just too cool! ;-)


-Zonn
---------------------------------------------------------------
Zonn Moore    
Zektor, LLC
www.zektor.com  

Remove the ".AOL" from the "From:" email address to reply.

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
able
solution

Right.  But still you provided useful design information and an interesting
story.



Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it

The biggest issue is one of performance.  Unless you scope is a storage
scope (rather unlikely), you will need to continually refresh the
image.  The speed of the controller determines how many vectors you can
draw without flicker.  That will also be influenced by the persistence
of the phosphor.

For any reasonable performance, I think you would want to build a vector
generator, either with analog circuits or high-speed digital.  In the
past they were mostly done with analog generators which, I think,
generated a smooth ramp from the starting to ending voltage on both X
and Y coordinates.

If you just want to demonstrate the principle, you could do that with
simple software, but you would be limited in the number of vectors.  You
could drive D/A converters with a Bresneham algorithm.  Let's say that
you can generate a point every 10 us (probably aggressive for 8051) and
that your scope resolution is 256 x 256.  Say you average vector is 50
pixels long.  That would be 500 us. for the vector.  If you refresh 30
times/second, you could draw about 66 vectors.  That's why
vector-generating hardware is used.

Thad

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
Y
can
display.  I
Quoted text here. Click to load it
most
or
could
8051
greatly

I was thinking I could connect some simple circuit to the DAC outputs, which
would create ramped lines.

Quoted text here. Click to load it

66 vectors is far too little, IMHO.  I want to create something impressive.



Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
... snip about vector generators for xyz scope ...
Quoted text here. Click to load it

You didn't like the cheap 7 segment stroke generator I described
earlier?  Seems that writing generatable chars all over the screen
should be fairly impressive, especially since you don't have to
change the hardware to go to 15 segments, or whatever.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

You're right, that should be impressive.  I certainly like the idea, and I
will take it into consideration.  The thing is that I was still trying to
understand the basic operation scheme you proposed.  Maybe you can
elaborate?



Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

I am not very good at ascii art.  I assume you know what an analog
integrater looks like.  You have an X and a Y register, together
with D/A converters, outputing the basic XY scope position through
a mixer.  The mixers are just resistors meeting at a virtual
ground (the - input of an op amp).  The mixers give you the
opportunity to inject a perturbation to the basic X or Y position,
which comes from 2 the integrators (a deltaX and a deltaY for each
of the fundamental X and Y values).  Don't forget you have a Z
input to enable or disable the dot at any time.

You feed inputs of +1, 0, or -1 to the integrators.  The quiescent
state is with 0 input. You make sure that the net input over a
drawing cycle is zero, which means the trace returns to the
starting point.  How to ensure this over many cycles is a problem,
which might be handled by a long time constant from the output to
the input to stabilize the DC base value.

Your controls are the integrator inputs, the X Y base values, and
the Z axis modulation. To display a point you move there, blip the
beam on, making a dot, then either move on to the next or energize
the multi-segment sequence, and then move on.  This is all
software.

I could sketch the circuit in 5 minutes.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it

This is the approach Atari took on its later X/Y generators, for games like
Tempest, Space Duel, etc (I'm not sure how many Arcade collector read this
group, the list goes on, but if you weren't there in the '80s you won't
recognize the titles. ;-)

One thing you have to worry about using this approach is drift. The integrator
will drift and since your only frame of reference is your current position, the
errors will accumulate.  Atari solved this problem by placing an analog switch
across the integrator's capacitor, and periodically (usually a few times per
screen refresh) discharging the capacitor, allowing the moves to start from a
known position (the center of the screen). Small offset voltages in the +1 0 -1
feeds (which come from bipolar DACs unless you only want to draw 0 45 90 and 180
degree angled vectors), also caused them to place an analog switch at the inputs
of the integrators.

You also cannot "jump" quickly to the start of a new vector, but must turn off
the Z-axis and move there.  This and the drift problem were what kept us from
using this approach.  We needed to be able to emulate Vector Generators that
could jump quickly to new positions in order for us to keep up with the game
code.

However this approach is probably the easiest from a software point of view, the
vector length time is linear (this is not true for the RC approach we used),
which makes the timing routines much easier to calculate and the firmware much
easier to write.

-Zonn
---------------------------------------------------------------
Zonn Moore    
Zektor, LLC
www.zektor.com  

Remove the ".AOL" from the "From:" email address to reply.

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

I used it in the early '70s for annotation of screen displays.  I
never got into video games.  These were PHAs (Pulse Height
Analyzers) for nuclear physics radiation analysis and some other
instruments for medical work.

Quoted text here. Click to load it

Our systems always used z blanking.  We were basically plotting
counts vs a position, or sometimes a 3 dimensional version by
mixing x & y values to form hor/ver base positions and using the
counts to add to the ver value.  We could afford slight drifts
from the annotation integrators, as long as it did not accumulate.

The idea is to make the net position change zero, and also to zero
the net dc effect of the integrator inputs.  That means starting
the trace from the middle and returning there.  This also means
some 1/2 segment moves, which is trivially done by adding those
moves to the start and end of the segment path.

Having done that you add a long rc time constant, relative to the
segment trace interval, from the integrator output to its input.
This does not include the basic XY position.  Now long term drift
goes away, and the picture no longer walks slowly off the screen.

The pattern traced looks roughly like:

     ____
    /_ _/  ____one of these two horizontal half segments
   /___/       is traced twice forward and back (while
               blanked at trace start/end) and takes 1/2 the time

The integrator looks like:

                   /| Voltage
                  / | follower
             +---O  |----------o---BIG C---gnd
             |    \ |          |
             |     \|          |
             R3                R2
             |                 |
             o--- C int -------o
             |                 |
             |     |\          |
             |     | \         |
  in ---R----o-----|- \        |
                   |   \       |
                   |    0------o------To mixer
                   |   /      
              +----|+ /
              |    | /
             gnd   |/

You might want to complicate the DC feedback by using another
opamp as a voltage follower in the path to R3, which greatly eases
the selection of R2 R3 and BIG C.  Now R2*BIGC controls the
timeconstant, and R3 controls the gain, independantly.  R*Cint
independantly controls the actual integrator.

To do this you have to design out the DC components of both the
output and the input of the integrator.  If the input is a
switching level (Vsat from gnd) you can supply the integrator +
reference from a similar Vsat.  This will temperature compensate
drift.

This transfer function could probably all be simulated perfectly
well with a fairly complex numerical chip, just as filters have
gone that way.  But op-amps are still cheap, as are R's and C's.
The cost is board space and assembly time.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
can
Quoted text here. Click to load it


That can be done, but I suspect that it won't be simple (at least for me
-- I'm not an analog guru).  I think that the slewing rate should be
fairly uniform, regardless of distance.  On one such system I used, the
Z drive had to be delayed slightly for the ramp to take effect.  If you
use an analog circuit for slewing, you will need to be fairly accurate
in terminating the ramp and Z drive.

Thad

Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
far
basicly
can
I
most
greatly

http://www.zektor.com

-->Neil



Re: Bringing vector graphics displays back to life

Quoted text here. Click to load it
far
basicly
can
I
most
greatly
I did Tempest signal analysis for the USAF during the mid 80's when Tempest
was considered a threat.  I had an oscilloscope that had X, Y, and Z-axis
inputs.  The Z-axis input was sometimes labeled the "intensity" input.
Anyhow, I was able to display a television signal on an oscilloscope by
playing the demodulated television signal into the Z-axis input on the
scope.  The X input was fed with the horizontal clock signal, and the Y
input on the scope was fed with the veritcal clock signal.

If I remember correctly, the resulting picture was upside down, but we were
using this test to read monitors from local office buildings, not to watch
television, but the same principle applied.  Perhaps you could do the same
thing?  Just display some graphics on a monitor, then put an FM receiver
near the monitor, tune it a little and then feed the demodulated output into
the scope's Z-axis input.  You would need to generate the X and Y signal
inputs somehow.  I think that either the X or the Y signal was a sawtooth
waveform.  Sorry I'm not being too helpful, but I think that this approach
might be less expensive, and I know that it will work.



Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it
probably
were
Y
display.
Tempest
were
into

I think you missed the point.  My intention was to demonstrate the
principles of the operation of a vector graphics display, not to use a scope
as a raster display.  Besides, your idea could be realized in under 8 hours,
which is far too less for the assigment ("come up with your own 80 hour
task, which must be approved by a teacher").



Re: Bringing vector graphics displays back to life
Quoted text here. Click to load it

The normal vector generation technique does NOT require DACs that fast.
Instead, the hardware only writes to the DACs for the line endpoints.
The analog circuitry charges (or discharges) a capacitor to ramp the
deflection voltage.

Go to the library and find the November 1976 issue of Byte.  Read Steve
Ciarcia's article "Make Your Next Peripheral a Real Eye Opener" And
maybe some other articles in that issue; I think at least one other
article covered vector generation.

There's errata to the article in the March 1977 issue.  I haven't read
that, so I'm not sure exactly how relevant/important it is.

A few years later Byte ran a construction article for a complete
standalone intelligent vector graphics system, based on Ciarcia's
vector design.  I don't recall the title, author, or exactly when it
appeared.  Early 1980s, I think.

For fun, look up "How to Implement Space Wars (or Using Your Oscilliscope
as a Telescope)" by Dave Kruglinski in the October 1977 issue.

Site Timeline