Clay Haliwell wrote:
>ANTIC DMA only consumes 1/3 of the bus bandwidth in the 8K display modes
>(8-11). In the text-based modes the impact is practically negligible.
Why is that? Doesn't the Antic or GTIA have to read the character data for
every line? Or do they read it from somewhere else where it doesn't disturb
the CPU?
And from Glenn Saunders:
>>So... in the end you get the same CPU speed as on the 2600, with the
>>difference that the custom chips will do much more additional work for
you.
>
>I'm not sure I would classify it that way. Can't the CPU perform any
>meaningful calculations while the image is being drawn? I realize that the
>processor is halted by ANTIC, but doesn't ANTIC/GTIA memory to load up all
>the registers for the entire scanline and then free up the bus for the 6502
>to process while the line is actually being drawn (i.e. parallel
>processing, in effect)? On the 2600, the 6507 rarely has enough free
>cycles to perform number crunching duties during the active portion of the
>screen.
Yes, of course, it can perform calculations while the image is being drawn.
And it could, theoretically, also enhance the Antic's performance by
re-writing the color registers, or anything else that can't be done by the
Antic, in real time, like it's done on the 2600. Since there are DLI
interrupts, it doesn't even have to wait until it's time to do those
things... you just write separate interrupt routines for it. Same for the
C-64, of course. This, in fact, makes those systems far more independent
from the video timing than the 2600. On the 2600, you HAVE to have the right
timing, in every single frame, in order to display the frame correctly,
since the TIA doesn't even generate the vertical blanking by itself.
Virtually all other systems, including many other early video game systems
like the Odyssey^2 (except for the Vectrex, I think), generate their display
no matter what the CPU does. Without CPU interaction, the 2600 will only
display vertical stripes (as you can see when you turn it on without a cart
inserted). The other systems, once the display is set, will keep that
display forever. So... the CPU doesn't have to update the screen in every
frame anymore. It can perform complex calculations, not watching what the
video processor does, and update the screen when they're ready. By means of
DLI, VIC or other interrupts (they are called differently on every system),
they can still try to do a more complex picture than the video chips could
do alone. So in effect, they don't have to care this much to be in sync with
the video timing. That's probably also why Amiga games run rather flawlessly
on different CPU speeds, and PC games do this too (aside from getting too
fast sometimes).
I'd compare this to the difference of modern programming languages to older
ones. Long after such interrupts had been incorporated in the hardware, for
other events, the programs still had to act like the 2600 - on the BASIC
languages of the 8-bit systems, if you wanted to read the keyboard, you'd
have to do it constantly and wait for a key being pressed. The Amigabasic
then introduced such commands as "On Mouse Goto..." and "On Menu Goto...",
which would free you from the load of constantly checking those events. But
the keyboard still had to be read constantly if you wanted to react to it.
In Visual Basic now used on PC's, you can do the same thing with keystroke
and other events. So basically, like with the interrupts, some routine you
wrote is automatically called when this occurs.
Strange effects, however, occur when some things in a game rely on CPU speed
and other on the video timing, causing the objects controlled by the CPU
speed to get faster when the ones controlled by the video timing don't. I
experienced this by playing around with a friend's Geneve, which is sort of
a Turbo TI-99 with a faster CPU. For instance, in Jungle Hunt there, on the
first scene, the movement of the Tarzan character relies on the video timing
(the TI has built-in interrupt-driven sprite moving routines for this),
while the scrolling is as fast as the CPU can handle it. So because the
ropes scroll by much faster, but Tarzan still moves the same speed, he
regularly flys OVER the next rope and crashes. Some C-64 games (especially
some Centipede clones) also do strange things like this when you alter the
frequency at which the timer issues its interrupts by doing, I think, POKE
56547,XX (with XX being a value between 0 and 255, for fastest to slowest)
before starting them. And some games, for that reason, become easier or
harder when running on PAL machines. Pole Position on the C-64, for
instance, then has the "Timer" count down every 1.2 seconds, but your car's
still going the same speed, which makes the game a lot easier to finish.
>>Also, on the TMS-9918 systems, this runs different. The video chip always
>>has its own memory and reads from there, not ever halting the CPU. On the
>
>Isn't this more akin to today's graphics chip systems?
Yes, of course it is. On the other hand, some early TMS-9918 systems would
have very little CPU RAM. The TI-99 without expansion, for instance, only
had 256 bytes, and its built in Basic crammed the programs you wrote into
the Video RAM. In fact, all built-in loading routines on this machine load
from Tape or Disk into Video RAM. If you've got a RAM expansion, the data is
then copied into CPU RAM. That's why the fastest loading disk format for
machine language programs is "PROGRAM", where data's stored in multiple 8K
long files which are loaded into Video RAM all 8K at once (using a built-in
routine) and then copied into CPU RAM until the whole program is loaded (32K
max. there). On the other hand, the CPU RAM expansion's not very fast
either, since the 16-bit TMS9900 CPU only accesses it via an 8-bit bus. Only
the built-in 256 bytes "Scratch Pad RAM" are 16-bit. And the TI-99
cartridges partly rely on some strange "GROM" which is read similarly to the
data out of the Video RAM. The TI has, however, built in interrupt routines
for sprite motion, playing music, and other useful things which run from
ROM, which is also 16-bit.
Concerning the dual CPU Saturn: I believe the SNES had a seperate processor
controlling the sound chip, and you HAD to use it for that purpose.
With love from Austria (and many more things to find)
Kurt Woloch
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
