Atari v Commodore

[atariksi]

By the way, there was a time when my identity was too wrapped up in the Atari for me to say anything good about the 64. Today, I think I'm pretty rational and even-handed about it. Although the Atari is still my favorite 8-bit, I think I could hang with the 64 guys and resist the urge to pour Mountain Dew into their 1541s.

 

I also have C64, Atari ST, Amiga, and Atari 8bits and PCs, but I don't foolishly treat them all as equal or purposely try to give some edge to another at the cost of the truth.

 

You should have stubbornly stuck to your original point that there's no planar MC mode on Atari and juggle words like they did not use the word "bitplane" or "planar". Because once you accept the MC mode, then having 3*N colors vs. N+2 colors where N is number of sprites, you are defying mathematical logic.

[Bryan]

Because you are too biased to think clearly that an Atari multicolor sprite implementation is superior.

Even 4 MC atari implemented sprites give more colors than 8 C64 MC sprites.

Here's what you're saying in a nutshell:

 

A single multi-color object made from 2 Players has 3 unique colors. Two of them are completely unrestricted and the third is derived from the other two. This 3 color object is superior to a 3 color object in which 1 color is completely unrestricted and the other two must be shared.

 

That's why it's important that you classify the Atari's multi-color object as a single "sprite" because in reality, you've thrown half your PMG resources at generating this single winning multi-color object.

 

It's a simple trade-off. The 64 doesn't have enough color registers to allow total color freedom, and the Atari consumes Players at twice the normal rate to do multi-color. From that perspective it's not a clear-cut win either way. The real win would be more color registers, but you've got to save silicon somewhere. Or how about the way the 7800 does it? A 3-color sprite can use one of a few palettes.

[Bryan]

I also have C64, Atari ST, Amiga, and Atari 8bits and PCs, but I don't foolishly treat them all as equal or purposely try to give some edge to another at the cost of the truth.

Yes, I have prostituted myself at the altar of inferior technology.

 

The PC literally kills them all but that's obviously not what I'm concerned with as a hobbyist. Heck, there's more technology in my optical mouse than in the entire 8-bit.

[atariksi]

Because you are too biased to think clearly that an Atari multicolor sprite implementation is superior.

Even 4 MC atari implemented sprites give more colors than 8 C64 MC sprites.

Here's what you're saying in a nutshell:

 

A single multi-color object made from 2 Players has 3 unique colors. Two of them are completely unrestricted and the third is derived from the other two. This 3 color object is superior to a 3 color object in which 1 color is completely unrestricted and the other two must be shared.

 

That's why it's important that you classify the Atari's multi-color object as a single "sprite" because in reality, you've thrown half your PMG resources at generating this single winning multi-color object.

 

It's a simple trade-off. The 64 doesn't have enough color registers to allow total color freedom, and the Atari consumes Players at twice the normal rate to do multi-color. From that perspective it's not a clear-cut win either way. The real win would be more color registers, but you've got to save silicon somewhere. Or how about the way the 7800 does it? A 3-color sprite can use one of a few palettes.

 

According to formula, 3N vs. N+2 if you had only one multicolor sprite they would be equal. Once you have more than one (which is the case for both A8 and C64), it's better to use 3N implementation. If you want to keep memory useage constant, then you have to sacrifice half resolution or half of players, but if you go via Amiga method planes are processed in parallel by hardware so you can keep same resolution, same amount of players and have the better multicolor implementation. It doesn't have to be all color registers-- some can be logical ORs or ANDs or SHRs (half-bright). Don't know how 7800 does it, but even if you implement a chunky mode and sacrifice half the resolution you can still have a better color result than N+2.

[Bryan]

According to formula, 3N vs. N+2 if you had only one multicolor sprite they would be equal. Once you have more than one (which is the case for both A8 and C64), it's better to use 3N implementation. If you want to keep memory useage constant, then you have to sacrifice half resolution or half of players, but if you go via Amiga method planes are processed in parallel by hardware so you can keep same resolution, same amount of players and have the better multicolor implementation.

 

Do you realize that more planes = more RAM and more DMA cycles? It's not free or magically parallel. Increasing bit depth always comes at the same price whether it's arranged chunky or planar.

Edited April 7, 2009 by Bryan

[atariksi]

According to formula, 3N vs. N+2 if you had only one multicolor sprite they would be equal. Once you have more than one (which is the case for both A8 and C64), it's better to use 3N implementation. If you want to keep memory useage constant, then you have to sacrifice half resolution or half of players, but if you go via Amiga method planes are processed in parallel by hardware so you can keep same resolution, same amount of players and have the better multicolor implementation.

 

Do you realize that more planes = more RAM and more DMA cycles? It's not free or magically parallel. Increasing bit depth always comes at the same price whether it's arranged chunky or planar.

 

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

 

http://alive.atari.org/alive8/c2p.php

 

But even if you do chunky implementation, 3N is better than N+2.

[atariksi]

I also have C64, Atari ST, Amiga, and Atari 8bits and PCs, but I don't foolishly treat them all as equal or purposely try to give some edge to another at the cost of the truth.

Yes, I have prostituted myself at the altar of inferior technology.

 

The PC literally kills them all but that's obviously not what I'm concerned with as a hobbyist. Heck, there's more technology in my optical mouse than in the entire 8-bit.

 

You can hook up the mouse to the 8-bit and have that technology+GTIA/POKEY/ANTIC/etc. programmability as their functionality is pretty much mutually exclusive.

[Bryan]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

[Heaven/TQA]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

 

Yup... interleaved bitplanes of the shifter is a pain...a real pain... and as far as I know the Amiga approach with linear bitplane is far easier to handle with the 680x0 at least with my low lever experience on the machines... ST really sucked...

[Crazyace]

According to formula, 3N vs. N+2 if you had only one multicolor sprite they would be equal. Once you have more than one (which is the case for both A8 and C64), it's better to use 3N implementation. If you want to keep memory useage constant, then you have to sacrifice half resolution or half of players, but if you go via Amiga method planes are processed in parallel by hardware so you can keep same resolution, same amount of players and have the better multicolor implementation. It doesn't have to be all color registers-- some can be logical ORs or ANDs or SHRs (half-bright). Don't know how 7800 does it, but even if you implement a chunky mode and sacrifice half the resolution you can still have a better color result than N+2.

 

That formula is a complete farce ...

 

it's not 3N vs N+2 , it's 3X vs Y+2 where X=2 and Y=8...

Why do you keep bringing the Amiga into it? The comparision is between the C64 and the Atari.

 

There's also the fact that the C64 sprites are higher resolution as well , which is just another nail in the coffin.

 

 

( It's a bit like the arguments between the Apple II and Atari about graphics - quoting graphics as 280x with 6 colours verses 160x with 4 colours for the Atari - with isn't really true )

[Crazyace]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

 

Yup... interleaved bitplanes of the shifter is a pain...a real pain... and as far as I know the Amiga approach with linear bitplane is far easier to handle with the 680x0 at least with my low lever experience on the machines... ST really sucked...

 

I think it would actually be quicker to implement a chunky mode in some ways....

 

Rather than multiple bit planes just fetch words directly into a shifter ( maybe 32 bits )... Clock this continuously at the highest clock - and have the bottom 4 bits latch the pallette lookup.

For low res reload the latch every 4 clocks - for medium res reload it every 2 clocks , and for high res reload it every clock.

To implement scrolling just delay the hsync pulses by up to 15 clocks relative to the display enable ( and fetch an extra word per line )

 

Then load the pallete with 4 copies of the same 4 colours for medium res, and 8 copies of the 2 colours for high res

[atariksi]

According to formula, 3N vs. N+2 if you had only one multicolor sprite they would be equal. Once you have more than one (which is the case for both A8 and C64), it's better to use 3N implementation. If you want to keep memory useage constant, then you have to sacrifice half resolution or half of players, but if you go via Amiga method planes are processed in parallel by hardware so you can keep same resolution, same amount of players and have the better multicolor implementation. It doesn't have to be all color registers-- some can be logical ORs or ANDs or SHRs (half-bright). Don't know how 7800 does it, but even if you implement a chunky mode and sacrifice half the resolution you can still have a better color result than N+2.

 

That formula is a complete farce ...

 

it's not 3N vs N+2 , it's 3X vs Y+2 where X=2 and Y=8...

Why do you keep bringing the Amiga into it? The comparision is between the C64 and the Atari.

 

There's also the fact that the C64 sprites are higher resolution as well , which is just another nail in the coffin.

...

The formula is just a fact of life you have to live with. I already stated the advantages of C64 sprites regarding resolution and quantity (see msg #3078) and earlier. I forgot it was early in the morning so although you replied to that message, you didn't understand it. N = # of MC sprites and we're not discussing quantity but number of color generated in the MC implementation of a sprite. You prefer that I keep repeating C64 has more sprites horizontally rather than discuss other points and aspects of sprites. In case you didn't know, Atari sprites cover a greater area (more pixel processing) than C64 since you keep thinking along X-axis only. Atari sprites can be replicated more times than C64 sprites due to Atari speed and vertical structure.

 

It isn't like the Apple argument.

[Crazyace]

The formula is rubbish... We are discussing which sprite system is best - and you keep holding on to the colour combination as if it's the ultimate mechanism for generating colour - which it isn't.

 

I'm surprised you keep on acting as if more sprites horizontally is less important - It's easy to multiplex sprites vertically ( and you have to on both the c64 and Atari ), but multiplexing horizontally is way more difficult in any but a seriously constrained sprite system.

[atariksi]

The formula is rubbish... We are discussing which sprite system is best - and you keep holding on to the colour combination as if it's the ultimate mechanism for generating colour - which it isn't.

 

I'm surprised you keep on acting as if more sprites horizontally is less important - It's easy to multiplex sprites vertically ( and you have to on both the c64 and Atari ), but multiplexing horizontally is way more difficult in any but a seriously constrained sprite system.

 

The formula is undeniably true. If you had the A8 MC implementation on C64, you would get more colors per sprite using 3N vs. N+2. Don't change the subject now-- you look like you need to relax and read the posts before you make your conjectures. I already agreed you have more sprites horizontally. You have more contraints vertically especially in overscan situations. I can change HPOS many times during one scanline. That formula has nothing to do with determining which sprite system is better but which multicolor sprite implementation is better. Think before you reply-- looks like someone pissed you off. Take a cold shower.

[atariksi]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

 

Yup... interleaved bitplanes of the shifter is a pain...a real pain... and as far as I know the Amiga approach with linear bitplane is far easier to handle with the 680x0 at least with my low lever experience on the machines... ST really sucked...

 

I think it would actually be quicker to implement a chunky mode in some ways....

...

You thought wrong. Many early systems used planar system and found to be easier implementation hardware wise.

 

>Rather than multiple bit planes just fetch words directly into a shifter ( maybe 32 bits )... Clock this continuously at the highest clock - and have the bottom 4 bits latch the pallette lookup.

...

 

You need higher clocking for chunky rather than using planes which get read in parallel. EGA systems employed parallel planes, Amiga employed parallel planes, Atari ST employed planes although they interleaved them, etc.

[atariksi]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

 

Yup... interleaved bitplanes of the shifter is a pain...a real pain... and as far as I know the Amiga approach with linear bitplane is far easier to handle with the 680x0 at least with my low lever experience on the machines... ST really sucked...

 

Amiga is more flexible since it also has the modulo registers which let you set the offset to next scanline data after every scanline fetch. And number of bitplanes if 1..4 doesn't affect Copper DMA bandwidth whereas going higher than 4 bitplanes slows down the Copper.

[Crazyace]

There are lot of articles on parallel planes being easier on the hardware; here's one atari related site:

When designing a variable bit depth system, it's true that chunky representation is more complicated, but the data retrieved is the same except for bit arrangement. The simplest type of implementation is probably the one used by the ST. Each 16-bit word represents a single bit for 16 pixels. The next word is the next bit and so on until you reach the end of your bit depth and then you move to the next 16 pixels. It's a pain in the ass to draw to such a bitmap, but the video hardware can simply reset its word counter at different points to achieve different bit depths. I believe the Amiga kept the planes as separate 1-bit arrays in memory.

 

Yup... interleaved bitplanes of the shifter is a pain...a real pain... and as far as I know the Amiga approach with linear bitplane is far easier to handle with the 680x0 at least with my low lever experience on the machines... ST really sucked...

 

I think it would actually be quicker to implement a chunky mode in some ways....

...

You thought wrong. Many early systems used planar system and found to be easier implementation hardware wise.

 

>Rather than multiple bit planes just fetch words directly into a shifter ( maybe 32 bits )... Clock this continuously at the highest clock - and have the bottom 4 bits latch the pallette lookup.

...

 

You need higher clocking for chunky rather than using planes which get read in parallel. EGA systems employed parallel planes, Amiga employed parallel planes, Atari ST employed planes although they interleaved them, etc.

 

I'm sorry - but where is your proof that I thought wrong? The clocking is the same as required for the high res case and the internal circuitry is actually smaller - rather than 4 16 bit shiftregisters and 4 16bit latches ( for the ST case ) I can implement a similar system with 1 16 bit latch and as little as 20 bits of shift register..

The Apple II GS was a chunky system, and TMS34010 was a chunky system. So were the 7800 and the Jaguar

 

Bit plane systems were actually easier to design blitters for, and I think that was the big advantage for the amiga ( and the ST software )

 

 

( Actually it would probally be better to implement the shift register as a 'shift 4 pixels' at the lores clock - and implement the medium and highres as a mask of the lores pixel: eg {0,0,1,1}/{1,1,0,0} at medium res clock or {1,0,0,0}/{0,1,0,0}/{0,0,1,0}/{0,0,0,1} at highres clock )

Edited April 7, 2009 by Crazyace

[Crazyace]

The formula is rubbish... We are discussing which sprite system is best - and you keep holding on to the colour combination as if it's the ultimate mechanism for generating colour - which it isn't.

 

I'm surprised you keep on acting as if more sprites horizontally is less important - It's easy to multiplex sprites vertically ( and you have to on both the c64 and Atari ), but multiplexing horizontally is way more difficult in any but a seriously constrained sprite system.

 

The formula is undeniably true. If you had the A8 MC implementation on C64, you would get more colors per sprite using 3N vs. N+2. Don't change the subject now-- you look like you need to relax and read the posts before you make your conjectures. I already agreed you have more sprites horizontally. You have more contraints vertically especially in overscan situations. I can change HPOS many times during one scanline. That formula has nothing to do with determining which sprite system is better but which multicolor sprite implementation is better. Think before you reply-- looks like someone pissed you off. Take a cold shower.

 

So does that mean you accept that the C64 sprites are superior to the Atari sprites , but the addition of the Atari colour pairing would make them even better?

 

For a general player you need to change not just HPOS, but the graphic data and colour as well - It's no use just repositioning the same graphic pattern, unless you want to reproduce some of the 2600 graphics capabilities

[Godzilla]

you will find pitting atari against commodore has a way of going on and on, it's the secret to the never ending thread! la laaa laaaaa la la la laa laaaaa never ending thread!! la laaa laaaaa la la la laa laaaaa (beware the nothing!)

[supercat]

I'm sorry - but where is your proof that I thought wrong? The clocking is the same as required for the high res case and the internal circuitry is actually smaller - rather than 4 16 bit shiftregisters and 4 16bit latches ( for the ST case ) I can implement a similar system with 1 16 bit latch and as little as 20 bits of shift register..

 

The EGA system used a planar architecture in part to allow faster programming (though the usefulness of those features was limited until the VGA added a couple of practical enhancements). For certain applications, the planar design is very nice; for others, it's a pain in the tush. Nobody uses those modes any more, but for some purposes they worked quite well.

 

As for hardware complexity or simplicity, planar modes make it easy to support an arbitrarily-variable number of bits per pixel. Using two or four bits per pixel may be more convenient in a "chunky" system than in a planar one, but what about using three or five? A bit-plane architecture which is equipped to handle pixel-level shifting of two sets of bit planes may use the two sets individually to produce an parallax-scrolling background, or together to produce more colors.

 

Unless one is using byte-sized "chunky" pixels, I don't see a huge difference between planar and chunky approaches for most applications.

 

BTW, I wonder what machines have used interesting addressing tricks to allow a processor to view memory in different formats? Rescue on Fractalus on the 7800 omitted an address line from its RAM chip, so as to allow each byte of RAM to be displayed twice, but what other tricks have been done?

[Bryan]

You need higher clocking for chunky rather than using planes which get read in parallel.

 

No. You don't. This is the source of much of your confusion.

 

If you have 4 bits per pixel (for example), then you need 4 bits (0.5 bytes) x the horizontal resolution x the vertical resolution. That's how much data you need.

 

The number of bus accesses to get this data depends on the size of the bus. So...

 

Let's take 640x480x16 colors. That's 153600 bytes. If the bus is 16-bits, then that's 76800 DMA reads per frame. Your bus clocking must support at least that amount of data per frame. It doesn't matter if it's arranged in pixels or planes or backwards, or semi-randomly through a LFSR.

 

Planes simplify the hardware because you only have one interpretation of the bits for all modes.

 

Planes do not affect clock rate: On the ST in low res, 4 16-bit words nets you 16 pixels. If the pixels were chunky (4+4+4+4), then 1 word would net you 4 pixels and 4 words would still net you 16 pixels. Bandwidth is bandwidth. There is nothing magical about bit-planes. It's just another representation of the same data.

[Crazyace]

For a simple games machine a chunky nibble display means that fine scroll only has to delay 3 pixels max The ST and Amiga bitplanes were the best implementation for 'general purpose' use - as you say a varying bit depth is easier to cope with in software for bitplanes. But for writing games it sucked on the ST - either take the hit for aligning sprites and masks, or have multiple copies of all of the graphics. I think I could actually implement a parallax effect more easily in chunky mode as well.

 

The Amiga didn't have a problem, as the blitter was used for graphics manipulation , but implementing texture mapping is a lot easier on a nibble based colour display than it is on a bit plane display - ( the CD32 had a chunky to planer converter to allow games to run byte/pixel graphics routines )

 

The ROF trick on the 7800 was pretty cool - didn't a lot of the NES chips also use ram/rom tricks as well

[malducci]

Ok, some one list some specs:

 

Number of sprites per scanline (hardware and lowest color count - i.e not pairing)?

Number of sprites per screen?

If the total number of sprites can be extended (by changing the registers on the fly), what's the CPU resource ratio?

What res are the sprites available in?

Can you mixed hi-res and low-res sprites, and can you mix them with a different background res?

How many colors per sprite (both for pairing or non pairing)?

Native/max sprite sizes?

Edited April 7, 2009 by malducci

[atariksi]

You need higher clocking for chunky rather than using planes which get read in parallel.

 

No. You don't. This is the source of much of your confusion.

...

List all my confusions and then I'll answer you otherwise it's Chewbacca defense.

[Bryan]

You need higher clocking for chunky rather than using planes which get read in parallel.

 

No. You don't. This is the source of much of your confusion.

...

List all my confusions and then I'll answer you otherwise it's Chewbacca defense.

I just did. You think you need higher clocking to read the same amount of data once the bits are in a different order.

 

What takes more bandwidth to read? A 32K screen or a 32K screen? You seem to think that planes are some sort of compression scheme. You are therefore confused.