Synchronizácia kódovania MFM

[RayeR]

Zajiame, budu sledovat jak se to tu vyvine.
Ja sem si hral s MFM disky pouze na PC, takze nevim jak to chodi na jinych platformach. Z toho vyse napsaneho jsem pochopil, ze ma disk zapsany nejakym jinym formatem, takze by ho PC MFM radic v PCcku neprecetl...

Slo by to asi udelat nejakou obdobu jako je Kryoflux na diskety, ze by se z disku cetly jen nake pulsy pri zmene mag. toku a cele by se to dekodovalo az nakym SW na PC, to by aspon pak bylo univerzalni...

[rampage]

Akurát pozerám prednášky o Raspberry Pico - najmä ohladom PIO.
Týpek z nejakej americkej univerzity s tým postavil jednoduchý softwarový renderer na VGA monitor pri 25MHz (640x480); také niečo keď ide, to bych si mohol vyskúšať spraviť softwarové dekódovanie MFM (10MHz) a RLL (15MHz) a následnú analýzu/zápis stopy.
To namiesto súčasného "interface" kde Arduino slúžilo iba ako medzikus medzi terminálom na PC, a hardwarovým harddiskovým radičom/sekvencerom.

Zobral som pokusne pár Pico II dosiek od zeleného škriatka.
Oproti Mega2560 to má menší počet GPIO, takže už musím osadiť posuvné registre, ale zas je to vraj naďalej +5V TTL "tolerantné" (ak to má napájanie); programovať sa to dá cez VSCode: druhé Pico som neska rozbehal ako debugger a funguje bez zaklínadiel - vo visualku normálne brejkpoint a vypluje stack, registre, premenné. Tak jak sa na dvadsiate prvé storočie patrí

Akurát analogový fázový záves k tým diskom by som si naďalej ponechal. Mám tu ešte nejaké WD čipy ktoré rozcuknú RAWDATA na DATA a CLK, ale datastream ďalej nespracúvajú, ani nedetekujú adresné značky, nič. Takže to by som skúsil riešiť sám. Ergo, preskočiť diskový radič uplne a ten si navrhnúť softwarovo.
Holé Arduino by to nedalo, toto už vyžaduje DMA.

[RayeR]

Ano, ty PIO jednotky na PICO jsou mocny nastroj, dokonce s tim nekdo udelal i knihovnu na bitbangovany HDMI vystup (jen nejnizsi rozliseni 480p), to je este vetsi HC jak VGA. Takze nakych par Mbitu z HDD by to melo zpracovat s prstem v nose... Otazka, jesli ta flexibilita PIO bude pro tuhle aplikaci stacit. Ja sem se k tomu zatim nedostal to nak do hloubky zkoumat, ty PIO jednotkyy se programujou ve specialnim assembleru oddelene od C zdrojaku...

[rampage]

Zdá sa, že ten "PIO asembler" vypluje pri skompilovaní céčkovský header, kde je const pole s jednotlivými 16-bit inštrukciami. Rutiny v SDK to pripravia do SRAM a spustia. Vraj každá inštrukcia je presne 1 takt CPU, teda pár ns. A ak by to nestačilo, SDK má vraj priamo rutiny na pretaktovanie.
Ale maximum je 32 inštrukcií - pre všetky PIO moduly spolu - a to iba základné opkódy typu in, out, mov, jmp a shift. Čiže je to poriadne obmedzené.
Gro sa musí pripraviť ešte pred spustením PIO procesoru, tzn. data už musia byť v SRAM, DMA kanál správne nastavený pre čítanie, zápis ap. Ale zatial som to neskúšal ešte.

Ale videl by som to jednoducho: čakaj dokým nepríde INDEX disku, z nábežnej hrany CLK zober DATA, ulož do RAM a opakuj kým nedojde ďalší INDEX (alebo nedojde RAM )
Dekodovanie z MFM/RLL na databity už potom v céčku...

Trocha bude problém pri zápise - za istý cylinder odbavovať predkompenzáciu bitov, tzn. oneskoriť ich o konkrétne jednotky ns. Ale najskôr to čítanie

[RayeR]

Toz drzim palce, kdyztak tady je upravena verze PicoSDK od Pandy ocesana o zbytecny bloatware https://github.com/Panda381/PicoLibSDK

[rampage]

Toš poslušne hlásim, že to malina stíha... Lepšie povedané, ide jak píla

1.jpg

Napokon som tam ponechal hardwarový fázový záves - starší Western Digital, ktorých je plný aliexpress. Ten rozcukne data z disku na CLK a DATA, zato ich ďalej nespracúva - na rozdiel od toho Silicon Systems zo začiatku vlákna, ktorý sa zároveň snažil zasynchronizovať o tie preambule a na výstupe by už mal priamo dekódované MFM bity, keby fungoval.
Takto riešim tú synchronizáciu plne softwarovo, takže tie divné preambule už problém nerobia. /Napokon PIO iba vzorkuje, celý šábes je v C++. Ale stíha čítať i hneď na to zapisovať, len už musím spúšťať build s aspoň -O1 pre gcc./
To WD tam mám ešte kvôli záznamovej predkompenzácii - oneskorovaní dátových bitov oproti CLK, o pár ns, aby sa to pri zhustených vnútorných stopách nepobilo. Toto by možno šlo i cez PIO vhodne umiestneným nop, ale už som to nechcel pokúšať, je to dost háklivé.

Na záznam napokon používam DMA už s vopred pripraveným MFM buffrom, keďže pri 5Mbps to musí nasypať osem bitov za okolo 1,5µs (CPU musí pritom sledovať INDEX, WRITE FAULT...) a to by s Arduinom rozhodne nehrozilo.
Ešte vyskúšam RLL 2,7. To má o niečo vyššiu datarate (7,5Mbps), ale to sa ešte dá.

I softwarové pretaktovanie ide Stock dualcore 150MHz mi šiel potiahnuť na 333MHz bez problémov. Nad tento kmitočet sa už odporúča upraviť clkdiv pre flash pamäť a prípadne vyradiť interný regulátor pre vcore, plus nejaké to chladenie pre ten mrňavý šváb. Ešte nejaké benchmarky tomu spraviť...

[RayeR]

Tak gratulace, uz teda z toho padaj do PC kompletni image?
RP taktovat jde slusne, je to vyrobeno nakou jemnejsi technologii, tak to bylo cileno spis na nizsi spotrebu nez vykon, ale treba kvuli tomu HDMI se to pretaktovavalo taky a no problem...

BTW na virtualni bastlirne sem zaslech o nakem projektu pro pripojovani starych IDE disku, co neumi LBA, taky snad neco na bazi RP, tam je to o dost jednodussi...

[rampage]

Jo už to sype image, zatial direkt na pamäťovku + prípadné errory na terminál, plus jednoduchý "DOS" viewer. Som to mal pôvodne ako arduino projekt, tak som tomu len prispôsobil classy:

1.png

Keďže má malina nativnu USB podporu a nie iba UART, možno sa raz dokopem a spravím k tomu normálnu appku...

Zatial to chrúme disky sformátované WD, ďalšie na rade budú OMTi, Xebec, Adaptec, Longshine/SMC a samozrejme ten smep. Prípadne tam dorobím nejaký raw dumper nezávisle od formátu, ktorý vysype celú stopu aj s adresnými značkami, pre neskoršie "offline" zasynchronizovanie.
Byť u GPIO miesto pinov nohy, tak ma nakopú do riti: RP2350 je ofiko +5V tolerant iba s napájaním, no a naraz sa s malinou zapne i fázový záves (naprázdno). Opencollector výstupy mám síce zavesené o +3.3V pullupy, zato niektoré výstupy fázového závesu sú TTL a (zatial...) sú zavedené do maliny napriamo bez shifterov

Interface s IDE diskami je pohoda (kým funguje elektronika disku), keďže tam je už dohodnutý command set. Len tie úplne prvé v ATA Mode 0/PIO nefungujú v USB-IDE redukciách, lebo im nezistia geometriu...

[rampage]

Pri softwarovom dekodovaní RLL 2,7 a najmä počítaní až 56-bitového CRC dátových polí, ktorými niektoré takéto disky bývali nahrané "za jazdy", už tých 150MHz nestačilo. Musia sa rýchle overiť data pred tým, než začne hlava disku čítať ďalší sektor.
Tak som zdvihol vcore z 1,1 na 1,8V, CLK z 150 na 600MHz a CLKDIV z 2 na 5 (flash a SPI teda bežia na 120MHz, odporúčané maximum je 133). Stále funguje, dokonca bez pasívneho chladenia, i keď už sa trocha viac hreje (55°C).
Rutina samozrejme beží priamo z RAM a nie z flashky - funguje už pri 200 MHz, takže to netreba nejak hnať, ale idem na tom odskúšať nejaké benchmarky

1.png

P.S. zisťujem, že iné RLL 2,7 kódovanie používa Western Digital a iné Seagate/IBM. Krasotinka...
P.P.S: ten smep je samozrejme MFM