Atari v Commodore

[TMR]

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.

 

Most DFLI pictures are converted, the dithering and so forth is down to that process; throw a decent editor at a good artist and it'll do something pretty spectacular...

 

For the Plus/4 to Atari comparison, the A8 can do 80 colours a scanline from 121 in 320x200 mode, can overscan vertically with ease although horizontal is a more tricky, the CPU is about the same speed on both and the only real down sides are the lack of hardware sprites and TED sound...

[Fröhn]

Aint most 4x4 atari doom clones using a HW mode where antic reads gfx only at every 4th line?

Actually no. If you just place four display list entries which repeat the adress, the ANTIC will repeat the DMA for every line. There is a trick to force ANTIC to reuse it's line buffer which needs a DLI every 8th rasterline. This trick was discovered rather late so most existing demos do not use it. That's why you see many demos having every 2nd rasterline empty: They try to save DMA cycles by that.

 

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

Don't forget: Even though it's half the resolution, the interlace doubles the data to be shifted by the CPU again. So the lower resolution only lowers the DMA load, not the CPU load.

 

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?

Theoretically yes, but same applies for VIC-II: Once a mode is set, the VIC-II displays it on it's own.

 

If I had to look at the time factor, 1.7897 timer vs. 1Mhz timer on C64.

I still can't think of a scenario where those timer speeds matter. Both are 1 CPU cycle per tick, so for the programmer both are "perfect".

 

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.

Now this is interesting. ATM I can't think of any.

 

I rather have vertically high sprites for some applications.

LDA STA every 21st rasterline on C64. Doesn't matter which rasterlines, because VIC-II sprite logic ignores the Y-position until the current sprite drawing has ended, so the programmer has a really easy job here.

[atariksi]

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

 

I already told you calculated OR is only a restriction if you are dynamically changing the palette not if it's set a priori. Two C64 multicolor sprites has two shared colors and two new colors for 4 so why are you saying 3 unique colors/object?

 

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

 

We're discussing a multicolor sprite. Two DMA cycles for one multicolor sprite on Atari. Don't mix it with other things (yet). Three unique colors for one multicolor sprite on Atari (and black in a restricted way).

 

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

 

Set up the registers: PMBase, HPos, Color, DMA enable, ... point is they both need to be set up. I'm not writing a s/w sprite. I'm using the atari H/W registers.

 

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

 

16K of RAM is not MOST of the RAM.

[Oswald]

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

 

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

 

Dithered and no shades.

 

guess what, even 320x200x256 amiga pictures use dithering why? because it makes them look better. dithering is used to improve image quality you know. no shades? what do you mean by shades? there are clearly different shades used of the same color. look closely.

[drac030]

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?

 

I have no idea, what happens, when you *physically* remove the CPU. However you can certainly setup the DL so that ANTIC displays some page-flipping animation, and then you can disable all interrupts and halt the CPU altogether (on 6502, by executin the opcode $02, on 65816 - by executing STP). The animation will still go after that, because the ANTIC, while it is executing own program (i.e. the display list), does not really need any external intervention.

[Fröhn]

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

 

I already told you calculated OR is only a restriction if you are dynamically changing the palette not if it's set a priori. Two C64 multicolor sprites has two shared colors and two new colors for 4 so why are you saying 3 unique colors/object?

Because he explicitely doesn't want to use one of the MC-colors to avoid sharing of colors. Imagine you use sprites 1 to 4, and overlay sprite 1 with 2 and 3 with 4. As a result you get two combined sprites with following colors:

 

Overlayed sprite A: SC1 + SC2 + MC1 (ignoring MC2)

Overlayed sprite B: SC3 + SC4 + MC2 (ignoring MC1)

 

So you get 3 independent colors for both overlayed sprites.

 

Since you have another 4 sprites left, you could do another 2 overlay sprites with minor color sharing to the other overlayed ones:

 

Overlayed sprite C: SC5 + SC6 + MC1 (ignoring MC2)

Overlayed sprite D: SC7 + SC8 + MC2 (ignoring MC1)

 

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?

Set up the registers: PMBase, HPos, Color, DMA enable, ... point is they both need to be set up. I'm not writing a s/w sprite. I'm using the atari H/W registers.

You forget that to get that method work, you need to initialize a lot of memory to the right sprite-shape shifts too.

[atariksi]

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

 

I used it to compare Z-axis-- for depth. I think they used that in that Atari game Landscape.

 

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

 

It is beneficial. For example, if you wanted to playback an digital audio block say from Windows WAVE file (11025Hertz), you are going to get some error after you divide into your timer frequency. That will eventually cause a drift (especially if you have the audio synced to video/imagery). Now if the timer frequency was higher, that error is less (or none sometimes).

 

>>How does that show that my link was wrong?

 

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

 

No, it doesn't. You have two articles giving different opinions. Why should I accept your article to be superior to the other one?

 

>it was made of only sprites.

 

Curtain scene is sprites moving while image is in the background.

 

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

 

Why do you call look-up tables are WASTING RAM? It's a way of SPEEDING things up. I use the following code all the time:

 

XFORM: DB 16 dup(240), 16 dup(241), 16 dup(242), 16 dup(243), 16 dup(244), ... 16 dup(255)

LDA Sample

TAX

LDA XFORM,X

STA 53761

 

rather than the slower:

 

LDA Sample

ROR

ROR

ROR

ROR

ORA #$F0

STA 53761

 

Pick one.

 

 

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

 

GTIA does 80*200*16 shades w/o cpu intervention. It does 160*200*30 shades w/ simple DLI.

[MaPa]

Post deleted.

Edited November 27, 2008 by MaPa

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

 

Most DFLI pictures are converted, the dithering and so forth is down to that process; throw a decent editor at a good artist and it'll do something pretty spectacular...

 

For the Plus/4 to Atari comparison, the A8 can do 80 colours a scanline from 121 in 320x200 mode, can overscan vertically with ease although horizontal is a more tricky, the CPU is about the same speed on both and the only real down sides are the lack of hardware sprites and TED sound...

 

If only there had been sprites - ( or if the C64 had the extended pallette ) there probally wouldn't be any comparisions...

As an aside I tried to run the chaos demo under WinVice, and it stops... What effect isn't being emulated?

[MaPa]

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.

 

Can you explain me please, how you want to verticaly move sprite by changing PMBASE without it to be almost totaly useless? Maybe I just don't get it, but isn't it like you need like 1kB (or 2kB if you use single line resolution) od RAM for one line Y-axis movement (ok, in double line resolution and fine Y movement you can save half memory used by using VDELAY register) and you will move all players together to that predefined position.... So I can't imagine any meaningful use of this method in your stated 16kB of RAM. Will be glad if you prove me wrong.

[Oswald]

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

 

>I used it to compare Z-axis-- for depth. I think they used that in that Atari game Landscape.

 

the screen rendered by a8/c64 is 2d. forget the z axis for god's sake.

 

 

>It is beneficial. For example, if you wanted to playback an digital audio block say from Windows WAVE file (11025Hertz), you are going to get some error >after you divide into your timer frequency. That will eventually cause a drift (especially if you have the audio synced to video/imagery). Now if the timer >frequency was higher, that error is less (or none sometimes).

 

kewl, then a8 has less error when dividing the timer freq when playing a 11025hz wav. a huge win

 

>>How does that show that my link was wrong?

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

>No, it doesn't. You have two articles giving different opinions. Why should I accept your article to be superior to the other one?

 

why should you accept anything I say or link, or anything on the world, like facts that there were sprite capable video chips before the atari ?

 

>it was made of only sprites.

>Curtain scene is sprites moving while image is in the background.

 

http://uk.youtube.com/watch?v=yFdjWSaDlIo

 

0:55, there sprites zooming while plasma/zooming chessb in the background.. 50fps..

 

 

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

 

>Why do you call look-up tables are WASTING RAM? It's a way of SPEEDING things up. I use the following code all the time:

 

compared to VICII where they are not needed arent they ? either 11x slower or much more ram needed to reach the same speed...

 

 

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

 

>GTIA does 80*200*16 shades w/o cpu intervention. It does 160*200*30 shades w/ simple DLI.

 

vs 320x200x16 colors. w/o cpu intervention.

[Fröhn]

Can you explain me please, how you want to verticaly move sprite by changing PMBASE without it to be almost totaly useless? Maybe I just don't get it, but isn't it like you need like 1kB (or 2kB if you use single line resolution) od RAM for one line Y-axis movement (ok, in double line resolution and fine Y movement you can save half memory used by using VDELAY register) and you will move all players together to that predefined position.... So I can't imagine any meaningful use of this method in your stated 16kB of RAM. Will be glad if you prove me wrong.

I guess by using all PMs as one combined sprite (like some games indeed do) or having only one sprite moving vertically, or by using 256k of mem for two sprites

[TMR]

I already told you calculated OR is only a restriction if you are dynamically changing the palette not if it's set a priori.

 

No, it's a restriction if you want totally arbitary placement of colours too; if i want the third colour to be darker than the first two it can't be, if i want it to be grey whilst the other two aren't it can't do that either and these are just simple examples.

 

Two C64 multicolor sprites has two shared colors and two new colors for 4 so why are you saying 3 unique colors/object?

 

Because i'm keeping it simple and am only using four C64 sprites in total to generate two objects for a direct comparison; since the multicolours are only used on those two objects i'm sharing them out so each is two sprite colours and one multi; that gives three unique colours with a register each. Or if we're not keeping it simple, i'll use the part of the hardware sitting idle.

 

We're discussing a multicolor sprite. Two DMA cycles for one multicolor sprite on Atari. Don't mix it with other things (yet). Three unique colors for one multicolor sprite on Atari (and black in a restricted way).

 

i'm not the one mixing it up with other things, you've forgotten the difference in height between the two; the Atari is using the DMA for 256 scanlines whilst the C64 only pulls for the 21 the sprite is displayed for, so even if we use two C64 sprites as i've proposed to match the Atari specifications for a multicolour sprite that's still 86 cycles (each sprite uses 42 cycles and one extra for the first scanline) over two sprites to the Atari's 512... unless i've truly stuffed my "calculations" and forgotten something important about DMA on one of the machines (always a possibility before the third cup of coffee) that's nearly six times the overhead...?

 

Set up the registers: PMBase, HPos, Color, DMA enable, ... point is they both need to be set up. I'm not writing a s/w sprite. I'm using the atari H/W registers.

 

And the definition of the sprite itself, where's that initialised? It was one of the LDA/STA pairs on the C64.

 

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

 

16K of RAM is not MOST of the RAM.

 

Read what i said again, where i said "method allows for animated objects" in particular because yours doesn't; 16K will give static objects with X and Y movement and that serves no useful purpose for anything apart from theoretical discussion. If the C64 doesn't need to change it's sprite definitions, it uses 512 bytes of sprite data for eight unique definitions whilst you're chewing through thirty two times that.

[TMR]

As an aside I tried to run the chaos demo under WinVice, and it stops... What effect isn't being emulated?

 

The WinVICE C16 and Plus/4 emulation is nowhere near accurate at the moment and it stuffs up a lot of things; for demo watching especially, get hold of YAPE instead.

[Rybags]

IIRC, the Atari actually can do 23 colours in a scanline without any CPU intervention.

 

GPRIOR set to 00 means PL0 colour/lum is ORed with PL1, and the two of those are ORed with PF0/1, same again with PL2/3 and PF2/3.

 

So maybe not useful in all applications, but it's a bigger number than 16.

[TMR]

So maybe not useful in all applications, but it's a bigger number than 16.

 

Yeah, but 320 pixels across is a much bigger number than 80 so losing seven colours is a pretty good trade-off. =-)

[Fröhn]

When I tried to get a graphics dude to do some A8 graphics, he simply used 4/8/12 for luma and x/x/x for chroma. I tried to make him use something else (to make the gfx look different) but he wasn't able to come up with a useful combination and it was impossible to explain bit-OR to him, he just asked "what about colors x/y/z?" and I always had to reply "sorry, doesn't work".

[MaPa]

So maybe not useful in all applications, but it's a bigger number than 16.

 

Yeah, but 320 pixels across is a much bigger number than 80 so losing seven colours is a pretty good trade-off. =-)

 

It's in 160x200 mode (probably char mode with 5th color).

[TMR]

So maybe not useful in all applications, but it's a bigger number than 16.

 

Yeah, but 320 pixels across is a much bigger number than 80 so losing seven colours is a pretty good trade-off. =-)

 

It's in 160x200 mode (probably char mode with 5th color).

 

Still needs the hardware sprites and gives half the resolution... 320x200x16 with all the sprites turned off is the C64's play on this front.

[ClausB]

A challenge to you C64 fans:

 

Port this (only 28 hacking days 'til Christmas):

XMASTREE.zip

[TMR]

A challenge to you C64 fans:

 

Port this (only 28 hacking days 'til Christmas):

 

Tell you what, i'll do it when the people talking about how they could do Turrican on the A8 are finished...

[pseudografx]

A challenge to you C64 fans:

 

Port this (only 28 hacking days 'til Christmas):

 

Tell you what, i'll do it when the people talking about how they could do Turrican on the A8 are finished...

I think Turrican with so many moving objects on the screen would only be possible on Atari if fewer colours and lower resolution were used (like 160x120x5 colours). Otherwise the framerate would have to be heavily decreased (like every third or even fourth frame). That might still make the game nice to play but the visual quality would be nowhere near the c64 version (especially if no memory expansion was used). And I'm saying this as an all-time Atari fan.

[Crazyace]

As an aside I tried to run the chaos demo under WinVice, and it stops... What effect isn't being emulated?

 

The WinVICE C16 and Plus/4 emulation is nowhere near accurate at the moment and it stuffs up a lot of things; for demo watching especially, get hold of YAPE instead.

 

Thanks.

I like the 128 colour chunky mode shown on the plus 4 - that's quite cool - although the CPU seems to slow down more than the atari during the demo

[atarian63]

The Design of the Atari XL series is much desired for good handling the keyboard, while the first breadbins weren't something like that. You'd need a ladder for the wrists to reach the keys easily

 

the first atari 8bits werent easy on the wrists either. anyhow I never found it uncomfortable, and I wouldnt have either if I had one of those ataris. this is just nitpicking.

Hardly... The Atari's not only looked better but had much better keyboards. Just a fact.

[TMR]

Hardly... The Atari's not only looked better but had much better keyboards. Just a fact.

 

The Ataris (as in all of them) had much better keyboards... [cough]Atari 400[/cough]