[stella] Hardware comparisons

Subject: [stella] Hardware comparisons
From: Glenn Saunders <cybpunks@xxxxxxxxxxxxx>
Date: Thu, 20 Apr 2000 13:45:37 -0700
At 02:13 PM 4/20/00 +0200, you 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".


I think the sprites on the C=64 were also at 320 pixel resolution, vs. the 160 resolution on the Atari.

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.

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.


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.

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.

I haven't played them on the C=64, but games like Archon which rely on having 8 shades of gray it can cycle through must look pretty lame on the C=64.

do that job for you, but if you want to move an object up and down, you
still have to re-write all of its data. But I'm not sure about this. Does

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.


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". Not sure if you can strobe out sprite clones. I don't think you can. Unlike the 2600, horizontal sprite position is decimal-based, not polynomial based, and requires no subroutine to calculate fine/coarse positions.

There's also a custom chip which reads in the registers for the sprites
itself, but it can also be done by the CPU (which, I think, no-one did on
the Amiga). Anyway, what's not possible there, unlike on the C-64, is to
share sprite data in memory among multiple objects, because the header of
the data also contains the positions the sprites should be displayed at. So
if you animate a sprite, on the Amiga you have to re-write it, and also if
you have multiple instances of the same object, they still need seperate
data chunks in memory with the respective locations inserted. This isn't
needed on the C-64, because there you can write the pattern and position
registers independently. But I'm slightly out of topic now...

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. 16-color Ansi terminal software was dog slow on the Amiga because it has to blit each character. Also, it was economical to tie in the serial and parallel ports to the custom chips, but it also had the net effect of slowing down serial port performance when the graphics were really busy. Not something they were thinking about when high speed modems were 2400 baud without compression.





Glenn Saunders - Producer - Cyberpunks Entertainment Personal homepage: http://www.geocities.com/Hollywood/1698 Cyberpunks Entertainment: http://cyberpunks.uni.cc


-- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/

Current Thread