Re: multi-game proto board

>So have you tried this? And all you get is the pincushion effect? No
>problem with filling the entire monitor with vectors? That would make life
>easier. Maybe the Sega Vector systems aren't using the full speed
>capabilities of the GO-8 monitors. That would be nice.

I haven't tried it myself-- others have though and the "distortion" effect
was limited to an occasional miss-placed vector. You could probably drive
the deflection section a little harder, or more likely just live with it.
;-)

>Does anybody know exactly how fast the Sega system sweeps it's vectors? Is
>this in the FAQ? Should I just read the FAQ and stop bugging you guys? Or
>should I shut down Eudora and acutally get some work done today?

I've pretty much given up on the "work" thing today. ;-) When I'm not
replying to these there's been a constant stream of people in and out of my
office...

The Sega vector system is kinda like an Atari Digital vector generator. (A
pair of DACs fed from a pair of digital counters.) It's does some funky
stuff-- the data is stored in a polar format (length, angle) so rotation is
really easy (and handled in the drawing hardware). They make what is
essentially a binary rate multiplier to provide clock (increment) pulses to
the digital counters at the correct rates to draw the lines at the right
speed and distance.

The only "gotcha" as far as the slew rate is concerned when using it with a
Wells Gardner monitor is parallel loads on the counters to the DACs.
(Those can make a big deflection fast when the new position is latched in.)
Otherwise, the max vector slew rate looks to be something the WG monitors
can handle OK. Distortions will kinda depend on the programming then. I'm
trying a little game stuff on the system now, so I'll see if I induce any
errors when programming. I think for new programs at least it's easy
enough to avoid. (Just put some "null" objects in the vector display list
that are positioned at the center of the screen. When these are between
objects that can move around you'll be sure that you'd not drawing in the
bottom right corner and then jump to upper left or something. The null
objects (color guns off, but position information intact) force the beam to
the center so the next parallel load on the counters can be at most a
half-screen jump. For something like "Space War" just draw the sun in
between the player ships... ;-)

The CPU and Vector generators can be separately clocked, so I had kicked
around the idea of dropping the vector draw speed a little to lower the
slew rate, but that doesn't help the (possibly large) fast deflections
caused by parallel loading the counters. (One advantage of the Atari
Analog Vector generator always having to reset the beam to the center of
the screen to get to a known location-- it helped keep those long vectors
and max-deflection jumps to a minimum...)

They have a weird little "protection" mechanism built in for the x/y
outputs. They digitally clip the input values to the DACs. I guess it
saves the monitor from most "programmer" errors writing big deflections to
the DACs, but a failed op-amp or DAC will still make things a bit firey for
the average GO-8. :-/

I gave a bunch of info to Al about the clipping regions and everything
which I think is in his hardware descriptions on www.spies.com/arcade

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Fri May 2 17:00:55 1997