OldComp.cz

Jo a jestli někdo potvrdí (dokáže) mou hypotézu zde http://oldcomp.cz/viewtopic.php?f=39&t=6733&start=810#p116401, že každý bezchybný přenos úspěšně chodí přes JP ERR45 a řekne mi i jak je to možné, že to funguje a data jsou OK, tak ode mne obdrží nějakou super značkovou láhev alkoholu! Zašlu v balíku klidně i ve vánočním balení.

Je veľký problém presmerovať to na voľné miesto, kde bude rutina ktorá spraví napríklad tón a farbu okraja podľa čísla chyby, a prípadne to do pamäte pripíše jeden byt s číslom chyby (vytvorí LOG)? Potom to skočí na pôvodnú rutinu. Nahrať do EEPROM, a odskúšať na reálnej mechanike. ...

pwramp provedl test. Díky jemu vím, že JP NZ ERR45 u coder1 nenastává. To ale znamená, že bit 6 i 7 nikdy není nulový zároveň. Tím pádem ale opravdu VŽDY read/write operace končí "malou" chybou (pouze bit 6 ST0 v jedničce). A aby se do registru A dostala nula, která znamená úspěch bez chyby pro vyšší podprogramy, musí být bit 7 ST1 v jedničce. Význam toho bitu je podle datasheetu End of cylinder. Buď je tedy zadrátovaný natvrdo, anebo se opravdu po každém načtení/uložení sektoru nastaví. Natvrdo si myslím to nebude, protože když je operace formát tak coderr dělá set 7,c.
Připravím si na to další test. Napadá někoho proč by end of cylinder řadič hlásil po úspěšném načtení/zapsání libovolného sektoru na stopě?

Edit: datasheet to vysvětlil. Mdos opravdu dává do příkazu číst pouze jeden sektor a zároveň jej označí jako poslední. Proto v ST1 bude vždy při čtení i zápisu sektoru bit7 nastaven a ST0 bude signalizovat malou chybu. U formátu to neplatí, tam je příkaz na formát celé stopy a tak si codder ten bit uměle nastaví. Také při formátu ignoruje ST0 registr úplně (spoléhá až na verify). Tak "záhada" objasněna. Bohužel tu pomalost mdos1 disket to nevysvětluje. Udělám test na který pokus ten sektor vlatně úspěšně načte. Tipuju, že u mdos2 disket to bude hned první/druhý kdežto u mdos1 disket na ty poslední (třetí až pátý).

Co přesně mám chápat pod tímto?
GPL ( GAP LENGTH) : GPL stands for the length of Gap 3. During the FORMAT Command. It determines the size of Gap 3.
MDOS2 cpe řadiči při čtení/zápisu dat GPL 10 (dekadicky).

MDOS1 dělá standardně (FORMAT příkaz v Basicu) úvodní mezeru na stopě (index pulz) 10 bajtů. Dále mezeru mezi sektory 40 bajtů.
MDOS2 standardně formátuje GAP3=80 (dekadicky) do devíti sektorů na stopu a GAP3=35 při desíti sektorech na stopu

Může toto být důvod toho přibrzděného čtení/zápisu?

Pustil jsem se i do kontroly samotných příkazů řadiči. Narazil jsem na zajímavost, že GM82c765b nemá INT STATUS definován s kódem 8 jak předpokládá MDOS2. Řadiče wd37c65c i Intel 8272 to mají OK, ale ten GM82c765b popisuje jen kód 7, přičemž se chová úplně jinak. Ten kód 8 ale musí také umět (ačkoliv v datasheetu chybí), protože jinak by MDOS2 nefungoval (hlásil by permanentní seek error).

Zase si odpovím sám
Dle datasheetu je GAP3 myšlena mezera mezi sektory na stopě (přikládám i obrázek). pwramp testem dokázal, že pokud se volá DREAD bez zbytečné omáčky okolo, tj. nepřepočítáváme logický sektor na fyzický a neděláme plno jiných "zbytečných" věcí, ale čteme stylem jako při verifikaci sektor po sektoru, stopu po stopě, tak ke zpomalenému načítání MDOS1 disket nedochází! To je pro mne jasným důkazem, že řadič je OK a nestíhá pouze MDOS. Trochu jsem počítal. Pokud to mám správně pak platí:
1ms ZX CPU = +-3500T
řadič vytáhne 31250 bytes za 1000 ms, takže 1 byte = 0,032ms = 112T na 1 byte
Pokud GAP3 má velikosti 40 bytes tak 40*112 = 4480T
u GAP3 35 bytes je to 3920T
a u GAP3 80 bytes 8960T
T-čka vlastně určují čas, který má MDOS na to, aby zahájil fyzické čtení/zápis (instrukce IN/OUT) dalšího sektoru v pořadí. Pokud to nestihne, sektor hlavě ujede a čeká se na další otáčku. Z toho ale vyplývá, že problém by měly mít i všechny diskety s deseti sektory na stopu naformátované na MDOS 2.x (např. 80x10). Kdo se nudí nechť vyzkouší - formát 80x10, následně co nejvícekrát SAVE * "xxx" CODE 0,65024 a pak disketu zkopírovat TOOLSem nebo MFC na jinou disketu s normálním formátem 80x9. Mělo by platit, že soubory jsou čteny z 80x10 mnohem pomaleji než zapisovány na 80x9. Při formátu s deseti sektory na stopu bylo by asi lepší zvolit jiný interleave už při formátování (pořadí sektorů na stopě přehodit z 1,2,3,4,5,6,7,8,9,10 na 1,6,2,7,3,8,4,9,5,10).

Jinak ty datasheety obsahují chyby. Nejvíce asi ten GM82c765b, ve kterém jsou pomotané i kódy příkazů (zřejmě psali stylem CTRL+C a CTRL+V). Čert, aby je vzal!

Presne tento problem som kedysi riesil na MB02 pri prechode na dalsiu stopu. Pri MDOSovej standartne formatovanej diskete 80x9 je na konci stopy kopec miesta (viac ako jeden sektor, kedze sa da naformatovat na 10 sec/trk), a pokym sa disketa stihne otocit o toto miesto, radic stihne posunut hlavicku na dalsiu stopu a citanie hned pokracuje. Avsak pri 10 sec/trk je na konci stopy uz prilis malo miesta (malo casu) a pri kroknuti na dalsiu stopu prvy sektor na tejto stope "ujde" a musi sa cakat na celu otacku diskety.
Kedze ja som chcel aby sa citalo/zapisovalo rychlo, a pritom aby disketa bola vyuzita co najlepsie (v tomto pripade protichodne poziadavky), tak som to vyriesil tak, ze sektory na dalsej stope su "pootocene" o jeden sektor voci predchadzajucej. Takze ked sa urobi krok, akurat pod hlavicku pride spravny sektor.

Mozno by takato uprava formatovania diskety v MDOSe mohla pomoct...

Pokud je to způsobeno seekem pak ano, toto je řešení. Já se ale obávám, že to nastává i na stejné stopě. Také Mdos tuším rozkládá sektory při formátování na každé straně jinak, takže při seeku by paradoxně tento problém nastávat neměl. Kuknu do výpisu, zda se nemýlím.
Jako hlavní brzda je u mdos 2.0 každopádně přepočet logického sektoru na fyzický. Jenže to jsem v 2.1 opravil. Nechce se mi ty Tčka (od dokončení načtení jednoho sektoru po záčatek načítání druhého) popočítat, ale asi budu muset
edit: je to tak, liché a sudé stopy jsou "osektorovány" jinak. Nehraje se na strany diskety, ale na sudé/liché, takže i jednostranný formát bude mít takovéto číslování sektorů. Má to MDOS1 i 2 (jde o to násobení čtyřmi v kódu)

Ano, prepocitat logicke cislo sektora na fyzicke zaberie obvykle viac nez trva medzisektorova medzera. Pokial si dobre pametam, MDOS si predpocita cisla sektorov v ramci jednej stopy a potom ich nahrava hned za sebou. A prave ked prepocitava cisla pre dalsiu skupinu sektorov, moze mu nieco ujst.
Na MB02 som toto nastastie nemusel riesit. Sice ani tam nestiham prepocitavat sektory v medzisektorovej pauze (navyse, pri HD ta pauza uplynie 2x rychlejsie), ale tam sa samotny prenos dat robi cez DMA, takze CPU ma chvilku volneho casu, a v tejto chvilke vzdy prepocitam cislo nasledujuceho sektora. Takze cely subor sa vzdy nahrava/uklada maximalne rychlo, bez akychkolvek (zbytocnych) zdrzani.

Hloupé to je, ale v praxi při normální práci (load, save) to až tak nevadí. Práce se jeví plynulá (na 80x09 s dost velkou Gap mezerou... , a oproti kazeťáku naprosto jiný rychlostní level. Kopírovací programy jako MFC a TOOLS mají Boot, Fat i Dir v bufferu neustále takže kopírují plynule. Jen je nepříjemné, že na MDOs 2.x nestíhají tu GAP mezeru s poloviční velikostí (35 u 80x10, 40 u MDOS 1 disket). MFC si sektory nepředpočítává, poctivě vezme z fat, přepočítá na fyzický a volá Dread. Tools bych řekl to samé. Opravdu bych chtěl vědět kolik Téček je k dispozici od dokončení čtení jednoho sektoru k zahájení čtení druhého při Gap 35. Pokusíme se to s pwramp zjistit.

Další mé výpočty (počítané pro MDOS 2.0 a snad spočítané správně) říkají, že od zavolání DREAD až po první načtený byte to CPU trvá 2223 T. Po načtení posledního byte ze sektoru následuje 949 T (načtení resultu z řadiče a jeho vyhodnocení) a až pak se řízení vrátí programu, který DREAD zavolal.
2223+949 = 3172 T
3920-3172 = 748 T
748 T je při formátu 80x10 čas na to, aby ovládací program vyhodnotil, že operace proběhla bez chyb, vzal další sektor z FAT, přepočetl ho na fyzický a zavolal znovu DREAD. 748 beru jako orientační hodnotu, od které je možno se odrazit pro další testing Ten výpočet pro GAP 35 (3920T) je teorie odvozená z rychlosti řadiče uváděném v datasheetu a z rychlosti Z80 CPU. Každopádně ten čas je tak krátký, že se v něm nedá téměř nic stihnout a sektor prostě musí hlavě ujet. Čas 3172 T jen pro režii při read/write sektoru je dost, odhadoval jsem, že bude menší. Při počítání jsem našel nějaké malé možnosti pro optimalizaci, ale jsou to drobečky. Ono by to chtělo zoptimalizovat tak na polovinu původního kódu, aby to mělo efekt...