Re: Is fast stepping used in the 1541?
Date: 2008-07-31 16:15:07

On 2008-07-31, at 11:42, <>  
<> wrote:

> Hallo allemaal,
> Just for fun I was looking if I could speed up the 1541 inside Gideons
> 1541 Ultimate. The idea was that to skip all delays caused by  
> mechanical
> features. For example, the start-up time for the motor can set from  
> $3C
> to 1. Should Work fine as I already use this feature in my 1541IDE
> project.

I can of course imagine some "unresponsibly" coded routines, which  
would depend on a delay here or there, the same way as it was once  
fashionable to do delays by busy looping e.g. in BASIC. ;-) But  
generally it should be fine.

> The next delay is the one for stepping the head. As I don't use any  
> head
> stepping at all, I simply removed all routines. But Gideons 'floppy
> drive' does act on the state of the outputs of the 6522 and so I  
> need at
> least the routines that output the signals for the stepping motor.
> There is a routine for fast stepping the head and one for slow  
> stepping.
> The actual decision is made at $FA0E where the number of steps is
> compared with MINSTP ($0064). MINSTP is filled with the value $C8 =  
> 200
> at position $F2A4. What ever the original input is, at $FA0E  
> register A
> is a number where bit 7 = _always_ zero. And therefore A can never be
> greater then $C8 and thus the fast stepping routine is never executed.

I don't ever recall anything using some "fast stepping" in the CBM  
DOS but I remember that one of the great DolphinDOS improvements was  
optimising the timing of the stepper. It was done so well that the  
stepper was executing very fast, and practically smooth and  
continuous, rather than stepping movements. This _greatly_ improved  
access times as the head was "flying" back and forth rather than  
moving. AFAIR there was virtually no problems related to this. Again  
- some (albeit few) non-standard transfer routines required turning  
DolphinDOS off but those were few and usually caused by other  
features which could be resolved by disabling RAM/parallel transfers.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.