Dehogy. Az mar a FAT resze,

Ok, de akkor a kérdés másik része még mindíg él:

Ha a WD elvárja valahol a CRC bájtokat, akkor ahova ő (WD) írja/olvassa a CRC értéket ( zozo hekkje nélkül  ), az egy másik IC -nek miért lesz jó ? A CRC érték letárolásához is van egy szabvány, amit a WD (és mindenki más is) tulajdonképp csak megvalósít ? De mi van ha valaki nem CRC -s biztosítékot akar ? Akkor az majd nem lesz kompatibilis a lemezeinkkel, de az iparban akkor is ez terjedt el, vagy mi ?

Értem hogy a szektorokba írt formátum már FileSystem függő dolog, de a szektorok maguk meg ugye WD függőek ... de nem mindenhol WD van ... nem ?

Így van, itt linkeltem is a szabványokat.

Ó, babám fsza ! Ennyi szirszart elolvasni, és megérteni, és akkor már képes is vagyok egy redvás szektort beolvasni egy lemezrol ... Hát ez király ...

Nem véletlenül volt a világon mindíg csak 3 ember, aki értett a hardverekhez.

Na ezeket én most mély tisztelettel nem tanulmányozom át ... Ha majd szereztem floppy -t, akkor maradunk a kérdezősdinél ... Még jó hogy nem akartam nekikezdeni megértéssel, jó lesz az az élő floppy -val kísérletezgetős megoldás is.

És akkor aki írta a WD kezelőt az ep128emu -ba, az ezeket mind áttanulmányozta és megértette ?

Vagy tulajdonképp most így belegondolva, lehet hogy pont ez a rész hibádzik most az emu WD kódjából, nem ?

Tehát ha belegondolunk ez a CRC -s kezelés valahol megtorténik a PC lemezkezelőjében, de mi nem közvetlen azzal kommunikálunk, hanem egy win file API -val, ami nyilván valahogy majd elnyeli azt, hogy X sectorokban CRC hiba van, es vagy nyujt a hibákról valami információt, vagy nem, ha nyújt, akkor majd azt kell kiolvasni, ha nem nyújt, akkor nekünk kell a CRC  tesztet a szabványok ismeretében elvégezni (ha a file hozzáféréssel hozzáférunk a CRC adathoz egyáltalán), meg még az is lehet, hogy mondjuk a win file API mondjuk a hibás szektorokra nem adja vissza a szektor adatot, amiből a CRC -t elvégezhetnénk, ÉS bármi is az előzőek közül a helyzet, az fix hogy ez csak egy windows -os módszer lesz, másik OS -eken is meg kell oldani ...

Nem tűnik eccerű mókának ...

Az emulátornak ilyen szinten nincs köze az egész floppys dologhoz, ő fájlt olvas. A nagy kérdés az, hogy mi történik, ha a fájolvasás során lemezhiba történik? Elvileg ilyenkor vissza kéne jutni egy hibakódnak az operációs rendszertől a programhoz (azaz az emulátorhoz).
Ez jelenleg nem történik meg, ki kéne találni, hogy a Windows sumákolja el, vagy az emulátor nem kérdezi le jól?
A lockolásos dolog kapcsán kiderült, hogy a Write Protect az nagyon szépen visszajut egészen az emulált EP-ig is. Vajon az olvasási hiba hol veszik el?
Az egyébként jól hallatszik, hogy retryzik a rendszer olvasáskot, tehát valamelyik szinten észlelve van a hiba.

A hiba összefoglalva az, hogy pl egy sávon az 5. szektor hibás. Ez be is van jelölve a FAT-ban, így az emulált EP fájlműveleteknél nem is akarná beolvasni.
Azonban az emulátor a puffereléshez beolvassa az egész sávot, így a hibás 5. szektorra is ráolvas. Itt az olvasás elakad, és az 5. szektortól a sáv végéig 00 bájtok lesznek a pufferben.
Így hiába olvasná az emulált EP a hibátlan 6. szektort, már nem azt kapja meg.

Ami eszembe jutott most: ez vajon általában a fájolvasás hibája, vagy a spéci \\.\A: fájlé?
Kipróbálom majd, hogy egy hibás lemezre ráírok egy IMG fájlt, és azt adom meg az emunak, vajon ekkor se lesz hibajelzés?

A másik ami eszembe jutott: megnézni Linux alatt ugyanazt a lemezt, vajon ott is jelentkezik-e a probléma?
Ehhez kérdezném a Linux gurukat, hogy milyen Linux verzióval lehetne egyszerűen ep128emu próbálgatni?

Igen külön van, ezt már maga a lemezvezérlő IC se adja vissza szektorolvasásnál. (WD-nél van ezekhez külön fejléc olvasás parancs.)

Akkor pedig (HA nem adja vissza a bad sector info -t a win a file api -kkal, vagy azzal a DeviceControl api -val, amivel a lock -ot is kellett allitani, illetve amivel a fizikai paramétereket is lekérdezi a WD kódja) gonban leszünk, mert sztm a win file api -ja csak a raw szektorokat adja vissza, így mindegy is hogy azokban mi lesz bad sector esetén, mert CRC info -nk az nem lesz.

Reméljük visszaadja a DeviceControl vagy más hasonló api a bad sector info -t.

A FAT -ból meg egyrészt nem kéne nekiállni kiolvasgatni ( gondolom nem 1Xu ), meg hát mikor kerül oda bele az info ? Mondjuk először még jó volt a lemez, de közben elromlott. Akkor ráolvasunk a win -nel, vajon mire visszatér a beolvasott szektor info, addigra már frissítve lett a FAT az új rossz szektorral ?

ja, de nem hinném hogy egy ilyen "fizikai" lemez file olvasása egy rossz szektortól meghiúsulna ... sztm be fog olvasni, valami akarmi lesz a rossz szektorok helyen, amit kitalaltak, es kesz.

lehet olyan hogy nem olvas be ez a sor, ha kivettek a lemezt vagy ilyesmi, de egy bad sector sztm ezt nem fogja lefalsoltatni.

De ha esetleg megis, akkor is ez egy teljes track beolvasasa, nekunk meg szektoronkent kellene a hiba.

Illetve hat lehet hogy mikor a wd- t track -re hivtak (ha van benne olyan) akkor meghalhatnank a teljes track- re is, de gondolom az EP nem olvasgat track -enkent vele, inkabb sector -osan talalnam elkepzelhetonek, szal nekunk sector -osan kell a hiba, nem ?

Linux:

Szerintem sima ubuntu -val tudsz probalgatni siman, viszont ha forditani, debuggolni akarsz az kulon sztori lesz. Akkor is jo az ubuntu, de az nem olyan kompakt mint a win -es fordito csomag.

Ja. Simán.

Mindenesetre kell egy fizikai floppy + egy rossz ( bad sector -os ) lemez, hogy kiprobalgathassam.

Te is ki tudod, ha begerjesztetted azt a debuggert, amit múltkor itt reklámoztam, én begerjesztettem, simán ment, vizuálisan lehet debuggolni.

És akkor egy bad sector ( -os track ) olvasásakor megnezed, hogy mit csinál az az fread, ad -e vissza hibát.

Mivel mostmár a forrásban felül lévő kódok futnak le win -en (amit írtam újonnan), és ott külön változó van a beolvasott byte -oknak meg tudod nézni mennyit sikerül beolvasni a teljes track -ből.