English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 02 April 2019, 21:24   #1
oRBIT
Zone Friend
 
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 43
Posts: 259
How fast can the Amiga read a floppy?

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..
oRBIT is offline  
Old 02 April 2019, 21:52   #2
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by oRBIT View Post
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..

Last edited by ross; 02 April 2019 at 22:52. Reason: spelling...
ross is offline  
Old 02 April 2019, 21:52   #3
zipper
Registered User
 
Join Date: Mar 2004
Location: finland
Posts: 1,534
I remember D-Copy (PD copier) was clearly faster than OS. And my A500 with Supraturbo 28 was clearly faster than plain A500.
zipper is offline  
Old 02 April 2019, 22:08   #4
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by zipper View Post
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).
ross is offline  
Old 20 April 2019, 00:22   #5
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,696
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.)

Last edited by Photon; 20 April 2019 at 00:40.
Photon is offline  
Old 20 April 2019, 16:30   #6
skan
emul-hat0r

skan's Avatar
 
Join Date: Sep 2007
Location: Carnorum Regio
Age: 43
Posts: 178
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...
skan is offline  
Old 20 April 2019, 19:15   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by skan View Post
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).
ross is offline  
Old 20 April 2019, 20:15   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,402
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?
phx is offline  
Old 21 April 2019, 01:38   #9
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 233
Quote:
Originally Posted by phx View Post
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.
Bruce Abbott is offline  
Old 21 April 2019, 09:09   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,402
Makes sense. Thanks.
phx is offline  
Old 24 April 2019, 09:52   #11
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 324
Quote:
Originally Posted by ross View Post
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.
zero is offline  
Old 24 April 2019, 22:47   #12
matburton
Registered User

matburton's Avatar
 
Join Date: Apr 2017
Location: Cambridge
Posts: 87
Quote:
Originally Posted by zero View Post
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)
matburton is offline  
Old 25 April 2019, 10:35   #13
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 324
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!
zero is offline  
Old 23 May 2019, 14:30   #14
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,230
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?
roondar is offline  
Old 23 May 2019, 14:50   #15
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by roondar View Post
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.
ross is offline  
Old 23 May 2019, 15:16   #16
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,230
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
roondar is offline  
Old 23 May 2019, 15:39   #17
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by roondar View Post
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.
ross is offline  
Old 23 May 2019, 16:42   #18
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 913
Quote:
Originally Posted by roondar View Post
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...
hooverphonique is offline  
Old 23 May 2019, 17:03   #19
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by hooverphonique View Post
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
ross is offline  
Old 15 July 2019, 22:06   #20
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 234
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
AmigaHope is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can Amiga read/write to Atari ST floppy disks? Blitter Retrogaming General Discussion 5 13 February 2017 20:09
Add ability to select PC floppy drive so you can read ADF files from PC Floppy Unicron request.UAE Wishlist 6 07 February 2017 16:12
Easynet Floppy read errors berkley support.Apps 1 14 October 2016 03:10
read amiga floppy disk on a pc reddwarf4ever support.FS-UAE 2 12 January 2016 13:45
Amiga 1200 Floppy read errors. atarisucks support.Hardware 1 18 May 2007 22:27

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09241 seconds with 15 queries