Atari v Commodore

[emkay]

Moving on from the initial primative layout example of Ping Pong, here it is now with more colour added with some shading to add a little depth... and the cost of this addition? nothing.. in fact 2 players have now been removed.

 

This colouring can go further still, it's just an initial quick example btw.

This is what I came up with from your source. IMHO the C64 version looks almost funny in comparison. Of course, these two pictures are 20 years apart but in any case, the C64 screen can't look much better than that.

Atari

 

C64

 

My version is just a mock-up of course, but it is designed with the respective restrictions in mind.

 

That's the way to go.... When chosing this way of getting depth into the scene, we wouldn't need to have hires PM for this. Making the ball a bit darker instead of size reducing was fairly enough...

Edited December 4, 2008 by emkay

[Oswald]

Sprites: C64>Amiga>Atari>PC

 

pc>amiga>c64>atari

 

Colors: PC>Amiga>Atari>C64

 

agree

 

Timer IRQs: Atari>Amiga>PC>C64 (I guess if you stick to 7.16Mhz Amigas, you can use CPU+Copper as better Timer IRQ)

 

pc>amiga>c64>atari

 

c64 has 4 16bit timer interrupts, the timers can count the other timers underflow, be one shot, or continous.

 

Cycle exact coding: Atari>C64>Amiga>PC (sorry but caching, branch prediction, non-standard freq. etc. makes for inexactness)

 

ok.

 

Gameport I/O: Atari>Amiga>C64>PC (if you use parallel port as joystick port then PC>Amiga>Atari>C64)

 

it makes no sense to compare a nonstandard solution of the a8 amongst systems. should be IO: pc>amiga>atari>c64. you are comparing here cpu speed. tho I'm not sure a parallel drive-c64 is not faster then atari, as you can beef up the c64's drive while on atari it says constant speed.

 

CPU Freq: PC>Amiga>Atari>C64

 

cpu speed again.

 

Real-time programming: Amiga>Atari>C64>PC (Modern PC OSes don't allow direct I/O control of all hardware and h/w is more & more nonstandard)

etc.

 

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

[Wrathchild]

so... who will do it?

Great screens Pseudografx!

I don't mind working on the disassembly and preparing of buildable sources on the A8 as the turnaround on that is quite quick, just the understanding of it that then follows takes the time

Regards,

Mark

[TMR]

TMR/Jason, looking forward to seeing what you have been working on.

 

At the moment, that makes two of us... i have no idea how it's actually going to look in a final form yet. =-)

[Heaven/TQA]

so... who will do it?

Great screens Pseudografx!

I don't mind working on the disassembly and preparing of buildable sources on the A8 as the turnaround on that is quite quick, just the understanding of it that then follows takes the time

Regards,

Mark

 

but please MADS format... not CA65.

[Wrathchild]

Drat - that counts me out then

[Gury]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

[emkay]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

While on the A8 you gain more and more colours by (quoting Oswald) "juggling around", the C64 can juggle as long as till it breaks: It never will show more than 16 "real" colours on the screen.

 

Seeing the 21 colours of the ping pong game at the 4 colour ( ) resolution, and every of them are a part of a screen enhancement, tells all

[Oswald]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

[Oswald]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

While on the A8 you gain more and more colours by (quoting Oswald) "juggling around", the C64 can juggle as long as till it breaks: It never will show more than 16 "real" colours on the screen.

 

Seeing the 21 colours of the ping pong game at the 4 colour ( ) resolution, and every of them are a part of a screen enhancement, tells all

 

more colors doesnt helps. see previous post .)

 

btw waiting for your pinball table mockup with 256 colors... you know, it only takes a decision of the coder as you said, lets decide so and show me

[Heaven/TQA]

@ Oswald, can you tell me what RAM the main program of Ping Pong occupies so I can make a memory snapshot and load the file into DIS6502?

[Oswald]

Therein lies the issue with your argument Oswald "what is not supportable is to try to turn down objective arguments based on how many ppl like a platform on a given forum. you don't have 24*8 hires pixel wide hw sprites. this is a fact regardless of what you like" Games are not just created because of what a platform will or will not allow TECHNICALLY, but by what experience the developer is seeking to create. The Spectrum has no hardware sprites (or scrolling) yet it manages to ATTEMPT versions of most games that appear on the C64 in the sprites and tiles days of the mid/late 80's. So lacking the C64's sprite hardware is not a problem, but a challenge...

 

hello? and what that has to do with what I have said ? some consistency please ? was I talking about games shouldnt be made without hw sprites or anything ?! I haven talked about this either but: what you call a problem or a challenge is subjective matter again. give me a break.

 

As someone who actually makes games, everyday since the late 80's, the technical issues are merely edges to be pushed against, that the power of a platform is only ever as realized as the latest game released for that system.

 

keep telling this to emkay please. its not me blabbling about virtual possibilities all the time.

[Oswald]

@ Oswald, can you tell me what RAM the main program of Ping Pong occupies so I can make a memory snapshot and load the file into DIS6502?

 

you should finish berzek, or beyond evil instead this ping pong game is really pointless, on the c64 it was unplayable. give it a go to see..

[Gury]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

Oswald, I don't know what is bothering you all the time. The fact is there are more color possibilities with A8 than C64. C64 colors don't even show all colors correctly, so many demonstration images are more like comics than true images.

[Oswald]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

Oswald, I don't know what is bothering you all the time. The fact is there are more color possibilities with A8 than C64. C64 colors don't even show all colors correctly, so many demonstration images are more like comics than true images.

 

but atari colors show all colors correctly ? give a check to g2f gallery, images are more like comics than true images, and sub quality to (non cpu aided) c64 ones.

Edited December 4, 2008 by Oswald

[Gury]

C64 don't even have normal red color.

[atariksi]

Although I gave the edge to C64 on sprite hardware, I was arguing against the statement that "it's WAY BETTER" (remember when I observed the universe has more than one dimension). If you look at it rationally and objectively rather than being biased toward the X-axis, the Atari sprite hardware is rendering about 10,000 sprite pixels every frame at 160*200 resolution which comes to about 600,000 pixels/second. C64 is doing 24*21*8 at 160*200 resolution which comes to less than half pixels/second. Now given Atari can use priority conflicts of sprites in various graphics modes even at 4X zoom, it can render about 2.4Million sprite pixels/second (more resultant rendered colored pixels/second than an ISA-based standard VGA card which came out 8 years later).

 

The PMBase does USE RAM, but it's very fast compare to block copying. There are 16-zones and conflict probability is actually 1/16 of Y positions but to keep my algorithm simple, I just merge 32 scanlines worth of sprites in a zone conflict.

 

if you would think rationally and objectively you would realise that for the average game scenario 8x24x21 multicolor/hires sprites with hires X coordinates are better than 4x8 pixel wide stripes without hires/multicolor abilty (yes you can combine them to have even less vertical stripes for multicolor..). and if I look at the whole thing horizontally which represents the true throughput the system (vertically you kindof just multiplex the system) the atari lags behind heavily.

 

And if you do the ORed mode horizontally at 4X sprite expansion, you'll see the ORing is at every pixel and so the throughput is similar horizontally as well. I was comparing both equally at 160*200 which is more used mode. I don't know where you get 4*8 from.

[Alison DeMeyer]

And Oswald never even coded an Atari 8-bit computer, probably never even touched one either. Those guys are the worst for just mouthing off. Schoolyard mentality 'my Speccy is better than your BBC'.

Edited December 4, 2008 by Alison DeMeyer

[Oswald]

C64 don't even have normal red color.

 

whats the definition of a normal red color ?

[pseudografx]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

I don't see a problem with this, as far as the scene looks overall better. Compared to it, the C64 screen looks like a poor relative. Of course the colour attributes add quite some nice possibilities to colouring an image (and I really wish atari had this feature), but you're still heavily restricted by the limited palette, while Atari is not.

[Oswald]

Although I gave the edge to C64 on sprite hardware, I was arguing against the statement that "it's WAY BETTER" (remember when I observed the universe has more than one dimension). If you look at it rationally and objectively rather than being biased toward the X-axis, the Atari sprite hardware is rendering about 10,000 sprite pixels every frame at 160*200 resolution which comes to about 600,000 pixels/second. C64 is doing 24*21*8 at 160*200 resolution which comes to less than half pixels/second. Now given Atari can use priority conflicts of sprites in various graphics modes even at 4X zoom, it can render about 2.4Million sprite pixels/second (more resultant rendered colored pixels/second than an ISA-based standard VGA card which came out 8 years later).

 

The PMBase does USE RAM, but it's very fast compare to block copying. There are 16-zones and conflict probability is actually 1/16 of Y positions but to keep my algorithm simple, I just merge 32 scanlines worth of sprites in a zone conflict.

 

if you would think rationally and objectively you would realise that for the average game scenario 8x24x21 multicolor/hires sprites with hires X coordinates are better than 4x8 pixel wide stripes without hires/multicolor abilty (yes you can combine them to have even less vertical stripes for multicolor..). and if I look at the whole thing horizontally which represents the true throughput the system (vertically you kindof just multiplex the system) the atari lags behind heavily.

 

And if you do the ORed mode horizontally at 4X sprite expansion, you'll see the ORing is at every pixel and so the throughput is similar horizontally as well. I was comparing both equally at 160*200 which is more used mode. I don't know where you get 4*8 from.

 

throughputwise horizontally a8 sprites are less then half of c64 ones.

[pseudografx]

One more colour "skin" :-)

[atariksi]

Sprites: C64>Amiga>Atari>PC

 

pc>amiga>c64>atari

...

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

 

>>Timer IRQs: Atari>Amiga>PC>C64 (I guess if you stick to 7.16Mhz Amigas, you can use CPU+Copper as better Timer IRQ)

 

>pc>amiga>c64>atari

 

>c64 has 4 16bit timer interrupts, the timers can count the other timers underflow, be one shot, or continous.

 

The lower resolution timers can be done in software using higher resolution timers. We are talking timer accuracy at max on each system: Atari is 1.78979Mhz w/16-bit divisor, Amiga CIA is 7.14Khz but you can combine with Audio Intr as timer IRQs, PC timer freq is 1.19318Mhz (standard PCs-- new nonstandard HPET doesn't qualify as most PCs don't have it nor can access it directly via applications), C64 is 1Mhz CIA frequency.

 

 

>>Gameport I/O: Atari>Amiga>C64>PC (if you use parallel port as joystick port then PC>Amiga>Atari>C64)

 

>it makes no sense to compare a nonstandard solution of the a8 amongst systems. should be IO: pc>amiga>atari>c64. you are comparing here cpu speed. tho I'm not sure a parallel drive-c64 is not faster then atari, as you can beef up the c64's drive while on atari it says constant speed.

 

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).

 

>>Real-time programming: Amiga>Atari>C64>PC (Modern PC OSes don't allow direct I/O control of all hardware and h/w is more & more nonstandard)

etc.

 

>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.

[Fröhn]

It is possible for the two halves of a 160-mode pixel to be programmed with different chroma? My guess would be that the chroma circuitry only samples its data once per chroma clock; making the hires modes are 'transparent' to chroma data would avoid strangeness.

No. The chroma resolution is 160, and the 320 mode is sort of a special case where the luma is handled differently from the chroma.

The color clock resolution on NTSC is 160 (chroma resolution is far less since it needs more than 1 color clock to get the monitor circuitry from one color to another).

 

On PAL the color clock resolution is 200.

 

Also, there is no "sampling" of the color carrier going on. It's a simple analog circuitry which converts average amplitude + phase shift to color offsets. For example, on PAL the color carrier is delayed in the delay loop for exactly 1 rasterline, so every line the math is like this:

 

U = C(prev_line) + C(current_line)

V = C(prev_line) - C(current_line)

 

(expecting that in a normal TV picture the chroma doesn't change too much from one rasterline to another)

 

That's why those 256 color modes works, and that's also why they don't work on NTSC because NTSC decodes colors differently.

[Oswald]

Now with no hi-res at all, and also in more colour versions:

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive.

 

yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

I don't see a problem with this, as far as the scene looks overall better. Compared to it, the C64 screen looks like a poor relative. Of course the colour attributes add quite some nice possibilities to colouring an image (and I really wish atari had this feature), but you're still heavily restricted by the limited palette, while Atari is not.

 

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.