Atari v Commodore

[Crazyace]

Nice pic - is there a reason why the green area is so wide, or is it intentional ( I thought you might only want the eye to be green )

Can G2F switch GTIA on/off across a line , as that would make the background grid much more impressive?

 

( I had a look at G2F - and I'm much more impressed with anyone who makes good pictures with it now )

[emkay]

Nice pic - is there a reason why the green area is so wide, or is it intentional ( I thought you might only want the eye to be green )

Can G2F switch GTIA on/off across a line , as that would make the background grid much more impressive?

 

Yes and no

 

( I had a look at G2F - and I'm much more impressed with anyone who makes good pictures with it now )

 

Particular the GTIA modes seem to have probs in G2F. At least it makes some demonstrations possible.

[emkay]

Sometimes I realize how ridiculous some things were on the A8 scene. While people have problems with moving objects in machine language on the Atari, others simply made full games in Basic. Not that "high tech" but a nice game with digi speech ...

 

 

[Fröhn]

Claim was that 320 mode has advantage of more colors so you do need to use a mode that has a bad line which prevents the horizontal split.

You are mixing up all kind of stuff now. 320 mode doesn't need color splitting because of the badlines which read 2 new colors for hires mode every 8 pixels. It would be completely stupid to use color splits for that purpose since it would reduce the amount of possible color changes to 1 color every 32 or 48 pixels.

 

That's artefacting due to simulated color carrier. If you use lower frequencies (160 res or multiple hires pixels of same color next to each other) there won't be any. Please keep in mind that C64 can scroll anything in 320 res accuracy, even 160x200 resolution.

I'll have to see if that retains the color (especially on edge of region).

No issue on C64. And hires colors are only an issue on chessboard patterns and if you have chosen to connect the C64 to the monitor via composite and not s-video. S-video completely removes ALL artefacting effects and allows for much much higher resolutions (on luma) too, for example Amiga 640x200 etc.

[dwhyte]

This thread and the 'Amiga Sub-Forum' thread are now the top two... WTF?!? Did the Commodore guys decide to razz the Atari guys this Christmas? If it continues, us hardcore Atarians might have to stir up some shit on the Commodore forums...

[Heaven/TQA]

Sometimes I realize how ridiculous some things were on the A8 scene. While people have problems with moving objects in machine language on the Atari, others simply made full games in Basic. Not that "high tech" but a nice game with digi speech ...

 

 

 

interesting...never played Bros but it really uses samples...

[atariksi]

You are generalizing incorrectly. The accuracy is always 1.79Mhz but for placing a horizontally split window on the display area, it's like every other CPU cycle. That's the point. DMA does not affect the 1.79Mhz accuracy. If you know the DMA chart, you can cause an interrupt to occur at the exact cycle (@1.79Mhz accuracy).

So you can on C64, and that's why I think this "1.77 mhz timers are better than 0.985 timers" doesn't matter at all: All that matters is that it can hit any CPU cycle. You may complain about slower CPU speed, but the timers can both achieve the very same thing. Also knowing the DMA chart is not enough, because you also need to know exactly what code is running outside the IRQ for knowing the actual delay.

...

You are DEAD wrong that it doesn't matter whether timers are 1.77 or 0.985. They can't achieve the same thing. You are MIXING up doing horizontal splits on display to whether a timer accuracy makes a difference. We're not trying to hit a IRQ on a CPU cycle but on a NTSC cycle. Atari can trigger the IRQ every other NTSC cycle (3.58Mhz/2). On display the DMA pre-empts so you have to pick the points carefully. And timers are also used for other things like audio playback, i/o, etc. You need to stop arguing about timers as the argument is how accurate can we make a horizontal split using a timer.

 

>You need them for color cells or char matrix row update. If you don't need that, badlines are not needed.

 

But the point is what things you can do in 320*200 mode to get more colors.

 

>>If the ratio is not evenly divisible, you will end of with an unstable point of interrupt on the screen. On the Amiga this happens as well since it's CIA interrupt freq is 7.15909Mhz/10 = 715Khz and it cannot have a divisor that evenly divides into cycles per frame.

 

>But since the CIA clocks are equal to CPU clocks on both systems, that doesn't happen.

 

On Amiga, the CIA IRQ does NOT sync up to the NTSC cycles because they divided the CPU freq by 10 before feeding it into the CIA. So in one frame intr, it may occur on one pixel and the next frame it may be another pixel. It diverges away from exact pixel on the screen.

 

>On C64 only slightly since it has an anti artefacting filter which heavily reduces the colors generated by hires pixel patterns. And if you connect the C64 via a S-Video connection it's no issue anyway because then absolutely no chroma effects will appear on switching hires lumas.

 

>The carrier is generated like this: C = U*sin(x) + V*cos(x) -> It can have any phase shift from 0...360°.

 

I agree lumas can be done at 320 pixel accuracy.

[potatohead]

This thread and the 'Amiga Sub-Forum' thread are now the top two... WTF?!? Did the Commodore guys decide to razz the Atari guys this Christmas? If it continues, us hardcore Atarians might have to stir up some shit on the Commodore forums...

 

They've got color envy, and besides, we are just cooler here! Read, enjoy, and know it's all a big compliment!

[atariksi]

In the example, if you replicate 4 sprites horizontally @60Hz, you are restricted in the y-position and shape since there's not enough time to update Grafn AND HPOSes.

 

Which is a limitation compared to the C64 , as I originally stated.

...

But you can have more then 5 sprites/scanline at 60Hz which was one of the points. There are uses for sprites other than having all of them have different shapes, colors, and Y-positions.

 

>>VBlanking method would have to be used if you want to change shape and Y-axis and have 8 sprites on a scanline.

 

>Are you talking about multplexing sprites - I was thinking of 8 per line from a far greater number ( 30 or 40 ) , which is what you would need for a 'busy' sprite game

 

Sure you can have more than 8 per screen but having 9 per line is do-able as Joust does it.

 

>My original point was that the c64 was much more geared to 320 pixel modes - the Atari has a limited support , but everything is based on 160. All of the underlay tricks are very usefull to 'extend' the 320 support - but they dont match the builtin colour ram.

 

>>I would state that they are not the same method to coloring stuff in 320 pixel mode not that Atari's tricks are more limiting. After all for certain cases, Atari approaches the 8-bit color depth whereas C64 hits the ceiling at 4 bit color depth.

 

>The Atari method is still inherently 160 pixel based - again you claim a shading advantage, which I agree with, while ignoring the resolution advantage.

 

I am not claiming just a shading advantage. I posted the example of GPRIOR-- that will OR colors as well as shades.

 

>>There's no side-effect in switching between Gr.9 <->Gr. 8 <->Gr. 11. Gr. 10 would cause one color clock delay. And sprite overlays can be replicated easily just like 53275 for switching priorities.

 

>This isn't as easy as just setting a bit in colour ram to select between 320 and 160 mode for each of the 40 characters. >Can you switch gr.8 -> gr.15 , and switch back 4 colour clocks later?

 

But Gr.15 and sprite overlays and GPRIOR based colors are at same resolution. It's better to move large sprites than toggle between Gr.15/Gr.8 (assuming Gr.15/Gr.8 switch was do-able).

 

>This is a very simple example of something you can never replicate on an A8, purely because of the 320 pixel resolution.

 

>There are A8 images that would be impossible for the c64 to replicate , and that's why the A8 is so cool... seeing as it can still hold up with the newer machine.

 

It's already known GTIA modes are undoable on C64, but we are talking 320 mode where I stated that the two machines have a different approach to doing color and 320 mode is not limited to two colors.

[Fröhn]

You are DEAD wrong that it doesn't matter whether timers are 1.77 or 0.985. They can't achieve the same thing. You are MIXING up doing horizontal splits on display to whether a timer accuracy makes a difference. We're not trying to hit a IRQ on a CPU cycle but on a NTSC cycle. Atari can trigger the IRQ every other NTSC cycle (3.58Mhz/2).

There are no such things as "NTSC cycles". The color carrier has a frequency, but it's NOT a digital clock. The monitor does NOT know about "pixels" at all.

 

You need to stop arguing about timers as the argument is how accurate can we make a horizontal split using a timer.

On typical A8 resolutions (40 byte/line) it's both the same: Every 8 pixels. Also it takes 0...7 cycles to actually start an IRQ on C64, and on A8 it will take 0...14 cycles due to every 2nd cycle lost -> ends up the same.

 

You need them for color cells or char matrix row update. If you don't need that, badlines are not needed.

But the point is what things you can do in 320*200 mode to get more colors.

That might be a point on A8, but on C64 you simply don't need to do that.

 

On Amiga, the CIA IRQ does NOT sync up to the NTSC cycles because they divided the CPU freq by 10 before feeding it into the CIA. So in one frame intr, it may occur on one pixel and the next frame it may be another pixel. It diverges away from exact pixel on the screen.

Amiga can use Copper to set IRQ flags. Timer IRQs are not needed for that anyway. And I don't really see how this has anything to do with C64. When it comes to clock generating A8, C64 and other 8 bit computers work basically the same: All clocks derived from color carrier clock * 4.

 

I agree lumas can be done at 320 pixel accuracy.

And chroma cannot be done in 160 pixel accuracy, it actually needs several color carrier cycles to move the circuit from one color or another. Also you can't really talk about "pixels" anyway. It's all analog and all you get is frequency ranges (which differ from output device to output device btw). I think a lot of A8 people have a heavy misconception of how video encoding and decoding works, mainly because some Atari books spread terms like "color clocks" and people had mistaken them being similar to CPU clocks, pixel clocks etc.

[atariksi]

Claim was that 320 mode has advantage of more colors so you do need to use a mode that has a bad line which prevents the horizontal split.

You are mixing up all kind of stuff now. 320 mode doesn't need color splitting because of the badlines which read 2 new colors for hires mode every 8 pixels. It would be completely stupid to use color splits for that purpose since it would reduce the amount of possible color changes to 1 color every 32 or 48 pixels.

...

 

I am not mixing things up, but you can't apply char mode colors and still claim a horizontal split. How many colors can you get at 320*200 and have no bad DMA lines? And after you answer that, tell me at which pixels you can cause an IRQ to occur consistently (every line and every frame, the horizontal position of pixel will be the same). I don't see how the 0.985Mhz timing accuracy is going to allow you to hit any pixel position consistently.

[Fröhn]

I am not mixing things up, but you can't apply char mode colors and still claim a horizontal split. How many colors can you get at 320*200 and have no bad DMA lines?

16 actually, with color cells as high as there are no badlines. But I still don't see why anyone would do that? I mean, color splits use all CPU time anyway, so why not use badlines which also use all CPU time but achieve much more colors?

 

And after you answer that, tell me at which pixels you can cause an IRQ to occur consistently (every line and every frame, the horizontal position of pixel will be the same). I don't see how the 0.985Mhz timing accuracy is going to allow you to hit any pixel position consistently.

You won't hit any pixel on A8 either, only every 8th (hires) pixel. Just like on C64. Don't know how often I have to repeat that until you read it. And since C64 doesn't take refresh cycles from CPU, it's even more accurate on the left side of the picture.

[Crazyace]

In the example, if you replicate 4 sprites horizontally @60Hz, you are restricted in the y-position and shape since there's not enough time to update Grafn AND HPOSes.

 

Which is a limitation compared to the C64 , as I originally stated.

...

But you can have more then 5 sprites/scanline at 60Hz which was one of the points. There are uses for sprites other than having all of them have different shapes, colors, and Y-positions.

 

>>VBlanking method would have to be used if you want to change shape and Y-axis and have 8 sprites on a scanline.

 

>Are you talking about multplexing sprites - I was thinking of 8 per line from a far greater number ( 30 or 40 ) , which is what you would need for a 'busy' sprite game

 

Sure you can have more than 8 per screen but having 9 per line is do-able as Joust does it.

 

 

But Joust doesn't do it - it flickers!

[potatohead]

How can we not talk about pixels and resolution?

 

Agreed the analog signal is not well described in terms of pixels and such, but that is how we address it, is it not? When we post up a TV test pattern, and we look at lines and things, we look for those elements that can be resolved, we give that a number, and that is the resolution of the system as a whole. This is an approximation, much like measuring something with a ruler is. However, it is a useful approximation, and is valid on that basis.

 

So then, on a color TV, composite video, an Atari 8 bit computer runs it's video in lock step with the color burst. Everything is a multiple of it, meaning that the addressable pixels, occur at the same time, or phase with respect to the color burst reference. One period of that color burst is equal to one 40 byte DMA color graphics mode pixel, and there are 160 of those per display line.

 

It is possible on all but the absolute worst TV's to display a red, green, blue, pixel pattern, repeat it, and see all of those pixels as discrete elements, and see their colors on the screen as the colors intended. True, there are chroma artifacts between pixels, but those are a fraction of the overall pixel image we see, and as such can be factored in as a mere quality discussion, not some denial of pixel resolution. To add to this, the TV's we have today are far better at this than the ones most of us had in the day.

 

On an Atari computer, any pixels smaller than the 160 pixel resolution pixel size, will result in chroma artifacts. Therefore the Atari does not have 320 pixel color resolution. Those smaller pixels cannot be addressed in terms of their color, nor do they display anywhere as the same color.

 

The C64 is different in this. On that machine, and I would really like to understand exactly why this is, a color pixel at the 320 pixel size can be seen anywhere as that color pixel. At that smaller pixel size, the chroma artifacts are larger with respect to the individual pixels, but we the programmers can address the pixels as color pixels, and we can do that anywhere on the screen, subject to cell limits and such, of course.

 

The quality of TV does impact this more than it does at 160 pixels, but that's not really the discussion is it?

 

So then, the C64 has 320 pixel color resolution. ...and how it's signal is built, compared to the Atari one is a topic I am interested in, because I'm writing video driver code and when I use the Atari timings, I get the 160 pixels of color resolution and the same artifact behavior.

 

From where I stand, I recognize the analog limitations. However, I cannot deny what I am able to resolve and how it's addressed.

 

Also, if you factor out the color, leaving LUMA, both machines do have 320 pixel LUMA resolution.

 

Finally, if you overdrive the color resolution a bit, you get something like the TI, which had a 256 pixel display with timing similar to what the Atari 8 bit computer does. On that display, the color pixels are resolvable, but the extra artifacts are a significant fraction of the pixel size, meaning we are a lot closer to being able to say that machine, for example, does not have 256 pixel color resolution, because not every color combination is directly viewable everywhere on the display.

[Crazyace]

>>There's no side-effect in switching between Gr.9 <->Gr. 8 <->Gr. 11. Gr. 10 would cause one color clock delay. And sprite overlays can be replicated easily just like 53275 for switching priorities.

 

>This isn't as easy as just setting a bit in colour ram to select between 320 and 160 mode for each of the 40 characters. >Can you switch gr.8 -> gr.15 , and switch back 4 colour clocks later?

 

But Gr.15 and sprite overlays and GPRIOR based colors are at same resolution. It's better to move large sprites than toggle between Gr.15/Gr.8 (assuming Gr.15/Gr.8 switch was do-able).

 

I guess that's a no then....

[atariksi]

You are DEAD wrong that it doesn't matter whether timers are 1.77 or 0.985. They can't achieve the same thing. You are MIXING up doing horizontal splits on display to whether a timer accuracy makes a difference. We're not trying to hit a IRQ on a CPU cycle but on a NTSC cycle. Atari can trigger the IRQ every other NTSC cycle (3.58Mhz/2).

There are no such things as "NTSC cycles". The color carrier has a frequency, but it's NOT a digital clock. The monitor does NOT know about "pixels" at all.

...

Sorry, I have to disagree. Both Amiga and Atari have their CPUs synced up to NTSC frequencies although Amiga's CIA IRQ is not (not enough accuracy).

 

>>You need to stop arguing about timers as the argument is how accurate can we make a horizontal split using a timer.

 

>On typical A8 resolutions (40 byte/line) it's both the same: Every 8 pixels. Also it takes 0...7 cycles to actually start an IRQ on C64, and on A8 it will take 0...14 cycles due to every 2nd cycle lost -> ends up the same.

 

Again wrong. As I stated, the DMA cycles are uniform in Gr.8 so regardless at which cycle you issue STIMER strobe, that same DMA will exist in next scanline. And for frame timing, you can shut off screen before starting timer and it will be at 1.79Mhz accuracy.

 

>>But the point is what things you can do in 320*200 mode to get more colors.

 

>That might be a point on A8, but on C64 you simply don't need to do that.

 

Okay, so that trick is not worth doing on C64.

 

>>On Amiga, the CIA IRQ does NOT sync up to the NTSC cycles because they divided the CPU freq by 10 before feeding it into the CIA. So in one frame intr, it may occur on one pixel and the next frame it may be another pixel. It diverges away from exact pixel on the screen.

 

>Amiga can use Copper to set IRQ flags. Timer IRQs are not needed for that anyway. And I don't really see how this has anything to do with C64. When it comes to clock generating A8, C64 and other 8 bit computers work basically the same: All clocks derived from color carrier clock * 4.

 

I stated CIA IRQ not copper-based irq. Copper is another hardware aspect which Amiga > Atari since it can modify the registers for you without involving CPU. Also note that Copper triggered IRQs have to be aligned on 4 low-res pixels (3.58Mhz/4). IRQ triggering is not the same on C64 and A8.

 

>>I agree lumas can be done at 320 pixel accuracy.

 

>And chroma cannot be done in 160 pixel accuracy, it actually needs several color carrier cycles to move the circuit from one color or another. Also you can't really talk about "pixels" anyway. It's all analog and all you get is frequency ranges (which differ from output device to output device btw). I think a lot of A8 people have a heavy misconception of how video encoding and decoding works, mainly because some Atari books spread terms like "color clocks" and people had mistaken them being similar to CPU clocks, pixel clocks etc.

 

I don't think it matters how video is encoded as long as the irq occurs consistently on a given pixel.

[atariksi]

I am not mixing things up, but you can't apply char mode colors and still claim a horizontal split. How many colors can you get at 320*200 and have no bad DMA lines?

16 actually, with color cells as high as there are no badlines. But I still don't see why anyone would do that? I mean, color splits use all CPU time anyway, so why not use badlines which also use all CPU time but achieve much more colors?

...

It's one or the other on C64. On Atari you can do horizontal splits and not use all CPU time.

 

>>And after you answer that, tell me at which pixels you can cause an IRQ to occur consistently (every line and every frame, the horizontal position of pixel will be the same). I don't see how the 0.985Mhz timing accuracy is going to allow you to hit any pixel position consistently.

>You won't hit any pixel on A8 either, only every 8th (hires) pixel. Just like on C64. Don't know how often I have to repeat that until you read it. And since C64 doesn't take refresh cycles from CPU, it's even more accurate on the left side of the picture.

 

I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel.

[atariksi]

In the example, if you replicate 4 sprites horizontally @60Hz, you are restricted in the y-position and shape since there's not enough time to update Grafn AND HPOSes.

 

Which is a limitation compared to the C64 , as I originally stated.

...

But you can have more then 5 sprites/scanline at 60Hz which was one of the points. There are uses for sprites other than having all of them have different shapes, colors, and Y-positions.

 

>>VBlanking method would have to be used if you want to change shape and Y-axis and have 8 sprites on a scanline.

 

>Are you talking about multplexing sprites - I was thinking of 8 per line from a far greater number ( 30 or 40 ) , which is what you would need for a 'busy' sprite game

 

Sure you can have more than 8 per screen but having 9 per line is do-able as Joust does it.

 

 

But Joust doesn't do it - it flickers!

 

Circular reasoning. I already stated you can have 8+ sprites @60Hz horizontally with restrictions but VBLanking have to be used to avoid these restrictions. VBlanking method by definition means @30Hz.

[Crazyace]

Why would you need a horizontal split on the c64 - you can change modes via the colour ram ( and there's only 2 of them ) - and there aren't that many pallette registers?

[Crazyace]

but you haven't show 8+ sprites at 60hz ?

[atariksi]

Why would you need a horizontal split on the c64 - you can change modes via the colour ram ( and there's only 2 of them ) - and there aren't that many pallette registers?

 

See, you did not follow the argument from way back around post #1999, 2119, etc. We were discussing various hardware supported methods to do colors. Horizontal splitting is one atari method which is less accurate on C64 to do (if even worth doing). Palette registers are not the solely responsible for color content as Atari has some fixed palettes and OR effects.

[Tezz]

Here's an example of 26 players.

PAL 50Hz.

plex.zip

[peteym5]

Well Reading through certain points of this 88+ page thread now. Seems like it is geared more toward software released for the machines. We say it time and time again that most of Atari ML games run faster and smoother because it running at higher speed. Even with some DLIs and player/missile multiplexing routines, still runs quick. It does take a lot to bog down the A8 down to an equivalent speed as a Commodore 64. By that time it probably is running something that exceeds the # colors + sprites capable from theC64.

 

I know I made this comment about the Commodore corporation in general. With all the models they made, Pet, CBM, Vic-20, 64, 128, 16, 4+, Amiga, most of them used different CPU, video, and audio hardware. That in turn caused compatibility problems between each machine and I am not impressed with that. I am more impressed with Atari, Apple, and IBM compatibles being able to release new models that are able to run the prior models software (with the exceptions of A8s to STs, and IIs to Macs.) That probably confused and annoyed consumers and it was no wonder that the C16 and 4+ failed because the people who already owned a Commodore could not run their software on these different machines.

 

I understand this is probably comes from Jack Tremail because when he came over to Atari, the different models of ST, TT, Falcons, they could not run 100% of the software from prior models. Interesting that after Commodore had the Amiga, they were able to maintain compatibility with software for prior models. Of course there is a big compatibly with Apple, Atari, and Commodore jumping from a 6502 based computer to a 68000 based computer. That is more of the manufacturer of the 6502 (MOS) not taking up an interest of making a better processor. Somebody else did, Western Designs, 65816, but was too late. These corporations already invested in the 68000.

[emkay]

Here's an example of 26 players.

PAL 50Hz.

 

I don't give a cent for a player multiplexer that doesn't show any background graphics.

[Fröhn]

How can we not talk about pixels and resolution?

 

Agreed the analog signal is not well described in terms of pixels and such, but that is how we address it, is it not?

It's only adressed like that at the input, not at the output. Output works different: It outputs for example 7 pixel clock cycles with chroma phase shift X and luma Y, then next color. That's why you get a lot of "dirt" when chroma is switched because it's a heavy jump in a sinus curve which produces a hell lot of weirdo frequencies, some of them being in luma range, some of them in chroma range. This happens also for low resolutions like 80x192 if you choose differen chromas for the colors. The video encoding/decoding is simply not designed for "pixels", it's designed for smooth natural TV pictures where chromas fade smooth from one color to another while luma has a lot of detail.

 

I stated CIA IRQ not copper-based irq. Copper is another hardware aspect which Amiga > Atari since it can modify the registers for you without involving CPU. Also note that Copper triggered IRQs have to be aligned on 4 low-res pixels (3.58Mhz/4).

You came up with POKEY timer IRQs to have IRQs at exact screen positions. Copper IRQs just do that. It doesn't really matter if you use CIA, POKEY or Copper since it's the result what matters.

 

I don't think it matters how video is encoded as long as the irq occurs consistently on a given pixel.

Then I would please have an IRQ at the 3rd pixel in the topmost line please.

 

I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel.

Both on Atari and C64 you have to sync the CPU to the display. IRQs don't do that, they can only set an IRQ flag at a certain point of display, but the CPU needs a delay from 0...7 cycles to actually react to that flag because it has to end the current opcode first. All split examples on A8 I've seen use WSYNC to sync the CPU 100% to display AFTER the IRQ. And then either WSYNC every line or cycle counting. On C64 it's similar, just that you don't have WSYNC and need timers/double-IRQs/DMA-cut etc for syncing. Once the CPU is in sync which can be done ONE TIME in the beginning of the IRQ, it will stay in sync until the end of the IRQ. That's how those demos doing register splits work.

 

I can't believe that I still reply to this. There are thousands of demos on C64 which place STA's at hundreds of accurate positions on the display. Every demo opening sideborder does it, every demo doing color split bars does it, every demo splitting modes does it, every demo doing FLI-modes does it etc etc. In fact it's far more common to do it on C64 than it is on A8.