Re: programmable logic

>Of course you can center a DVG anytime you like. But what you can't do
>with an Atari AVG is jump around the screen like the Cinematronics and Sega
>games do. If you want to write your own games you can control the order of
>your list, but if you want to run emulated games (more my goal) you don't
>have that kind of control.

I agree. The only "gotcha" with the instantaneous re-positioning of the
beam is that the color Amplifone and Wells Gardners can't keep up. As a
result of testing with the Sega hardware on a WG I have a rule of thumb:
Don't deflect farther than 1/2 the screen width in a single "jump". (Kinda
makes sense the way the AVG works, eh?) Anything more than about 50% of
the screen width as an instantaneous change results in the a distorted
vector.

>I just picked up a Asteroids Caberet this weekend, and this is the first
>DVG game I own (well I have a non-working Omega Race) so I looked it over
>pretty carefully. It looks like they never did get the draw speed quite
>right since some angles are definitly brighter than others. But I really
>like the way the lines connect *perfectly*. You just can't get the Tempest
>AVG to do that -- I'm talking perfect!

Yep, there's a lot to be said for directly driving deflection with the DAC.
The smaller screen sizes (like 13") with vectors look really sharp too.

>Of course if you're controlling the vector time in software (using the PIC)
>you could probably add fudge factors based on the length of the lines and
>get a better lineup than the AVG.

I was basically going to put the burden of line brightness on the host CPU
and have it loaded as a "line" parameter into the VRAM. The more I looked
at Atari's way of controlling the brightness of all three guns with one DAC
it really works well for fixing line length/brightness problems. Length of
a line is a pretty calculation on a 486 or better, so I was going to use
that for doing the correction.

>Yeah, I doubt if you could even measure the error. The thing about the
>Breseham algorithm is that it appears to be less complicated, and I believe
>I can control the draw speed precisely so that the intensity for any angle
>will remain the same. But the increment test registers must be
>pre-calculated in software or the design would end up be much more
>complicated than the simple *step rate* registers used by Atari.

Wow. That would be really cool. I'd love to have a DVG card. ;-) I just
didn't want to tackle all the issues with a stand-alone state machine. If
you can pull it off that'd be tremendously cool...

>Using PIC instructions I was able to write a Bresenham line draw loop in
>about 12 instructions. So if I want to drive the WG monitor at it's rated
>slew rate I figured I needed to upate a 10bit DAC at a 3.33mhz rate, so I
>need a CPU with a 25ns instruction time. That would be a standard PIC
>running a 160mhz. The new SX could do it with a 50mhz clock since it can
>run an instruction on every clock (no internal divide by 4), giving it a
>20ns instruction time.

One thing to remember about the PIC is that you'll need to bit-bang stuff
like writes to DAC registers and stuff. My actual control loop was really
small for the AVG stuff, but then you start adding stuff like "set DAC1
write low, set DAC1 write high, output data, set DAC2 write low, set DAC2
write high..." etc. Added about 50% in my case 'cause I'm controlling some
digital switches plus the DACs and memory counters...

>It's very tempting to just wait for this processor...

Yep. Particularly at <$5.

>I'm not sure what the speed is, or how ZIP calcuted their spec, but
>currently this is the unknown part of the equations and I'm not going to go
>ahead with any design until I figure out how I'm going to get the data to
>it fast enough. My caclulation was on worst case data using a standard
>DVG. 10 bit starting and ending X/Y data, and a 12bit color - 800k per
>second (wince!). That assumes 500 vectors 40 times a second. On the
>Cinematronics games most only generate around 200 vectors 38 times a
>second, Sundance being the largest at 430+ vectors per frame.

Hmmmm. 800K per second. I just don't think a parallel port can pull it
off. That's more in SCSI 1 throughput range. (*Snicker*, you could make
an IDE/ATA vector generator. ;-)

The Vectrex goes through about 230 vectors max before flicker (so assume
about 33ms refresh, probably a little longer 'cause the monochrome
phosphors have a pretty long persistance).

Curiously enough, Asteroids seems to be tied to a 60Hz refresh rate.
Vector drawing only takes up a fraction of that time though.

I think I wanted about 750 vectors every 33ms, so that's probably pretty
close to your 500 every 1/40th sec...

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Mon Oct 6 16:59:10 1997