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..