Atari v Commodore

[potatohead]

I think it's a matter of logic too. All those collisions add up. Probably a point of diminishing returns. Was just thinking about that, and the interrupt capability provided on C64. That is probably where they were headed too, when faced with all those collision conditions.

[Rybags]

IRQ for collision.

 

PMSL... about as useful as an ashtray on a motorbike.

[atariksi]

http://www.c64-wiki.com/index.php/Sprite

 

Sprite 0 is always on top, sprite 7 is at the back.

 

Color 0 reveals either another sprite, or the non-sprite graphics. (transparent)

 

For the two intermediate color combinations, (color 1 and 2) it appears there are two color registers that are shared between all sprites.

...

The two colors shared was one of the points argued in this thread-- namely two C64 multicolor sprites yields 4 unique colors whereas two Atari multicolor sprites yeilds 6 colors (4 from registers and 2 from OR effect).

 

>Each sprite can be either behind, or in front of non-sprite graphics data.

 

There's only one playfield on C64 rather than PF0..PF3 + BAK on Atari. Amiga has two playfields.

 

>Each sprite has two collision bits. One for "another sprite" and another for non-sprite visible pixels.

 

That's register is vague; there's no way to tell which sprite collided with another sprite if you read it and find multiple bits are set. Seems like a rush job like their scrolling hardware.

 

>An interrupt can be triggered upon a collision sprite to sprite, or sprite to background.

 

Atari has 60-bits of unique sprite collision detection between missiles/players/playfields.

 

>Each sprite may be double sized horizontally and / or vertically.

 

Just like double line mode on Atari and 2X zoom mode; but Atari also has 4X zoom.

 

>Sprites are positioned with 9 bits of data.

 

That's better on C64-- 1/320 positioning and resolution (and they need it for overscanning and other things).

 

>I didn't see sprites operating on one another, and that's confirmed by the post above. Also, I didn't know the 01 color is always overlapped. Interesting... Probably some tricks to be had there.

 

They don't have any GPRIOR effects of playfields with players; they only have one playfield so they rather rely on using a couple of multicolor sprites on top of each other and get 4 unique colors.

[atariksi]

So, does the C64 have anything like this with it's sprites? That's the real question, with the rest being semantics.

Well, if we use the argument that something is a bit-plane even if the elements don't combine to make additional color, then you put all the 64 sprites on top of each other and call them a bunch of bit-planes. The truth is that sprites and players are graphic elements. They are independent or semi-independent objects designed to augment the playfield which is also a graphic element. Bit-planes are sub-element objects. They are usually locked in position relative to each other and all contribute to a single image. They are a way of making the system more flexible, although they can sometimes be used to create the effect of separate objects.

 

 

 

I feel sprites and pm's are not bitplanes. Now if you look at the Jaguar's OPL, you could probably

more accurately call that a bit plane set up than a bunch of sprites. Then again, the OPL of the Jag

is intended for both foreground and backdrop gfx.

 

When I think of plane I definitely think as in backdrops and not as foregrounds. Also the bit plane

nature of the Atari ST GFX (which I hate btw) for instance, work hand in hand to determine color.

Sprites and PM's are not intended for this, even if it may be an after effect of the hardware or tricky

coding.

 

I still do not recall seeing a C64 sprite cover more than a 24x21 pixel area...hardly a screen bitplane

by any definition.

 

Even if you define bitplane to be backdrops or covering the screen, you can set priority of Atari sprites to be in background and then fill up the screen with them. In fact, suppose I set up narrow mode and fill up the screen with a multicolor sprite at 4X zoom-- that's 2 bitplanes on top or behind any other chunky graphics mode that may be there.

 

I thought they eventually did chunky modes on Atari ST... maybe much later models.

[Crazyace]

http://www.c64-wiki.com/index.php/Sprite

 

Sprite 0 is always on top, sprite 7 is at the back.

 

Color 0 reveals either another sprite, or the non-sprite graphics. (transparent)

 

For the two intermediate color combinations, (color 1 and 2) it appears there are two color registers that are shared between all sprites.

...

The two colors shared was one of the points argued in this thread-- namely two C64 multicolor sprites yields 4 unique colors whereas two Atari multicolor sprites yeilds 6 colors (4 from registers and 2 from OR effect).

 

>Each sprite can be either behind, or in front of non-sprite graphics data.

 

There's only one playfield on C64 rather than PF0..PF3 + BAK on Atari. Amiga has two playfields.

 

>Each sprite has two collision bits. One for "another sprite" and another for non-sprite visible pixels.

 

That's register is vague; there's no way to tell which sprite collided with another sprite if you read it and find multiple bits are set. Seems like a rush job like their scrolling hardware.

 

>An interrupt can be triggered upon a collision sprite to sprite, or sprite to background.

 

Atari has 60-bits of unique sprite collision detection between missiles/players/playfields.

 

>Each sprite may be double sized horizontally and / or vertically.

 

Just like double line mode on Atari and 2X zoom mode; but Atari also has 4X zoom.

 

>Sprites are positioned with 9 bits of data.

 

That's better on C64-- 1/320 positioning and resolution (and they need it for overscanning and other things).

 

>I didn't see sprites operating on one another, and that's confirmed by the post above. Also, I didn't know the 01 color is always overlapped. Interesting... Probably some tricks to be had there.

 

They don't have any GPRIOR effects of playfields with players; they only have one playfield so they rather rely on using a couple of multicolor sprites on top of each other and get 4 unique colors.

 

You forgot one or two points...

 

1/ Having 2 multicolour objects on a line requires all 4 of the Atari Players , but only 2 out of 8 of the C64 sprites. In actual games this is quite useful.

2/ The width of each individual sprite on the c64 is 24 pixels ( 12 in multicolour ) , compared to 8 pixels for the Atari.

[Crazyace]

Even if you define bitplane to be backdrops or covering the screen, you can set priority of Atari sprites to be in background and then fill up the screen with them. In fact, suppose I set up narrow mode and fill up the screen with a multicolor sprite at 4X zoom-- that's 2 bitplanes on top or behind any other chunky graphics mode that may be there.

 

I thought they eventually did chunky modes on Atari ST... maybe much later models.

 

With sprite reuse on the c64 you can fill the whole screen up with a 7x by 10y grid of sprites , which will give you 7 unique colours per pixel at 160x200y ( or 3 unique colours at 320x200y ) without any constraints ( 16 colours as usual with the 8x8 cell constraints )

 

I think the Falcon and the TT were the only machines with chunky modes

[Atari_Owl]

I think you mean the PET rather than the Vic 20 - i not sure a 1981 computer can really be seen completely as contemporary

 

Everything I've seen places the introduction of the VIC-20 in 1980, maybe six months after the 400/800 started shipping.

 

http://www.commodore.ca/products/vic20/commodore_vic-20.htm

 

"The VIC-20 debuted in June of 1980 at the Computer Electronics Show but its development started almost by accident two years earlier."

 

Much as i have a fondness for some of these, more so than for Atari, I'll still admit the 800 WAS very a significant step, and regardless of this massive thread and whether or not the C64 is better, it bloody well should have been, coming so many years down the line.

 

Right. You can demonstrate that the 64 has advantages over the 800 just as the Amiga and ST have advantages over the 64. The biggest problem with Atari is that while they spent all their budget on feature-laden vaporware they let their core design get stale.

 

-Bry

 

Fair enough, it's possible i'm just thinking of it from a UK perspective.

I'd only checked here:

http://www.old-computers.com/museum/comput...?st=1&c=252

 

which stated May 81 and tied up with my memories of the time. But who knows what country's release that was.

 

Edit: Actually even reading that page more closely it says late 1980 as the 1001 in Japan first so even there it does indeed say 1980 (though not as the Vic20 as such even if its the same machine ) and to be fair, your reference also states that it didn't hit store shelves until 1981, and if we accept May quoted in Old-computers then even if Ataris weren't available til christmas 79 thats still 18 months.

 

Between early 1981, when the VIC actually hit store shelves,

 

Well it doesn't really matter anyway - i agree that compared to its contempories with their sugar cube 80x50 graphics, predominantly monochrome displays etc - the 800 WAS a significant step - it just wasn't capitalised upon.

Edited April 7, 2009 by Atari_Owl

[emkay]

>If just only one would write a full POKEY supporting tracker. But this time, SID clearly wins in most cases...

 

I am not too much into making musical notes on Atari nor C64. Supposedly, the envelopes simulation would eat up too much Atari CPU time.

 

 

That's one reason why POKEY music still waits to be unleashed... people may think too complex.

 

The Atari is able to use high sample rates with envelops.... but the envelopes with the pokey's generators are too time consuming?

 

Actually, RMT does it already, but in a fully wrong way. 2 updates per second on the registers would be clearly enough. And the "music"-commands have to be in the pattern, not in the instruments.

The generators have to be handled like samples then, but they cost "nothing" except the initial routines.

Particular with the filter voice you could use all possible side effects, like interference volume control or half pitch corrections. And, not to forget, for a PC tool we'd need a 100% corrected emulation.

Double VBI routines you can use in almost all games and demos!

[emkay]

I think even with a 4GHz cpu you would still drive Antic/GTIA at 1.79MHz - so there's only 114 accesses per line ( roughtly ) - so I guess you could get 80x240 with 256 colours, and the refresh may still screw things up

 

If the CPU can change all registers fast enough, GTIA will show them all 2 "bytes" on the screen. It's like a software HAM then. It will act on the colours as on the PM positions, sizes, etc...

[Rybags]

If you had the means, you could change a colour register per cycle on GTIA. Fast enough to have Gr. 10 with all colours, no limitations.

 

If you had a quick enough CPU, you could take Antic out of the equation anyway... just drive GTIA directly through the AN0-2 lines.

 

But if you were to go to that extent, may as well drive 3 of them for seperate RGB component output.

[Bryan]

Fair enough, it's possible i'm just thinking of it from a UK perspective.

I'd only checked here:

http://www.old-computers.com/museum/comput...?st=1&c=252

 

which stated May 81 and tied up with my memories of the time. But who knows what country's release that was.

 

Edit: Actually even reading that page more closely it says late 1980 as the 1001 in Japan first so even there it does indeed say 1980 (though not as the Vic20 as such even if its the same machine ) and to be fair, your reference also states that it didn't hit store shelves until 1981, and if we accept May quoted in Old-computers then even if Ataris weren't available til christmas 79 thats still 18 months.

 

Between early 1981, when the VIC actually hit store shelves,

 

Well it doesn't really matter anyway - i agree that compared to its contempories with their sugar cube 80x50 graphics, predominantly monochrome displays etc - the 800 WAS a significant step - it just wasn't capitalised upon.

 

The 400/800 did have a small jump on the Vic-20 which was a toy by comparison. I wonder if Commodore even knew Atari was developing a machine. The PET was more of a business machine and I don't think I ever knew anyone who had one.

 

It seemed to me that in 1979 through 1980 you almost had to discover the 800 by accident. Everyone here had heard of the Apple and had seen a TRS-80 in RadioShack but you had to search out an Atari dealer. Atari certainly had access to retailers but I think they were trying to be somewhat exclusive at first and I think they missed their window.

 

-Bry

[Bryan]

If you had the means, you could change a colour register per cycle on GTIA. Fast enough to have Gr. 10 with all colours, no limitations.

 

If you had a quick enough CPU, you could take Antic out of the equation anyway... just drive GTIA directly through the AN0-2 lines.

 

But if you were to go to that extent, may as well drive 3 of them for seperate RGB component output.

 

I had drawn up a design to do that at one point. You would place your data in SRAM and then the values would be stuffed into GTIA every cycle during the active line (while locking out the CPU from GTIA). It would still be cool to build it some day.

[Crazyace]

If you are going for RGB why bother with 3 antics - with a 4GHz cpu just drive the RGB lines directly ( like the usebox or propeller kits )

[Gorf]

...and that's semantics really.

 

Better to shift focus from "bitplane" and just talk about what the entities actually do.

 

 

I dont think it is semantics at all. A backdrop bitplane is NOT the same as a sprite/player.

[Fröhn]

http://en.wikipedia.org/wiki/Bitplanes

[Gorf]

I thought they eventually did chunky modes on Atari ST... maybe much later models.

 

 

I dont recall anything but bitplane modes with the ST...the Falcon030 is where

I think they added chunky modes.

 

TT had new modes of 320 x 480 x 256 colors, 640 x 480 x 16 color and 1280x x960 mono.

Im not sure if these were chunky modes or not. If they were bit plane, the 320 x 480 x 256

colors mode would require manipulation of 8 bitplanes!!! Yuk!!! TT also allows the ST mono

(640x480) mode to use any two colors of the 4096 palette.

[Gorf]

http://en.wikipedia.org/wiki/Bitplanes

 

 

Wiki? You can't be serious.

[atariksi]

http://www.c64-wiki.com/index.php/Sprite

 

Sprite 0 is always on top, sprite 7 is at the back.

 

Color 0 reveals either another sprite, or the non-sprite graphics. (transparent)

 

For the two intermediate color combinations, (color 1 and 2) it appears there are two color registers that are shared between all sprites.

...

The two colors shared was one of the points argued in this thread-- namely two C64 multicolor sprites yields 4 unique colors whereas two Atari multicolor sprites yeilds 6 colors (4 from registers and 2 from OR effect).

 

>Each sprite can be either behind, or in front of non-sprite graphics data.

 

There's only one playfield on C64 rather than PF0..PF3 + BAK on Atari. Amiga has two playfields.

 

>Each sprite has two collision bits. One for "another sprite" and another for non-sprite visible pixels.

 

That's register is vague; there's no way to tell which sprite collided with another sprite if you read it and find multiple bits are set. Seems like a rush job like their scrolling hardware.

 

>An interrupt can be triggered upon a collision sprite to sprite, or sprite to background.

 

Atari has 60-bits of unique sprite collision detection between missiles/players/playfields.

 

>Each sprite may be double sized horizontally and / or vertically.

 

Just like double line mode on Atari and 2X zoom mode; but Atari also has 4X zoom.

 

>Sprites are positioned with 9 bits of data.

 

That's better on C64-- 1/320 positioning and resolution (and they need it for overscanning and other things).

 

>I didn't see sprites operating on one another, and that's confirmed by the post above. Also, I didn't know the 01 color is always overlapped. Interesting... Probably some tricks to be had there.

 

They don't have any GPRIOR effects of playfields with players; they only have one playfield so they rather rely on using a couple of multicolor sprites on top of each other and get 4 unique colors.

 

You forgot one or two points...

 

1/ Having 2 multicolour objects on a line requires all 4 of the Atari Players , but only 2 out of 8 of the C64 sprites. In actual games this is quite useful.

2/ The width of each individual sprite on the c64 is 24 pixels ( 12 in multicolour ) , compared to 8 pixels for the Atari.

 

Point 1 (you made)-- stated at top when I talked about comparing C64 multicolor players to A8 multicolor players. Yeah, you use up two A8 multicolor players + missiles to get 2 C64 multicolor players in width.

 

Point 2 (you made)-- msg #3073.

 

Point 3 (I make)-- Atari sprites are 8*248, 16*248, or 32*248.

[atariksi]

Even if you define bitplane to be backdrops or covering the screen, you can set priority of Atari sprites to be in background and then fill up the screen with them. In fact, suppose I set up narrow mode and fill up the screen with a multicolor sprite at 4X zoom-- that's 2 bitplanes on top or behind any other chunky graphics mode that may be there.

 

I thought they eventually did chunky modes on Atari ST... maybe much later models.

 

With sprite reuse on the c64 you can fill the whole screen up with a 7x by 10y grid of sprites , which will give you 7 unique colours per pixel at 160x200y ( or 3 unique colours at 320x200y ) without any constraints ( 16 colours as usual with the 8x8 cell constraints )

 

I think the Falcon and the TT were the only machines with chunky modes

 

You mean 7*10 monochrome sprites zoomed to 2X in x-direction would fill up screen (w/aid of raster interrupts to do vertical re-use).

 

What about STe machines-- I thought they expanded the graphics capabilities on those.

[atariksi]

http://en.wikipedia.org/wiki/Bitplanes

 

Better to understand Planar mode which uses bitplanes. It only has to do with the way a color is encoded as compared to chunky mode. So it has nothing to do with size of the bitplane. Atari multicolor player uses planar mode. C64 multicolor player uses chunky mode. And as I explained before, two atari multicolor sprites give you 6 colors (+see thru) whereas two C64 multicolor sprites give 4 colors (+ see thru).

[Rybags]

STe has no sprites.

 

IIRC, it adds fine H-scrolling, the ability to set screen address on a 2-byte boundary instead of 256, 12 bits per palette entry rather than 9, and the ability to change the current screen fetch address on the fly.

[atariksi]

If you had the means, you could change a colour register per cycle on GTIA. Fast enough to have Gr. 10 with all colours, no limitations.

 

If you had a quick enough CPU, you could take Antic out of the equation anyway... just drive GTIA directly through the AN0-2 lines.

 

But if you were to go to that extent, may as well drive 3 of them for seperate RGB component output.

 

Let's make this more realistic. Suppose the hardware was just a 14.31818181818Mhz CPU upgrade-- all other chips are the same. So it's up to software not to drive the chipset beyond 1.78979Mhz. Basically, you have to use at least 8 CPU cycles to code your write to the palette registers or GPRIOR register. If you use graphics 10, you could set up the 9 palette registers in HBlank. Then you have 80 CPU cycles @1.79Mhz during display time minus 9 Refresh cycles minus 38 DMA cycles (2 cycles done before display starts) = 33 CPU cycles in display region. So you can re-use a color register 33 times + 9 initial = 42 unique colors/scanline.

 

A better approach would be to mix in GPRIOR effects, sprite overlays and use 160*200 mode.

[Atari_Owl]

Fair enough, it's possible i'm just thinking of it from a UK perspective.

I'd only checked here:

http://www.old-computers.com/museum/comput...?st=1&c=252

 

which stated May 81 and tied up with my memories of the time. But who knows what country's release that was.

 

Edit: Actually even reading that page more closely it says late 1980 as the 1001 in Japan first so even there it does indeed say 1980 (though not as the Vic20 as such even if its the same machine ) and to be fair, your reference also states that it didn't hit store shelves until 1981, and if we accept May quoted in Old-computers then even if Ataris weren't available til christmas 79 thats still 18 months.

 

Between early 1981, when the VIC actually hit store shelves,

 

Well it doesn't really matter anyway - i agree that compared to its contempories with their sugar cube 80x50 graphics, predominantly monochrome displays etc - the 800 WAS a significant step - it just wasn't capitalised upon.

 

The 400/800 did have a small jump on the Vic-20 which was a toy by comparison. I wonder if Commodore even knew Atari was developing a machine. The PET was more of a business machine and I don't think I ever knew anyone who had one.

 

It seemed to me that in 1979 through 1980 you almost had to discover the 800 by accident. Everyone here had heard of the Apple and had seen a TRS-80 in RadioShack but you had to search out an Atari dealer. Atari certainly had access to retailers but I think they were trying to be somewhat exclusive at first and I think they missed their window.

 

-Bry

 

Actually that's a very good point, certainly the Apple, TRS80 and to a degree Sharp were more visible - as much as anything really was prior to 81/82.

[Fröhn]

Yeah, you use up two A8 multicolor players + missiles to get 2 C64 multicolor players in width.

Not quite. All A8 MC PMs = 20 pixels wide, two MC C64 sprites = 24 pixels wide.

 

Better to understand Planar mode which uses bitplanes. It only has to do with the way a color is encoded as compared to chunky mode.

"Bitplanes" are the groups of bits in a picture with the same ordinality. Chunky mode also has bitplanes

 

And as I explained before, two atari multicolor sprites give you 6 colors (+see thru) whereas two C64 multicolor sprites give 4 colors (+ see thru).

It's not two Atari sprites but four which are used as "two" by using the same screen positions for pairs of PMs. Now simply use 4 C64 sprites and use them as pairs, that will give you 6 colors too.

[atariksi]

Yeah, you use up two A8 multicolor players + missiles to get 2 C64 multicolor players in width.

Not quite. All A8 MC PMs = 20 pixels wide, two MC C64 sprites = 24 pixels wide.

 

...

Practically you do since each missile can be set to be sized, moved by one or two away from player, etc. So by wise choice of positions and colors, you can make it look like 12 pixels wide (I have done this).

 

>"Bitplanes" are the groups of bits in a picture with the same ordinality. Chunky mode also has bitplanes

 

The way you look up color information in planar organization of bitplanes vs chunky is different.

 

>>And as I explained before, two atari multicolor sprites give you 6 colors (+see thru) whereas two C64 multicolor sprites give 4 colors (+ see thru).

 

>It's not two Atari sprites but four which are used as "two" by using the same screen positions for pairs of PMs. Now simply use 4 C64 sprites and use them as pairs, that will give you 6 colors too.

 

Did you like miss the point of the past hundred+ posts. One multicolor Atari sprite is two monochrome sprites-- that's what all this bitplane/planar mode discussion starting from. Read again: TWO atari MULTICOLOR sprites gives 6 colors; two multicolor C64 sprites gives 4 colors; Atari has a better multicolor sprite but it has less of them.