Atari v Commodore

[andym00]

And the reading of Colour RAM causes Cycle Stealing, as the Sprite reading does with the already slower CPU.

 

Okay, listen now.. VICs Colour Ram fetches do not steal cycles from the CPU.. It happens on the cycles where the CPU couldn't run anyway.. The character matrix fetches steal from the CPU.. 40 character matrix fetches equals the 40 cycles we lose on a badline..

There's an additional 40 colour fetches but these are interleaved with the character matrix fetches that take place, but the CPU pays no penalty for those 40 colour ram fetches..

 

edit: Check the first timing table.. https://sh.scs-trc.net/vic/vic_article_3.6.htm#3.6.3.

the 'c' cycles are what's of interest to you..

 

Scrolling on the A8 is a bit odd. First it takes more DMA cycles , but when scrolling is working, the CPU gets cycles back.

 

Care to explain that more ? I'm curious..

Edited July 2, 2009 by andym00

[Rybags]

I believe the Colour RAM fetches are part of the character matrix fetches.

 

Any more info on this "memory corruption" ? Sounds a bit weird to me.

[jvas]

Maybe this discussion is about the memory corruption:

 

http://noname.c64.org/csdb/forums/?roomid=...mp;firstpost=18

Edited July 2, 2009 by jvas

[Rybags]

A8 scrolling means 48 characters are fetched. But, as the display moves to the right less than that are needed.

[atariksi]

I don't think sprite replication on Atari or 23 color GPRIOR is as complex as doing time critical things on C64 given no hardware support for them and giving burden to software to deal with it. GPRIOR can be used even in BASIC as I gave the code already. Delaying DMA cycles to get some effects isn't your normal coding especially when you have to deal with the BA signals caused by color RAM and sprite motion. And now you combine stuff like line-based scrolling and overscan/underscan and your timing can't be used anymore. You are blaming me for claiming things impossible but I already gave code for them in BASIC yet you are trying to explain things that would require cycle-exact coding and more overhead in software than Atari doing it via it's DL and hardware registers.

 

I beg to differ because the code involved is fairly constant, and very easy to set up.. Far far easier then this pie in the sky idea of horizontally multiplexing players.. I'm ready to be proved wrong on this, and would love to be..

Colour Ram doesn't incur any overhead on the 64.. Colour Ram is connected via a seperate bus to VIC internal 1k x 4bit memory..

Scrolling doesn't affect timing at all.. Timing is exactly the same..

You're BASIC example is exactly that.. It shows 23 colours, now do something sensible with if you please...

 

I set up the GPRIOR in BASIC; it's just poke 623,0. You are arguing against something that you don't understand-- that's all. Time critical stuff is complex not things that can be programmed in BASIC with PLOT/DRAWTOs and a positioning players.

 

Let's stick to the point here-- we are talking about Atari having easier/faster video synching cycle-exacting coding. I already gave example of "backyard pong" and how it can be done using GPRIOR mode 0. Your own C64 people confirmed that earlier in the thread what was causing BA inexactness.

[MaPa]

A8 scrolling means 48 characters are fetched. But, as the display moves to the right less than that are needed.

 

I don't fully understand your second sentence why only when display moves right. In normal size display it's needed max. 41 characters (40 when char aligned) of course when the display is only 40 chars wide

Edited July 2, 2009 by MaPa

[atariksi]

Lovely is when it's simple and exact and relies less on software and more on hardware. It's good that you have some workarounds but not as good as hardware support for it.

 

And the point of this is ? I'm not biased here at all.. If I knew the A8 as well as I know the 64, or the 7800 or the 2600 then I would be posting pro's and cons on both sides.. Since I don't, we're left in an ever decreasing circle of petulance from you..

...

 

Now I see why you assumed you won't get anything out of this. Before it was me the only one being inaccurate in the thread and now it's me in a circle of petulance. Your hatred in your replies is evident. Perhaps, some logic or rationality would help you. And dropping false accusations would help you get something out of it.

 

My original point was that it's better to have hardware support for something than having to do it in software-- so where's the circle. Your tried to brush the whole Atari advantage of cycle-exact coding with saying your C64 stuff is "no brainer" when it actually is still harder than Atari and inferior (slower) since it requires complex software work arounds. I haven't even talked about the timer frequency also being superior on Atari which also relates to cycle-exact coding.

 

You do need to play audio on badlines-- most of audio files/audio recorders nowadays are on Windows which uses 11Khz, 22Khz, etc. so if you use 11Khz, you end up with playing audio on badlines.

>Umm, we don't in the context of what we're talking about.. So, why would you use 11Khz or 22Khz ? Instead of 7.8Khz or 15.6 Khz then ? Go on, I'm dying to hear this answer.. I believe you're just being deliberately obtuse here now..

 

Once again just insulting people without any basis. What context???? Atari can play any audio sampling rate uniformly given it's DMA-- that's the original point. Now you narrowed yourself to 7.8Khz and once again shove the Atari advantage under the rug with word jugglery.

 

>Next you'll be saying that the 64 fails because we can't have a 320x256 or 256x256 screen, because that's a common size of images on Windows..

>I did hold you in some high regard up until now, but you've really just blown it with that

 

You are a biased envious confused person as far as I can tell from your replies. Audio playback is the topic -- read the posting before you reply.

You want me to quote it back to you so you can try again to understand it.

 

Stretching sprites by constantly modifying some register every scanline is still not as good as GTIA automatically replicating the sprites for you. You have more software burden involved. In my book if hardware can consistently do it, it's a feature even if happens to be not the intention of the designer.

 

>I didn't say it was in this context.. I simply gave one of many ways of ensuring a constant set of cycles over the screen.. Your choice of word here, replicating, is deliberately chosen to mislead.. GTIA doesn't replicate sprites for you at all..

 

Sorry, you are DEAD WRONG. It's automatically by default in replicate mode once you turn on the machine. Your so-called constant set of cycles requires overhead and not as good as Atari.

 

>It has no idea of a sprite in the context of an isolated on screen object occupying a fixed vertical region, just an array of memory that it blindly displays down the height of the screen..

 

Whatever in GRAFn can be made to repeat.

 

>Life in the world of Atarski could be fun

 

You are the one who is making false accusations.

 

>So does this mean, that by messing with the sprite addressing hardware, and forcing it not to add 3 to each sprite line, and 2 instead (or the other possibilities, there are many!) that we support hardware sprite distortion ? Or maybe at a pinch, (holy crows!!!) hardware texture mapping!!!

 

Take your bullcrap elsewhere. You are dead wrong so until you show otherwise, you can stop all the other absurd distorted conclusions that you come up with.

 

It's a "no brainer" at the cost of complexity; it more complex than the DLIs I posted earlier in this thread which execute cycle-exact code without relying on WSYNC. It requires that code be all exact in the background.

 

>It's not.. I've told you once already how to ensure jitter free interrupts, you've chosen to ignore that..

 

Go read the original point. I actually granted you that you can stabilize things but Atari is still superior at this-- no doubt about it.

[atariksi]

Another speculative remark on your part: "only one throwing inaccurate facts around is you". I suppose you read all the bullcrap that so many C64 fans wrote in this forum and drew this conclusion? I don't know why you can't accept facts as they are stated and want to resort to attack people based on something unrelated to C64 vs. Atari. But let's get the posting # for the Pet stuff so I can see what you are referring to.

 

I have heard from many people about memory corruption using these DMA delay tricks.

 

Okay okay, the choice of saying 'the only one' maybe wasn't the best first choice.. I've read most of this thread over it's life, and I've ignored most of the clearly wrong stuff because it wasn't being picked up on, or simply wasn't relevant, or simply didn't want to get involved.. I just feel that you're being overly vocal here and were thoroughly mispresenting the 64, and think it fair that it be pointed out that you've made mistakes in your statements before.. Though on the whole, bar being a bit wonky, you've done a fair job when not splitting hairs.. I'm not digging for that post, you can find it if you want.. It's where you're going on about pets and their cpu configurations..

 

I've also heard from many people about the memory corruption (I've also heard the moon is made of cheese), but that fact of the matter is there's a work around.. Demos don't care that the memory might corrupt, as long as it survives the duration of the effect.. Games obviously have different criteria.. No go figure why commerical games featuring these effects work fine.. Big cluestick time.. It's nothing to do with the memory refresh being altered by the dma-delay..

 

Wasn't the best choice?? You made quite a few blunders, man. Make up your mind-- first you claim I am inaccurate about Pets and now I am "thoroughly mispresenting the 64". Purposely and desperately trying to find some fault won't suit you in having a coherent discussion while superficially claiming "unbiased". Your bias is oozing out of you and more hatred than objectivity. Sorry, there's nothing misleading that's why you won't need to dig through it.

 

I NEVER said anything about memory refresh. You need to get a clue. I have tried some of the stuff whilst my C64 was working and there's all sorts of problems I had. Stop false accusations and write FACTs. Your game is simply "call a dog a bad name and hang him." Sorry, there's some intelligent people around here.

[atariksi]

...So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

I'm all for commodore but have to correct you

In every line where you use sprites VIC has to read pointer and sprite data...

So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins...

So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles...

It's not without cost

 

And as I know one line is 63 cycles long on PAL system ?

25 badlines = 25 * 21 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 63

112 blanked lines = 112 * 63

So we get 18606 cycles per frame..

 

But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution...

 

As Rybags stated in post #6443, it's not just cycles you have to look at but uniformity of it and being able to sync up to particular cycles and I would say exactness of them. I can play back a digitized audio file knowing DMA is pretty much uniform in graphics modes (no bad lines). So what happens when you play audio with bad lines on C64? What's the worst case latency? And then of course those sprites and color RAM don't always use up same number of cycles so writing kernels would be a much more difficult task. Atari CPU clock syncs up with video color burst.

 

PAL/NTSC have same number of CPU cycles/scanline on Atari so one version of kernel will work on both machines. And you can use sprites in replicate mode w/screen off and get 105 cycles/scanline (27510/frame NTSC or 32760/frame PAL) for applications that need the time.

 

Here's the post again regarding synchronization and audio playback. Nothing to do with limiting to just 7.8Khz playback.

[emkay]

Okay, listen now.. VICs Colour Ram fetches do not steal cycles from the CPU.. It happens on the cycles where the CPU couldn't run anyway.. The character matrix fetches steal from the CPU.. 40 character matrix fetches equals the 40 cycles we lose on a badline..

 

 

Where is the difference? It is not enough time for fetching Colour RAM and Char "matrix" in the "other time" , so it steals 40 cycles of the already slower CPU. And, as used in "Mood" the doubled fetches cost double CPU cycle stealing.

I'm really burning to see "Mood" in 3 to 4x speeds on the Atari

[R4ngerM4n]

@atariski: it's very difficult to follow your posts. Please do not always quote the entire text of the person you respond to. More info concerning proper quoting can be found at learn.to/quote. Thanks!

[emkay]

A8 scrolling means 48 characters are fetched. But, as the display moves to the right less than that are needed.

 

I don't fully understand your second sentence why only when display moves right. In normal size display it's needed max. 41 characters (40 when char aligned) of course when the display is only 40 chars wide

 

I don't understand the question itself. Every Atari coder knows that scrolling takes always 8 bytes more than than the screen width.

If you use a 32 chars wide screen, ANTIC fetches 48 bytes

If you use a 40 chars wide screen. Antic fetches 48 bytes.

Since 48 bytes is the max- that Antic fetches every line, it doesn't make sense to have 40bytes wide horizontal scrolling games.

(You can say: The more the Antic is doing, the more it gives back to the CPU... resulting in an unseen speed balancing...)

 

 

But that wasn't part of my sentence above. When vertical scrolling is used, RAM refresh is reduced...

Well, and horizontally the DMA reads get reduced aswell...

 

Another thing, people always may lose their focus on is the fact that DLIs (or Screen kernals) do not steal as much cycles as they might think.

Starters on the A8 see the DMA Cycle stealing and think that additional DLIs do additional cycle stealing.

But, clearly, they share the same time, and the VBI time still remains at 1.79MHz....

Edited July 2, 2009 by emkay

[popmilo]

Sometimes I feel like a character in this image...

 

 

Please Tell me this:

If I produce c64 demo on one screen that shows 16 colored 160x200 bitmap and bunch of sprites flying around screen,

and you can not produce same picture and same moving objects on Atari......

 

Will you say "I admit, it can not be done on Atari...." ?

 

Or will you say something else ?

[emkay]

Please Tell me this:

If I produce c64 demo on one screen that shows 16 colored 160x200 bitmap and bunch of sprites flying around screen,

and you can not produce same picture and same moving objects on Atari......

 

Will you say "I admit, it can not be done on Atari...." ?

 

Or will you say something else ?

 

Well, it refers to the vocal emphasizement

 

The Atari could not do THAT.

But, since C64 allows Interlace, it is no problem to show 256 colour images at 160x239 and you could see a big bunch of "sprites" flying around the screen

[popmilo]

We were arguing over simplicity and Atari has quite a few things that can be done simply using even BASIC. Yeah, to go beyond it's standard modes, you need to use DLIs and IRQs or whatever. But it's quite easy to have a GITA 16-color mode with GPRIOR enabled and sprites overlayed even in BASIC. Getting more than 5 sprites per line would require some complexity.

But I can also make my 16 color 160x200 bitmap screen with 8 sprites flying around screen in basic ???

In my vocabulary BASIC <> SIMPLICITY (even the excellent Atari basic )

 

Did you catch that ? 8 SPRITES FROM BASIC....

 

Again, you claimed 5-color mode was complex and I stated it's like C64 char mode. For simplicity, the linear modes are there but then where's the linear mode on C64?

I claimed 5-color mode is complex because color depends on character code...

On C64 character code is character code.... color is color.... Uniformity... Simplicity....

 

But I'll admit - its a minor difference with no practical influence in coding...

But its a BIG difference in trying to design level graphics....

 

And while we are on character sets... Will you claim that Ataris 128 chars are better than C64's 256 chars ?

[popmilo]

Well, it refers to the vocal emphasizement

 

The Atari could not do THAT.

But, since C64 allows Interlace, it is no problem to show 256 colour images at 160x239 and you could see a big bunch of "sprites" flying around the screen

 

Finally somebody with sense of humor!

 

If an atari guy says to me: "C64 can not display 256 colors!"

I'll say: "Yes, you are right."

No buts...

Simply Yes...

 

Is it to much to ask for same ?

 

I spent hours reading this topic, and main reason for that is to learn something new... I'm very glad to say that I did.

Thank you all for that. I know we are comparing two so different and yet so similar computers.

Comparisson can not be done in black and white.

Im not looking for faults, Im looking for features - a friend of mine has a saying he uses alot: "Its not a bug, Its a feature!"

 

So lets find best features for both computers and use them to produce something great!

[kenfused]

I don't understand the question itself. Every Atari coder knows that scrolling takes always 8 bytes more than than the screen width.

If you use a 32 chars wide screen, ANTIC fetches 48 bytes

If you use a 40 chars wide screen. Antic fetches 48 bytes.

Since 48 bytes is the max- that Antic fetches every line, it doesn't make sense to have 40bytes wide horizontal scrolling games.

[Bryan]

I claimed 5-color mode is complex because color depends on character code...

On C64 character code is character code.... color is color.... Uniformity... Simplicity....

I believe the 64 has char modes that work both ways.

[atariksi]

Sometimes I feel like a character in this image...

 

 

Please Tell me this:

If I produce c64 demo on one screen that shows 16 colored 160x200 bitmap and bunch of sprites flying around screen,

and you can not produce same picture and same moving objects on Atari......

 

Will you say "I admit, it can not be done on Atari...." ?

 

Or will you say something else ?

 

Picture looks b&w on my machine. Regardless, it does depend on how the colors are spread out and which colors are involved and how many sprites/scanline you have and how many overlap/intersect each other.

 

Besides some C64 people's claim that they can have 16 colors anywhere, it's still restricted since having ability to have 16 colors anywhere would require a 160*200*16 = 16K buffer.

[atariksi]

We were arguing over simplicity and Atari has quite a few things that can be done simply using even BASIC. Yeah, to go beyond it's standard modes, you need to use DLIs and IRQs or whatever. But it's quite easy to have a GITA 16-color mode with GPRIOR enabled and sprites overlayed even in BASIC. Getting more than 5 sprites per line would require some complexity.

But I can also make my 16 color 160x200 bitmap screen with 8 sprites flying around screen in basic ???

In my vocabulary BASIC <> SIMPLICITY (even the excellent Atari basic )

 

Did you catch that ? 8 SPRITES FROM BASIC....

...

Yeah, I catch that. You can have only 4 players and 4 missiles on Atari without resorting to multiplexing.

 

BASIC is supposed to be beginners programming language, but you can also have simple code in ASM, but I would bet you can build a program faster in BASIC if you knew both languages.

 

Again, you claimed 5-color mode was complex and I stated it's like C64 char mode. For simplicity, the linear modes are there but then where's the linear mode on C64?

...

>And while we are on character sets... Will you claim that Ataris 128 chars are better than C64's 256 chars ?

 

See you're used to dealing with chars since your text modes and graphics modes are centered around that whereas I deal with text modes and linear graphics modes so although 256 chars is better than 128, I have other options available to me on a per scanline basis.

[popmilo]

Picture looks b&w on my machine. Regardless, it does depend on how the colors are spread out and which colors are involved and how many sprites/scanline you have and how many overlap/intersect each other.

Its supossed to be BW... And its not done on C64

But, its a good idea!!!

It is an ilustration based up on a book "The Ingenious Hidalgo Don Quixote of La Mancha", in wich Don Quixote attacks Windmills and fails...

The novel was recently voted The Greatest Book of All Time by the Nobel Institute...

 

I posted it because of famous expression: "Tilting at windmills"

 

From wikipedia: "Tilting at windmills is an English idiom which means attacking imaginary enemies, or fighting unwinnable or futile battles".

http://en.wikipedia.org/wiki/Tilting_at_windmills

 

Well, sometimes I feel like that...

Fighting a futile battle

[popmilo]

Besides some C64 people's claim that they can have 16 colors anywhere, it's still restricted since having ability to have 16 colors anywhere would require a 160*200*16 = 16K buffer.

"Anywhere" = Any three colors out of 16 in any of 40 uniformly horizontally spread regions in one scanline + one background color for whole line + one border color

 

How many uniformly horizontally spread regions in one scanline, and with how many colors in them can you make on Atari ?

 

And yes there is a hires character mode "extended background" where charset is 64 chars, and background color is choosen with bits 6 and 7 of char code.

And guess what ? Whas it used in games ?

Maybe, I can not remember any... And I remember thousends....

Guess why ?

Because it sucks!

[emkay]

From wikipedia: "Tilting at windmills is an English idiom which means attacking imaginary enemies, or fighting unwinnable or futile battles".

 

Interesting, what english guys always name an englisch idiom

I bet some guys think that chinese is the biggest english idiom of the world

 

In German it is "Kampf gegen Windmühlen" and I guess, you find a parallised sentence in the more than 5000 years old chinese history books

 

And, at the same line, we always read that the C64 was the first "Homecomputer"...

[emkay]

And yes there is a hires character mode "extended background" where charset is 64 chars, and background color is choosen with bits 6 and 7 of char code.

And guess what ? Whas it used in games ?

Maybe, I can not remember any... And I remember thousends....

Guess why ?

Because it sucks!

 

Looking at enforcer 2. It would fit. Ont the first sight it looks impressive. Looking closer at the background, it sucks. And the screencontent is rather low.

[Bryan]

Well, sometimes I feel like that...

Fighting a futile battle

 

Yeah, but you have to be as crazy as Don Quixote to really care whether you can convince a handful of people that one obsolete 8-bit is better than another.