[SharpMZ] Chovani realneho FD radice u disket s "cizim" formatem
Michal Hucik - ORDOZ
ordoz na ordoz.com
Úterý Leden 26 16:36:16 CET 2016
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
Daląí informace o konferenci SharpMZ