Atari v Commodore

[atariksi]

>Actually, i never offered an opinion regarding which was more flexible or anything, the point is that a four colour image on the Amiga is seen by the hardware as two independent bitplanes in the same way that what you're trying to call a single three colour sprite is still two sprites according to the hardware. And if the Atari can use two sprites to generate a three colour object it's an unfair comparison to for some reason disallow the C64 from doing exactly the same.

...

You can use the same technique on C64 if you want. I was comparing two multicolor sprites on both systems.

 

>But we weren't talking about a multiplexer and the comparison was two three colour objects being moved on both machines, keeping it simple. On the C64 side of things i didn't allow any CPU overhead for an interrupt-based framework and my Atari code was working under the same circumstances; you claimed your example to be ten times faster than my Atari method but, with all the bounds checking and the interrupt framework ticking over every frame, i can see that claim being well off the mark you're claiming even before the exception cases where block shifting kicks in.

 

Interrupts speed things up over standard methods. You can disable/enable DMA on lines where you want to render sprite so it gives you gain of 5 cycles/scanline or 4 cycles/scanline (for just players in our case). It'll be more than 10X faster when compared to standard methods of memory copy.

 

>>Sorry, but "static" does not mean "dynamic" in my dictionary. Read you original post and tell me you did not state STATIC:

 

>...so for a start, i'm not saying the objects are static, merely the screen - there's another battle of semantics right there since i and others use the word "screen" in those contexts to mean the same as "background". You might doubt the sincerity of that statement, but it was backed up with...

 

I prefer keeping things explicit and not reading imaginary things to avoid misinterpretation. Screens whether static or dynamic have no impact on the overlayed sprites. Perhaps, you want to post your algorithm more precisely to which to compare.

[TMR]

No, Gameport is for games-- you know Mov DX,201h; IN AL,DX that interface is standard on all PCs with gameport. Atari standard is LDA 54016. C64 is LDA $DC01. Amiga is Move.b $DFF0nn,D0 followed by some XOR algorithm. Not comparing CPU speed but more instructions/processing on PC than all other platforms. It takes about 1 ms to read joystick on PC and stick is analog (less control than other three systems).

 

But that means that your statement "Atari>Amiga>C64>PC" isn't right because the C64 and Atari are taking the same number of commands whilst the Amiga needs the XOR work too. More accurate would be Atari=C64>Amiga>PC.

 

You can take over amiga with simple Move.w $7FFF,$DFF09E, Move.w $7FFF,$DFF09a.

Similar on Atari/C64. But on PC, you can't tell physical addresses from linear or virtual; you can't do I/O w/o OS intervention, etc.

 

So again, is saying that "Amiga>Atari>C64>PC" an accurate representation if all three of the other machines can kick their operating systems out with a couple of commands and what makes the Amiga the top of the totem in this particular situation? i don't know the Amiga or PC well personally, but from what you've said Amiga=Atari=C64>PC would describe things better.

[Oswald]

Sorry my PC does not have any sprites nor can Amiga sprites do 24 pixel width.

 

HW sprites are simply outdated on the PC, there's no need for them and that doesnt means its not as good. it can do better with the CPU/GPU, just like the amiga can do better sprites with the blitter/cpu.

 

No, Gameport is for games-- you know Mov DX,201h; IN AL,DX that interface is standard on all PCs with gameport. Atari standard is LDA 54016. C64 is LDA $DC01. Amiga is Move.b $DFF0nn,D0 followed by some XOR algorithm. Not comparing CPU speed but more instructions/processing on PC than all other platforms. It takes about 1 ms to read joystick on PC and stick is analog (less control than other three systems).

 

who gives a shit if its 20 or 30 zillionth of a second is to check joy state? doesnt affects performance at all. wow atari is the best in that! it doesnt even needs some xor algorithm like the amiga!

 

 

>nothing differentiates here amiga/c64/atari, all of them allow direct chip access.

 

You can take over amiga with simple Move.w $7FFF,$DFF09E, Move.w $7FFF,$DFF09a.

Similar on Atari/C64. But on PC, you can't tell physical addresses from linear or virtual; you can't do I/O w/o OS intervention, etc. H/W is nonstandard so even if you do IN AL,61h to read PC keyboard, it won't run on system w/USB keyboard. VGA card is nonstandard nowadays as well so you can't tell where it's physically mapped unlike older cards where it's always at $A000:0000. You can't call API calls in real-time programming unless you know worst case timing of the API call.

 

who give a shit again how does it happen. the pc owns all the rest of the 3 anyway.

[Rybags]

You neglected to mention that on the C-64 the joysticks and keyboard interfere with each other.

 

The keyboard interference can be alleviated by ensuring the row select is all zeros. But you'd also need to disable the system timer IRQ to ensure it doesn't undo your work.

[Oswald]

You neglected to mention that on the C-64 the joysticks and keyboard interfere with each other.

 

The keyboard interference can be alleviated by ensuring the row select is all zeros. But you'd also need to disable the system timer IRQ to ensure it doesn't undo your work.

 

not a typical scenario, one is playing a game but the keyboard interference has to be take care of because he might have wanting typign something while playing

[Gury]

that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage.

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this.

[Rybags]

The keyboard interference thing was a laugh that soon turned into major annoyance when any smartarse mate would just grab the joystick and start stuffing up your typing.

 

Really, you'd think they could have just chucked a $3.50 6520 PIA into the machine and kept the input devices seperate.

[Alison DeMeyer]

I read in Retro Gamer that the PC owes the Atari 8-bit computer a great deal, USB ports etc..... (RG issue 47).

Edited December 4, 2008 by Alison DeMeyer

[Rybags]

No. No. No.

 

Leave the "Atari invented USB" conspiracy bollocks to Carmel.

[Oswald]

that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage.

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this.

 

indeed, it does have more important things than 128/256 colors.

[Oswald]

I read in Retro Gamer that the PC owes the Atari 8-bit computer a great deal, USB ports etc..... (RG issue 47).

 

buhahaha c= pet had a serial bus before a8, and there was an industry standard for that before the c= pet.

[Rybags]

If anything, Atari could probably lay more claim to Plug & Play than it could ever hope to for USB (SIO devices downloading drivers, XL/XE PBI protocols etc).

[Gury]

that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage.

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this.

 

indeed, it does have more important things than 128/256 colors.

I doubt that.

Also, A8 has even more important things than that.

[Oswald]

The keyboard interference thing was a laugh that soon turned into major annoyance when any smartarse mate would just grab the joystick and start stuffing up your typing.

 

Really, you'd think they could have just chucked a $3.50 6520 PIA into the machine and kept the input devices seperate.

 

another entry on the unimportant feature list the a8 has and the c64 doesnt. keep it growing

[atariksi]

No, Gameport is for games-- you know Mov DX,201h; IN AL,DX that interface is standard on all PCs with gameport. Atari standard is LDA 54016. C64 is LDA $DC01. Amiga is Move.b $DFF0nn,D0 followed by some XOR algorithm. Not comparing CPU speed but more instructions/processing on PC than all other platforms. It takes about 1 ms to read joystick on PC and stick is analog (less control than other three systems).

 

But that means that your statement "Atari>Amiga>C64>PC" isn't right because the C64 and Atari are taking the same number of commands whilst the Amiga needs the XOR work too. More accurate would be Atari=C64>Amiga>PC.

 

You can take over amiga with simple Move.w $7FFF,$DFF09E, Move.w $7FFF,$DFF09a.

Similar on Atari/C64. But on PC, you can't tell physical addresses from linear or virtual; you can't do I/O w/o OS intervention, etc.

 

So again, is saying that "Amiga>Atari>C64>PC" an accurate representation if all three of the other machines can kick their operating systems out with a couple of commands and what makes the Amiga the top of the totem in this particular situation? i don't know the Amiga or PC well personally, but from what you've said Amiga=Atari=C64>PC would describe things better.

 

Because primarily Atari is reading both joysticks with one LDA and flip to output as well in 8-bit mode. Amiga w/XOR is faster than C64. I am not comparing CPU speed but joystick I/O speed. But Amiga/Atari/C64 are all close whereas PC is really slow, but for large amounts of data I/O, the small edge becomes bigger.

 

Amiga has more hardware support for real-time events (after you suspend OS and set up your vectors)-- Copper Lists can modify things in I/O area at specific 3.58Mhz clock count accuracy consistently. Atari has WSYNC + counting cycles of instructions so you know how long each procedure will take. I suppose C64 can keep it's cycles accurate to it's clock frequency. PC has no way to tell how long a procedure will take (assuming you can find a way to disable all other tasks/interrupts). Even if you time the procedure, it may take a different number of cycles the next time you call it especially with power management, caching, and dynamic frequency processors.

[TMR]

>Actually, i never offered an opinion regarding which was more flexible or anything, the point is that a four colour image on the Amiga is seen by the hardware as two independent bitplanes in the same way that what you're trying to call a single three colour sprite is still two sprites according to the hardware. And if the Atari can use two sprites to generate a three colour object it's an unfair comparison to for some reason disallow the C64 from doing exactly the same.

...

You can use the same technique on C64 if you want. I was comparing two multicolor sprites on both systems.

 

In which case that's a "win" to the C64; over two multicolour objects, three independent colours per object and no OR'd third colour. At least i'm not using the argument that because the Atari hardware is using half it's sprites per object the C64 should do the same... =-)

 

Interrupts speed things up over standard methods. You can disable/enable DMA on lines where you want to render sprite so it gives you gain of 5 cycles/scanline or 4 cycles/scanline (for just players in our case). It'll be more than 10X faster when compared to standard methods of memory copy.

 

i'd argue the toss over that because the interrupts may make juggling the sprites easier but they take CPU power in the process; looking at my own DLI code there's stashing and unstashing of registers to do at each end (pha / txa / pha / tya / pha, that bit alone is thirteen cycles per iteration and it's reversing that as well) and then the actual handling code between them and that adds up if you're kicking in an interrupt several times a frame. And you still have your worst cases when two objects need to pass and either it starts dropping objects, interleaving them or pulling up a block copy that probably won't be faster than the one i was proposing on top of that load.

 

I prefer keeping things explicit and not reading imaginary things to avoid misinterpretation. Screens whether static or dynamic have no impact on the overlayed sprites.

 

That's why i said a static screen, i was saying "ignore the screen". Perhaps i should have said that it was turned off...

 

Perhaps, you want to post your algorithm more precisely to which to compare.

 

For speed it's an unrolled loop so it's pretty large for a sixteen pixel high object - basically it's lda definitions,x / sta player_data,y followed by thirty more lda/sta cycles for the draw, Y used for current height, X used for the animation frame to draw in. It can run faster by writing "dead" areas in above and below the draw itself and "dragging" those over the previous frame to delete it, but that requires other routines to manage it otherwise there are "dead" images left behind if an object is required to change height rapidly when recycled for a new job.

[Alison DeMeyer]

I read in Retro Gamer that the PC owes the Atari 8-bit computer a great deal, USB ports etc..... (RG issue 47).

 

buhahaha c= pet had a serial bus before a8, and there was an industry standard for that before the c= pet.

 

Yes, but the Atari serial is the grandfather of USB, not the PET. Who cares about the PET serial, not one person.

And the MSDOS floppies is based on Atari DOS, read Retro Gamer, schoolboy.

[atariksi]

...

who gives a shit if its 20 or 30 zillionth of a second is to check joy state? doesnt affects performance at all. wow atari is the best in that! it doesnt even needs some xor algorithm like the amiga!

...

 

Subjective. You don't care does not mean no one cares. It all adds up when data starts piling in or going out.

 

>who give a shit again how does it happen. the pc owns all the rest of the 3 anyway.

 

Subjective.

[Oswald]

that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage.

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this.

 

indeed, it does have more important things than 128/256 colors.

I doubt that.

Also, A8 has even more important things than that.

 

you doubt that? hell, c64 should have been 4096 colors with a screen able to display only one pixel. that would fulfill your list of important things alone

 

you should see that 16 colors is (amongst others) the key to the high color density on the c64. it allows 2 independent colors in one byte. also it spares silicon space for sprites for example. 128 colors does little when you can only display them in very special circumstances (rainbow&static screen) and have to do softsprites, etc.

[Fröhn]

Yes, but the Atari serial is the grandfather of USB, not the PET. Who cares about the PET serial, not one person.

And the MSDOS floppies is based on Atari DOS, read Retro Gamer, schoolboy.

So what makes the Atari SIO more "grandfather of USB" than earlier serial daisy chain busses?

[atariksi]

>>You can use the same technique on C64 if you want. I was comparing two multicolor sprites on both systems.

 

>In which case that's a "win" to the C64; over two multicolour objects, three independent colours per object and no OR'd third colour. At least i'm not using the argument that because the Atari hardware is using half it's sprites per object the C64 should do the same... =-)

 

Because you missed the point entirely, I stated you can do it too. All it proves is that you prefer using Atari's method of multicolor sprites.

 

>i'd argue the toss over that because the interrupts may make juggling the sprites easier but they take CPU power in the process; ...

 

Sorry it's much faster than your standard copy method. It's 4*200+ cycles you gain. Your analysis is speculative that interrupt processing is worse.

 

>For speed it's an unrolled loop so it's pretty large for a sixteen pixel high object - basically it's lda definitions,x / sta player_data,y followed by thirty more lda/sta cycles for the draw, Y used for current height, X used for the animation frame to draw in. It can run faster by writing "dead" areas in above and below the draw itself and "dragging" those over the previous frame to delete it, but that requires other routines to manage it otherwise there are "dead" images left behind if an object is required to change height rapidly when recycled for a new job.

 

"Can run faster" does not count as an algorithm. You need to state exactly.

[atariksi]

You neglected to mention that on the C-64 the joysticks and keyboard interfere with each other.

 

The keyboard interference can be alleviated by ensuring the row select is all zeros. But you'd also need to disable the system timer IRQ to ensure it doesn't undo your work.

 

Yeah, I should have stated KB+Joystick I/O. But I am sticking to just joystick I/O.

[Oswald]

Because primarily Atari is reading both joysticks with one LDA and flip to output as well in 8-bit mode. Amiga w/XOR is faster than C64. I am not comparing CPU speed but joystick I/O speed. But Amiga/Atari/C64 are all close whereas PC is really slow, but for large amounts of data I/O, the small edge becomes bigger.

 

funny how amiga needs xor to check the bits, while the atari can do it with one lda. ammazing!

 

timing blabbla: just as the sprites the pc does not need that. it can do better without it. and yes, its a scientific wonder, but the c64's cpu is in synch with its gfx chip. halleluja!

[Oswald]

I read in Retro Gamer that the PC owes the Atari 8-bit computer a great deal, USB ports etc..... (RG issue 47).

 

buhahaha c= pet had a serial bus before a8, and there was an industry standard for that before the c= pet.

 

Yes, but the Atari serial is the grandfather of USB, not the PET. Who cares about the PET serial, not one person.

And the MSDOS floppies is based on Atari DOS, read Retro Gamer, schoolboy.

 

 

grandfather my ass. its just the same design philosophy. msdos floppies claim is probably similer: they are also circle shaped and spinning, right? :D

[atariksi]

Because primarily Atari is reading both joysticks with one LDA and flip to output as well in 8-bit mode. Amiga w/XOR is faster than C64. I am not comparing CPU speed but joystick I/O speed. But Amiga/Atari/C64 are all close whereas PC is really slow, but for large amounts of data I/O, the small edge becomes bigger.

 

funny how amiga needs xor to check the bits, while the atari can do it with one lda. ammazing!

 

timing blabbla: just as the sprites the pc does not need that. it can do better without it. and yes, its a scientific wonder, but the c64's cpu is in synch with its gfx chip. halleluja!

 

Go check out the Amiga Hardware Reference manual if you have a problem. Hope you know that 68000 MOVEs generally take more cycles than LDA. And if you can't make a rational argument, don't reply-- let someone who knows about the subject reply. PC cannot do better w/o sprites.