RE: Space Fury/G-80 info...

>You could prove your point by having the first object at 0x210 instead
>of 0x2EF and rerunning your test of having the next object at 0x4FF or
>0x500. This would show that the above rule of thumb isn't seperation of
>objects by more than 0x0200, but instead separation of object's high
>order byte by 0x02!!!

Hmmm. That's worth looking at. I'll play around with it.

>Assuming your hypothesis about the high order byte is true, when the
>beam is recentered on the screen, it'd better be at 0x??50 and not on a
>boundary like 0x??00! If recentering occurred on 0x??00 then one half
>of the screen would be more likely to have a glitch in it. Of course, I
>may be mixing Atari and Sega architecture issues, since I think someone
>said that only Atari "centers" the beam between objects....hopefully I'm
>not mistaken and inadvertantly muddying the waters.

The "center" of the G-80 display is 0x0400, 0x0400. I don't think that
makes too much of a difference conceptually though since vector objects can
have positive and negative deflections in equal amounts. The point that
drawing starts at is just a position that is being converted to an output
voltage in the monitor so that 0x400,0x400 should be essentially 0V,0V (no
deflection).

(just kinda thinking while typing here)

The Sega Vector system can move the electron beam to an absolute position
on the screen, then it draws a series of relative moves that are
essentially polar coordinates. (An angle and a length to travel in.)

For the Atari Analog Vector generator the only time you *really* know where
the beam is at is right after the integration caps were discharged which
brings the deflection voltage to 0V,0V. So, since the analog integrators
tended to have some drift, and since it makes the code easier, Atari did a
lot of "zero integrators" move to new location, draw new object there,
lather, rinse, repeat.

So an Atari-ish way of putting objects in four corners would be like:

Center beam
move to upper left corner, draw object
center beam
move to upper right corner, draw object
center beam
move to lower right corner, draw object
center beam
move to lower left corner, draw object
(So the beam generally never moves more than half the screen at a time)

Sega seems to do more of a:

move to upper left corner, draw object
move to upper right corner, draw object
move to lower right corner, draw object
move to lower left cornet, draw object

This make for beam moves that span the entire screen instead of a maximum
of half the screen. Since Atari generally wouldn't have encountered this
behaviour given their hardware, they probably didn't notice the "problem"
in the monitor. If they did, the answer is simple-- don't do that. Center
the beam and do your next move. ;-)

So, I think that it's probably the amount of relative deflection that's
getting us with the vector glitches. Although since it looks like the DAC
counter values get loaded in two passes (high nibble, low byte?) there can
be some amount of time in between when the low and high values of the
deflection words are latched when the DAC can be causing deflection before
the full value is loaded. (?) This would make certain situations (mainly a
transistion from 0x0NFF to 0x0(N+1)00) more prone to distortion, but only
when the total deflection difference is somewhere near the (imperically
measured) 0x0200 units.

I suppose I could look up the maximum vector slew rate from the WG manual
and calculate what an instantaneous load of maximum deflection would do on
the DACs... (This also tends to explain why the "stray vectors" go away
when you reduce the size of the picture to roughly half the normal picture
size... :-)

Maybe this was all redundant. I'm just kinda making this up as I go along
and maybe it'll jog an idea from someone else. ;-)

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Thu May 8 10:49:26 1997