2M versus XDF

Naprostým unikátem v plnění disket daty byl program 2M a později 2MGUI od jistého španělského studenta jménem Ciriaco García de Celis. Tomu se podařilo ovládnout disketovou mechaniku a vyždímat z floppy řadiče maximum možností. Jeho technika formátování disket se později objevila i v OS/2 3.0 ve formátu IBM XDF s tím, že OS/2 měl pro svůj specifický formát přímo podporu, zatímco diskety naformátované programem 2M nepodporoval (takto byly formátovány diskety, na nichž se OS/2 3.0 distribuoval, byla to taková zajímavá forma ochrany proti kopírování, výrazně vymakanější než u Microsoftího DMF).

U 2M šlo v zásadě nejen o to srazit mezery mezi sektory na nějaké snesitelné minimum, tak se ostatně dělaly diskety s 21 sektory na stopu. 2M navíc uměl disketu zformátovat tak, že používal jednak jinou velikost sektorů než klasických 512 bajtů, ale především uměl na jednu stopu nacpat několik sektorů různé délky. Stejně na to šel XDF formát, akorát používal jiný počet jiných sektorů.

Klasický formát s 21 sektory na stopu dokázal na takovou stopu dostat 10 752 bajtů (všechny sektory mají 512 bajtů). Maximem pro 2M (nikoli 2MGUI, ten na to šel ještě drsněji) však bylo nacpat na jednu stopu 11 776 bajtů, tj. jako by na disketě bylo 23 sektorů na stopu. Navíc pro zachování kompatibility a možnosti z takové diskety bootovat byla první stopa na první straně naformátovaná normálně (v boot sektoru byl mimo jiné zavaděč podpory pro 2M diskety, takže i zbytek nestandardně naformátované diskety byl při bootování přístupný).

Jak to udělal? Celkem kouzelně. Na stopu dal 7 sektorů:

• 5 sektorů mělo velikost 2 048 bajtů,
• 1 sektor byl 1 024bajtový
• a 1 byl 512bajtový.

To dává dohromady zmíněných 11 776 bajtů. Protože ale souborový systém nemůže mít každý sektor jinak velký, zajišťoval rezidentní „ovladač“ zpracování clusterů nastavených na patřičnou velikost. Velikost clusteru byla 1 024 bajtů, tzn. že při přepsání jednoho takového clusteru musel ovladač načíst celý 2 048bajtový sektor, půlku v něm změnit a zase jej celý zapsat. Zápis tedy mohl být pomalejší, pokud se pracovalo s menšími než 2KiB bloky dat.

Porovnání formátu 2M a XDF (zdroj: 2M-INFO)

Formát XDF je podobný, ale řeší to jinak: na stopu nacpe čtyři sektory:

• jeden 8KiB,
• jeden 2KiB,
• jeden 1KiB
• a jeden 512bajtový.

Navíc byly sektory číslovány velmi nestandardně, pro MS-DOS se kvůli výpisu obsahu adresáře používaly na první stopě sektory č. 1 až 7 a pro OS/2 od 128 výš (ty MS-DOS neviděl). Další stopy měly jen ty sektory s vyššími čísly.

Struktura formátu diskety s OS/2 3.0 (zdroj: 2M-INFO)

2MGUI

2MGUI, jak bylo řečeno, na to šel ještě drsnější metodou. V zásadě by se dalo říci, že „uměl využít neformátovanou kapacitu“, ale není to tak úplně přesné. Kousek z té „neformátované“ kapacity musel být vždy využitý na identifikaci sektoru a asi i CRC (byť o použití CRC mám v případě 2MGUI přeci jen pochybnosti, spíše si myslím, že si program CRC řešil v rámci datové oblasti po svém). Bez identifikace sektoru to každopádně nejde.

2MGUI - formátování diskety

Kdybychom to chtěli dotáhnout ad abusrdum do úplného maxima, a 2MGUI to skutečně uměl, byť to nebylo výchozí chování, dalo se na disketu nacpat ještě trošku víc. Už to ale záviselo na tom, jak dobře je udělaná disketová mechanika. Kvalita mechaniky nemá na čtení vliv, protože při čtení se časování odvíjí přímo od značek zaznamenaných na disketě, takže kdyby se disketa otáčela o něco rychleji nebo o něco pomaleji, tak je to jedno, řadič by si s tím poradil, protože sleduje to, co je na disketě (je tam samozřejmě určitá tolerance, myslím, že 5 %, takže zase úplně libovolně rychlá či pomalá mechanika být nesmí).

Jenže při zápisu se ty značky teprve vyrábí a tak se časování odvíjí právě od řadiče (ten generuje takt, který je v zásadě na všech řadičích stejný). Počet otáček za minutu je definován standardem na 300, takže jedna otáčka by měla trvat přesně 200 milisekund. Jenže ono se to v praxi o nějaké ty desetiny milisekund liší, tzv. „horší mechaniky“ se otáčejí o ždibínek rychleji (takže zvládnou otáčku za 199 milisekund a nějaké drobné), zatímco „lepší mechaniky“ se naopak točí pomaleji, takže ke 200 ms přibudou ještě nějaké desetinky.

Proč je mechanika točící se pomaleji označena za lepší a ta rychlejší za horší? Protože mechanika točící se pomaleji dokáže zapsat na jednu otáčku více dat. Pokud taková mechanika zformátuje disketu na fyzické maximum, pak ji „horší“ mechanika sice přečte, ale pokud na ni bude chtít zapisovat, její rychlejší otáčky způsobí, že si koncem stopy přepíše její začátek a data tak vlastně rovnou zničí. Obráceně to problém není, mechanika naformátovaná na „horší“ (rychlejší) mechanice jde v pohodě přepsat na „lepší“ (pomalejší), nanejvýš mezi stopami bude drobná mezírka navíc.

2MGUI - test maximální kapacity v konkrétní mechanice

2MGUI umí při spuštění s parametrem /TEST otestovat rychlost mechaniky a zjistit, jaké absolutní maximum dat dokáže daná konkrétní mechanika nacpat na jednu stopu. Test je samozřejmě destruktivní, tzn. maže data na disketě, protože si musí metodou pokus-omyl vyzkoušet, kolik dat vlastně na stopu dokáže dostat. Pak vysype nějaký výsledek, přičemž údaje z tohoto výsledku pak lze použít pro „ruční vyladění“ formátu diskety na maximum skrze příslušné parametry na příkazovém řádku. Jestli jsem to ještě neřekl, tak 2M ani 2MGUI nemá GUI (GUI v názvu programu značí Guinness), pracuje se s ním pouze skrze příkazový řádek. GUI má doplňkový program 2M-INFO, jehož součástí jsou nástroje 765DEBUG a FDTR (a čerpá z něj i tento text).

765DEBUG - Struktura formátu diskety s maximální kapacitou

Právě pomocí 765DEBUGu jsem zkoušel zjišťovat, jak je to vlastně s tím 2MGUI formátem. Je to velmi zajímavé: po chvilce zmatení při pohledu na výsledek člověk nakonec dojde k závěru, že 2MGUI vlastně zformátuje disketu tak, že každá stopa má jen jeden sektor, ten má pro jistotu (aby disketa nebyla normálně čitelná) označení 0 (což je mimo pravidla, protože sektory se číslují na rozdíl od stop a hlav od 1) a velikost sektoru je 16 384 bajtů (16 KiB). To je samozřejmě více (značně více), než je skutečná kapacita stopy (na stopu se opravdu tolik dat normální mechanikou nacpat nedá, ani tou nejlepší z nejlepších). Fyzicky tak vlastně sektor na stopě nemá svůj konec.

Takže je jasné, že vyjma identifikace musí program všechny nezbytné záležitosti pro udržení spolehlivosti sektoru dodělat sám v rámci datové části sektoru a přidat vlastní identifikaci typu „kolik vlastně chceme, aby měl sektor dat“, přičemž to ani nemusí být nějaké „kulaté“ číslo, prostě jak to vyjde. Disketa je pak brána spíš jako „pásková jednotka“ – kopice „RAW sektorů“ (co sektor, to stopa), ze kterých rezidentní ovladač dělá sektory logické a z nich pak tvoří clustery. Při přepisu jednoho clusteru se v lepším případě přepisuje jedna fyzická stopa, v horším dokonce dvě – jeden logický cluster se totiž může rozkládat na konci jedné stopy a začátku stopy následující.

Z hlediska principu fungování diskety jako takové a klasického disketového řadiče zkrátka víc dat na disketu dostat nejde. Pak už je to o disketové mechanice, čím se točí pomaleji, tím dokáže na disketu nacpat víc dat :) (samozřejmě v rámci oné 5% tolerance v rychlosti otáček).

FDTR - přenosová rychlost dosažená na disketě zformátované na maximální kapacitu

Ať tak či onak, mně se v praxi podařilo v běžné „horší“ mechanice naformátovat disketu, která měla volnou kapacitu pro uživatelská data 2 067 456 bajtů. Použil jsem k tomu 84 stop, na každou 12 354 bajtů, tedy pouze necelých 8 KiB je režie. Jak je vidět, na disketě je místa, že by se tam dalo tancovat. Mimochodem nevýhoda 2MGUI je ta, že pro takto naformátované diskety vytváří další virtuální jednotku, takže se nepracuje s disketou A:, ale např. D: (aneb první volné písmenko za pevným diskem). Je to proto, aby se taková šílenost nedala považovat diagnostickými programy přímo za disketovou mechaniku, ale za obecnou jednotku s výměnným médiem.

2MGUI - disketa zformátována na maximální kapacitu

Finta programů 2M a 2MGUI byla navíc v tom, že dávaly mechanikám takové parametry, že pak nebyl např. problém s kopírováním disket přes klasický DOSový program Diskcopy (za předpokladu, že měly obě diskety nachlup stejnou kapacitu) a žádné problémy na takto naformátovaných disketách neshledával ani Scandisk.

V příštím dílu…

Příště se podíváme na další specialitku ze světa floppy: disketovou mechaniku pro 2,88MB diskety. Věnoval mi ji jeden čtenář, kterému velmi děkuji. Dozvíte se mimo jiné, proč použití speciálních formátovacích programů s touto mechanikou nebyla žádná legrace. Povíme si, čím byla 2,88MB disketovka tak zvláštní.

Bude-li mít tento seriál dobrou čtenost, vyjde ještě i díl třetí, v němž se podíváme na další raritu ze světa floppy. Oč půjde, si zatím nechám pro sebe.

• Druhý díl: Retro Floppy Test II: jak to bylo s 2,88 MB disketovkou (7. 8. 2013)
• Třetí díl: Retro Floppy Test III: 120 MB na disketě s LS-120 disketovkou (12. 8. 2013)