Space Fury/G-80 info...

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?

3) Space Fury trivia.
   Space Fury was my guinnea pig, so I found some stuff out as I was going
along, might be useful to someone:

   When the game is running, the player's Ship data is loated at 0xE500 in VRAM.
   During gameplay, the Players ship symbol record is at 0xE0A0
   " " , Center highscore list starts at 0xE190 with each digit
following in 10 byte increments)

   During the docking phase, the player "shells" are at:
   left shell-- 0xE1CB
   top shell -- 0xE1D5
   right shell-- 0xE1DF
   (These are probably located there the entire game, the don't seem to
move stuff around in VRAM once it's running...)

   Left side score start at: 0xE211

   The Star Field symbol record starts at: 0xE1E9

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 08:54:28 1997