PC Vector Generator Card...

From: Clay Cowgill <clayc_at_diamondmm.com>
Date: Fri Dec 05 1997 - 16:04:08 EST

Hi All,

I've been back thinking about making an ISA card that's compatible with
Wells-Gardner "type" vector monitors again.

My original plan was to use a PIC to fetch and decode instructions from
some shared RAM and have the PIC run an Atari-like Analog Vector generator.
I think it'd work, but the more I think about how to compensate for
varying vector brightness there's a lot to be said for something like a
digital vector generator.

Zonn had talked previously about implementing a hardware driven vector
engine by implementing Bresenham's line algorithm on a fast little
controller (like the SX PIC clone), but with the SX tied up in lawsuit-land
that might not fly.

So, I've been thinking of other ways to do it. Curious to hear opinions...

Approach 1: Modified DVG.
Use a 20MHz PIC to run the state machine. Implement the binary rate
multipliers and counter circuits (and as much else as possible) in a CPLD
or FPGA. Advantages-- hardware based, hardware assisted line draws,
minimum of data from PC required. Disadvantages-- take some work to figure
out the programmable logic parts, PIC might not cut it (could do it all in
FPGA).

Approach 2: DSP
I think the cycle time of even pretty lowly DSP's could probably handle the
DDA line draw in ample time. Advantages-- possibly cool DSP based drawing
like splines, etc. Fully programmable. Maybe use cheaper serial DACs.
Disadvantages-- complex to prototype, lots of code to write for DSP, maybe
kinda expensive.

Approach 3: "dot engine"
Thought this one up this morning. Have the PC perform all the DDA line
draws and just store the "pixels" into a linear address space, then the
"vector card" just cruises through memory plotting all "pixels".
Advantages-- gets away from requirement of fast micro on card to rip lines,
simplifies vector card hardware significantly. Disadvantages-- more CPU
overhead for PC, more RAM required for "pixel" storage on card.

Here's some numbers to think about if you're interested in thinking about
this problem. (Hey Zonn, see if you agree with me on these?)

The Atari Digital Vector Generator Binary Rate Multipliers are clocked at
1.5MHz. This means that at maximum rate, each line counter clocks at about
~677ns per "pixel". (Rate multiplier max rate = (1.5MHz*63)/64) Assuming
you want to redraw the display at least once every 30th of a second, that
gives you about--

33.33ms / 677ns = 49218 "pixels" per refresh (max)

("pixel" = clocks to line counter)

Figure you have a 1024x1024 resolution display-- that gives you around 200
lines that go about a quarter the way across the screen (max). These
figures will be less 'cause not every vector generator clock pulse is used
for clocking the line counters. (This makes sorta "back of envelope"
sense-- if each asteroid is about 256 "pixels" in circumference, and you
add in the player ship, missiles, explosions, text, etc, you could still
probably draw an entire game screen with less than 200 lines of 256 pixels
each. Even with 30% overhead for the state machine (130 or so lines of 256
pixels) it's probably do-able.)

Anyway, let's say we want a vector generator that can pull off at least 3
times the performance of the Asteroids DVG (to try to equal the AVG in
performance? that's a completely wild-ass-guess). Everything scales pretty
linearly, so you need a "pixel" plotted about every 225ns on average.

The CPLD/FPGA hardware line-generator solution is looking pretty attractive...

BTW, anyone see any reason why a sufficiently accurate PWM couldn't replace
a Binary Rate Multiplier?

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Fri Dec 5 13:03:28 1997

This archive was generated by hypermail 2.1.8 : Thu Jul 31 2003 - 23:01:04 EDT