Atari v Commodore

[Heaven/TQA]

Oswald... Space Harrier does not use charmode on A8... load the demo, press F8 and type DLIST...

[Oswald]

Oswald... Space Harrier does not use charmode on A8... load the demo, press F8 and type DLIST...

 

no idea what f8 and dlist does but learning this, WOW the c64 could never handle this at these speeds. this must be given to the lowres mode of the antic&faster cpu speed. hmm and more mem still it looks to be too fast to be bitmap for me

[atariksi]

I dont know how anyone can argue that the Atari sprites are better than the C64 sprites - it's just not true..

 

( Setting double width on C64 - so that the res is the same )

 

C64 - 8 sprites, each 24 pixels wide

A8 - 4 sprites, each 8+2 pixels wide or 5 sprites, each 8 pixels wide

 

....there's no comparision - the C64 wins the sprite award with ease

 

I just looked around and the universe still has IN FACT more than one dimension! I sense your bias (and some others') toward your C64 at the cost of establishing the truth. There's also a Y-axis and Z-axis and time, originality, etc.. Ever heard of these elements of the universe? If I only looked at the height of sprites, perhaps I will conclude the opposite. If I had to move sprites in the Z-direction, well then having 2X,4X zoom is better than just 2X so Atari wins there as well. If I had to look at the time factor, 1.7897 timer vs. 1Mhz timer on C64. Well, Atari would win there as well. If I had to look at originality, well Atari came out with sprites first.

I can show you sprite examples (if you did not read about them already in this thread or others) that will not work on C64. So don't say stuff like in your post #347:

"C64: 64K memory, way better sprites, 16 colours/line, 320pixel scrolling and colour"

 

It's not WAY better. I rather have vertically high sprites for some applications. 16 colors/line is also available on Atari and even more colors as well. You can also multiplex sprites horizontally if the shapes are taken from same PMBase. 64K memory is not a big deal vs. 62K on 800XL.

[atariksi]

...

I told you above, that ANTIC is not a GPU, so what's the point of requiring "rendering bobs" from it afterwards? (I am pretty sure that you will skip this question in your answer).

 

And sure, ANTIC incorporates "most of" the functions of a central processing unit on a single integrated circuit: it is a single integrated circuit, it has a program counter, it has separate instruction list, and it processes data. Of course, it is a specialized microprocessor (but in no way a video microprocessor: it is a video microprocessor only in the sense that the circuit it is controlling is a video interface controller), but it is still a microprocessor.

 

While the VIC-II is only an I/O chip. ChipSelect line etc. Like 6520. And so you in no way can claim the C-64 to be superior in design here For that, however, better go to a ZX Spectrum forum - you can legitimately claim that a C-64 displays more colours, and, of course, that the ZX Spectrum's ULA doesn't generate violet; and, IIRC, it doesn't generate brown either.

 

Yeah, I would agree ANTIC is a processor being used as a co-processor. So if I set up ANTIC with some complex display list which jumps all over memory, four player sprites with overlap on themselves and some overlap over ANTIC mode 2, disable all IRQs and NMIs, and HALT the 6502 and remove it while the Atari was on, will the ANTIC continue to display the same picture on the video output? I mean will the ORing of the colors still occur on the overlap of sprites, the black fill will still occur on the priority conflict areas, and screen remain still stable? Or do I need to set some other pin on GTIA or something?

[atariksi]

I meant the algorithm can be complex-- the hardware aspects are simpler if they are separated. You have been using "keep it simple" in a disparaging way as if someone is restricting you. We were talking multicolored sprites (including you)-- in Atari a multicolor sprite is by definition two single color sprites. The Atari has a better implementation of the multicolor sprite.

 

Yes, i do feel it's being used as a one-sided restriction which is why i've been sarcastic when using the term. If you use two sprites to render one object on the Atari it simply isn't a fair comparison to insist that the C64 has to "keep it simple" and isn't allowed to use the exact same technique; the better implementation of multicolour sprites is the hardware that can do it either way depending on what the programmer wants.

...

If you want to call the C64 multicolor sprites "monochrome" then you can also use the Atari hardware method of enabling multicolor mode by setting bit 5 of 53275. However, it won't give you the "OR" color mode. You will end up having 4 colors and use up two multicolor sprite channels whereas I get 3 colors + black using two monochrome sprite channels. Now you want to count DMA cycles as to which is better implementation.

 

>>It does-- it depends on usage. If you cross the two multicolor sprites in the same zone you have to resort back to memory move or adjust the PMBase tables for high probability. For a single 7+ color sprite or where sprites are in zones, it works great. Your better off arguing it's subjective like you did with the palette.

 

>i can't see how it's subjective as to which is a better design; one takes CPU power, RAM overheads and restricts motion of objects depending on the code-driven solution used or the other that merely involves setting Y registers. If we were really keeping it simple, the code would be kept out of it and players can't actually move vertically at all without the code...

 

I think you missed the point. All hardware aspects of both machines require CPU access to enable/disable/initialize things. The algorithm I presented of Y-axis simulation only uses a few instructions just like setting sprite/SID/etc. registers on your machine. There's 16K RAM useage for all the sprites and we're targetting 800XL/C64 so it's no problem. I gave you two algorithms-- one is not restricted and the other one is. The players can move vertically using almost same amount of code as you use to set up your sprites. I am not giving you a software sprite algorithm-- just a method of setting up PMBase register and HPOS registers-- I'll give you a shell code in my reply to Heaven. Your original argument was that Atari sprite motion is 11X slower. So I gave you a method which is more than 10X faster than your method.

 

I did keep it simple.

[Oswald]

If I had to move sprites in the Z-direction, well then having 2X,4X zoom is better than just 2X so Atari wins there as well. If I had to look at the time factor, 1.7897 timer vs. 1Mhz timer on C64. Well, Atari would win there as well. If I had to look at originality, well Atari came out with sprites first.

I can show you sprite examples (if you did not read about them already in this thread or others) that will not work on C64. So don't say stuff like in your post #347:

"C64: 64K memory, way better sprites, 16 colours/line, 320pixel scrolling and colour"

 

It's not WAY better. I rather have vertically high sprites for some applications. 16 colors/line is also available on Atari and even more colors as well. You can also multiplex sprites horizontally if the shapes are taken from same PMBase. 64K memory is not a big deal vs. 62K on 800XL.

 

- how is 4x zoom better, when the c64 can display sprites in a wider area than 4x atari sprites but twice the resolution ?

- sure in timer resolution a8 is better, but can you do anything faster/better with it?

- originality: nope atari was not first with sprites, bad luck.

- show me a sprite example which would not work on c64

- I rather have 8 4x wider sprites on a scanline without the need to use cpu power to move them vertically.

- 16 colors/line or more on atari is very limited, needs cpu usage. practically unusable for random game scenarios.

[atariksi]

>...numbers that are kept in some kind of computer memory. There are four steps that nearly all von Neumann CPUs use in their operation: fetch, decode, execute, and writeback." antic is missing the execute, and writeback features. antic is a statemachine with some cpu-esqueish features (jmp). the display list is used to change its inner state, which in turn affects the graphical output. however it cannot execute anything that gets near to a program, a program would need atleast the writeback feature, if then style instructions, etc.

 

>(from >http://en.wikipedia.org/wiki/Central_proce...#CPU_operation)

 

You are speculating about ANTIC. Someone should get that article removed from wikipedia. I just removed the RAM from my laptop and it boots up to "NO RAM..." So it cannot do any writeback so that means there's no processor in the machine? Or is it that Pentium is no longer a processor?

[Oswald]

>...numbers that are kept in some kind of computer memory. There are four steps that nearly all von Neumann CPUs use in their operation: fetch, decode, execute, and writeback." antic is missing the execute, and writeback features. antic is a statemachine with some cpu-esqueish features (jmp). the display list is used to change its inner state, which in turn affects the graphical output. however it cannot execute anything that gets near to a program, a program would need atleast the writeback feature, if then style instructions, etc.

 

>(from >http://en.wikipedia.org/wiki/Central_proce...#CPU_operation)

 

You are speculating about ANTIC. Someone should get that article removed from wikipedia. I just removed the RAM from my laptop and it boots up to "NO RAM..." So it cannot do any writeback so that means there's no processor in the machine? Or is it that Pentium is no longer a processor?

 

I am not speculating, all my arguments are based on facts and definitions. by removing ram from your laptop you are not removing the built in ability of the cpu of being able to write back data.

[atariksi]

>- how is 4x zoom better, when the c64 can display sprites in a wider area than 4x atari sprites but twice the resolution ?

 

You can't read-- for Z-axis only.

 

>- sure in timer resolution a8 is better, but can you do anything faster/better with it?

 

Better timers don't increase speed but accuracy.

 

>- originality: nope atari was not first with sprites, bad luck.

 

http://www.old-computers.com/MUSEUM/computer.asp?c=460

 

>- show me a sprite example which would not work on c64

 

Full screen overscan moving curtains that I told you about last year. Remember? Or you want to see someone else's work?

 

>- I rather have 8 4x wider sprites on a scanline without the need to use cpu power to move them vertically.

 

Subjective.

 

>- 16 colors/line or more on atari is very limited, needs cpu usage. practically unusable for random game scenarios.

 

GTIA -- less CPU useage than your FLI (forced lengthening of Internal character cells).

[Oswald]

The players can move vertically using almost same amount of code as you use to set up your sprites.

 

only when you are wasting ram. te c64 doesnt have to to do this.

[Crazyace]

I dont know how anyone can argue that the Atari sprites are better than the C64 sprites - it's just not true..

 

( Setting double width on C64 - so that the res is the same )

 

C64 - 8 sprites, each 24 pixels wide

A8 - 4 sprites, each 8+2 pixels wide or 5 sprites, each 8 pixels wide

 

....there's no comparision - the C64 wins the sprite award with ease

 

I just looked around and the universe still has IN FACT more than one dimension! I sense your bias (and some others') toward your C64 at the cost of establishing the truth. There's also a Y-axis and Z-axis and time, originality, etc.. Ever heard of these elements of the universe? If I only looked at the height of sprites, perhaps I will conclude the opposite. If I had to move sprites in the Z-direction, well then having 2X,4X zoom is better than just 2X so Atari wins there as well. If I had to look at the time factor, 1.7897 timer vs. 1Mhz timer on C64. Well, Atari would win there as well. If I had to look at originality, well Atari came out with sprites first.

I can show you sprite examples (if you did not read about them already in this thread or others) that will not work on C64. So don't say stuff like in your post #347:

"C64: 64K memory, way better sprites, 16 colours/line, 320pixel scrolling and colour"

 

It's not WAY better. I rather have vertically high sprites for some applications. 16 colors/line is also available on Atari and even more colors as well. You can also multiplex sprites horizontally if the shapes are taken from same PMBase. 64K memory is not a big deal vs. 62K on 800XL.

 

Brilliant

 

The 64k memory comment for the C64 was more about every single machine having 64k ram - my 400 only had 16k , and my first 800 came with 16k that I upgraded to 48k. There were a lot of A8 games that had to use less memory to maximise the audience. Even with the XL there were the 600XL and 800XL - only the XE's gave 62K min.

 

I've been programming the 8 bits for a long time - and I like the PM graphics, but as a programmer there's no way I'd prefer them over the C64 sprites - even given the stupid limitations . ( The Z direction is the most stupid thing ever - it's like saying the 2600 players are better than the A8 or C64 because you can set 3 copies )

 

The Atari advantages come with the faster processor and the bitmap modes - look at Wayout on C64 and A8, the Atari version looks a lot smoother.

 

 

If anything, I'm biased towards the A8... but although I'm biased I cant really accept complete fiction

[Oswald]

>- how is 4x zoom better, when the c64 can display sprites in a wider area than 4x atari sprites but twice the resolution ?

>You can't read-- for Z-axis only.

 

whatever boasty description you give to it, there's no use of 4x wider sprites when the c64 can display wider than your 4x sprites in higher reso.

 

 

>- sure in timer resolution a8 is better, but can you do anything faster/better with it?

>Better timers don't increase speed but accuracy.

 

can you do anything better with it, other than measuring the time of some event outside of the computer more accurately ? not really useful for anything.

 

>- originality: nope atari was not first with sprites, bad luck.

>http://www.old-computers.com/MUSEUM/computer.asp?c=460

 

In the mid-1970s, Signetics devised the first video/graphics processors capable of generating sprite graphics. The Signetics 2636 video processors were first used in the 1976 Radofin 1292 Advanced Programmable Video System.

http://en.wikipedia.org/wiki/Sprite_(computer_graphics)

 

>- show me a sprite example which would not work on c64

>Full screen overscan moving curtains that I told you about last year. Remember? Or you want to see someone else's work?

 

dont remember. the c64 can cover the whole screen while doing a zoom fx:

at 4:13...

 

>- I rather have 8 4x wider sprites on a scanline without the need to use cpu power to move them vertically.

>Subjective.

 

11x less cpu power to manage wider & more sprites with more colors is objectively better.

 

>- 16 colors/line or more on atari is very limited, needs cpu usage. practically unusable for random game scenarios.

>GTIA -- less CPU useage than your FLI (forced lengthening of Internal character cells).

 

what are you talking about? GTIA with less or same cpu usage can not come up with better gfx than the VICII.

[Crazyace]

Full screen curtains wouldn't be impossible on the c64 - just more difficult. I'd only use sprites for the edges of the curtains, and change the colour/character cells - as that way I wouldn't have to use any interupts or multiplexing, and the curtain edges could be more detailed.

This is reaching - especially as there are effects ( The 256 colour per pixel 80x100 GTIA+ mode ) that are impossible to replicate on the C64. ( Funny - I think the +4 might be able to do it - but that has no sprites at all )

[Oswald]

http://absenceandwilds.extra.hu/?q=node/24

 

this is how gfx should look like using a computer with 128 colors

[atariksi]

>whatever boasty description you give to it, there's no use of 4x wider sprites when the c64 can display wider than your 4x sprites in higher reso.

 

One dimensional thinking is what I was refuting and he once again starts talking about his precious x-axis.

 

>can you do anything better with it, other than measuring the time of some event outside of the computer more accurately ? not really useful for anything.

 

Yeah, the IRQs are more accurate meaning I can have an interrupt occur at exact points on the screen. Yeah, I can use it for I/O transfers for joystick ports, use it for more accurate audio sampling rates when synchronizing with imagery, etc. etc.

 

>In the mid-1970s, Signetics devised the first video/graphics processors capable of generating sprite graphics. The Signetics 2636 video processors were first used in the 1976 Radofin 1292 Advanced Programmable Video System.

http://en.wikipedia.org/wiki/Sprite_(computer_graphics)

 

How does that show that my link was wrong?

 

>dont remember. the c64 can cover the whole screen while doing a zoom fx:

at 4:13...

 

Didn't see any sprites-- or were some of those things sprites?

 

>11x less cpu power to manage wider & more sprites with more colors is objectively better.

 

Stop with the biased 11X. 16K RAM is easily available on Atari since the games are mostly optimized for 16K anyways and the theme of thread was targetting 800XL. And you need space for sprites anyways and can re-use the 16K for more sprites with different shapes if they are in zones. I can update the Y-axis for my sprite applications in same time as your C64.

 

>what are you talking about? GTIA with less or same cpu usage can not come up with better gfx than the VICII.

 

That's subjective again. Most imagery of the world has shades and GTIA can display shades better than your VICII. And his point was 16 colors / scanline and GTIA does that.

[atariksi]

Full screen curtains wouldn't be impossible on the c64 - just more difficult. I'd only use sprites for the edges of the curtains, and change the colour/character cells - as that way I wouldn't have to use any interupts or multiplexing, and the curtain edges could be more detailed.

This is reaching - especially as there are effects ( The 256 colour per pixel 80x100 GTIA+ mode ) that are impossible to replicate on the C64. ( Funny - I think the +4 might be able to do it - but that has no sprites at all )

 

Well the demo was Curtains opening with a GTIA image in the background. It's basically impossible on the C64 even if I reduce the GTIA image to use less colors. And it's suppose to be a sprite useage so you can't use character cells anyway.

 

>I've been programming the 8 bits for a long time - and I like the PM graphics, but as a programmer there's no way I'd prefer them over the C64 sprites - even given the stupid limitations . ( The Z direction is the most stupid thing ever - it's like saying the 2600 players are better than the A8 or C64 because you can set 3 copies )

 

Just wanted to be complete since most C64 people here keep repeating sprites on a scanline (x-axis) and forget any other uses for sprites. Atari sprites were not just meant for small moving objects-- it states it directly in their old literature-- they intended to use them for boundaries and walls and so on. Perhaps, they wanted to port those Pong type games and use the walls for collision detection.

[atariksi]

I don't have any problem saying that for most games, the C64 has the clear advantage.

 

The Atari chipset was designed when there were NO chipsets out there that could do a full alpha screen plus sprites, not to mention 4-voice sound. Atari was the pioneer in this area and they clobbered the VIC-20 which was released at about the same time as the 400/800. When VIC II and SID were being developed, the Atari was the machine they needed to beat.

 

Atari's crime was letting their engineers leave and their hardware stagnate.

 

-Bry

 

More developers developed games for the C64 and targetted their wider sprites so they were harder to port to other platforms (even Amiga in some cases) without significant changes. Supposing they first targetted Atari 800s and used their sprites and took advantage of their vertical resolution, they would be harder to port to C64.

[atariksi]

http://absenceandwilds.extra.hu/?q=node/24

 

this is how gfx should look like using a computer with 128 colors

 

Dithered and no shades.

[emkay]

I don't have any problem saying that for most games, the C64 has the clear advantage.

 

For most written games in the past, yes. But, not with the given hardware-abilities...

[emkay]

http://absenceandwilds.extra.hu/?q=node/24

 

this is how gfx should look like using a computer with 128 colors

 

Dithered and no shades.

 

Come on. The Plus 4 really has it's advantages is colouring.

[TMR]

If you want to call the C64 multicolor sprites "monochrome" then you can also use the Atari hardware method of enabling multicolor mode by setting bit 5 of 53275. However, it won't give you the "OR" color mode.

 

Layering two sprites on the C64 will give me something better, two multicolour objects with three unique colours per object rather than the Atari's two and the third being calculated. Again, just because the Atari needs two sprites per multicolour object there is nothing to stop C64 programmers should they want to do the same - if you can do both solutions (and indeed a few other options as well since it leaves half the sprite hardware idle), you have the superior system.

 

i could be using terms like "the Atari needs half of it's sprites to generate one object" and if i use half the C64 sprites i can get four unique colours and twice the resolution, something the Atari simply cannot do at all from the sprite hardware.

 

Now you want to count DMA cycles as to which is better implementation.

 

Unless i forgot something important the C64 uses less DMA for eight sprites than the Atari needs for five. =-)

 

I think you missed the point. All hardware aspects of both machines require CPU access to enable/disable/initialize things. The algorithm I presented of Y-axis simulation only uses a few instructions just like setting sprite/SID/etc. registers on your machine.

 

Okay, so to set up a sprite on the C64 we're talking five LDAs and five STAs at absolute max for X, X MSB, Y, colour and data pointer (not including the setting of enable registers for sprites and multicolour mode which are two more LDA/STA pairs since they're a single write). To keep it simple, how long does your system take to set one object up if it doesn't know in advance what shape the object is?

 

I gave you two algorithms-- one is not restricted and the other one is. The players can move vertically using almost same amount of code as you use to set up your sprites. I am not giving you a software sprite algorithm-- just a method of setting up PMBase register and HPOS registers-- I'll give you a shell code in my reply to Heaven. Your original argument was that Atari sprite motion is 11X slower. So I gave you a method which is more than 10X faster than your method.

 

My method allows for animated objects, reading through yours again it relies rather heavily on everything holding still or a hideous amount of RAM use. For an example piece of code it perhaps has merit, but i'm intrigued as to how hogging most of the RAM for the sprite system will work within a full game.

[Crazyace]

http://absenceandwilds.extra.hu/?q=node/24

 

this is how gfx should look like using a computer with 128 colors

 

Some of those are quite nice - but some are a bit disappointing... but that's on a machine designed in 1984 - which would be a different Atari v Commodore comparision.

[Oswald]

>whatever boasty description you give to it, there's no use of 4x wider sprites when the c64 can display wider than your 4x sprites in higher reso.

>One dimensional thinking is what I was refuting and he once again starts talking about his precious x-axis.

 

4x zoom can only be done on the x axis what else should I be talking of ?

 

 

>can you do anything better with it, other than measuring the time of some event outside of the computer more accurately ? not really useful for anything.

 

>Yeah, the IRQs are more accurate meaning I can have an interrupt occur at exact points on the screen. Yeah, I can use it for I/O transfers for joystick >ports, use it for more accurate audio sampling rates when synchronizing with imagery, etc. etc.

 

irqs cant be more accurate than 1mhz on a c64 hence the cpu is 1mhz, so there's no use of a faster timer. c64 can also have interrupt occur at exact points of the screen. same goes for I/O, audio sampling, etc etc a faster timer than the system clock is no benefit regarding internal events.

 

>In the mid-1970s, Signetics devised the first video/graphics processors capable of generating sprite graphics. The Signetics 2636 video processors were first used in the 1976 Radofin 1292 Advanced Programmable Video System.

http://en.wikipedia.org/wiki/Sprite_(computer_graphics)

 

>How does that show that my link was wrong?

 

it does show that you was wrong. atari was not first with sprites.

 

>dont remember. the c64 can cover the whole screen while doing a zoom fx:

at 4:13...

 

>Didn't see any sprites-- or were some of those things sprites?

 

it was made of only sprites.

 

>11x less cpu power to manage wider & more sprites with more colors is objectively better.

 

>Stop with the biased 11X. 16K RAM is easily available on Atari since the games are mostly optimized for 16K anyways and the theme of thread was >targetting 800XL. And you need space for sprites anyways and can re-use the 16K for more sprites with different shapes if they are in zones. I can update >the Y-axis for my sprite applications in same time as your C64.

 

either 11x faster, or not wasting ram. pick one.

 

>what are you talking about? GTIA with less or same cpu usage can not come up with better gfx than the VICII.

 

>That's subjective again. Most imagery of the world has shades and GTIA can display shades better than your VICII. And his point was 16 colors / scanline >and GTIA does that.

 

not subjective. most imagery of the world has more than 4 or 5 "shades". VICII can display more than that without cpu intervention. and gtia doesnt do 16 colors/line without cpu intervention. VICII does. which one is better objectively?

[atariksi]

>...numbers that are kept in some kind of computer memory. There are four steps that nearly all von Neumann CPUs use in their operation: fetch, decode, execute, and writeback." antic is missing the execute, and writeback features. antic is a statemachine with some cpu-esqueish features (jmp). the display list is used to change its inner state, which in turn affects the graphical output. however it cannot execute anything that gets near to a program, a program would need atleast the writeback feature, if then style instructions, etc.

 

>(from >http://en.wikipedia.org/wiki/Central_proce...#CPU_operation)

 

You are speculating about ANTIC. Someone should get that article removed from wikipedia. I just removed the RAM from my laptop and it boots up to "NO RAM..." So it cannot do any writeback so that means there's no processor in the machine? Or is it that Pentium is no longer a processor?

 

I am not speculating, all my arguments are based on facts and definitions. by removing ram from your laptop you are not removing the built in ability of the cpu of being able to write back data.

 

It has AN0..AN2 lines for output. It does instruction fetch/input through DMA addresses set via the display list.

[TMR]

>dont remember. the c64 can cover the whole screen while doing a zoom fx:

at 4:13...

 

Didn't see any sprites-- or were some of those things sprites?

 

Wind forward to 4:14 and that picture that scales and flips, that's all hardware sprites and Z really doesn't seem to be an issue...