On speed optimization

The theoretical limit, assuming 300rpm drives, is 200ms per track. Or 400ms per cylinder, or 32 seconds per disk. Most attempts read slightly more than one track. I read 16,384 bytes, or 262ms worth.
Right now, if I continue to use the SX/B UART code, which maxes out at 230,400 bps. That puts my PC xfer code at 711 ms per track.

So that’s 262ms + 711ms = 973ms or about 1 second per track. 160 tracks or 2:40 minutes per disk. Not bad, but I’d much rather be closer to 1 minute.

I also have overhead in the PC->SX communication, and I’m currently turning the motor ON and then OFF for each track. I’ve gotta fix that. Plus, I have to wait 500ms for the drive to spin up on each attempt. Leaving the motor on all the time raises some issues, but I’ll get that in time.

More on this later

About the author


Amateur Electronics Design Engineer and Hacker


  • ok, I hate to admit my current transfer times. But this is the worst case scenario — it will never be worse than this.

    It’s currently taking me 7:36 to transfer a disk to ADF. Way way too slow.

    Transdisk does the same disk in 0:45 seconds which is smoking. The theoretical max is like 0:32 seconds, so this really kicks butt.

    I’m going to use Transdisk as the Gold Standard (TM) however, as you saw from the math in the post, I don’t expect to get under 2:40 per disk until I change out my UART code. I haven’t figured how I’m going to do that yet.

    Realistically, I want to run my transfer code at around 2mbps, if possible, which puts the transfer at 81ms + 262ms = 343ms per track = 55 seconds total for all tracks. That’s pretty good.

    Even if I run it at 1mbps, that adds another 81ms, so 162+262 = 424 ms per track = 68 seconds, which isn’t horrible.

    There is going to be some additional overhead with commands, so I think I’m going to set my current goal to 2:40 + 15% = 3:04 seconds. If I can do a disk in 3 minutes, I’ll be happy in the short term.

    So, short term goal is 3 minutes. Let’s see what I can do.

  • By leaving the motor on all the time, and shortening and removing delays throughout the code, I’m at 4:40 per disk. That’s a 3-minute improvement from earlier.

    So if I subtract the disk-read time and the track transfer time, I’m still dealing with 2 extra minutes of overhead. This works out to be 750ms extra per track. Let’s figure out where that’s at!

  • OK I’m at 3:06 per disk.

    That’s real close to my short term goal, and I think that any more serious reduction to the overall time is going to come with improving the UART transfer speed.

    I can explain 2:36 of this total in reading+transferring, so that leaves 30 seconds unaccounted for. Divide that across 160 tracks, and that’s a mere 188ms per track of overhead(16%).

    I have a delay of 300ms between issuing the read command and starting to receive, because if I start too early my read routine will timeout. Sure I could increase the timeout value, but then, if there was a slightly short read, I might end up running longer.

    I would be willing to bet that 300 is slightly overkill. Real number is 262ms, but I wanted to add extra time to process the R command, setup, and so forth.

    Even so, I’m pretty happy about a 3 minute time frame right now. I will improve upon this.

    I didn’t want to have to revisit the UART stuff so soon, because its a pain in the ass, but if I want to get these times down I have no choice.

    My long term goal is under 1 minute. If I transfer at 2mbps, I should be able to achieve this.