Re: Order of sectors on a track

Re: Order of sectors on a track

From: Ruud_at_Baltissen.org
Date: Sat, 23 May 2009 11:06:28 +0200
Message-ID: <4A17D8B4.3955.A553DA@Ruud.Baltissen.org>
Hallo allemaal,


> Second idea (that just popped up): I only use
> this method for track 25 - 35. Wow, I'm good :)

The idea worked out fine indeed and still only 35 seconds :) 
FYI, I check things by using a floppy I created myself. I filled all 
sectors with nines (to have something different then the content written by 
the format routine) with the exception of the first two bytes: they 
represent the track and sector number of that particular sector. After 
executing the copy routine, it is just a matter of checking these two 
particular bytes on every sector of the harddisk.

But I'm still left with a question: why did things go wrong? My first 
thought was that it had to do with the sector density of inner tracks. But 
this morning it occurred to me that that idea is wrong! The inner tracks 
have less sectors/track then the outer ones, thus less sectors pass the 
head/second then in case of the outer tracks. So expecting to find sector 
4, with the inner tracks I rather expect to run into sector 3 then sector 
5. The only thing that comes into my mind is "intersector distance", the 
distance between two sectors.

Writing the above I decided to check things again. I installed a previous 
version and started to check what sector from the floppy was loaded and the 
order as it was done (interleave = 5):
harddisk  floppy
  0          0
  5          5
 10         10
 15         15
  2          1
  7          6
 12         11
 17         16
  4          2
  9          7
 14         12
  1         17
  6          3
 11          8
 16         13
  3          0
  8          5
 13         10
 
It seems my previous conclusion was wrong: not the 6th but the fourth 
sector is loaded from time to time. What is also strange, it only happens 
when I pass the last sector. The only thing that now comes to my mind is 
the gap between the last and first sector. Think, think, think.... the 
original DOS calculates all gaps but I'm not sure if JiffyDOS does. I 
suspect JD uses an hardcoded number, one that should also work on a disk 
that turns slower then it should, but within limits. On a normal drive this 
will leave a wider gap between the last sector and sector 0. And this is 
most probably what I ran into. 


--
    ___
   / __|__
  / /  |_/     Groetjes, Ruud Baltissen
  \ \__|_\
   \___|       http://Ruud.C64.org







       Message was sent through the cbm-hackers mailing list
Received on 2009-05-23 12:21:18

Archive generated by hypermail 2.2.0.