Mikre jössz rá még ennyi év elteltével is... 

Miben már az EXDOS 2.0?

Valódi gépen történõ tesztelés (az emulátor nem emulálja a WD idõzítéseit) után az derült ki, hogy alap 4 Mhz-es gépen rendszeresen Data error hibákat jelez, 6 Mhz kell a normális mûködéséhez.
Ez egyébként nem is valódi data error, hanem csak a Lost data hibához is ugyanazt a EXOS hibakódot rendeli az EXDOS:

DB	0BAH,0B9H,0B8h,0B8H,0B7H,0BFH,0B6H,0BDH
	;bit 0: 186 Not Ready
	;bit 1: 185 Verify error
	;bit 2: 184 Data error (ez valójában Lost data)
	;bit 3: 184 Data error
	;bit 4: 183 Sector not found
	;bit 5: 191
	;bit 6: 182 Write protected disk
	;bit 7: 189

Ilyen hiba akkor van, ha olvasáskor a Z80 nem olvassa ki addig az adatot a WD-bõl ameddig az beolvassa a lemezrõl a következõt (ilyenkor elveszik az adott bájt), ill. íráskor nem írja be idõben a következõt (ilyenkor 00 íródik a helyére a lemezre). Valószínûleg úgy gondolták, ilyen hiba úgyse fordulhat elõ, így még belsõ hibakódot se pazaroltak rá
De elõjön, ha pl elkezdjük tubosítani a WD-t HD-s lemezekhez (erre majd még visszatérünk), mennyivel egyszerûbb lett volna a dolgom, ha tudom, hogy nem valódi data error-okkal kel hadakozni 

Visszatérve az EXDOS 2.0-hoz, miért generál ez ilyet normál alap gépes körülmények között?
1.3-ban (a konkrét címektõl eltekintve ugyanez a többi 1.x verzió is) így néz ki az olvasási rutin kezdete:

		;WD olvasási mûveletek végrehajtó rutinja
 
lde43:  CALL    LDF50		;várakozási értékek beállítása
        OUT     (C),A		;12 (13);WD Command kiirása
        SET     3,C		; 8 ( 9);EXDOS Status register
lde4a:  JR      LDE4C           ;12 (13);várakozás
lde4c:  LD      A,00H		; 7 ( 8);várakozás
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      M,LDE65		;10 (11);ugrás, ha DRQ aktív

Itt ha jól számoltam alapgépen (OUT 191,4) 30 órajel alatt jut el a DRQ állapot beolvasásáig.
2.0-ban:

.   E05E  CD 6F E1     CALL  E16F ;várakozási értékek beállítása
.   E061  ED 79        OUT   (C), A    ;12 (13);WD Command kiirása
.   E063  CB D9        SET   3, C      ; 8 ( 9);EXDOS Status register
.   E065  3E 06        LD    A, 06     ; 7 ( 8)
.   E067  3D           DEC   A         ; 4 ( 5)
.   E068  20 FD        JR    NZ, E067  ;12 (13), 7 ( 8) ha Z 
.   E06A  ED 78        IN    A, (C)    ;12 (13);EXDOS Status olvasása
.   E06C  FA 7F E0     JP    M, E07F   ;10 (11);ugrás, ha DRQ aktív

Ez esetben 120 órajel alatt jut el a DRQ beolvasásáig, ami igen jelentõs növelés, fõleg ha azzal vetjük össze, hogy DD-s lemezrõl 128 órajelenként jönnek az adatok (4 Mhz-es gépnél). Így akkor már érthetõ miért csúszik le néha-néha az elsõ adatbájtról.
Ennek a jelentõs növelésnek csak akkor van értelme, ha jóval gyorsabb CPU-ra bízzuk a végrehajtást, és nem akarjuk, hogy túl gyors végrehajtás miatt Not ready hiba legyen, mert nem várja meg a kód a változatlan sebességû lemezvezérlõt.
Ha jól tudom abba a bizonyos szuper EP-be tervezett Hitachi Super Z80, nem csak órajelében nagyobb, hanem az utasításokat is rövidebb idõ alatt hajtja végre. Így nézve értelmet nyer a dolog.

Van egy probléma, amit a Z180 kapásból megoldana 
De hátha ügyes bitfaragóknak (fõleg Istvánban reménykedek  ) van valami ötletük, hogyan lehetne a jó öreg Z80-al megoldani a feladatot.
A probléma az, hogy 1.44-es lemez kezeléséhez 7.12Mhz-es gép kell, 6Mhz-en OUT 191,14 kell. Jobb lenne, ha nem kéne... de még jobb lenne ha 4Mhz-en is menne!
Itt egy táblázat, hogy hány órajelenként jönnek az adatbájtok 4/6/7.12Mhz esetén:
                    normál DD 128 192 227
                    turbó   DD 102 154 182
300-as fordulatú 1.2M HD  77 115 137
                     1.44M HD  64  96 114

Az a 64 órajel nem túl sok mindenre elég
Így néz ki az eredeti EXDOS olvasás rutin:

lde43:  CALL    LDF50		;várakozási értékek beállítása
        OUT     (C),A		;12 (13);WD Command kiirása
        SET     3,C			; 8 ( 9);EXDOS Status register
lde4a:  JR      LDE4C       ;12 (13);várakozás
lde4c:  LD      A,00H		; 7 ( 8);várakozás
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      M,LDE65		;10 (11);ugrás, ha DRQ aktív
        DEC     DE			; 6 ( 7);várakozási számláló csökkentése
        IN      A,(C)		;12 (13);várakozás
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      M,LDE65		;10 (11);ugrás, ha DRQ aktív
        LD      A,D			; 4 ( 5);számláló
        OR      E			; 4 ( 5);=0?
        JP      Z,LDEE3		;10 (11);kilépés, ha várakozási idõn belül nem érkezett DRQ
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      P,LDE4A		;10 (11);ugrás, ha DRQ nem aktív
lde65:  DEC     C			; 4 ( 5);WD Data
        IN      A,(C)		;12 (13);adat beolvasása
        LD      (HL),A		; 7 ( 8);letárolás
        INC     HL			; 6 ( 7);transzfercím növelése
        INC     C			; 4 ( 5);EXDOS Status
lde6b:  IN      A,(C)		;12 (13);status olvasása
        AND     82H			; 7 ( 8);csak DRQ és INTRQ bitek maradnak
        JR      Z,LDE6B     ;12 (13), 7 ( 8) ha NZ ;várakozás tovább, ha nincs esemény
        JP      M,LDE65		;10 (11);ugrás, ha újabb adat érkezett
        JR      LDEE0       ;12 (13);INTRQ esetén kilépés

És így amit megfaragtam:

lde43:  CALL    0DF50h		;várakozási értékek beállítása
        OUT     (C),A		;12 (13) ;WD Command kiirása
        SET     3,C			; 8 ( 9);EXDOS Status register
lde4a:  
lde4c:  
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      M,lde65		;10 (11);ugrás, ha DRQ aktív
        DEC     DE			; 6 ( 7);várakozási számláló csökkentése
 
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      M,lde65		;10 (11);ugrás, ha DRQ aktív
        LD      A,D			; 4 (5);számláló
        OR      E			; 4 (5);=0?
        JP      Z,0DEE3h		;10 (11);kilépés, ha várakozási idõn belül nem érkezett DRQ
        IN      A,(C)		;12 (13);EXDOS Status olvasása
        JP      P,lde4c		;10 (11);ugrás, ha DRQ nem aktív
lde65:  LD		E,82H		; 7 ( 8)
lde67:  IN      A,(13H)		;11 (12);adat beolvasása
        LD      (HL),A		; 7 ( 8);letárolás
        INC     HL			; 6 ( 7);transzfercím növelése
	in a,(c)
	jp m,lde67
 
lde6b:  IN      A,(18h)		;11 (12);status olvasása
        AND     E			; 4 ( 5);csak DRQ és INTRQ bitek maradnak
        JR      Z,lde6b     ;10 (11);várakozás tovább, ha nincs esemény
        JP      M,lde67		;10 (11);ugrás, ha újabb adat érkezett
 
        JR      ldee0       ;12 (13);INTRQ esetén kilépés
 

Ez 6 Mhz-en már teljesen jó, és OUT 191,12 mellett majdnem jó 4 Mhzre is. FISH-en keresztül kezelve nincs hiba (gondolom nyom egy retryt adatvesztés hibánál), DISKIO-n keresztül idõnként (kb 2-3x 10-bõl) adatvesztés hiba lesz (és pl az EPDOS az DISKIO-t használ), ilyenkor az elsõ 2-3 bajtból veszik el 1-2. Tehát valahogy a rutin elejét kéne gyorsítani...
Az írás az nagyjából egykutya, a Verify viszont rosszabb eset, ott van egy plusz JR NZ is 

Van valakinek ötlete, mit lehetne még faragni ezen? Az se baj, ha nem fér be az eredeti helyére.

Ez igaz, viszont az IN A,(C) az állítja a flageket, így közvetlenül alkalmas a DRQ vizsgálatára.

B-ben van a szektorszámláló, így kell PUSH.

És az elõzõ pont értelmében amúgy is egy POP BC-re kell ugrani
Hely az nem gond, amúgy is újrafordított EXDOS a cél. (Már lefordul, csak valahol bujkál még valami fixcímzés  ) Addig is ideiglenesen mehet a ROM végén üres részbe az újrafordított rutin.


Ez is jó ötlet, köszi!

Azt vettem észre emulátoron, hogy 1.0-nál csak a felsõ floppy, 1.3-nál az alsó floppy is felvillan az EP felirat után. Az 1.3 valószínûleg mindkettõn megnézi, van-e EXDOS.INI, az 1.0 pedig csak az alapértelmezett egységen.

Az, hogy nagy (5.25") vagy kis (3.5") lemez, nem számít. Meghajtótól függõen lehet 1 vagy 2 oldalas, 40 vagy 80 sávos, DD vagy HD.
Az alap EXDOS DD-t kezel (a Turbo az HD-t is), így lehet a további paraméterek alapján 180/360/360/720-as meghajtó, lemez fizikai méretétõl függetlenül. Az PC-s hülyeség, hogy 5.25"-ösben nem ismeri 720-as formátumot, ill. 3.5"-ben a 180/360-at.
Ez némileg megnehezítette az EP-sek (és TVC-sek) dolgát, mert nálunk szerintem a floppytulajdonosok 90%-ának 5.25" 720K meghajtó volt az elsõ meghajtója.
PC-n a Microsoft nem ismeri a saját szabványait se (ezt már itt többször tárgyaltam), így a 800.COM vagy FDREAD.EXE nevû segédprogramokra volt szükség ezek kezelésére. DR/Novell DOS alatt nem volt szükség ilyenre.

Jöhet a tovább növelés kérdése: az EXDOS alapértelmezésben a PC-n is szabványos 9 szektoros formátumot használja, ezekkel számoltuk ki az elõbb a lehetséges lemezméreteket. Igazából teljesen érthetetlen miért ez a 9 szektoros formátum lett a szabvány, ha megnézzük pl a WD1772 leírásban ajánlott paramétereket, akkor az jön ki, hogy minden ajánlott érték (szektorok közti távolság, szektorfejléc és adatterület közti távolság) betartásával simán elfér 10 szektor. Így a különbözõ meghajtótípusokkal 200/400/800K kapacitást kapunk. Ezt az EXDOS természetesen zokszó nélkül kezeli.
PC-n anno DOS alatt erre is ugyanaz igaz mint a 720K 5.25" meghajtóra: MS-DOS-nál segéd program kell.
Ami jó hír számunkra: XP/Vista/Win7 esetén simán kezeli ezeket a lemezeket! Tehát manapság EP-hez 800K-ra formázott DD lemezt érdemes használni, erre mai Windows alatt is tudunk másolgatni.

Van még egy módja a lemez kapacitás növelésének: plusz sávokat írunk fel, addig amíg nem koppan a fej
Általában a legtöbb 80 sávos 5.25" meghajtó 84 sávot tud, így a 840K volt a legelterjedtebb formátum EP-n.
3.5"-bõl a NEC FD1035 meghajtó (ilyen van nekem ) az 90 sávot tud!

PC-n DOS alatt ugyanez vonatkozik erre is. Mai Windowsok valami idióta ökörség miatt nem kezelik, plusz sávok esetén figyelmen kivül hagyják a boot szektor adatait, és hibásan elképzelt paraméterekkel kezelik a lemezt 

Lássuk mivel tudunk tuning lemezt formázni: PC-n DOS alatt az FDFORMAT-tal, avyg Attus formázó programjával.
EP-n az elsõ ilyen a Devilsoft féle FORMAT.800 volt.
Utána a Venus VFORMAT-ja jött, ez 820-as lemezeket formáz, és tud hibás szektorokat bejegyezni a FAT-ba.
Majd jött az EPDOS Formatja, itt már állíthatóak a paraméterek, 87 sávig lehet elmenni, és 11 szektorig. 11 szektort elösször nem kezelte az EXDOS, én találtam meg hol kell átírni az ellenõrzést, ekkor került bele a HELP szövegbe, hogy 11 sector version by Zozosoft.
A 11 szektornál viszont már annyira alámegyünk az ajánlott értékeknek, hogy azt csak WD vezérlõs gépek értik (EP-n kivûl pl Atari ST), PC egyáltalán nem! (Megjegyzés Amigán is 11 szektor van, csak más felirással).

Visszatérve az EPDOS Formatjához, ez már kezeli a különbözõ meghajtókat, tehát lehet pl 360-as meghajtóban 400-as lemezt formázni, vagy plusz sávokkal mondjuk 420-at.
Nem kezeli viszont a hibás szektorokat.

Ezért láttam neki a FAFO megírásának, egyrészt lehessen bárhonnan formázni, legyen lehetõség hibás szektorokat bejegyezni, és nem volt elég az EPDOS által biztosított 87 sáv így lett nálam 90, mert csak ott koppan a NEC meghajtó.
Késõbb jött még a különbözõ logikai paraméterek beállíthatósága is.
Turbo EXDOS fejlesztése után a FAFO lett képes a turbo DD (13 szektoros), és HD lemezek formázására, 1.44-es HD lemezen 22 szektorig lehet elmenni ezt ugyanúgy nem érti a PC mint a 11 szektoros DD-t. A 21 szektoros viszont használható, ha nincsenek plusz sávok, akkor a mai Windowsok jól kezelik, tehát 1.44-es meghajtóhoz ez az ajánlott formátum: 1680K
(Megjegyzés késöbb a Microsoft is rájött, hogy milyen hülye helypazarló, és pl a Win 95 floppys verziójánál ilyen 1680K-s formátumot használt a telepítõlemezekhez.)

FAFO alapban a Zozotoolsban van benne, de létezik betölthetõ verzióban is, majd csinálok abból is frissített verziót. Mint korábban volt róla szó, a 2.5-ös verzió már a modernebb PC szabványok szerinti boot szektort készít.

FAFO 2.5 betölthetõ verzió. (Az emuhoz verzióban nincs Turbo EXDOS ellenõrzés.)