Subject: Re: [stella] Hardware comparisons From: kurt.woloch@xxxxxxxxx Date: Tue, 25 Apr 2000 08:56:51 +0200 |
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[stella] New application for the At, Maximiliam Luppe | Thread | Re: [stella] Hardware comparisons, Ben Combee |
Re: [stella] Hardware comparisons, Glenn Saunders | Date | Re: [stella] Hardware comparisons, Ben Combee |
Month |