Re: Playing Vector Games on the Big Screen

On Fri, 31 May 2002 02:01:33 -0400, Robert Mudryk <rob@lasers.org> wrote:

>The information above is defiently 100% correct
>
>Lets start with from the information that I've read over the years and talking to EE that have worked in Analog
>Electronics for 10-20 years
>
>First the galvometer: for reference http://www.camtech.com/technology/dual_led.htm model 6800 with the 678xx
>series amps
>Limiting factors, mass and inertia, these galvometers/amps have been designed for 99.9% linearity
>
>Vector Monitor: limiting factors Rise, leakage, and settle time.
>Now because Galvometers are alot slower and faster dacs and drive transistors... Galvo's of today don't suffer
>from the limits of the driver.. but the basic drive circuitry is almost identical.. aka they are both driving
>magnetic coils...
>

The drivers are similar, but the driver for a CRT monitor does not depend upon
the characteristics of the monitor, other than require the monitor be as fast or
faster than the driver. The fact you're driving magnetic coils is a moot point
on a CRT, electrostatic screens work just fine (ala oscilloscopes), it's just
that yokes make for cheaper monitors.

Where as the inertia of the mirror in a Laser system is very much apart of the
whole display system. It is expected to overshoot to allow things like circles
drawn with six points, etc.

>Lets start with why we use "Velocity Points" in laser, aka putting multiple points along the length of a
>vector... drawing a line from edge to edge... It's going to be brighter where I started, dim in the Middle,
>then brighter where we are stopping at the end of the Vector.
>
>In a Vector Monitor... if I do the Same... I am going to get a almost invisible line, and point at the end of
>the line. Put Asteriods on a 20mhz Scope... you will see what I mean... you get dots not lines...

Just a side point here, put a scope on a Tempest monitor and you do not see
those points, it uses an analog vector generator.

You can also see those points on an Asteroids monitor if you turn down the
brightness and tweak the focus just right. The Asteroids monitor is faster than
the Asteroids vector generator, and can display the individual dots if you keep
the brightness from causing adjacent dots to overlap.

>so Vector
>Monitors suffer from Acceleration very rapid acceleration but it's still acceleration

It's referred to as the slew rate.

>(aka it takes 250ns
>minumum for the AD561 to reach it's next step)

That maybe true, but the AD561 is on the vector generator, not the monitor.

> then the op amps, transistors, drive transistors... they have a
>rise time as well...

That's also true, but these rise times are completely swamped by the inductance
of the yoke. The yoke inductance and the voltages used to drive the yoke are
pretty much the determining factors of the slew rate of the monitor. The drive
transistor and op amps at least an order of magnitude faster than the yoke.

>In asteroids, I thought this was pretty cool... the "Z" axis or intensity signal, has
>the 4 Scale bits tied to resistors to give extra boost in Intensity for longer vectors.

Well, it at least allows for 16 intensities, though Asteroids doesn't seem to
use them all. The length of a vector on asteroids does not change its
intensity, though the angle does, but not by enough that Atari did any
correction for it. This is all explained in Jed Margolin's Secret Life of XY
Vector Generators: <http://www.jmargolin.com/vgens/vgens.htm#Digital Vector>

>Also by adding more points along the line, it minimized the effect of non-linear rise time...

Asteroids adds all points along the line.

The divisors going into the DACs are used to change the angle of the line. One
DAC is driven at the full 1.5mhz, the other one is driven through a divisor to
step the second DAC at a lower rate, allow angle lines to be drawn.

>Transistors, have leakage, aka over shooting...

Leakage is not overshoot, the voltage does not "jump back" after leakage. You
must simply add any leakage value to the calculated value of a voltage. It's
more of an offset.

> defiently not as previlant as Laser, but it's a factor that
>has to be considered in the code, I've read in the comments from I can't remember what game programmer that
>did discuss this and what I called "Acceleration" in the previous paragraph.
>
>
>In a nutshell... analog electronics are not 4th dimential 0 time devices... they still suffer from the time it
>take to move from volt to volt

Ok, that clears things up! ;^)

>
>Reference info:
>
>Working with Asteriods... main components AD561 (10 Bit DAC), 2n3717/2n3792 drive pair
>
>first the AD561, is a amazing DAC for it's time, minimum Settle Time 250ns, effective load and output time
>1.1us (or about 1 Million loads per second) http://www.analog.com/productSelection/pdf/1161_a.pdf
>
>the 2n3717 is another high performer, a Hi Fidelity Audio Drive Transistor... I think this is where the 6MHZ
>is coming from at least from the NTE replacement datasheet, on the 2N3792 datasheet it's spec'd at 4MHZ
>minimum... otherwise I can't find any meantion of 6MHZ on any schematic on Asteroids or the G05 Service

Yeah it's not there, you know crow is not really that bad. Call it the other,
other white meat!

>> The DVGs (which are Lunar Lander, Asteroids, Ast Deluxe(?), Sega Systems, Omega
>> Race, did I miss anything?), use 10 bit DACs, and plot every point of the
>> 1024x768 point space available on a vector monitor.
>
>Yes the monochrome games

Well, some. Sega systems were all color. And I believe Red Baron used an AVG,
and it was black and white (Ok, monochrome for the laser inclined where "white"
is a more sacred color ;^)

>> So a line drawn from the upper left corner of the screen to the lower right
>> corner consists of 1024 individual steps of the 10 bit X-Dac, and 768 steps of
>> the Y-Dac. The DACs are clocked at a constant 6mhz speed, as are the sample and
>> hold, and data latches associated with the DACs. Since this is faster than the
>> CPU even ran, a state machine made up of discrete components was used to clock
>> the DACs (among other things.)
>
>That would be interesting but looking at even the test patterns in the G05 manual, there isn't a stair stepping
>going on, and looking on the scope from the Asteroids board, I would assume on a 6" screen... I'd almost have a
>solid image... very digital looking but a solid image, if they plotted every point. also I am deducing
>because they have logic in the "Z" axis to "normalize" intensity, but that also could be a function of the
>analog multiplier, as it's spreading the points apart after the DAC's... but then it wouldn't make sense
>because they really couldn't compensate for the pincushion in the same way

Pincushioning in a B&W monitor is done be proper placement of magnets around the
yoke, so you don't need to do it in the VG, and Asteroids does not correct for
pincushion in its VG. Pincushion can also be fixed by proper yoke design,
(magnets don't work on color monitors), but this was not done for the WG
monitors, and so must be done by the VG.

As for how Asteroids work, don't take my word for it, once again, check out the
webpage by Jed Margolin, a very literate ex-Atari engineer that describes the
workings of the Asteroids DVG in very small detail.

<http://www.jmargolin.com/vgens/vgens.htm#Digital Vector>

The Digital Vector Generator splits the CRT into 1024 by 768 pixels and steps
through them to draw a line, exactly as you would if you were drawing a line in
a frame buffer, without the memory of course. Unlike a frame buffer, to refresh
you have to keep drawing the vectors over and over again.

>> For AVGs the PPS can be thought of as infinite. These systems use some type of
>> R/C circuit to control the speed of the CRT trace. Since the CRT trace follows
>> the movement of a charging R/C circuit, the beam is not stepped 1024 times when
>> drawing a full screen diagonal line, but an infinite number of steps (if you
>> want to think of it that way, you can also think of it as one perfectly smooth
>> step) are drawn from one corner to the next.
>
>>
>> In all cases the CRT is designed to be faster than the control board, and is no
>> way depended upon to react a certain way to draw a pattern -- except that it
>> must be fast enough to keep up.
>>
>> If you try to drive a CRT like a laser system you will have some real problems
>> with repeatability. Also, six points on a CRT will look like a hexagon since
>> there is no "overshooting" (for the most part) in the CRT world.
>
>all depends on the settle time of the DAC, and also waiting for the scanner to get to it's destination before
>going to the next point... the galvo's we use are closed loop... position sensors, etc... if you give it
>enough time between points... it will be a hexagon, the same as a CRT, and if you do 6 point hexagon, as fast
>as the DAC can put out, you won't see the line, and it will be a circle just like a laser... like you said in
>the next paragraph... the yoke is a limiting factor

True, but a CRT is *never* run in this mode (at least by the current crop of
Arcade X/Y generators). There is no "tuning" of a CRT monitor, and different
monitors from different manufacturers have wildly varying slew rates. Drawing a
circle this way could not be relied upon to work the same from monitor to
monitor, and would never look right on a 'scope.

>> Simply setting two points on the screen will not draw a straight line between
>> the two. To see this, turn up the brightness on a Vector game and look at the
>> retrace lines, they are not straight but move as fast as the yoke, and drive
>> electronics will let them.
>
>>
>>
>> Like a Laser you can set more and more points, to make things better. Of course
>> this will eventually lead to the DVG which sets points at 6 million per second.
>
>shit you might as well be doing raster, that's more resolution than a TV

Your damned right it is! That's why vector monitors were so cool! High
resolution, without high frame buffer memory! That and a standard TV can't even
display an 80 column text screen readably. TV resolution kinda sucks!

But as far as a comparison to a raster monitor I'll quote from Jed's page:

"In a Digital Vector Generator, each XY position comes from the output of a
counter so the result is similar to what you would get by using a frame buffer
[Jed's nomenclature for raster display]. Since the Digital Vector Generator in
Lunar Lander and Asteroids used 10-bit DACs we have a screen resolution of 1024
x 768. (We actually could use 1024 x 1024 but then the 4:3 aspect ratio of the
CRT produces different X and Y scaling values.)

As a result, lines have the same stair-stepping that you get in a frame buffer.

So, considering the effort that was required to develop the technology (the XY
Monitor as well as the Vector Generator) the question is, why did we bother?

The answer is, that in 1978 when the Digital Vector Generator was developed for
Lunar Lander, memory was much too expensive for a frame buffer in a video game.
The first game to use a frame buffer was several years in the future (Missile
Command) and even then, it was low resolution. (It may have been 512 x 384, but
I'm not sure.)

Even in 1980, the latest and greatest DRAM was 16K bits and cost about $4.80. A
single 256 x 256 x 4 frame buffer would have required 16 devices at a cost of
$74. Two frame buffers would have required 32 devices costing $148 just for
memory, which was more than the cost allowed to manufacture the entire PC board.
Two frame buffers of 512 * 512 * 4 would have required 128 devices costing
$614."

Cheap memory helped kill vector displays...

>> Or you can play with the number of points until it looks ok. Then when you run
>> this on a different monitor you will see much different results (especially if
>> it is a different make or manufacturer) since the slew rates between different
>> X/Y monitors can vary greatly.
>>
>> >and 6mhz? is that the main Processor or the State Machine Processor?
>>
>> This is the speed the DAC is stepped, or more precisely the sample rate of the
>> DAC.
>
>I should have read thru your entire message first... as the last 4-5 paragraphs describes exactly how
>Mechanical Scanners and the CRT are the same, and how they have the same limitations

I was agreeing that they could be run the same way, but that's not how it's
currently done.

>> >the State Machine Processor drew
>> >all the vectors which it read not actual vectors, but instructions on how to build the vectors from shared
>> >memory from the main processor
>>
>> >>
>> >> > just need to be able to output the frames at a fixed rate, 60fps
>> >> > (200-600 Vector Points) for Asteroids and I think 20fps (1000+ vector
>> >> > points) for Star Wars
>> >>
>> >> It's 45fps for Asteroids and 30fps for Star Wars.
>>
>> If Neil says this is the case, this is the case. ;^)
>
>I simply went by the FPS set by MAME.. 60 for Asteroids, and 30 for Starwars... I didn't have the source code
>in front of me when I wrote the other message...

Yeah, that's the problem with converting X/Y systems to raster monitors. You
loose the variable rate refreshes. Atari games refreshed at whatever speed the
programmers decided to refresh at.

>> Ok, so if you've read this far, then I'll let it slip that me and a couple of
>> other friends (partners?) are also working on a PC->VG.
>>
>> So far the vectors look beautiful (though I haven't got the new "single supply"
>> dac version running yet to see if they'll still look as nice. Other things that
>> remain to be tested is the PC->VG interface speed, the redesign of the
>> pincushion circuit for the WG monitors (we're trying to eliminate the MC1495),
>> and the VDR replacement to eliminate bowing.
>
>do it in the emulator... why deal with the analog multipliers... x*y^2 doesn't take that many clock
>cycles... well at 6 million points per second, nevermind you'd need 50 million floating point instructions per
>second

Which is one of the many reasons we went with an analog generator. Stairstepping
was a big one. I really like the look of analog vectors. Our reasons are very
similar to those Atari used to move from DVG's to AVG's.

If you're going to generate vectors, you want infinite resolution -- at least as
much as the monitor allows (no stepping!) to take full advantage of a vector
system look. As you stated earlier, you might as well use a 1024x768 mode
raster monitor and turn the brightness way up, if you're going to plot the
points digitally, anyways!

>> We're trying to get this all
>> working before the CGE in Vegas this year... On the emulation side I'm getting
>> (*mucho*) help from one of the "World Renowned Experts in Vector Emulation". ;^)
>>
>> I'm really interested in seeing how a laser system would respond to VG that
>> treats it like a CRT (assuming it is slowed down to the speeds mirrors need to
>> move.) I think it would act like an infinite PPS system with no ability to draw
>> circles, but the vectors should be nice and straight and consistent in
>> brightness...
>
>The PCI card I am using now, can do at least 200kpps, all I need make is convert the signal to un-balanced and
>voltages, then apply a analog filter to slow down the slew rate of the dacs... I know someone that actually
>was able to slow down the rate enough on the CRT to pretty much emulate how the galvo's react at 12kpps... I
>bet at 150kpps I can emulate every vector game that was made in the 80's I'll prove it one of these days :)

Instead of slowing down the CRT to run laser games, we're designing a generator
that is fast enough to play all known vector games at their original speeds (if
you have the monitor that can support the speed of the game). I'm interested in
a VG, that if placed inside a Tempest cabinet, and set next to a real Tempest,
you could not tell which game had the real Tempest hardware, and which one was
ours. (Except that our vectors would line up better! ;^)

My card cannot be rated in PPS (it's analog, it has infinite PPS), but can be
rated as vectors per frame. Each vector has a starting point and an ending
point. There are no points in between, vectors are drawn by controlling the
speed of the trace as it makes it's way from the first point to the second.

The limiting speed will probably be the interface between the PC and the board,
which will be a parallel port running in the ECP DMA mode, using a compressed
instruction set to describe each vector's position and color.

-Zonn
---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to neil@synthcom.com.
Received on Fri May 31 23:26:43 2002