Atari v Commodore

[Crazyace]

>GTIA is the strengh of the Atari in the colour sense ( I did mention in the original post about colour range )

I think the C64 sprite h/w is a large portion of the chip - it's actually almost competitive with the NES in someways - it wasn't till the SNES/Megadrive that you could cover a complete scanline with sprites! ( I know you can retrigger the pm graphics - but you'd have to retrigger them a lot before you matched the standard C64 sprites, and there would be difficulties in a game situation )

 

Yeah, sprites don't have to be triggered vertically but horizontally. Whereas on C64 they would have to be retriggered vertically. So there are tradeoffs. But if you just want to cover the screen, you can do that with Atari by quad width and using just the 5 players without any DLIs and use it to give a background color in text mode.

 

Seems a little harder than the C64 - where you'd use an inverse character set and extended background to get 16 backgrounds + 4 foreground colours.. - and scrolling might be a bit of a chore

 

 

 

>The colours per scanline is the other improvement - that's the big win from the colour ram. It doesn't really matter if you can get 17 colours per scanline with a software loop ( I can do that with a 2600 )

 

Colour RAM is in text mode. I haven't seen any program on C64 that allows you to show any of the 16 colors on any pixel in 160*200. There are restrictions so with restrictions you can show more than 16 unique colors/scanline. I just gave a simple example.

I haven't seen any program on the 8 bit that allows that either

 

On the plus side for the 8 bit - the '256' colur GTIA9/11 mode still impresses today - lowres, but true colour in a way that nothing else could match until the Amiga with HAM ( or ST with Spectrum512 , or maybe the MSX2? )

[Oswald]

Original argument was maximum colors per scanline w/o sprites. If I use GTIA, I can show 80 colors/scanline but then the palette is restricted.

 

sure, the same way I can display 80 colors on the speccy. so much about your arguments.

[atariksi]

>>Yeah, sprites don't have to be triggered vertically but horizontally. Whereas on C64 they would have to be retriggered vertically. So there are tradeoffs. But if you just want to cover the screen, you can do that with Atari by quad width and using just the 5 players without any DLIs and use it to give a background color in text mode.

 

>Seems a little harder than the C64 - where you'd use an inverse character set and extended background to get 16 backgrounds + 4 foreground colours.. - and scrolling might be a bit of a chore

 

Yeah, perhaps some GRAFn writing for VSCRL of background color info.

 

>>Colour RAM is in text mode. I haven't seen any program on C64 that allows you to show any of the 16 colors on any pixel in 160*200. There are restrictions so with restrictions you can show more than 16 unique colors/scanline. I just gave a simple example.

 

>I haven't seen any program on the 8 bit that allows that either

 

With restrictions you can have many unique colors per scanline at 160*200 and with GTIA interlace a lot more.

 

>On the plus side for the 8 bit - the '256' colur GTIA9/11 mode still impresses today - lowres, but true colour in a way that nothing else could match until the Amiga with HAM ( or ST with Spectrum512 , or maybe the MSX2? )

 

How does the Atari ST display a 16-shade Atari image or 30 shade interlaced image? Never heard of MSX2.

[atariksi]

Original argument was maximum colors per scanline w/o sprites. If I use GTIA, I can show 80 colors/scanline but then the palette is restricted.

 

sure, the same way I can display 80 colors on the speccy. so much about your arguments.

 

Without interlace, you can do it-- you can switch out the entire 16-colors with LDA/STA midscreen 7 times per scanline.

[Thorsten Günther]

Does anybody have any views on where any titles were launched on both Atari and Commodore - and the Atari version is the better of the two?

 

David's Midnight Magic. The Atari version uses artifacting to get four colors in 320-wide mode. The Commodore version tries, but artifacting doesn't work on the C64.

 

Almost anyone here in Europe hates Graphics 8 artifacting for the simple reason that artifacting doesn't work on PAL TVs the way it does on NTSC TVs - it just give black, white and something ugly changing between blueish and brownish. Some guys hence hacked Drol and several other games (Crossfire, Hard Hat Mack spring to mind) to Graphics 15 - Lode Runner (cart) was even officially converted to that mode. Sadly, Tower Toppler is not (yet) on that list.

 

A game way better on the Atari is Amaurote - the C=64 version doesn't even have the fancy isometric graphics from the Amstrad(?) original.

 

 

Thorsten

[analmux]

so now show me some scrolling games which outperform c64's scrolling games, to proove your case.

 

OK, of course this isn't a complete game, but have a look at this Atari executable enclosed.

 

Note:

-It is scrolling (fast) in all 8 directions.

-Pokey Music in the background.

-Size of screenmemory (for this scroll-engine) is not larger than 920 bytes in total: No double or triple buffering used or needed.

 

Scrolling could even be faster when using a screenbuffer of f.e. 16kbytes, then even no gfx-unpacking would be needed, but this executable was designed to work with a minimum of screenmemory. So, in fact, here Antic's feature of allowing 16kb screenmaps isn't used.

 

This screen setup works thanks to Antic DList features. I don't see how it would work on C64, without glitches OR without the need for a double screenbuffer. Remember that colour-RAM can't be double-buffered.

 

Turrican on C64 has a great 8dir scrolling, but runs in a smaller screen-area and it is somewhat slower than this one.

 

I remember the 'fast' levels of turrican2, with the spaceships:

-the (fast) 8dir parts have a 'constant' colour-RAM

-the fastest parts (level 3-3, boss at the end: scrolling in circles): very fast scrolling, but even screenram isn't really updated there.

 

...Other 8dir scrolling games on C64? I don't know too much of C64 games

[Fröhn]

>>Yes, the interlace is crap when colors are far apart but Atari has shades that so that shade 2 interlaced with shade 3 produces shade 2.5 which is perfectly useable. Software driven modes are essentially something the hardware is allowing you to do.

>128 color palette on Atari has 8 different luminances, 16 color palette of C64 has 9 luminances. Pretty much the same when it comes to interlace. And with the half-pixel shift you can do true horizontal interlace on C64 too.

 

You can have 16lums+16lums (31 shades) or 16lums+8lums (30 shades) of any of the 16 colors. Now tell me which 9 luminance levels you are talking about on the C64?

Black and White + two times 7 luminance levels used for the other 14 colors.

 

I can construct any waveform using just two DACs and playback is 21Khz which is impossible on the C64. So you cannot establish SID>POKEY.

You cannot create any waveform. You can create some waveforms but it's very CPU intensive, that's why the sound chip is supposed to do it. For example, emulating the SID filters is impossible for the poor 6502.

 

Again, you can have overscanned scrolling displays horizontally and vertically so there's scrolling hardware features you can't do on C64.

True. Although you can scroll expanded sprite layers over all borders.

 

 

>>>CPU overhead for scrolling: Atari > C64

>>Err, that's not a hardware feature.

>Ofcourse it is.

Overhead is not a hardware feature argument. Both machines have scrolling hardware. How is the C64 have less overhead?

I said the C64 has more overhead.

 

Higher accuracy than C64? How can a timer be more accurate than "1 clock cycle per timer step"?

By having more steps per second. Which is more accurate a ruler with centimeter markings or one with inch markings?

Doesn't matter. The only thing which matters to the programmer is the clock cycle accuracy, both are 1 timer cycle = 1 clock cycle.

 

I want to see that-- an C64 IRQ that occurs on an exact point on screen. I thought your timer is not evenly divisible with CRT's colors clocks.

Get rid of those "color clocks". They do not matter, and even on PAL Atari the color clock isn't dividable by the CPU clock.

 

To answer your question: Yes you can easily have IRQs at any clock cycle on screen. And NMIs too.

 

Yeah, sprites don't have to be triggered vertically but horizontally. Whereas on C64 they would have to be retriggered vertically. So there are tradeoffs. But if you just want to cover the screen, you can do that with Atari by quad width and using just the 5 players without any DLIs and use it to give a background color in text mode.

Retriggering sprites on C64 is very easy: One STA every 21 rasterlines to retrigger a sprite. On Atari you need to do it every rasterline.

 

Colour RAM is in text mode. I haven't seen any program on C64 that allows you to show any of the 16 colors on any pixel in 160*200. There are restrictions so with restrictions you can show more than 16 unique colors/scanline. I just gave a simple example.

Color RAM is in every C64 mode. No matter if hires bitmap, lores bitmap or the different text modes.

 

Perhaps, you want to explain how NTSC scrolls a colored pixel 1/320 pixel while retaining the same color.

By not changing the phase of the color carrier when scrolling.

 

I/O was one argument so it's all under I/O. If you want to split it up, I can just do joystick I/O on both if you want and Atari will be >2X faster than C64. What's your maximum transfer rate on the 1541 drive so we can compare with SIO max. rate?

10 kB/s when reading from disk with a good routine. Pure IEC bus transfer rate is 2-3 times of that, but somewhere the drive has to read the sectors too

[analmux]

Seems a little harder than the C64 - where you'd use an inverse character set and extended background to get 16 backgrounds + 4 foreground colours.. - and scrolling might be a bit of a chore

 

However, there still was somebody who did it, including scrolling:

 

(when it is running you can use keys 1,2 or 3 to select/deselect/change demo-features, like turning sprite underlays on/off, etc. Push 'HELP'-console-key for showing description of the keys)

[Oswald]

OK, of course this isn't a complete game, but have a look at this Atari executable enclosed.

 

I know this tech, its very nice, but sorry, but the point was to push atariski to admit the truth. c64 is better when it comes to 2d (scrolling) games. instead he just didnt answer. well, thats a sort of admitting aswell.

[atariksi]

OK, of course this isn't a complete game, but have a look at this Atari executable enclosed.

 

I know this tech, its very nice, but sorry, but the point was to push atariski to admit the truth. c64 is better when it comes to 2d (scrolling) games. instead he just didnt answer. well, thats a sort of admitting aswell.

 

You wrote: "so when it comes to gfx/sound/2d games the c64 can perform better. when its all about cpu power atari wins." now where does it state you are talking about some particular 2d scrolling game? I can also write a 2D scrolling game that you can't do on the C64 so there's no truth established to admit to.

[TMR]

That argument of Atari colors more than C64 is always true. When you want to argue how many colors can you show in 160*200 on one scanline, that's a different argument. Do you want to argue this?

 

No, i don't want to argue anything because my point is still that this is all hugely subjective. But if we're going to argue, the C64 does 320x200 with 16 colours a scanline and 8x8 pixel attribute cells where the colours are independent between background and foreground, that'd be my opening gambit...

 

Perhaps, you want to explain how NTSC scrolls a colored pixel 1/320 pixel while retaining the same color.

 

Well, i can't explain it because i'm rubbish with hardware... but here's a bit of Spectacular Rise And Fall Of Commodore where designer Bob Yannes goes into detail:

 

'"It was the same thing with the Apple and Atari computers," explains Yannes. "You would get interaction between the luminance signal, which is the black and white information, and the color signal. So you would end up with these various colors on the screen that weren't really what you wanted, but it was just the nature of the NTSC video standard that the luminance and chrominance signals interact with each other." To purify the colors, Charpentier made a risky last minute change. "Al had the idea that if the two clocks were independent from each other then that interaction wouldn't happen," says Yannes. "We separated the clock generators on the VIC chip so that the color crystal was a separate clock from the video shift rate."'

[TMR]

Original argument was maximum colors per scanline w/o sprites. If I use GTIA, I can show 80 colors/scanline but then the palette is restricted.

 

sure, the same way I can display 80 colors on the speccy. so much about your arguments.

 

Without interlace, you can do it-- you can switch out the entire 16-colors with LDA/STA midscreen 7 times per scanline.

 

That's not hardware, you're not sticking to your own rule of keeping it simple...

[Crazyace]

Seems a little harder than the C64 - where you'd use an inverse character set and extended background to get 16 backgrounds + 4 foreground colours.. - and scrolling might be a bit of a chore

 

However, there still was somebody who did it, including scrolling:

 

(when it is running you can use keys 1,2 or 3 to select/deselect/change demo-features, like turning sprite underlays on/off, etc. Push 'HELP'-console-key for showing description of the keys)

 

Are there 16 background+8 foreground colours per line - I only counted 9

 

It's nice - but where are the player and enemy sprites - on the c64 you could have 8 multicolour sprites without any difficult programming needed

[Oswald]

You wrote: "so when it comes to gfx/sound/2d games the c64 can perform better. when its all about cpu power atari wins." now where does it state you are talking about some particular 2d scrolling game? I can also write a 2D scrolling game that you can't do on the C64 so there's no truth established to admit to.

 

stop blabbling, show me a 2d scrolling game on the a8 which is better than any other c64 one. why there's none ? why is turrican literally impossible for the a8? even if I let it go with 5 colors only, its impossible, why oh why ? with a BETTER gfx chip, a machine which is better overall it should be possible, innit ?

[TMR]

I can also write a 2D scrolling game that you can't do on the C64 so there's no truth established to admit to.

 

But until you actually write it, there's no way to disprove his argument either... i'm intrigued as to what specifically you had in mind, though.

Edited November 22, 2008 by TMR

[atariksi]

>>You can have 16lums+16lums (31 shades) or 16lums+8lums (30 shades) of any of the 16 colors. Now tell me which 9 luminance levels you are talking about on the C64?

>Black and White + two times 7 luminance levels used for the other 14 colors.

 

Yeah, but now you're mixing color+luminance which will increase flicker and also increase number of combinations of colors on Atari as well.

 

>You cannot create any waveform. You can create some waveforms but it's very CPU intensive, that's why the sound chip is supposed to do it. For example, emulating the SID filters is impossible for the poor 6502.

 

Upto 21Khz using DACs.

 

>>Overhead is not a hardware feature argument. Both machines have scrolling hardware. How is the C64 have less overhead?

>I said the C64 has more overhead.

 

Okay, but Oswald just stated 2d scrolling is better on C64.

 

>>By having more steps per second. Which is more accurate a ruler with centimeter markings or one with inch markings?

 

>Doesn't matter. The only thing which matters to the programmer is the clock cycle accuracy, both are 1 timer cycle = 1 clock cycle.

 

So you are heading toward the subjective path again. Sure it matters and the hardware potential is more on the Atari.

 

>Get rid of those "color clocks". They do not matter, and even on PAL Atari the color clock isn't dividable by the CPU clock.

 

Sorry, I need to use the color clocks. PAL also has 228 color clocks/scanline. Any Atari PAL users here want to prove?

 

>To answer your question: Yes you can easily have IRQs at any clock cycle on screen. And NMIs too.

 

It did not work. CIA timer is not accurate enough and not evenly divisible into color clock frequency perhaps.

 

>Retriggering sprites on C64 is very easy: One STA every 21 rasterlines to retrigger a sprite. On Atari you need to do it every rasterline.

 

Yeah, so I gave the C64 the edge on the sprites.

 

>Color RAM is in every C64 mode. No matter if hires bitmap, lores bitmap or the different text modes.

 

But it's at text mode resolution so I wanted some C64 guy to show they can do 160*200*16 without restrictions.

 

>>Perhaps, you want to explain how NTSC scrolls a colored pixel 1/320 pixel while retaining the same color.

 

>By not changing the phase of the color carrier when scrolling.

 

I did not know C64 had circuitry to set color carrier phase on the TV dynamically. Perhaps, they forgot to put it in my C64.

 

>>I/O was one argument so it's all under I/O. If you want to split it up, I can just do joystick I/O on both if you want and Atari will be >2X faster than C64. What's your maximum transfer rate on the 1541 drive so we can compare with SIO max. rate?

>10 kB/s when reading from disk with a good routine. Pure IEC bus transfer rate is 2-3 times of that, but somewhere the drive has to read the sectors too

 

So it's not much better than SIO. Yeah, bus transfers would be faster than SIO speed on both machines.

So given Joystick I/O is > 2X faster on Atari, overall I/O is better on Atari.

[Oswald]

I can also write a 2D scrolling game that you can't do on the C64 so there's no truth established to admit to.

 

But until you actually write it, there's no way to disprove his argument either... i'm intrigued as to what specifically you had in mind, though.

 

my bets: he will change the colors with dlis "look 32 colors", or simply claim that the pixel aspect ratio is different or overscan stuff so its impossible on the c64

[Goochman]

Maybe I could simplify it this way for 6502 based machines:

 

Business - Apple II+

 

Games - C64

 

Biz/Games - Atari XL

 

The Atari wasnt quite as good at Biz apps, but its hardware lent itself to being better than the C64 (speed wise). The C64 had higher rez and better use of multi-colors making it a better games machine than the Atari in most 80's games related cases.

 

That work for everyone?

 

Back to my Quad core 4gb Vista 64 machine so I can run AtariWin800

Edited November 22, 2008 by Goochman

[atariksi]

You wrote: "so when it comes to gfx/sound/2d games the c64 can perform better. when its all about cpu power atari wins." now where does it state you are talking about some particular 2d scrolling game? I can also write a 2D scrolling game that you can't do on the C64 so there's no truth established to admit to.

 

stop blabbling, show me a 2d scrolling game on the a8 which is better than any other c64 one. why there's none ? why is turrican literally impossible for the a8? even if I let it go with 5 colors only, its impossible, why oh why ? with a BETTER gfx chip, a machine which is better overall it should be possible, innit ?

 

When I started participating in this thread, I stated we are measuring potential of each machine. Whether some software has been written or how many users are there is of no consequence. You can go back and read for yourself as I have not edited my replies. Now that you have separated the 2D scroll from GFX/Sound/2d, in what way is your gfx chip superior in 2D scrolling? Don't tell me it's because of sprites.

[Oswald]

So it's not much better than SIO. Yeah, bus transfers would be faster than SIO speed on both machines.

So given Joystick I/O is > 2X faster on Atari, overall I/O is better on Atari.

 

you have issues. joystick I/O!= overall I/O.

[Oswald]

Whether some software has been written or how many users are there is of no consequence.

 

Brain usage would have a serious impact on your replies tho.

 

So speccy is better than A8, hence the potential of its HW is there and "Whether some software has been written or how many users are there is of no consequence."

[atariksi]

Maybe I could simplify it this way for 6502 based machines:

 

Business - Apple II+

 

Games - C64

 

Biz/Games - Atari XL

 

The Atari wasnt quite as good at Biz apps, but its hardware lent itself to being better than the C64 (speed wise). The C64 had higher rez and better use of multi-colors making it a better games machine than the Atari in most 80's games related cases.

 

That work for everyone?

 

Back to my Quad core 4gb Vista 64 machine so I can run AtariWin800

 

It won't for everyone because you have not proven it. This thread started off people giving examples of Atari games that are better than C64 so that does in your claim. You are looking at it one dimensionally. There are MORE colors on Atari vertically in any mode. Horizontally, it depends on the mode, but both have restrictions. And Atari has more colors regardless of C64 graphics mode.

 

And as far as your 4GB Vista 64 machine goes, I doubt you can do some things the C64 and Atari can do in real-time. Try writing code that writes an asm routine and calls it or timing something more accurately than either C64 or Atari. You need to pick up an Atari 800XL from Ebay. You need to remove the L1 and L2 caches from your machine and slow down the processor, shut off power management, turn off branch prediction, set RAM speed to same as processor, etc. so you can use the processor to time things more accurately.

[atariksi]

So it's not much better than SIO. Yeah, bus transfers would be faster than SIO speed on both machines.

So given Joystick I/O is > 2X faster on Atari, overall I/O is better on Atari.

 

you have issues. joystick I/O!= overall I/O.

 

Because all other I/O is pretty much the same so joystick I/O gives big edge and so overall it goes to Atari. See how simple it is.

[atariksi]

Whether some software has been written or how many users are there is of no consequence.

 

Brain usage would have a serious impact on your replies tho.

 

So speccy is better than A8, hence the potential of its HW is there and "Whether some software has been written or how many users are there is of no consequence."

 

You can go debate that with someone who is familiar with speccy. I never heard of it. If you go by what software has been written for it, then you are not establishing the truth. It's subject to change. If you understand the underlying hardware of both, you can make certain conclusions that are objective.

[Fröhn]

>>You can have 16lums+16lums (31 shades) or 16lums+8lums (30 shades) of any of the 16 colors. Now tell me which 9 luminance levels you are talking about on the C64?

>Black and White + two times 7 luminance levels used for the other 14 colors.

 

Yeah, but now you're mixing color+luminance which will increase flicker and also increase number of combinations of colors on Atari as well.

The human eye is very lazy on chrominance. That's why chroma has such an extremely low resolution on PAL/NTSC and the luma has high resolution.

 

You cannot create any waveform. You can create some waveforms but it's very CPU intensive, that's why the sound chip is supposed to do it. For example, emulating the SID filters is impossible for the poor 6502.

Upto 21Khz using DACs.

Which leaves no CPU time for something else. Dude, the sound chips generate the waveforms because the CPU is busy with other things, like "running a game" etc.

 

Get rid of those "color clocks". They do not matter, and even on PAL Atari the color clock isn't dividable by the CPU clock.

Sorry, I need to use the color clocks. PAL also has 228 color clocks/scanline. Any Atari PAL users here want to prove?

There are 114 CPU clock cycles per rasterline but 285 PAL color clock cycles.

 

(4.43361875 MHz color carrier vs 1.77 MHz CPU)

 

To answer your question: Yes you can easily have IRQs at any clock cycle on screen. And NMIs too.

It did not work. CIA timer is not accurate enough and not evenly divisible into color clock frequency perhaps.

What are you talking about? Why are you so focussed on the color clock? That one does not matter to the CPU, the only clock which matters for timers & CPU is the clock where the CPU and timers are clocked. In case of the Atari that is either 1.77 MHz or 1.79 MHz, in case of the C64 it's either 1.02 MHz or 0.985 MHz.

 

Color RAM is in every C64 mode. No matter if hires bitmap, lores bitmap or the different text modes.

But it's at text mode resolution so I wanted some C64 guy to show they can do 160*200*16 without restrictions.

You don't need "no restrictions" because that would only be useful for color bars, not graphics.

 

But to satisfy you: There are 40x25 color cells which are 8x8 (hires) or 4x8 (lores) pixel big. The height of those color cells can be modified down to 1 rasterline, so you get 40x200 color cells instead, which offers almost full 16 color mode at 160x200.

 

Perhaps, you want to explain how NTSC scrolls a colored pixel 1/320 pixel while retaining the same color.

By not changing the phase of the color carrier when scrolling.

I did not know C64 had circuitry to set color carrier phase on the TV dynamically. Perhaps, they forgot to put it in my C64.

It's just a color carrier phase, and if color X is displayed, phase Y is used. It is NOT moved with scrolling, because it has nothing to do with scrolling. Scrolling is done loooong before the output of colors.

 

So it's not much better than SIO. Yeah, bus transfers would be faster than SIO speed on both machines.

So given Joystick I/O is > 2X faster on Atari, overall I/O is better on Atari.

That was IEC bus. C64 has other busses too, like the 8 bit parallel port where you can ofcourse reach much higher transfer rates.

 

EDIT: Ok I looked SIO bus speed up: It's 19200 bps, with start and stop bit that boils down to about 2 kB/s. Can you explain me how ten times more speed on IEC (20 kB/s) is "not much faster"?

Edited November 22, 2008 by Fröhn