Over the weekend, numerous people wrote:
>>think the C-64's able to put out better graphics than the Atari 8-bit's.
>The background on the C=64 could output 16 colors at 320x200 whereas the
>only 320x200 color mode on the 8-bits was only two shades of one hue per
>scanline, called "1.5 colors".
Two shades of hue? That's worse than the two colors I thought... but
anyway... the C-64 can change foreground and background colors for every 8x8
tile of graphics. In 160x200, two of the four colors per tile are fixed
(equal on all the screen), and two can vary in each tile (or was it even
three?), while in this mode, the Ataris only display 4 colors out of their
palette (which can be changed per scanline with the display list / ANTIC, or
whatever it is).
>I think the sprites on the C=64 were also at 320 pixel resolution, vs. the
>160 resolution on the Atari.
This is also true. Correctly, they can also be switched between 320x200 and
160x200 mode. In 320x200 mode, they can be assigned one color each, in
160x200, they have one individual color, and two more colors which are
shared among all sprites.
>But the color really bugs me. Only 16 shades on the C= tend towards games
>that are really posterized and unbalanced, aesthetically, whereas you can
>be more creative and artistic in picking colors on the Atari.
That's basically right.
>>Which is also caused by the different sprite architecture. From what I
know,
>>the Atari 8-bit's still have 8-pixel-wide "players" like the 2600. They
have
>>double the amount of them, but that's it, they still need to be re-written
>They don't need to be rewritten in software every scanline. ANTIC/GTIA
>takes care of that. The 8-bit stores enough memory for an entire vertical
>strip for each sprite, and an entire screen (or more) of framebuffer. It
>also supports hardware scrolling of the background. Not sure about the
>C=64. The C=64's graphics memory map was kinda weird. The Atari stores
>graphics memory in a more conventional chunky pixel format. The options in
>drawing to the screen with the Atari were numerous because of all of the
>available graphics/text modes. The C=64 didn't have that kind of
>variety. You could have part of the screen be text (for scores) and part
>be a GTIA 16-shade mode, and part a 160x200/4 color mode, and so on. There
>are all sorts of interesting effects that can be achieved through display
>lists.
That's right, the C-64 doesn't have that amount of different modes. I think
more modes would be pretty useless, based on the fixed 16-color-palette it
had. Anyway, on the C-64 you can also do screen-splitting by software - tell
the VIC to generate an interrupt on any line you want and then change colors
or screen modes by CPU, or re-write the sprite registers. It's right that
sprites are only 21 lines tall on the C-64, but as soon as a sprite has
ended you can re-write its registers to start displaying a different sprite
further down the screen. I think even Atari was one of the first
manufacturers actually doing this on the C-64 in their C-64 versions of Dig
Dug and Donkey Kong. And- C-64 sprites are 24 pixels tall, and can be
enlarged to 48 pixels (similar to the "double and quadruple with" of the
2600 players). And there are 8 of them, while the Atari 8-bits have only 4
(and 4 missiles). I think the C-64, at the time it was released, was the
only system at that time (be it computer or gaming console) which could
display that amount of multi-coloured (not only color-striped) sprites in
one scanline.
>Look at the Atari 8-bits as a 2600 with more sprites, better resolution,
>some better color (GTIA mode, 16 shades) and a chip that handles the kernel
>with its display list rather than a software kernel.
Does anyone know more about that display list? Which things can the ANTIC
change in each scanline without CPU interaction? Does anyone know recourses
on the Internet about that? I'd like to learn more about it...
>The Atari clock is 1/2 NTSC colorburst instead of 1/3rd, so it's still
>closely tied to TV timings, unlike the C=. So it's still possible to do
>2600-like effects and get through to the hardware while the screen is being
>drawn.
OK, the C-64, at least on PAL, had a bit weird timing. It doesn't care much
about that color burst, you could say. Basically, it multiplies it by 5
(giving about 17,9 MHz), and divides that number by 9 (!!!). Which means
though it's got basically the same resolution, it draws a larger border,
cramming 9 pixels into 4 color bursts. Now this makes for some strange
colour effects... The CPU basically is running at the speed at which the 8x8
tiles run on the screen (1 MHz).
>To move a sprite up and down you have to move the memory. It would have
>been nice if there had been hardware support for this, but this can be done
>very simply to all sprites without any slowdown. Even in Basic there are
>ML subroutines that can do this.
Yes, of course it can be done without much slowdown, because there are so
few of them... ;-)
>Remember that there is a strip of memory representing the sprite. I think
>the C=64 sprites have a physical length to them much smaller than the
>entire screen. So you can paint more of the screen vertically with Atari
>sprites. You can also reposition a sprite in mid screen similar to the
>Atari 2600 to create vertically separated "pseudosprites". Unlike the
2600,
>horizontal sprite position is decimal-based, not polynomial based, and
>requires no subroutine to calculate fine/coarse positions.
That's true for the C-64 too... you just write the horizontal and vertical
positions to the VIC registers for that. Downside is, because the vertical
position takes up 9 bits, there's a ninth register containing the upper bits
for all 8 sprites. Some calculations to be done here... anyway,
HORIZONTALLY, you can paint more of the screen with C-64 sprites. There are
8 of them, and if you double their width, you get a combined width of 384
pixels - more than the C-64 screen is tall (unless you switch off the
border, which with some tricks can also be done).
>The special hardware features of the Amiga are too numerous to list. Its
>only real weakness over earlier systems was the lack of a high speed
>hardware text mode. (...)
Well... as far as I know, the Atari ST didn't have that text mode either.
And on the Amiga the mouse pointer was represented by a sprite, not by
re-writing the bitmap as it was done on the Atari ST, and as it's still done
on the PC's and Mac's today.
>The C=64 allowed you to scroll from 0-7 pixels horizontally and
>vertically - then it was up to the program to shift all of memory
>over one character. You could get a very smooth scroll -
>60 fps on an NTSC machine.
That's true either. There were many smooth scrolling C-64 games... some even
had better scrolling than their Amiga counterparts (Commando,
Ghosts'n'Goblins, Ikari Warriors), and I even know of one that did better on
that part than it's Arcade original (Green Beret). I don't know how this
worked on the Ataris...
>Most of the time Apple II or C=64 games tried to get artistic in the
>graphics they resorted to ugly dithering, otherwise, like I said,
>everything looks posterized and unrealistic. Everything is painted in the
>wrong color just so that it will stand out against the other
>colors. Whereas the Atari graphics tended to have fewer colors, but more
>appropriate colors to the scene.
On the other hand, I've also seen games (graphic adventures) using ugly
dithering on the Atari where there were solid colors on the C-64. Also, the
C-64 pallette was equal for PAL and NTSC, unlike on the Ataris, where if the
programmer forgot something, like in Summer Games, you got swimmers with
purple skin, for instance...
With love (and still much to compare) from Austria
Kurt Woloch
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
