OldComp.cz

Na MB02 som problem detekcie DD / HD diskety riesil tak, ze ako prve sa skusa disketa nacitat v hustote, ktora bola v danej mechanike naposledy pouzita. Cize ak uzivatel pouziva nejaky typ diskiet, tak mu to ide hned a bez zbytocneho zdrzovania, ak vlozi disketu s inou hustotou, tak prve nacitanie je dlhsie (musi skusat obe hustoty, az sa "chyti") ale dalsia praca s touto disketou je uz rychla. S touto a so vsetkymi dalsimi s rovnakou hustotou zaznamu.

Nieco podobne by mohlo byt aj v MDOSe 2.x - bude si pre danu mechaniku pametat, ake cislovanie stran bolo naposledy pouzite a toto rovno pouzije pri ready teste a dalsich operaciach. Tym padom tiez nikdy nenastane ta pauza v polovici vypisu pri CAT.

Ano. Len som zdoraznil, ze ten test by sa robil uz pri ready teste na zaciatku samotnej operacie, nie az v priebehu. Napriklad CAT cita boot sektor a potom adresarove sektory zo strany 0 a potom prejne na druhu stranu. Ak je druha strana cislovana zle, tu sa na chvilku zastavi. Ak by sa test urobil uz pri zaciatocnom ready teste, v tomto okamihu by uz vedel ake ma cislovanie a uz by sa nezdrzoval a rovno cital dalsie sektory z druhej strany so spravnym nastavenim cislovania.

To ano, ale - kedy netreba ? Vypis katalogu cita aj z druhej stopy, a pri citani / zapise suborov dlhsich ako 4.5 kB sa tiez urcite cita aj z druhej stopy. A pri suboroch kratsich je napolovicna pravdepodobnost ze tiez. Navyse, bolo by to iba po prvom vlozeni diskety formatovanej v MDOS1, dalej by to uz o nic viac nezdrzovalo vdaka odpametaniu.

Celkom ina otazka je co je lepsie z psychologickeho hladiska - ci obcasne dlhsie cakanie na zaciatku, alebo uprostred vypisovania. Podla mna, na zaciatku je to take implicitne, tam sa ocakava ze sa najprv musi seekunut na nulu (ak nie je), nacitat boot, fat (no, vlastne v MDOSe pre samotny vypis suborov netreba citat FAT). A potom uz vypisovanie ocakavam s minimalnymi pauzami (napr. dve desatiny sekundy) pre citanie dalsieho sektora katalogu. Ale ked sa mi vypis zasekne na dlhsie (FDC radic po sekunde zahlasi ze sa nepodarilo nacitat sektor a citanie sa opakovat) tak je to take .... viac stresujuce

Na WD2797 by som to vedel, ale zrovna tam to nie je treba...
Nie, ziadne citanie navyse, ale rutinka RDID by citala ID rovno z druhej strany, cim by sa zaroven zistilo, ako je ta druha strana cislovana.

Takto to i dělá originál mdos 2.0, akorát tím vždy při ready testu posílá hlavu HOME. No a ještě tu samozřejmě máme jednostrannou disketu, kde bychom ten test rozhodně dělat neměli . Myslím, že se mi to podařilo vymyslet lépe. Ten kyvadlový princip co navrhnul PotPalo je dobrý, a ještě jsem přidal, aby tedy v případě jiného číslování vyhodnotil Mdos 2.2 problém mnohem rychleji/dříve. Mělo by to fungovat a ta prodleva už nebude taková do očí bijící. Mělo by to působit téměř plynule. Snad.

Jak jsi na tom? Zavři se v práci na záchod a nevylez dokud to nebudeš mít vymyšlené. Jinak tam zůstane můj PRINT * PEEK# n

Super! Poslal jsem ti soukromou zprávu. Aniž bych se o to snažil, zůstalo mi 128 bajtů volného místa. Náhoda? Nevěřím tomu! Pořadové číslo verze je 129 (ale správně mělo být 128, protože jsem před časem o jedničku omylem při SAVE přidal).

Podělím se s Vámi o další zajímavé zjištění ohledně čtení disket z MDOS1 na MDOSu 2.x
MDOS 2.x čte diskety MDOSu1 výrazně pomaleji a to i když jim natvrdo podstrčíme jako číslo strany hodnotou 2. Podle mého názoru to způsobuje právě index pulz. I ve skalici to věděli, protože MDOS 2 vybavili "natvrdo" 5ti pokusy načíst/uložit sektor. U MDOSu 1 bylo zvykem počet pokusů určovat v rutinách registrem E (ve všech komentovaných výpisech označeno jako počet opakování, toto je však špatně, nejde o opakování ale o celkový počet pokusů). V MDOSu 1 si byli dokonce tak jisti bezchybným provozem, že často dávají hodnotu 1, tj. jeden pokus. Na druhou stranu tento optimismus vůbec nevadí, protože pořád je možné vypsat chybové hlášení s možnosti P/R (retry) a tak celkový počet pokusů je dán vlastně jen vytrvalostí uživatele. MDOS 2.0 má však natvrdo nastaveno 5 (registr E si tedy nepřebírá, ale nastavuje si ho sám úplně na té nejspodnější rutině - #238B, kterou žádná aplikace nedokáže ovlivnit). 5 pokusů očividně stačí, aby MDOS1 disketa fungovala i tam.

Tímto příspěvkem chci jen říct, že je lepší mít diskety naformátované "standardním" způsobem a kochat se plnou rychlostí než trápit řadič neustálým opakováním operací

Nemyslim. Hardware s novym intel radicom ma specialne index pulz upraveny, aby neblokoval citanie prveho sektora pri prilis malej a norme nevyhovujucej medzere medzi indexom a tymto prvym sektorom. Alebo mi nie je celkom jasne, co si myslel.
Pozri lepsie do specifikacie WD2797. Tento radic pri prijati prikazu na citanie znacky alebo sektora spusti citanie, a pri cakani na data si zaroven interne pocita index pulzy. Ak prejde presne 5 index pulzov, a citanie sa ani za tento cas nepodari, tak vyhlasi Record not found. Takze aj ked sa v MDOS1 vola citanie iba raz, v skutocnosti na urovni FDC radica dojde k piatim pokusom o citanie.

Tím HW myslíš novou d80mini anebo i kompakty s GM82c765b ze skalice? U toho kompaktu opravdu každá originální disketa od Proximy měla všechny I/O operace takové přibržděné. A že jsem jich měl opravdu dost, abych mohl vyloučit náhodnou chybu. Myslel jsem, že je to tím číslováním stran, ale musí tam být opravdu ještě něco jiného. Když ne ta mezera tak co?
To jsem netušil, díky za objasnění. Máš můj THANX

Beru zpět, těch 5 opakování natvrdo je o tom co píše Busy (v MDOSu 2. se akorát dělá softwarově), kousek dál je i to standardní opakování, které si může určit programátor registrem E (#23B6). Funguje to tedy stejně (podobně) jako na MDOS1

edit: pwramp však při testování mdosu 2.2 (pravděpodobně omylem) udělal jedno formátování tak, že natvrdo zapnul MDOS1 emulaci strany, tj. že vždycky bude mdos 2.2 posílat řadiči stranu 1 jako hodnotu 2. Neuvědomil si však, že formátování MDOS 2.2 vždy dělá správně, tj. i se správnou hodnotou strany (tj. 1 je opravdu 1). Sice jsem to v pokecu napsal, ale asi to přehlédl. Každopádně výsledek je ten, že emulace se aktivovala až při verifikaci (čtení sektorů). Tím pádem se nepodařilo sektor nikdy přečíst (řadič tam dostává 2, ale formát před tím tam dal 1). Zajímavé je však to, jak dlouho ta verifikace trvá, na jedné stopě (tj. obě strany) minutu! To je +- 3 sekundy na jeden sektor (sektorů je 18 pro jednu stopu). Verifikace probíhá s jedním pokusem (E=1) a na nižší úrovni je těch pokusů 5 na jeden sektor jak jsem psal v minulém příspěvku. Jak je možné, že programu #2387 těch 5 pokusů tak dlouho trvá? Beru i to, že těch 5 pokusů sežere 5 celých otáček diskety, ale i tak se mi to zdá moc a smrdí mi to nějakou čekací smyčkou jinde (že by příkaz nešel odeslat a mdos tak dělal i reset řadiče?). Já toto zpomalení znám ze svého kompaktu při těch originálních disketách od Proximy. Toto není náhoda. Rád bych tomu přišel na kloub.

Prosím řekněte mi, že to tak není! To "jp nz,ERR45" (chyba internal error). Program ji bude vyhazovat i když bude registr B na začátku (jde o FDD StatusRegistr0), hlavně jeho bity 7 a 6 v nule. To by znamenalo, že po každém načtení / zapsání sektoru, které proběhlo naprosto bez chyby se tam skáče. V tom případě nechápu jak MDOS 2.x může fungovat a načítat správná data. ERRR45 je program na výpis chyby. Možná díky jedinečné hvězdné konstalaci v době volání výpisu chyby (zásobník, zakázané přerušení, "jedinečnému" ready testu mechaniky) to nějak ustojí. To mi teda hlava nebere. Kdyby se ten CODERR volal jen po chybě, chápu, ale on se volá vždycky po dokončení I/O operace!

podla komentovaneho vypisu mdos20.lst (z doc/for_coders adresara balika mdos3) sa mi javi, ze CODERR sa vola len z rutiny DRWLOO, kam sa skace iba z DRWER0 pri CRC error (podla komentara). ale aj tak mi to cele pripada ako dead code lebo nevidim kedy sa skace na DRWER0 inak ako v slucke z DRWLOO (teda pokial je v tom vypise cela rom a nie su tam niektore casti nedisassemblovane alebo ak skok na rutinu nie je robeny nejako vypoctom adresy kam skocit, takze v kode nevidno priamo navestie).

EDIT: aha, tie "db 0" pred DRWLOO, to bude asi "zakomentovany kod", takze sa na DRWLOO da dostat tadial. ale predtym je nejaky komentar o "DMA", tak sa to tam mozno nestihne dostat a vykonavanie sa (pri uspesnom nacitavani) stihne odklonit?

A mozu byt za normalnych okolnosti (uspesna operacia alebo nejaka bezna chyba CRC / NotFound) oba tie bity v nule ?

Castokrat pomoze si vedla seba dat vypisy oboch MDOSov (1.0 + 2.0) a porovnavat.
Rutnka CODERR sluzi na prevod statusu z WD36c65 na status WD2797 a podla tohto to vyzera, ze bity 7 a 6 ine ako 0 a 1 nacitane zo status registra ST0 znamenaju nejaku vaznejsiu chybu, nez len bezne chyby zapisu/citania a v takom pripade nie je mozne danu chybu reportovat status registrom povodne pouzivaneho WD2797.
Ale WD36c65 nepoznam, takze neviem toto posudit.

Význam jsem psal již tady http://oldcomp.cz/viewtopic.php?f=39&t=6733&start=780#p115453
pokud je v jedničce jen bit 6, mělo by se provést vyhodnocení chyby (CRC, secnotfound, write protect)
pokud je v jedničce i bit 7, měl by se vyhodit internal error
pokud je však bit 7 i 6 v nule, operace byla dokončena úspěšně a není třeba vyhodnocovat chybu.
Proto mě to zaráží. Když by se CODERR volal jen po chybě, pak je to naprosto v pořádku, ale on se volá vždy, takže to musí při bezchybných operacích skákat na ERR45.

Pokud je řadič zdravý a posílají se řadiči i správné parametry (což se posílají), tak mohou nastat jen tyto kombinace:


Ještě nevím jak, ale domnívám se, že v tom volání err45 (které při volání pouze z toho coderr záhadně nic nevypíše) se program dostane na 25B6 a RETem se vrací za call CODERR. V reg A je nula, čili signál přenosu bez chyby, proto na chybu nikdy nikdo nenarazil. Internal error u zdravého řadiče nikdy nenastane (aby byl bit 7 v jedničce), čili dokonale zamaskovaná chyba. To přerušení tam bude hrát svou roli - viz pořád má neznámá - to pomalé čtení MDOS1 disket o pár příspěvků výše...

Přepracoval jsem to (CODERR, od CODER2 je to už původní). Na vstupu je v B status registr 0 (ST0) a v C je status registr 1 (ST1). Originál MDOS 2 na výstupu vrací v registr A jen jinak uspořádaný ten ST1, A=% 0 c1 0 c0c2 c5 c4 0 0. Já to ponechávám, řadič stejné žádné další chyby nemá. Pouze na začátku testuji i ST0. Zahrnuju bit 7,6 a 4 (4 je EQUIPMENT/FAIL error). Pokud jsou všechny nulové, je předpoklad, že operace proběhla bez chyby ale pro jistotu nechám ještě ST1 vyhodnotit (měl by ale vždy vracet také nulu). Když je v ST0 hodnota 64 (tj. svítí pouze bit 6), tak jde o standardní "malou" chybu, kterou umíme vyhodnotit (write protect, sec not found, crc error). Není-li 64 (tj. svítí i bit 7 anebo 4) pak bude vyhozen Internal error (skok na CODER4, A=3). U formátování (reg. D = 2) by teoreticky neměla nastat jiná malá chyba než Write protected (skok na CODER3, který tu neuvádím).
Výstupem je registr A s kódem chyby, který je vyhodnocován ve vyšších rutinách v registru C (bread, bwrite)


Pokud chce někdo otestovat, napište mi soukromou zprávu. Nechci zatím veřejně vystavovat, protože by to mohlo napáchat škody pokud jsem se někde seknul...