Atari Vs C64 --- 80s Computer scene etc chat...

[+wood_jl]

That cutthroat IKEA approach is great when there is untapped market to conquer. In a mature market, there is an expectation of quality and an expectation of parity with competitive systems. That is what just he didn't seem to get at all. For a number of years, the most popular upgrade for the ST was a set of keyboard stiffening springs while Amiga owners had all sorts of cool funky stuff to buy. Tramiel just kept selling the same increasingly stale wine in the same bottles with different stickers.

 

Bravo. I knew this was the case but have never seen it put into words this well.

[+wood_jl]

There's lots of technical discussion comparing sprites, etc. in this thread. I played mostly A8 games but was surprised the first time I played friend's C64 that it was "as good as mine" in many respects.

 

I seems a moot point to argue the point which was "better" in graphics, considering how primative both machines are by today's standards; any non-8-bit enthusiast spoiled on modern hardware would find the primitive displays of both machines suck equally. In reality, they both played a great game.

 

What bothered me much more about the C64 (than colors ever could) were the crappy floppy drives.

I believe they ran at a sloth-like 300 characters per second/2400 bps or something like that. Also, Atari Basic seemed more user friendly (a bigger deal in those days, obviously). I should think these things matter more, and it seems inexcusable that the C64 wasn't superior in every way being years later in introduction.

[Rybags]

The C-64 floppy drive in itself isn't at fault.

 

The fault is within the C-64 OS, and also I believe there was some design error in implementing the CIA to do the I/O, so it had to be done in software instead.

 

Look at some of the turbo-loaders out there. I think it might have been Armalyte (cracked) - it loaded in seconds, and did I/O at a rate of nearly a track per second. Probably faster even than the best 1050 upgrade.

[frogstar_robot]

I seems a moot point to argue the point which was "better" in graphics, considering how primative both machines are by today's standards; any non-8-bit enthusiast spoiled on modern hardware would find the primitive displays of both machines suck equally. In reality, they both played a great game.

 

Agreed but it is fun to pick over the fun points as long as nobody takes anything personally. It is a geek affliction to see his technological choices as evidence of his good taste. I think that fuels some of the more acrimonious geek debates.

 

What bothered me much more about the C64 (than colors ever could) were the crappy floppy drives.

I believe they ran at a sloth-like 300 characters per second/2400 bps or something like that.

 

Fastloaders both coded in later games and third party carts at first helped a lot. I don't remember the full story but I believe the default 1541 code was detuned purposely.

 

Also, Atari Basic seemed more user friendly (a bigger deal in those days, obviously). I should think these things matter more, and it seems inexcusable that the C64 wasn't superior in every way being years later in introduction.

 

Ah! But they didn't have the great Jay Miner and his design team until the Amiga (which is the true 16-bit successor to the A8. Engineering wise if not company wise. It is an irony that is also true of the C64 to ST).

 

I dunno. I always liked the different text colors on the C-64. It is actually a somewhat advanced bit of programming to make an A8 do textwise what any inquisitive kid can do on the C-64 at power on. In either case, I think that made little difference. I typed many the program in "on faith" so to speak on both my 800XL and a buddy's C64.

Edited April 23, 2008 by frogstar_robot

[Heaven/TQA]

it's interesting that i have a ST as well... and the "tricks" of demos are kind of similar to the VIC2 tricks... code for stable rasters, open borders (first bottom, then right, then all 4, sync scrolling etc)...

 

Allas, have not any NES at home but I would guess that the NES is more for gaming than the c64...why? simply it was made for gaming... and pure gaming...

[Rybags]

The NES has some distinct disadvantages:

- only 256 pixels across

- inferior sound system

- being a Nintendo. Their systems have always struck me as "kiddies games".

[emkay]

Fastloaders both coded in later games and third party carts at first helped a lot. I don't remember the full story but I believe the default 1541 code was detuned purposely.

 

It's compareable with cars: When the manufacturer realizes his machine cannot do 7000 rpm constantly, it gets a reduce to 5500 rpm.

Some machine are built better, so they run at 7000 rpm when someone removes the "break". Others burn out by the high rotation speed.

 

Same with electronics. If Commodore was sure about the functionality of their electronic chips, the C64 would have got higher transfer speeds by default.

[Rybags]

I think it's more a case of laziness.

Commodore barely changed the OS from the PETs of the late 1970s through to the '64.

 

At least with the 128, they bothered to give it a half-decent built-in version of BASIC.

[TMR]

@ all c64 users from AtariAge:

 

What machine do you think is better by hardware: C64 or NES ?

 

Well, the NES has more colours and a higher colour depth despite it's standard mode being a bit lower res horizontally than the C64; being able to do that ring-buffered scrolling stuff is pretty cool too (one thing i wish the C64 could do a bit easier, VSP or AGSP routines help loads but having it in hardware so y'don't have to stop the sprites leaving through the top of the play area would've been nice) but i'm really not keen on how you have to get data to and from the PPU through a couple of registers, it's a serious bottleneck. The NES sprites are weaker than the C64 too, s'got 64 sprites that can either be 8x8 or 8x16 pixels but the same eight-on-a-scanline limit as the C64 so that's only 64 pixels across max on the one scanline, a quarter of the screen. Granted, a decent-sized object need only be sixteen pixels across but that's still only four objects a scanline before things start disappearing...

 

Sonically... well, as a C64 user i believe i'm contractually obliged to mention the SID at this point, really. =-)

[TMR]

I think it's more a case of laziness.

 

No, frogstar is right (i assume that's a first name? =-) the C64's serial transfer speed was deliberately dialled down to retain backward compatibility with the VIC 20 and it's peripherals; they could've started from scratch but it's more sensible to have an upgrade path for existing users, VIC owners could simply disconnect the machine and drop a C64 into the middle of it's nest of devices, it makes it look a cheaper solution than a total upgrade and i suspect the reason why the C16 and Plus/4, which come fitted with a searingly fast parallel connection for the 1551 drive, both still have an IEC serial port and can talk to a 1541 as well.

 

Commodore also seemed to have a bit of a thing about data integrity, the tape system is slow and verifies everything from a second copy to make sure it doesn't make mistakes and whenever they used a third party tape loader like Novaload they'd switch it back to a very low speed.

 

Commodore barely changed the OS from the PETs of the late 1970s through to the '64.

 

Well, if it ain't broke... let the third parties write fastloaders to make it go quicker. =-)

[Fröhn]

Same with electronics. If Commodore was sure about the functionality of their electronic chips, the C64 would have got higher transfer speeds by default.

No the protocol is slow because:

 

- it's extremely complicated

- it's doing a hell lot of unneccessary handshaking

- it transfers every byte on it's own and not entire sectors, so for every byte you need to sync 1541 with C64 again

- it's all written in software with a lot of subroutine jumping for "setting a bit" etc

 

It's not the electronics faults, it's strictly the OS'es fault. The electronics can easily do 125 kHz bit transfer (the maximum you can do in software) without a single bit failure for days. People have been using 10x - 20x fastloaders since 1985 without problems.

 

EDIT:

 

What TMR said: It was even slowed down for C64 again, but it was very slow on VIC20 already. The difference was: On VIC20 with only 3.5k free memory, the speed was not an issue since not much data needed to be transferred anyway.

Edited April 23, 2008 by Fröhn

[Oswald]

The C-64 floppy drive in itself isn't at fault.

 

The fault is within the C-64 OS, and also I believe there was some design error in implementing the CIA to do the I/O, so it had to be done in software instead.

 

both and even more

 

on the edge (book about c= history, engineers themselves interviewed, etc) tells three stories:

 

a) the CIA chips were faulty, so all the handshaking and shifting bits one by one had to done by software instead of lightning fast chip hw

a2) it coud have been fixed, but how would they have told the users that the early machines load slow, and the later ones faster, so they decided to leave it so. c64 sold like a fortune anyway.

b) there were some lines on the first 1541's motherboard for parallel transfer, but in the plant one engineer optimized them off

c) Jack Tramiel was angry because why the 1541<->c64 thing got delayed, so called Bob Russel (software) into his office and told him that he wants to see the thing working in 3 days on his desk. So Bob made it working as fast he could, and as sure he could make it will work, and that made it quite slow

 

c64's SID and VICII was designed from january till early november, and then came the decision to build a home computer around it. The prototype was ready by the end of december (!! )

Edited April 23, 2008 by Oswald

[emkay]

It's not the electronics faults, it's strictly the OS'es fault. The electronics can easily do 125 kHz bit transfer (the maximum you can do in software) without a single bit failure for days. People have been using 10x - 20x fastloaders since 1985 without problems.

 

 

Since no one can really proof history, you can tell all you want, trying someone to believe it or not

 

Fact: Big C did all necessary to push their Product. But the biggest problem-> the low data transfer <- they never could handle any better? Making the slow machine more suitable for business usage by doing really nothing but change the code?

Good Lord...

The only assumption here is that they have seen problems during the development of the hardware. So they used the "handshake" methode to assure either the communication or the stability of the chipset.

Have a look at the manifold defective C64s in the first time. Possibly caused by fastloaders... , you know at least in Germany the customers had 6 months of free service, so the machine must guarantee to live out for that time... or even longer.

No Hardware distributor lives from exchanging defective hardware ...

 

Possibly, the C64s that outlived until today could all hande fastloaders , because the ones who couldn't hanlde it, died in the 80s already.

[Oswald]

Fastloaders both coded in later games and third party carts at first helped a lot. I don't remember the full story but I believe the default 1541 code was detuned purposely.

 

It's compareable with cars: When the manufacturer realizes his machine cannot do 7000 rpm constantly, it gets a reduce to 5500 rpm.

Some machine are built better, so they run at 7000 rpm when someone removes the "break". Others burn out by the high rotation speed.

 

Same with electronics. If Commodore was sure about the functionality of their electronic chips, the C64 would have got higher transfer speeds by default.

 

 

no emkay. its your ammazingly stupid bullshit again which is only about how to kick the c64. read my post about above.

[emkay]

both and even more

 

on the edge (book about c= history, engineers themselves interviewed, etc) tells three stories:

 

a) the CIA chips were faulty, so all the handshaking and shifting bits one by one had to done by software instead of lightning fast chip hw

a2) it coud have been fixed, but how would they have told the users that the early machines load slow, and the later ones faster, so they decided to leave it so. c64 sold like a fortune anyway.

b) there were some lines on the first 1541's motherboard for parallel transfer, but in the plant one engineer optimized them off

 

Sounds realistic.

 

c64's SID and VICII was designed from january till early november, and then came the decision to build a home computer around it. The prototype was ready by the end of december (!! )

 

 

Well, changing&enhancing some available resources is always faster than to build something completely new.

[emkay]

no emkay. its your ammazingly stupid bullshit again which is only about how to kick the c64. read my post about above.

 

Amazingly stupid is what C64 guys sometimes let out. Particular when argueing through their small window of technical achievement...

[Rybags]

Look at the 1050 disassembly - it is also done nearly 100% in software, and with a rather cripplingly small amount of RAM too.

 

But, I guess without the flexibility of POKEY, the Atari would have had the same problem re disk loading speeds.

 

Not much contest with tape - I think even with it's dual-redundancy, the C-64 default tape load is still faster.

[Oswald]

about the NES:

 

I have met one in the late nineties _not_having_heard_of_it_before_at_all_ (in hungary we had c64s for gaming, period. it was c64land) it only had a mario cartridge. and my thoughts was: what is this shit. primitive sound, ugly gfx, etc, this could be the oh so great console mario first ran on? crap. I like giana more.

 

NES gets the upper hand in Nr of Colors, and Resolution (256 vs 160 pixels) tho.

[Oswald]

Since no one can really proof history, you can tell all you want, trying someone to believe it or not

 

since the c64/1541 engineers are still alive you can decide to believe them or not

 

Fact: Big C did all necessary to push their Product. But the biggest problem-> the low data transfer <- they never could handle any better? Making the slow machine more suitable for business usage by doing really nothing but change the code?

 

Fact: c64 never targeted the business market. the opposite: it was the first computer to be sold in shopping malls. Business computers were the pricey bloated shitty IBM and Apple, already in those early times.

 

Good Lord...

 

Good Lord indeed. with so many bullshit from you, you could have gotten a fact right by mistake, but you even fail in that

 

The only assumption here is that they have seen problems during the development of the hardware. So they used the "handshake" methode to assure either the communication or the stability of the chipset.

 

Good Lord , SIO uses handshakes aswell. thats because the atari chips are faulty/unstable mr einstein?

 

Have a look at the manifold defective C64s in the first time. Possibly caused by fastloaders...

 

:-o :rolling: no comment :-o :lol:

 

 

Possibly, the C64s that outlived until today could all hande fastloaders , because the ones who couldn't hanlde it, died in the 80s already.

 

possibly. the only question remains: how dares one talk about c64 and hardware whithout not even knowing what are handshakes for, and thinking that fastloaders killed c64s :-o :-o

[Oswald]

no emkay. its your ammazingly stupid bullshit again which is only about how to kick the c64. read my post about above.

 

Amazingly stupid is what C64 guys sometimes let out. Particular when argueing through their small window of technical achievement...

 

porting over amiga's Desert Dream to c64 is enough technical achievement for you? check it on youtube. and what have you done mr ? you cant even get basic atari 8 bit facts right, which is your beloved machine. I have seen you turned down by heaven not twice, not three times... that is your technical achievement.

[+Philsan]

no emkay. its your ammazingly stupid bullshit again which is only about how to kick the c64. read my post about above.

Can you try to be more polite?

I agree with many things you have written (I have read "On the edge"), but normally in this forum we try to have good manners toward others.

[Oswald]

no emkay. its your ammazingly stupid bullshit again which is only about how to kick the c64. read my post about above.

Can you try to be more polite?

I agree with many things you have written (I have read "On the edge"), but normally in this forum we try to have good manners toward others.

 

yeah you are right. excuse me dear emkay.

[atariksi]

There's lots of technical discussion comparing sprites, etc. in this thread. I played mostly A8 games but was surprised the first time I played friend's C64 that it was "as good as mine" in many respects.

 

I seems a moot point to argue the point which was "better" in graphics, considering how primative both machines are by today's standards; any non-8-bit enthusiast spoiled on modern hardware would find the primitive displays of both machines suck equally. In reality, they both played a great game.

...

Unless you were writing a real-time system targetted to an NTSC/PAL system then Amiga/Atari may just fit the bill. How do you write to the overscan area on the PC or time things with the OS hogging up most of the resources and watching all your I/Os?

[atariksi]

Actually couple of words got left out. C64 optimized games that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. I.e., if you use the hardware resources of the Atari, you will have a hard time porting it to C64. Obviously, if you just write simple BASIC programs or ML programs, they can be easily converted one platform to another.

>Hmm there are a lot of A8 -> C64 conversion which are 1:1. Boulder Dash, Bruce Lee etc etc. Especially in the early 80s many games were ported over. Typical sprite based games port over pretty easily from A8 to C64.

 

>Counterexamples would be the Lucasfilm games where clearly the A8 versions are the best, but those are not sprite based.

 

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

 

>Concerning CPU speed: The speed difference between A8 and C64 is not as big as the MHz numbers might suggest. C64 uses a 1.97 MHz bus system where every 2nd cycle is used by the CPU, every other cycle is used by the VIC2 for bitmap data fetch, DRAM refresh and some sprite DMA cycles...

 

The FACT is that the higher CPU speed is available to the user on the Atari if he wants to use it. You can write code on latest PC polling keystrokes via IN AL,64H or similar method but it slows down your PC to around 1 Mhz, but once again the way one goes about coding the program determines how efficiently one uses the resources available to him.

 

>Now back to sprite multiplexing: I guess you have not understood just HOW simple multiplexing sprites on C64 is. All you need to do is this: Setup raster IRQ below a sprite, change sprite Y-position there. Done.

 

Okay, it is simple but an Atari coder would use and design according to what's available rather than try to get 24*21 sprites.

 

>Yes you can do it, but 8 sprites multiplied with 8 pixels is 64 pixels. Only 3 of the 8 C64 sprites already have more than that: 72 pixels. All sprites together cover a horizontal zone of 192 pixels. Some demos use this to produce a 2nd graphic layer on top of the normal bitmap for new graphic modes or (like in the case of Lemmings) a gfx layer only for bobs.

 

You can cover the screen with sprites on Atari as well by quadrupling the sprite size but why bother-- they are mostly needed for fast moving objects since there are more than enough graphics modes on the Atari that can be updated fast.

 

PMBASE is also like a sprite pointer

>One pointer for all PMs, but on C64 you have 8 pointers, one for each of the 8 sprites.

 

That can have advantages like in sprite multiplexing.

[atariksi]

Same with electronics. If Commodore was sure about the functionality of their electronic chips, the C64 would have got higher transfer speeds by default.

No the protocol is slow because:

 

- it's extremely complicated

- it's doing a hell lot of unneccessary handshaking

- it transfers every byte on it's own and not entire sectors, so for every byte you need to sync 1541 with C64 again

- it's all written in software with a lot of subroutine jumping for "setting a bit" etc

 

It's not the electronics faults, it's strictly the OS'es fault. The electronics can easily do 125 kHz bit transfer (the maximum you can do in software) without a single bit failure for days. People have been using 10x - 20x fastloaders since 1985 without problems.

 

EDIT:

 

What TMR said: It was even slowed down for C64 again, but it was very slow on VIC20 already. The difference was: On VIC20 with only 3.5k free memory, the speed was not an issue since not much data needed to be transferred anyway.

 

Do the 1541, 1571 boot up or does one always have to write the LOAD "*',8,1 or something similar? I'm not trying to find fault-- just for comparison as I have an atari behind my PC and never touch it-- just power it on and the PC controls the disks/keyboard/joystick/etc. but that requires that it boot directly into my application. I'd be interested in the smallest possible boot sector that I can transmit to a C64 so I can control it from a PC.