Atari v Commodore

[atariksi]

- Atari has 256 palette colors

No it hasn't. It's 128 colors in most modes + PMs. 256 only works in one GTIA mode and the 256 color mode which only works on PAL machines. No to mention that 160x200 = 4 colors and 320x200 = 2 colors. Doesn't matter what palette, 4 colors will always look like 4 colors and 2 colors will always look like 2 colors.

 

- Atari has 1.79Mhz CPU

Which loses many cycles to ANTIC. So in the end it's just 20% faster than the 0.985 MHz CPU of the C64. Nothing left of the "2 times faster" which atariski dreams of.

 

- Atari has 128K

I could pull out the C128 now. Or I could mention that no XL and no 400/800 has 128k.

 

You're replying to someone else so's arguments so don't make attacks on me until you can answer all the points I have raised which you have yet to reply to. Atari CPU is 1.79X faster when I write consecutively to DAC registers, when I update registers during HBLank, VBLank, etc. The fact that some DMA cycles come in does not slow down the CPU. You just skip a cycle from the software's perspective. So if I update, for example, a DAC register with STX 532761 and STY 53761 during HBLank I can guarantee that 2nd write will be 558*4 ns later. Oops, I forgot I just enable fast pot scan and do an INC/DEC/ROL/ROR/etc. on 53761 and I get a write 558ns later. Now go analyze the C64's speed.

 

GTIA modes can be mixed with normal modes so you do get 256 colors available during a frame.

[atariksi]

Okay, frohn read the replies-- don't skip and state the same thing again and again based on your biased imperfect analysis. Here's the reply you forget to reply to again (see above).

My biased analysis? It is your biased analysis. What you are trying to do is to find something against the C64s strongest feature: sprites. If there is one field where the C64 can beat the A8 any day it's sprites.

 

I am NOT trying to find something against C64s sprites. I HAVE ALREADY PROVEN somethings atari sprites can do better than C64s sprites-- only your biased analysis and trying to confuse people is preventing you from understanding it. You cannot put up 2000+ moving 8*1 sprites was the latest thing I showed. Multicolor sprite implementation was another one. So for all the hardware aspects I compared in this thread, you want me to just keep repeating C64 sprites have higher horizontal sprite resolution and coverage. Sorry, that would be biased.

[atariksi]

Let's just reverse the plan: I do something on C64 and atariski tries to do it on A8.

 

First let's see the 2000+ moving sprite algorithm rather than try to shove it under the rug with words like "useless", "waste", "it can be done", etc.

[atariksi]

Going back to original question-- which machine can put up more sprites simultaneously on the screen. Atari can and I specifically mentioned thousands 8*1 flooded all over the screen. You stated C64 can do the same. Now you are arguing some other point-- there's a CPU restriction or Y-axis motion does not have enough cycles. First you need to make up your mind whether you are still going to stick to C64 can do the same or not before you try to raise other issues. Sprites are still sprites even if they don't move in the y-axis.

 

Just to clarify - are you talking about thousands of different 8x1 bitmaps moving around the screen, or thousands of identical 8x1 bitmaps , or thousands of 8x1 lines ?

 

How many thousands? and what resolution are these 8x1 bitmaps ( 320pixel, or 160 pixel )

 

You can have 2000+ sprites at 8*1 moving on the screen. It's easy math-- you have 4 players at 8*1 full height screen and vertically multiplexed every scanline and you have 4 missiles vertically multiplexed every scanline and zoomed to 8*1. That's 248*8 visible sprites on PAL, 240*8 visible sprites on NTSC...

 

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

You forgot the "..." in my message (I had to run away for a couple of hours).

 

The standard set of players and missiles replicated every line gives 240*4 of 8*1 and 240*4 of 2*1 missiles zoomed to 8*1 so total 8*1 sprites is 1920. Now you use horizontal sprite replication using GRAFn/HPOS of a player to get another 8*1 sprite every other scanline or so. This gives 2040 sprites for NTSC and more for PAL. So it's 2000+ as I stated. And that's with all DMA channels enabled at 54272. And this is without using GRAFn to replicate vertically for free (so not stretching it at all).

 

fair enough... but would it be not more fair to speak of sprite overlay? nobody would actually speak of sprites when talking about G2F PM over/underlays?

 

If my memories are right I would found sources in this thread when you were talking about sprite overlays and treat it like separate bitplanes? which is imho better when we are using them as an overlay...

 

The talk about bitplanes was when I was comparing different methods of encoding color-- Amiga uses bitplanes for color encoding which just happens to be exactly how the multicolor sprite implementation works on A8.

 

Overlays/underlays are different in that they are static. In the above algorithm, you can set the XPos for each of the 2000+ sprites. And for demo purposes, you can maintain PMBase reflecting different Y-positions and switch out PMBase during VBLank and with one swoop you have also set the Y-positions as well.

[atariksi]

Even though the idea of 1,900 + moving objects is bordering on rediculous on either machine, I doubt you'd be repositioning many sprites per scanline on the C-64.

 

Badlines are the enemy here, although I suppose you can use VScroll tricks to just repeat the one line of characters indefinately without incurring any badlines?

 

Such a demo might be interesting, but you'd need compromises like using positional data multiple times. Maybe something like using a 128 byte X-pos buffer per object.

Read it in order first time, read it backwards and add an offset the second pass.

 

you can not reposition sprites on c64 on a rasterline. no sprite #0 twice per line...

 

so...on the "new" definition here...when I am moving around 7168 pixels per frame... i could claim >7000 software sprites????

 

Let's not mix sprites with pixel positioning. In my example, I have an image in the background which is unaffected by the moving sprites which would not be the case if you were modifying pixels. Just looking at the specs: Atari 800 still has 8 sprites (4 players/4 missiles), but that was an example of how more powerful Atari is in re-using it's hardware resources.

[emkay]

GTIA modes can be mixed with normal modes so you do get 256 colors available during a frame.

 

 

Fröhn is wrong again. The ATARI, ofcourse, can display real 256 colour images. Just, again, the missing tools are not available. So here a limited 256 colour pic, done in G2F.

 

[atariksi]

Atariski...you should really come down to earth... you seem to have fun in terms of try to discuss in a "correct" manner like we learned in school and in philosophic course at university... but is it pratical?

 

yes...of course you can call 240x8 = 1920 sprites but in reality? can you move them around? can you at least do something practical with them in games?

 

you would need to feed in a kernal 8 hpos registers plus 4 graphpx registers plus 1 graphm register not to mention the colour registers...

 

aehm... should we now state that 800 has 1920 hardware sprites? in 256 colours? come on...

 

same goes to some of your aspects refering to a single bit of hardware... sometimes I feel you are too academic with the loose for reality...

 

I did give example of practical use that I did-- enhance an image by overlaying top of Graphics 9 mode (that's antic mode K)-- in that case there were 4 8*1 per line and 4 2*1 per line and few more wherever I could squeeze them in (total > 2000).

 

You don't need to set GRAFn more than once per line. You have the GRAFn set via DMA automatically for the 4 players and missiles and you have enough time to setup another GRAFn and set another HPOS >100 times per frame even after updating all 8 HPOSes for players and missiles.

 

I don't know what you are talking about regarding the "single bit of hardware".

 

And if by "correct" manner you are complaining about my dealing with Frohn-- he was being duplicitous-- first he states C64 can also do what Atari can regarding 2000+ sprites and then when proven wrong he has this backup plan-- it's useless or it's impossible to do on Atari as well. Nice deceptive way to argue huh--

plan A: whatever Atari can do just say C64 can do until someone proves you wrong;

plan B: if they do prove it wrong, just say it's useless until someone thinks of good use for it;

plan C: if they do find a good use for it, just say that Atari can't do it either until someone actually goes and does it or prove it can be done.

plan D: if they prove it can be done, pretend you missed that posting because you left town, went on vacation, etc. and repeat the same point again (The TMR may have been the original found of this plan).

That does apear to be his plan from what I have seen in this thread.

 

Amazingly enough he used plan D to dismiss this post and used plan A,B, & C again since this post.

[atariksi]

The C64 has not been designed to be technology advanced , it has been designed to cost the less as possible.

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is.

 

...

 

It's competitive but that doesn't mean it wins in all cases. There are many events in the olympics so just because you have a faster backstroke/freestyle swimmer doesn't mean you'll win all swimming events. Get the picture? Your logic is that when Atari shows it's better at sprite useage in vertical direction or in overscanned cases or other cases, you're going to show wider sprites at more resolution although the event calls for something else. So when we talk about collision detection of 60 bits vs. 8 bits + 8 bits of vagueness, you're still going to use your freestyle swimmer.

 

P.S.: for those that don't know there's a C64 register for sprite detection called the "Vague sprite collision register": whenever a sprite collides with another sprite, it sets the bit for both sprites that collided. So if sprites #0 and #1 collide and sprites #4 and #5 collide, you end up with 4 bits being set. And now if sprites #0 and sprites #4 collide and sprite #1 and sprite #5 collide, it sets the same 4 bits and so on. So to calculate what collisions actually took place, you can do the following algorithm:

 

eenie, meenie, minie moe

catch the sprite that is colliding so

if it's not colliding, you won't know

but who cares if you let one go

...

[Crazyace]

Just thinking - On the VCS I can reuse the sprites to get 18 sprites on a line - I can't do this on the 8 bit - so does this mean the VCS sprite hardware is superior to the 8 bit sprite hardware

[emkay]

But I understand that you are not able to accept that anything that C-64 can't actually do (easily, like opening the borders, or at all, like 256 colors) "does really matter"; as everyone knows, that the 16 colors (incl. 5 brown and 5 violet) is better than 256 (be it 128), 20%-100% faster CPU does not really matter, bigger screen does not really matter, more memory (which means that upgrades are common and coders can use them, if they want) does not really matter etc. as long as these are things C-64 can't do.

 

 

In the "real world" things turn fully different.

I'm talking about AYO Technoloy .... the Timbaland Music that uses a SID Station.. place 30-20 in the charts

 

http://www.youtube.com/watch?v=gX8T6J_N74w...feature=related

 

Without SID it made it placed 1st in Germany

 

 

 

Edited April 10, 2009 by emkay

[Allas]

The C64 has not been designed to be technology advanced , it has been designed to cost the less as possible.

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is.

 

...

 

It's competitive but that doesn't mean it wins in all cases. There are many events in the olympics so just because you have a faster backstroke/freestyle swimmer doesn't mean you'll win all swimming events. Get the picture? Your logic is that when Atari shows it's better at sprite useage in vertical direction or in overscanned cases or other cases, you're going to show wider sprites at more resolution although the event calls for something else. So when we talk about collision detection of 60 bits vs. 8 bits + 8 bits of vagueness, you're still going to use your freestyle swimmer.

 

P.S.: for those that don't know there's a C64 register for sprite detection called the "Vague sprite collision register": whenever a sprite collides with another sprite, it sets the bit for both sprites that collided. So if sprites #0 and #1 collide and sprites #4 and #5 collide, you end up with 4 bits being set. And now if sprites #0 and sprites #4 collide and sprite #1 and sprite #5 collide, it sets the same 4 bits and so on. So to calculate what collisions actually took place, you can do the following algorithm:

 

eenie, meenie, minie moe

catch the sprite that is colliding so

if it's not colliding, you won't know

but who cares if you let one go

...

 

mmm... this require the knowledge of Fröhn or TMR. I sure there is a satisfactory answer.

 

Other way, on Atari we can distinct the collision with background graphics, doing distinction over each pixel color. I guess on C64 is not posible.

Edited April 10, 2009 by Allas

[atariksi]

Just thinking - On the VCS I can reuse the sprites to get 18 sprites on a line - I can't do this on the 8 bit - so does this mean the VCS sprite hardware is superior to the 8 bit sprite hardware

Ahm, that's not correct. If you put up 7 sprites on A8 normally and replicate the 8th missile/player many times with no background graphics, you get 18 more sprites for a total of 25 sprites/scanline on A8. That does not make the entire sprite hardware inferior or superior but that's one aspect to look at incase you have some application that requires more horizontal sprites.

[atariksi]

The C64 has not been designed to be technology advanced , it has been designed to cost the less as possible.

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is.

 

...

 

It's competitive but that doesn't mean it wins in all cases. There are many events in the olympics so just because you have a faster backstroke/freestyle swimmer doesn't mean you'll win all swimming events. Get the picture? Your logic is that when Atari shows it's better at sprite useage in vertical direction or in overscanned cases or other cases, you're going to show wider sprites at more resolution although the event calls for something else. So when we talk about collision detection of 60 bits vs. 8 bits + 8 bits of vagueness, you're still going to use your freestyle swimmer.

 

P.S.: for those that don't know there's a C64 register for sprite detection called the "Vague sprite collision register": whenever a sprite collides with another sprite, it sets the bit for both sprites that collided. So if sprites #0 and #1 collide and sprites #4 and #5 collide, you end up with 4 bits being set. And now if sprites #0 and sprites #4 collide and sprite #1 and sprite #5 collide, it sets the same 4 bits and so on. So to calculate what collisions actually took place, you can do the following algorithm:

 

eenie, meenie, minie moe

catch the sprite that is colliding so

if it's not colliding, you won't know

but who cares if you let one go

...

 

mmm... this require the knowledge of Fröhn or TMR. I sure there is a satisfactory answer.

 

Other way, on Atari we can distinct the collision with background graphics, doing distinction over each pixel color. I guess on C64 is not posible.

 

It has to be done in software. From hardware support perspective A8 has more colisiion detection support than C64. Are you trying to insult me by saying that "eenie, meenie, minie moe" is unsatisfactory. How dare you!

[emkay]

It has to be done in software. From hardware support perspective A8 has more colisiion detection support than C64. Are you trying to insult me by saying that "eenie, meenie, minie moe" is unsatisfactory. How dare you!

 

 

It's as easy as it can be.

 

Look what is done on the C64 and you see all the C64 can do

 

Look what is done on the Atari 8-bits, and you see approx. 60% of what is possible (including the Space Harrier demos)...

Edited April 10, 2009 by emkay

[atariksi]

Advanced chips? Haven't I already pointed out that there still is a huge difference?

The differences are huge in both directions, but look around at the graphics chips available at that time. VIC2 beats the vid chips Motorola and TI were producing and it beats the Antic/GTIA combo in many areas. A chip doesn't have to outperform in every possible way to be advanced.

 

If the SID really was an advanced chip, it would had have the possibility of using free waveforms. And, if VICII was something like an advanced chip, it would had have 256 colours at least.

??? I guess now I know the technical definition of advanced.

 

You haven't given any evidence of what makes the VIC2 advanced over ANTIC/GTIA either. Just some vague blurb "many areas" although ANTIC/GTIA have more modes, more colors, more control of timing, "free" sprite replication, more priority settings, more collision detection, etc. Just having 1/320 positioning does not throw out everything else. PC's CGA had higher resolution (1/640) than C64's VIC2 and also had 80*25*16 colored text mode which also allowed you to reduce char height and make a graphics modes out of it. I don't consider that superior to Atari's chips nor C64's.

[atariksi]

Has any 64 fan ever stuck up for the Atari in a 64 forum?

Yes I even coded a bunch of crap for Atari. But sadly all C64 gfx people I asked (3 so far) rejected Atari for pretty similar reasons: Their or the the works of people they respects had been stolen by Atari people with their tag removed with "OMG loooks Atari is better than C64" underline.

Ah, too bad. The way I see it there are two reasons to be into retro computers:

 

1. You're genuinely interested in the technology of yesteryear.

 

2. You're perpetually childish and stuck in the past.

 

I think most of us fit into both categories to some degree, but I'd imagine you run into full-on type 2's in every computer scene.

 

I don't fit into either of the two.

[atariksi]

Going back to an earlier point, I don't think the 64 vs. 800 makes much sense because the machines are years apart. I also don't think Atari can win the 64 vs 800XL debate because of Atari's aging hardware.

 

I think the most interesting debate is which one represented the biggest advance in technology...

 

...

 

You are following some blind speculation that anything produced a few months or years down the road MUST have better technology. You fail to see other factors involved-- marketing, investment to redesign, engineers involved, etc. For example, to speed up modern processors they had to sacrifice the ability to time things using cycle counts from processors; to reduce size of motherboards (or for other reasons), they had to remove parallel ports which have no equivalent in modern machines. You can have machines built later that are inferior overall. C64 was designed to be a cheaper machine for marketing purposes or for whatever purpose. I have an HP Pavilion 1.4Ghz that plays back MPEG videos SLOWER than a Toshiba 300Mhz. I have a Thinkpad 760 133Mhz w/built in genlocking capability which does not exist on most other PCs.

[Bryan]

 

1. You're genuinely interested in the technology of yesteryear.

 

2. You're perpetually childish and stuck in the past.

 

I don't fit into either of the two.

 

Ah, so your reason for being here must be a fascination with endless tedious debate! It all makes sense now.

[Bryan]

You are following some blind speculation that anything produced a few months or years down the road MUST have better technology.

 

Oh, there's blindness in this thread alright...

[youki]

You are following some blind speculation that anything produced a few months or years down the road MUST have better technology.

 

You are following some blind speculation that anything produced by Atari down the road MUST have better technology.

[Heaven/TQA]

The C64 has not been designed to be technology advanced , it has been designed to cost the less as possible.

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is.

 

...

 

It's competitive but that doesn't mean it wins in all cases. There are many events in the olympics so just because you have a faster backstroke/freestyle swimmer doesn't mean you'll win all swimming events. Get the picture? Your logic is that when Atari shows it's better at sprite useage in vertical direction or in overscanned cases or other cases, you're going to show wider sprites at more resolution although the event calls for something else. So when we talk about collision detection of 60 bits vs. 8 bits + 8 bits of vagueness, you're still going to use your freestyle swimmer.

 

P.S.: for those that don't know there's a C64 register for sprite detection called the "Vague sprite collision register": whenever a sprite collides with another sprite, it sets the bit for both sprites that collided. So if sprites #0 and #1 collide and sprites #4 and #5 collide, you end up with 4 bits being set. And now if sprites #0 and sprites #4 collide and sprite #1 and sprite #5 collide, it sets the same 4 bits and so on. So to calculate what collisions actually took place, you can do the following algorithm:

 

eenie, meenie, minie moe

catch the sprite that is colliding so

if it's not colliding, you won't know

but who cares if you let one go

...

 

ok...must be alcohol... or other drugs...

[emkay]

You are following some blind speculation that anything produced a few months or years down the road MUST have better technology.

 

You are following some blind speculation that anything produced by Atari down the road MUST have better technology.

 

All in all it is.

 

It's only the fact that C64's features were optimized to the genres that people wanted back in that time, makes it look superior.

But, as a computer itself, it is inferior to the A8. Even if the C64 is produced almost 4 years later.

[atarian63]

The C64 has not been designed to be technology advanced , it has been designed to cost the less as possible.

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is.

 

Commodore used some component they had

Yes, and they had VIC2 and SID.

 

Damn I am f**king annoyed of this crap. All this "ooooooh A8 could have been much better if only the evil companies/coders/whatever had done that". NO! The C64 can do 2D games much much easier than the A8. On C64 a Crownland engine is just a matter of coding a week. And even after that its far from "cutting edge" on C64, it's just a straight forward job.

Please.. the Vic was an utter failure in the US. The main market at the time.

[atarian63]

Atariski...you should really come down to earth... you seem to have fun in terms of try to discuss in a "correct" manner like we learned in school and in philosophic course at university... but is it pratical?

 

yes...of course you can call 240x8 = 1920 sprites but in reality? can you move them around? can you at least do something practical with them in games?

 

you would need to feed in a kernal 8 hpos registers plus 4 graphpx registers plus 1 graphm register not to mention the colour registers...

 

aehm... should we now state that 800 has 1920 hardware sprites? in 256 colours? come on...

 

same goes to some of your aspects refering to a single bit of hardware... sometimes I feel you are too academic with the loose for reality...

 

I did give example of practical use that I did-- enhance an image by overlaying top of Graphics 9 mode (that's antic mode K)-- in that case there were 4 8*1 per line and 4 2*1 per line and few more wherever I could squeeze them in (total > 2000).

 

You don't need to set GRAFn more than once per line. You have the GRAFn set via DMA automatically for the 4 players and missiles and you have enough time to setup another GRAFn and set another HPOS >100 times per frame even after updating all 8 HPOSes for players and missiles.

 

I don't know what you are talking about regarding the "single bit of hardware".

 

And if by "correct" manner you are complaining about my dealing with Frohn-- he was being duplicitous-- first he states C64 can also do what Atari can regarding 2000+ sprites and then when proven wrong he has this backup plan-- it's useless or it's impossible to do on Atari as well. Nice deceptive way to argue huh--

plan A: whatever Atari can do just say C64 can do until someone proves you wrong;

plan B: if they do prove it wrong, just say it's useless until someone thinks of good use for it;

plan C: if they do find a good use for it, just say that Atari can't do it either until someone actually goes and does it or prove it can be done.

plan D: if they prove it can be done, pretend you missed that posting because you left town, went on vacation, etc. and repeat the same point again (The TMR may have been the original found of this plan).

That does apear to be his plan from what I have seen in this thread.

 

Amazingly enough he used plan D to dismiss this post and used plan A,B, & C again since this post.

yes it goes on and on... Maybe the Lemon 64 site would find him more interesting. Yawn.

[emkay]

yes it goes on and on... Maybe the Lemon 64 site would find him more interesting. Yawn.

 

Finally, real working programs on the A8, that really shows - what's possible - will close many C64 user's mouths. But, until that, they will keep pressurin the A8 down by all approached software, this big C64 community, has got.