Re: [SharpMZ] Chovani realneho FD radice u disket s "cizim" formatem

především - zkusil jsi, že ta Tvoje mechanika správně nabootuje "korektní" formát s 256B v základní stopě ?

Moje mechanika v pohode nabootovala z tech 3 disket, kdyz na nich bol standardni cp/m zavadec ... jakmile jsem na ty same 3 diskety nahral tvuj image, tak uz bootovat nechteji. Jine diskety samozrejme funguji normalne. Podle Zdenkova napadu jsem vyzkousel ty diskety opet nahrat do PC a byly funkcni. Jedine, co jsem s nimi nyni nezkusil je to, ze bych na ne pres cpcsisk opet nahral nejaky standardni Sharp format, nicmene po tom co jsem se podival do te ROM, na tu zminenou zaverecnou kontrolu, tak uz mi to prijde zbytecne.

A teď ke Tvé analýze: Je to zvláštní. Když čtu multisektor, tak mi musí přijít DRQ a pak DATA_LOST kdykoli přestanu číst. Prostě mi to nedává smysl... Použiváš řadič s WD2791, nebo WD2797 ? Ten má jeden bit přepínání délky sektoru. Ale nevím, jak by ten bit ovlivnil funkcionalitu v reále - tj. co by to způsobilo.

Mam tady 2 radice s WD2797. Tezko se naprazdno dohadovat nad tim, jak se v realu chova  nedokoncene multi blokove cteni. Jedno mozne vysvetleni bych tu vsak mel:

A) kdyz mas "rozecteny" sektor, tak ty datove bajty prichazeji pomerne rychle po sobe a stejne tak je potreba si je po vystaveni DRQ pomerne rychle prebirat, jinak prijde trest v podobe erroru

B) kdyz se pri multibloku dokonci precteni celeho sektoru, tak zakonite musi nejakou dobu trvat, nez zacte cteni dalsiho - radic si totiz inkrementuje interni sector_registr a pak zacne na aktualni stope hledat index sektoru s odpovidajicim novym ID - to muze zabrat klidne az 2 a mozna i 3 otacky disketou dokola (na tom je mimochodem zalozena ochrana Lemings, jejihz tajny sector nevyctes pres multiblock, protoze jeho ID je vyssi, nez je pocet celkovy sektoru :-)
Toto zabere tedy nejaky cas a pokud si vsimnes, tak Sharp ROM prave v tomto case posila do mechaniky prikaz k zastaveni a az potom se pta opetovne na status - 0xE5DD. Prijde mi tedy v pohode, ze realny radic v takovem pripade radic zadnou chybu neeviduje.

No a ted k te tve diskete: kdyz cte Sharp multiblokovym ctenim z MZFS a precte 256 bajtu, tak se nachazi v situaci B) a tedy do DRQ a nasledneho DATA_LOST mu zbyva opravdu hodne casu. Zatimco kdyz se z tveho sektoru precte jen polovina bajtu, tak jsi v situaci A), coz znamena okamzitou paniku, errory, zimu a tmu :)

Jen pro zajimavost: pokud by jsi cetl sektor z radice s HD upravou v rezimu, kdy ti radic posila misto DRQ interrupt, tak tam uz je to naprosta nestihacka - neco jak curaci zastavka v udoli chrestysu - neni cas zabyvat se tim, ze by se jeste pocitalo a kontrolovalo to, kolik bajtu ze sektoru je nacteno. V takovem pripade se musi kontrola prenosu udelat vzdy az po te co te radic propusti ze svych sparu.

Michal