<whitequark>
so i was wondering about the dfiv2 bitstream format
<whitequark>
it doesn't store the polarity of the index pulse, only that it changed
<whitequark>
it seems strange to spend so much effort on the precise timing (down to 128 samples) of the index transition (which is actually far less precise due to the mechanical nature of the index sensor), only to completely lose the sign
<whitequark>
er, less than 128 samples*
<whitequark>
i spent some time today drafting dfiv3 spec (as i've long was planning to), and thought about using a much simpler scheme: bit 7 is the logical value of INDEX line, bits 0-6 indicate time until current transition, or 0x7f if there's been 128 samples without one
<whitequark>
the uncertainty of the index transition is never worse than 2 MFM bits as a consequence of MFM having a minimum transition rate, and at 25 MHz sample rate, it is slightly higher than one minimum domain size on HD floppy (4 µs domain size, 5.12 µs worst case uncertainty)
<whitequark>
this is AFAIK more precision than both the hardware is capable of providing (I didn't measure /INDEX jitter but I'll be happy to do so to further prove my claim) and than any software can possibly use
_whitelogger has joined #discferret
<cr1901_modern>
On my 5.25" double density drive I have on hand, the index pulse has a known resting state of 1 because the line is pulled up. A pulse on the index line is _short_, a few bit cells in length (pics on request).
<cr1901_modern>
Since a pulse will eventually go back to the resting state, can't the polarity be inferred from measuring the time diff between the next change?
<whitequark>
hmm
<whitequark>
it can, but this feels like baking too many assumptions into the format
* cr1901_modern
nods
<whitequark>
actually, my first instinct would be to make it like a logic analyzer with RLE. two bits for \INDEX and \RDATA
<whitequark>
but given that the behavior of \RDATA (where the level doesn't matter, only the edges do) is a property of floppy drives (and not something that can change from disk to disk) that seems excessive
<whitequark>
actually
<whitequark>
i'm curious if \RDATA *does* denote actual magnetic polarity?
<whitequark>
or is it just a T flip-flop?
<whitequark>
I can see either happening
<cr1901_modern>
RDATA is the massaged output of a differentiator on the analog side
<cr1901_modern>
when it changes polarity, the differentiator's output exceeded a threshold
<cr1901_modern>
or fell under* a threshold
<whitequark>
do you have a pdf for a circuit that does this?
<cr1901_modern>
Not a circuit, but a block diagram
<whitequark>
also, you're saying "differentiator"
<whitequark>
but isn't that just the pickup coil?
<cr1901_modern>
From the block diagram, there's an actual op-amp differentiator
<whitequark>
hmm, link?
<cr1901_modern>
looking for it... it's on bitsavers
<cr1901_modern>
page 024 shows you what actual raw read coil signal looks like, and why it needs to be massages
<whitequark>
fascinating
<whitequark>
oh, max head output p-p is 7 mV.
<whitequark>
that... explains why my plan of "hook up a scope to the head test points" failed utterly
<whitequark>
the noise around was definitely much, much higher than 7 mV.
<cr1901_modern>
The actual read signal looks kinda like superimposed Gaussians, although later in the manual they admit they never created a good mathematical model for an arbitrary stream of what the coil reads.
<cr1901_modern>
s/manual/memo/
<cr1901_modern>
for a given change of polarity of the magnetic media across +/-0, there will be spurious smaller zero crossings. I guess this is due to the Gibbs Effect? Those spurious crossings are called "snakes" and need to be filtered out before being passed to the differentiator.
<cr1901_modern>
Not that I'm about to lead the charge to do this, but I think that internal memo has a sufficient amount of into to actually make a crude floppy disk reader from parts and a 3d printer :P
<whitequark>
oooh fascinating
<whitequark>
cr1901_modern: i think i don't understand why the differentiator exists
<whitequark>
it appears they are turning a sine wave into cosine, which is what sin'x would do, yes
<whitequark>
but... why?
<whitequark>
isn't that just a phase shift?
<cr1901_modern>
whitequark: my interpretation is that the differentiator is being used as a zero-crossing detector, which will be maximized as the signal goes from negative to positive and vice-versa (mean value theorem)
<whitequark>
but... isn't it easier to use something like a schmitt trigger?
<whitequark>
maybe it isn't. i should ask around
<cr1901_modern>
I don't know :(.
<cr1901_modern>
The actual /RDATA signal as seen from the floppy output will be low for the short period the differentiator has exceeded said threshold- it'll then go back to its resting "1" state
<cr1901_modern>
This isn't actually a problem of course- on the controller side the posedge of /RDATA will be used to clock a latch or a posedge detector to detect when a flux transition occurred.
<cr1901_modern>
Don't remember offhand if the 765 controller will do this for you, or you're expected to do it yourself as preprocessing
<whitequark>
ohhhh right
<whitequark>
of course there is no actual flux transitions on /RDATA
<whitequark>
I completely forgot that the pulses are self-timed
<whitequark>
yes. that makes the idea of sampling /RDATA value very stupid.
<cr1901_modern>
Right. Though I gave it a few minutes of thought- my gut feeling is that a schmitt trigger will work as long as you immediately latch the posedge of the trigger's output, but sampling RDATA won't actually help you.
<cr1901_modern>
My educated _guess_ (YMMV, I was not there 40 years ago, etc) is that they use a differentiator because it's a high pass filter that tells you sooner whether a zero-crossing occurred, and they wanted to floppy output to report as quickly as possible when a flux transistion was imminent.
<cr1901_modern>
whitequark: What do you mean by "self-timed"?
<whitequark>
the posedge marks the zero crossing, the negedge marks not the next zero crossing but rather an arbitrary interval determined by the silicon that is always fixed
<whitequark>
so like a monostable timer
<cr1901_modern>
Ahhh okay, yea that's accurate. The pulse interval varies a bit because analog signals aren't perfect, but it doesn't vary enough to matter for converting to digital.
<cr1901_modern>
what does "AFE" stand for again? And what page is the "sine to cosine" blurb on?
<cr1901_modern>
"Analog Front End"?
<whitequark>
yes
<whitequark>
sine to cosine is on page 24
<whitequark>
the one you linked me to
<cr1901_modern>
oh... that never really registered w/ me as being important for analysis purposes. I interpreted it as a point of comparison of "ideal versus actual behavior".
<cr1901_modern>
A differentiator is a phase shifter only if your input signal is a sine or cosine wave; the actual input signal _isn't_ a sine wave. But for making the math easy when they can get away with it, they _treat_ the input signal as a sine wave.
<cr1901_modern>
My interpretation is that the differentiator/snake-suppressors are two sections where "treat input as a sine wave" doesn't work
<cr1901_modern>
Oh shit. It's constant for all frequencies ._.
<cr1901_modern>
>A differentiator is a phase shifter only if your input signal is a sine or cosine wave <-- yea, I'm dead wrong about this, oops.
<cr1901_modern>
whitequark: Btw, as I'm sure you've gathered by now, discferret has long latency for replies, but others will get back to you if you continue to wait.