Zozo,

az miert van, hogy ugy kell kimuteni az EXDOS -ból a floppy vezérlő IC kezelést ?

Tehát ha van az EXDOS, az ő összes ismert funkciójával, és van neki egy bővítő interfésze, melyhez (mellyel) te tudtál illeszteni egy IDE vezérlő kártya hardvert,
akkor a floppy vezérlő harver a floppy vezérlő IC -vel miért nem ugyanezen a pluggable interfészen keresztül kapcsolódik az EXDOS -hoz ?

És akkor a WD IC (meg az egész floppy vezérlő elektronika) kezelésének kiműtése gyakorlatilag annyi volna, hogy a floppy vezérlő EXDOS bővítőt ne "láncolja be" az EXDOS, es joccakát ... nem ?

Lehetne azt is, de akkor a RAMDISK lesz az A: ...

Vagyis akkor rossz volt a kérdésfeltevés, mert igenis a pluggable EXDOS bővítő interfészen kapcsolódik az EXDOS -hoz a floppy vezérlő elektronika(-t vezérlő szoftver),

de te nem csak simán leválasztod a bővítőn át, hanem inkább meghagyod, és a floppy vezérlő EXDOS bővítő szoftverből hekkeled ki a floppy vezérlő hardware -hez nyúlkálásokat,

azért hogy a betűjelek konzisztensek maradjanak ?

Ha így van, akkor lehet egyszerűbb lenne valami fake meghajtót írj, ami leköti a betűjeleket még az IDE (vagy akármik) előtt, mint kihekkelni a floppy vezérlő HW nyúlkálásokat, nem ? Vagy ha ez igaz lenne, akkor úgy csináltad volna ?

Ugyan régi a topic, de - úgy érzem - ide tartozik. Mivel az ExDOS bővítésem összeállni látszik, az IDE interfész a következő megoldandó feladat. "Gyorsan" átfutottam a témát, remélem mindent jól értek...

Az első bejegyzésben szereplő rajz a jelenleg használatos interfész kapcsolási rajza? A címdekódolást vizsgálva "kijön" a 0xE8..0xEB illetve 0xEC..0xEF címtartomány a (talán) JP1 állása alapján, az _IORQ + ezen címekkor aktív (magas) lesz a 'HCT21 8-as lába, illetve a 'HCT04 10-ese emiatt alacsony. Ezt az "aktív" jelet meg az _RD meg a _WR alapján kétfelé bontja az U12 egy-egy kapuja, ezekből plusz a két alsó címbitből meg két demultiplexer ('HCT139) csinál 4-4 olvasáskor / íráskor aktív jelet. A regiszterek kiosztása is annak tűnik, mint ami az első hozzászólásban szerepel, ez eddig jónak tűnik...

A 'HCT139 kimenetei aktív alacsonyak, viszont a használt 'HCT273-as tárolók felfutóélre tárolnak. Emiatt azoknak a kimeneteik a ciklus végén állnak be. Ez az adatvonalak beírásánál semmi extra dolgot nem okoz. De a "parancsport" része egy kicsit trükkösnek tűnik. Ez itt az adat beírása, ami a topic elején van:


Első körben a B7..0 illetve B15..8 kerül beírásra (1..4 sorok), eddig sima. Utána jön a "regisztercím + írás" beállítása a "parancsport" regiszterbe (5..7 sorok). Az IDE busz fele akkor generálódik az ALE, IOR illetve IOW jel, amikor ezt a regisztert írja a Z80. Azt, hogy az IOR vagy az IOW lesz-e aktív, azt a "parancsport" hozzá tartozó két bitje határozza meg. Igen ám, de ezek csak akkor fognak beállni, amikor ez a beírási ciklus véget ért, tehát ekkor még nem történik semmi. A tényleges IDE regiszterírás akkor fog bekövetkezni, amikor az RD illetve WR bitek visszaállítását végzi a kód (8, 9 sorok), mivel a Z80 írási ciklusa közben ekkor aktív még a tároló RD vagy WR vonala.

Jól fejtegetek?

Én is meglepődtem, hogy működik
Azóta lett volna ötletem jobb megoldásra, de manapság minek, ott az SD vezérlő

Hallgatlak!

Amúgy egy kérdés ezek után felmerült bennem. Az IDE olvasási / írási ciklusa olyan hosszú így, mint a Z80 _WR impulzus ideje. Tehát nem a sebesség a felépítés oka. Akkor tulajdonképpen (maximális tisztelettel) szeretném megtudakolni, hogy miért lett ez ennyire elbonyolítva?

Az volt a régi tervem, hogy az IDE interfész lehető legnagyobb részét belapátolom a CPLD-be, de ez mindenestől nem fog beleférni, leginkább I/O láb hiányom van. Emiatt egy rakás alkatrészt kívülre kéne pakolnom, de az meg sok helyet foglal.

Arra gondoltam, hogy esetleg csinálnék egy egyszerűbb verziót, és az IDE.ROM megfelelő részeit esetleg megpeccselném... Kérdés hogy ez mennyire lehetetlen, forrás szinten biztosan egyszerűbb. Az IDE írás / olvasás hogyan van megcsinálva az IDE.ROM-ban? Nagyon nagy kaland azokat a részeket módosítani? (Mondjuk okosan, feltételes fordítással beépítve a módosítást, hogy ne kelljen külön verzió belőle.) Ha a kód mondjuk úgy lenne felépítve, hogy van egy közös írás illetve olvasás szubrutin, akkor a peccselős verzióm is működhetne. De ha "sok" helyen van direkt HW kezelgetés, az egy csöppet megbonyolítaná az életem.

(Közben itt szerkesztgetem a hozzászólást, de talán annyira nem beszélünk el egymás mellett. )

A 8/16 bit konverzió. Az alapötlet, hogy előre eltárolni a 16 bitnyi adatot, aztán az egyéb jelekkel együtt kiengedni az IDE buszra. Ill. fordítva. Mindezt ismert és kéznél lévő alkatrészekből összerakva

Ja, ismerős. Mi van a fiókban. Először arra gondoltam, hogy a Z80 írási ciklusa esetleg túl rövid az ISA ciklusaihoz képest, emiatt nem lett a buszra direkt rákötve az IDE interfész. A "saját" ötletem annyi, hogy a felső 8 bithez kell a 8 bites tárolópár, de az "alját" kaphatná közvetlenül a buszról. Ha sok címet az I/O területről nem akarok elhasználni, a regisztercím regisztere megmaradhat, esetleg kiegészítve azzal, hogy melyik IDE "csatornának" szól a dolog.

Ami ötletem lett volna. Kihasználni, hogy az OUT (C) műveleteknél kimegy a B az A8-A15-re (amiből ugyan az A14,A15-t a Dave "elrontja", de ez most nem érdekes), ebből az A8 vezérelné a plusz 8 bit-et. 0-nál eltárolja, 1-nél meg az aktuális 8 bittel együtt megy ki. Olvasásnál fordítva, 16 bit bejön, amiből 8 eltárolódik, következőben meg az a 8 bit jön.
Így lehetne a Z80 ciklusos utasításaival kezelni. Persze ez esetben az IDE regisztereket közvetlen Z80 I/O portokra kéne kódolni.

Ez most egy kicsit homályos, de ez úgyis teoretikus. (A Z80 ilyen "titkai" most nincsenek fejben előttem.)

Később még jobban megtetszett a CF, ami tud 8 bites üzemmódot, így nem kéne vacakolni a 16 bites konverzióval. Sőt tud memória üzemmódot is, ami még egyszerűbb és gyorsabb lenne. Ez ott akadt el, hogy csak gusztustalan felület szerelt CF foglalatokat találtam... mire találtam átmenőset, addigra már volt SD, így már sok értelme nincs ezzel is foglalkozni. Max az írás lehetne gyorsabb mint az SD, mert itt az is lehetne LDIR, míg ott már a CPLD erőforrások hiányában csak olvasásra van gyors üzemmód.

Ezt a 8 bites üzemmódot csak a CF tudja? Amúgy jó a "sima" másolgatás is, gyorsabb ez még így is, mint a sima floppy. Én is valami hozzáillő CF kártyát akarnék használni, örülök hogy a cucc csendben van. (Erről jut eszembe; a topic eleje fele valahol írtad, hogy ki kellene próbálni ST-157 HDD-vel. Az sikerült? Vagy csomagolhatok a pakkodhoz egy ilyen meghajtót is? )

Egy kicsit elhavaztam, de alakul a cucc. Nagyjából összeállt a jelenlegi, Zozo-féle IDE illesztővel kompatibilis elektronikám, amihez BASIC-ben írtam is pár tesztet. Ezek regiszter olvasás / írások, úgy tűnik, hogy valamelyik R/W-képes regiszterbe beírt adatokat vissza is tudom olvasni. Meg az állapotregiszter kiolvasott értéke is hihetőnek tűnik. Szóval valami van...

Viszont a keresgélésem nem hozott eredményt, a hozzá tartozó IDE.ROM fájlt nem találom. A legutolsó verzióról - tisztelettel - egy linket kérhetnék? Illetve "hova" is kell majd ezt beillesztenem?

EXDOS feletti szegmensre kell rakni, hogy inicializálva legyen mire az EXDOS indul.

Köszi, kipróbálom és beszámolok!

A BASIC tesztjeim amúgy csak fél sikert mutatnak, de a pontos okokat egyelőre nem tudom. Próbáltam egy "paraméterlekérdezés" parancsot küldeni a meghajtónak, de az állapotregiszterben a "hiba" jelzőbit bekapcsolódott, a hibaregiszterben meg a sokat mondó "végrehajtás során hiba történt" bit állt be. Előfordulhat valami TimeOut itt? (A BASIC meglehetősen lassú.)