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

Clay Cowgill wrote:
>
> Just a little update from G-80 programming land...
>
> For whatever reason, my menu system code is now working just fine. The
> only thing I did differently was locate the graphics off in memory up out
> of the "boot rom" area. I probably had an address wrong or something
> before.
>
> (It was pretty cool to see my graphics pop up on the monitor the first
> time. The editor program I wrote worked perfectly! They look much nicer
> on the Vector monitor than the PC too. :-)
>
> Anyway, I was experimenting last night and came up with some new trivia...
>
> 1) Regarding the WG Color Monitor and the G-80 combo:
> Yep, it's the parallel loads causing the occasional vector distortion.
> The frustrating part is that it's completely avoidable just by changing the
> drawing order on the screen! *sigh* Take Space Fury for example-- the
> right side player score "loses" part of a vector. Well, the programmers
> draw the "high score" (center) first, then the left side player score, THEN
> the right side player score. That makes for a big move for the beam (left
> side to right side) and it glitches. 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?

So what do you think the possibility is of hacking the G-80 hardware to
give the WG a little more time. I will have to start looking at my Star
Trek Schems and see what it looks like in there. You though about just
adding a 'wait gate' on the main vector clock right?

-- 
Jess Askey              Atari Game Page:http://magenta.com/havoc
ESLB\The Audio Analyst        
509 S 2nd St Unit B     Wanted: Atari I,Robot PCB  
Laramie, WY 82070               Data East Speed Buggy PCB      
(307)721-9001                   Atari Quantum PCB