How fast can the Amiga read a floppy?

[oRBIT]

I'm just a bit curious, how fast could the Amiga read a floppy, assuming we bypass the filesystem? As far as I remember, X-copy read like 1 track / second (or something similar), but is it possible to go faster (with minimum error-detection/correction)?
I've no experience writing custom trackloaders but I'm just curious..

[ross]

Originally Posted by oRBIT

I'm just a bit curious, how fast could the Amiga read a floppy, assuming we bypass the filesystem? As far as I remember, X-copy read like 1 track / second (or something similar), but is it possible to go faster (with minimum error-detection/correction)?
I've no experience writing custom trackloaders but I'm just curious..

Some raw data, but consider that everything depends on the Amiga base clock, so they are slightly approximated.

A bitcell in a DD floppy is 2us and there are 5 disk rotations/sec (300 rpm).
So theoretically you can read 100000 cells/rotation (actually Amiga can do a little better than this).
In a standard MFM encoding 2 cells are required for 1 bit of data, so 100000/2/8=6250 raw bytes per track.
For a raw speed of 6250*5=31250kB/s -> 30.5Kib/s

Off course there are sector headers, checksums, gaps, syncs and times lost for settle and head movement, so values are a little "worse".
I would say that with commitment you can also reach a real 25KiB/s speed (with 11*512bytes sectors/track).

So with a good loader and a complete 160-track disk reading (880 KiB), this is something like a time of ~35 secs
(much much more that a 1 track/second)

EDIT: just checked X-Copy and got 37secs for a full disk read so I was a bit optimistic
I should try a version of my loader designed only for maximum speed, maybe a day..

[zipper]

I remember D-Copy (PD copier) was clearly faster than OS. And my A500 with Supraturbo 28 was clearly faster than plain A500.

[ross]

Originally Posted by zipper

I remember D-Copy (PD copier) was clearly faster than OS. And my A500 with Supraturbo 28 was clearly faster than plain A500.

Even a bare 7.09Mhz Amiga with only chip RAM can reach the maximum speed if a proper non-system double buffered loader is done.

Anyway the trackdisk.device from KS 2.0+ is really good (considering that is working for a multitasking environment).

[Photon]

Ross has given the physical limits (+1), which can maximize rawbits per track. Apart from this, there are some considerations.

If you use DMA, the ideal limit is 46950 bytes/s, but you can poll DSKBYTR with the CPU to go higher. (If you do this, disregard the rest (on 68000 only) as you will waste 100% CPU on plain loading.)

On top of this, you can use better encoding than MFM and GCR to almost reach 1.5:1 encoding instead of 2:1. (You can never reach 1.5:1.)

And the CPU can easily decode such a low datarate, so on top of this you can add a compression algorithm. On 68000, it must be very simple to make a gain, though. Because if you fill up the CPU cycles, like in Soviet Russia, the hardware will be waiting for you

On accelerated Amigas, you can do all of the above. If accelerated enough, it will be close to the physical specs of the medium+highest compression ratio. (Edit: A very good test case for stock A1200, at least I think there have been no attempts in this direction.)

[skan]

Slightly OT (and silly idea): Would it be possible to read from both internal and external drive at the same time to halve loading times? Sort of "striping"? Just curious...

[ross]

Originally Posted by skan

Slightly OT (and silly idea): Would it be possible to read from both internal and external drive at the same time to halve loading times? Sort of "striping"? Just curious...

No, but you can write on 4 drives simultaneously (the same data of course).

[phx]

But what happens when you have multiple drives selected for reading? Will the DMA favour data from one drive, or will it be from a random drive every word? Or is the data complete garbarge? Anybody tried that?

[Bruce Abbott]

Originally Posted by phx

But what happens when you have multiple drives selected for reading? Will the DMA favour data from one drive, or will it be from a random drive every word? Or is the data complete garbarge?

The drive read data lines are wired-or, so it will be a mixture of data from each drive. Since each drive runs at a slightly different speed and they are not synchronized, the data will be garbage. Chances are DMA won't even start, because it won't detect the corrupted sync word.

[phx]

Makes sense. Thanks.

[zero]

Originally Posted by ross

No, but you can write on 4 drives simultaneously (the same data of course).

Do any copiers implement that? Back in the day I only ever had two drives.

[matburton]

Originally Posted by zero

Do any copiers implement that? Back in the day I only ever had two drives.

Yes, XCopy Pro and DCopy certainly do at least.

I gave it a quick try in WinUAE and you can see it writing to all 3 simultaneously.



Saying that it didn't actually write to any of the target disks under WinUAE, maybe a bug in WinUAE? (Either than or I did something wrong)

[zero]

Interesting, thanks. Must have sped up distributing disk mags back in the day a bit!

I always liked DCopy. Being able to kill the OS on a 1 meg A500+ was handy to avoid disk swapping!

[roondar]

This thread makes me wonder, do older drives degrade in terms of speed? Or would they simply fail to work if they can't rotate the disk at the correct speed?

[ross]

Originally Posted by roondar

This thread makes me wonder, do older drives degrade in terms of speed? Or would they simply fail to work if they can't rotate the disk at the correct speed?

Paula is very tolerant in respect of RPM speed changes (I don't know how the internal resync PLL works, even though I have my own idea ..)
Unless you have very big changes, you would simply have an increase in intermittent read errors.

[roondar]

That's interesting. Does that mean you shouldn't count on a given speed for the disk then? Or are any such changes going to be fairly minor (before the number of errors starts getting too high obviously).

Sorry, I'm a bit of a noob when it comes to the actual physical hardware. The software interface I usually get, but don't ask me how the disk drive actually reads it's bits

[ross]

Originally Posted by roondar

That's interesting. Does that mean you shouldn't count on a given speed for the disk then? Or are any such changes going to be fairly minor (before the number of errors starts getting too high obviously).

You must always start from the assumption that the rotation is at 300RPM. All the small variations regarding the bit cells length are (on read) managed transparently by Paula. Of course the speed changes cannot be too high but a 15% variation (or a little more) is tolerated. For the writing, well, you need a decent drive
If your drive write too many cells (so RPM<<300) and another drive on read rotate too fast (>>300RPM), or viceversa, it is likely that synchronization may be lost.

[hooverphonique]

Originally Posted by roondar

This thread makes me wonder, do older drives degrade in terms of speed? Or would they simply fail to work if they can't rotate the disk at the correct speed?

Disk drives normally have a closed-loop system for the rotational speed, so it shouldn't degrade as such, but if there's so much wear and gunk in the drive that it doesn't have the power to spin the disk properly, then...

[ross]

Originally Posted by hooverphonique

Disk drives normally have a closed-loop system for the rotational speed, so it shouldn't degrade as such, but if there's so much wear and gunk in the drive that it doesn't have the power to spin the disk properly, then...

True, but it is not an instant system so you have micro (de)accelerations that over time lead to a slight variation in speed.

But surely there are indeed other causes that give you defective reads

[AmigaHope]

I remember spending a good amount of time on all my Amigas tuning the track wait times for every drive I had so the seek times were the absolute minimum that was still reliable on that particular drive, then throwing the patched config into the startup sequence so my floppies were always the fastest. xD