RE: 137179 replacements (again)

> The AVC IC has a push-pull stack onboard so that the vector generator
> can JSR and RTS up to a depth of 4(?). So the RAM is required to store
> the return address on multiple subroutine jumps.
>
Rumor has it that the AVG ASIC's only have a three level stack. I haven't
verified that though...

> The basic idea of the Atari Vector generator is that the vector RAM is
> where the main code is written by the game CPU. For all the individual
> objects on the screen, the code just JSR's to a section of the vector ROM.
> Sort of like sprites, the vector ROM has a big index table in the
> beginning
> so that every object can be referenced by a number, makes the graphics
> organization nice
> and easy.
>
Now that I've used it for a while, the AVG system is really pretty cool.
You can mix and match "shapes" (pre-defined sprites or whatever) with
free-form line instructions at will. (Something that would be a real
rat-bastard to pull off with the Sega G-80 system for example.)

The only thing I *don't* like is that the hardware doesn't do rotation of
sprites for you (like the Sega G-80 does). If it had that it would just be
too cool. And separate X and Y scaling would be neat too. ;-)

One thing that's a little odd (but makes sense when you think about how it
works) is that your scale factor applies to everything once you set it. So
your "absolute" screen coordinates are only absolute if the scale is right.

Atari seemed to generate the vector-list on the fly (adding objects to it
sort of like a big linked list). I took a slightly lower-tech approach and
put objects in specific locations of VRAM and *didn't* allow them to move
around. That made it a lot easier to do the bricks in V-Breakout, and some
of the "automatic" animation the ISR handles. The downside is that if you
need to add something all your offsets move. :-( That's bad because VRAM
addresses don't equate to vector generator addresses 1:1, so all the
defines/equates change.

I finally came up with a pretty good way to do it. All my "static" stuff
(locations that don't change) sit in low VRAM memory. Then I just have a
single "jsr" up to higher memory. The higher memory areas have sort of a
"goto chain" where one routine chains to the next. For everything I want to
draw I start with a h'40, h'80 (center) instruction. If I don't want to
draw that at that time the main program changes the center instruction to a
"goto" to the next routine to draw. Works pretty well-- you'll notice in
V-Breakout that to reduce the chance of burn-in the attract mode sometimes
plays the game and shows the title, then it'll only show the title, then
it'll only show the game, etc. Just "goto's" over the displaylist.

Knowing the absolute location of the objects in VRAM also makes easy for
easy color-cycling where you *don't* want to modify the palette. (So on
V-Breakout, the "BREAKOUT" title cycles through red and yellow a letter at a
time. Changing the palette entries would change everything at once
(including the bricks), but just writing to the color instruction (h'xx,
h'68) from the main loop solves that.)

I have a pet peeve of games that "slow down" or "speed up" during play
(depending on how busy the screen is), so I actually draw *everything* on
the screen at all times. Bricks that are "hit" in V-Breakout just get their
color set to "black", so they're still drawn which gives the AVG a pretty
constant frame rate. One "gotcha" seems to be that "Breakout" isn't the
WG6100's favorite screen layout-- lots of activity up top (the bricks) and
not so much activity down low (paddle, score, etc.) It would semi-trip the
spot killer on my monitor, so I had to add a couple full-screen boxes around
the perimeter to get it to stabilize. The downside is that those long lines
take a lot of vector time, so it drops the framerate. Not a big deal
(flicker isn't noticeable during gameplay really, but you can see it on the
titlescreen if you semi-look away from the screen and catch it with
peripheral vision), not nearly as bad as Star Wars or ESB though...

-Clay
Received on Tue Jun 8 13:27:24 1999