<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Dne 26.1.2016 v 16:00 Vaclav Peroutka napsal(a):<br>
</div>
<blockquote cite="mid:PJd.JIeR.23aa4j10F%7BF.1Mfue2@seznam.cz"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
především - zkusil jsi, že ta Tvoje mechanika správně nabootuje
"korektní" formát s 256B v základní stopě ?<br>
</blockquote>
<br>
<br>
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.<br>
<br>
<blockquote cite="mid:PJd.JIeR.23aa4j10F%7BF.1Mfue2@seznam.cz"
type="cite">
<div>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.<br>
</div>
</blockquote>
<br>
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:<br>
<br>
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<br>
<br>
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
:-)<br>
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.<br>
<br>
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 :)<br>
<br>
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.<br>
<br>
Michal<br>
<br>
</body>
</html>