On 2009-05-23, at 16:53, Spiro Trikaliotis wrote:

>> Hey, Ruud - maybe I am missing something but why not use the well  
>> proven
>> method, which I also chose after analysing the fastest copiers: you  
>> just
>> get the next available sector and check whether you need this one
>> (meaning: you haven't read it yet) if not, you wait until the next  
>> and do
>> the same. IMHO you don't get any faster than that (you always get the
>> next missing sector *at most* in one rotation but normally you just  
>> get
>> the next available, which is much much closer) and it works on all
>> tracks, regardless of the speedzone and you don't have to wait for  
>> sec 0,
>> etc..
>
> This is what I described when I told about how the warp routines in
> OpenCBM and Star Commander work. But it seems I was ignored. ;)

Hm, I haven't noticed that either. But - anyway - it just adds to the  
weight. I took the idea from the copier on the 64 but it seems that it  
was very widely adopted (I wasn't aware that OpenCBM/StarCommander  
employ it too) for a good reason: I would like to be proven wrong but  
for now I simply can't imagine any more efficient solution to this  
problem.

>>> FYI: I also replaced the 1541's 'changing track' routine I used by  
>>> my
>>> own
>>> one. The gain was maybe half a second. Too less IMHO so I kept the
>>> original
>>> 1541 one.
>
> Note that the 1541 and the -II (or was it C?) one use different  
> timings,
> as do the 1570, and the 1571 uses yet other timings. Note also that  
> some
> speedloaders/copy protections have problems if you change the  
> stepping.
> Thus, IMHO, it is not worth it.

I tend to slightly disagree - what I did was I took the timings from  
DolphinDOS (verified to be "close to perfect" in terms of reliability  
vs. speed: head moves very smoothly in perceivably singular movements  
even across the whole diskette), I apply it during the read, and I  
restore the original timings once the process is done. This way I get  
no problems with "slowloaders"/protections after I am done. Of course  
we are all talking about imaging the non-protected diskettes as  
protected do not fit well into D64.

But... in the current stage, I think fiddling with the head movements  
timing is a "premature optimisation", which may possibly backfire when  
applied before the other parts fully stabilise.

-- 
SD!


       Message was sent through the cbm-hackers mailing list