Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre> Radku, podle toho co ti vraci ten READ_ADDR to vypada, ze mam to cteni prilis pomale (DATA_LOST) - to znamena, ze to budu muset prepsat tak, aby se IORQ vykonal opravdu ihned, kdyz na radici identifikujeme DRQ, coz bohuzel asi znamena, ze ten driver bude muset prepisovat sam sebe mnohem vic, nez jsem mel v planu, aby se nevykonavaly zadne zbytecne jumpy navic a rozdil mezi HD ready a normalnim radicem bude tedy mnohem vetsi... Jina vec je ten READ_SECTOR, tam to hlasi RNF, coz by mohlo mit duvod v tom, ze u toho prikazu nastavuji overeni strany (to je zrejme dalsi vec, kterou emulatory ignoruji) a je mozne, ze tu stranu overuju spatne. Jiny duvod pro to RNF mne zatim nenapada ... Zkusim prolezt zdrojak cp/m 1.4 a porovnat to s tim, jak to delam ve svem driveru. Testovaci vzorek bych ti asi uz poslal mimo konferu, at s tim tady nestrasime. Michal Dne 1.1.2012 13:33, Radek Suk (sharpemu@pandora.cz) napsal(a): <span class="replyquote1">> > Ahoj Milane > > Tak jsem ti to vyfotil http://www.radeksuk.cz/sharp/smazat/IMG_1301.JPG > a vraci to EF,0,0 - toto ale dostanu tak z 20% pokusu. Podle toho > statusu to nenajde ten sektor. > > Vetsinou (asi z 80%) to nenacte ani ten Read Address a to vraci > FB,05,00. Zde jako kdyz vyskocis jeste nez prectes posledni bajt. > > Vzdy to vraci stejne hodnoty. > > Radek > </pre>