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 listReceived on 2009-05-23 12:21:18
Archive generated by hypermail 2.2.0.