Question on disk flux transitions

[Farb]

Hi all,

 

As a learning exercise, I've been looking at the flux values stored in SuperCard Pro files and it raised some questions about how this data is interpreted. I'm hoping someone here can help answer them. Here is a quick diagram:

 

 

My understanding based on looking through websites and PDFs on the Internet is that 8-bit SD disks use FM encoding which means flux transitions are interpreted as I've tried to show in the diagram. The values in the SCP file indicate the duration of each flux transition. I'm converting those values into microseconds using:

num * 25 * (driveRpm / 288.0) / 1000.0

I assume here that I need to account for the fact that my drive captured the data at 360 rpm but the data is intended to be read at 288 rpm.

 

1. I'm unclear what is considered a "bit cell". I had thought that the term referred to the 8 microsecond interval as shown in the diagram during which no transition means a 0 and a single transition means a 1. However, the SCP format documentation seems to indicate "bit cell" and "flux transition" are synonymous.

 

2. I can't seem to find any information on how to determine byte demarcations in the stream of bits.

 

3. In the flux output of a track with no copy protection, I see some transitions that are higher than the ~4 or ~8 us that I would expect (e.g. 11 us). What does that represent? Perhaps related to question #2?

 

I have looked at the a8rawconv source code to see how the FM decoding is done but it is not entirely clear why the code is doing what it is doing :-)

 

Thanks for any insight anyone can share.

[ijor]

I assume here that I need to account for the fact that my drive captured the data at 360 rpm but the data is intended to be read at 288 rpm.

Correct.

 

1. I'm unclear what is considered a "bit cell". I had thought that the term referred to the 8 microsecond interval as shown in the diagram during which no transition means a 0 and a single transition means a 1. However, the SCP format documentation seems to indicate "bit cell" and "flux transition" are synonymous.

Many of these terms are somewhat ambiguous. The term usually refers to the clock period, that in this case it is 4us (half bit). Sometimes it can be used to refer to the full bit (8us in this case). Shouldn't be synonymous to flux transitions.

 

2. I can't seem to find any information on how to determine byte demarcations in the stream of bits.

There is no strict concept of bytes. This is a higher level issue that might not be universal. The FDC uses sync marks to align bytes. Check the FDC documentation.

 

3. In the flux output of a track with no copy protection, I see some transitions that are higher than the ~4 or ~8 us that I would expect (e.g. 11 us). What does that represent?

Usually just write splice that produces all sort of noise. Might also be damaged data, of course.

[phaeron]

To understand what a8rawconv and the FDC chips are doing, it's best to shift the diagram by 2us:

 

 

Each 8us bit cell, which encodes one data bit, is split into two 4us periods where the first slot is for clocking pulses and the second slot for data pulses. For FM, the clocking pulse is always present, and the data pulse is present for a 1 and absent for 0. You can invert the waveform and the result will be the same, since the output of the data separator is just pulses where the transitions occur, regardless of the polarity.

 

There are no framing start/stop bits like in an SIO or RS232 transmission, just a continuous stream of encoded data bits. As ijor says, byte alignment is achieved by looking for special sync marks, encoded with patterns that are impossible or extremely improbable in normal data. In these sync patterns, some normally encoded clock transitions are omitted. Once the sync bytes have been identified, the byte alignment from those sync bytes is applied to the rest of the bitstream for the address or data frame. Note that this synchronization is not just for bit sync but also half-bit sync, since initially the decoder can't distinguish between clock and data pulses. After sync is established the clock pulses are not used for synchronization, and in fact some copy protection schemes rely on the FDC being able to process encoded data bytes in data frames that have clock pulses missing.

 

Beyond bit-level synchronization, there is also the need for the decoder to lock onto the bit cell timing used by the encoder. There are no indications of the bit cell or half-bit cell timing other than the pulses from flux transitions, which occur irregularly based on the FM or MFM encoding. The basic approach used is a control loop that tracks the timing difference between when the pulses are expected and when they occur -- if the pulse is early or late, the bit cell timing of the decoder is adjusted by feedback to bring the received pulses closer to expected timing. When there is no pulse, such as the data cell when encoding a 0, there is no timing reference from the decoder and it must extrapolate the timing across the blank cell. This is why encoding schemes limit the number of consecutive encoded 0s, as the more periods there are with no pulses the more critical and difficult it is to keep the encoder and decoder in sync.

 

There are a number of reasons the timing can deviate, such as differences in clock rate and rotational speed between the reading and writing drives, instantaneous spindle speed variations, and peak shift effects. As a result, there is a tension between how fast the decoder can adapt to local and global timing errors. Lowering the adaptation rate of the decoder stabilizes the timing so that it can better handle jitter and peak shift. However, it also increases the time for the decoder to acquire and lock phase at the start of a frame -- too long and it won't sync quickly enough before the address/data field starts. Raising the adaptation rate shortens time to lock and improves the ability to react to instantaneous speed variation. Limits on the feedback are also necessary to prevent the decoder timing from going haywire during glitches or unformatted regions, which otherwise might throw the decoder so far off that it can't properly lock once a valid frame arrives. The strange logic you see in a8rawconv to adjust cell_timer to slowly adjust the cell timing to keep the decoder in phase without allowing it to overcorrect on a single shifted pulse. It's a simple algorithm, however, and one that could probably be improved.

 

[Mclaneinc]

Slight OT: I'm just grateful your guys understand all this stuff, its so far above my head it might as well be on the ISS but its amazing at just how complex (to me) all this stuff is. Farb, Phaeron, Ijor and all the others, thank you for being able to use this stuff to make our hobby so much more accurate in every way...And of course a huge hand to Farb and the guys for the Preservation initiative..