Zaslal: st únor 04 2026, 16:28 Předmět: Synchronizácia kódovania MFM
Touto témou tu asi rúbem hodne vysoko, každopádne... napadlo mi že sa opýtam človečiny, pretože už ma nebaví čítať fabulácie umelej idiocie No a problém bude určite riešiteľný elektronicky.
Mám bastl s Arduinom, ktorý na jednom plošáku obsahuje pokusne rozbehaný radič harddiskov. Prehistorických, MFM. Sú tam dva hlavné čipy; jeden je sekvencer (nepodstatný) a ten druhý synchronizátor dát. Obidva vytiahnuté zo starej ISA karty. Prezrel som im datasheety, zistil, že sa dajú "programovať", tak reku vyskúšam ich. Fungujú. Som schopný pracovať s dinosaurami ktoré boli sformátované na radičoch Westen Digital, OMTI a podobne. /Je mi jasné, že univerzálnejší radič/emulátor už niekto vyvinul predo mnou - beriem to ako výzvu zo "šuflíkových" súčiastok./
A teraz kameň úrazu, kde to nefunguje, a kde by som to chcel vyriešiť.
Použitý dekodér/synchronizátor MFM dát je Silicon Systems 32D534.
Ako i iné radiče, pred tým než môže začať čítať, sa musí na dáta z disku správne zasynchronizovať fázový záves (PLL). A to na hranici bajtu, aby neboli jednotlivé bity poposúvané, alebo povypadávané.
To sa u týchto diskov riešilo tzv. adresnou značkou - zápisom A1, teda postupnosťou 10100001 s jedným MFM clock bitom vynechaným. Tesne pred touto postupnosťou sa nachádza súvislý rad nulových bitov, ktoré slúžia ako indikátor "zachvíľu začnú data". Tento rad sa nazýva "preambula" a býva obvykle 10-13 bajtov dlhý (80-100 nulových bitov).
No - a tento huncút správne funguje iba s takými formátmi, kde sa do tzv. tolerančných medzier disku (umelo vytvorených, aby sa vykompenzovalo kolísanie otáčok), pri formátovaní zapisovali nenulové hodnoty. Akékoľvek, len hlavne nenulové. Pretože po nich nasledujú už záhlavia sektorov.
Ak sú to nuly, tak ten MFM deserializér to začne považovať ako preambulu - istý čas, než to vzdá, vyresetuje sa a začne odznova. A zrovna vtedy preletí A1čku - sekvencer nedostane signál a sektor som nenašiel.
A just som musel taký formát objaviť, SMEP - made in Czechoslovakia. Asi nemali nemali valuty na západný radič, takže to činilo jeden kompletný, škaredý, hradlový orloj, ktorý im dovolil takéto zhovadilosti. Okrem toho dali tú preambulu dlhú (až 16 bajtov).
Tým, že fázový záves po správnom zasynchronizovaní iné formáty číta dobre (PC), si hovorím že jedine ako toto by možno šlo elektricky doladiť, je upraviť časovanie preambule - dať snáď volajaký viacotáčkový trimer do 1FS? Prípadne ešte pre IREF, len s tým to rozhasím asi úplne... Rýchlosť dát je 5Mbps.
Ešte som skúšal takú z núdze cnosť a to vypnúť vyhladávanie preambule/adresnej značky a proste zasynchronizovať hneď po hradlovaní READ GATE; v tom datasheete sa to volá Direct Sync Mode.
Následne zaserializovať bajty do binárnej podoby (do textového reťazca jedničiek a núl) a tam hladať správnu bitovú postupnosť - následne ju textovo "urezať" tam kde to začína. Takto "opravenú" potom deserializovať spátky na bajty.
A ak nesedí CRC, proste repete. Pretože sa to väčšinou striafa do A1čiek v datach, a nie v záhlaví, za preambulou.
No... lenže okrem toho že je takáto zhovadilosť na Arduine pomalá jak piča, beztak toto neprečíta kompletnú stopu. Iba nejakých 10-12 sektorov zo 17tich, pretože to neni iba bitový posun - zlým zasynchronizovaním bity vedia vypadnúť - úplne. Potom nenájde postupnosť bitov, a som nahratý. A to tam mám asi 50 pokusov pred tým, než prehlásim že ten sektor na disku neni
To je zase špalek. Napadá niekoho niečo? Vysrať sa na to úplne?
Založen: Aug 16, 2022 Příspěvky: 882 Bydliště: Roztoky
Zaslal: st únor 04 2026, 18:51 Předmět:
Pokud si to dobře pamatuji, tak se na čtení a zapisování dat používalo RLL kódování, takže tam nemohl být větší nulový blok, než je definováno v typu kódu.
https://en.wikipedia.org/wiki/Run-length_limited
RLL 2,7 prišlo neskôr, toto je ešte MFM, ako diskety.
RLL radič s Western Digital čipmi som si na Arduine rozbehal úspešne, len s touto synchronizáciou 32D534 mám furt akési trable.
Naďalej by som používal WDčko, holt len u WD nefunguje prispôsobovanie - nemôžem ho naprogramovať na iný formát - tak ako tento radič. Keby fungoval s tými nulovými výplňami.
Ono keď sa to čiastočne na tú stopu chytí, potom ten separator prečíta zvyšok sektoru v pohode. Aj CRC kontrolný súčet sedí. Časovanie fázového závesu je teda správne, inak by to predpokladám "utekalo" (ten datasheet tam už začína pripomínať dizertačnú prácu).
Ak by som používal nesprávne kódovanie, tzn. na RLL záznam MFM radič - to by mi neprečítalo ani mäkké f.
No, doma tu mám akútny nedostatok presných trimrov... budem musieť spraviť ten 1FS DETECT a IREF dolaďovateľný. Zatiaľ sú tam odpory pre "typical application" pre 5Mbps dátový tok.
Či si tým pomôžem neviem - ale iné mi nenapadá. Toť:
Skúšal som rôzne šírky preambuly po nenulovom GAP (gap=tolerančná medzera), v datasheete uvádzajú ako príklad GAP 16 bajtov hodnoty 4E, preambula 13 bajtov núl. Funguje. Dokým je gap nenulový, funguje to až po 15 bajtov preambuly.
Keď má preambula 16 bajtov, ako to má SMEP, potom to už nezoberie. Tým duplom ak sú GAP samé nuly - to má SMEP tiežť. To potom bere asi ako dve preambuly po sebe, a nedokáže sa zasynchronizovať.
Asi vtedy dochádza k internému resetu toho flipflopu (sedemnásty bajt je už A1, ktorú nestihne spracovať).
Výstup /AMD (address mark detect) je vtedy rovný jak EKG mrtvoly, takže sekvencer (a Arduino) mi nemá čo čítať.
No a ak zapnem direct sync (EWCASM 1) -, to momente ako zapnem READ GATE (vstupné hradlo), okamžite zoberie prvú postupnosť bitov ako platnú. A začne sypať úplné hausnumerá. Boha krista mária
"preambulu si zdeteguj externe" => navrhni si vlastný fázový záves aj separátor dát od hodín
Ak by log. 1 značila bit 1, a log. 0 bit 0, no to ano, to by sa nám žilo. Je to žial trocha zložitejšie.
K tomu celému ešte: disk sa krúti, takže pôvodný záznam zapísaný 10MHz hodinami neni tak úplne desať.
ak som to spravne pochopil, tak ulohou je napasovat ten MFM radic na akekolvek ine pred-formatovane disky z inych pristrojov, kde sa data ukladaju v inom formate? To sa mi zda absurdna uloha, kedze ta synchronizacia tam bude uplne nahodna.
Pokusate sa rozbehat nejaky stary SMEP pocitac s vyuzitim tohoto radica? Snazite sa nahradit TTL orloj tymto cipom? Pouziva SMEP MFM? V com je odlisnost? V takom pripade chapem to cele usilie.
Vyzera to pekny projekt na dlhe zimne vecery, ak to je myslene na hobby. Mozno by som este pouvazoval nad niektorym z MFM radicov pre Floppy, tusim Intel 8272. Nieco sa mi mari, ze sa pouzivali aj v radicoch diskov PMD30 (tam mozno starsi model 8271). Schema bude na Internete, ak pomoze.
Prepáč, neštudoval som ten obvod do podrobna, takže ak sa mýlim, tak ma oprav. Zatiľ som to pochopil tak, že ten obvod obsahuje fázový záves, dekóder dát a detektor preambuly. Ak vypneš detektor preambuly, tak ti zostane len fázový záves a dekóder dát. Sype to bity, ale nevieš, kde je začiatok bajtu. No a k tomu si urob externý detektor preambuly napríklad s posuvným registrom. Je jedno, ako je A1 hodnota zakódovaná, nepotrebuješ ju dekódovať. Hľadj tú zakódovanú sekvenciu, ktorá obsahuje tu A1 hodnotu. Snáď vieš ako vyzerá, ak je pred ňou tá dlhá medzera. Alebo deteguj časovačom (trebárs 555) koniec dlhej medzery a jak sa objaví prvý bit, tak vieš, že začala preambula. Od toho okmihu narátaj čítačom (alebo hoc ďalšou 555) delay po začiatok dát.
Pokusate sa rozbehat nejaky stary SMEP pocitac s vyuzitim tohoto radica? Snazite sa nahradit TTL orloj tymto cipom? Pouziva SMEP MFM? V com je odlisnost? V takom pripade chapem to cele usilie. Vyzera to pekny projekt na dlhe zimne vecery, ak to je myslene na hobby.
Jasné že je to voľnočasová aktivita, na štyridsaťročnom diskovom zázname majlant netrhneš
Skôr sa jedná o spôsob dostať z toho disku data (zápis mi funguje, to je kategoria sama osebe - neštandardné počítanie CRC...).
Ten SMEP je klon PDP-11, má modul na harddisky a odzálohovať celý disk, priamo na tom stroji, cez sériový prenos trvá viac než osem hodín. Blbých dvadsať megabajtov.
S Arduinom sa to vepchá do bársjakého kompu do USB a je to za 15 minút cobydup. Len tieto nulové gapy robia problém. Musím niečo vyšpekulovať.
Ivan_Ryger napsal(a):
kde sa data ukladaju v inom formate? To sa mi zda absurdna uloha, kedze ta synchronizacia tam bude uplne nahodna
Nie tak úplne, takéto riešenia už existujú. Mojim cieľom to bolo odskúšať zo šuflíkových súčiastok - programovatelný radič zo starého PC. Sekvencer ide, dáta (keď sa chytia), sú platné. Už len synchronizáciu
I8272ka nepôjde, tá je zafixovaná na IBM floppy formát a k tomu obmedzená na prenosovú rýchlosť desaťkrát pomalšiu jak tento disk.
Tak potom na to treba ísť ešte jednoduchšie. Zavesiť na vstupné dáta časovač (trebárs 555), ktorý ak dlhší čas neprídu dáta, tak sám pošle pulz do /RD vstupu. Stačí nastaviť timeout časovača tak, aby bol dlhší než minimálna medzera, kratší než maximálna medzera a v násobkoch za posledným vloženým pulzom zostala aspoň minimálna medzera pred preambulou. Tým by sa zamedzilo resetu.
Ešte je otázne, čím je spúšťaný reset. Pokiaľ by bol púšťaný poklesom napätia na VCOIN, tak by stačilo zabrániť poklesu napätia na tomto vstupe pod určitú honotu. (Možno opačne, ak je logika opačná.)
VCOIN je spojený nakrátko s PDOUT; proti zemi je tam RC článok. Filter fázového závesu a zaujímavá matematika. Dosť možné, že by som to čítanie po zasynchronizovaní porušil - keď niečomu nie úplne rozumiem, používam odporúčané hodnoty
Ale dáva zmysel to, čo píšeš - umelo injektovať jedničky tam, kde sa predpokladá tá nulová tolerančná medzera a časovač vysadiť, kde sa predpokladá preambula - či po zasynchronizovaní, už keď sa čítajú bajty.
Bude tam trocha problém zistiť stav, kedy je RGATE aktívna, ale separator ešte neni zasynchronizovaný (neni tam na to navonok vyvedený signál). Arduino v nejakej čakacej slučke je na to pomalé, no a sekvencer mi ponúka až jednu jedinú z tých kvanta nôh pre "generické" použitie.
Druhá vec bude "narušiť" ten MFM datastream (na pár sto ns ho invertovať?); keďže databit 1 môže byť kľudne logická 0 alebo logická 1... v závislosti od toho, aký bit bol predošlý (a či vyžaduje hodinový bit.) Uf.
Zatial som pre odpory pre 1FS a IREF hodil trimre na "doladenie", a do menu spravil "debug" kde to číta stopu do aleluja a porovnáva časy.
Možno... to pôjde zladiť takto. Keďže ten IREF ovplyvňuje celý čítací oscilátor - chvalabohu nie ten zápisový.
A jak nie, tak potom už ten Gesswein. A nech to vezme čert
Matematika okolo fázových závesov nie je až tak zložitá, jak sa to traduje.
Vieš sa pozrieť osciloskopom na ten VCOIN, že čo sa na ňom deje, keď príde dlhá medzera a obvod sa zresetuje?
Arduino v "čakacej slučke" vie skontrolovať vstupný pin každé tri hodinové takty. Len čakaciu slučku nemôžeš ísať v pythone, ale musíš ju napíať v asembleri cez inštrukciu sbis následovanou inštrukciou rjmp späť na inšrukciu sbis.
S pajtnom daj svatý pokoj, toto je C++
Už keď som chcel obslúžiť hardwarové prerušenie, tak arduiňácky ISR ktorý som napísal v inline asembleri - od nábežnej hrany po prvú inštrukciu - zožral 6 µs. Inicializácia stacku, zachovanie registrov a celá tá opruz v pozadí.
Ako, ja nie som hardwarista ani v najmenšom slova zmysle, ale to je kurva pomalé - hneď 30 bitov fuč a to som ešte nespravil nič. S tým môžem leda tak dymové signály spracúvať, nie 40 ročný harddisk.
Musel som ísť do knižníc Arduina, vyhodiť rozdeľujúceho pavúka na attachInterrupt(), a dať direktívu ISR_NAKED. To mi dovolilo skresať to na pár stovák ns.
Späť k disku: prepísal som komplet jednu stopu nulami. Bez sektorov a dátových polí, bez adresných značiek, iba samé nuly - ako nekonečne dlhá nulová preambula, aby sa ten "input counter" mohol resetovať furt. Neviem, či k tomu ozaj dochádza, signál na to nemám, verím, že to tak je. Viera hory prenáša.
Zapnul Auto sync mode; povesil škopík na VCOIN. Je tam nemenná úroveň +1,7V so zvlnením okolo 100mV. Ditto u Direct sync. READ GATE (RG) celý čas zapnutý a nemenný.
Založen: Aug 16, 2022 Příspěvky: 882 Bydliště: Roztoky
Zaslal: pá únor 06 2026, 14:36 Předmět:
A co použít něco rychlejšího s STM32 (Black pill)? Vím že to má 3,3V logiku, ale jsou tam 5V tolerantní piny a výstupy se dají zapojit přes TTL hradla se SCHKO vstupem.
Veru, bude dôvod, prečo Gesswein na to má Beaglebone a celú demoduláciu/synchronizáciu robí softwarovo, na rýchlejšej platforme, bez hardwarových dekodérov. No čo no, snaha bola... takýto zádrhel človek objaví neskôr, tak to niekedy býva. Ak nepomôže directsync a doladiť to trimrami, dá sa tam to.
Inak by som vymýšlal ďalšie orloje z 555 - jednu na pulz, druhú na premlku, potom to správne sčasovať, aby to nekafralo buď záhlavia alebo dátové polia po zasynchronizovaní... A som u súdruhov z RVHP.
Nech celý ten BDSMEP vyskratuje a zhorí do rána.
Hlavne, že mali valuty na procesory AMD. Dať aj západný, zaužívaný harddiskový radič? Nie.
Vyjma tých nulových tolerančných medzier a nulových preambúl, asi aby sa to ľahko zasynchronizovalo, má ten diskový záznam každý pár bajtov navzájom prehodený.
A pri počítaní CRC do záhlaví a dátových polí sa neinicializuje register na samé jedničky alebo nuly... ale na hodnotu 6E958E56 pre záhlavia, a CF2105E0 pre dáta. Asi aby sa ľahko pamätali. V dokumentácii o tomto ani slova. Ale s tým som si vedel aspoň softwarovo poradiť.
Týpek, čo má ten SMEP, má radičov 5 a iba 1 (slovom jeden) funkčný. I to požičaný.
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.
FAQ
Hledat
Uživatelské skupiny
Profil
Soukromé zprávy
Přihlášení
No a problém bude určite riešiteľný elektronicky.
