Administrace komentářů

Stream z disketovky jsou data z hlavy, pouze jsou kvantizovaný na dva stavy: H a L a mají omezenou minimální frekvenci (nejde zaznamenat mnoho H nebo L za sebou) a je omezená i maximální frekvence (dost možná to je omezený jen fyzikálníma vlastnostma hlavy a magnetickým povrchem). Střídání H a L si pak řeší FDC řadič v kompu, třeba MFM apod (určitě by šlo vymyslet něco mnohem efektivnějšího jako 8/10 nebo dokonce 128/130).

Pokud zanedbám hazardní stavy když přijde hrana při samplování na vstupu, tak se dá ten stream _IMO_ pustit přímo do SPI a načítat ho nějakou samplovací frekvencí, do paměti MCU pak uložíš třeba 000001111111111000001111100000 (třeba pro 5x oversampling pro data 011010) a pak až bude dost času, tak to analyzuješ a dekóduješ do reálných dat. Jelikož se vždycky čte maximálně cela stopa, tak to pro 5.25" disketu není nějak velká pálka RAM (15*512*8 = 62kbit na stopu .. reálně to bude trochu víc 512B sektor má děsnej overhead, ale i kdyby to bylo 100kbit na stopu tak s 5x oversamplem potřebuješ jenom 64kB buffer, což je pro rpí nula nula nic).

Dost možná by oversampling ani potřeba nebyl, těch bitů na stopu je fakt málo, takže samplovací frekvence má velkou toleranci, než by se to se záznamem rozešlo tak moc, že by se osamploval špatný interval.

Ale jak říkám, je to jen teorie a jelikož teďka nemám programátor, tak to ani nemůžu otestovat . Plánoval jsem ale udělat frontend v nějakým CPLD, který by ten interval měřil a PICu posílal už čistý (třeba MFM) data.