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

>----------
>From: Clay Cowgill[SMTP:clay@supra.com]
>Sent: Thursday, May 08, 1997 11:56 AM
>To: vectorlist@goonsquad.spies.com
>Subject: Space Fury/G-80 info...
>
>Just a little update from G-80 programming land...
>
>1) Apparently the WG monitor is OK with
>the deflection speed as long as (first G-80 programming rule-of-thumb:) YOU
>DON'T TRY TO RELOCATE THE BEAM MORE THAN 0x0200 "units" at a time. (That's
>about half the screen, which kinda makes sense as the WG color monitor
>spends most of it's life moving from the center of the screen to the object
>to be drawn and not from one screen corner to the other...)
>
>2) WEIRD drawing characteristic.
> This is a strange one. I was testing the Wells Gardner monitor with the
>G-80 boardset and an adapter trying to figure out the "range" of a move
>that will cause a vector distortion when I noticed the following little
>gotcha... I had a symbol at about 0x02EF on the horizontal axis. The next
>symbol being drawn was at around 0x05C0. This was causing a display
>glitch. So, I started backing off the new x position until the glitch went
>away. Reduced the deflection all the way to 0x0500-- glitch was still
>present, although it was much smaller. Then I switched to 0x04FF. The
>glitch COMPLETELY disappears. (This is much stranger when you see it--
>normally a change of 1 unit only made the glitch move a *tiny* amount.)
>The only thing I can think of is that the way the DAC Counters are loaded
>the high byte loads first, which causes the DACs to start deflecting
>immediately. So a load sequence would be like:
>
>load high nibble with 0x05 (DAC starts off for what is essentially 0x0500)
>load low byte with 0x00 (DAC still goes for 0x0500)
>
>vs.
>
>load high nibble with 0x04 (DAC starts heading for what is essentially
>0x0400)
>load low byte with 0xff (DAC is now going for 0x04FF, but it's already had
>a jump start towards 0x0400 already, so the effect of the full deflection
>isn't felt.)
>
>Any guesses guys?
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!!!

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.

(Of course, since some of the topics on this email list have been about
swapping Atari color XYs and Sega XYs, accidentally mixing Atari and
Sega architectural issues might be useful.)
>
>That's all for now.
>
>-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:00:23 1997