been learning a lot about floppy drives/disks/controllers lately, what with #Floppy "Fun" -- Backing up a unique Kay-Pro disk  and #Improbable AVR -> 8088 substitution for PC/XT

Also finally started attacking a long-planned project to record audio directly onto floppy disks...

So, here I plan to throw random unexpected discoveries that may be useful for floppy endeavors of all sorts.

(Many Many more are buried in logs at the projects linked above).

1) the /STEP input is *not* directly fed to the stepper motor driver. Boolean logic determines whether the drive pays attention to the /STEP input. Primarily: the drive *will not step* if /WG is active.

(This Teac drive manual actually shows the logic equation... and similar equations exist and are explained for other I/Os as well...)

2) if /WG is active when the index pulse arrives, the pulse is extended (dramatically) presumably to indicate to the host controller that the write process was truncated (?).

I vaguely recall reading about this extended pulse somewhere (and plausibly whether the write actually gets truncated, or whether it's allowed to overwrite the beginning of the track) but have yet to relocate that source.

3) microstepping?! Fiddling with /WG and /STEP timings, I noticed it may actually be plausible to acheive some level of microstepping. More logically, /STEP and /DIR could plausibly acheive this as well. Precision more likely than accuracy, so maybe not so useful when using disks for storage, but maybe something to fiddle with. (One thought... maybe possible to use Step/Dir microstepping in attempt to read tracks written on a poorly calibrated drive... or, e.g. where a 5.25in disk has an oblong hole, from years of wear).

The odd thing about /WG's effect on stepping... I was under the impression that /STEP must be (falling)edge-triggered... the outputs of the motor driver holding their new state after the edge. But then /WG's only effect should be that of either allowing or blocking the transition to the next state. Then there should be no fractional (or incomplete) steps. But almost certainly I could hear attempted steps cut short.

That would imply... 

4) /STEP is not edge-triggered (?!)

And, actually, that makes some amount of sense based on my readings which I didn't quite wrap my head around until just now... combined with knowledge of the stepper motor driver chips used in some (macintosh) drives I've scrounged for their... wait for it... stepper-driver chips. These chips have two supply voltages for the motors... 12V for seeking and 5V for holding. 

And the readings...? As I recall, the stepping-procedure for drives allots various (adjustable) time parameters for head movement... step-rates made sense to me; don't try to step too fast or the head won't overcome static friction, and steps will be missed. Head settling time; after a step, the motor will bounce briefly before settling into its new position... give it a certain amount of time to settle. But there were other step-timing parameters I didn't grasp... and I'm betting one of them is the duration of the /STEP pulse, which probably also determines the duration that the new state is supplied with 12V to nudge that motor into that new position... (note the drive I'm working with now only has a 5V supply, but may use a similar seek/hold scheme).

Aside: I used those motor drivers (once removed from the drives) for quite a bit of experimenting... #CD/DVD mechanisms and cartesian thinggie[s?]  microstepping was definitely doable, but also causes quite a bit of heat... also, I worked with the driver chips themselves, which had separate phase-inputs rather than step/dir like that entering the floppy drive's controller board (and presumably going through some logic, flip-flops, etc. in order to convert those step/dir pulses into winding phase states). 

That all said, it seems entirely plausible (ifnot more-so, now) to implement microstepping via the step/dir inputs... (except during write, of course) hmmm...

So, the initial thought was that maybe /STEP could just always be active, and /DIR, alone could be PWMed... but of course I was thinking about DC motors... something has to advance the whole-steps, and /DIR can't be responsible for that since, under normal conditions, it stays constant while *stepping* between tracks on the disk. Duh. So, it would seem /STEP has three jobs... on the falling edge it loads the new phase-state on the windings... depending on the value of /DIR. Then while /STEP is low it uses high current to cause the motion (then low-current to hold the position, when /STEP is high).

But here's the other kicker... to do microstepping, as I see it, requires pwming DIR... and changing DIR, alone, doesn't actually cause a step-phase state change. So... each time DIR is changed, it needs to be followed by a falling edge on /STEP.

... (this is similar to another project a while back... a weird DC motor driver chip that required a strobe for each PWM change)

Ok... so now that should take care of microstepping between two full steps... what about advancing to the next...? Two /Step strobes, I guess.

And that stuff about high-current for seeking and low current for holding...? In my experience with bipolar steppers it takes more current to hold, say, a half-step, than a full step... so... most-likely we'll want to keep /STEP active (low) as much as possible... which will likely result in hot motors and hot motor drivers... so maybe worth analyzing more thoroughly, or at least watching closely.

I think it's doable. Depends of course on the drive... different designs might meet the normal specs in different ways... do they use regular ol' logic or is there a processor involved? Etc. (Looking at that Teac manual... well... read the next paragraph)

I think it should go without saying this sorta thing would be way outside the typical specs for these things... but then... they've little reason to spec e.g. falling-edge /STEP to motor driver output propagation delays, as long as the de-facto 3ms *motion* time is guaranteed.

So, I guess the question is why... and I guess the only thing I can come up with is for data recovery on misaligned tracks... might e.g. be doable with a regular ol' PC/drive and an ATtiny dangling on the ribbon cable.

....

Another thing about microstepping... it makes for nice smooth motion between two full steps... no huge buildup in momentum and no sudden deceleration. It's plausible, e.g. that a smoothed step from one track to the next would require less settling time, so might actually make for faster seeks despite taking longer than the requested /STEP pulse. Would also likely be quiter, if not nearly silent...

Yahknow... for those die-hard floppy users of today ;)

......

The Teac manual...

Is *very* thorough regarding input and output requirements. Meeting those requirements is probably de-facto in most cases, by most computers... so some of that data seems needless. E.g. a step will not occur if the disk is not write protected AND writing is active. So... it'll step if writing is active and the disk is write protected? When would that ever be the case...? (Hah! Maybe that's the trick I need for writing while microstepping!)

Other thoroughalities include things like extensive info on the requirements for /STEP and /DIR... almost making it sound like if they're not met then the stepper controller itself won't recognize/accept the command, or possibly misinterpret it, rather than its resulting in a "failed" full-step motion (which would be exactly what I'd want, for microstepping)... but... who knows...

....

More thoughts on *why*... why am I intrigued to implement microstepping on a floppy drive...? Here's a possibility: many/most stepper-controllers, e.g. as used in 3d printing, or maybe better yet laser etching, have the same-ish interface; step/dir. Alotta the time those controllers implement microstepping on-chip. So, e.g. if you send a single step command it steps a quarter step. Therein lies a problem... fractional steps are wonky. It's stopping point will likely be closer to the side approached from than an actual quarter-way between two full steps... and when static friction is taken into account, even a single half-step may have no effect on a stepper's position, so repeatability is a concern. 

Also, external forces can sway fractional steps dramatically. Imagine milling aluminum in a line from (0.25,0) to (0.25,10) (units being full steps). Now, it starts closer to (0,0) due to the fact it was powered up at the origin, the quarter-step move to the starting point doesn't supply enough power to cut the aluminum all the way to (0.25,0) so the line really begins at (0.1, 0). Now the thing's moving in a line, and cutting has started, that x coordinate may settle closer to a quarter step. Now a chip hits the tool, and the quarter-step is bounced to, say, 0.4... and so-on... you'll end up with a wobbly line.

One design-technique to improve that is to only use full steps for actual endpoints/corners...

Microstepping *between* these points, though, is very helpful... it smooths the motion, reduces bounce, and more.

But, with only step and dir signals connected between your motion controller and your stepper drivers, and what with homing/zeroing, there's little can be done to know/control whether *requesting* a full-step (e.g. four step signals, with a quarter-stepping motor driver) actually ends at a full step. Maybe it zeroed at a quarter-step.

So... maybe a cheaper and less-sophisticated motor driver that only handles full-stepping is a better option... with a more sophisticated motion-controller... Using PWM on the DIR pin and pulsing the STEP pin at each edge, as described earlier.

(TODO: wouldn't be hard to modify grbl-abstracted... already works on a pic32 twiddling its thumbs alot of the time, and small systems could use actual floppy circuitry as motor drivers. Low entry-cost!)

.....

2-21-19: http://cowlark.com/fluxengine/

Kinda like KyroFlux, but opensource and also looks to have some useful links.

Also, he's using a timer/counter to measure the time between flux transitions... Sounds like a job for PWM-nibbles! #Floppy-bird 

Also, he's looking into other controller-options...

Thx @Starhawk and the blog... https://hackaday.com/2019/02/19/flux-engine-reads-floppies/ which has some informative commentary.

.....

Surely more to come...