Atari 8 Bit I/O Performance vs C64

[bbking67]

When I had my Atari, I always perceived the disk and tape I/O as being faster than my friends' C64s. Games and programs just seemed to load faster. I can remember waiting for the C64 to load stuff and it just went on and on and on. Then again, the Atari always had the audible cues that maybe made it seem faster... and of course the standard disks held less data. Same goes for tapes, though I don't recall tapes on the C64 one way or another. The Atari tapes seemed pretty slow...

 

I just finished listening to the David Small interview on Antic where he moaned about the drive speed being abysmal... well, was it? I mean compared to the other computers that mattered?

 

And I'm talking about standard drives here... not the various high speed upgrades for either system.

 

[Chilly Willy]

Apple 2 Disk 2 = 1500 baud. CBM 1541 = 2400 baud. Atari 810 = 19200 baud. Do the math!

Edited January 18, 2015 by Chilly Willy

[Rybags]

Stock drive speed on Atari is fairly quick compared to stock C64 - 1541 transfer supposedly about 300 bytes/second compared to about 1,900 for Atari though in the real world a stock Atari drive does about 1K per second.

 

Turbo loaders on the 1541 will in practically all cases be faster than Atari drives. But hardware enhancements to Atari drives typically increase transfer speed by 2, 3, 4x so will be comparable or better to 1541 turboloaders.

 

Advantage of turboloader on 1541 is it works with practically any drive at no cost or modification needed (aside from the ones which convert the drive to parallel IO).

Disadvantage of 1541 is that the user has to manually type in the load command. Most Atari software will autoboot which gives it a head start.

 

C64 tape speed - at stock it's supposedly 300 bits/second which is half Atari's rate although Atari uses stop/start bits, C64 doesn't (?) although it uses parity bits.

Atari penalised by using short blocks with 128 bytes payload, C64 penalised in that standard tape programs are saved twice, second copy used to correct errors found in the first.

 

C64 tape turbo loaders significantly increase it's speed to the point of being quicker in many cases than their stock 1541 disk drive.

Atari can also do turbo tape but software only solutions only provide small speed increase (probably 1/3rd at best) although hardware mods exist for Atari tape drives to provide significant increase.

 

 

Other systems like BBC, Apple II - their disk drives much quicker than stock Atari or C64, the reason being that the disk controller is inside the computer and the computer will usually directly control the drive rather than relying on a slow serial interface.

[Joey Z]

I don't know about this for sure, since I've never owned a C64, but I heard that there was a bug when commodore made something which meant the drives had to operate at a slower rate than the hardware was originally intended to support. As a result, disk was really slow compared to what it could have been. Perhaps the only advantage I can see to a C= disk system is that you wouldn't have to wait for DOS to load on bootup just to use the disk. I looked up this online after I typed it and apparently the bug was in the 6522 serial shift register feature. The bug made the feature unusable meaning that all the shifting out of data had to be implemented in software, resulting in a much slower interface than originally intended. Wikipedia says drives running stock software got about 300 bytes per second.

 

In addition to that, different drives had different speed capabilities even within a system family. I don't know how many drives the C= families had, but I'm sure there were ones made for the 64, the 128, and older drives for vic-20 and such that might work with the 'newer' systems. On the atari, the very early 810 boards lacked an analog data separator daughterboard and ran REALLY slow. I also think that they didn't do the sector interleave right at first and you could make a disk with no interleave. This mean the 810 could read sector 1, deal with the data, and by the time it goes to sector 2, the disk has spun by and it's already on sector 4. so you waited for the entire disk to spin around again, a time equal to about 1/5 of a second... then you could read sector 2. The same thing would happen with EVERY SECTOR YOU HAD TO READ. I think later drives corrected this issue though.

 

Anyway, I suppose the point of my comment is that you'd have to compare drives around the same introduction date rather than comparing, say, the commodore 1581 to the atari 810, two drives produced at least 5 years apart.

[Rybags]

A disk has to have sector interleave, all that is is the offset of sequential sectors physically.

 

The Atari drives spin at 280-300 rpm, so no stock drive will read more than a sector in a revolution. The only ones that can are the modified drives that allow entire track buffering, but still in any case the serial interface is a bottleneck. An entire track will be anything from about 1,300 - 4,600 bytes of data which in a best case (accelerated IO) scenario will take the same time to transmit as several disk revolutions anyway.

[Muzz73]

I was a Commodore guy before I was an Atari guy (at least as far as computers were concerned) and have owned more C=, Apple and Atari 8-bit machines than I even care to get into. I ran the games Drol, Karateka and one or two others for side-by-side comparison on loading times, animation and gameplay.

 

As far as load times on the games are concerned, my personal observations are: my 800XL/1050 was usually fastest, my 64C/1541C was always, BY FAR the slowest and my Apple IIe/Disk ][ was somewhere in the middle.

 

I even stuck an EPYX Fast Load cartridge in my 64C and my IIe was still faster at loading and saving. My 800XL was almost always noticeably faster than my IIe, and both smoked the Commodore even with the Fast Load.

[phaeron]

Atari SD disks are formatted with 9:1 interleave and will transfer at two sectors per revolution in normal conditions. It is very noticeable when read speed drops to one sector per rev. Last time I crunched the numbers, the best case for the standard SIO protocol was 156 degrees per sector, so with stock hardware this is probably the best that can be done as 8:1 is too tight.

 

The Apple II disk hardware was actually capable of very fast transfers, but like the C64 it was hobbled by poor software: the FMS within DOS 3 transferred one byte at a time. Under the hood, the low-level RWTS routines were a lot faster, and modified DOSes like Diversi-DOS as well as ProDOS could load at about two tracks per second (4K/track). I never had such a disk myself, but supposedly there were loaders with custom track formats that could load an entire 4.5KB track in a single rev, which I believe is much faster than either the Atari or C64 could achieve.

 

Atari had the fortune at least of not seriously botching either the hardware or the software: the hardware serial port worked, and DOS knew how to burst so the CPU wasted little time on large transfers doing anything other than receiving sector data. However, it's a shame they didn't leave in some way to upload code onto the 810, which looking at the firmware could have done at least ~26Kbaud.

[Rybags]

My calcs were a bit out... better than 1 per revolution. I found on my 1050 that you actually got a slight speed increase if you did sector reads in reverse order per track.

 

I didn't realise Apple II had slow IO by default, remember reading that their disk subsystem was one of the faster ones.

[bfollett]

My neighbor had the Commodore 1541 and it was soooo slow compared to the Atari. Also he found using the turbo loaders were problematic because they often wouldn't work with copy protected disks.

 

Bob

[bbking67]

Apparently the Atari test equipment could only test up to 19,200 baud, so they built the equipment to support that... of course later hardware mods went faster. Another tidbit from the Antic podcast (maybe Mark Russtad's interview)

 

I wonder why Dave Small thought it was so slow then? If it was faster than its contemporaries, it was a fast drive. I suppose he had access to other platforms outside of home computing that went faster.

 

The fact that 1541 went 2400 baud is shameful... I guess every C64 user had an Expyx Fast Load or some equivalent by the time it mattered.

Edited January 18, 2015 by bbking67

[Rybags]

19.2K makes sense in that regard or in regard that industry standards tended to be on those multiples of 300 - 2.4K, 4.8K, 9.6K, 19.2K.

 

In regard to what the hardware is capable of or what a 1 MHz peripheral could bit-bang through a PIA or RIOT port - sure, they could and probably should have gone higher.

 

But Atari were pretty cautious in those times as evidenced in the military RF shielding and such of the day.

Though even the industry in general was conservative in what speeds were theorised - I don't think the coax network cables of the day were much over 1 megabit around that time, and these days we pump multiples of that down crappy old phonelines at medium ranges.

[ricortes]

Apparently the Atari test equipment could only test up to 19,200 baud, so they built the equipment to support that... of course later hardware mods went faster. Another tidbit from the Antic podcast (maybe Mark Russtad's interview)

 

I wonder why Dave Small thought it was so slow then? If it was faster than its contemporaries, it was a fast drive. I suppose he had access to other platforms outside of home computing that went faster.

 

The fact that 1541 went 2400 baud is shameful... I guess every C64 user had an Expyx Fast Load or some equivalent by the time it mattered.

 

Parallel mounted disk controllers can about 10x the speed of the serial ones, at least at 19k BAUD. I think Bob did a 1450XL demo of Picture Show at a SLACC using the built in drives and it seemed to be as fast as a ramdisk. Been too long since I looked at 1450xl schematics but I seem to recall they used some 8051 type processor to handle the drives which probably helped offload some of the load. Mr. Small was probably comparing the drive speed to that of an [iBM, ST, Mac] which are all pretty quick. He probably had moved on to ST accelerators and Magic Sack by the time of the article.<?>

 

Now that serial speeds are up to ~128k BAUD<Shouldn't this actually be 112 with our clock divisor?> it is somewhat of a mute point. I just mean this from a doing something useful with the data standpoint. If you are loading a Picture Show type program, it doesn't make sense to load more then a frame every 1/60 of a second. Maybe with VBXE it would be important.

[+bob1200xl]

I think they use a CPU in the disk controllers because the 6502 can't keep up with the data stream directly from the drive. Interrupts and HALT gang up on you and you miss a data byte. Now, you have to wait for the sector to come back around under the head again - 200ms. This is where buffered devices, like IDE drives and CF cards, make things easy/useful.

 

Yes, 112K is about right...

 

Bob

[Lynxpro]

I was a Commodore guy before I was an Atari guy (at least as far as computers were concerned) and have owned more C=, Apple and Atari 8-bit machines than I even care to get into. I ran the games Drol, Karateka and one or two others for side-by-side comparison on loading times, animation and gameplay.

 

As far as load times on the games are concerned, my personal observations are: my 800XL/1050 was usually fastest, my 64C/1541C was always, BY FAR the slowest and my Apple IIe/Disk ][ was somewhere in the middle.

 

I even stuck an EPYX Fast Load cartridge in my 64C and my IIe was still faster at loading and saving. My 800XL was almost always noticeably faster than my IIe, and both smoked the Commodore even with the Fast Load.

 

Now I'm curious.

 

What about pitting an 800XL, 65XE, 130XE, or XEGS coupled with a 1050 or XF551 up against a C64C or C128 with a 1571 drive and a FastLoad cartridge...

 

Heck, what about with the modern SD adapters?

[Chilly Willy]

19.2K makes sense in that regard or in regard that industry standards tended to be on those multiples of 300 - 2.4K, 4.8K, 9.6K, 19.2K.

 

In regard to what the hardware is capable of or what a 1 MHz peripheral could bit-bang through a PIA or RIOT port - sure, they could and probably should have gone higher.

 

But Atari were pretty cautious in those times as evidenced in the military RF shielding and such of the day.

The FCC at the time were the cautious ones. Atari had those "buckets" of aluminum because that's what you needed to be FCC certified at the time. The instant the FCC relaxed the rules, Atari used cheaper/lighter enclosures.

 

I run my SD2SIO at 57.6. The next higher speed (115.2) doesn't work on my 65XE. Reading up on that, the serial on the Atari can be a little iffy on certain models at that rate because of clock delays. There are ways to fix it, but 57.6 is fine with me. It's three times faster than default, and the SD card means never worrying about interleave and the like.

[Bryan]

Apparently the Atari test equipment could only test up to 19,200 baud, so they built the equipment to support that... of course later hardware mods went faster. Another tidbit from the Antic podcast (maybe Mark Russtad's interview)

That might be the case, but 19200 also makes sense when you consider the nature of SIO. If you could afford it, you could have 7 or 8 devices connected and the data will get quite noisy. If SIO is fixed at a high value, then things stop working. Happy warp speed has problems with just a few devices.

[bbking67]

The FCC at the time were the cautious ones. Atari had those "buckets" of aluminum because that's what you needed to be FCC certified at the time. The instant the FCC relaxed the rules, Atari used cheaper/lighter enclosures.

 

I run my SD2SIO at 57.6. The next higher speed (115.2) doesn't work on my 65XE. Reading up on that, the serial on the Atari can be a little iffy on certain models at that rate because of clock delays. There are ways to fix it, but 57.6 is fine with me. It's three times faster than default, and the SD card means never worrying about interleave and the like.

You can probably reach the higher speeds if you remove some of the capacitors on your SIO port (they are sometimes referred to as "vampire" caps.) There is also a minor SIO mod you can do where you add a resistor.

 

http://sio2sd.gucio.pl/wiki/HighSpeed_en

 

The article claims 127K is possible.

[+Stephen]

You can probably reach the higher speeds if you remove some of the capacitors on your SIO port (they are sometimes referred to as "vampire" caps.) There is also a minor SIO mod you can do where you add a resistor.

 

http://sio2sd.gucio.pl/wiki/HighSpeed_en

 

The article claims 127K is possible.

127k is definitely possible. Here is a video of a single pass copy of 180kB disk via APE.

21 sec for 180K read = 8.57KB/sec

24 sec for 180K write = 7.5KB/sec

[JamesD]

Apple 2 Disk 2 = 1500 baud. CBM 1541 = 2400 baud. Atari 810 = 19200 baud. Do the math!

The Apple II tape interface is 1500 baud, not the disk drive.

 

The book "Beneath Apple ProDOS" says the Apple II disk can transfer data at 8K per second.

[+SpiceWare]

I don't know about this for sure, since I've never owned a C64, but I heard that there was a bug when commodore made something which meant the drives had to operate at a slower rate than the hardware was originally intended to support.

The bug was a problem with the Shift Register in the MOS 6522 VIA chip used in the VIC-20. Jim Butterfield talks about it here.

starting with the VIC-20 the serial bus was born. It was intended to be just as fast as the IEEE-488 it replaced. Technically, the idea was sound: the 6522 VIA chip has a "shift register" circuit that, if tickled with the right signals (data and clock) will cheerfully collect 8 bits of data without any help from the CPU. At that time, it would signal that it had a byte to be collected, and the processor would do so, using an automatic handshake built into the 6522 to trigger the next incoming byte. Things worked in a similar way outgoing from the computer, too. We early PET/CBM freaks knew, from playing music, that there was something wrong with the 6522's shift register: it interfered with other functions. The rule was: turn off the music before you start the tape! (The shift register was a popular sound generator). But the Commodore engineers, who only made the chip, didn't know this. Until they got into final checkout of the VIC-20. By this time, the VIC-20 board was in manufacture. A new chip could be designed in a few months (yes, the silicon guys had application notes about the problem, long since), but it was TOO LATE! A major software rewrite had to take place that changed the VIC-20 into a "bit-catcher" rather than a "character-catcher". It called for eight times as much work on the part of the CPU; and unlike the shift register plan, there was no timing/handshake slack time. The whole thing slowed down by a factor of approximately 5 to 6.

 

When the 64 came out, the problem VIA 6522 chip had been replaced by the CIA 6526. This did not have the shift register problem which had caused trouble on the VIC-20, and at that time it would have been possible to restore plan 1, a fast serial bus. Note that this would have called for a redesign of the 1540 disk drive, which also used a VIA. As best I can estimate - and an article in the IEEE Spectrum magazine supports this - the matter was discussed within Commodore, and it was decided that VIC-20 compatibility was more important than disk speed. Perhaps the prospect of a 1541 redesign was an important part of the decision, since current inventories needed to be taken into account. But to keep the Commodore 64 as a "bit-banger", a new problem arose. The higher-resolution screen of the 64 (as compared to the VIC-20) could not be supported without stopping the CPU every once in a while. To be exact: Every 8 screen raster lines (each line of text), the CPU had to be put into a WAIT condition for 42 microseconds, so as to allow the next line of screen text and color nybbles to be swept into the chip. (More time would be needed if sprites were being used). But the bits were coming in on the serial bus faster than that: a bit would come in about every 20 microseconds! So the poor CPU, frozen for longer than that, would miss some serial bits completely! Commodore's solution was to slow down the serial bus even more. That's why the VIC-20 has a faster serial bus than the 64, even though the 64 was capable, technically, of running many times faster. Fast disk finally came into its own with the Commodore 128.

[Drummerboy]

Sure in short. The Atari load times is more fast than Commodore 64. Commodore 128 with the C=1571, i think is too fast.

 

Thats the reason in C=64 exist too many Turbo Loaders.

 

The Atari 8Bit, have a autoboot load just like an Amiga. For me its the same concept.

[JamesD]

Just so you know, most Apple II games are based on DOS 3.3 which isn't very fast.

In a comparison of load times of the same program in the Apple II faq:

 

Std DOS 3.3**- 8.9 sec

DavidDOS- 2.8 sec

DiversiDOS- 2.9 sec

EsDOS- 2.3 sec

ProntoDOS v1- 3.0 sec

ProntoDOS v2- 3.0 sec

 

You will notice that all the custom/patched versions are about 3 times faster than DOS 3.3.

Most people that knew about them used custom a custom DOS. Beagle Brothers had a patch that was one of the most popular.

 

ProDOS was also fast but the faq didn't include it in the comparison.

Here is where I found the info.

http://www.faqs.org/faqs/apple2/faq/part6/

 

 

 

*Edit*

It's my understanding that part of the reason that DOS 3.3 is slow is it copies data multiple times as well as reading it.

I believe ProDOS does away with that.

Edited January 20, 2015 by JamesD

[Muzz73]

 

Now I'm curious.

 

What about pitting an 800XL, 65XE, 130XE, or XEGS coupled with a 1050 or XF551 up against a C64C or C128 with a 1571 drive and a FastLoad cartridge...

 

Heck, what about with the modern SD adapters?

 

I probably should have been clearer on this; my 800XL had a stock 1050 (four of them, actually) and it skunked the 64C no matter what. Many times as fast on its worst day.

 

Now, a C=128 with a 1571 in 128 mode would be interesting, since it has a burst mode that is supposed to be really fast, but I'd wager any A8 with any 5.25" drive would probably still beat it.

[Muzz73]

I remember reading somewhere that the cassette tape drive on a Tandy CoCo was faster than a 1541.

 

I don't know if it's true or not, but it wouldn't surprise me!

 

You know something that's kind of funny? I started on a C=64 with a datasette drive, so the 1541 was like a dream when I first got it!

[jhd]

I remember reading somewhere that the cassette tape drive on a Tandy CoCo was faster than a 1541.

 

I don't know if it's true or not, but it wouldn't surprise me!

 

A Coco tape drive normally ran at 1500 baud. It could be sped-up (slightly), but at the risk of data reliability.

Edited January 20, 2015 by jhd