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

[Michal Hucik - ORDOZ]

Dne 26.1.2016 v 16:00 Vaclav Peroutka napsal(a):
> 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

------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20160126/b45dd757/attachment.html