Már látom is hol a hiba!
      if (currentTrack != bufferedTrack || currentSide != bufferedSide)
        (void) updateBufferedTrack();   // FIXME: errors are ignored here
      if (!flagsBuffer[bufPos >> 9]) {
        if (!readTrack()) {
          setError(0x08);               // CRC error
          dataRegister = 0x00;
          return 0x00;
        }
      }
A readTrack akkor fut le, amikor változott a sáv vagy oldal, azaz frissíteni kell a puffert.
De a visszaadott errorFlag csak itt van vizsgálva! Ha hiba volt vissza is megy hibajelzés, de nincs letárolva a hiba ténye, ezért az ismételt olvasásnál, amikor már a pufferből dolgozik, nem lesz hibajelzés.

Tehát akkor a readTrackben kéne egyből megnézni, hogy volt-e hiba, ha igen, akkor szektoronként újraolvasni, és egy tömbben letárolni, hogy melyik szektor hibás.
Majd itt a szektor olvasó rutinban ezt a tömböt nézni mindig, és annak megfelelően generálni a hibát.

És akkor most a WD emulációja az emunak valahogy úgy egyszerűsít, hogy fejléptetéseknél, ilyesmiknél csak magának regisztrál, de a floppy meghajtót nem bizergálja, hisz nincs is neki rá interfésze jelenleg az OS felé, hanem file olvasással a beolvasást track szinten cache -elve elkerülvén a továbbforgások miatti, forgásonkénti 1 szektor beolvasási lassulást, a track bufferből szolgálja ki az "adatolvasási" hívásokat az EXDOS felől ?

Amiből (ha majd ki lesznek javítva a jelenlegi hibák, akkor is) az eredeti EP/WD floppy IC kezeléshez képest olyan hátrányok származnak, mint:

- A floppy fej/motor/mittudoménmégmik nem pont ugyanúgy mozognak, működnek, mint ahogy azt az EP működtette volna a vas WD IC -n keresztül. (Tehát ha valaki írt valami floppy kattogtató/zenéltető programot, az itt nem működne, nem beszélve az értelmesebb felhasználás különbségeiről
- Mikor egy szektort beolvas az EXDOS akkor a WD emuláció egy teljes track -et betölt a floppy -ról, ami jelentős lassulást eredményezhet az első szektor kiolvasásáig, ha a file -ok töredezettek és több track -en vannak elszórt szektorokban, akkor meg még sokkal nagyobb lassulást
- Előbbi jelenség kiírásnál ugyanúgy megvan
- Ráadásul mivel egész track -eket írunk ki, egy bizonyos szektor kiírásakor bekövetkező CRC/bad sector hibáról csak később szerzünk tudomást, mint mikor az eredeti VAS -on a szektor írása megtörtént volna, és ahol a szektor írási hibát az eredeti EXDOS kód, vagy akár az alkalmazás kezelni tudta volna
- Ha viszont a track -en belül ír/olvas szektorokat az EXDOS, akkor fejmozgás, lassulások, ilyesmik elmaradnak, és a vasnál sokkal gyorsabb lesz minden
- Mivel kiírni csak akkor írja ki a track -et a floppy -ra az emulált WD, mikor másik track -re léptünk, ezért olyankor lesznek floppy írásra várakozások, mikor az eredeti EP -ben nem voltak. Ettől lehet zozo szívfájdalma, hogy mikor valamit ráírunk egy lemezre, és a funkcióból rég kiléptünk, az emu még csak akkor blokkolódik, ráadásul egy egesz track floppy -ra írásának erejéig, talán épp azért, mert a fej csak akkor lett még elmozgatva onnan, ahol az utolsó írás történt, és ekkor ír csak track -et az emu.

Mindezeket teljesen megszüntetni gondolom csak úgy lehetne, ha valami driver szinten OS alól hozzáférnénk WD szintű lemezkezelési parancsokhoz, és azokra fordítanánk a WD -hez érkező parancsokat.

Na mindennek vajon hány % -a igaz ?

Ha mindaz igaz amit leírtam, ha magamnak írnám az emut, en elfelejteném ezt az egész track cache dolgot, és megírnám normálisan szektorosra.

Akkor az maradna, hogy a fej/motor/akármik nem pont ugyanúgy mozognának mint a vas esetében, illetve sokkal lassabb lenne, de a többi hiba magától eltűnne, és szoftveres értelemben minden program ugyanúgy működne mint az eredeti EP -n.

Lévén ez egy emulátor, sztm az a legmagasabb prioritás. Nem ?

És mellesleg itt a válasz a tegnapi USB floppy -s kérdésre is a driver FAQ -jából:


Can I use a USB floppy drive?
No — USB floppy drives contain a separate floppy controller chip, which is not directly accessible from the host PC. Without access to that it's simply not possible to support formats beyond what the drive chooses to expose (typically DOS 720K and 1.44M formats only).



Én ezt úgy értem, hogy az USB floppy valahogy másképp kommunikál mint a floppy vezérlő, így nem lehetne ezzel a driver -rel hajtani. Magában az eszközben, az USB géppel ellentétes oldalán van a floppy vezérlő IC, amiben huzalozva van valószínűleg a nekünk szükséges szektor kezelés és formázás.

Persze fentiektől esetleg még az is lehetséges, hogy alacsonyszintű ("lemezvezérlő szintű") parancsokat attól még esetleg átvisz az USB, csak a CRC paraméterek vannak belehuzalozva a vezérlőbe, és azon nem tudnak változtatni a driver -ükkel. Inkább az elsőre tippelnék sajnos.

Tehát ha ezt a driver -t használnánk akkor félig vagy egészen, de az USB floppy -kat elbuknánk úgy tűnik, ami a fejlődés irányát nézve (gépekből sorra maradnak ki a floppy meghajtók, szinte nem is gyártják őket már) lehet gázos lesz a jövőben.

De a jelenlegi file -os módszer 99% menne akkor az USB floppy -kon is, sztm ...

Fontossági sorrendre én ezt mondanám:
-kijavítani a tegnap felderített hibás szektor vs pufferbe olvasás problémát
-így akkor ki lehetne adni 2.0.9.2 verziót, ebben frissíteni a ROM és konfig fájlokat is
-WD emulációban a szektor méretet is beállítható paraméterré tenni
-ezután image fájlokkal már használhatóak lennének a Spectrumos lemezek, be lehetne tenni a zx128emu-ba a SpeccyDOS-t, és Beta Disk-et. (Ez lehetne 2.0.9.3)
-ezután jöhetne ez az új fajta API

Egyébként filerendszer szinten ugyanaz a FAT12 van a floppy -kon is, mint az EP winyón ?

Amiből az is következik, hogy ha olvassa az EP floppy -kat egy mai modern OS (márpedig tudtommal az összes olvassa), akkor egy mai modern OS -ben még mindíg benne kell legyen az ős régi FAT12 fájlrendszer írása/olvasása (ha már a formázására nem is képesek) ?

Szerintem igen ... Engem az is erdekelne, hogy mi a helyzet a FAT16-el. Zozo mintha azt mondta volna, hogy valoszinu megoldhato lenne az is EP-n tobb-kevesebb munkaval. Ez azert is erdekes, mert ha HDD-t nezzuk, ott azert a FAT12 limitacioi komolyabbak, jol jonne a FAT16. Floppy eseten ez kevesbe problema persze