RE: 137179 replacements (again)

> They are definitely defined somewhere, I'd start with Jess's page, if
> it's not already there he's going to want to know about it.
>
I used the AVG commands from Jess' write-up when working on Tempest.
They're "close enough". ;-) Tempest doesn't have the beam-intensity control
like MajorHavoc/StarWars/Etc. I think I noticed a bug in the way long
vectors work vs. the doc. Something about the top sign bit. Or maybe that
was a MAME bug. (It would look OK in MAME, but the shapes would be screwed
up on the real machine.) I probably should have been writing that stuff
down...

> That was tossed around a bit in the past. The advantages of DSP (or
> any digital approach) is absolute control of vector position and
> speed. This disadvantage is the need for a very fast DAC (I think we
> figured it needed to be updated at a 6mhz rate.)
>
Yeah, this got ugly when we worked through the timing. Wait a couple years
and we'll have fast enough DSPs. ;-)

> I've convinced myself the best design would be an analog system that
> has direct plotting abilities (the ability to move directly and
> quickly to a new spot before starting to draw).
>
That's probably a pretty good way to do it. There will need to be a way to
insert "wait states" after a reposition to allow the beam to reach the
destination before resuming drawing. (That's the problem with running Sega
G-80 system games on a WG monitor-- the Sega "jumps" to new positions fast.
The WG can't keep up with the Sega's slew rate except for distances about
half the width of the screen given the update speed from the G-80.) The
delay needed after an absolute position jump is relative to the distance
moved, so the delay could be calculated by the host CPU and inserted in the
instruction display list on the fly. Different WG6100's might be a little
faster or slower though, so you'd probably have to err on the side of
caution...

> By placing a CPU in front of the analog system you can add any type of
> scale, palette control, etc.
>
My design basically relied on a fast clock and lots of RAM for the display
list. There are two CPLD's (or one big one) that act as fixed-point binary
accumulators. The upper bits of the adders drive parallel DACs (x and y).
The host CPU loads the display list with a 16-bit color for the color
latches, an angle (fractional binary numbers for delta-x and delta-y), and a
distance. The CPLD's then take off, iteratively adding the delta-x and
delta-y values until the distance is reached. Since the speed of the line
write is dependant on the magnitude of the deltas, the host CPU can always
load slope values to keep thngs "constant". I suppose you could also tweak
the line brightness with the color value if necessary. The scheme relies on
the host CPU for some horsepower in that the host would actually build a
"line list" of things to draw. The idea was actually to be an output stage
for an emulator-- the device driver would interpret the output of whatever
manufacturer's vector platform to be a series of colored lines (so a
"center" command from Atari is really just a "black" line from the current
position to 0,0 -- up to the CPU to pick the angle and distance to get
there).

VRAM was two 280Kx8 frame buffer FIFO's. (Easy for the "host"-- throw an
entire "screen" at the fifo's and toggle the "go" bit on the interface.)

> The current design uses 12 DACs to achieve a 1024 x 768 resolution
> (same as Asteroids). Which is fine for a 19" monitor, you might start
> to notice a little jumpiness in slow moving objects on a larger (25")
> monitor.
>
I think whatever is used we'd probably have to stick with 12-bit DACs. They
seem to be on the right price curve...

What about an analog "relative" system using an 8-bit DAC? Basically use
the 8-bit value to position the beam to an absolute location on a 255x255
screen-- then have all motion be relative, so you get 8-bit resolution from
that point at whatever scale you pick. Wouldn't be good for "long" lines
(tempest, gravitar, etc), but would be nice for "sprite" based games
(asteroids, galaga, etc.). 8-bit DACs are cheap and you can pump data to
them really fast with a little 8 bit micro like a Scenix or PIC or AVR or
something...

-Clay
Received on Wed Jun 9 12:55:04 1999