Atari v Commodore

[frogstar_robot]

actling like there's no difference between built in and cpu driven modes wont help. I can define the matter easily so that you cant escape: c64 can display a better picture without it's cpu touching any gfx chip regs without using "sprites" at all, than the a8 doing as hard as it can the opposite.

 

Largely a matter of opinion. I'll agree that C64 can display restricted 320H pictures with a higher color density than the A8 can do. But those restrictions often result in pictures I don't find very pleasing at all. Incidentally most of the C64 pix I do find pleasing employ some form of the dreaded hardware diddling or *gasp* aren't 320H. You C64 modes aren't the slamdunk you think they are. *Sometimes* they *are* better but not often enough to make want to throw my Atari gear out and replace it with Commodore gear.

 

indeed, now compare this graphics hardware to one which doesnt expects cpu help, and does still better ? no more comment needed.

 

The A8 has more CPU to do it with and one practical adjustable tradeoff is that lower-res/lower-color modes can be used to make more cycles available for animation or other logic. Ballblazer is a practical example as it is very colorful, fast, and buttery smooth and perhaps someone can name the exact demo but I once saw an animation of a low-res correctly colored rotating Rubik's Cube that solved itself.

 

The engineers of both systems had to make tradeoffs and balance factors to come up with practical and affordable designs. The two teams made very different decisions and *overall* I prefer the mix in the A8 but don't hold it a sin to prefer the C-64.

[jvas]

... I can define the matter easily so that you cant escape: c64 can display a better picture without it's cpu touching any gfx chip regs without using "sprites" at all, than the a8 doing as hard as it can the opposite.

Unfortunately I don't agree that the C64 can display better picture and you didn't convinced me so your statement means ..... : NOTHING

 

indeed, now compare this graphics hardware to one which doesnt expects cpu help, and does still better ? no more comment needed.

But I question that the C64 "does still better". This is what the discussion is about and you would like to end it by "declaring" the one is better.

[Heaven/TQA]

Powrooz has choosen this colours because he wanted to have these colours not because he was restricted in terms of fixed colours from the 16 palette... if we wanted to have purple background or tshirt then it is like it is... his choice.

 

..and if he wanted a blue sky he'd have a blue tshirt&blue tree, or if he wanted a red tshirt, he'd have a red sky & red tree, or if he wanted a brown tree he'd have a brown sky & brown tshirt.

 

sorry, we both know thats not the reason. it's simply a8's limitations. it's charmode, and I can easily tell the main character colors being: purple, white,black, gray and the most used green.

 

when you have 128 colors, the only thing makes you use 5 colors only on the majority of the picture (not to talk about purple is used to "enhance" greens) , is the limitations.

 

to judge yourself... go to g2f.atari8.info and download the full package...in the examples you might find the source files to proof your assumption.

[Wolfram]

Powrooz has choosen this colours because he wanted to have these colours not because he was restricted in terms of fixed colours from the 16 palette... if we wanted to have purple background or tshirt then it is like it is... his choice.

 

..and if he wanted a blue sky he'd have a blue tshirt&blue tree, or if he wanted a red tshirt, he'd have a red sky & red tree, or if he wanted a brown tree he'd have a brown sky & brown tshirt.

 

sorry, we both know thats not the reason. it's simply a8's limitations. it's charmode, and I can easily tell the main character colors being: purple, white,black, gray and the most used green.

 

when you have 128 colors, the only thing makes you use 5 colors only on the majority of the picture (not to talk about purple is used to "enhance" greens) , is the limitations.

 

okay, I was wrong. the tree&sky&tshirt uses different color. I have played a bit with replacing colors, the result is imho a much better picture. the original artist focused probably on showing off with the palette trying to be different to c64... but when you have 2-3-4 steps between black and white (yes even with 128 colors you dont have more.. ), and the steps between the colors are not even, the result will be not so nice, if you force many colors that are close in brightness... I have tried to fix this issue, and give the picture a better contrast ramp:

 

new:

 

old:

Edited April 17, 2009 by Wolfram

[Fröhn]

Fröhn...which hardware do you have?

 

http://www.go64.de/shop/index.php/cat/c4_C64-Hardware.html

I use an old Retro Replay + RR-Net + case and the newer MMC-Replay + RR-Net + case. I also own a 1541u, but hardly use it because the Ethernet stuff still needs a few fixes and most releases these days are single file anyway so I can simply transfer them over network anyway without the need for a 1541.

[+wood_jl]

-snip- RAH RAH RAH! -/snip- ...remember I want to play Hyper Sports and it's not on A8.... -snip- RAH RAH RAH! -/snip-

If you're so keen to play Hypersports in particular, then unless I'm mistaken a solid state card solution like the SD2IEC board for $45 should do the trick, considering Hypersports is just a single load game. Plus it apparently works with 300+ multi-load games. It's not a complete solution like the 1541 Ultimate, but perhaps it would meet your needs.

 

...you can attempt to attract attention and somehow feel better about themselves with such nonsense as "Mine sold more, and I was THERE back in 1985."

Actually, that "I was THERE" bullshit came from an Atari user.

 

 

Thanks. It's difficult to learn of these developments, if you're not already a C64 owner.

[youki]

To using the famous Atari Jaguar strapline

 

'Do the Math'

 

Atari 8bit....cpu at 1.79 or 1.77mhz

 

C64....cpu at sub 1 mhz (from what memory recalls)

Doing the math again: 1.77 vs 0.985 MHz doesn't mean that A8 is 80% faster. Since A8 steals a lot of DMA cycles from the CPU and the C64 doesn't, on a normal screenmode (160x200@4cols, 320x200@2cols) the A8 is only 20% faster than a C64. On the expanded pixel modes it's about 50% faster.

 

In addition the A800 has a 6502C and the C64 a 6510.

 

The 6502C is a custom 6502 done by MOS Technology specially for Atari in 1978.

 

The 6510 despite being based on the 6502 core , had been produced few year laters. in Addition to having a built in 8 bit IO port , his internal design has been more optimized than the prehistoric 6502C. In 3 years, the 6502 series have sligthty progressed .

 

Can i prove that? ... not at all... it is just to drop some oil on the fire! But i won't be suprised that a 1982 6510 will be sligthly faster than a 1978 6502 at the equal frequency.

[Barnacle boy]

how many games actually scroll the colour ram, too???

 

There are heaps of c64 games that scroll colour ram. Certainly far more than you might expect judging by your comments. Bear in mind too that you don't necessarily have to scroll a 40x20 colour tile map to add a nice amount of extra colour. SEUCK, for example, has the colour map arranged in tiles of 5x5 characters, but even that still offers a fair degree of flexibility when it comes to adding colour.

 

Anyway, here's a few games I could think of offhand that scroll the colour RAM, at least to some extent, complete with youtube links when available (unfortunately the video compression is pretty brutal on many of these vids).

 

turrican 2

turrican

Alien syndrome

katakis

rastan saga(not obvious on this level, more obvious on later levels.)

Enforcer

shinobi

Creatures

Ikari Warriors

Phobia

Operation Wolf

Atomic Robokid

<- Notice the 1 pixel high gap between the scrolling area and the score display. Obviously not impossible on the c64!

 

There are many many more. It's not some kind of rare feature that's hard to find in actual games. Plus, as wolfram pointed out, even without scrolling, the colour RAM comes in very handy for colourful flick-screeners.

 

ok... Fire up Schreckenstein... play it! it has 50 Hz overscan splitscreen and mixing gfx modes (the score panel f.e.). and no flickering of rasterlines nor many "empty scanlines" between to trigger "Rasterinterrupts". Ah...and of course overscan...

Split screen horizontal scrolling is no big deal on the c64. Split screen vertical scrolling is much trickier. And as you can see with Rolling Ronny above, it's possible to have a split without many "empty scanlines".

Edited April 17, 2009 by Barnacle boy

[potatohead]

Man! Not having a nice easy peripherial emulation really touched off a thread.

 

LOOK AT THAT COLOR MODE! COUNT 'EM 16!

 

NEVER MIND THAT YOU HAVE TO HAVE A 1541... PEOPLE ARE PROGRAMMING FOR THE STUFF WE DO HAVE.

 

AND LOOK AT THE COLORS ON THE SCREEN. THERE THEY ARE! ALL OF THEM!

 

AND SPRITES! MY GOD! THERE THEY ARE TOO!

 

I SEE IT RIGHT THERE ON MY TV!

 

8 BIT GAMING IS ABOUT SOME FUNKY PIXEL ART AND SPRITES! THAT IS WHAT MY MACHINE DOES AND IT'S THE SHIT.

 

HARDWARE MODES IS WHAT IT IS ALL ABOUT. VIC II GIVES HEAD TOO.

 

Never mind that there isn't a real disk drive replacement. SD card, IDE, and god knows what else connects on SIO, and older software can talk to it, via the handler system. Atari has great systems engineering in it's favor here.

 

BUT LOOK AT THE COLORS!

 

AND SPRITES!

 

AND DON'T FORGET SID.

 

AND SCREW NICE PEOPLE. WITH THE BIGGEST SCENE COMES THE BIGGEST EGOS. JUST LOOK AT HOW MANY PEOPLE HAVE SUCCESSFULLY CHOSEN THE 8 BIT COMPUTER! THE C 64! MORE GAMES. MORE PEOPLE. MORE OF EVERYTHING, CAN'T YOU SEE?

 

But I like Atari.

 

YOU FOOL! LOOK AT THE COLORS! AND THE SPRITES! MY GOD MAN!

 

You know the C64 is a great machine! I really like it. Many people do!

 

BUT YOU'VE GOT TO SAY IT! COME ON, SAY IT! C64 IS THE BEST. IF YOU DON'T SAY IT, I GET LIMP. SAY IT!

Edited April 17, 2009 by potatohead

[Barnacle boy]

-snip- RAH RAH RAH! -/snip- ...remember I want to play Hyper Sports and it's not on A8.... -snip- RAH RAH RAH! -/snip-

If you're so keen to play Hypersports in particular, then unless I'm mistaken a solid state card solution like the SD2IEC board for $45 should do the trick, considering Hypersports is just a single load game. Plus it apparently works with 300+ multi-load games. It's not a complete solution like the 1541 Ultimate, but perhaps it would meet your needs.

Thanks. It's difficult to learn of these developments, if you're not already a C64 owner.

Bear in mind I haven't used it myself, so I'd recommend seeking more info from other c64 users (frohn? wolfram?) before splashing out any cash. Maybe ask the friendly folks at lemon64 if any of them have used it.

[+warerat]

Man! Not having a nice easy peripherial emulation really touched off a thread.

 

LOOK AT THAT COLOR MODE! COUNT 'EM 16!

 

NEVER MIND THAT YOU HAVE TO HAVE A 1541... PEOPLE ARE PROGRAMMING FOR THE STUFF WE DO HAVE.

 

AND LOOK AT THE COLORS ON THE SCREEN. THERE THEY ARE! ALL OF THEM!

 

AND SPRITES! MY GOD! THERE THEY ARE TOO!

 

I SEE IT RIGHT THERE ON MY TV!

 

8 BIT GAMING IS ABOUT SOME FUNKY PIXEL ART AND SPRITES! THAT IS WHAT MY MACHINE DOES AND IT'S THE SHIT.

 

HARDWARE MODES IS WHAT IT IS ALL ABOUT. VIC II GIVES HEAD TOO.

 

I'm sold. I'm dumping all my awful primitive Atari 8-bit stuff for the graphical and musical genius that is the C64. How could have wasted all my time and money on Atari gear?

 

And the VIC-II gives great head and even kisses you when its done. Especially to the little-dick envy C64 fan-boys that just don't seem to get it- WE LIKE THE ATARI BETTER.

[frogstar_robot]

But i won't be suprised that a 1982 6510 will be sligthly faster than a 1978 6502 at the equal frequency.

 

I can find absolutely no evidence for that. Everything I have found says that the motivation for the design was to consolidate some memory and IO logic. Atari did a similar thing with the 6502C in the XL and XE series to eliminate additional circuitry that was necessary in the 400/800.

 

The 6502 isn't like modern Pentium and PowerPC chips where variations of the chip can accomplish more or less instructions per clock cycle. Everything I've found emphasizes opcode compatibility and the phrase "slightly modified" turns up over and over. There is no reason to believe either a stock 6502, 6502C, or 6510 running at the same clock have any significant differences from an assembly language point of view or in performance.

[thorfdbg]

In addition the A800 has a 6502C and the C64 a 6510.

 

The 6502C is a custom 6502 done by MOS Technology specially for Atari in 1978.

 

The 6510 despite being based on the 6502 core , had been produced few year laters. in Addition to having a built in 8 bit IO port , his internal design has been more optimized than the prehistoric 6502C. In 3 years, the 6502 series have sligthty progressed .

 

Can i prove that? ... not at all... it is just to drop some oil on the fire! But i won't be suprised that a 1982 6510 will be sligthly faster than a 1978 6502 at the equal frequency.

 

Nope, please look into the data sheets. The instruction timing of the 6510 hasn't changed a bit. Including its "ability" to execute undocumented opcodes.

 

So long,

Thomas

[oky2000]

c64 palette is like the ZX Spectrum pallette...

 

Few "ugly" c64 image with his "ugly" palette.

 

 

 

 

 

 

 

 

 

Finally... i think i like what is ugly!

 

 

It's this kind of "self lying".

 

"120" colours do not suite the C64's original graphics.

 

They put interlace in it, add some "probably PAL artefacts" , then press it through a graphics tool that is calculating it to one "fixed" image. Suggesting people more than the original really is.

 

Not true at all, and no different to the tricks used on the A8 just to try and get 4 colours per 4x8 pixel block @ 160x200 or try and make up for the lower technology player+missile Vs Sprites on the C64 etc using zero extra CPU time. We get the odd bit of flicker you get either scanlines or pixels the size of dinner plates

 

Anyway you can download a program that just takes a 320x200 bmp/jpeg and runs many different options on it to create pictures in different modes...just like Ham+ and Dynamic Hires by Newtek in Digiview on the Amiga improved the existing screen/colour resolutions per scan line it's nothing new at all. There is no PAL artefacting, it is simple interlacing...and on a 320x200 image on a TV it will only display at 30/25FPS anyway because ALL TVs use interlace to display a picture and do 60/50 FIELDS not frames per second. Each field is identical usually on 320x200 rez so you are just making use of what the TV is wasting every other scanline.

 

One program creates an actual executable .PRG you can run on a real C64 or a 100% accurate emulator to display them so I know they look great even on a real C64 on a real TV.

 

Here is a simple picture I really like of real life subjects

 

And the C64 Hires FLi program I was talking about is called Mixcol Hi Fli (Windows only) and it outputs a standard C64 executable you can load up.

 

These modes mean little on either system as you can't write an arcade game with them. As I said I am yet to see anything as impressive or colourful as Enforcer II level 2 or Mayhem in Monsterland or the electric guitar sound using SID waveforms on the game Wizball.

 

The 6510/6502 has very little bearing on the speed of either machine, it is specific differences between the DMA/IRQ blah blah and VIC-II versus Antic GTIA combo.

 

As for overscan Crest have written a demo with 50 pixel wide unexpanded sprites (so 100 pixels each in x-expand mode) AND have managed to get 9 sprites on the same scan line. All in the border....which is plenty enough for overscan images in the borders. Most games use sprites in the border too, it's a waste not to do that as the VIC-II is otherwise just wasting sprites/scanline if you don't there is no serious hit to the CPU. Demo is called Krestage III

 

(PS the C64 already has 2 hard disk interfaces using laptop IDE hard drives despite what somebody claimed before as it being an SIO only thing)

[atariksi]

You have been insulting me regarding using joystick I/O ever since you joined atariage. You did say Atari palette is subjective and that was one reason why I stated not to trust you since that's just such a simple truth...

 

 

yeah. whats up with the joystick I/O ? it turned out that c64's joyport is 8bit wide just like atari's. So when I say the liking of a palette is subjective, thats unfair ? its sure not an objective thing.

 

It's not 8bit on C64. Palette is not subjective. Obvious truths.

[potatohead]

Does that IDE interface load up ALL software?

[Barnacle boy]

There is no PAL artefacting, it is simple interlacing...and on a 320x200 image on a TV it will only display at 30/25FPS anyway because ALL TVs use interlace to display a picture and do 60/50 FIELDS not frames per second. Each field is identical usually on 320x200 rez so you are just making use of what the TV is wasting every other scanline.

Hmmm... I'm not sure if I'm reading you right, but interlaced images on the c64 aren't interlaced in the traditional PAL/NTSC sense. They're usually two separate MC images, offset horizontally by one hires pixel.

 

Also, because the image outputted from the Atari/c64/NES etc isn't interlaced, the two alternating fields are positioned directly on top of each other and so effectively function as two separate non-interlaced frames, which means they can display true 50/60 fps movement (depending on whether it's PAL or NTSC). What I'm getting at is that it's incorrect to say you are just making use of what the TV is wasting every other scanline. In fact you are literally animating between two discrete frames at 50/60 fps, which means you are going to get a certain amount of flicker, depending on the degree of difference between the two images/frames.

 

Interestingly enough, Rybags from this very forum was exploring a method to get a true interlaced image from the Atari. See here. It's pretty cool.

Edited April 17, 2009 by Barnacle boy

[potatohead]

PAL alternates the color phase every other line and uses the combination of both phases, over the course of a full frame to get it's color info.

 

A computer user can alternate their generated pixels to take advantage of this and generate artifact colors. This is how PAL artifacting works.

 

NTSC gets it's color info from each scan line, and accepts either an alternating color phase signal (that's the dot crawl you see on TV graphics, your DVD menu, C 64, etc...), or a fixed phase signal. (Atari, CoCo, VCS, others...)

 

Artifacting on NTSC involves placing small pixels to generate colors.

 

On the C64, color timing is interlaced to bring it to 320 pixel resolution. On Atari it's not, and that gives 160 pixel info. Artifacting on NTSC is possible on Atari because of this, where it isn't on C64.

 

Both machines can easily manupulate pixels to produce new colors on PAL.

 

A complete C64 frame is 1/30 of a second, due to the color interlace. Takes two scans of the tube to get the 320 pixel color resolution. There will be dot crawl because of this. Not a bad thing, it just is.

 

A complete Atari frame is 1/60 of a second as the color info does not change across frames. There is no dot crawl of any kind.

 

Object in motion will see minor shape artifacts on C64, depending on their speed and color contrast with other entities on the screen.

 

True interlace can happen both horizontally and vertically.

 

C64 does this in hardware as part of it's pixel generation. That's the 320 pixel color resolution. Atari horizontal interlace is difficult, and needs to be monochrome. (that's something I've got to finish a demo on)

 

Vertical interlace involves changing the scan line timing such that a half-scan delay happens somewhere in the blanking area. This is what Rybags is working on. Early results look good on that, BTW!

 

Vertical interlace delivers twice the vertical resolution, but does take a full frame to realize a complete image. Moving object may see tearing, depending on the speed at which they are moved on the screen. If the motion is latched to full frames, this tearing won't be seen.

 

Vertical interlace has essentially the same effect on both PAL and NTSC, in that twice as many vertical scan lines are drawn to the display.

 

It is true that C64 interlaced images are not real interlaced images. The color is interlaced across frames, but the pixel data is not.

 

(and IMHO, that's a good thing overall, just thought I would clear the whole interlace thing up.)

Edited April 17, 2009 by potatohead

[potatohead]

So then, the various disk drive emulations / replacement devices really don't act like the 1541 in all respects.

 

Why can't you C64 guys just say that and move on?

 

Clearly, this is an Atari strength in that disk emulations / replacement devices are simple to use, cheap and function with all software. Other I/O devices are the same, due to the device independent XIO system in the Atari OS.

 

Can't have it all guys!

[atariksi]

its about built in modes. you can forget the clown.

 

It sounds more like reframing the argument so that you have a strawman to beat the crap out of. The A8 chipset has no "graphics modes" it has line modes which are built into "graphics modes" as well as various ways individual modelines can be affected under anywhere from minimal to moderate CPU intervention which is exactly what Mr. Miner's team intended. It is expected by A8 developers that the graphics hardware will be directed.

 

And yes, quite usable and artful displays can be build with plenty of CPU time left over for other tasks. The rate at which the CPU runs, the DMA, interrupts, Display Lists and so-forth are all of an integrated piece. It is supposed to work that way and Atari devs are quite correct to think "WTH?" when tasked with such facetious argument.

 

 

actling like there's no difference between built in and cpu driven modes wont help. I can define the matter easily so that you cant escape: c64 can display a better picture without it's cpu touching any gfx chip regs without using "sprites" at all, than the a8 doing as hard as it can the opposite.

 

 

"It is expected by A8 developers that the graphics hardware will be directed."

 

indeed, now compare this graphics hardware to one which doesnt expects cpu help, and does still better ? no more comment needed.

 

All the DL-based graphics modes on Atari don't use CPU. All the sprites in GRAFn mode w/o using PMBase don't use CPU nor RAM and still the GPRIOR mode works, collisions work, and zooming works. In fact, they don't even use DMA cycles. All the horizontal and vertical scrolling is simply setting scroll registers or LMS pointers. You can repeat areas of graphics memory, zoom, etc. using a DL. All the GTIA modes don't use CPU. It's more flexible to have built-in features and be able to use CPU together.

[Wolfram]

So then, the various disk drive emulations / replacement devices really don't act like the 1541 in all respects.

 

Why can't you C64 guys just say that and move on?

 

Clearly, this is an Atari strength in that disk emulations / replacement devices are simple to use, cheap and function with all software. Other I/O devices are the same, due to the device independent XIO system in the Atari OS.

 

Can't have it all guys!

 

there are two disk drive emulations / replacements which does the job.

 

and clearly this is not the strength of the a8 drives, just sideeffects of its design and 1541's design 30 yrs later.

[Fröhn]

A complete C64 frame is 1/30 of a second, due to the color interlace. Takes two scans of the tube to get the 320 pixel color resolution. There will be dot crawl because of this. Not a bad thing, it just is.

C64 has 320x200 @ 60 Hz (50 Hz PAL).

 

It is true that C64 interlaced images are not real interlaced images. The color is interlaced across frames, but the pixel data is not.

On C64 interlace does indeed interlace the pixels. The C64 has the ability to scroll half a pixel in 160x200 resolution, so you scroll every 2nd frame by 0.5 pixels to get true (horizontal) interlace of pixels.

[Wolfram]

A complete C64 frame is 1/30 of a second, due to the color interlace. Takes two scans of the tube to get the 320 pixel color resolution. There will be dot crawl because of this. Not a bad thing, it just is.

...

 

It is true that C64 interlaced images are not real interlaced images. The color is interlaced across frames, but the pixel data is not.

 

 

1. cant imagine thats true. both machines draws up the full frame right on spot with the electron beam.

2. same goes for a8, except the new vertical technique mentioned.

[atariksi]

...

display a picture and do 60/50 FIELDS not frames per second. Each field is identical usually on 320x200 rez so you are just making use of what the TV is wasting every other scanline.

 

...

Wrong, it's not a wasted line. TV and computer interlace pictures flicker at 25/30Hz whereas they don't flicker at 50Hz/60Hz especially when color differences/shade differences are bigger which is more of the case on C64. You can't compare interlace pictures with non-interlaced ones; it's like comparing apples and oranges. By the way that picture you posted is dithered spatially as well.

[potatohead]

It is absolutely true the machine does 1/60 second motion. What I posted was about baseband composite NTSC displays, and I posted it to clarify how the systems display differs and to clarify interlace. A C64, running on a monitor that will accept a seperate chroma signal, does not exhibit the motion artifacts.

 

In order for the C64 to display all of it's 320 pixels in color, without artifacting on a composite display, a full NTSC frame must occur. This is just how NTSC works. And this is why C= provided the luma signal. (good move)

 

Users of the machine are completely free to change the display every frame. If these changes exceed 1/30 of a second, there will be some loss of detail in the image. The loss of detail occurs because of the color interlace.

 

If monochrome pixels are drawn to the screen, this does not occur, leaving the image detail complete at 1/60 second motion.

 

Again, my point was to clarify the differences between the two, in terms of how the display is generated, not to say the machine does 1/30 second motion.

 

 

Re: True interlace.

 

Real horizontal interlace on the machine would yield 640 pixels of detail.

 

Shifting the 160 mode pixels by half a pixel yields 320 pixels of information, with some overlap. That does not exceed the 320 pixel hardware resolution delivered in the first place. What you get with that technique is more color options, and that's good, but it's not really interlace.

 

If it were possible to shift a 320 mode pixel by half a pixel, then that would be new resolution detail.