How fast can the Amiga read a floppy?

[rutra80]

Of all the copiers I tried among the decades, the fastest were:
1. SuperDuper
2. Rattle Copy
3. D-Copy

[daxb]

I can remember of a copy program collection disk around 30 years ago on my A500. It had the common up/down scroll menu selection and I think it was in (dark) blue. There were a lot of programs (maybe 10?). Some or most had the usual nice looking GU like XCopy had. One or some turbo copy programs were (insane) very fast and I thought they must make a fake copy. Copy a disk in under 10 seconds (sounded like a machinegun)?! I didn't trust, can't be a valid copy but did some tests and in surprise the copy worked. Just in case someone can remember this collection disk.

[rutra80]

It probably was a dos disk with not much data and bitmap copy mode (which copies only used sectors). Every decent program had such option.

[matburton]

Originally Posted by ross

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

Out of interest is it possible to upgrade KS 1.3 somehow?

Perhaps it's possible to make a custom KS 1.3 ROM with an upgraded trackdisk.device?

[ross]

Originally Posted by matburton

Out of interest is it possible to upgrade KS 1.3 somehow?

Perhaps it's possible to make a custom KS 1.3 ROM with an upgraded trackdisk.device?

A google search pointed me out to hackdisk.device by Dan Babcock (updated by Harry Sintonen); it's on Aminet.
No idea if it can be 'inserted' as a custom module in KS1.x.

[Ray Norrish]

Asides from actual read speed, I quite like the "illusion" of read speed.
I sometimes put data on same side of the disk so the loading "sounded" faster

As a small aside, I coded a music disk set for DCS back in the day and put a neat trick in the boot-code.
I wanted the intro to start immediately (like in Global Trash by TSL) but not with a little sample loop, with actual PT music that continued as the rest loaded.
I managed to squeeze the intro sequence, PT player and the first bit of the module + 1 instrument into the first track (about 11k? iirc)
The loader carried on and loaded and stitched the rest of the loading tune onto the back of the stub.
I think this was the only time this was ever done with a full PT music track/continuation demo on the Amiga?
Yes, TSL did it first with a single sample, but I'm not aware of any other trackmo/multi disk effort that did this. Please let me know if I'm wrong.
Oh, the prod that this was done in was Sonic Attack by DCS if you want to check it out.

[a/b]

I did something similar.
Track0 was main loop, loader&support code, first effect and first part of the sample that was played immediately, and which was actually used in the module and was removed from the pattern row, and copied into its proper location within module.
And I didn't load track0, I reused trackdisk's MFM buffer to decode it for a super fast start, while I was loading track1 that contained the rest of the sample being played, PT player, some gfx, etc.
Module was split into a few out of sequence chunks (or should I say time-based chunks) that were from track2 on.

[ross]

Originally Posted by a/b

..
And I didn't load track0, I reused trackdisk's MFM buffer to decode it for a super fast start..

Yes, this is a neat idea, and I do too if possible, but with a difference: I leave the decoding of track0 to the system (which I think is very fast regardless since it's buffered).
In your case it's a bit dangerous: what if the bootblock is in fast-ram? (KS2.0+ does it )

[a/b]

That was ~25 years ago. Nowadays I just reuse a2 IO request with modified length of size of a track and let the system do the work.
And to be more precise, I checked the old code, I only did the MFM trick with KS1.x, otherwise track0 was loaded (didn't work on a4000, a0 pointed to something else).
But back then during the newbie days it was good enough (and all about 0% OS usage :P), it worked fine with OS killed and cpu decoding.

[ross]

Originally Posted by a/b

But back then during the newbie days it was good enough (and all about 0% OS usage :P), it worked fine with OS killed and cpu decoding.

That's true, and at least it was great code!

Take a look at the code of many commercial games/programs; as well as using 'dirty' tricks they were also poorly written..

[roondar]

Apologies for the thread necromancy, but there's something I wonder about regarding disk drive read speeds. Amiga disk DMA through Paula uses 3 DMA cycles per scanline, which gives it something like 1878 bytes/frame or 93900 bytes/second of bandwidth. Now this is encoded data so you'd still need to decode it. Using standard MFM, this translates into 46950 bytes/second of decoded data.

This is way more than the floppy drive delivers (which is about 20-25KB/sec decoded data). Yet, when I look in WinUAE using the visual DMA debugger in cycle exact mode with 1x floppy speed, the DMA seems to be in-use for entire frames at a time when reading from disk. Why is there such a large difference?

The only reason I can think of is that those cycles might be used to account for timing differences, but that feels slightly weird to me. Anyone know what's going on here?

[a/b]

Some of the data is wasted (when you load a full track you also load a gap between the last and the first sector). A decent amount of metadata is used and discarded: sync words, sector headers (sector/track info, checksums, some unused space).
The rest is suboptimal parallelization and safety (read/decode/timings), I guess.

[ross]

Normal DD floppy MFM cells are 2us.
The amiga uses a multiple (as with anything clocked in hardware) of the bus cycles, to be precise 7, for the cell duration.

For simplicity, let's take a PAL system, with BUS frequency (CCK) = 3546895 Hz and 227 cycles per line.
This implies an MFM cell duration of 1/CCK*7=1.97356us (so tracks written by Amiga are naturally slightly longer than normal, but absolutely within tolerance).

In a line of 227*1/CCK~=64us, how many 2ns cells can I write? Of course 32.
Potentially how many cells per line can be written by Amiga? 16*3.

So @roondar, surely what you saw are 2 channels always full and practically the third almost empty
Why 'almost'? Because, as said, the amiga cells are slightly faster than the standard and also (on read) the slight variations in motor speed can 'generate' more cells on the track.
Another reason to see the third available channel used 'more often' is when the track to be read (perhaps protected) is 'long'.

[roondar]

Originally Posted by ross

Normal DD floppy MFM cells are 2us.
The amiga uses a multiple (as with anything clocked in hardware) of the bus cycles, to be precise 7, for the cell duration.

For simplicity, let's take a PAL system, with BUS frequency (CCK) = 3546895 Hz and 227 cycles per line.
This implies an MFM cell duration of 1/CCK*7=1.97356us (so tracks written by Amiga are naturally slightly longer than normal, but absolutely within tolerance).

In a line of 227*1/CCK~=64us, how many 2ns cells can I write? Of course 32.
Potentially how many cells per line can be written by Amiga? 16*3.

So @roondar, surely what you saw are 2 channels always full and practically the third almost empty
Why 'almost'? Because, as said, the amiga cells are slightly faster than the standard and also (on read) the slight variations in motor speed can 'generate' more cells on the track.
Another reason to see the third available channel used 'more often' is when the track to be read (perhaps protected) is 'long'.

Right, that makes sense. It's all about the timing of the floppy drive and when the cells are available to read or write. This is the real limit of the read/write speed, not so much the theoretical DMA bandwidth available. That is much more reasonable than anything I had come up with.

Thanks for explaining it!

P.S. I had written my question from my memory of what I saw in WinUAE, and I did not actually remember that one of the three channels was empty some or most of the time in the Visual DMA Debugger

Edit: I'm not entirely sure I get it fully yet. If the Amiga reads/writes roughly 32 cells in a scanline and cells represent transitions rather than bits, I'd expect two cells to form one bit (assuming what I found about MFM cells is correct). This would come out to 16 bits per scanline => 5008 bits per PAL frame => 31300 bytes per second in encoded form, which would represent ~15650 bytes per second when decoded. That seems too low, so I'm sure I'm still missing something here.