Ha lesz kedved majd meselj róla, hogy mi volt és hogy ... Tök érdekes lehet ... milyen hiba lehet ami nem érintette a floppy -s dolgokat, de a winyo/SD -t már igen, viszont csak az SD -nél lett elkezdve keresve, mert ott nyilván más hibajelenséget produkált mint a winyóknál ...
Na szóval onnan indult a történet, hogy meg kaptam az SD illesztő prototípusát, és neki álltam tesztelni turbós géppel, mivel a projekt elején nem voltam benne, hogy szóljak, hogy már rég nem 4MHz-nél tart az EP
Miután úgy tűnt az olvasás remekül megy bármilyen sebességgel, átmásoltam a Small Demot az egyik kártyáról a másikra. A másolat meg jól lefagyott...
További próbálkozások alapján úgy tűnt, hogy 10MHz-et nem bírja.
Másnap további tesztelés alapján kiderült, hogy 4MHz-en is tud hibázni.
Mivel az nem túl egzakt teszt, hogy lesni, lefagy-e a Small Demo, vagy esetleg grafikai hibák jelennek meg, csináltam egy tesztecskét, ami 512K pszeudó random számot ír ki fájlba, majd ellenőriz vissza.
Ezzel további teszteket végezve elsőként úgy tűnt, hogy akkor van gond, ha két SD kártya van használva. Ehhez a hw tervezőjétől is jött az a infó, hogy elképzelhető az, hogy bezavar egymásnak két kártya, a TVC-s ősön csak egy kártya volt, cska az EP verzióhoz jött a két kártyás megoldás.
Begyűjtöttem még egy félmarék kártyát, további kb 2 nap alatt eljutottam oda, hogy tök mindegy milyen kártya, a kártya tartalma számít. Amelyiken az üres particiós VHD van, azon hibázik... de ha egyedül van, akkor nem... hát ez elég érdekes.
Hétvégére hoztam Apucihoz is egy EP-t, hogy ne kelljen napokig várni a tesztelés folytatására
Itt meg elsőként nem akart hibázni... a fő különbség az volt, hogy ez 128K-s gép, míg otthon 1088K-s géppel ment a teszt.
Közben nézegettem, a hibásra sikerült teszt fájlokat, akkor láttam, hogy egy-egy FAt szektor repült be a fájlba.
Itt olyasmira kezdtem gyanakodni, hogy időnként az SD kártya "not ready" és nem követi le a váltásokat ami a sorban adatszektorok írása és a néha írt FAT szektorok között van.
Végül eljutottam oda, hogy 1 db 16MB-os kártya 1 db 16MB-os partíciójával mindig hibázott, akkor is ha egyedül van a kártya. Vagyis sikerült kiszűrni a két kártya zavarja egymást dolgot.
Közben SzörG is tesztelt, neki nem akart előjönni a hiba, itt felmerült az is, hogy csak az én illesztőm hibás.
Emulátoron IDE-s konfigban ugyanazokkal a VHD-kkel is többször is lefuttattam a tesztet, nem hibázott.
Végül átírtam a tesztet 4 megás fájlra, ezzel sikerül SzörG-nél is előhozni a hibát.
Itt lett az elsődleges a gyanúm, hogy szoftver hiba lesz. Persze leginkább arra gondoltam, hogy én rontottam el valamit
Elsőként valami szektorcím számítási hibára gondoltam, bár igen furcsa volt, hogy csak írásnál volt gond.
Csináltam egy olyan tesztet ami a lemez összes szektorába beleírja az LBA szektorszámot, majd ellenőrzi ezt. Nem volt hiba semmilyen kártyával, semmilyen partícióval, bármilyen gép sebességgel sem.
Kipróbáltam, szektorszám alapján generált pszeudó random számokkal is, ott se volt hiba.
Közben az IDE-s VHD-kat nézegetve feltűnt, hogy nincs FAT2.
Jött is az ötlet, disk editorban átírtam az SD kártyán a partíciót 1 FAT példányosra, és rögtön el is múlt a teszt hiba!
Ekkor már tutira vettem, hogy itt valami fájlrendszeri bugzás lesz...
Elsőként arra gondoltam, hogy ott a hiba, amikor az EXDOS bővítésünk visszaadja az adott partíció paramétereit, mivel az EXDOS bővítés mikéntjéről mind a mai napig nem kerültek elő a hivatalos dokumentációk
így könnyen lehet, hogy a visszafejtésen alapuló megoldásomból esetleg hiányzik valami. De több órányi debugolást követően kiderült, hogy az eredeti feltételezésem a helyes, és csak a boot szektor kell odaadni.
Akkor lehet, hogy a boot szektorból ért valamit félre az EXDOS?
Ennek tesztelésére végül csináltam egy olyan IDE-s konfigot emulátorban, ahol mind az IDE mind a floppyt kezelő UNITH formázáskor csak egy XOR A, RET kódot hajt végre, magyarán mind a FORMAT A: mind a FORMAT F: meghagyja a létező boot szektort, ami alapján majd a FISH elkészíti a FAT táblákat és a főkönyvtárt.
Bitre ugyanazt a sima 720K-s EXDOS 1.3 formázott lemezt raktam A-nak, és F partíciónak, majd LUA scripttel figyeltem mi történik, az eredmény mellékelve. Mindkettőben elsőként egy normál 2 FAT-os, majd egy 4 FAT-os formázás látható. Total Commanderben összehasonlítva a két txt-t, jól látszik a hiba, a szektorírásoknál a DE-ben van a szektorszám. Mint látható az F meghajtón minden FAT példány az FAT1-re íródik.
Kidebuggolva a FAT író ciklust, kiderült, hogy 0 FAT mérettel számol, ezért történik ez.
Sok más paraméter mellett a FAT méret is a
meghajtó adatterületen van tárolva., ezt az EXDOS 1.3-ban CE3Ah címen lévő rutin tölti ki a boot szektor alapján. Lehet, hogy nekünk is kéne ilyen rutin a bővítőprogramunkba? Újabb debuggolás után kiderült, hogy nem, ezt a FISH maga végzi a boot szektor bekérése után. A vizsgált F meghajtónál is megcsinálta, megvizsgálva a memóriát ott is vannak a paraméterek a helyükön.
Akkor mégis miért olvas 0 FAT méretet? Itt akkor memória lapozási hiba lesz!
Kipróbálva az IDE-t 128K-s módban, hopp eltűnt a hiba!
A mayarázat: a beépített floppy és RAMDISK egységek esetén a mindig belapozott rendszerszegmensben vannak a meghajtó leírók, ill. az eredeti IDE verziónál is így volt, ezért ezeknél nem jelentkezett a hiba.
Mivel a túl nagy rendszerszegmens helyfoglalás miatt több (bénán megírt) program nem futott az IDE-vel, ezért az 1.1 verzió RAM bővítős gépen ( EXOS 2.2+ esetén, mivel az eredeti EXOS hibás) saját RAM szegmenst foglal, ezért a meghajtó leírói már más szegmensben lesznek. Ugyanez a helyzet az SD-vel is, annak a 7-es szegmensen belül van saját RAM területe.
További debugolással kiderült, hogy az 1.3-ban CA5Dh-n kezdődő rutinban van a bug itt, szerepel egy
SET 6,H
RES 7,H
rész, ami a címet az első lapra konvertálja, miközben a FORMAT alatt debuggolva, 95xxh körül lévő adatokban akar kotorászni rendszerszegmensben. Beépített egységek leírói esetén itt az 1. lapon is a rendszerszegmens van, tehát a címkonvertálás nem okoz gondot, viszont külön szegmensben lévő leírók esetén ez a szegmens van belapozva, innentől kezdve viszont totál hülyeségeket fog olvasni!
Az IDE esetén, hacsak nincs nagyon sok partíció, akkor leginkább nullákat, SD-nél meg vagy a a ROM végi FFh-kat (aminek az a eredménye, hogy a FAT2-t 255 szektoral a FAT1 mögé írja, azaz már telibe az adatszektorokat), vagy amikor éppen felsőbb részt néz, akkor az SD meghajtóleíró területről valami megjósolhatatlan értékű adatot, ha esetleg ír is ide, azzal még tovább növelve a káoszt.
Ez megmagyarázza, hogy miért viselkedett totál összevissza a rendszer a tesztelés alatt.
Gyorsjavításként kipróbáltam a cím 2-es lapra javítását, ezzel a FORMAT-nál, ill. a tesztfájlt író programnál megszűnt a bug.
Viszont lesz más, COPY-nál vagy DEL-nél rövid úton megzuhan a fájlrendszer
azaz az a sejtésem jött be, hogy az 1-es lapos címzés jó, viszont a memórialapozás van elszúrva, nem kicsit, nagyon
további debuggolás folyamatban...
