Welcome, Guest. Please login or register.


Author Topic: EXDOS (Read 88849 times)

Offline Ep128

  • EP addict
  • *
  • Posts: 1744
  • Country: hu
  • OS:
  • Windows Vista/Server 2008 Windows Vista/Server 2008
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • Honlapom
Re: EXDOS
« Reply #180 on: 2014.April.10. 00:22:22 »
Quote from: Zozosoft
Jön majd mesedélután :-)
Bár nem értek hozzá, de ha szájbarágósan leírod, engem is érdekel! :-)

Offline Povi

  • EP addict
  • *
  • Posts: 2087
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Chrome 33.0.1750.154 Chrome 33.0.1750.154
    • View Profile
    • http://povi.fw.hu
Re: EXDOS
« Reply #181 on: 2014.April.10. 14:02:11 »
engem is érdekel! :-)
*** Speicherplatz zu klein

Online gflorez

  • EP addict
  • *
  • Posts: 3125
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
Re: EXDOS
« Reply #182 on: 2014.April.10. 15:31:46 »
Y yo...(And I....)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #183 on: 2014.April.12. 21:34:43 »
Quote from: Z80System
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 :oops:
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 :cry: í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 :oops: 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 :twisted: további debuggolás folyamatban...

Offline Lacika

  • EP addict
  • *
  • Posts: 2991
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://www.ep128.hu
Re: EXDOS
« Reply #184 on: 2014.April.12. 21:49:42 »
Ez a 800K-s vhd-kat mennyiben érinti? Hogyhogy, ez a hiba nem jött elő anno másolgatás közben? A 720K-sokat nem Ep-vel csinálom, az tuti.
És lehet, hogy akkor nem is az EPDOS 1.9 bugzik ilyen csúnyákat?

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #185 on: 2014.April.12. 21:58:03 »
Quote from: Lacika
Ez a 800K-s vhd-kat mennyiben érinti? Hogyhogy, ez a hiba nem jött elő anno másolgatás közben? A 720K-sokat nem Ep-vel csinálom, az tuti.
A floppykat nem érinti. a "Az ep128emu-hoz 192 Mb-os virtuális HDD, hat partición mindenféle jóval" című VHD-n lehet gubanc.

Quote from: Lacika
És lehet, hogy akkor nem is az EPDOS 1.9 bugzik ilyen csúnyákat?
Elképzelhető, ill. úgy tűnik ott is lesz plusz egy bug: meghajtó adatterület olvasásnál nem számít nem rendszerszegmensben lévőre, így nem is lapozza be.

Online Z80System

  • EP addict
  • *
  • Posts: 3842
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
Re: EXDOS
« Reply #186 on: 2014.April.12. 22:20:39 »
Quote
A floppykat nem érinti. a "Az ep128emu-hoz 192 Mb-os virtuális HDD, hat partición mindenféle jóval" című VHD-n lehet gubanc.
Maga az eredeti, üres VHD biztosan jó ?

Ha pedig az üres jó, és esetleg PC -n van összemásolva a VHD, akkor annak is jónak kellene lennie ...
Z80 System

Offline Lacika

  • EP addict
  • *
  • Posts: 2991
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://www.ep128.hu
Re: EXDOS
« Reply #187 on: 2014.April.12. 22:22:37 »
Quote from: Zozosoft
A floppykat nem érinti. a "Az ep128emu-hoz 192 Mb-os virtuális HDD, hat partición mindenféle jóval" című VHD-n lehet gubanc.
Azok egyáltalán nem is láttak Ep-t (abban az állapotban, ahogy felraktam őket) direkt a tapasztalt bugok miatt.

Online Z80System

  • EP addict
  • *
  • Posts: 3842
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
Re: EXDOS
« Reply #188 on: 2014.April.12. 22:23:04 »
Quote
viszont a memórialapozás van elszúrva, nem kicsit,
Nem lehet, hogy ez nem bug tulajdonképpen ? Tehát ők úgy terveztek, hogy az ilyen meghajtó programok beférnek a rendszerszegmensre, és nem gondoltak ilyenekre, hogy külön szegmensen legyen bármi ehhez hasonló kód ? És ezért nem is lapoztak ...
Z80 System

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #189 on: 2014.April.12. 22:38:32 »
Quote from: Z80System
Nem lehet, hogy ez nem bug tulajdonképpen ? Tehát ők úgy terveztek, hogy az ilyen meghajtó programok beférnek a rendszerszegmensre, és nem gondoltak ilyenekre, hogy külön szegmensen legyen bármi ehhez hasonló kód ? És ezért nem is lapoztak ...
Nem, ha így lenne akkor nem lenne szegmensszám tárolva hozzá. És lapoznak is. A gond itt az, hogy itt is lapoz, egy korábban letárolt szegmens számot, ami úgy tűnik éppen rosszkor lesz letárolva, pont akkor amikor a bővítő leíró szegmense van belapozva.

Ahogy Bruce mondta: "Rengeteg kézzel írt assembly kód van EXOS, IS-BASIC, EXDOS programokban, valószínűleg tele vannak hibákkal."

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #190 on: 2014.April.12. 22:41:55 »
Quote from: Lacika
Azok egyáltalán nem is láttak Ep-t
Ez egyébként baj, mert nem EP-s a boot szektor, így az UNDEL rendszer, ill. majd SD-nél a lemezcsere ellenőrzés nem fog rendesen működni.
Majd csinálok egy boot szektor EP-sítő programot :-)

Online Z80System

  • EP addict
  • *
  • Posts: 3842
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
Re: EXDOS
« Reply #191 on: 2014.April.12. 22:42:18 »
Quote
Ahogy Bruce mondta: "Rengeteg kézzel írt assembly kód van EXOS, IS-BASIC, EXDOS programokban, valószínűleg tele vannak hibákkal."
Mi az hogy kézzel írott ? Mivel lehetett még írva ? Fordítókkal nem hinném hogy dolgoztak még akkoriban ... gondolom minden raw assembly volt és joccakát. Nem ? (Meg hát ha elírta a szegmens logikát valaki, akkor elírta volna C -ben is, nem ?)
Z80 System

Online Z80System

  • EP addict
  • *
  • Posts: 3842
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
Re: EXDOS
« Reply #192 on: 2014.April.12. 22:45:09 »
Quote
Az egyébként baj, mert nem EP-s a boot szektor, így az UNDEL rendszer, ill. majd SD-nél a lemezcsere ellenőrzés nem fog rendesen működni.

Mi tud az EP-n más lenni a boot sectorban ? Fenti 2 fícsőrrel összeköttetésben ? Nem arról volt szó, hogy az EP file kezelő kódja ha FAT12 -es is csupán, de azon belül 100% kompatibilis minden rendszerrel ? Erre most kiderül, hogy azért mégsem 100% ?
Z80 System

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #193 on: 2014.April.12. 22:53:26 »
Quote from: Z80System
Mi tud az EP-n más lenni a boot sectorban ? Fenti 2 fícsőrrel összeköttetésben ? Nem arról volt szó, hogy az EP file kezelő kódja ha FAT12 -es is csupán, de azon belül 100% kompatibilis minden rendszerrel ? Erre most kiderül, hogy azért mégsem 100% ?
Ez a 100%-on felül van, ezért kell hozzá EP-s boot szektor.
Itt volt tárgyalva a téma.
Az aktuális FAFO már a "mindent tudó" boot szektor írja fel, ez lesz majd az SD meg az IDE formatjában is, ill utólag ezt kell betenni Lacika VHD-jaiba.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13949
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 28.0 Firefox 28.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EXDOS
« Reply #194 on: 2014.April.12. 22:58:41 »
Quote from: Z80System
Fordítókkal nem hinném hogy dolgoztak még akkoriban ...
Bőven léteztek már, éppen azért írta, hogy ez raw assembly és jóccakát :-D

Quote
Meg hát ha elírta a szegmens logikát valaki, akkor elírta volna C -ben is, nem ?
Ez igaz, de minél több utasítással van leírva valami, annál nagyobb az esélye az elírásnak.

Ha annó nem ment volna csődbe a cég, akkor valószínűleg ők is észreveszik előbb-utóbb :-)