classic battle atari 8bit vs commodore 64

[+davidcalgary29]

The players in what is generally known as the great home computer war were:

Apple II – the 800 pound gorilla. Dominated the US Market from release in the late 70s thought the early 1980s, largely though early entrenchment, but also because Apple, as thay always have, has a great instinct for knowing what the public will respond well to.

 

I'd agree that Apple did a great job marketing its computers to educational institutions and the non-gaming consumer, but did anyone else really want one? I can't recall ever being impressed with an Apple product before the latter-day Macs, and none of my friends had one (or wanted one). We all played pirated games on our school's Apples, and then searched for the better version of the game undoubtedly available on the C64, A8, or more rarely, the TI99 4/A.

 

Adam – The all in one wonder computer that was thought of as the only potentially successful latecomer to the computer wars that stood a fighting chance.

 

Wasn't the Aquarius also touted to be an-up-and-comer in the console wars?

Edited July 18, 2007 by davidcalgary29

[emkay]

You know both the commodore 64 and Atari 8 bit had similar resolutions, but have different ways of controlling colors. I am sure the C64 could display more onscreen colors with color mapping but was limited to 16 of them.

You can also have a lot of colors on Atari graphics, but within games this is very hard to do in a useful way. Crownland preview is doing that and looks pretty good at that.

 

Atari had 128 color pallette that was way ahead of its time, it was not until the Amiga was release in 1985.

The C16/C116/Plus4 had a 121 color palette in combination with color handling similar to C64.

 

 

Well... the bad thing is that the Plus 4 doesn't have sprites at all and the DMA stealing is rather high.

And, when the Plus 4 arrived the ATARI got 256 colours already.

 

Honestly I don't see any point in this debate over technology that are 25 years old.

It's fun and you learn a bit too.

 

If you are on the internet with your PC, you are at a superior machine.

Not in all aspects. NO Windows/Linux PC can do 100% smooth scrolling.

 

 

That's not true.... really. I guess you are talking about that people doesn't calculate the "real" frame to the syncing of the monitor.

[ijor]

Hmm, I don't see why a PC can't do fine smooth scrolling. Or are you talking about the limitations of "normal" PC Operating Systems not being real-time?

It's mainly the OS. You don't need realtime capability though, just an API which provides the right tools and enough free CPU time. I mean, if there is 90% free CPU time you SHOULD be able to do something 100% smooth. But with current OS'es you are not.

 

I don't know what you are talking about, or might be I don't understand what you are trying to say. Direct X provides the API since long ago. I was doing smooth scrolling back on Windows 95.

 

If by not 100% you mean that sometimes you might get a glitch, well you are right. That's precisely a realtime issue. Free CPU time might be 90%, but it's an average. If some driver blocks the CPU for too long (some drivers do that sometimes) then you might miss a frame. Let alone that in a modern PC, you might have a lot of free CPU time, but not enough free GPU time.

[Fröhn]

I don't know what you are talking about, or might be I don't understand what you are trying to say. Direct X provides the API since long ago. I was doing smooth scrolling back on Windows 95.

No it doesn't. You can do 99% smooth scrolling, but not 100%. Every now and then it will STILL jump, even though there is loads of CPU time free. DirectX only provides the possibility to wait for a vertical blank or to flip with a backbuffer and wait for vblank, however it does NOT say which vertical blank it will wait for. The next one? Perhaps... but not always.

 

If by not 100% you mean that sometimes you might get a glitch, well you are right. That's precisely a realtime issue.

Realtime is not needed as long as enough free CPU time is there to compensate. Look at AmigaOS, it can do 100% smooth scrolling without disabling the scheduler.

[ijor]

No it doesn't. You can do 99% smooth scrolling, but not 100%. Every now and then it will STILL jump, even though there is loads of CPU time free. DirectX only provides the possibility to wait for a vertical blank or to flip with a backbuffer and wait for vblank, however it does NOT say which vertical blank it will wait for. The next one? Perhaps... but not always.

 

If by not 100% you mean that sometimes you might get a glitch, well you are right. That's precisely a realtime issue.

Realtime is not needed as long as enough free CPU time is there to compensate. Look at AmigaOS, it can do 100% smooth scrolling without disabling the scheduler.

 

It is precisely a realtime issue. The API does say it will wait for the next vertical blank. What it cannot do is to guarantee that.

 

No free CPU time can compensate for the lack or realtime behavior. And of course that AmigaOS is much more realtime than Windows. Still if some Amiga low level task will block the CPU for a full frame, then nothing can help it. The difference is that you don't have nearly as many current processes, tasks and drivers on the Amiga as on the PC (and that possibly the Amiga OS is optimized for giving higher priority to the video).

 

Do you care if it will "jump everyone and then"? I don't, most people don't. That's why the system overall is not designed to guarantee a 100% timing behavior all the time. If you do care and you insist, then it is not that difficult to get as close to 100% as you want.

[sniperstorm]

The onlything I can say in the debate on what machine is better. Are these 2 words. ALTERNATE REALITY. If I need to get into it further I will.

[Fröhn]

It is precisely a realtime issue. The API does say it will wait for the next vertical blank. What it cannot do is to guarantee that.

No it doesn't in fact, most drivers implement the "wait for vblank" as a busy loop simply comparing vertical beam positions. This results in 100% CPU load even if your application is doing almost nothing (which PROVOKES conflicts with other tasks), and it will result in waiting for A vertical blank, not the next one.

 

No free CPU time can compensate for the lack or realtime behavior.

Ofcourse it can.

 

And of course that AmigaOS is much more realtime than Windows. Still if some Amiga low level task will block the CPU for a full frame, then nothing can help it.

On AmigaOS you can block the scheduler and have complete realtime capability, but you don't need to do that to have 100% smooth scrolling. You can do those 100% in the normal multitasking environment.

Edited July 18, 2007 by Fröhn

[emkay]

It is precisely a realtime issue. The API does say it will wait for the next vertical blank. What it cannot do is to guarantee that.

No it doesn't in fact, most drivers implement the "wait for vblank" as a busy loop simply comparing vertical beam positions. This results in 100% CPU load even if your application is doing almost nothing (which PROVOKES conflicts with other tasks), and it will result in waiting for A vertical blank, not the next one.

 

No free CPU time can compensate for the lack or realtime behavior.

Ofcourse it can.

.

 

ROTFL..... I cannot believe what I am reading here. Someone's blaming that the PC handles multiple threads and has to do some more important things first.

Well.. It's true that the PC during the 2000/XP period has problems with interrupt handling(some applications suffers by slow downs, stuttering). But it's always up to the coders of minimizing some interrupt issues.

With Vista the sound "problem" is solved, so almost everything runs without gaps.

Well... with standard Windows applications, there was no problem at all. With Vista it got even more stabilized for critical programs.

Actually, you can run "X" programs, the Harddisk is working (and so on) but a scrolling game keeps scrolling without any gaps.

 

...

[Impaler_26]

Do we really need another discussion which homecomputer was/is the best?

[+Random Terrain]

Do we really need another discussion which homecomputer was/is the best?

Yes we do and the answer is whichever computer you had back then.

 

I had a VIC-20, a C-64, and an Amiga 500 before I got a PC in 1999 and my favorite of those three was my VIC-20, so it was the best.

 

Too bad I sold it for food money.

[mos6507]

They had people proposing further upgrades for the 8-bit system. I think they could have made some simple enhancements to Antic/GTIA chipset to give it better graphics, like more Players (maybe 8 or 16 instead of 4), compress the overscan mode to fit the screen( maybe use 64 bytes instead of 48), maybe run at higher speed. But even when Atari was taken over, both companies invested in the 16-bit 68000 series computers.

 

I don't think the Tramiels had engineers good enough to take the GTIA/ANTIC schematics and add anything to it. I don't even think late-era Warners had the brain-trust either, which is why the 7800 is kind of a pseudo-Atari architecture, carrying over some concepts from the 2600/5200/8-bit and abandoning others. Based on what I've read, most of the Atari ST was off-the-shelf as well. More of an integration project than true R&D.

Edited July 18, 2007 by mos6507

[Bryan]

I don't think the Tramiels had engineers good enough to take the GTIA/ANTIC schematics and add anything to it. I don't even think late-era Warners had the brain-trust either, which is why the 7800 is kind of a pseudo-Atari architecture, carrying over some concepts from the 2600/5200/8-bit and abandoning others. Based on what I've read, most of the Atari ST was off-the-shelf as well. More of an integration project than true R&D.

 

Well, since this has turned into a general computing thread....

 

The ST was made in response to Jack losing the Amiga deal to Commodore. Suddenly you've got no product, so you write a minimal spec and whip something up as fast as you can (oh, and buy an OS while you're at it!). IMO, the Amiga was the only true next-gen machine since it bested existing designs in practically every way.

 

-Bry

[thomasholzer]

The Amiga was more an Atari than the ST ever was (Jay Miner (RIP)= VCS, A8, Amiga)

[Bryan]

Atari could have ruled the home computer market if they'd:

 

1. Set their sights on the casual hobbyist rather than Apple's high-end customers. The 800 wasn't really that easy to internally expand anyway (except for RAM).

 

2. Built a low cost 1-board model like the 800XL from the start. Of course, there were serious problems with this since the FCC had not yet relaxed RF emission standards. The 400 was still more complex than it needed to be, though.

 

3. Given away all the documentation from the start. Get people coding and you end up with a loyal user base and a healthy software library.

 

-Bry

[ijor]

No it doesn't in fact, most drivers implement the "wait for vblank" as a busy loop simply comparing vertical beam positions. This results in 100% CPU load even if your application is doing almost nothing (which PROVOKES conflicts with other tasks), and it will result in waiting for A vertical blank, not the next one.

 

Oh, I see where are you going. Yes, there are many crappy drivers. Many do that when they shouldn't (some have no choice because of lack of hardware support). In most cases there are ways to workaround. Under later DirectX you don't want to flip with Vsync. Even if it won't busy loop, it still won't return until vsync.

 

In the worst case, we started from a platform comparison, to an OS limitation, to an API limitation, and now to a driver issue...

 

No free CPU time can compensate for the lack or realtime behavior.

Ofcourse it can.

 

Really? So let's suppose you want to peform a tiny task every 10ms with a 250 us accuracy (not very far from actual real goals). No problem at all for the A8 or for (almost) any other vintage platform for that matter.

 

The goal is ridiculous easy for a modern PC (hardware wise). It would take a tiny percentage of CPU time. And it indeed would work most of the time under Windows. But it is enough for a high priority interrupt to block every second for 300us (a very realistic possibility), and then your original procedure will fail "every now and then". And (assuming everything else is idle) you still has plenty of free CPU time. This is exactly lack of realtime behavior.

[ijor]

Based on what I've read, most of the Atari ST was off-the-shelf as well. More of an integration project than true R&D.

 

The ST has several off-the-shelf components, notably the sound chip. But there is nothing off-the-shelf in the video subsystem.

[Fröhn]

Under later DirectX you don't want to flip with Vsync. Even if it won't busy loop, it still won't return until vsync.

Sometimes that's exactly what you want and need. And this case is: If you want smooth animations/scrolling.

 

Really? So let's suppose you want to peform a tiny task every 10ms with a 250 us accuracy (not very far from actual real goals). No problem at all for the A8 or for (almost) any other vintage platform for that matter.

 

The goal is ridiculous easy for a modern PC (hardware wise). It would take a tiny percentage of CPU time. And it indeed would work most of the time under Windows. But it is enough for a high priority interrupt to block every second for 300us (a very realistic possibility), and then your original procedure will fail "every now and then". And (assuming everything else is idle) you still has plenty of free CPU time. This is exactly lack of realtime behavior.

That's exactly what I am talking: It works MOST of the time but not ALL the time. Even if you have made a set of precautions like not running other CPU/GPU intensive programs, it is still impossible to make something 100% smooth. And that should not be! When there is no frigging reason to have jerky animations, the animations should be smooth.

[Gury]

The Amiga was more an Atari than the ST ever was (Jay Miner (RIP)= VCS, A8, Amiga)

I agree with that. One off-topic question. I know Amiga 500 was best selling machine of the line. Amiga 2000 had more RAM, separate casing and detachable keyboard. Are these two machines 100% compatible? (Workbench, software) If I ever go for Amiga, I will probably choose Amiga 500, but I want to know if Amiga 2000 would be also good choice.

[+Philsan]

One off-topic question. I know Amiga 500 was best selling machine of the line. Amiga 2000 had more RAM, separate casing and detachable keyboard. Are these two machines 100% compatible? (Workbench, software) If I ever go for Amiga, I will probably choose Amiga 500, but I want to know if Amiga 2000 would be also good choice.

Amiga 500 and 2000 are 100% compatible.

But if you want an Amiga I suggest to take a 1200; it is near 100% compatible, has better graphics (AGA) and OSs (3.1, 3.5, 3.9), a faster processor (68020), you can upgrade processor and expand memory, with OS 3.9 you can surf the web even wireless using the pcmcia port, you can mount an hard disk internally (I use a compact flash with a ide/cf adapter), etc.

Edited July 19, 2007 by Philsan

[Rybags]

Are you sure on the 100% with Amiga 500 and higher models?

 

Lots of 68000 programs have problems because they use the "spare" 8 bits of pointers to store other things. All fair enough with 24 bit addressing, but no good for the higher processors with 32 bit addresses.

[Heaven/TQA]

but my a1200 had a boot menu to run in a more "compatible" mode and there are some tools to run the stuff...

[+Philsan]

Are you sure on the 100% with Amiga 500 and higher models?

 

Lots of 68000 programs have problems because they use the "spare" 8 bits of pointers to store other things. All fair enough with 24 bit addressing, but no good for the higher processors with 32 bit addresses.

 

Amiga 500 (OS 1.3) and 2000 (OS 1.3) are 100% compatible.

On the newer models, 600, 3000, 1200 and 4000, some programs (in particular games that use "forbidden features") have problems because the OS and the cpu changes.

What I want to say is that *now* an Amiga 1200 with only a memory expansion, an hard disk/cf card and a program called WHDLOAD can load all Amiga games.

In my experience for the serious programs there are no problems because most of them have been updated.

Edited July 19, 2007 by Philsan

[+Philsan]

I've just received, from ebay, two t-shirts that clearly show my preferred 8-bit!

[FastRobPlus]

I've just received, from ebay, two t-shirts that clearly show my preferred 8-bit!

 

OMG a shirt for conjoined twins one that likes Atari and one that likes Commodore. Imagine that sibling rivalry. This could be the ultimate version of hell!

[ijor]

Under later DirectX you don't want to flip with Vsync. Even if it won't busy loop, it still won't return until vsync.

Sometimes that's exactly what you want and need. And this case is: If you want smooth animations/scrolling.

 

Fröhn, it seems to me that you have some misunderstanding about the flip semantics in DirectX. Note that Ms infinite wisdom changed the defaults across versions.

 

But you have two different sets of parameters and flags. You can ask when the flip will be performed in the hardware (now, next frame, in 2, 3, or 4 frames). And you can ask when the call will return control to you (now, or after the hardware performed the flip); in other words, sync or async.

 

Some crappy drivers might not follow exactly, and some cards are unable to implement all the options. But disregarding driver issues and hardware limitations, what you want is an async call.