Enterprise Forever

:HUN => Programozás => Topic started by: Zozosoft on 2006.August.23. 22:22:20

Title: EXDOS
Post by: Zozosoft on 2006.August.23. 22:22:20
Mi az érdekes a képen? :-)
(http://enterpriseforever.com/userpix/12_exdos03_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos03_1.png)
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.23. 22:42:10
MrPrise visszavonta a tippjét, pedig most készültem egy kis segítséget adni :-)
Közben kiszúrtam még valamit az általunk ismert verzióknál, ezt is kéritik felfedezni :-)
Sorban a képek: 1.0, a most kapott 1.2, angol-német 1.3 (ha jól tudom ez a egybe dobozolt floppys EXDOS-ban volt), és a leginkább elterjedt angol-magyar 1.3, amiben az ISDOS is benne van (és egy kicsit bele is piszkáltam, de nem ez az érdekes, tehát azt a sort nem kell figyelni :) )
(http://enterpriseforever.com/userpix/12_exdos10_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos10_1.png)
(http://enterpriseforever.com/userpix/12_exdos12_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos12_1.png)
(http://enterpriseforever.com/userpix/12_exdos13_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos13_1.png)
(http://enterpriseforever.com/userpix/12_exdos13h_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos13h_1.png)
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.23. 23:21:42
Ilyen nehéz a kérdés? :-)
Addig nem kaptok több érdekességet, míg meg nem fejtitek!  :twisted:
Title: Re: EXDOS
Post by: Lacika on 2006.August.23. 23:32:22
0.3-as EXDOS??? BUFFER parancs???
Ez meg mi fán terem?
Title: Re: EXDOS
Post by: Lacika on 2006.August.23. 23:35:08
Nem tudom, mit kell nézni a képen...
Az ATTR, ATDIR, ASSIGN, MAPDISK parancsok csak a Turbo-ban vannak.
A szabad memória mérete is változik egy pár byte-al.
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.23. 23:40:03
Quote from: "Lacika"
Nem tudom, mit kell nézni a képen...

Jó helyen keresgélsz, így kiérdemeltetek még egy képet :-)
(http://enterpriseforever.com/userpix/12_exdos20_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_exdos20_1.png)
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 01:05:06
Itt vannak a romok is:
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 01:24:47
Ami igazán izgalmas az elb...ott verziószámon kívül:
Az 1.0, 1.2, és az angol-német 1.3 ugyanazokat a parancsokat ismeri.
Ez a 0.3 6 új parancsot ismer! ATTR, EXIT, ATDIR, ASSIGN, BUFFERS, MAPDISK
Izgalmas, hogy a 2.0 is csak az alap parancsokat tudja...
És ott van még a nálunk legelterjedtebb angol-magyar 1.3-as, amiben ISDOS is van. Ez 4-et ismer az elöbb emlegetett 6-ból!
A "legújabb" 2 az EXIT, ez kilép az EXDOS ablakból, talán BAT fájlok számára lehet értelme, vagy MS-DOS kompatibilitás.
A legérdekesebb a BUFFERS! Ezt elõre megjósoltam :-)
Novemberben az EXDOS visszafejtés kezdetén elmélkedtem errõl:
Quote
"Beláncolásnál igényel egy darab 512 byte periféria RAM-ot, vagy hogyan?"
Ennél bonyolultabb :-) A beláncoló rutinnak egy paraméterben van átadva, annak 0 értékénél 537 bájtot igényelne. Az EXDOS 3-as értéket használ ez esetben, 1583 bájt lesz, és ezt osztja fel a megadott 3 diskpuffer területre,ill. valamennyit használ másra. Viszont érdekes ennek a beláncoló rutinnak a hívása! Az derül ki belõle, hogy ez a 3 a minimum szükséges diskpuffer szám de lehetne több is. Úgy mûködik a hívó program rész, hogyha nem sikerült a megadott mennyiséget lefoglalni, akkor újrapróbálkozik a minimális 3-as darabszámmal.
Felmerül a kérdés, hogyha átárírjuk nagyobbra az alapban használt minimális 3-as értéket akkor mi történik? Azon kívül, hogy szépen lefoglal több memóriát... (ezt ki is próbáltam :-)
Valami olyan tesztet kéne csinálni, ami több különbözõ meghajtón, több fájllal végez egyszerre mûveleteket, és megnézni, hogy a több pufferes EXDOS változatnál van-e gyorsulás. De ezt igazi EP-n kéne kipróbálni, emulátorok nem igazán alkalmasak floppykezelés teljeítményének mérésére :-)


Na ez a BUFFERS parancs pont ennek a beállítására szolgál!


Az nagyon érdekes, hogy a számszerint legnagyobb 2.0-ás csak az alapparancsokat ismeri... binárisan összehasonlítva a fájlokat, a 2.0 kb 50%-ban egyezik az 1.2-essel.
Ezek alapján nekem úgy tünik, hogy az 1.2 után következõ verziót 2.0-nak nevezték el. De aztán ez valahogy mégse került így kiadásra, talán azt mondták a fönökök, hogy nincs elég módosítás ekkora verziószám ugráshoz :-) így 1.3 néven folytatodott a fejlesztés.
Ennek elsõ verziója került németesítésre. Ez ránézésre semmi újat nem tud.
Egy következõ 1.3-as változat jutott el hozzánk, ebbõl lett az angol-magyar, ez ismeri már az ATTR, ATDIR, ASSIGN, MAPDISK parancsokat.
A legfejlettebb pedig a 0.3-as névre hallgató verzió. Csak mért 0.3, valaki elírt valamit? :D

Mindenesetre az összeset párhuzamosan kell disassemblálni, és akkor okosabbak leszünk :-)
Title: Re: EXDOS
Post by: MrPrise on 2006.August.24. 08:53:44
Quote from: "Zozosoft"
A legfejlettebb pedig a 0.3-as névre hallgató verzió. Csak mért 0.3, valaki elírt valamit? :D

Mindenesetre az összeset párhuzamosan kell disassemblálni, és akkor okosabbak leszünk :-)

Izgalmas! Tisztára mint valami nyomozás! :-D
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 09:03:22
Quote from: "MrPrise"
Izgalmas! Tisztára mint valami nyomozás! :-D

Pontosan :-) Az IDA tud párhuzamosan 6 fájlt feldolgozni? :-)
Title: Re: EXDOS
Post by: MrPrise on 2006.August.24. 09:07:02
Quote from: "Zozosoft"
Quote from: "MrPrise"
Izgalmas! Tisztára mint valami nyomozás! :-D

Pontosan :-) Az IDA tud párhuzamosan 6 fájlt feldolgozni? :-)

Elvileg csinálhatsz új szegmenseket és oda tudsz is berakni új file-t.
Title: Re: EXDOS
Post by: MrPrise on 2006.August.24. 09:10:01
Quote from: "MrPrise"
Quote from: "Zozosoft"
Quote from: "MrPrise"
Izgalmas! Tisztára mint valami nyomozás! :-D

Pontosan :-) Az IDA tud párhuzamosan 6 fájlt feldolgozni? :-)

Elvileg csinálhatsz új szegmenseket és oda tudsz is berakni új file-t.

Ezeknek gondolom, már nem tudsz megadni úgy offsetet, hogy mind 0xc000-tól látszódjon, ami a visszafejtést picit nehezíti. Lehet, hogy mégis lehet valahogy, nem tudom. Nem volt még rá szükségem, hogy több file-t fejtsek vissza egyszerre ;-)
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 09:20:49
Úgy tünik el lehet indítani egyszerre több IDA-t :-)
Title: Re: EXDOS
Post by: MrPrise on 2006.August.24. 09:21:33
Quote from: "Zozosoft"
Úgy tünik el lehet indítani egyszerre több IDA-t :-)

Akkor meg banzáj! :-D
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 10:16:55
Ilyet is kaptunk Adrian barátunktól :) remélem kitaláljátok mi ez :-)
(http://enterpriseforever.com/userpix/12_hdos_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_hdos_1.png)
Title: Re: EXDOS
Post by: XYBeR on 2006.August.24. 10:52:17
Quote from: "Zozosoft"
Ilyet is kaptunk Adrian barátunktól :) remélem kitaláljátok mi ez :-)
(http://enterpriseforever.com/userpix/12_hdos_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_hdos_1.png)


wow! az eredeti ep-s vinyóvezérlõ szoftvere?
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 11:00:09
Quote from: "XYBeR"
wow! az eredeti ep-s vinyóvezérlõ szoftvere?

Pontosan! Arról a cuccról (http://www.binarydinosaurs.co.uk/Museum/Enterprise/harddisk/index.php) van szó amit Kopácsy emlegett az 1991-es interjúban (http://ep.homeserver.hu/Dokumentacio/Cikkek/VTGe.htm), azaz amivel XT kártyákat lehet EP-hez kötni.
Amit sokáig csak legendának gondoltunk :-)

Ez a program csinál egy F: meg egy G: meghajtót, persze a hw nélkül sokra nem megyünk :-)
Ez a két meghajtó meg is felel annak, hogy 87-ben két vinyót köthettél egy MFM kártyára, amik lehettek kb 10-20 megásak. Így itt még nem merül fel a több mint 32M, sok partició kellene problémakör, elég 1-1 betü a két vinyónak.

Remélem a visszafejtés során azért sikerül új információkat kideríteni az EXDOS bõvítés mikéntjérõl.
Title: Re: EXDOS
Post by: XYBeR on 2006.August.24. 11:59:51
Quote from: "Zozosoft"
Quote from: "XYBeR"
wow! az eredeti ep-s vinyóvezérlõ szoftvere?

Pontosan! Arról a cuccról (http://www.binarydinosaurs.co.uk/Museum/Enterprise/harddisk/index.php) van szó amit Kopácsy emlegett az 1991-es interjúban (http://ep.homeserver.hu/Dokumentacio/Cikkek/VTGe.htm), azaz amivel XT kártyákat lehet EP-hez kötni.
Amit sokáig csak legendának gondoltunk :-)

Ez a program csinál egy F: meg egy G: meghajtót, persze a hw nélkül sokra nem megyünk :-)
Ez a két meghajtó meg is felel annak, hogy 87-ben két vinyót köthettél egy MFM kártyára, amik lehettek kb 10-20 megásak. Így itt még nem merül fel a több mint 32M, sok partició kellene problémakör, elég 1-1 betü a két vinyónak.

Remélem a visszafejtés során azért sikerül új információkat kideríteni az EXDOS bõvítés mikéntjérõl.


na igen, de 160M-es vinyót emlegettek egyesek...
kitõl van egyébként a rom? (le vagyok maradva)
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 12:08:05
Quote from: "XYBeR"
na igen, de 160M-es vinyót emlegettek egyesek...

Az 1991-ben volt, de ez a ROM 1987-es! Ezek szerint már 87-ben kész volt a dolog, csak mélyen kussoltak róla :(

Quote from: "XYBeR"
kitõl van egyébként a rom? (le vagyok maradva)

Adrian Grahamtõl aki a Binary Dinosaurs (http://www.binarydinosaurs.co.uk/Museum/Enterprise/index.php) oldal gazdája.
A gyûjteményében lévõ dolgokból azt sejtem, hogy a német cég megszünte után kidobott cuccok egy része kerülhetett hozzá.
Title: Re: EXDOS
Post by: XYBeR on 2006.August.24. 12:28:44
Quote from: "Zozosoft"
Quote from: "XYBeR"
na igen, de 160M-es vinyót emlegettek egyesek...

Az 1991-ben volt, de ez a ROM 1987-es! Ezek szerint már 87-ben kész volt a dolog, csak mélyen kussoltak róla :(

Quote from: "XYBeR"
kitõl van egyébként a rom? (le vagyok maradva)

Adrian Grahamtõl aki a Binary Dinosaurs (http://www.binarydinosaurs.co.uk/Museum/Enterprise/index.php) oldal gazdája.
A gyûjteményében lévõ dolgokból azt sejtem, hogy a német cég megszünte után kidobott cuccok egy része kerülhetett hozzá.


az évet nem néztem :) de egyébként nemcsak a kopácsys intejrúból emlékszem a vinyót illetõen, a mikro magazinban is írtak (az pedig korábban volt) ilyesmirõl
Title: Re: EXDOS
Post by: geco on 2006.August.24. 15:26:13
Mik nem kerülnek elõ.:)
Title: Re: EXDOS
Post by: Povi on 2006.August.24. 17:34:01
Zozonak:
Title: Re: EXDOS
Post by: Zozosoft on 2006.August.24. 18:49:46
Quote from: "Povi"
Zozonak:

Köszi! Ez egy újabb fajta 1.3 :-)
Angol-magyar, már ISDOS-szal, de a HELP listában még nincs kiírva az ISDOS.
Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.26. 10:49:56
előkerültek az EXDOS bővítés eredeti leírásai vagy a fontos fejezetek még mindíg nincsenek? érdekelne pl. hogy az EXDOS(FD) EXDOS(FC) EXDOS(FB) bővítők meghívásával milyen lehetőségeket biztosít az EXDOS?
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.26. 18:15:40
elõkerültek az EXDOS bõvítés eredeti leírásai vagy a fontos fejezetek még mindíg nincsenek?
Azok sajnos továbbra is hiányoznak :-(
érdekelne pl. hogy az EXDOS(FD) EXDOS(FC) EXDOS(FB) bõvítõk meghívásával milyen lehetõségeket biztosít az EXDOS?
Engem is érdekelnének :-)
Amit visszafejtés során sikerült kiderítenem, azt még az indexes fórumba írtam:
Úgy mûködik az EXDOS, hogy a 26 logikai meghajtó (A-Z) számára létrehoz egy fizikai meghajtó hozzárendelési táblázatot. Itt kezdetben mindegyik logikai az azonos számú fizikai meghajtóhoz van rendelve, de ez pl ASSIGN utasítás hatására változhat.
Ha meg van a fizikai meghajtó száma, akkor egy másik táblázatból keresi ki a fizikai meghajtó leíróját. Ez a táblázat 3 bájtos elemekbõl áll, megadja a leírót tartalamzó szegmens számát, és persze a leíró címét.
A fizikai meghajtó leírója többek között tartalmazza kezelõ program szegmensszámát és kezdõcímét, a kezelõprogramhoz tartozó RAM terület szegmensszámát és címét. Innen már látszik, hogy milyen szép rugalmasan bõvíthetó rendszerrõl van szó, úgy ahogy azt már az EXOS mûködésében is megszokhattuk!
Az inicializálási folyamatban úgy néz ki, hogy miután a logikai meghajtók táblázatát felépítette, elkezdi összeszedni a rendelkezésre álló fizikai meghajtókat. Elöször az EXDOS ábrán (http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/images/exdos.gif) látható UNITH egységet veszi fel, ami 4 meghajtót vállal be, ez az egység végzi a floppy kezelést, tehát ez lesz a négy floppy meghajtó A:-C:
Következõ és egyben utolsó belsõ EXDOS egység a RAMUNIT, ami 1 meghajtót vállal, magyarán ez lesz a RAMDISK, E: meghajtóként.
Ezután jön a számunkra roppant fontos rész: az EXDOS lekérdezi a lehetséges EXDOS bõvítéseket!
Ez ugy néz ki, hogy EXDOS,0FFH paranccsal kérdezi le a rendszerbõvítõket. Ha egy bõvítõ szeretne csatlakozni, akkor a következõ a dolga: saját RAM területén biztosítja a fizikai meghajtók leírónak szükséges helyet. Visszatéréskor B-ben megadja ennek a területne a szegmensszámát, DE-ben a címét. A megadott terület elején pedig a következõ adatokat kell letárolni: kezelendõ meghajtók darabszáma, kezelõ program címe és szegmensszáma.
Ezen adatok alapján az EXDOS elkészíti a szükséges számú meghajtó leírót a megadott RAM területen, és ezek címét eltárolja a saját fizikai meghajtó táblázatában.
Fontos, hogy a bõvítõ jegyezze meg, hogy egyszer már válaszolt az EXDOS,0FFH parancsra, továbbiakban hagyja figyelmen kivûl! Ez a módszer biztosítja azt, hogy tetszõleges számú EXDOS bõvítõ csatolható a rendszerhez. Az EXDOS addig kérdezget az EXDOS,0FFH paranccsal, amíg már senki nem válaszol rá.
Amikor összegyûjtötte az összes fizikai meghajtót, létrehozza a szükséges számú EXOS perifériát, A: B: stb neveken.
Ezután még lehetõséget ad az EXDOS a bõvítõknek, hogy saját inicializálást végezzenek, ez elsõ esetben, vagyis hidegindításkor az EXDOS,0FCH paranccsal történik. A bõvítõknek változatlan BC, DE regisztertartalommal kell visszatérni ebbõl a parancsból, hogy az összes a bõvítõ sorban megkapja a parancsot.
Melegindítás esetén EXDOS,0FBH parancs jár körbe.
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.26. 18:30:59
És amit a kezelõprogramról sikerült kideríteni:
A=akciókód, C=alegység sorszám, IX=transzfercím, IY=kezelöprogram adatterülete.
P0=nullás lap, P1=transzfer terület szegmense, P2=kezelöprogram adatterület szegmense, P3=kezelöprogram szegmense.
3-as akciókód: lemeztipus megadása, transzfer területre be kell olvasni a BOOT szektort, visszaadandó B=formázási tipusbájt,HL=utolsó logikai szektor sorszáma (azaz szektorok száma-1)
4-es akciókód: logikai szektorok olvasás
5-ös akciókód: logikai szektorok írása
6-os akciókód: logikai szektorok irása ellenõrzéssel
Mind három esetben B=átviendõ szektorok száma, DE=kezdõ szektor sorszáma.

A FISH nem foglalkozik formázással, miután a FORMAT megkérdezte, hogy biztos vagy-e benne, és azt válaszoltad, hogy igen, akkor 8-as akciókóddal meghívja a meghajtó kezelõprogramját, hogy "formázd meg a hozzád tartozó lemezt, hogy hogyan az a te dolgod, engem csak az érdekel, hogy sikerült-e" :-) A boot szektort el kell készíteni, a FAT táblákat és a fõkönyvtárat már az EXDOS készíti el az adatok alapján (amit 3-as kóddal kér be).

Az 1,2,7-es kódokról még nem tudni mi az, de az EXDOS használja... a vinyóvezérlõ programja ilyenkor RET-tel válaszol...


Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.26. 19:22:23
szerinted EXDOS(FD)-vel körbehív valaha, mert a sztringet látni benne.

parancsfüzér feldolgozása előtt miért állsz meg ha P1-en a nullás szegmens van?
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.26. 20:31:00
szerinted EXDOS(FD)-vel körbehív valaha, mert a sztringet látni benne.
Az a parancs sztringek között van.
Felhasználói program tudja hívni.
Válaszként B=EXDOS verziószám
DE pedig a FISH adatterületre mutat a rendszerszegmensben.
parancsfüzér feldolgozása elõtt miért állsz meg ha P1-en a nullás szegmens van?
Ezt hol látod? Amúgy:
Quote from: Intelligent Software
Note that ROM extensions are allowed to make scan extension EXOS calls while in their allocate RAM routines. This can result in a ROM being entered with action code 2 or 3 before it has any RAM allocated. This case can be detected by testing for segment number zero in Z80­page 1, which can only occur before RAM is allocated, or if no RAM is requested.
Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.27. 12:56:52
Ezt hol látod? Amúgy:
Quote from: Intelligent Software
Note that ROM extensions are allowed to make scan extension EXOS calls while in their allocate RAM routines. This can result in a ROM being entered with action code 2 or 3 before it has any RAM allocated. This case can be detected by testing for segment number zero in Z80­page 1, which can only occur before RAM is allocated, or if no RAM is requested.

exdext.asm -ban láttam. ez az angol nyelvű exos technikai leírásból van? én még soha nem láttam ilyet bekövetkezni. mi az a formázási tipusbájt?
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.29. 09:42:45
ez az angol nyelvû exos technikai leírásból van?
Igen. A magyarban is benne van, csak kicsit zavarosra sikerült a fordítás...
én még soha nem láttam ilyet bekövetkezni.
Attól még bekövetkezhet :-) Ami benne van az EXOS leírásban, arra fel kell készülni.
mi az a formázási tipusbájt?
Media descriptor
0xF0    Double Sided, 80 tracks per side, 18 sectors per track
0xF8    Single sided, 80 tracks per side, 9 sectors per track
0xF9    Double sided, 80 tracks per side, 9 sectors per track
0xFA    Single sided, 80 tracks per side, 8 sectors per track
0xFB    Double sided, 80 tracks per side, 8 sectors per track
0xFC    Single sided, 40 tracks per side, 9 sectors per track
0xFD    Double sided, 40 tracks per side, 9 sectors per track
0xFE    Single sided, 40 tracks per side, 8 sectors per track
0xFF    Double sided, 40 tracks per side, 8 sectors per track

Természetesen az elsõt az EXDOS FORMAT (még :-) ) nem ismeri.
Ez a érték kerül a BOOT szektor 31. bájtjára, és a FAT elsõ bájtjára.
(Kis kiegészítés: EP-n RAMDISK esetén ez az érték 2AH)
Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.29. 10:55:41
ez a tipusbyte befolyásolja valahol a működést a unit handleren kívül? ha nem, akkor felteszem a 2a-nak sincs semmi jelentősége hiszen úgysem abból hámozza ki a fish, hogy melyik unit handlerhez forduljon.
Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.29. 11:05:47
egy másik találós kérdés: mi lehet az oka annak hogy DISK: és az A: nevü eszközök eszközkezelői eltérőek?
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.29. 11:16:40
ez a tipusbyte befolyásolja valahol a mûködést a unit handleren kívül?
Maga a FISH csak logikai szektorokkal foglalkozik (mai fogalmaink szerint: LBA címzést használ), az már az adott meghajtóhoz tartozó kezelõprogram dolga, hogy fordítja le ezt a fizikai lemez formátumára.
Egy helyen foglalkozik a típusbájttal a FISH: a FORMAT parancs végrehajtásakor a /1/H/8 paraméterek éppen megadott kombinációját típusbájtra lefordítva adja át a meghajtó kezelõprogramjának.
De az már a program belsõ ügye, hogy mit csinál ezzel az információval...
ha nem, akkor felteszem a 2a-nak sincs semmi jelentõsége hiszen úgysem abból hámozza ki a fish, hogy melyik unit handlerhez forduljon.
Így van ez a FISH-t nem érdekli. Minket érdekelhet, ha pl EXOS 2.3 RAMDISK megõrzést írunk :-)
Title: Re: EXDOS
Post by: Zozosoft on 2007.May.29. 11:28:10
egy másik találós kérdés: mi lehet az oka annak hogy DISK: és az A: nevü eszközök eszközkezelõi eltérõek?
Ebbe még nem ástam be magam, de pl a DISK-nél úgy kell kezdeni, hogy DISK:,DISK-1:,DISK-2:,stb szét legyen válogatva az aktuális, A:,B:,stb meghajtókra.
A:,B:,stb meg egybõl az adott meghajtóra vonatkozik, itt számozott eszköznév hibát is okoz.
Title: Re: EXDOS
Post by: Mayer Gábor on 2007.May.29. 13:18:02
de ha jól sejtem ez a szétválasztás még az eszközkezelő előtt megtörténik, tehát az eszközkezelő program csak azt kapja meg, hogy hanyadik aleszközhöz szól az aktuális kérés. persze ez csak tipp nem tudom pontosan. akár az is lehetne a válasz, hogy a szétválasztást nem az eszközkezelőben csináják hanem már eleve az a rész van csak beállítva eszközkezelőnek ami ténylegesen szükséges, viszont arra nem találtam magyarázatot, hogy miért eltérő a működés a következő esetben:

ha másolunk SERIAL: -rol DISK: -re (és ugye itt nem lesz eof kénytelenek vagyunk stoppolni) akkor kiírodik a file ha az kevesebb mint 512 byte, de ha SERIAL: -rol A: -ra másolunk akkor nem. lehet hogy pont fordítva van, nem emlékszem, de ez az eltérés. tippem szerint valami puffer kiírás nem következik be az egyik esetben. itt figyeltem fel arra, hogy eleve eltérő a két eszközkezelő címe.

Title: Re: EXDOS
Post by: Zozosoft on 2008.May.15. 00:23:29
Most, hogy végre sikerült egy eredeti IS-DOS lemezt megkaparintanom :-) végre megnézhettem azt, amire évek óta kiváncsi voltam: gyári EP program lemezét mivel formázták: EP-vel? PC-vel?
De amit találtam attól kicsit kiakadtam, hogy ez meg mi????? EXDOS 4.0  :?:  :?:  :?:

Szalai! Meg tudnád nézni a te példányod boot szektorát?

[attachimg=1]
Title: Re: EXDOS
Post by: Mayer Gábor on 2008.May.15. 00:41:34
eredeti? guy kopexy? mi ez???
Title: Re: EXDOS
Post by: Zozosoft on 2008.May.15. 00:49:47
eredeti?
Eredeti (http://enterpriseforever.com/dlattach.html;topic=170.0;attach=1130;image), legalábbis ezt árulták a Centrumban :-)
Mint látható írás engedélyezõ bevágás sincs rajta.

Quote
guy kopexy? mi ez???
Ezt egy másik topicban boncolgatom :-)
Title: Re: EXDOS
Post by: Ep128 on 2008.May.15. 00:57:42
Itt lép be a képbe az a bizonyos "másik Enterprise", amirõl Kopácsy titokzatoskodott anno...?  :roll:
Title: Re: EXDOS
Post by: Zozosoft on 2008.May.15. 10:22:43
Itt lép be a képbe az a bizonyos "másik Enterprise", amirõl Kopácsy titokzatoskodott anno...?  :roll:
Na ez ugrott be nekem is... de lehet, hogy csak simán egy újabb verzió? Végülis elõkerült nemrég egy 2.0-ás is...
Title: Re: EXDOS
Post by: Zozosoft on 2008.May.15. 21:31:10
Na, nagy nehezen sikerült összehoznom egy disk image-t az eredeti IS-DOS lemezrõl. Nem volt egyszerû, mivel egy mai PC-t nagyjából lehetetlen rávenni egy SS/SD floppy olvasására, különösen picipuha oprendszer alatt...
Végül EP-n egy EPDOS Disk parancsokat használó Basic programmal sikerült összehozni :-)
Title: Re: EXDOS
Post by: szalai56 on 2008.May.19. 18:55:04
Megnéztem, az én lemezemen is EXDOS4.0 van. Bájtra stimmel a Zozo lemezével.
Title: Re: EXDOS
Post by: Zozosoft on 2008.May.19. 18:57:01
Megnéztem, az én lemezemen is EXDOS4.0 van. Bájtra stimmel a Zozo lemezével.
Köszi! Akkor ezt ezek szerint így árulták nálunk.

Felteszem a kérdést a külföldieknek, van-e valakinek angol kiadású?
Title: Re: EXDOS
Post by: IstvanV on 2008.December.14. 21:47:57
Elfelejtettem, szerintem EP32 (EXDOS) csak floppy méretû image-okat eszik... A Zozo-féle EXDOS bõvítés (IDE vezérlõhöz) meg 32 Mbyte-osat fog, mert azt az EP32 még nem emulálja...
Ilyen EXDOS bővítés van floppyhoz is ? Az ep128emu-val több mint 50 MB méretű floppy image is kezelhető, de például egy 32 MB méretűre formázott image-t az EXDOS csak 360K-nak "lát". Nem tudom, pontosan mekkora a legnagyobb használható méret, de 4.7 MB (240*2*20*512 byte) például még működik.
Title: Re: EXDOS
Post by: IstvanV on 2008.December.15. 13:09:25
Úgy látszik, a legnagyobb használható méret 240/2/40 (azaz 9600 KB), de az is csak az emulátorhoz módosított EXDOS változattal, mert az eredeti csak 9 szektort fogadott el egy sávban, ami az ep128emu csomagban található 2 MB-os image használatát teszi lehetővé. Az alábbi .7z file-ban megtalálható a 9600K méretűre formázott "floppy", és egy valamivel kisebb 8 MB-os image is, amivel a cluster méret még nem 4, hanem csak 2 KB.
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.15. 13:20:40
Úgy látszik, a legnagyobb használható méret 240/2/40 (azaz 9600 KB), de az is csak az emulátorhoz módosított EXDOS változattal
Azért lett 40, hogy a túlformázott ED-s lemezt is kezelje. Viszont átírhatjuk akár 255-re is :-)
A 240 sáv az hogy jött ki? Van arra is valami ellenõrzés?
Viszont határ fog szabni a FAT12 fájlbejegyzések száma, úgy emlékszem, hogy floppyn csak 1-2 szektoros clustereket kezel. De nem biztos, ezt újra le kéne tesztelni :-) lehet, hogy csak az EPDOS-szal keverem.
Az biztos, hogy maga az EXDOS magja kezeli a többet is, hiszen vinyón megy. Kérdés, hogy a floppy kezelõ modulban van-e erre is ellenõrzés?
Title: Re: EXDOS
Post by: IstvanV on 2008.December.15. 18:02:52
Azért lett 40, hogy a túlformázott ED-s lemezt is kezelje. Viszont átírhatjuk akár 255-re is :-)
A 240 sáv az hogy jött ki? Van arra is valami ellenõrzés?
Az az emulátorban van, legfeljebb 240/2/240 (~56 MB) méretű image-t fogad el :) :oops: Bár az EXDOS ROM-ban is van egy CP 0F0h utasítás a szektorok számát ellenőrző rész közelében, annak valószínűleg más funkciója van :)
Quote
Viszont határ fog szabni a FAT12 fájlbejegyzések száma, úgy emlékszem, hogy floppyn csak 1-2 szektoros clustereket kezel. De nem biztos, ezt újra le kéne tesztelni :-) lehet, hogy csak az EPDOS-szal keverem.
Az biztos, hogy maga az EXDOS magja kezeli a többet is, hiszen vinyón megy. Kérdés, hogy a floppy kezelõ modulban van-e erre is ellenõrzés?
Megpróbáltam módosítani az exdos13.rom-ot, és úgy látszik, legfeljebb 128 szektor lehet egy sávban, ezt az értéket túllépve hibásan működik. Ezért a lenti exdos13.rom-ban az ellenőrzést 128 szektorra állítottam be. Viszont egy 30 MB-os (240 sáv és 128 szektor/sáv) image még valóban használhatónak tűnik, amint az az alábbi screenshoton is látható.
A .7z csomagban egy 16 MB-os (4K cluster méret) és egy 30 MB-os (8K cluster méret) image található.
[attachthumb=#]
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.15. 18:11:45
Bár az EXDOS ROM-ban is van egy CP 0F0h utasítás a szektorok számát ellenõrzõ rész közelében, annak valószínûleg más funkciója van :)
Az a típusbájtot ellenõrzi, eredetileg CP 0F8h, a HD-s lemezek használatához lett módosítva (elõször a Turbo EXDOS-ban, most késöbb meg az összes verzióban az emuhoz)
Quote
Megpróbáltam módosítani az exdos13.rom-ot, és úgy látszik, legfeljebb 128 szektor lehet egy sávban, ezt az értéket túllépve hibásan mûködik. Ezért a lenti exdos13.rom-ban az ellenõrzést 128 szektorra állítottam be. Viszont egy 30 MB-os (240 sáv és 128 szektor/sáv) image még valóban használhatónak tûnik, amint az az alábbi screenshoton is látható.
A .7z csomagban egy 16 MB-os (4K cluster méret) és egy 30 MB-os (8K cluster méret) image található.
Na ez király, ha minden igaz ez jó lesz arra, hogy EPDOS 1.9-ben bugokat vadásszunk, addig is, amíg nem lesz kész a vinyó emuláció :-)
Mindjárt megcsinálom akkor a többi EXDOS verziót is.
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.15. 19:20:43
az eredeti csak 9 szektort fogadott el egy sávban
Az eredeti 10 szektort fogadott el!
Elég hamar ki is jött egy 800K-s formázó program (amit nem látok fent az ep128.hu-n, kénytelen leszek elõásni...), majd azt hiszem a Venus volt a következõ, ami 820-ra formázott. Ezután jött az EPDOS, ahol már be lehetett állítani a plusz sávok számát, ill. a szektor számot is 8-11-ig.
Viszont ekkor még nem mûködött a 11 szektoros lemez, Not a DOS disk hibával. Haluska Laci azt hitte, hogy fizikailag képtelen az EXDOS olvasni. Én viszont rájöttem, hogyha a boot szektorban átszerkesztem 10 szektorosra a lemezt, akkor mûködik. (Igaz lassan, ekkor jött az interleave ötlet, amirõl már a FAFO topicban beszéltünk)
Vagyis ha fizikailag olvassa, akkor valami ellenõrzés lesz...
Így is lett végül kiszúrtam, hogy hol is van ez a vizsgálat.
Ekkor lett a 11 szektoros változat, amiben ki lett javítva ez a szám, itt az EXDOS Help-be be is került, hogy 11 sector version by Zozosoft  :ds_icon_cheesygrin:
Turbósításnál lett elõször 13 szektoros, amit a sima DD-s lemezre lehetett rávésni, Lacika tapasztalatai alapján mondhatjuk, hogy az idõ próbáját is kiállta a dolog :-)
HD-s turbónál pedig 22 szektoros, ekkor lett a típusbájt vizsgálat is módosítva.

Most pedig itt az egész gyûjtemény 128 szektoros :-)
Dokumentáció jelleggel pedig a módosított bájtok helyei, elsõ a típusbájt, második a szektorszám:
0.3: 21B6,21F2
1.0: 2743,277C
1.2: 228E,22C7
1.3: 2073,20AC
2.0: 2296,22CF
Title: Re: EXDOS
Post by: IstvanV on 2008.December.15. 22:07:36
Most pedig itt az egész gyûjtemény 128 szektoros :-)
Dokumentáció jelleggel pedig a módosított bájtok helyei, elsõ a típusbájt, második a szektorszám:
0.3: 21B6,21F2
1.0: 2743,277C
1.2: 228E,22C7
1.3: 2073,20AC
2.0: 2296,22CF

A ROM csomagot lecseréljem ? Esetleg az ep128emu image csomagjában (disk.zip) vagy az ep128.hu-n az emulátor oldalon lehetne nagy méretű üres image is ?
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.15. 22:20:17
A ROM csomagot lecseréljem ? Esetleg az ep128emu image csomagjában (disk.zip) vagy az ep128.hu-n az emulátor oldalon lehetne nagy méretû üres image is ?
Szerintem mehet! Jó ez a kvázi vinyó :-)
Amúgy egy ilyen image fájlt viszonylag egyszerûen fel is lehet majd írni EP vinyóra. Visszafelé egy picit bonyolultabb, mert lehet, hogy nem jön ki kerek értékre mint "floppy lemez"... esetleg ha az emu úgy kezelné, hogy elfogadja az ilyen nem pont sáv végén végzõdõ image-t is, akkor nincs gond. (A nem létezõ szektorokra nyugodtan lehet Sector Not Found-ot adni, normál esetben úgyse fog arra járni az EXDOS, max csak Disk Editor használatával)
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.16. 18:28:07
Még két módosított EXDOS verzió, amelyek a sebességet javítják emulátor alatt.
Itt pontosan mi lett változtatva?
Title: Re: EXDOS
Post by: Lacika on 2008.December.16. 18:35:00
Szerény véleményem szerint, előbb-utóbb hatalmas kavarodás lesz abból, ha nem az emulátort írjuk az Ep-hez, hanem az Ep programjait az emulátorhoz... :oops:
Title: Re: EXDOS
Post by: IstvanV on 2008.December.16. 18:51:59
Itt pontosan mi lett változtatva?

A szektor olvasást és írást végző ciklusok, bár sok más helyen lehetne például várakozásokat rövidíteni vagy törölni. Ezek a változások az eredeti EXDOS ED-s lemezt is elfogadó változatához képest. Amint látható, meghagytam azt, hogy írásnál a szektor vége után még egy byte-ot kiír :)
Az exdos13e.rom feltételezte az emulátornak azt a tulajdonságát, hogy a DRQ jel olvasás és írás közben mindig aktív, és a következő byte feldolgozását egyszerűen a Z80 port műveletei engedélyezik (tehát akár INIR/OTIR utasítást is lehetne használni). Az első változat csak optimalizálva volt erre az esetre, de még "szabályosan" figyelembe vette a DRQ jelet.

Code: Diff
  1. --- exdos13.s   2008-12-16 18:41:42.000000000 +0100
  2. +++ exdos13f.s  2008-12-16 18:40:52.000000000 +0100
  3. @@ -4711,13 +4711,13 @@
  4.  .   DE60  ED 78        IN    A, (C)
  5.  .   DE62  F2 4A DE     JP    P, DE4A
  6. -.   DE65  0D           DEC   C
  7. -.   DE66  ED 78        IN    A, (C)
  8. -.   DE68  77           LD    (HL), A
  9. -.   DE69  23           INC   HL
  10. -.   DE6A  0C           INC   C
  11. -.   DE6B  ED 78        IN    A, (C)
  12. -.   DE6D  E6 82        AND   82
  13. -.   DE6F  28 FA        JR    Z, DE6B
  14. -.   DE71  FA 65 DE     JP    M, DE65
  15. +.   DE65  C5           PUSH  BC
  16. +.   DE66  0D           DEC   C
  17. +.   DE67  16 82        LD    D, 82
  18. +.   DE69  ED A2        INI
  19. +.   DE6B  DB 18        IN    A, (18)
  20. +.   DE6D  A2           AND   D
  21. +.   DE6E  FA 69 DE     JP    M, DE69
  22. +.   DE71  28 F8        JR    Z, DE6B
  23. +.   DE73  C1           POP   BC
  24.  .   DE74  18 6A        JR    DEE0
  25.  .   DE76  3E A8        LD    A, A8
  26. @@ -4740,14 +4740,13 @@
  27.  .   DE97  18 F0        JR    DE89
  28.  .   DE99  0D           DEC   C
  29. -.   DE9A  59           LD    E, C
  30. -.   DE9B  0C           INC   C
  31. -.   DE9C  56           LD    D, (HL)
  32. -.   DE9D  23           INC   HL
  33. -.   DE9E  ED 78        IN    A, (C)
  34. -.   DEA0  E6 82        AND   82
  35. -.   DEA2  28 FA        JR    Z, DE9E
  36. -.   DEA4  4B           LD    C, E
  37. -.   DEA5  ED 51        OUT   (C), D
  38. -.   DEA7  FA 9B DE     JP    M, DE9B
  39. +.   DE9A  58           LD    E, B
  40. +.   DE9B  16 82        LD    D, 82
  41. +.   DE9D  ED A3        OUTI
  42. +.   DE9F  DB 18        IN    A, (18)
  43. +.   DEA1  A2           AND   D
  44. +.   DEA2  FA 9D DE     JP    M, DE9D
  45. +.   DEA5  28 F8        JR    Z, DE9F
  46. +.   DEA7  ED A3        OUTI
  47. +.   DEA9  43           LD    B, E
  48.  .   DEAA  0C           INC   C
  49.  .   DEAB  2B           DEC   HL
  50. @@ -5032,5 +5031,5 @@
  51.  .   E0A8  20 12        JR    NZ, E0BC
  52.  .   E0AA  3D           DEC   A
  53. -.   E0AB  FE 2A        CP    2A
  54. +.   E0AB  FE 80        CP    80
  55.  .   E0AD  30 0D        JR    NC, E0BC
  56.  .   E0AF  56           LD    D, (HL)
  57.  
  58. --- exdos13.s   2008-12-16 18:41:42.000000000 +0100
  59. +++ exdos13e.s  2008-12-16 18:41:00.000000000 +0100
  60. @@ -4711,13 +4711,13 @@
  61.  .   DE60  ED 78        IN    A, (C)
  62.  .   DE62  F2 4A DE     JP    P, DE4A
  63. -.   DE65  0D           DEC   C
  64. -.   DE66  ED 78        IN    A, (C)
  65. -.   DE68  77           LD    (HL), A
  66. -.   DE69  23           INC   HL
  67. -.   DE6A  0C           INC   C
  68. -.   DE6B  ED 78        IN    A, (C)
  69. -.   DE6D  E6 82        AND   82
  70. -.   DE6F  28 FA        JR    Z, DE6B
  71. -.   DE71  FA 65 DE     JP    M, DE65
  72. +.   DE65  C5           PUSH  BC
  73. +.   DE66  0D           DEC   C
  74. +.   DE67  16 82        LD    D, 82
  75. +.   DE69  ED A2        INI
  76. +.   DE6B  ED A2        INI
  77. +.   DE6D  DB 18        IN    A, (18)
  78. +.   DE6F  A2           AND   D
  79. +.   DE70  FA 69 DE     JP    M, DE69
  80. +.   DE73  C1           POP   BC
  81.  .   DE74  18 6A        JR    DEE0
  82.  .   DE76  3E A8        LD    A, A8
  83. @@ -4740,14 +4740,13 @@
  84.  .   DE97  18 F0        JR    DE89
  85.  .   DE99  0D           DEC   C
  86. -.   DE9A  59           LD    E, C
  87. -.   DE9B  0C           INC   C
  88. -.   DE9C  56           LD    D, (HL)
  89. -.   DE9D  23           INC   HL
  90. -.   DE9E  ED 78        IN    A, (C)
  91. -.   DEA0  E6 82        AND   82
  92. -.   DEA2  28 FA        JR    Z, DE9E
  93. -.   DEA4  4B           LD    C, E
  94. -.   DEA5  ED 51        OUT   (C), D
  95. -.   DEA7  FA 9B DE     JP    M, DE9B
  96. +.   DE9A  58           LD    E, B
  97. +.   DE9B  16 82        LD    D, 82
  98. +.   DE9D  ED A3        OUTI
  99. +.   DE9F  ED A3        OUTI
  100. +.   DEA1  DB 18        IN    A, (18)
  101. +.   DEA3  A2           AND   D
  102. +.   DEA4  FA 9D DE     JP    M, DE9D
  103. +.   DEA7  ED A3        OUTI
  104. +.   DEA9  43           LD    B, E
  105.  .   DEAA  0C           INC   C
  106.  .   DEAB  2B           DEC   HL
  107. @@ -5032,5 +5031,5 @@
  108.  .   E0A8  20 12        JR    NZ, E0BC
  109.  .   E0AA  3D           DEC   A
  110. -.   E0AB  FE 2A        CP    2A
  111. +.   E0AB  FE 80        CP    80
  112.  .   E0AD  30 0D        JR    NC, E0BC
  113.  .   E0AF  56           LD    D, (HL)
  114.  
Title: Re: EXDOS
Post by: Zozosoft on 2008.December.16. 19:23:40
A szektor olvasást és írást végzõ ciklusok, bár sok más helyen lehetne például várakozásokat rövidíteni vagy törölni.
Mindenesetre jó, hogy ilyenekbe beleásod magad! Ami érdekes kérdés: vajon fel lehetne-e úgy gyorsítani az EXDOS rutinok mûködését, hogy alap 4 Mhz-es gép tudja a 16 Mhz-es WD-t követni, azaz HD-s lemezt olvasni?
Title: Re: EXDOS
Post by: Attus on 2008.December.16. 22:01:26
Szerény véleményem szerint, elõbb-utóbb hatalmas kavarodás lesz abból, ha nem az emulátort írjuk az Ep-hez, hanem az Ep programjait az emulátorhoz... :oops:
Egyetértek.  ;-)
Title: Re: EXDOS
Post by: Zozosoft on 2009.January.07. 23:32:24
Mindenesetre az összeset párhuzamosan kell disassemblálni, és akkor okosabbak leszünk :-)
Na úgy látom senki más nem vetette rá magát a témára  :oops: így akkor neki estem én, pár dolog már kiderült.
A 0.3-as tényleg a legkorábbi, valószínüleg azért ismeri ez a legtöbb parancsot, mert késõbb ahogy nõt a kód mérete, egyes kevésbé lényeges parancsokat kihagytak (kár, hogy az ATTR is ide jutott...), úgy tünik nagyon ragaszkodtak a 16K-s ROM mérethez, pedig a gyári EXDOS kártyán is ott a jumper 32K-s ROM beállításhoz. A kimaradt utasítások az ISDOS-ba költöztek.
Itt még sok dolog nagyon eltérõ, az EPDOS el is száll ezzel a verzióval (az alaposan belekotorászik az EXDOS RAM területébe)
A hibaüzenetek már tömörítve vannak, de a több más szót (file, disk, stb) tartalmazó szintén tömörített tábla még külön van. Sok szöveg tömörítettlen.
A "file cannot be copied onto itself" hiba még nem létezik, simán el is végzi a mûveletet.

Az 1.0-ás a gyári EXDOS kártyák verziója, a kód már erõsen hasonlít az újabb verziókra, de vannak még eltérések, pl memóriakezelésben, Haluska Laci írta is a FISH cikkben, hogy 1.0 esetén nem lehet a verem a 0. lapon FISH hívás esetén.
Ami még szembetünõ, hogy "darabra" meg van minden ami az újabban van, de sok helyen más sorrendben vannak összepakolva a szubrutinok.
A hibaüzenetek és szinte minden egyéb szöveg már egy egységes tömörített táblában vannak. Érdekes, hogy valószínüleg a tömörítés jobb hatásfoka érdekében a szöveg eleji nagybetûket kicsire cserélték, utólag nagybetûsíti a rendszer.
Itt már kialakult a végleges parancs és hibaüzenet készlet.

Az 1.2 korábban számunkra ismeretlen volt. Ez már tekinthetõ a (jelenleg ismert) végleges változatnak, ezen alapul az általunk legjobban ismert 1.3-as változat, amelyet a németek követtek el: a szöveg kezelés lett átalakítva kétnyelvûre, emiatt hizott 32K-sra a ROM. Mivel itt aztán bõven volt hely, a szövegek már nem tömörítve vannak tárolva. Kétnyelvûség miatt a Retry/Abort/ignore rutinban is átalakítva a billentyûzet kezelés.
Ez az angol-német változat a gyári EP floppyba építve került forgalomba.
Egyelõre ismeretlen magyar illetõ meglátva a sok üres helyet a ROM-ban, nekiállt kibõvíteni: bekerült az IS-DOS a ROM-ba, ill. a korábban kimaradt parancsokból 4: ATTR, ATDIR, ASSIGN, MAPDISK, valamint a német üzenetek HUN-osra lettek cserélve.
Ez eredeti 1.3-as ROM-ban ezért a parancstáblázat átkerült a ROM végére kibõvítve, és az üresen maradt helyre került a plusz utasítások rutinja, amelyik a másik szegmenst hívják meg, ténylegesen ott található a végrehajtó kód.
Ebben a verzióban még nincs benne a HELP listában az IS-DOS, és mint kiderült hibás is: nem mûködött a gyors videókezelõ.
Ezt a verziót szerkesztettem én újra: egyrészt a hibasüzenetek közé bekerült pár, amire eredetileg nem tartalmazott üzenetet a ROM, az IS-DOS pedig újra berakva a lemezes IS-DOS.SYS-bõl kiindulva, és a HELP listába is bekerült az ISDOS. Továbbá az EXDOS inicializációs rutinjába bekerült a 73-as EXOS változó, azaz a fejléptetés sebességének állítása, mivel WD1772-es esetén ezt 3-asra érdemes állítani, a gyorsabb, csendesebb mûködés érdekében, a ROM fájl 3F99 címén lehet az alapértelmezést beállítani.

És végül van még a nagyon érdekesnek hangzó 2.0-ás változat. Ez sajnos semmilyen forradalmi újdonságot nem tartalmaz, mindössze 8 bájttal több mint az 1.2-es. Ha jól néztem a WD port kezelésnél lettek egyes várakozások jelentõsen megnövelve.
Most kipróbáltam valódi gépen, és azt tapasztaltam, hogy ennek következtében véletlenszerûen, de rendszeresen kiakad Data error hibával! Disk Editorban nézve 1 bájttal elcsúszik ilyenkor a beolvasott adat. Viszont ha a gépet 6 Mhz-re kapcsolom, akkor hibátlanul mûködik! Lehetséges, hogy az új "szuper EP" számára készült ez a változat?
És ott van az a 4.0, amirõl csak annyit tudunk, hogy Kopácsyék azzal formázták az ISDOS lemezeket...
Title: Re: EXDOS
Post by: Ep128 on 2009.January.07. 23:58:02
És ott van az a 4.0, amirõl csak annyit tudunk, hogy Kopácsyék azzal formázták az ISDOS lemezeket...
... és azt örökké bánni fogom, hogy nem tudtam kihúzni belõle errõl részleteket!
Lehet, hogy 1x mégis újra meg kellene támadni, de az már (sajnos) nem én leszek...
Title: Re: EXDOS
Post by: Zozosoft on 2009.January.10. 22:20:00
Ugye emlékeztek még a ROMDISK programocskára? Amivel elõször sikerül új, saját meghajtót csatlakoztatnia rendszerhez.
Most a további visszafejtéssel sikerült egy új módszert találni, így nem csak hidegindításkor, hanem akármikor tudunk meghajtót beláncolni! Az eddig ismeretlen 24-es FISH hívással.
Ugye tudjátok ez mit jelent? :-)
Már csak az ellentétére kéne rájönni.
Itt egy ilyen ROMDISK, benne a Smalldemo-val :-) (igaz ep128emu-val csak az elsõ részig megy, mert nem kezel 64K-nál nagyobb ROM-ot :-( EP32-vel megy az egész.)
[attachthumb=1]
[attachthumb=2]
Title: Re: EXDOS
Post by: Ep128 on 2009.January.10. 23:33:21
Remek!  :) "Pen Drive" Ep -hez? :-D
Lassan tényleg hihetetlen, amit az elmúlt években összehoztok!  :smt023
Title: Re: EXDOS
Post by: Zozosoft on 2009.January.10. 23:59:13
Remek!  :) "Pen Drive" Ep -hez? :-D
De elszaladt a fantáziád!
Egyelöre majd örüljünk annak,hogyha nem kell majd FDISK után újraindítani a gépet!
Ha a kiszedés is menne,akkor megoldodna a RAM gond,lehetséges lenne a felesleges meghajtókat ideiglenesen eltávolítani, egy-egy RAM éhesebb program futattásához!
Title: Re: EXDOS
Post by: IstvanV on 2009.January.11. 01:55:42
Itt egy ilyen ROMDISK, benne a Smalldemo-val :-) (igaz ep128emu-val csak az elsõ részig megy, mert nem kezel 64K-nál nagyobb ROM-ot :-(
Bár nem ideális megoldás, de snapshot file használatával ezt a problémát meg lehet kerülni:
[attachurl=#]
A snapshot az alábbi programmal készült - ezzel elvileg bármilyen memória konfiguráció létrehozható, de ez a verzió valószínűleg még nem igazán megbízhatóan működik: :)
[attachurl=#]
Title: Re: EXDOS
Post by: IstvanV on 2009.January.11. 13:31:38
Már találtam is hibát :) :oops: A fenti file-okat javított változatra cseréltem.
A snapshot készítéséhez ezt a konfigurációt használtam:
Code: INI
  1. ; ROM segments
  2. 0x00    rom     "exos231uk.rom"
  3. 0x20    rom     "exdos13.rom"
  4. 0x30    rom     "epfileio.rom"
  5. 0x40    rom     "iview.rom"
  6. 0x50    rom     "zt18uk.rom"
  7. 0x60    rom     "exdext.rom"
  8. ; RAM segments
  9. 0xD8    ram     ""      36
Természetesen az epmemcfg segédprogrammal más speciális konfigurációk (pl. "lyukas" RAM) is létrehozhatók.
Title: Re: EXDOS
Post by: szipucsu on 2009.January.11. 13:50:42
Az epmemcfg-t hogyan kell használni? Nálam indulás után azonnal kilépett (XP alatt).
Title: Re: EXDOS
Post by: IstvanV on 2009.January.11. 13:59:08
Az epmemcfg-t hogyan kell használni? Nálam indulás után azonnal kilépett (XP alatt).
Az epmemcfg parancssoros program, és a konfigurációs file és a snapshot file nevét megadva kell futtatni:
.\epmemcfg.exe exdext.cfg exdext.ep128s
Ez feltételezi, hogy az előbbi konfigurációt egyszerű szöveges file-ként (pl. a Notepad segítségével) "exdext.cfg" néven mentetted, és minden file megtalálható az aktuális könyvtárban. Ha a ROM-ok nincsenek az aktuális könyvtárban, akkor a konfigurációt módosítani kell, például "exos231uk.rom" helyett "C:\Program Files\ep128emu2\roms\exos231uk.rom"-ot írva.
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.07. 16:04:31
Van itt egy csúnya, az EP szellemiségéhez méltatlan baki az EXDOS-ban:
[attachimg=1]
Milyen dolog ez, hogy ott a sok RAM, és még se tudja használni?! RAMDISK 127-nél nagyobbat nem tud kezelni az EXDOS :(
Valamelyik Intelligent Software-s fiú siethetett haza a munkanap végén, és úgy gondolta, hogy áááá úgyse lesz soha több mint 2 mega RAM egy EP konfigban, minek foglalkozni a kérdéssel...

A kérdés amivel foglalkozni kellett volna, az az, hogy a RAMDISK-ben alkalmazott 1 szektoros cluster méret max 2 megás lemez méretig használható. Az állandó 2 szektoros cluster meg a kis méretû RAMDISK-nél lenne célszerût, ott minden egyes elveszett szektorért kár.
Vagyis le kell ellenõrizni a létrehozandó méretet és ennek függvényében változtatni a cluster méretet, valamint módosul a FAT méretének kiszámítása is. Ez nyilvánvalóan pár bájttal hosszabb kódot eredményez, és inkább ezt a pár bájt megtakarítást választották, hiszen úgyse lesz soha egy gépben olyan sok RAM :-)
Viszont mamár valódi gépen se túl nehéz összehozni ennyit, emulátorban meg pláne könnyû :-)

Így aztán nekiálltam, a szükséges plusz kód 10 bájt. Az elején ha likvidáljuk azt az ellenõrzést, ami azt nézi, hogy 127-nél nagyobb-e? Akkor nyerünk 5 bájtot. Már csak másik 5-t kell találni :-)
Faragtam vagy 2 napig a biteket, végül befért  :ds_icon_cheesygrin:
Remélhetõleg nem rontottam el semmit  :oops:
Itt az eredeti és a módosított rutin forrása, ill. egy módosított ROM. Ha nincs hiba akkor belerakom a többibe is.
[attachimg=2]
Title: Re: EXDOS
Post by: Ep128 on 2009.May.07. 23:34:10
Mikre jössz Te rá... Már a probléma fellelése is gratulációt érdemel, hát még a javítása. :)
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.07. 23:46:06
Mikre jössz Te rá... Már a probléma fellelése is gratulációt érdemel, hát még a javítása. :)
A probléma már vagy 15-16 éve feltûnt, amikor volt ez a 512K-val tunningolt gépünk (http://ep.homeserver.hu/Galery/Bovitmenyek/Picture/512ext1.jpg), amiben belül is van +64K, a Cartridge-ban 32K SRAM, Microteam kártyán 512K, plusz az emeletes 64K SRAM (http://ep.homeserver.hu/Galery/Bovitmenyek/Picture/IM000721.jpg) :-)
Ehhez jött kölcsön Matusa Pisti vadonatúj Mészáros féle 1 megás kártyája, így ekkor láttam életemben elõször túlmenni a számlálót a bûvös 2048K-n :-) egészen 2336K-ig.
És roppantul meg voltam sértõdve, amikor pofámba nyomta ezt az Insufficient memory hibaüzenetet  :evil:
Akkor odáig jutottam el, hogy Asmonban meg "diskeditor"-oztam a megnyitott kisebb RAMDISK boot szektorát, majd nyomtam egy resetet EXOS 2.3-al, és akkor annak a RAMDISK megõrzõ funkciója rendben elrakta a helyére, és utána mûködött.
Title: Re: EXDOS
Post by: Ep128 on 2009.May.07. 23:53:18
Ahhhaaaaa! Nem tudtam, hogy ilyen régre nyúlik vissza ez a kérdés. Akkor meg végképp tök jó, hogy megoldottad. :-)
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.08. 00:13:54
Kicsit játszottam az epmemcfg-vel, ez a max ami kijön :-)
[attachthumb=1]
[attachthumb=2]
Title: Re: EXDOS
Post by: Ep128 on 2009.May.08. 00:19:01
Ilyet mikor látok majd az itthoni normál gépemen?  :lol:
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.08. 00:20:41
Ilyet mikor látok majd az itthoni normál gépemen?  :lol:
Leginkább soha, mert túl sok értelme nincs olyan gépnek, ahol az EXOS 2.31-en kivül csak egy EXDOS 1.2 ROM fér el, mert a többi helyet elfoglalja a sok ram :-)
Title: Re: EXDOS
Post by: geco on 2009.May.08. 08:36:40
Gratula.:) Kár, hogy nem voltál az EXDOSos srácok között. ;)
Biztos meglepődnének az EXOS, és EXDOS fejlesztői, hogy mit lehetett még kihozni, meg javítani kódjukban.
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.08. 10:06:23
Biztos meglepõdnének az EXOS, és EXDOS fejlesztõi, hogy mit lehetett még kihozni, meg javítani kódjukban.
Igazából én is meglepõdtem, hogy végül befért az eredeti helyre, nem hittem volna, hogy ki lehet szedni 5 bájtot, nem így ismertem eddig az IS programokat :-) Ráadásul vagy 3x eljutottam odáig, hogy kész, aztán kiderült valami bibi, ami miatt át kellett variálni, amihez megint plusz bájtokat kell keresni...
Az 1.3-asban mondjuk meg lehetett volna csinálni úgyis, hogy egy üres részre rakni a plusz kiegészítést, és azt hívni az eredeti rutinból, de az így nem szép :-)
Title: Re: EXDOS
Post by: Zozosoft on 2009.May.08. 15:10:01
Mivel eddig senki nem jelzett hibát, megcsináltam a többi ROM verzióban is (kivéve a 0.3-as, mert ott eltérõ a rutin).
Title: Re: EXDOS
Post by: Ep128 on 2009.May.08. 15:16:42
Leginkább soha, mert túl sok értelme nincs olyan gépnek, ahol az EXOS 2.31-en kivül csak egy EXDOS 1.2 ROM fér el, mert a többi helyet elfoglalja a sok ram :-)
Azért még férne valamennyi a jelenlegi mellé...  ;-) (Na nem mint ha nagyon hiányozna, csak a poén kedvéért, hogy Neked hála "ilyet is tudunk". :) ) Ez a hellyel történõ gazdálkodás nem semmi, hogy 5 bájtokat hajtunk fel a cél érdekében. :)
Title: Re: EXDOS
Post by: geco on 2009.May.08. 20:40:58
Igazából én is meglepõdtem, hogy végül befért az eredeti helyre, nem hittem volna, hogy ki lehet szedni 5 bájtot, nem így ismertem eddig az IS programokat :-) Ráadásul vagy 3x eljutottam odáig, hogy kész, aztán kiderült valami bibi, ami miatt át kellett variálni, amihez megint plusz bájtokat kell keresni...
Az 1.3-asban mondjuk meg lehetett volna csinálni úgyis, hogy egy üres részre rakni a plusz kiegészítést, és azt hívni az eredeti rutinból, de az így nem szép :-)

Gratula a türelemhez is, meg a megvalósításhoz is :) Én fel szoktam adni egy idő után a bepaszírpzást, és inkább beteszek egy call-t  :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2009.November.01. 09:51:09

Pontosan! Arról a cuccról (http://www.binarydinosaurs.co.uk/Museum/Enterprise/harddisk/index.php) van szó amit Kopácsy emlegett az 1991-es interjúban (http://ep.homeserver.hu/Dokumentacio/Cikkek/VTGe.htm), azaz amivel XT kártyákat lehet EP-hez kötni.
Amit sokáig csak legendának gondoltunk :-)

Ez a program csinál egy F: meg egy G: meghajtót, persze a hw nélkül sokra nem megyünk :-)
Ez a két meghajtó meg is felel annak, hogy 87-ben két vinyót köthettél egy MFM kártyára, amik lehettek kb 10-20 megásak. Így itt még nem merül fel a több mint 32M, sok partició kellene problémakör, elég 1-1 betü a két vinyónak.

Remélem a visszafejtés során azért sikerül új információkat kideríteni az EXDOS bõvítés mikéntjérõl.
Na elkezdtem felboncolni ezt a cuccot is, hátha tanulunk belõle valamit :-)
Ami érdekesség kiderült, hogy a ROM fájlban tulajdonképpen két verzió is benne van, ha az elején a NOP-ok helyére teszünk egy JP-t, úgy lehet elõcsalni az 1.1A-t.
Csináltam két szétszedett ROM-ot, ill. itt van két nyers assembly fájl is.

Ami még kiderült, úgy tünik, hogy az XT MFM vezérlõ kártya ami ott a 320-323H címeken van, úgy lett EP-re kötve, hogy 20-23H portokon legyen.

Én vagyok béna, vagy a google, vagy tényleg nincs fent a neten sehol, hogy kell XT-n programozni a vinyót??? Legalábbis több órás kereséssel se találtam semmit :(
Egyedül az Abonyi Zsolt: PC hardver kéziköny címû könyvben találtam némi nem túl részletes infót róla, de neten max a port kiosztást.
Title: Re: EXDOS
Post by: Zozosoft on 2009.November.02. 16:03:13
Én vagyok béna, vagy a google, vagy tényleg nincs fent a neten sehol, hogy kell XT-n programozni a vinyót??? Legalábbis több órás kereséssel se találtam semmit :(
További több órás szenvedéssel még mindig semmi :-( pedig még Linux drivert is írtak rá!
Title: Re: EXDOS
Post by: Zozosoft on 2009.November.02. 19:19:39
Na csak meg lett  :ds_icon_cheesygrin: itthon elolvastam az Abonyi könyv irodalom jegyzékét, és IBM PC technical reference néven keresve sikerült rábukkani!
Ami nagyon érdekes, hogy az XT vinyóvezérlõ programozása, szinte szóról szóra megegyezik a SASI programozásával! A SASI kapta késõbb a SCSI nevet, amirõl talán már mindenki hallott. Talán nem véletlen, ha arra gondolunk, hogy ugyanaz a Shugart Associates mûködött közre az MFM vinyók megalkotásánál is, akik a SASI-t is kitalálták. (És nekik köszönhettük a floppy szabványt is, benne is van az EXDOS leírásban, hogy Shugart 410 kompatibilis floppymeghajtót kell a boltban keresni :) )

Egyedüli különbség, hogy a SASI/SCSI esetén logikai szektor címet viszünk át, míg XT esetén a hagyományos C/H/S címzés szerepel a parancsokban.

Itt van két PDF, az IBM-esben (http://www.retroarchive.org/dos/docs/ibm_techref_v202_1.pdf) a 197. PDF lapon kezdõdik a leírás, a WD-sben (http://javascript:openreq('http://www.datasheetcatalog.org/datasheets/restul/499118_DS.pdf')) a 17. oldalon.

Elvileg ez alapján már meg kell tudnunk fejteni, mit csináltak a németek 1987-ben EP vinyó ügyben!
Aztán ha nagyon unatkozik István, beleteheti a következõ ep128emu-ba  :ds_icon_cheesygrin:
Title: Re: EXDOS
Post by: Zozosoft on 2009.November.04. 00:13:31
Ami már kiderült, hogy a kártyán DIP kapcsolókkal lehetett kiválasztani a két vinyó típusát, az 1.2-es ROM 3 típust ismer, a paraméterek alapján Seagate ST213 (http://www.4drives.biz/images/DRIVEPICTURES/SEAGATE_ST213.jpg), ST225 (http://retropages.uw.hu/Gepek/Alkatreszek/HD-FD/ST-225.jpg), ST238R (http://retropages.uw.hu/Gepek/Alkatreszek/HD-FD/ST-238R.jpg) típusokra lehet tipelni (10.7, 21.3, 31.7 megabájtosak, és ténylegesen, akkor még nem hazudtak nagyobb méretet a vinyókra :) )

Az 1.1A verzió még nem figyel DIP kapcsolókat, ott csak egyféle 30 megás típus van.
Title: Re: EXDOS
Post by: Zozosoft on 2009.November.04. 21:49:25
És amit a kezelõprogramról sikerült kideríteni:
A=akciókód, C=alegység sorszám, IX=transzfercím, IY=kezelöprogram adatterülete.
P0=nullás lap, P1=transzfer terület szegmense, P2=kezelöprogram adatterület szegmense, P3=kezelöprogram szegmense.
3-as akciókód: lemeztipus megadása, transzfer területre be kell olvasni a BOOT szektort, visszaadandó B=formázási tipusbájt,HL=utolsó logikai szektor sorszáma (azaz szektorok száma-1)
4-es akciókód: logikai szektorok olvasás
5-ös akciókód: logikai szektorok írása
6-os akciókód: logikai szektorok irása ellenõrzéssel
Mind három esetben B=átviendõ szektorok száma, DE=kezdõ szektor sorszáma.

A FISH nem foglalkozik formázással, miután a FORMAT megkérdezte, hogy biztos vagy-e benne, és azt válaszoltad, hogy igen, akkor 8-as akciókóddal meghívja a meghajtó kezelõprogramját, hogy "formázd meg a hozzád tartozó lemezt, hogy hogyan az a te dolgod, engem csak az érdekel, hogy sikerült-e" :-) A boot szektort el kell készíteni, a FAT táblákat és a fõkönyvtárat már az EXDOS készíti el az adatok alapján (amit 3-as kóddal kér be).

Az 1,2,7-es kódokról még nem tudni mi az, de az EXDOS használja... a vinyóvezérlõ programja ilyenkor RET-tel válaszol...

A LUA Scriptes trükk, és a HDOS boncolása alapjá:
0-ás akciókód, hidegindítási inicializálás, az EXDOS az egység beláncolása után hívja
1-es akciókód, melegindítási inicializálás
2-es akciókódra még csak tippelek, hogy esetleg a lemezcsere ellenõrzés lesz... a RAMDISK és a HDOS:
LD B,1
XOR A
RET
utasításokkal intézik el a dolgot.
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.10. 23:32:55
A LUA Scriptes trükk, és a HDOS boncolása alapjá:
0-ás akciókód, hidegindítási inicializálás, az EXDOS az egység beláncolása után hívja
1-es akciókód, melegindítási inicializálás
2-es akciókódra még csak tippelek, hogy esetleg a lemezcsere ellenõrzés lesz... a RAMDISK és a HDOS:
LD B,1
XOR A
RET
utasításokkal intézik el a dolgot.

Fordítottam ez alapján egy IDE.ROM-ot, úgy tûnik pár kamu data error hibajelzés eltûnt így Epdos alatt.
Title: Re: EXDOS
Post by: Lacika on 2009.December.11. 11:32:16
Én is kicseréltem.
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.25. 12:58:07
Arra jutottam, hogy a legjobb az lesz, ha nem három különféle program kergeti az EXDOS.INI-t, így csináltam az 1.3-es EXDOS-ból olyat ami maga keresi az E:, F:, B:, A: meghajtókon.

Itt a módosított rutin kódja:
Code: ZiLOG Z80 Assembler
  1.                 ORG 0FFB2H
  2.                 OBJECT EXDINI.BIN
  3.                 PUSH IY
  4.                 POP HL
  5.                 LD DE,05DBH
  6.                 ADD HL,DE
  7.                 LD A,5
  8.                 CALL INI
  9.                 LD A,6
  10.                 CALL INI
  11.                 LD A,2
  12.                 CALL INI
  13.                 LD A,1
  14. INI:            LD (IY-57H),A
  15.                 LD DE,0C131H
  16.                 EX DE,HL
  17.                 PUSH DE
  18.                 LD BC,9
  19.                 LDIR
  20.                 ADD A,40H
  21.                 DEC DE
  22.                 DEC DE
  23.                 LD (DE),A
  24.                 POP DE
  25.                 PUSH DE
  26.                 EXOS 26
  27.                 POP HL
  28.                 RET
C128-nál kell a CALL FFB2H-t beszúrni az eredeti rutin helyére.
Title: Re: EXDOS
Post by: Lacika on 2009.December.26. 12:32:05
Arra jutottam, hogy a legjobb az lesz, ha nem három különféle program kergeti az EXDOS.INI-t, így csináltam az 1.3-es EXDOS-ból olyat ami maga keresi az E:, F:, B:, A: meghajtókon.

Szerény véleményem szerint elég, ha csak az E:, A: meghajtókon keresünk ini-t, lassítja a bejelentkezést, ha végignézünk mindent. PC-n sem lehet akárhány partícióról boot-olni...
Title: Re: EXDOS
Post by: szipucsu on 2009.December.26. 21:08:57
Szerény véleményem szerint elég, ha csak az E:, A: meghajtókon keresünk ini-t, lassítja a bejelentkezést, ha végignézünk mindent. PC-n sem lehet akárhány partícióról boot-olni...
Lassan BIOS is kell EP-re, amiben be lehet állítani a BOOT sorrendet (is). :D
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.26. 21:37:41
Ha volt ZT a rendszerben, akkor eddig is volt E, B, A... egyedül az F az újdonság, de az pillanatok alatt lemegy. Ha gyorsan akarsz valahova jutni, akkor nyomj gombot a ZT-nek, az ezután is müködik .-)
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.28. 19:35:50
Korábban már megfejtettük az ismeretlen 24-es FISH hívást, de maradt még ott "fenntartva" a listában...
(http://enterpriseforever.com/dlattach.html;topic=283.0;attach=2373;image)

Most a 27-est sikerült felderíteni, ez a diskpufferek számának növelésére szolgál, B regiszterben adjuk meg a pufferek új számát (max 10 lehet), 0 esetén lekérdezés.
Ezt használja a BUFFERS parancs, ami eredetileg benne volt az EXDOS-ban (lásd 0.3), de késõbb kiszorult belõle és csak az ISDOS-ban található meg.

Megjegyzés: ha kevesebbet adunk meg, mint amennyi jelenleg van, akkor se történik semmi, csak visszakapjuk az aktuális értéket, vagyis FISH-en keresztül csökkenteni nem lehet. Ez úgy oldható meg, hogy a FISH adat területen átírjuk a pufferek számát (IY+21H), majd kiadunk egy EXOS resetet 20H-val, így újraszerkesztõdik a periférialánc, ezáltal a pufferek számára memóriát foglaló . nevû periféria is újra lesz beláncolva, az általunk megadott puffermérettel.
Amikor a FISH 27 mûködik, az pluszban vesz fel még egy . nevû perifériát, a szükséges plusz pufferek foglalásához. Ez jól látható, ha az EPDOS DEVS parancsával kilistázzuk a periférialáncot a BUFFERS parancs használata után. Ha azonban kilépünk pl BASIC-be az ISDOS-ból, már ismételten csak egy . lesz, mivel ilyenkor végrehajtódik egy EXOS reset, így újra lácolódnak a perifériák.
Cseles megoldás :-) de nem ez az egyetlen trükk az EXDOS memóriakezelésben.
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.28. 20:13:12
Cseles megoldás :-) de nem ez az egyetlen trükk az EXDOS memóriakezelésben.
Pl rögtön itt van a szintén ismeretlen FISH 23 hívás:
Ezzel kisebb memóriaterületet lehet átmenetileg lefoglalni, BC-ben a kért méret, visszatéréskor B a szegmensszám, DE pedig a terület fölé mutat.
A trükk itt az, hogy a FISH egy jelzõbiten keresztül üzen a DISK perifériának, hogy ne normál fájlkezelõ módban mûködjön, hanem csak foglalja le a megadott méretet csatornapufferként. Így nyit meg egy csatornát (szabad csatornaszámot keres hozzá), a kapott csatornapuffer címét adja vissza a felhasználónak. A területet addig használhatjuk, amíg nem történik a csatornák bezárásával járó mûvelet.
Title: Re: EXDOS
Post by: Zozosoft on 2009.December.28. 21:58:01
Most a további visszafejtéssel sikerült egy új módszert találni, így nem csak hidegindításkor, hanem akármikor tudunk meghajtót beláncolni! Az eddig ismeretlen 24-es FISH hívással.
Itt kimaradt a pontos leírás, tehát
B=szegmensszám, DE=cím mutat a leendõ meghajtó leíróblokk helyére, ahol a következõ adatokat kell elhelyezni:
0: belsõ egység darabszám
1-2: kezelõprogram címe
3: kezelõprogram szegmensszáma
A megadott területnek RAM-ban kell lennie, méret 3 bájt (a következõ leíróblokkra mutató cím számára) + annyiszor 60H bájt ahány belsõ egységet megadtunk.
A leíróblokkban a kezelõprogram RAM területének a híváskor megadott szegmens:cím lesz bejegyezve.
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.19. 21:28:36
Mint azt már tudjuk egy ideje, eredetileg Plug and Play rendszert terveztek a bõvítõkártyákhoz, amibõl csak a gyári EXDOS és hozzá adott BRIDGE készült el ilyen módon. (Mivel nem volt errõl szóló dokumentáció, így sajnos a magyar fejlesztések nem követték ezt a rendszert.)
Ime, hogy hogyan számolja ki az EXDOS a WD portcímét:
Code: ZiLOG Z80 Assembler
  1.         LD      C,0B3H
  2.         IN      C,(C)           ;C=ROM szegmensszáma
  3.         SRL     C               ;C=C/2
  4.         BIT     1,C            
  5.         JR      Z,LDCBD
  6.         LD      C,10H
Ebbõl kiderül, hogy a lehetséges ROM címekhez, az IO tartomány fel osztható ki, 80H-tól az alaplap jelenlegi, ill. esetleges késõbbi eszközei helyezkednek el. A BRIDGE-n 3 darab Socket Address címvezeték helyezkedik, el, ez 8 kártyát tesz lehetõvé. A kártyákon az eredeti EXOS ROM tesztet figyelembe véve a következõ aktív ROM szegmensek és IO címek lehetnek:
0: 10H, 00-0FH
1: 20H,30H, 10-1FH
2: 40H,50H, 20-2FH
3: 60H,70H, 30-3FH
4: 80H,90H, 40-4FH
5: A0H,B0H, 50-5FH
6: C0H,D0H, 60-6FH
7: E0H,F0H, 70-7FH

A fenti SRL-es számítási módot tekintve lehetséges az is, hogy 1 kártya két lehetséges ROM-ja, elossza 8-8 arányban a lehetséges 16 portot. Az EXDOS ezt mindenesetre nem teszi, 10-13H a WD, 18H a kártya vezérlõregisztere.

Még egy érdekesség a fenti rutinról: valószínûleg a fejlesztési fázisból benne maradt egy kivételkezelés, ami gyári konfigurációban akkor lép mûködésbe, ha a cartridge-ban van az EXDOS ROM, ekkor kiszámolt bázis port címet a jól ismert 10H-val helyettesíti, ami a gyári BRIDGE-hez kötött EXDOS kártyának felel meg.

Anno a Turbo EXDOS fejlesztésekor tapasztaltam, hogy a ROMLOAD-dal betöltött EXDOS ROM nem mûködött a PNP portcím számítás miatt, hiszen nem a 20H-ra lett töltve. Viszont ennek a kivételkezelésnek az lett a mellékhatása, hogy x4 vagy xC végû szegmensre töltve mûködik a betöltött EXDOS ROM. (Magyarán egy RAMDISK 3 után mehetett a ROMLOAD)

A portcímszámolgatás még egy másik esetben került elõ: egyes magyar gyártású BRIDGE-ekben nem volt megfelelõen bekötve SA0-SA2, így más címre dekódolódott az EXDOS, ezért pár program ami fix WD címeket használt, nem mûködött. (Ezt anno be is küldtem az Enterpressbe.)

Title: Re: EXDOS
Post by: Zozosoft on 2010.June.20. 01:40:15
Az EXDOS kártya programozásáról nem sok információt találtam, de az emulátorban a "disk change" a 18h port 6. bitje. Amikor lemezcsere történik, akkor ez a bit 0 lesz (egyébként 1), addig, amíg ugyenerre a portra írás történik beállított 6. bittel, ami törli a "disk change" jelet.
Valóban így várja az EXDOS:
Code: ZiLOG Z80 Assembler
  1.         IN      A,(C)           ;EXDOS STATUS olvasása
  2.         AND     40H             ;DISK CHANGE bit marad
  3.         JR      NZ,LDDC8        ;ugrás ha nem volt lemezcsere
  4.         LD      A,E
  5.         OR      40H             ;DISK CHANGE RESET
  6.         OUT     (C),A           ;1-be állítva
  7.         OUT     (C),E           ;0-ba állítva
  8.         IN      A,(C)           ;EXDOS STATUS olvasása
  9.         AND     40H             ;DISK CHANGE bit marad
  10.         JR      NZ,LDDB3        ;ugrás, ha törlödött a csere
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.24. 22:45:26
Az viszont egy apróbb bökkenõ, hogy nem sikerült egyetlen egy olyan meghajtót se találnom, ami ezt a fajta Disk Change jel kezelést tudná. Talán ha valakinek van valami egész õsi SS/SD meghajtója, hátha az tudja még a Shugart szabványt... vagy venni eBay-en eredeti Shugart floppyt 100 dolcsiért  :ds_icon_cheesygrin:

Szóval, ha majd eljutunk az új EXDOS verzió fordításáig, akkor érdemes lesz átírni ezt a rész a PC-s módszerre, bár az egy picit bonyolultabb lesz, mert ott fejléptetéssel megy a törlés.
Az EP-vel egy idõs, fekete elejû (ma ismét divatos színû :-) ) TEAC 5.25" meghajtók is ezt a módszert tudják.
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.26. 23:31:17
Laci! A DISKIO leírást (http://www.ep128.hu/Ep_Konyv/Exdos_Muszaki_Leiras.htm#10) lehet kiegészíteni:
A hibabiteknél a fentartottnak írt 5-ös bit jelentése DISK CHANGED, 1-7 parancsoknál.

Az általános tudnivalókhoz: az 1-7 parancsok végrehajtása elõtt megvizsgálja a hw lemezcserejel állapotát, és ha aktív, akkor ennek megfelelõ hibakóddal megszakítja a parancs végrehajtását. A lemezcsere jelzést törli, így az ugyanerre a meghajtóra kiadott következõ parancs már végrehajtódik.

Disk reset-nél: visszatéréskor a C az EXDOS kártya IO port tartományába mutat.
Title: Re: EXDOS
Post by: Lacika on 2010.June.27. 09:15:11
Kiegészítettem!
Így jó lesz?
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.27. 09:22:33
Kiegészítettem!
Így jó lesz?
Jó!
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.28. 22:31:34
Újabb kiegészítés: az eddig ismeretlen 7-es DISKIO funkció: hw lemezcserejel lekérdezése
Csere esetén a megfelelõ hibakód beállítva. Ez a parancs is törli az esetleges jelzést, így ismételt lekérdezés már nem jelez  cserét, csak akkor ha fizikailag tényleg újabb lemezcsere történt.
Title: Re: EXDOS
Post by: Lacika on 2010.June.28. 22:57:04
Megtörtént.
Title: Re: EXDOS
Post by: Zozosoft on 2010.June.28. 23:03:08
Úgy tûnik az EXDOS képes azzal a ténnyel is együtt élni, hogyha a DISK CHANGE RESET jellel nem sikerül törölni a DISK CHANGE jelet. Minden meghajtóhoz külön tárolja az állapotot, és a nem törlõdött jel már nem okoz újabb lemezcsere jelzést. Viszont ha a meghajtó majd egyszer törli a jelzést, majd újra aktívvá válik, akkor az természetesen újabb lemezcsere jelzést vált ki.
Ebben nekünk az a jó, hogy ahhoz, hogy áttérjünk a PC kompatibilis lemezcsere jelzésre (34-es lábon jelez, és akkor törlõdik, ha fejléptetés parancsot kap a meghajtó miközben van benne lemez), csak azt kell módosítani, hogy a 18h port melyik bitjét figyelje. Kb két AND 40h-t kell AND 01h-ra átírni :-)
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.04. 00:19:35
Egy rejtélyes kis érdekesség: egy normál FAT típusú lemezen az érdemi logikai adatok 0Bh bájttól vannak tárolva a boot szektorban.
Vajon milyen az a FAT fájlrendszert használó operációs rendszer, ahol ezek az adatok 50h-tól vannak tárolva, és elterjedt volt a 80-as években Angliában?

Csak azért kérdezem, mert az EXDOS képes lenne ilyen lemezt is kezelni! Külön kivétel kezelést raktak bele, hogyha a normál helyen lévõ paraméterek érvénytelenek, akkor nézze meg ezen az eltolt helyen is, és ha így értelmesnek találja a lemezt, akkor a memóriában lévõ boot szektorban átmásolja az adatokat a rendes helyükre, majd megy minden tovább a szokásos módon.

Gondolom valami fontos oka lehetett, hogy ilyen képességet is raktak bele, mert amúgy nem nagyon szokták a bájtokat pazarolni :-)
Title: Re: EXDOS
Post by: geco on 2010.July.04. 00:22:18
Nem lehet, hogy valamilyen az ángluisoknál elterjedt, és népszerű gép használhatott ilyet?
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.04. 00:44:37
Nem lehet, hogy valamilyen az ángluisoknál elterjedt, és népszerû gép használhatott ilyet?
De lehet :-) már csak azt kéne kitalálni melyik?
Title: Re: EXDOS
Post by: geco on 2010.July.04. 00:59:49
De lehet :-) már csak azt kéne kitalálni melyik?
Tűt a szénakazalban :D
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.05. 22:55:41
Tût a szénakazalban :D
Meg van, Apricot!
Csak a Wikipedia-t kellett kiolvasni :) (http://en.wikipedia.org/wiki/File_Allocation_Table)
Quote
The implementation of FAT used in MS-DOS for the Apricot PC had a different boot sector layout, to accommodate that computer's non-IBM compatible BIOS. The jump instruction and OEM name were omitted, and the MS-DOS file system parameters (offsets 0x0B - 0x17 in the standard sector) were located at offset 0x50.

Szegények itt szenvednek (http://www.actapricot.org/support/apricot_file_transfers.html), hogyan lehet a lemezeiket áthozni PC-re, közben meg csak EP-n egy COPY az egész :-)
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.05. 23:42:04
Mûködik is! Mondjuk az EPDOS az elszáll tõle (meg 1.x PC-DOS lemeztõl is :-) ), így Disk Editorba lépés után kell berakni az Apricot lemezt, hogy lássuk a boot szektort:
[attachthumb=1]
Az EXDOS viszont szépen látja, ahogy az most már várható is volt.
[attachthumb=2]

Az XP meg csak ezt bírja kinyõgni rá  :ds_icon_cheesygrin:
Quote
Microsoft Windows XP [verziószám: 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>dir a:
A kötet nem tartalmaz felismert fájlrendszert.
Gyõzõdjön meg róla, hogy az összes szükséges fájlrendszer-illesztõprogram be van
-e töltve, és a kötet nem sérült-e.

C:\>
Title: Re: EXDOS
Post by: Lacika on 2010.July.06. 07:43:38
Ez nagyon tetszik! Döbbenetes, 25 év után kiderül, hogy az EXDOS nem csak MSDOS kompatibilis...
Ez talán még az angol EXDOS dokumentációkban sincs benne?
Title: Re: EXDOS
Post by: geco on 2010.July.06. 09:01:16
Vajon még milyen extrákat rejteget gépünk... :)
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.06. 09:55:50
Ez talán még az angol EXDOS dokumentációkban sincs benne?
Benne van:
Quote
As mentioned previously, programs will only be generally available on the 3.5" format. The choice of drive size and format however, may be dictated by other considerations. EXDOS is MS-DOS `file compatible' and so can read and write disks produced on other computers. These computers include the IBM PC and compatibles (which mostly use 5.25" drives) and the Apricot range, RM Nimbus, Atari 520ST and the MSX machines (all of which use 3.5"). If data portability is important to you, it is essential to choose drives that can handle the size and format of the disks from the other computer.

Maximum flexibility for the interchange of data with other computers could be achieved by having one 3.5" drive and one 5.25", both of which were double sided, 80 track. This combination would even allow data to be transferred from an IBM PC to an Apricot or vice versa via the Enterprise while still maintaining access to the generally available Enterprise programs

A magyarban is :-)
Quote
Már említettük, hogy a programok fõleg az 5.25"-es lemezen elérhetõk. A meghajtó méretének kiválasztásában azonban még egy fontos tényezõ is szerepet játszhat. Az EXDOS az MS-DOS-szal file-szinten kompatibilis, így más típusú gépeken írt lemezek is olvashatok. Ilyenek pl. az IBM PC kompatibilis gépek (fõként 5.25"-os lemezt használnak), az Apricot család, az RM Nimbus, Atari 520ST és az MSX gépek (mind 3.5"-es lemezt használnak). Ha a hordozhatóság önnek nagyon fontos, lényeges, hogy más gépekkel megegyezõ méretû és formátumú meghajtót vásároljon.

Legsokoldalúbbá rendszerünket egy 3.5"-es és egy 5.25"-es meghajtó beállításával tehetjük, mindkettõ legyen 80 sáv formátumú és kétoldalas. Ez a konfiguráció lehetõvé teszi adatok átvitelét pl. IBM PC-rõl egy Apricot gépre (és fordítva) az Enterprise-on keresztül, miközben az Enterprise által terjesztett programokat is tudjuk használni.

Csak azt nem tudtuk eddig, hogy az Apricot ilyen kretén egyedi boot szektort használ, és ez így nagy dolgot jelent! Atari ST normális, MSX is (itt annyi plusz van az EXDOS részérõl, hogy teszt egy RET utasítás oda, ahol az MSX boot kód indulna, így nem fagyna le egy MSX gép EP-n formázott lemeztõl).
Elsõ ránézésre az a RM Nimbus is normál lemezt használ.
Title: Re: EXDOS
Post by: Zozosoft on 2010.July.07. 22:58:20
Az Atari TOS* ilyen boot szektort gyárt:
[attachthumb=1]
Jól látható, hogy az éppen használt memória tartalomba (ami ez esetben az utolsó sáv formázásához használt sáv adatok), írja bele a kötelezõ adatokat. Ez így 100%-ig megfelel a Bill Gates által kitalált FAT szabványoknak. Ezek után gondolom senki nem lepõdik meg azon, hogy Microsoft operációs rendszerek nem olvassák :-)
Az EXDOS természetesen igen!
Ez úgy is mûködik, hogy az XP nem olvassa, de az ep128emuban futó EP meg igen :-)

* az 1989-ben megjelent 1.04 verzióra írják, hogy javítottak a formázáson az MSDOS kompatibilitáshoz
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.04. 22:58:07
Az EXDOS lemez felismerésének menete, azaz a UNITH egység mûködése 3-as akciókódnál:
-disk reset DISKIO hívás, azaz a fej 0. sávra állítása
-0. sáv 0. fej 1. szektor, azaz a boot szektor beolvasása
 -ha nem sikerült, akkor 0. sáv 0. oldalról megpróbál egy szektor azonosítót beolvasni
 -ha ez sikerült, akkor 180-as hiba lesz: Not a DOS disk
 -ha sikertelen volt, akkor 181-es hiba, Unformated disk
(Itt megjegyzem, hogy van egy sajnálatos hiba az EXDOS-ban: 1024 bájtos szektorokkal formázott lemez esetén hatalmas fagyás lesz, mert az 512 bájtosra méretezett puffer mögötti memória felül lesz írva az 1024 bájtos boot szektor beolvasásakor. A helyes megoldás az lenne, ha elõször lenne szektor azonosító olvasás, és abban ellenõrizni, hogy 512 bájtos-e? Majd javítom ezt is, bár az 1024 bájtos lemezekkel való összefutás esélye elég csekély, különösen manapság  :ds_icon_cheesygrin:
Dr. Préry! Tudom, hogy itt leskelõdsz  :lol: mi volt az a Ataris formázó program amivel mindenféle kretén formátumú lemezeket tudtál nekem formázni?)

-sikeres boot szektor olvasás esetén ellenõrzi a következõ paramétereket (0Bh bájtoktól):
 -szektor méret 512 bájt?
 -cluster méret 0-nál nagyobb, és 2 hatványa?
 -FAT példányok száma 1-7 között van?
 -FAT méret 1-12 szektor között van?
 -egy sávon max 10 szektor van? (Ez az eredeti érték, ezt azóta többször is módosítottuk.)
-sikertelen ellenõrzés esetén 50h-tól megismétli az ellenõrzést, azaz Apricot lemezként próbálja értelmezni. Ha így sikerült a felismerés akkor a paramétereket átmásolja a helyükre, vagyis a hívásból visszatérve szabványos boot szektort fog kapni a FISH
-ha se a normál se az Apricot módszer nem vezetett eredményre, akkor megpróbálkozik az MS-DOS 1.x lemezekhez való módszerrel:
  -beolvassa a 0. sáv 0. oldal 2. szektort, azaz a FAT elsõ szektorát
  -ellenõrzi, hogy az 1. és 2. bájt az FFh, és 0. bájt az F8-FFh, azaz FAT típusbájt-e
  -ha így se sikerült azonosítani, akkor Not a DOS disk
  -ha meg van a típusbájt, akkor az alapján legyárt egy szabvány boot szektort a következõ paraméterekkel:
   FFH - DS/SD/8 (320K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 1 FAT szektor, 2 példány
   FEH - SS/SD/8 (160K), 1 boot szektor, 1 szektor/cluster,  64 fõkönyvtár bejegyzés, 1 FAT szektor, 2 példány
   FDH - DS/SD/9 (360K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 2 FAT szektor, 2 példány
   FCH - SS/SD/9 (180K), 1 boot szektor, 1 szektor/cluster,  64 fõkönyvtár bejegyzés, 1 FAT szektor, 2 példány
   FBH - DS/DD/8 (640K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 2 FAT szektor, 2 példány
   FAH - SS/DD/8 (320K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 2 FAT szektor, 2 példány
   F9H - DS/DD/9 (720K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 3 FAT szektor, 2 példány
   F8H - SS/DD/9 (360K), 1 boot szektor, 2 szektor/cluster, 112 fõkönyvtár bejegyzés, 2 FAT szektor, 2 példány

-ha meg van az ellenõrzött boot szektor, akkor következik a lemezkompatibilitás ellenörzése
-két oldalas lemez esetén beolvas egy szektor azonosítót a 0. sáv 1. oldalról, és ellenõrzi, hogy tényleg az 1. oldalhoz tartozó azonosítót olvasott be. Ha nem sikerült, akkor 150-es hibakód, Incompatible disk
-elléptet a 8. sávra, és beolvas a 0. oldalról egy szektor azonosítót, majd ellenõrzi, hogy hanyadik sávhoz tartozik a beolvasott azonosító:
 -4., azaz SD lemez DD meghajtóban, dupla léptetést bekapcsolja
 -8., megfelelõ beállítás
 -16., azaz DD lemez SD meghajtóban, Incompatible disk.
Ha több egyforma lemez használunk egymás után, akkor ezt a kompatibilitás ellenõrzést nem végzi újra el. (Ennek az ellenörzésnek van az a jellegzetes taktak hangja az elsõ lemez beolvasásakor, amit TVC használatakor is fel lehet ismerni, ami nyilván nem véletlen :-) )

Külön nem említettem, ha nincs bent lemez, vagy nem elérhetõ a meghajtó akkor természetesen Not ready hiba lesz.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.07. 21:34:55
Egy újabb érdekesség, így néz ki az EXDOS által használt formázáshoz használt sávformátum:
Code: ZiLOG Z80 Assembler
  1.                 ;tömörített sáv adatok formázáshoz
  2.  
  3. LE553:  DB 03CH,04EH    ;60x4Eh pre-index GAP (GAP4b)
  4.         DB 00CH,000H    ;12x00h Sync (PLL Lockup time)
  5.         DB 003H,0F6H    ; 3xF6h Sync (C2h kerül a lemezre)
  6.         DB 001H,0FCH    ; 1xFch Index Mark
  7.         DB 03CH,04EH    ;60x4Eh post-index GAP (GAP1)
  8.  
  9.                 ;szektor fejléc
  10. LE55D:  DB 00CH,000H    ;12x00h Sync (PLL Lockup time)
  11.         DB 003H,0F5H    ; 3xF5h Sync (A1h kerül a lemezre)
  12.         DB 001H,0FEH    ; 1xFEh ID Address Mark
  13.         DB 002H,000H    ; 2x00h Track Number, Side Number
  14.                         ;       Sector Number
  15. LE565:  DB 001H,002H    ; 1x02h 512 bájtos szektor méret
  16.         DB 001H,0F7H    ; 1xF7h 2 CRC bájt kiírása
  17.                 ;szektor adatterület
  18.         DB 016H,04EH    ;22x4Eh ID GAP (GAP2)
  19.         DB 00CH,000H    ;12x00h Sync (PLL Lockup/Write slice time)
  20.         DB 003H,0F5H    ; 3xF5h Sync (A1h kerül a lemezre)
  21.         DB 001H,0FBH    ; 1xFBh Data Address Mark
  22.         DB 000H,0E5H   ;256xE5h adatbájtok    
  23.         DB 000H,0E5H   ;256xE5h adatbájtok
  24.         DB 001H,0F7H    ; 1xF7h 2 CRC bájt kiírása
  25.         DB 054H,04EH    ;84x4Eh Data GAP (GAP3)
  26. LE579:  DB 000H,04EH   ;256x4Eh run out GAP (GAP4a)
  27.         DB 0CCH,04EH   ;204x4Eh run out GAP (GAP4a)

Ami az érdekes, hogy az elsõ 4 sornyi azaz az Index Mark-os történet, nem szerepel a WD 177x leírásban, ott így néz ki az ajánlott MFM formátum:
[attachimg=1]

Viszont a WD 179x leírásban még szerepel:
[attachimg=2]

Lehet, hogy még a VTDOS fejlesztésbõl maradt benne ez a kódban? :-) Vagy eredetileg 1793-assal tervezték az EXDOS-t, ahogy a TVC lemezvezérlõjét is?

Mindenesetre egyik leírásból sem derül semmi ki arról, hogy mindez mire is jó a sáv elején, csak annyi, hogy F6h hatására C2h kerül a lemezre. A nevébõl én arra tudnék következtetni, hogy ez egy szoftveres Index jel lehetett abból az idõkbõl, amikor még nem volt Index jeladó a meghajtókon? Annyi azonban biztos, hogy a WD-k ezt nem kezelik, õk a hardveres Index jelet várják a meghajtóktól.
Valószínûleg ezért is maradt ki már teljesen a 177x leírásból...
Egy Ataris oldalon olvastam, hogy az ST-n is 177x leírásban ajánlottak alapján megy a formázás.

Mondjuk elférni elfér, egyedül a 11/22 szektoros formázásnál jöhet jól az elhagyásával nyert pár plusz bájtocska.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.11. 10:38:08
Úgy tûnik meg van a dolog eredete. Elõször is egy kis összefoglaló a floppy szabványokról:
-ISO 5654/1:1984, 200 mm (8"), 1,9 tpmm (48 tpi), one-sided, 13 262 ftpr (SS/SD); ISO 5652/2:1984 Formatted (ECMA-54 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-54,%202nd%20Edition,%20January%201982.pdf))
-200 mm (8"), 1,9 tpmm (48 tpi), two-sided, 13 262 ftpr, (DS/SD); (ECMA-59 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-59,%201st%20Edition,%20August%201979.pdf))
-ISO 7065/1:1985, 200 mm (8"), 1,9 tpmm (48 tpi), two-sided, 13 262 ftpr, (DS/DD); ISO 7065/2:1985 Formatted (ECMA-69 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-69,%201st%20Edition,%20January%201981.pdf))

-ISO 6596/1:1985, 130 mm (5.25"), 1,9 tpmm (48 tpi), one-sided, 7 958 ftpr, (SS/SD); ISO 6596/2:1985 Formatted (ECMA-66 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-66,%201st%20Edition,%20September%201980.pdf))
-ISO 7487/1:1986, 130 mm (5.25"), 1,9 tpmm (48 tpi), two-sided, 7 958 ftpr, (DS/DD) (MD-2DD); ISO 7487/2:1986 Track Format A; ISO 7487/3:1986 Track Format B (IBM) (ECMA-70 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-70,%202nd%20Edition,%20June%201986.pdf))
-ISO 8378/1:1986, 130 mm (5.25"), 3,8 tpmm (96 tpi), two-sided, 7 958 ftpr, (DS/QD); ISO 8378/2:1986 Track Format A; ISO 8378/3:1986 Track Format B (IBM) (ECMA-78 (http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-78,%202nd%20Edition,%20June%201986.pdf))
-ISO 8630/1:1987, 130 mm (5.25"), 3,8 tpmm (96 tpi), two-sided, 13 262 ftpr, (DS/HD) (MD-2HD); ISO 8630/2:1987 Track Format A (77 Tracks); ISO 8630/3:1987 Track Format B (IBM) (ECMA-99 (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-099.pdf))

-ISO 8860/1:1987, 90 mm (3.5"), 5,3 tpmm (135 tpi), two-sided, 7 958 ftpr, (DS/DD) (MF-2DD); ISO 8860/2:1987 (ECMA-100 (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-100.pdf))
-ISO 9529/1:1989, 90 mm (3.5"), 5,3 tpmm (135 tpi), two-sided, 15 916 ftpr, (DS/HD) (MF-2HD); ISO 9529/2:1989 (ECMA-125 (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-125.pdf))
-ISO 10994/1:1992, 90 mm (3.5"), 5,3 tpmm (135 tpi), two-sided, 31 831 ftpr, (DS/ED) (MF-2ED); ISO 10994/2:1992 (ECMA-147 (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-147.pdf))

Ebbõl egyrészt kiderül, hogy kb mindenki rosszul használja az SD,DD fogalmakat  :oops:
Az SD az valójában az FM felírást jelenti amit a WD is ismer, ahol az általunk megszokotthoz képest fele akkora sebességgel (125kbit/sec) fele annyi adat fér egy sávra. A DD az jól ismert MFM felírás, viszont különbözõ sávszám tartozik hozzá a különbözõ lemezeken! 8" 77 5.25" 35/40 3.5" 80
Az általunk használt 5.25" 80 sávos 720-as meghajtók pedig valójában QD-sek.

De szerintem most már késõ lenne megreformálni a népnyelvet  :lol:

Másrészt visszatérve az Index Mark-os történethez:
8" lemezen van még ilyen:
[attachthumb=1]

5.25"-ös lemezen már nincs:
[attachthumb=2]

Vagyis ez tényleg egy régrõl benne maradt õsi dolog az EXDOS sáv formátumában.
Title: Re: EXDOS
Post by: Z80System on 2011.November.11. 19:23:18
Istenem, de szeretnek megegy eletet, hogy beleashatnam magam ugy ezekbe a dolgokba, hogy ertsem mit beszelsz ... de ha ujra szuletnek most, ennek az infonak se technikai se szentimentalis erteke nem volna ... csak ecce lephetunk ugyanabba a folyoba.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.11. 20:01:39
ertsem mit beszelsz ...
Szabad kérdezni! :-)
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.11. 22:48:02
Megpróbálom a elejétõl:

A lemez fix, percenként 300-as fordulatszámmal forog, a vezérlõ pedig fix átviteli sebességgel ír/olvas, ez FM átvitelnél 125000 bit/sec, MFM-nél 250000 bit/sec, ezeket ismeri a WD 177x gyárilag. (A HD-s lemezekhez pedig már 500000 bit/sec kell, ezt a Turbo EXDOS átalakításnál a WD órajelének duplájára növelésével értük el.)
A normál EP-s lemezeknél az MFM mód használatos, könnyen kiszámolható egy sáv mérete: másodpercenként 5 fordulat, tehát 250000/5=50000 bit osztva 8-al=6250 bájt. Ez azonban csak a formázatlan kapacitás, egy normál 720-as lemez esetén 2x80x6250=1000000 bájt, ezt szokták a lemezeken kis lódítással 1MB-nak megadni. Valójában 976KB.
Azonban ezt nem lehet teljesen adattárolásra kihasználni, a biztonságos adatátvitelhez további dolgok is szükségesek: kellenek a szektorok címét tartalmazó szektor fejlécek, valamint ezek, és az adatterületek elé szinkronizációs bájtok kellenek, ahogy a magnós átvitelnél is a bevezetõ szinkron sípolások. A fejléceket és adatterületeket CRC bájtok zárják le, hogy az átvitel hibátlanságát ellenõrizni lehessen. A maradék helyet kitöltõ üres területeket nevezzük GAP-eknek. Ezeknek kettõs szerepük van: a vezérlõnek szüksége van bizonyos mûveleteknél (szektorcím ellenõrzés, CRC számítás, írás elõkészítés) némi idõre, azonban a lemez ez idõ alatt is elfordul, így ezen idõ alatt elhaladó bájtok adják meg 1-1 GAP lehetséges legrövidebb hosszát (pl távolság a szektor fejléc és szektor adatterület között). Azonban a különbözõ meghajtók nem pontosan tartják a szabványos van köztük lassabb, gyorsabb ezért célszerû biztonsági okokból a GAP-eket nagyobbra méretezni, különben ha pl túl közel van két szektor egymáshoz, akkor egy gyorsabb meghajtóban az elsõ szektor írásakor felülíródik a második szektor eleje. Ennek a veszélye a 11 szektoros lemezek esetén áll fent, mivel ahhoz, hogy a 11 szektor elférjen, szinte minden GAP teljesen minimálásra lett véve.
Az MSDOS kompatibilis 9 szektoros formátum azonban fölöslegesen nagy GAP-eket tartalmaz, a WD leírásban lévõ összes ajánlott értéket betartva létrehozható a 10 szektoros formátum is. Talán az igen korai gyártású, ékszíjas meghajtású meghajtókra gondoltak, amikor a 9 (pláne a 8 ) szektoros formátumot kitalálták... de már a 80-as évek közepére is bõven túllépett ezeken a technika.

Visszatérve sávon található információkhoz, így néz ki egy sáv szerkezete:
-nagy bevezetõ GAP
-1. szektor fejléc
-kisebb GAP
-1. szektor adatterület
-nagyobb GAP
-2. szektor fejléc
...
-9. szektor adatterület
-nagy kivezetõ GAP

Amikor ezeket a területeket létrehozzuk, azt nevezzük formatálásnak. Ehhez létre kell hozni egy memória pufferben a sáv adatokat tartalmazó adatblokkot, majd ezt kiküldeni egy sávírás paranccsal a WD-nek. Ebben a blokkban különbözõ meghatározott bájtok, bájtkombinációk jelzik az adott területeket.
Korábban betettem ide azt a tömörített táblázatot amibõl az EXDOS elõállítja ezt a sáv formázási adatblokkot.
Ennek elemzésekor bukkantam egy érdekességre: az elsõ szektor elõtt található bevezetõ GAP, nem egy egybefüggõ terület, hanem van benne egy Index Mark nevû valami, amirõl egy szó nincs a WD 177x leírásban. Vajon mi ez és mért van ott?
Elõször a miénknél korábbi WD 179x leírásban bukkantam nyomra, ott még van ilyen a sáv formátum példában.
További nyomozásként elõástam a floppy lemezekre vonatkozó szabványokat, a legõsibb 8 collostól a legfejlettebb 3.5" ED-s lemezig. Ezeknek az európai szabványát (ECMA-xx) be is linkeltem (az ISO leírás letöltéséhez baromi sok svájci frankot akarnak kérni...).
Ezekbõl kiderült, hogy a 8" lemezeknél még használatban volt ez a jel, az 5.25" lemezeknél már nem, 3.5" lemezeknél sem. Magyarán ez a pár bájt simán elhagyható.
Title: Re: EXDOS
Post by: vizor on 2011.November.11. 23:12:48
Akkor ezek szerint ha igazi EP igazi floppymeghajtójával megformázok egy lemezt, akkor PC-n tudok rá másolni Atari fájlokat és az Atari 1040ST FM gépem be is fogja olvasni? Milyen 3,5"-os meghajtókat lehet az EP lemezvezérlõ kártyájához kapcsolni? Gondolom a PC-s HD-s nem jó. Az Amiga500 vagy 500+-om floppyja jó lenne hozzá? Vagy egy külsõ Amiga floppydrive? (Persze csak átmenetileg szerelném ki belõlük  :ds_icon_cheesygrin:) Esetleg az Apple II-é lenne az igazi? Minden más floppym 5.25"-os  :)
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.11. 23:22:05
Akkor ezek szerint ha igazi EP igazi floppymeghajtójával megformázok egy lemezt, akkor PC-n tudok rá másolni Atari fájlokat és az Atari 1040ST FM gépem be is fogja olvasni?
Igen. (Régi TOS-os az Atarid, és ezért nem olvassa a PC?)

Quote
Milyen 3,5"-os meghajtókat lehet az EP lemezvezérlõ kártyájához kapcsolni? Gondolom a PC-s HD-s nem jó.
Bármilyen, a PC-s HD-s is jó (természetesen DD-sként, hacsak nincs turbosított EXDOS-od).
Ha van mellette egy A: meghajtód, akkor semmi más teendõd nincs, mint mellé rakni B-nek. Ha A-nak akarod, akkor vagy keresel egy olyan darabot amin még van jumper, vagy egy picit bütykölni kell. (http://ep128.hu/Ep_Hardware/PC_FDD.htm) 
Title: Re: EXDOS
Post by: vizor on 2011.November.11. 23:37:41
Megmondom õszintén, még sosem jutott eszembe az Ataris lemezeket PC-n kipróbálni. Van kb. 10 lemezem hozzá, amin autostart-os játékok vannak. Most pillanatnyilag egyik PC-ben sincs floppy, csak megragadta a figyelmem ez a lehetõség. Az EP-hez egy A: 5.25"-os floppy van, meg fogom nézni. Köszi az infót!

u.i.: nincs lehetõség Amiga lemezeket másolni EXDOS-al? Jó lenne egy mûködõ Workbench.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.12. 00:51:00
u.i.: nincs lehetõség Amiga lemezeket másolni EXDOS-al? Jó lenne egy mûködõ Workbench.
Sajnos nem, mert az Amiga régi Commodore szokás szerint semmivel nem kompatibilis egyéni lemez formát használ, nem MFM kódolást.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.13. 11:08:47
Laci! FISH cikk kiegészítendõ:
FISH 21-nél C-ben a meghajtó adatterület szegmensszámát kapjuk vissza (ez a beépített eszközöknél a rendszerszegmens, bõvítéseknél (pl merevlemez) azonban bármi más is lehet)

FISH 29-nél a hordozó helyett írjunk formázási típusbájtot, ahogy máshol is. A szövegben pedig a "A funkció ellenõrzi," helyett: A FISH nem végez ellenõrzést a típusbájttal kapcsolatban, azt változatlanul adja tovább a meghajtó kezelõprogramjának. A hívásnál a DE-vel megfelelõ méretû pufferterületre kell mutatni, ez a beépített lemezegység kezelõnél 6500 bájtot jelent.
A Ramdisk-et kezelõ RAMUNIT nem kezeli a funkció hívást, a floppy meghajtókat kezelõ UNITH egység pedig a következõ módon hajtja végre...

És még egy apróság a paraméterek leírását jobb lenne a FISHDOC-ban használt módon megadni, úgy olvashatóbb lenne.
Title: Re: EXDOS
Post by: Lacika on 2011.November.13. 17:35:28
A Ramdisk-et kezelõ RAMUNIT nem kezeli a funkció hívást, a floppy meghajtókat kezelõ UNITH egység pedig a következõ módon hajtja végre...

Mi a mondat vége? :oops:
Jól gondolom: "A Ramdisk-et kezelõ RAMUNIT nem kezeli a funkció hívást, a floppy meghajtókat kezelõ UNITH egység pedig a következõ módon hajtja végre: a funkció ellenõrzi, hogy az adott meghajtó alkalmas-e a kívánt formátumban való mûködésre, és szükség esetén 40-ben korlátozza a sávok számát, ill. 1-ben az oldalakét."

És még egy apróság a paraméterek leírását jobb lenne a FISHDOC-ban használt módon megadni, úgy olvashatóbb lenne.

... ???
Halandók számára lefordítva ez mit jelent?  :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.13. 17:51:05
Jól gondolom:
Jól.
Quote
Halandók számára lefordítva ez mit jelent?  :oops:
Pl:
Ehelyett:
Quote
19. Szektorok írása (logikai szektor)
DE = SZEK      DE = következõ SZEK
H = SZEKN      H = kiírt SZEKN
L = MEGH        L = MEGH
IX = TRC          IX = TRC a következõ bájtra mutat

Ez:
Quote
Paraméterek :   IX -> transzfercím
                DE =  logikai szektorszám
                 H =  írandó szektorok száma
                 L =  meghajtó száma (1...26)

Eredmények :    IX -> aktualizált memóriacím
                DE =  következö logikai szektorszám
                 H =  írt szektorok száma
                 L =  ua. a meghajtó szám
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.13. 19:08:56
A FISH nem végez ellenõrzést a típusbájttal kapcsolatban, azt változatlanul adja tovább a meghajtó kezelõprogramjának.
Ez egyébként abból a szempontból jó hír, hogy viszonylag egyszerûen meg lehet majd oldani, hogy egy készülõ új "normális" Turbo Exdos tudjon a FORMAT paranccsal HD-s lemezt is formázni. A FORMAT feldolgozásába kell újabb paramétereket belevenni, ill. a UNITH formázó részét kibõvíteni.
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.16. 14:50:15
FISH 21-nél javítandó:
"IX = meghajtó adatterület+8" helyett: meghajtó adatterület (ez az EXDOS által belsõleg használt meghajtó leíró +8 bájtjára mutat)

táblázat:
IX-08h: meghajtó RAM terület szegmensszáma, kivéve a beépített egységek esetén, ott a UNITH meghajtóinál 0, RAMUNIT-nál 2
IX-07h,06h: meghajtó RAM terület címe, beépített EXDOS egységek esetén ez szokásosan az EXDOS RAM terület 80h bájtjára mutat, bõvítõ egységek esetén megegyezik azzal a címmel, amit a bõvítõ megadott a leírok létrehozásához, tehát a meghajtóleíróblokk 0. bájtjára mutat
IX-05h: meghajtó kezelõprogram szegmensszáma
IX-04h,03h: meghajtó kezelõprogram címe (3. lapon)
IX-02h: belsõ egységszám, minden egység esetén 0-tól induló belsõ sorszám, és addig tart ahány alegységet kezel (pl a floppyt kezelõ UNITH esetén ez 0-3)
IX-01h: (1-26) meghajtószám MAPDISK átirányításhoz, ha nincs átirányítás, akkor megegyezik a fizikai meghajtószámmal
IX+00h: (1-26) fizikai meghajtószám, 1-tõl kezdõdik, beláncolás sorrendjében folyamatosan növekvõen kerül kiosztásra
IX+01h: belsõ lemezcsere ellenõrzés jelzõbájt
IX+02h: cluster maszk (egy clusterben lévõ szektorok száma-1)
IX+03h: cluster eltolás (clusterméret 2-es alapú logaritmusa, azaz 2 hanyadik hatványa a méret)
IX+04h,05h: boot szektorok száma=elsõ FAT szektor sorszáma
IX+06h: FAT példányok száma
IX+07h: bejegyzések száma az utolsó fõkönyvtár szektorban, 0 ha 16 bejegyzés van, azaz a teljes szektort kitölti
IX+08h: fõkönyvtár teljes szektorainak száma, ha ez elözõ érték nem 0, akkor van még 1 csonka szektor is
IX+09h: FAT szektorok száma
IX+0Ah,0Bh: elsõ fõkönyvtár szektor sorszáma
IX+0Ch,0Dh: 2. cluster logika szektorszáma (elsõ adatszektor)
IX+0Eh,0Fh: legnagyobb lehetséges cluster sorszám+1 (clusterek száma+2)
IX+10h: "piszkos diszk"-jelzõ : 0 = tiszta ; 1 = piszkos (UNDEL jelzõbájt)
IX+11h-14h: 32 bites lemez azonosító (ID) (amelyik lemez nem tartalmaz ilyet, ott FFFFFFFFh)
IX+15h: formazási típusbájt
IX+16h,17h: aktuális könyvtár kezdõ cluster száma, (IX+17h) 7-es bitje 1 ha a fõkönyvtár az aktuális
IX+18-57: aktuális útvonal sztring, 00h-val lezárva
Title: Re: EXDOS
Post by: Mayer Gábor on 2011.November.16. 17:57:48
hol kell javítani?

Amúgy a wikiben van az exdosnak oldala? Ha nincs akkor létrehozom. Kezdetnek feltehetnénk az exdos verziók leírását, ha jobb ötlet nincs akkor a te ezzel kapcsolatos postod alapján, illetve linkeket a romokra vagy ha lehet, akkor csatolni őket wikibe.
Title: Re: EXDOS
Post by: Lacika on 2011.November.16. 18:48:04
Megtörtént!
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.16. 19:54:24
Itt gyûjtögetjük össze a szoftveres tudnivalókat. (http://www.ep128.hu/Ep_Konyv/Exdos_Muszaki_Leiras.htm)
Itt meg az általános dolgokat szedte össze Lacika. (http://www.ep128.hu/Ep_Hardware/Ep_Exdos.htm)
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.18. 11:02:35
Egy kis boot szektorológia  :)
Így néz ki az EXDOS boot szektor:

00-02 EBH. FEH, 90H IBM ( Ugrás a betöltõ kódra)
03-10 "EXDOS 1.0" rendszer (formázó software)
11-12 512 byte / szektor
13      szektor/cluster
14-15 boot szektorok száma (általában 1)
16      FAT példányok száma (általában 2)
17-18 fõkönyvtár bejegyzések száma
19-20 lemez szektorainak száma
21      formázási típusbájt (F8h-FFh)
22-23 egy FAT példány szektorainak száma
24-25 szektor/sáv
26-27 fejek száma
28-29 rejtett szektorok száma
Innentõl csak EXDOS (vagy VT-DOS) lemezeken:
30      C9H RET, az MSX-DOS BOOT program belépési pontja
31-63 0 nullázás
64-69 "VOL_ID" azonosító string
70     0 UNDEL jelzõ-byte
71-74 32 bites lemezazonosító
75-99 0 nullázás
100-511 E5H üres terület

A 03-29 terjedõ terület megfelel a FAT szabványban leírtaknak, most inkább a körítéssel foglalkoznék:
A 00-02 címen található egy x86-os ugróutasítás, amire az EXDOS-nak nincs semmi szüksége, de kompatibilitási okokból oda teszi, mivel egyes Microsoft operációs rendszerek - a saját szabványuktól eltérõen - ellenõrzik ennek a meglétét is. Ebbe futottak bele az Atarisok, mivel a korai TOS verziók nem írták ezt oda, így a PC-k nem olvasták az Atarin formázott lemezeket.
30-as címen az MSX tulajdonosokra gondoltak, hogy egy véletlen meghajtóban felejtett EP lemez esetén nem okozzon elszállást a bootolási kísérlet, ezért egy RET utasítást tettek erre a belépési pontra.
64-74 bájtokon terül el az EXDOS saját extrái: 64-69 bájtokon a "VOL_ID" azonosító jelzi, hogy ez egy EP lemez, és tartalmazza a következõ 2 adatot. 70-en egy jelzõ bájt jelzi, hogy a lemez tartalmaz törölt, de helyreállítható fájlokat. 71-74 bájtokon pedig egy véletlenszerû 32 bites lemezazonosító található, aminek lemezcsere ellenõrzésnél veszi hasznát.

Az EXDOS megalkotása óta eltelt több mint 25 évben újabb szabványok újabb adatokat pakoltak a boot szektorba:

28-31 rejtett szektorok száma (32 bit)
32-35 lemez szektorainak száma (32 bit)
36      fizikai meghajtó szám (PC) (00h floppy, 80h HDD)
37      CHKDSK jelzõbájt (Windows NT alapú rendszerek)
38      kibõvített boot szektor jelzõbájt (29h) ez jelzi, hogy a következõ paraméterek léteznek
39-42 32 bites lemezazonosító
43-53 11 karakteres lemeznév
54-61 7 karakteres fájlrendszer azonosító "FAT12  " vagy "FAT16  "
510-511 55h,AAh boot szektor jelzés

Ezeket az újdonságokat is célszerû lesz beépíteni az EP-s formázó programokba, a mai rendszerekkel való jobb kompatibilitás érdekébe. Szerencsénkre ezek mind az EXDOS által kihagyott üres területre esnek, így egyszerûen csak ki kell bõvíteni az eddigi EP-s boot szektort.
Egyedül csak MSX-eseknek kedveskedõ RET utasítás esik áldozatául a bõvítésnek, de az is csak vinyón, 65535 szektornál többet tartalmazó partició esetén, ez talán túlélhetõ probléma  :ds_icon_cheesygrin:
Mint látható pár évvel az EXDOS után a Microsoft is feltalálta a 32 bites lemezazonosítót :-) ezzel annyi a teendõ, hogy az EXDOS által is használt 32 bites azonosítót beírni a PC-s helyére is, valamint 38-as bájtra írt 29h-val jelezni, hogy van ilyen érték. A fájlrendszer azonosító esetünkben "FAT12  ".
A boot szektorba helyezett lemeznév az tulajdonképpen egy okos ötlet lett volna, hogy ne a fõkönyvtárban kelljen keresgélni a lemez nevét. Viszont kipróbáltam MSDOS 6.2 és XP alatt is, hogy ettõl függetlenül a fõkönyvtárban lévõ lemeznevet használja, ha nincs olyan akkor se veszi elõ a boot szektorban lévõt. Így nyugodt szívvel figyelmen kívül hagyhatjuk ezt a mezõt. Majd egyszer bele lehet rakni a VOL parancsba, hogy ide is írja be.
Utolsó teendõ még a boot szektor végére elhelyezni az 55h,AAh bájtokat. Nem létszükséglet, de ki tudja mit ellenõriznek egyes kreténebb PC-s rendszerek (ahogy az már pl az ugró utasításról, vagy a formázó program nevérõl kiderült).

És van még egy dolog, a lemez elején EBh. FEh, 90h az egy önmagága ugró JMP utasítás PC-n, ami azt jelenti, hogy ha egy EP-s lemezt felejtünk a meghajtóban, és arról boot-ol a PC, akkor jól lefagy... végülis kárt nem okoz ez a megoldás, csak bosszantó, hogy resetelni kell.
Egyszerû megoldás, ami nem pazarol sok helyet: az EP-s lemez azonosító után pl a 75-76 címekre CDh,19h bájtokat kell írni, majd az ugró utasítást a lemez elején EBh,49h,90h-ra módosítani. Az új utasítás amire ráugrik, az egy INT 19h, ami újraindítja a boot-olást, azaz így újra meg újra olvassa a floppyt, azonban amikor észrevesszük a bent felejtett lemezt, és kivesszük, megy tovább rendesen, nem kell resetelni.
Ha nem sajnálunk több bájtot elpazarolni az EP-s programunkban, akkor egy hosszabb kóddal az is elérhetõ, hogy ki se kell venni a lemezt, az tölti be a vinyó boot szektorát (szintén 4Bh-re helyezve):

      db 31h,0C0h   ;xor   ax, ax
      db 8Eh,0D8h   ;mov   ds, ax
      db 8Eh,0C0h   ;mov   es, ax
      db 0FCh      ;cld
      db 0B9h      ;mov   cx,
      dw 100h      ;          100h
      db 0BEh      ;mov   si,
      dw  7C00h   ;          7C00h
      db 0BFh      ;mov   di,
      dw  8000h   ;          8000h
      db 0F3h,0A5h   ;rep movsw
      db 0EAh      ;jmp   far ptr 800h:62h
      dw  62h   
      dw 800h
      db 0B8h      ;mov   ax,
      dw 201h      ;          201h
      db 0BBh      ;mov   bx,
      dw  7C00h   ;          7C00h
      db 0BAh      ;mov   dx,
      dw  80h      ;          80h
      db 0B9h      ;mov   cx,
      dw   1      ;          1
      db 0CDh,13h   ;int   13h   ; DISK - READ SECTORS INTO MEMORY
      db  72h,5   ;jb   +5
      db 0EAh      ;jmp   far ptr   0:7C00h
      dw 7C00h
      dw   0
      db 0CDh,19h   ;int   19h   ; DISK BOOT
Title: Re: EXDOS
Post by: Mayer Gábor on 2011.November.18. 11:55:18
Ezek nagyon hasznos infók, miért nem a wikibe töltöd fel?
Title: Re: EXDOS
Post by: Povi on 2011.November.18. 11:56:23
jól látom, hogy az EP-n (EXDOS-on) nem létezik BOOT-ból induló program?

és CP/M-en?

egyébként erről (is) lehetne előadást tartani a specci találkozón... :-)

az MS-DOS formázója is EBH, FEH, 90H-t ír a 00 címre? elég nagy hülyeségnek tűnik nekem, hogy egy önmagára ugró utasítást tenne be oda, akkor már miért nem ott is egy RET van?
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.18. 12:05:43
jól látom, hogy az EP-n (EXDOS-on) nem létezik BOOT-ból induló program?
Igen. Ott az automatikus indításra az EXDOS.INI lett kitalálva.

Quote
az MS-DOS formázója is EBH, FEH, 90H-t ír a 00 címre? elég nagy hülyeségnek tûnik nekem, hogy egy önmagára ugró utasítást tenne be oda, akkor már miért nem ott is egy RET van?
Az MS-DOS természetesen értelmes ugrást tesz oda.
RET-et nem tehetünk oda, mert nem CALL-al hívja, hanem JMP-vel ugrik rá, A visszatérésre az említett INT 19h a lehetõség. Ami amúgy beférne ide az ugrás helyére, de az említett kompatibilitási okokból oda mindenképpen ugró utasítás kell.
Title: Re: EXDOS
Post by: lgb on 2011.November.18. 15:02:54
Egy kis boot szektorológia  :)
Na, ez az elemzes siman megerdemelne egy otost :)
Title: Re: EXDOS
Post by: Povi on 2011.November.18. 22:57:10
Igen. Ott az automatikus indításra az EXDOS.INI lett kitalálva.

Ez az EXDOS.INI inkább az autoexec.bat-ra hasonlít...

Bár, jobban belegondolva, az, hogy nincs boot-szektorból futtatható kód az EP-n, azzal kizárjuk a boot-vírusok lehetőségét is!  :mrgreen:
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.18. 23:10:56
Ez az EXDOS.INI inkább az autoexec.bat-ra hasonlít...

Bár, jobban belegondolva, az, hogy nincs boot-szektorból futtatható kód az EP-n, azzal kizárjuk a boot-vírusok lehetõségét is!  :mrgreen:
Így van!
Mivel nekünk ROM-ban van az operációs rendszer, így nincs szükség lemezes bootra. (Érdekességként van olyan XT laptopom, ami úgy bootol ROM-ból, hogy egy MS-DOS floppy image van ROM-ba égetve :-) )
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.18. 23:18:54
Ezeket az újdonságokat is célszerû lesz beépíteni az EP-s formázó programokba, a mai rendszerekkel való jobb kompatibilitás érdekébe.
FAFO-ba beépítve.
[attachthumb=1]
Title: Re: EXDOS
Post by: Povi on 2011.November.18. 23:19:59
(Érdekességként van olyan XT laptopom, ami úgy bootol ROM-ból, hogy egy MS-DOS floppy image van ROM-ba égetve :-) )

Úgy tudom, hogy az IBM PS/1-es gépen is a ROM-ba volt égetve a DOS 4.01... :-)
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.19. 09:09:48
FAFO-ba beépítve.
(Attachment Link)
Laci! látom már ki is raktad  :) Azt írhatnád még oda, hogy a PC-számára olyan boot kód lett beépítve, ami vinyóról folytatja a bootolást, így az esetleg a meghajtóban felejtett EP lemez olyan, mintha ott se lenne, nem kell már resetelni, mint a korábbi EP lemezeknél, ahol csak egy önmagára ugró JMP volt PC boot kódként.

(Ez a probléma nálam kb mindennap elõfordult, mivel segítek a Hard Disk Sentinel (http://www.hdsentinel.hu/) fejlesztõjének, és a vinyókról a pontos információ kinyerés DOS alatt lehetséges, ezért be van állítva a floppy boot. Az EP lemezek használata meg szintén mindennapos :-) )
Title: Re: EXDOS
Post by: Zozosoft on 2011.November.20. 21:53:10
Meg van az utolsó ismeretlen FISH hívás magyarázata:
FISH 30 szektorpuffer lefoglalása/felszabadítása
B=255 paraméter esetén a FISH az általa használt szektorpufferek közül egyet kivon a normál használatból, és címét átadja HL-ben. A HL által mutatott 512 bájt terület szabadon felhasználható annak felszabadításáig. Melegindításkor vagy EXOS 0 híváskor a foglaltság megszûnik.
Csak egy ilyen puffert lehet foglalni, ismételt híváskor a már korábban lefoglalt puffer címét adja vissza.
A pufferterület a 2-es lapon, a rendszerszegmensben található.

B=0 (vagy bármi 255-nél kisebb) paraméter esetén a korábban lefoglalt puffer visszakerül a FISH normál használatába.
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.12. 00:01:22
Találtam egy picike bugot az EXDOS-ban  :twisted:
[attachthumb=1]
Title: Re: EXDOS
Post by: lgb on 2011.December.12. 07:36:50
Találtam egy picike bugot az EXDOS-ban  :twisted:
(Attachment Link)


Ehhheee, ez majdnem olyan szitu akkor mint a microdrive ami speccy-n van/volt, nem? Drive-nak is hijjak, de ha jol remlik szallag van benne amugy, tehat "tape" is megvan. Lehet, nem is bug, habem feature?! :) Munkam soran (nem, nem "emberekkel talalkozom" mint a reklamban) is egyre tobbet futok bele olyan bug-okba ami mintha valami rejtett feature lenne. Vagy csak kozeledik 2012 es a "vilag vege" :)
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.12. 10:25:00
És erre milyen ideológiát találnál?  :lol:
[attachthumb=1]

És legyen egy németül is  :ds_icon_cheesygrin:
[attachthumb=2]

Még nem árulom el a megoldást, hátha kitalálja valaki.
Csak annyit, hogy nem kell hozzá semmi trükk, csak egy megfelelõen hibás lemez. Bármely EXDOS verzióból elõhozható.
Title: Re: EXDOS
Post by: lgb on 2011.December.12. 13:31:10
És erre milyen ideológiát találnál?  :lol:

És legyen egy németül is  :ds_icon_cheesygrin:

Még nem árulom el a megoldást, hátha kitalálja valaki.
Csak annyit, hogy nem kell hozzá semmi trükk, csak egy megfelelõen hibás lemez. Bármely EXDOS verzióból elõhozható.

Nemetul nem tudok :) A sound queue full az nagyon egyszeru: a fejleptetes hangjat igyekszik emulalni software-esen, mivel az ujabb meghajtok nagyon csendesek am! Viszont itt olyan szintu seek-elegetes volt, hogy megtelt tole az emulalt-fejbizeralas-hang queue ...
Title: Re: EXDOS
Post by: Lacika on 2011.December.12. 14:31:05
Nemetul nem tudok :)

Azt hiszem, ez az Invalid cursor coordinates német megfelelõje.

A sound queue full az nagyon egyszeru: a fejleptetes hangjat igyekszik emulalni software-esen, mivel az ujabb meghajtok nagyon csendesek am! Viszont itt olyan szintu seek-elegetes volt, hogy megtelt tole az emulalt-fejbizeralas-hang queue ...
:ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin:
Title: Re: EXDOS
Post by: Lacika on 2011.December.12. 14:32:39
Csak annyit, hogy nem kell hozzá semmi trükk, csak egy megfelelõen hibás lemez.

Azért valami huncutság lesz abban a "semmi trükk"-ben, mert ilyet eddig még nem láttam...  :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.12. 15:19:45
Azért valami huncutság lesz abban a "semmi trükk"-ben, mert ilyet eddig még nem láttam...  :oops:
És ilyesmit?
[attachthumb=1]

Már egy rossz értékû bájtocska okozhatja kamu hibaüzenetek generálását. Ha nincs a véletlenszerû hibakódhoz üzenet a rendszerben, akkor lesz ilyen számos hiba.
4 bájt jól megválasztott értékével pedig el lehet érni, hogy a kamu hiba kódja pontosan az általunk kiválasztott legyen :-)
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.12. 15:24:43
Azt hiszem, ez az Invalid cursor coordinates német megfelelõje.
Invalid beam position
Azért nem angolul tettem be, mert akkor rögtön elkezdtettek volna CD-ROM-ra asszociálni  :ds_icon_cheesygrin:
Title: Re: EXDOS
Post by: lgb on 2011.December.12. 17:40:51
Azt hiszem, ez az Invalid cursor coordinates német megfelelõje.
 :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin: :ds_icon_cheesygrin:

Amugy ez nem is annyira vicces, ha jobban belegondolok: van olyan floppy drive emulator (mar nem remlik, hogy pontosan hol, lehet az is Commodore gepekhez, talan az 1541Ultimate nevu project?), ahol van kulon sound emulacio, hogy hallhasd, dolgozik a "floppy" (ami valojaban persze nem igaz, mivel csak memoriakartyarol, stb emulalja a dolgot; igy nincs benne mozgo alkatresz, ami hangot adhatna - na azert kell emulalni, hogy meglegyen a feeling).
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.13. 09:18:25
Na itt egy hibát elõhozó image, így már könnyû lesz megfejteni :-)
Az ep128emu lemezkép ellenõrzõje észleli a hibát, ezért kézzel kell megadni a lemez paramétereket (80/2/9).
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.14. 09:52:00
Úgy látom szabad a gazda...
Itt a hiba (az 1.3-as EXDOS ROM-ban):
Code: ZiLOG Z80 Assembler
  1. LE1BB:  LD      A,0B4H          ;180-as hibakód, Not a DOS disk
  2. le1bd:  OR      A
  3.         RET  
  4. ...
  5.         DEC     DE              ;szektorok száma-1, =utolsó logika szektor sorszám
  6.         CALL    LE28F           ;sávok számának kiszámítása, és ellenõrzés
  7.                 ;C lesz, ha a szektorok+rejtett szektorok száma több mint FFFFH
  8.                 ;vagy ha a lemez szektorainak száma/(szektor/sáv)/oldal nem egész szám
  9.         JR      C,LE1BB         ;hibakóddal visszatérés
  10.         LD      A,D             ;sávok száma
  11.         OR      A               ;több mint 255?
  12.         RET     NZ              ;visszatérés ha igen
  13.         LD      A,E
  14.         DEC     A
  15.         CP      0FEH            ;ha sávok száma 255, vagy 0
  16.         JR      NC,LE1BB        ;hibakóddal kilépés
  17.         LD      (IX+01H),E      ;legnagyobb sáv sorszámának letárolása

Amikor a sávok számát ellenõrzi, akkor két esetnél rendesen hibakóddal visszatérésre ugrik. Viszont abban az esetben, ha a sávok száma 255-nél nagyobbra jön ki, elfelejtettek a hibakódra ugorni, csak egy sima RET NZ van, így az A aktuális értéke (=sávok száma felsõ bájt) adódik vissza mint hibakód, így jöhetnek a kamu hibaüzenetek. A korábban emlegetett megfelelõ paraméterek a konkrét kiválasztott hibaüzenet produkálásához: oldalszám: 1, szektor/sáv: 1, az összes szektor száma alsó bájt: 0, felsõ bájt: a kiválasztott hibaüzenet kódja+1

A helyes kód az lenne, ha a RET NZ helyén egy JR NZ,E1BB lenne. Viszont utólag ez már nem fér be...
Úgy viszont igen, ha össze vonjuk a CALL után a C flag vizsgálatát a D regiszter tartalmának vizsgálatával:
Code: ZiLOG Z80 Assembler
  1. LD A,00
  2. SBC A,D
  3. JR C,LE1BB
  4.  
Title: Re: EXDOS
Post by: Ep128 on 2011.December.14. 17:06:10
Mikre jössz rá még ennyi év elteltével is...  :)
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.15. 08:57:05
Mikre jössz rá még ennyi év elteltével is...  :)
Igyekszek :-)
Van más bug is, igaz az már nem ennyire mókás  :(
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.15. 11:03:27
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:
Code: ZiLOG Z80 Assembler
  1. DB      0BAH,0B9H,0B8h,0B8H,0B7H,0BFH,0B6H,0BDH
  2.         ;bit 0: 186 Not Ready
  3.         ;bit 1: 185 Verify error
  4.         ;bit 2: 184 Data error (ez valójában Lost data)
  5.         ;bit 3: 184 Data error
  6.         ;bit 4: 183 Sector not found
  7.         ;bit 5: 191
  8.         ;bit 6: 182 Write protected disk
  9.         ;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  :oops:

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:
Code: ZiLOG Z80 Assembler
  1.                 ;WD olvasási mûveletek végrehajtó rutinja
  2.  
  3. lde43:  CALL    LDF50           ;várakozási értékek beállítása
  4.         OUT     (C),A           ;12 (13);WD Command kiirása
  5.         SET     3,C             ; 8 ( 9);EXDOS Status register
  6. lde4a:  JR      LDE4C           ;12 (13);várakozás
  7. lde4c:  LD      A,00H           ; 7 ( 8);várakozás
  8.         IN      A,(C)           ;12 (13);EXDOS Status olvasása
  9.         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:
Code: ZiLOG Z80 Assembler
  1. .   E05E  CD 6F E1     CALL  E16F ;várakozási értékek beállítása
  2. .   E061  ED 79        OUT   (C), A    ;12 (13);WD Command kiirása
  3. .   E063  CB D9        SET   3, C      ; 8 ( 9);EXDOS Status register
  4. .   E065  3E 06        LD    A, 06     ; 7 ( 8)
  5. .   E067  3D           DEC   A         ; 4 ( 5)
  6. .   E068  20 FD        JR    NZ, E067  ;12 (13), 7 ( 8) ha Z
  7. .   E06A  ED 78        IN    A, (C)    ;12 (13);EXDOS Status olvasása
  8. .   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.
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.17. 11:08:31
EXDOS 2.0 várakozási ciklus átszámolva Z180-ra:
Code: ZiLOG Z80 Assembler
  1. .   E05E  CD 6F E1     CALL  E16F ;várakozási értékek beállítása
  2. .   E061  ED 79        OUT   (C), A    ;10 ;WD Command kiirása
  3. .   E063  CB D9        SET   3, C      ; 7 ;EXDOS Status register
  4. .   E065  3E 06        LD    A, 06     ; 6
  5. .   E067  3D           DEC   A         ; 4
  6. .   E068  20 FD        JR    NZ, E067  ; 8, 6 ha Z
  7. .   E06A  ED 78        IN    A, (C)    ;10 ;EXDOS Status olvasása
  8. .   E06C  FA 7F E0     JP    M, E07F   ; 9 ;ugrás, ha DRQ aktív

Ez így már csak 83 órajel, ha pedig figyelembe vesszük az órajel növekedést is, átszámolva 55.3 4 Mhz-es órajel marad, ami már nem sokkal több mint az 1.x EXDOS-ban alkalmazott 30 órajel.
Vagyis 6 Mhz-es Super Z80-at (alias Z180) feltételezve teljesen érthetõ az EXDOS 2.0-ban található módosítás!
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.31. 00:39:25
Van egy probléma, amit a Z180 kapásból megoldana  :)
De hátha ügyes bitfaragóknak (fõleg Istvánban reménykedek  :oops: ) 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:

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


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


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  :cry:

Van valakinek ötlete, mit lehetne még faragni ezen? Az se baj, ha nem fér be az eredeti helyére.
Title: Re: EXDOS
Post by: geco on 2011.December.31. 02:58:51

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


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

Ha egy adott helyen a C értéke állandó, akkor érdemes lenne lecserélni az OUT (C),A-kat, és IN A,(C)-ket OUT (nn),A-ra, és IN A,(nn)-re, így a SET 3,C-t is ki lehetne dobni, és ezek egy picit gyorsabbak is, ha nem állandó, akkor ötlet stornó.
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.31. 04:02:14
Ha egy adott helyen a C értéke állandó, akkor érdemes lenne lecserélni az OUT (C),A-kat, és IN A,(C)-ket OUT (nn),A-ra, és IN A,(nn)-re, így a SET 3,C-t is ki lehetne dobni, és ezek egy picit gyorsabbak is
Ez igaz, viszont az IN A,(C) az állítja a flageket, így közvetlenül alkalmas a DRQ vizsgálatára.
Title: Re: EXDOS
Post by: IstvanV on 2011.December.31. 10:52:59
A B regisztert el lehet rontani (PUSH BC-vel biztosan :)) ? Így az LD E, 82H elkerülhető lenne az első DRQ feldolgozásakor (helyette a B-ben lehetne a 82H már előre beállítva).

A JP Z,0DEE3h helyett is lehetne JR, mert az gyorsabb, ha a számláló nem fut le (és erre az esetre kell optimalizálni). Igaz, a cím túl messze van (de csak néhány byte-al :evil:), de ha sikerül helyet találni egy JP-nek, akkor arra lehetne ugrani JR-el.

Még egy lehetőség: a második IN A, (C) helyett IN F, (C), és akkor az LD A, D áthelyezhető az IN elé. Ennek az az értelme, hogy rövidül a második és a harmadik IN közötti hosszú várakozás (akkor a legvalószínűbb az első DRQ elvesztése).
Title: Re: EXDOS
Post by: Zozosoft on 2011.December.31. 11:26:41
A B regisztert el lehet rontani (PUSH BC-vel biztosan :)) ?
B-ben van a szektorszámláló, így kell PUSH.

Quote
A JP Z,0DEE3h helyett is lehetne JR, mert az gyorsabb, ha a számláló nem fut le (és erre az esetre kell optimalizálni). Igaz, a cím túl messze van (de csak néhány byte-al :evil:), de ha sikerül helyet találni egy JP-nek, akkor arra lehetne ugrani JR-el.
É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  :oops: ) Addig is ideiglenesen mehet a ROM végén üres részbe az újrafordított rutin.


Quote
Még egy lehetõség: a második IN A, (C) helyett IN F, (C), és akkor az LD A, D áthelyezhetõ az IN elé. Ennek az az értelme, hogy rövidül a második és a harmadik IN közötti hosszú várakozás (akkor a legvalószínûbb az elsõ DRQ elvesztése).
Ez is jó ötlet, köszi!
Title: Re: EXDOS
Post by: Zozosoft on 2012.April.05. 15:46:15
Nem tudom, ide tartozik-e, de az EXDOS 1.3 miben más, mint az EXDOS 1.0?
Ez még megfejtendõ kérdés  :oops: amire majd a teljes visszafejtés elkészültével lesz válasz.
Haluska Laci írta a Fish cikkben, hogy van ami nem, vagy nem úgy mûködik az 1.0-ban.
Title: Re: EXDOS
Post by: szipucsu on 2012.April.05. 20:10:21
Ez még megfejtendõ kérdés
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.
Title: Re: EXDOS
Post by: Zozosoft on 2012.April.11. 19:35:56
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.
Gyárilag az is csak az A-n nézi, de készült módosítás, hogy EBA sorrendben nézze. Zozotoolsban is van ilyen funkció.
Title: Re: EXDOS
Post by: Zozosoft on 2012.April.11. 20:29:03
Akkor a nagyobb méretû lemezre is lehet valami trükkel akár 400 KB-ot is írni?
(Nagyobb méretû, azt hiszem, az 5,25-ös, kisebb méretû a 3,5-ös? Már régen használtam ezeket az elnevezéseket.)
És hogyan lehet 360-nál nagyobbra formázni? Ha jól emlékszem, a Zozotoolsban van ilyen lehetõség, meg valami FAFO-ról hallottam még, de az EP-s idõkben ezek nem voltak meg nekem.
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  :cry:

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.
Title: Re: EXDOS
Post by: Ep128 on 2012.April.14. 14:59:03
Még mindig mosolygok, mikor ilyesmiket olvasok... :-)
A 90% -át tudtam az Általad most leírtaknak, de akkor is jó érzés látni újra és újra, milyen jó a gépünk és a lemezkezelésünk (Neked hála)! :D
Title: Re: EXDOS
Post by: Zozosoft on 2012.April.30. 14:12:12
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.)
Title: Re: EXDOS
Post by: Lacika on 2012.May.16. 08:15:41
Most vettem csak észre, hogy az 1.3-as EXDOS-ok help-jében van egy gépelési hiba:
"Commands avaliable:"
Title: Re: EXDOS
Post by: Zozosoft on 2012.May.16. 09:01:24
Most vettem csak észre, hogy az 1.3-as EXDOS-ok help-jében van egy gépelési hiba:
"Commands avaliable:"
Következõ verzióban javítjuk  :ds_icon_cheesygrin:
1.3-asokat amúgy is át akarom variálni, hogy a hibaüzenetek ne a második szegmens elején legyenek, plusz az IS-DOS-t EPCompressel berakni, és az így felszabadult helyre lehetne más ROM-ot berakni, hátha pl. az IDE ROM beférne. Ez jól jönne a "csak IDE kártya, EXDOS a cartridge-ban" konfigokhoz.
Title: Re: EXDOS
Post by: Lacika on 2012.May.16. 10:10:10
Ha engem kérdezel, a FILE kellene bele, legyen "ipari szabvány".
Csak a verziószám legyen más, mert az EXDOS-nál már hatalmas kavarodás van. 1.3-asból van az eredeti, "11 sector version", Turbo ("22 sector version), BIG ramdisk, meg még ki tudja micsoda...  :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2012.May.16. 10:20:35
A BIG RAMDISK az aktuális használandó, a többi az történelmi érdekesség :-) (A turbo az külön ügy)
Title: Re: EXDOS
Post by: Zozosoft on 2013.November.21. 10:15:35
Povi! Ezt a bugot emlegettem neked a találkozón. (http://enterpriseforever.com/programozas/exdos-283/msg24383/#msg24383)
(Feljebb leírtam a miértjét is.)
Title: Re: EXDOS
Post by: Povi on 2014.January.09. 11:02:15
hogyan lehet megnézni fájl írásakor, hogy van-e már olyan nevű fájlunk? (nem akarom fölülírni)
próbáltam exos 2-vel, hogy ad-e hibaüzenetet, ha már létező fájlt akarok írásra nyitni, de nem (mondjuk az is igaz, hogy emulátoron, file: eszközzel próbáltam - lehet, hogy disk-re kellett volna próbálni?)
Title: Re: EXDOS
Post by: Zozosoft on 2014.January.09. 12:35:41
Megnyitod olvasásra, és sikerül-e?
Konkrétan EXDOS-on, pl kiadsz egy DIR-t a fájlnévre, és lesz-e fájl not found? (csak legyen a háttérben egy video lap, amire a dir írhat)
A tisztességes EXDOS megoldás, ha ugyanezt FISH hívásokkal csinálod meg.
Title: Re: EXDOS
Post by: szipucsu on 2014.January.09. 12:45:13
BASIC-ben én erre a WHEN EXCEPTION USE galiba jellegű megoldást használtam. Megpróbáltam megnyitni a fájlt OPEN-nel, és ha nem találta, akkor okozott hibát és akkor lehetett menteni (ezt kezelte a HANDLER eljárás). Ha megtalálta a fájlt, nem volt hiba, akkor kellett figyelmeztetni a felhasználót, hogy ne írja felül.
Title: Re: EXDOS
Post by: Povi on 2014.January.09. 13:14:45
Quote from: Zozosoft
Megnyitod olvasásra, és sikerül-e?
tényleg, ez jó módszernek tűnik :-)
Title: Re: EXDOS
Post by: Zozosoft on 2014.January.09. 14:17:45
Egyébként az EXOS 1-el megnyitottba is tudsz írni EXDOS-al (ahogy PC-n is az MS-DOS alatt), ilyenkor az elején áll a fájl mutató, innentől kezded felül írni. Ha hozzáfűzni szeretnél, akkor az EXOS 10-el a végére kell vinni a mutatót (vagy akár tetszőleges pontra).
EXOS 2-vel nyitáskor törlődik a régi tartalom.
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.09. 16:48:05
Úgy tűnik, hogy a több mint egy hetes SD kártya ügyi hibakeresés vége az, hogy az EXDOS-ban sikerült egy jó nagy bugot fogni!
Ez érinti az IDE-s konfigokat is, lehetséges, hogy Moldaninak is ettől lett partició összeomlása :oops:
És aminek Lacika nagyon fog örülni: a programos VHD-t újra kéne csinálni, mert lehet, hogy vannak rajta sérült programok :oops: :oops: :oops: 

Majd meg kell nézni az EPDOS 1.9 bétát is, hátha csökkenek a kijavítandó hibák is :-)
Title: Re: EXDOS
Post by: Z80System on 2014.April.09. 17:09:11
Quote
Úgy tűnik, hogy a több mint egy hetes SD kártya ügyi hibakeresés vége az, hogy az EXDOS-ban sikerült egy jó nagy bugot fogni!
Gratula! :smt023

( 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 ... meg ilyenek ... engem érdekelne. )
Title: Re: EXDOS
Post by: Lacika on 2014.April.09. 18:31:20
Quote from: Zozosoft
Úgy tűnik, hogy a több mint egy hetes SD kártya ügyi hibakeresés vége az, hogy az EXDOS-ban sikerült egy jó nagy bugot fogni!
Részletek mikor lesznek? :oops:
Title: Re: EXDOS
Post by: lgb on 2014.April.09. 21:22:57
Engem is erdekelne, hatha tobb erdeklodo tobb reszletet fog jelenteni :D
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.09. 21:56:44
Jön majd mesedélután :-)
Title: Re: EXDOS
Post by: Ep128 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! :-)
Title: Re: EXDOS
Post by: Povi on 2014.April.10. 14:02:11
engem is érdekel! :-)
Title: Re: EXDOS
Post by: gflorez on 2014.April.10. 15:31:46
Y yo...(And I....)
Title: Re: EXDOS
Post by: Zozosoft 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. (http://ep128.hu/Ep_Konyv/Exdos_Muszaki_Leiras.htm#13), 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...
Title: Re: EXDOS
Post by: Lacika 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?
Title: Re: EXDOS
Post by: Zozosoft 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.
Title: Re: EXDOS
Post by: Z80System 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 ...
Title: Re: EXDOS
Post by: Lacika 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.
Title: Re: EXDOS
Post by: Z80System 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 ...
Title: Re: EXDOS
Post by: Zozosoft 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."
Title: Re: EXDOS
Post by: Zozosoft 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 :-)
Title: Re: EXDOS
Post by: Z80System 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 ?)
Title: Re: EXDOS
Post by: Z80System 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% ?
Title: Re: EXDOS
Post by: Zozosoft 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. (http://enterpriseforever.com/programozas/exdos-283/msg24203/#msg24203)
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.
Title: Re: EXDOS
Post by: Zozosoft 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 :-)
Title: Re: EXDOS
Post by: Z80System on 2014.April.12. 23:12:43
Na oks, akkor tehát egy EXDOS bugrol beszélünk (már hogy Zozo) és annak egy tulajdonságáról (hogy nem kell minden eszköz kezelő a rendszer szegmensen legyen kötelezően), ami egy ilyen flexibilitási jelenség/bug akkor, elvben megírták hogy ez így legyen, csak aztán valszeg az életben nem tesztelték, mert soha senki nem írt olyan eszköz meghajtót, ami ne akart volna a rendszer szegmensre beférni ?

Ergó a bug javítása nélkül is lehetne tökéletes IDE/SD meghajtót írni, ha nem érdekelne az bennünket hogy a rendszer szegmenst illegálisan használó programok nem futnak ?

És az hogy lehet hogy régen, mikor voltak azok a sok -sok mindenféle hardveres fejlesztések az EP -hez (egér, hardver óra, tudomisénmégmi), azok mind valahogy más interfészeken csatlakoztak, amikben nincs ez a bug ? Vagy azok is mind be akartak férni a rendszerszegmensre ? Vagy ez csak egy EXDOS bővítőknek dedikált bug, és semmi mást nem érint ?
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.12. 23:22:47
Quote from: Z80System
elvben megírták hogy ez így legyen, csak aztán valszeg az életben nem tesztelték, mert soha senki nem írt olyan eszköz meghajtót, ami ne akart volna a rendszer szegmensre beférni ?
Így van.

Quote
Ergó a bug javítása nélkül is lehetne tökéletes IDE/SD meghajtót írni, ha nem érdekelne az bennünket hogy a rendszer szegmenst illegálisan használó programok nem futnak ?
Igen. Majd bele is kell tenni ezekbe, hogy vizsgálja meg, hogy hiba javított-e az EXDOS (legegyszerűbb lesz, ha azt majd 1.4-nek nevezzük el), és ha nem, akkor rendszerszegmenses módon működjenek.

Quote
Vagy ez csak egy EXDOS bővítőknek dedikált bug, és semmi mást nem érint ?
Így van.
Title: Re: EXDOS
Post by: Povi on 2014.April.13. 08:54:47
Úgy gondolnám, hogy az EXOS / EXDOS nem is annyira komplex rendszer (oké, 8 bites környezetben talán ez a legösszetettebb), és mégis mennyi mindenre kell figyelni. Ezek után nem csoda, hogy pl. a Windows évekig mennyire instabil volt (kék halál és társai), ami nagyságrendekkel bonyolultabb, mint egy EXOS. És ezek után azt is el tudom képzelni, ennek analógiájára, hogy nem a Windows volt rosszul megírva, ha nem a hozzá írt alkalmazások / meghajtók kezelték illegálisan a függvényeket stb. Mint ahogy a fix memórialapozással operáló Spectrum átiratok esetében sem az EXOS hibája, ha összeomlik a rendszer... :-)

Az is lehet, ha meglenne a hiányzó EXDOS bővítő leírás, abban le lenne írva, hogy csak rendszerszegmenst használhatja az EXDOS-bővítő :-)
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.13. 19:26:13
Meg van egész konkrétan a hiba:
Amikor FAT szektorokat kezel, akkor a meghajtó adat területről átmásol adatokat az adott szektort tartalmazó szektorpuffer fejlécébe, többek között a FAT méretét, és a hozzá tartozó meghajtó kezelőprogramjának címét (szegmens, cím).
A szektorpufferek csak a rendszerszegmensben lehetnek.

Amikor meghajtó műveletre kerül sor, akkor az 1-es lapon a kezelőprogram szegmense van, C-ben a transzferszegmens száma, IX-ben az 1-es lapos transzfercím. Az EXDOS lapozórutinja (ami a rendszerszegmensben van), lapozza át az 1-es lapról a 3-asra a kezelőprogram szegmensét, és az 1-esre a transzferszegmenst.

A CA5Dh (1.3-ban) kezdődő rutin kiveszi a szektorpuffer fejlécéből a tárolt adatokat, belapozza a kezelőprogram szegmensét a híváshoz, és a puffercímét 1-es lapra konvertálja.
A bug a hívás után jön: CA8Ah-tól kezdődő rutinban IX-et használva címzi a szektorpuffer fejlécét, pl. a FAT méretet használja, hogy az adott FAT szektor címét kiszámolja a következő FAT példányban.
Viszont az IX az 1-es lapra van konvertálva, így ha kezelőprogram nem a rendszerszegmensben van, akkor más szegmens van az 1-es lapon, és jön az, hogy téves adatokat olvas!

A helyes megoldás, hogy vissza kell konvertálni az IX-et a 2-es lapra, majd az ismételt hívás (következő FAT példány) előtt újra 1-es lapra konvertálni. Töprengek rajta de ez az eredeti helyére nem fog beleférni... így csak az 1.3-ban lehet kijavítani, abban van szabad hely. Lesz belőle 1.4, így akkor a bővítő programok tudják ellenőrizni, hogy hibajavított-e az EXDOS.
Title: Re: EXDOS
Post by: geco on 2014.April.13. 19:35:34
:smt041
Title: Re: EXDOS
Post by: Ep128 on 2014.April.14. 00:49:20
Grat! :-)
Title: Re: EXDOS
Post by: Lacika on 2014.April.14. 17:46:38
Wow! És ha új verzió lesz, akkor standard lesz benne a FILE-bővítés az újratömörített ISDOS mellett? :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.14. 18:49:48
Quote from: Lacika
Wow! És ha új verzió lesz, akkor standard lesz benne a FILE-bővítés az újratömörített ISDOS mellett? :oops:
Toronyóra lánccal, nem kéne? :twisted: Miért pont az EXDOS-ban?
Majd meglátjuk, az elsődleges prioritás az lesz, hogy a TVC-sek által csinált FAT16 dolgot belebütykölni az EXDOS-ba.
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.21. 11:28:42
Az általunk ismert legrégebbi verzió a 0.3-as, ami csak 2006-ban került elő:
http://enterpriseforever.com/userpix/12_exdos03_1.png (http://enterpriseforever.com/userpix/12_exdos03_1.png)

Az első kiadott verzió az 1.0, ami a gyári EXDOS kártyákon volt.
http://enterpriseforever.com/userpix/12_exdos10_1.png (http://enterpriseforever.com/userpix/12_exdos10_1.png)

A kód növekedése miatt több parancs is ki lett véve, többségük az ISDOS-ban lett elérhető: ATTR, EXIT, ATDIR, ASSIGN, BUFFERS, MAPDISK. Ezt már korábban is tudtuk, most felfedeztem, hogy volt még egy speciális rendszerparancs is: "EXDOS",0FEH, ami bővítő meghajtó rendszerbecsatolására való, a korábban már beazonosított FISH 24-es hívás használatával.

A következő verzió volt az 1.2 (szintén 2006-ban került elő), ami az 1.0 továbbfejlesztett, javított verziója, de nem került kiadásra, valószínűleg az angol cég összeomlása miatt. Azonban ez a kód került a németekhez, amit forrás szöveg szintjén módosítottak, gyakorlatilag minden szövegkiíró rutinba beletettek egy elágazást: lekérdezi a 144-es EXOS változót, és ettől függően veszi az angol vagy a német szöveget. Az eredeti angol tömörített szövegrendszert kidobták, és a második szegmensre rakták szimpla szövegként az angol és német szövegtáblákat. Billentyűfigyelésnél (Retry,stb) szintén beletették ezt a 144-es változó lekérdezős elágazást.
Őszintén szólva meglehetősen primitív programozással oldották meg, pl a sok 144-es változó lekérdezést ki lehetet volna rakni egy szubrutinba, és CALL-al hívogatni ahonnan kell, sok bájtot megtakarítva. És csak az egészen kezdő programozó használnak különálló LD B,n LD C,n utasításokat az egy bájttal rövidebb LD BC,nn helyett :twisted:

Ez a kétnyelvű, 1.3-as verzió került a német EXDOS-al egybeépített floppy meghajtókba. A sok plusz szöveg miatt a ROM mérete immár 32K, rengeteg kihasználatlan hellyel. A parancskészlet az 1.0-hoz képest változatlan.
http://enterpriseforever.com/userpix/12_exdos13_1.png (http://enterpriseforever.com/userpix/12_exdos13_1.png)

Ezután jön az általunk leginkább ismert angol-magyar verzió:
Az az egyszerűbb része, hogy a német szövegek magyarra lettek cserélve. Sokkal izgalmasabb, hogy 4 korábban kivett parancs visszakerült: ATTR, ATDIR, ASSIGN, MAPDISK
http://enterpriseforever.com/userpix/12_exdos13h_1.png (http://enterpriseforever.com/userpix/12_exdos13h_1.png)

Régen, mivel akkor még nem tudtam, hogy ezek valaha bent voltak az EXDOS-ban, azt hittem, hogy az ISDOS-ból lettek kiszedve, és berakva az EXDOS ROM-ba. Sőt egészen mostanáig ebben a hitben voltam!
A módosítások binárisan történtek az 1.3-on, a plusz parancsok miatt hosszabb parancstábla átkerült a ROM végére, és az eredeti parancstábla helyére kerültek a végrehajtó kódok, ill. a kód egy része a második szegmensre került.

Most az 1.4 miatt elkezdtem gatyába rázni az 1.3-ra rakodott plusz módosításokat, egyrészt, hogy ne szétszórva legyenek, hanem egy tömbben, hogy a szabad hely egyben legyen, ami kelleni fog majd a FAT16 mókához. Másrészt kell fordítható áthelyezhető módon, hogy az SD cartridge memóriakonfigurációjához is hozzá legyen szabva.

Szóval visszafordítottam ezeket plusz parancsokat is kiderült, hogy semmi közük az ISDOS-hoz, annál inkább hasonlítanak a 0.3-ban lévőkhüz, bár nem azonosak. A fő lényeg, hogy rengeteg belső EXDOS szubrutint használnak, a parancsszöveg feldolgozáshoz (paraméterek kielemzése, számparaméter konvertálása, stb), ill. szövegkiíráshoz is.
Ezt így csak az tudta megcsinálni, aki rendelkezett legalább egy EXDOS forrásszöveggel! Vélhetőleg valamely 0.x verzióval, amiben benne voltak ezek a parancsok. Gondolom, ha lett volna 1.3 forrása, akkor nem bináris piszkálással kerültek volna be. De ha már ismert egy verziót, akkor az alapján meg lehetett keresni az ugyanolyan feldolgozó rutinokat az 1.3-ban, és átültetni a parancsokat.

A nagy kérdés, hogy ki lehet az, akinek ilyen információk voltak a keze ügyében? Én csak Kopácsyékra tudok tippelni.

Az 1.4-be most visszakerült minden ami a 0.3-ban benne volt (utálom ha valami régen tudott valamit, aztán meg már nem :twisted: ), vagyis az EXIT, BUFFERS és az "EXDOS",0FEh (ez utóbbi lehetőség a korábbi verziókban a bug miatt amúgy is hibásan működött volna). Mindez fordítható, "defregmentált" kódként, ami a további fejlesztéshez elengedhetetlen.

Következő cél a szövegrendszer: sajnos a magyar EP-sítés eléggé össze lett kavarva sokféle nem kompatibilis karakterkészletekkel :cry:  Az a tervem, hogy a szövegek HFONT-os ként lesznek tárolva (itt meg van minden ékezet), kiíráskor mintát vesz a karakterkészletből, hogy eldöntse melyik aktív, és ennek megfelelően konvertálja a karaktereket.
Title: Re: EXDOS
Post by: geco on 2014.April.21. 11:39:14
Quote from: Zozosoft
Őszintén szólva meglehetősen primitív programozással oldották meg, pl a sok 144-es változó lekérdezést ki lehetet volna rakni egy szubrutinba, és CALL-al hívogatni ahonnan kell, sok bájtot megtakarítva. És csak az egészen kezdő programozó használnak különálló LD B,n LD C,n utasításokat az egy bájttal rövidebb LD BC,nn helyett :twisted:

A nagy kérdés, hogy ki lehet az, akinek ilyen információk voltak a keze ügyében? Én csak Kopácsyékra tudok tippelni.
Tuti azért, hogy minél jobb legyen a 2. szegmens kihasználtsága :ds_icon_cheesygrin:
Szerintem is, ő tartott minden szálat a kezében EP ügyben, nem?
Title: Re: EXDOS
Post by: Ep128 on 2014.April.22. 00:24:53
Nagyon komoly és nagyon jól hangzik amiket leírtál Zozo, köszi! :)
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.22. 11:37:36
Én sose voltam megbékélve az EXDOS ablak lila színével, most megkérdeztem Bruce-t, azt mondta, hogy ~30 év után ő is meglepődött, amikor először látta, hogy ez lila :-)

Kipróbáltam sötét zölddel, nekem így jobban tetszik :-) talán a betűket vegyük világosabb sárgára, esetleg fehérre?
[attach=1]
Title: Re: EXDOS
Post by: szipucsu on 2014.April.22. 13:59:53
Quote from: Zozosoft
talán a betűket vegyük világosabb sárgára, esetleg fehérre?
Kicsit szerintem lehetnének világosabbak a betűk, bár ez se rossz.
Title: Re: EXDOS
Post by: Lacika on 2014.April.22. 19:29:14
Én a kékre szavazok, de az eredetivel sincs semmi bajom, az is majdnem kék... :oops:
Title: Re: EXDOS
Post by: Zozosoft on 2014.April.22. 20:17:21
Quote from: Lacika
Én a kékre szavazok, de az eredetivel sincs semmi bajom, az is majdnem kék... :oops:
A kék az nagyon PC-s, én már a kék halál feltalálása előtt is meggyűlöltem :twisted: Norton, Borland, DOS Edit, stb... tök jó volt, amikor a 6.0-ás Turbo Pascal-ban már be lehetett állítani, egyből visszatértem a fekete alapon zöld betűkhöz :-) DOS Navigatorból is hál istennek el lehetett tüntetni a Nortonos kékséget.

Beleteszem majd fordítási opciókba a színt, és majd mindenki olyan színűt tud fordítani magának, amilyet csak akar! :-D
Title: Re: EXDOS
Post by: Trefe on 2014.April.22. 21:41:20
Nekem speciel jobban bejön a zöld-sárga. És tetszik az 54K-s Command.com is...:lol:
Title: Re: EXDOS
Post by: lgb on 2014.April.22. 22:15:46
Lassan lesz configolhato theme/skin is? :D
Title: Re: EXDOS
Post by: Ep128 on 2014.April.23. 00:23:14
Quote from: Zozosoft
Én sose voltam megbékélve az EXDOS ablak lila színével, most megkérdeztem Bruce-t, azt mondta, hogy ~30 év után ő is meglepődött, amikor először látta, hogy ez lila :-)

Kipróbáltam sötét zölddel, nekem így jobban tetszik :-) talán a betűket vegyük világosabb sárgára, esetleg fehérre?
(Attachment)
Szerintem az "Ep -zésben megfáradt szemnek" jobb ez így, ne vegyük világosabbra a betűket! Ez így nagyon kulturált, emberbaráti és szimpatikus! :-)
Title: Re: EXDOS
Post by: Z80System on 2014.April.23. 10:29:23
En valahogy ugy gondolkodnek a szinrol ... hogy az olyan eredeti ... mert ugye lila ... nem kek ...

De az is igaz, hogy en 3X latom egy evben, szoval nem hinnem hogy az igenyeim sokat kene nyomjanak a lattban ...
Title: Re: EXDOS
Post by: Moldani on 2014.April.26. 22:14:10
Quote from: Zozosoft

Kipróbáltam sötét zölddel, nekem így jobban tetszik :-)
(Attachment)
Ez a zöld szín szép és nagyon nyugtató lenne.... :)
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 17:14:35
Tesztelhető a magyar, HFONT-os verzió (Snapshotban csak F1-et nyomni a hibaüzenetek listázásához).
Mivel már nem kell fix helyen nyomorogni az üzenetekkel, a meglévőeket is átszabtam. Az eredeti HFONT-osításkor csomó hosszú ékezetes karakter kimaradt ezeket javítottam. Nézzétek át, mit nem vettem észre :oops:
Title: Re: EXDOS
Post by: Lacika on 2014.May.04. 17:21:04
A "formálatlan lemez" szerintem nem túl szerencsés, a "formázatlan" értelmesebbnek tűik.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 17:23:50
Quote from: Lacika
A "formálatlan lemez" szerintem nem túl szerencsés, a "formázatlan" értelmesebbnek tűik.
Ok. (Az még az eredeti magyarításból maradt :-) )
Gondolkozok még azon is, hogy egy rakás Érvénytelen lehetne inkább Hibás...
Title: Re: EXDOS
Post by: Lacika on 2014.May.04. 17:27:03
Ha meghívod a "magyar" EXDOS ablakot, a státusz-sor felirata túl rövid, nem írja felül a BASIC statusz-sor utolsó karakterét.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 17:33:25
Quote from: Lacika
Ha meghívod a "magyar" EXDOS ablakot, a státusz-sor felirata túl rövid, nem írja felül a BASIC statusz-sor utolsó karakterét.
Ez is még az eredeti HUN EXDOS-ból jött, ahhoz, hogy a hosszabb szövegek elférjenek, innen kivettek egy csomó szóközt.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 11:45:42
Röviden amit az angolba írtam:
A START parancs azért nem működik EP64-en, mert az EXOS 2.0 elfelejti átadni az alapértelmezett 0 egységszámot a DISK perifériának, amikor teljesen üres fájlnevet használunk, azaz LOAD "" vagy a START parancs. Regiszterszemét kerül át, ami mindig 5, ezért hiszi azt, hogy az E: meghajtóról akarunk tölteni.

Lehetséges lenne egy kerülő utat építeni a DISK perifériába:
Ha az egységszám=5 és a fájlnév="" és EXOS verzió=2.0 akkor 0-ás egységszám legyen használva.
Ezzel működőképessé válna a START EP64-en, viszont lenne egy újabb bug, a LOAD "DISK5:" nem az E-ről töltené a START-ot, hanem az alapértelmezett meghajtóról :oops: de csak EXOS 2.0 estén.
Viszont biztos vagyok benne, hogy még soha senki nem írt be ilyet, hogy LOAD "DISK5:" :)
A LOAD "E:" az működne hibátlanul, valamint a LOAD "DISK5:fájlnév" esetén sincs gond.

Szerintem ez egy elfogadható kompromisszum lenne, az EP64-en is működő START sokkal fontosabb lenne.

Legyen benne az EXDOS 1.4-ben?
Title: Re: EXDOS
Post by: Lacika on 2014.May.18. 13:35:03
Quote from: Zozosoft
Szerintem ez egy elfogadható kompromisszum lenne, az EP64-en is működő START sokkal fontosabb lenne.

Legyen benne az EXDOS 1.4-ben?
Szerintem ne. Ne a régebbi verzióhoz igazodjunk.
Vagy akkor külön verzió Ep64-hez?
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 14:02:43
Nem lesz külön verzió, de a változás csak akkor jelentkezik, ha EXOS 2.0 van a gépben. Tehát EP128-on semmit nem jelent.

Engem baromira idegesít, hogy akárhányszor EP64-ezek mindig többször sikerül belefutni, hogy F1 megnyom, és kiköpi, hogy No RAM disk...
Title: Re: EXDOS
Post by: geco on 2014.May.18. 14:32:50
Quote from: Zozosoft
Nem lesz külön verzió, de a változás csak akkor jelentkezik, ha EXOS 2.0 van a gépben. Tehát EP128-on semmit nem jelent.

Engem baromira idegesít, hogy akárhányszor EP64-ezek mindig többször sikerül belefutni, hogy F1 megnyom, és kiköpi, hogy No RAM disk...
Egyetértek, először néztem is nagyokat, milyen gombot nyomhattam meg, aztán kiderült, hogy pont azt, amit akartam :lol:
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 19:34:03
Már működik :-)
C778h-n kezdődő rutin elejére kellett ezt beszúrni:
Code: ZiLOG Z80 Assembler
  1. LC778:  LD A,(0B21CH)
  2.                 CP 0B2H
  3.                 JR Z,C778END    ;EXOS 2.1+
  4.                 LD A,(DE)
  5.                 OR A
  6.                 JR NZ,C778END   ;NEM NULL FÁJLNÉV
  7.                 LD A,C
  8.                 CP 5
  9.                 JR NZ,C778END   ;NEM DISK5
  10.                 LD C,0                  ;0 EGYSÉGSZÁM
  11. C778END
Title: Re: EXDOS
Post by: geco on 2014.May.18. 19:53:30
Quote from: Zozosoft
Már működik :-)
:smt041 :smt041 :smt041
Title: Re: EXDOS
Post by: Lacika on 2014.May.18. 21:00:43
Erről jut eszembe: azt a START (file-kiválasztó) programot, ami nálam a disk-image-eken van, valaki megcsinálná, hogy Ep64-en is működjön?
Title: Re: EXDOS
Post by: szipucsu on 2014.May.18. 21:25:20
Quote from: Lacika
Erről jut eszembe: azt a START (file-kiválasztó) programot, ami nálam a disk-image-eken van, valaki megcsinálná, hogy Ep64-en is működjön?
Erről jut eszembe: A disk image-eket frissíteni kéne. A webes emuval több olyan programba botlottam bele, ami azóta javítva lett. Pl. a Hungry Creature. Meg más is, de már nem tudom, mik voltak.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 22:38:06
Bekerült a tömörített ISDOS is a ROMba, tesztelni kéne pár programmal, nekem jónak tűnik.
Kérdés: a gyors videó kezelő be legyen kapcsolva alapértelmezésben?
Title: Re: EXDOS
Post by: Lacika on 2014.May.18. 22:44:13
Quote from: Zozosoft
Kérdés: a gyors videó kezelő be legyen kapcsolva alapértelmezésben?
Igen.
Title: Re: EXDOS
Post by: Lacika on 2014.May.18. 23:06:16
Ha HDD-ről akarok törölni, még mindíg DATA ERROR üzenet lesz belőle, ezek szerint ez a javított bugtól független (vélhetően EPDOS) hiba?
Ebben a FAT16 benne van? Azt hogyan formázhatunk?
Title: Re: EXDOS
Post by: Lacika on 2014.May.18. 23:07:45
Az ISDOS nincs benne a HELP listában. Direkt? Eddig benne volt.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 23:12:04
Quote from: Lacika
(vélhetően EPDOS) hiba?
Valószínű :oops:

Quote
Ebben a FAT16 benne van? Azt hogyan formázhatunk?
Attól még messze vagyunk, majd az lesz az 1.6 verzió :-)
Egyelőre az ismert hibák kijavítása zajlik, meg minél több dolog átpakolása a második szegmensre, hogy legyen hova berakni a FAT16 dolgokat.
Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 23:13:28
Quote from: Lacika
Az ISDOS nincs benne a HELP listában. Direkt? Eddig benne volt.
Majd lesz, csak majd itt más HELP rutin kell, ott az ISDOS kódban lévő szöveg volt felhasználva, de az itt tömörítve van, külön kell berakni.
Title: Re: EXDOS
Post by: Zozosoft on 2014.June.01. 22:01:46
Elvileg kész az egységes magyar EXDOS.
A HFONT-osan tárolt ékezetes karakterek kiíráskor konvertálódnak az aktuális karakterkészletnek megfelelően, így nem lesznek mindenféle csúnya krikszkrakszok. UK, BRD, HUN és EP PLUS HUN karakterkészleteket kezel, kihasználva a fellelhető ékezetes karaktereket (hiszen még az UK-ban is van egy csomó!). Ahol nincs hosszú ékezet ott rövid van használva, pl ő helyett ö, ha rövid sincs akkor lesz éktelen. Ismeretlen karakterkészlet esetén az összes ékezetes karakter éktelen lesz.

A kétnyelvű EXDOS ha nincs nyelvi bővítő ROM, akkor saját maga létrehozza a 144-es nyelvi EXOS változót, ezt alapból 255-re azaz angolra állítja. De mivel már nincs kriksz-kraksz veszély, lehetne 0-ra állítani, engedélyezve a magyar nyelvet. Ez a mellékelt ROM ilyen.

A dolog több helyen szívatós volt, pl a PLUS-nál 0 (BRD), 1 (UK), 2 (HUN) a nyelvek számozása, el kellet érni, hogy a HUN-t is nullának lássa :-)
Szintén a PLUS miatt a © karaktert is konvertálni kellett, viszont a © 1985 Intelligent... üzenet nem a normál szövegkiíró rutinon ment keresztül (ahova bekerült a konvertálás), hanem direkt EXOS 8-al.
A szövegtáblában volt egy nem használt Copyright Intelligent... üzenet,  idekerült át ez, és a HELP rutin módosítva, hogy a szövegtáblából kérje ezt a sort.
Szintén a szövegtáblába került be az ISDOS HELP sora, az első szegmensből kikerült © 1985... szöveghelye lett felhasználva az általános HELP kiíró rutin megbütyköléséhez :-)
Az EXDOS ablak státusz sorába írt "parancsértelmező" volt a következő probléma, mivel ez közvetlen videó memóriába megy, így a HFONT-os karakterek 128-al kisebb kóddal szerepelnek. A különböző készletekben meg vegyesen hol 128 alatti hol feletti karakterek lennének, azaz össze-vissza hol piros hol kék...
Mivel a szöveg kikérése az általános rutinon keresztül megy, így akkor rendes kódú HFONT-os karakterek lettek bele, amik szépen konvertálódnak.
A másoló LDIR lett lecserélve egy másoló ciklusra, ami közben törli a 7. bitet, így biztosítja az egyforma színt. Ez a ciklus szintén a korábban említett felszabadult helyre került.

Utolsó problémának ott volt a magyarított ISDOS...
Majd ha egyszer vissza lesz fejtve, akkor abba is lehet tenni ilyen kiírás közben konvertálást :oops:
Most az a megoldás lett, hogy indításkor lesznek az éppen aktuális karakterkészletnek megfelelőre konvertálva az ékezetes karakterek.
Bonyolított a helyzetet, hogy az ISDOS CRC-ket számol a programterületeire, így ezeket is ki kellett számolni mindegyik variációhoz, és egy táblázatból az éppen aktuális értékeket bemásolni.

Ha valakit érdekel, akkor majd berakhatom a karakterkészlet felismerő és konvertáló rutint...
Title: Re: EXDOS
Post by: Lacika on 2014.June.01. 22:18:26
Quote from: Zozosoft
Elvileg kész az egységes magyar EXDOS.
Arról lesz majd lista, mi változott az új EXDOS-ban?
Title: Re: EXDOS
Post by: Lacika on 2014.June.01. 22:24:59
Zozo, azt majd megnéznéd, hogy ami nálam kint van csomag (http://www.ep128.hu/Ep_Util/Prg/Exdos.rar), abban mit kellene megtartani, mit nem, mert elég nagy már a kavar benne.
Title: Re: EXDOS
Post by: szalai56 on 2014.June.01. 23:25:24
Quote from: Zozosoft
Elvileg kész az egységes magyar EXDOS. ......


Ezt berakhatom az exdos kártyámba? (nem csak 16 kb-s lehet?)
Title: Re: EXDOS
Post by: Zozosoft on 2014.June.01. 23:38:15
Quote from: szalai56
Ezt berakhatom az exdos kártyámba? (nem csak 16 kb-s lehet?)
Milyen, gyári? Azon is ott a jumper a 32K-s EPROM-hoz. Utángyártottak szerintem mind eleve 32K-shoz készültek.
Beteheted, bár még nem végleges verzió.
Még 2 ismert bug javítása hátra van:
- WD nélkül lefagy, csak vinyó vagy SD rendszer esetén ez elég nagy baj :-)
- 1024 bájtos szektoroktól lefagy, mert túlcsordul az 512 bájtos puffer. Lemez azonosításnál előre kell venni a szektorazonosító ellenőrzést.

Második szegmenst még rendezni kell, hogy hátra legyen tolva minden, elől lehető legtöbb szabad hely legyen, egyéb programoknak. Lacika pl FILE bővítést szeretné :-)
Title: Re: EXDOS
Post by: Z80System on 2014.June.01. 23:43:20
Quote
 Lacika pl FILE bővítést szeretné (http://enterpriseforever.com/Smileys/phpbb/ds_icon_smile.gif)

FILE bővítés ELVBEN is csak emuban értelmes ? Vagy ELVBEN lehetne olyan hw -t csatlakoztatni az EP -hez, ami a FILE bővítést kiszolgálhatná ?
Title: Re: EXDOS
Post by: Zozosoft on 2014.June.02. 00:05:40
Quote from: Lacika
Arról lesz majd lista, mi változott az új EXDOS-ban?
Az utolsó magyar 1.3-hoz képest:
- szektorpuffer kezelési hiba külön szegmensben lévő meghajtó kezelők esetén javítva
- korábban emlegetett "kazetta CRC hiba" :lol: bug javítva
- a magyar verzióban korábban visszakerült parancsok mellé az EXIT, BUFFERS és az "EXDOS",0FEh is visszakerült, most még lett egy bónusz VER is :-)
- minden hibakódhoz tartozik hibaüzenet, főleg a nem angol hibaüzenetek szerkesztve, mivel már nem kellett méretkorlátokhoz igazodni.
- második szegmens elejére EXDOSROM szöveg került, így EXOS 2.3+ felismeri ha esetleg ROM szimulációban van használva. Ez cserélhető EXOS_ROM-ra, ha más programmal vonjuk össze.
- ez utóbbi lehetőséghez, minden kód és adat a második szegmensen fel lesz tolva, hogy maximális szabad hely maradjon elől
- szintén ezen lehetőség miatt opcionálisan fordítható be ISDOS a ROM-ba, ill. lehetséges csak angol verzió is, ahol a másodlagos nyelv sem foglalja a helyet.
- ISDOS m3-as Epcompress tömörítéssel kerül be
- a jövőbeli FAT16 módosításoknak helyet csinálandó az amúgy is módosított ISDOS töltő, és a szöveg kezelő rutinok teljes egészében átkerültek a második szegmensre. Ha kell még további dolgok is átmehetnek, pl a parancstáblázat és kezelője, LOAD, VAR, TIME, DATE, PAUSE...
Title: Re: EXDOS
Post by: Zozosoft on 2014.June.02. 00:06:57
Quote from: Z80System
FILE bővítés ELVBEN is csak emuban értelmes ? Vagy ELVBEN lehetne olyan hw -t csatlakoztatni az EP -hez, ami a FILE bővítést kiszolgálhatná ?
Erősen gyanítom, hogy kevered a :FILE-t a FILE:-vel :-)
Title: Re: EXDOS
Post by: Z80System on 2014.June.02. 00:09:40
Quote
Erősen gyanítom, hogy kevered a :FILE-t a FILE:-vel (http://enterpriseforever.com/Smileys/phpbb/ds_icon_smile.gif)
Ja, nem tudtam hogy :FILE is van ... :) (Az mi a rák egyébként?)
Title: Re: EXDOS
Post by: Zozosoft on 2014.June.02. 00:15:26
Quote from: Z80System
Ja, nem tudtam hogy :FILE is van ... :) (Az mi a rák egyébként?)
Ez. (http://ep128.hu/Ep_Util/Pack.htm) Számtalan program használja betöltendő fájl választásához.
Title: Re: EXDOS
Post by: szalai56 on 2014.June.03. 00:07:38
Akkor várok a véglegesre. Végül is sehová nem sietek.
Title: Re: EXDOS
Post by: Z80System on 2014.September.26. 00:16:04
Az mitől lehet, hogy a FILE bővítés nem listázza a ".." nevű könyvtárat, és így nem lehet felfele lépkedni a mappákban ?
Title: Re: EXDOS
Post by: Z80System on 2014.September.26. 00:31:40
Azért van, mert a ".." az hidden (legalábbis az én esetemben), és azokra külön kapcsoló van a FILE -ban.
Title: Re: EXDOS
Post by: Z80System on 2014.September.28. 03:04:15
Hogy tudok EXDOS -szal teljes könyvtárat átmásolni, rekurzívan ?

Hogy tudok EXDOS -szal letörölni readonly file -t ? (Vagy legalábbis nem töröl le egy file -t, aminek a neve után vany egy kis "r" karakter a mérete előtt.)
Title: Re: EXDOS
Post by: Zozosoft on 2014.October.15. 22:53:56
A már majdnem végleges EXDOS 1.4.
EXDOS.INI kezelés:
E-F-B-A meghajtókon keresi. Mivel előfordulhat, hogy valami hülyeséget sikerül beleírni a vinyó/SD EXDOS.INI-jébe ezért a Bal SHIFT nyomva tartásával át lehet ugorni az EXDOS.INI keresést (Hasonlóan, mint PC-n MSDOS 5.0-tól kezdve).
Alapértelmezésben egy EXDOS.INI-t hajt végre, tehát ha talál az F-n, akkor a floppyn már nem nézi. Ha a CTRL le volt nyomva a keresés kezdetén, akkor viszont nézi a következő meghajtón is, tehát pl egy F:EXDOS.INI után lefuthat az A:EXDOS.INI is (feltéve ha az elsőként lefutó nem veszi át végleg a vezérlést).
Az ALT segítségével pedig csak a floppykon lesz keresés (B-A), CTRL-el kombinálható :-)

Aktuális meghajtó: minden lehetséges EXDOS.INI kezdetén az azt tartalmazó maghajtó az aktuális.
Sikeresen lefutó EXDOS.INI után megjegyzi az aktuális meghajtót, és a végén az lesz az aktuális, ha több INI is lefut, az utolsó számít.
Ez azt jelenti, hogy ha az F-ről lefut, és utána nem talál a floppyn, akkor marad az F az aktuális. De ha az F-es INI átlép mondjuk a H-ra, akkor az lesz, ha nem volt több INI.
Ha nem volt egy INI se (vagy SHIFT-tel át lett lépve), akkor ha létezik az F, akkor az lesz a kezdő meghajtó, egyébként meg marad az A.
Title: Re: EXDOS
Post by: Z80System on 2014.October.15. 22:59:25
Hááát ... lehet ennek már olyan komplex az inicializálódása, mint egy linux boot script -nek ... :)
Title: Re: EXDOS
Post by: Zozosoft on 2014.October.15. 23:09:05
Hááát ... lehet ennek már olyan komplex az inicializálódása, mint egy linux boot script -nek ... :)
Ez az amit PC-n a BIOS-ban állítgatsz, hogy boot order... de nekünk nincs CMOS SETUP-unk.

De azért szerintem 3 gombot nem olyan nehéz megjegyezni, főleg, hogy a legfontosabbat (SHIFT) már vagy 20 éve megszoktuk PC-n :-)
Title: Re: EXDOS
Post by: Z80System on 2014.October.15. 23:12:14
Quote
De azért szerintem 3 gombot nem olyan nehéz megjegyezni, főleg, hogy a legfontosabbat (SHIFT) már vagy 20 éve megszoktuk PC-n :-)

Sosem használtam ... DOS -os időkben amigáztam ... onnan win95 ...

A leírt keresési logika felére kapcsiból nem tudom mikor jöhet jól ... :) De egyrészt majd rájövök, másrészt az sosem árt ha van ... akkor van gáz, ha valamit nem tud, ami kéne ...
Title: Re: EXDOS
Post by: Z80System on 2014.October.15. 23:55:43
Konkrét szitu:

Van az SD,

kis kártyán ott van az image, F,G,H,I,J,K -val, "nem" kiszedhető (csak ha kiszedem magát az SD nyákot is),

és van egy nagy kártya, könnyen cserélhető, van rajta minimum egy L partíció ...



Namost én beteszek az L -re egy "rendszert" EXDOS.INI -vel,

eddig áthekkeltem az A: -ot L:EXDOS.INI -re a ROM -ban, útmutatásaid alapján,
így mindíg az indult, ami a cserélhető SD kártyán volt ...



Az új EXDOS -szal ennek szimulációja az, hogy az F: -ra rendszeresítek egy EXDOS.INI -t,
melyben egy L:EXDOS.INI hívás van ?

És ennek az F:EXDOS.INI file -nak a változtatása egyenlő a korábbi ROM hekkelésemmel ?
Title: Re: EXDOS
Post by: Zozosoft on 2014.October.15. 23:58:53
Az új EXDOS -szal ennek szimulációja az, hogy az F: -ra rendszeresítek egy EXDOS.INI -t,
melyben egy L:EXDOS.INI hívás van ?

És ennek az F:EXDOS.INI file -nak a változtatása egyenlő a korábbi ROM hekkelésemmel ?
Igen. Csak itt több utasítást is beletehetsz, pl ASSIGN-olod az A-t az EGI-nek.
Title: Re: EXDOS
Post by: Z80System on 2014.October.16. 00:03:21
Quote
Igen. Csak itt több utasítást is beletehetsz,

Ja, ez király,

Quote
pl ASSIGN-olod az A-t az EGI-nek.

mondjuk ez pont nem jó példa, mert az assign -olás az már az EGI EXDOS.INI -jébe kell kerüljön,
mert a nagy kártyát (nálam H:) amin az EGI is lenne, azt cserélgetem,

a cserekártyán pld. egy ASMON -os fejlesztőkörnyezet, vagy akármi más lesz,
annak más EXDOS.INI -je lesz, és nem kell neki az assign ...
Title: Re: EXDOS
Post by: Z80System on 2014.October.16. 01:09:18
Na maga a működés (exdos, exdos.ini, assign) az jónak tűnik,

de úgy látszik nem lehet mindenkinek kedvezni egyszerre:

én szerettem az EXDOS színeit, és nagyon nem szeretem ezt a zöldet ... nem kaphatnánk egy offsetet, ahol át(vissza)hekkelhetjük magunknak a színeket ?

Esetleg jó lenne az eredeti színkombó lista is, hogy ne kelljen keresgetni őket ...
Title: Re: EXDOS
Post by: Z80System on 2014.October.16. 01:31:09
Második megközelítésben mégsem tűnik olyan jónak egy szempontból, mint a korabbi:

Az van tehát, hogy van egy L partícióm,
és az F: partícióm exdos.ini -jében egyetlen sor van:
:exdos L:

namost ha van L: particio exdos.ini -vel akkor minden király,
de ha nincs, akkor hibaüzenettel lerohad az EXDOS képernyőn ...

korábban mikor a rom -ba volt hekkelve az
:exdos L:
akkor is elindult a basic ha nem talalta az adott exdos.ini -t ...
Title: Re: EXDOS
Post by: Zozosoft on 2014.October.16. 09:36:55
Fordítsak neked E-L-F EXDOS.INI-s, lila EXDOS-t? :-)
Title: Re: EXDOS
Post by: Z80System on 2014.October.16. 10:02:12
Quote
Fordítsak neked E-L-F EXDOS.INI-s, lila EXDOS-t? :-)

Hát az is egyfajta megoldás ... de elég "hardkódolt" fajta ... :)

Ha majd lesz kedved, még az is lehet hogy másnak is kellene majd ... de akkor majd jön valaki, hogy ok, neki is kéne az E,L,F, de neki maradjon zöld,
vagy legyen E,K,F és piros ...

Talán (az image miatt) az E,L,F -es verzió lehetne plusszban (talán...),
a színekre meg adjál meg hekkelési paramétereket, és majd mindenki hekkeli, aki akarja ... nem ?
Title: Re: EXDOS
Post by: Z80System on 2014.October.16. 10:20:08
Nagyon lassú lenne egy for ciklusos EXDOS.INI keresés ... tehát ott mikor eddig az F: -et nezted, ott egy ciklusban keresned F: -től felfele a létező partíciókon ?

(A ciklus előtt meg után meg azok lennének, amik eddig az F: előtt és után voltak nyilván ... )

És akkor ki ahova teszi az EXDOS.INI -t, az futna, ha sehol nincs, akkor meg semmi ...
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 01:22:02
Lenne kerdesem az EXDOS muszkai leiras kapcsan. FISH hivasoknal:

"Verem a 0. vagy 2. lapon. (EXDOS 1.0 és E: esetén a 2. lapon)". Most az EXDOS 1.0 es E: ugy ertendo, hogy tenyleg 1.0-as EXDOS verzio es csak a ramdisk-nel a 2. lapon kell, hogy legyen a stack, vagy ugye, hogy E: eseten barmelyik EXDOS verzional ez kitetel? Ez elve nekem azert is fura, mert a 2. lapon a rendszerszegmens van, akkor oda kell vmi stack-et is applikalni hivas idejere? Vegulis manapsag mar rakhatom 0-as lapra a stack-et mindig, ugy se valoszinu, hogy EXDOS 1.0-val talalkozom? Vagy az EXDOS 1.0 ugy ertendo, hogy 1.x?

A masik: "2. lap = FISH RAM területet tartalmazó szegmens, általában a rendszerszegmens." Altalaban? Mi lehet meg? Peldakban en mindig latom, hogy fixen 0xFF megy a 0xB2 portra, oszt' kesz. Ezek szerint viszont ez igy nem feltetlen igaz mindig, mi a "tokeletes" megoldas erre a problemara?

"Transzfercím használat előtt be kell állítani a felhasználói szegmensregisztereket. (IY-5D) = P0 - (IY-5A) = P3". Ezt most ertsem ugy, hogy ami programban hasznalnek amugy B0...B3 portokon lapzva, azt kell betolni a fenti helyekre, ha ilyen transzferes jatekra van szuksegem? Eleve ez a transzfer se vilagos mit jelent. Azt gondoltam azt, hogy adatot kell atadni/venni ami RAM-ban (nem regiszterben) tortenik, de lathatoan ez nem igaz, mivel pl 4-es FISH funkcio (file keresese) is FCB-ket bizeral, ami szinten ugye a memoriaban van es csak a cimet adom at a FISH hivasnak, megsincs szo semmifele transzferrol. Bocs, lehet hogy ertem kozben, az a transzfer, ha vmit az IX regiszterbe kell pakolni (a cimet).
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 09:49:19
Most az EXDOS 1.0 es E: ugy ertendo, hogy tenyleg 1.0-as EXDOS verzio es csak a ramdisk-nel a 2. lapon kell, hogy legyen a stack,
Tényleg, mert hibás az 1.0-ban a RAMDISK rutinja:
Code: ZiLOG Z80 Assembler
  1.   EC97  DB B0        IN    A, (B0)
  2.   EC99  F5           PUSH  AF
  3.   EC9A  78           LD    A, B
  4.  *EC9B  D3 B0        OUT   (B0), A
  5.   EC9D  01 00 02     LD    BC, 0200
  6.   ECA0  ED B0        LDIR
  7.   ECA2  FD 7E 1D     LD    A, (IY+1D)
  8.   ECA5  D3 B1        OUT   (B1), A
  9.   ECA7  F1           POP   AF
  10.   ECA8  D3 B0        OUT   (B0), A
Ha a 0-ás lapon volt a verem, akkor amikor elővenné a B0h eredeti értékét, akkor hülyeséget olvas.

A 1.3-ban már így néz ki:
Code: ZiLOG Z80 Assembler
  1.         IN      A,(0B0H)        ;nullás lap
  2.         LD      C,A             ;mentése
  3.         LD      A,B             ;szektort tartalmazó  
  4.         OUT     (0B0H),A        ;szegmens belapozása
  5.         LD      A,C             ;eredeti nullás lap száma
  6.         LD      BC,0200H        ;512 bájt
  7.         LDIR                    ;szektor átmásolása
  8.         OUT     (0B0H),A        ;nullás lap visszalapozása
  9.         LD      A,(IY+1DH)      ;RAMDISK kezdőszegmens száma 
  10.         OUT     (0B1H),A        ;1-es lapra belapoz

Quote
ugy se valoszinu, hogy EXDOS 1.0-val talalkozom?
Milyen céllal írod a programot?
Bármely gyári EXDOS kártyával rendelkező felhasználó esetén 1.0 van...

Quote
Vagy az EXDOS 1.0 ugy ertendo, hogy 1.x?
Nem.

Quote
A masik: "2. lap = FISH RAM területet tartalmazó szegmens, általában a rendszerszegmens." Altalaban? Mi lehet meg? Peldakban en mindig latom, hogy fixen 0xFF megy a 0xB2 portra, oszt' kesz. Ezek szerint viszont ez igy nem feltetlen igaz mindig, mi a "tokeletes" megoldas erre a problemara?
Normál EXDOS rendszer esetén FFh és kész.
Trükkös programok esetén lehet, hogy csinálsz másik RAM területet neki, máshol.

Quote
"Transzfercím használat előtt be kell állítani a felhasználói szegmensregisztereket. (IY-5D) = P0 - (IY-5A) = P3". Ezt most ertsem ugy, hogy ami programban hasznalnek amugy B0...B3 portokon lapzva, azt kell betolni a fenti helyekre,
Igen.
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 10:45:21
Koszi az infokat!

Quote
Milyen céllal írod a programot?

Hat jelenleg sajat magam szorakoztatasara, plusz gyakorlaskeppen es ismerkedeskeppen :) Persze azert csak jo ilyenekre is figyelni, ha esetleg egyszer kiderulne, hogy masnak is hasznos lesz, vagy hasonlo.
Celja meg nagyon nincs, csak jatszok vele, directory olvasas, kiiratas, ilyenek, eddig csak EXOS-al "erintkeztem" programjaimban, gondoltam, megnezem ezt is :)

Quote
Bármely gyári EXDOS kártyával rendelkező felhasználó esetén 1.0 van...

Aha, en abba nem fogok beleutkozni :) de akkor viszont azt hiszem, megis erdemes lenne azert erre figyelnem. Viszont, akkor mi a bevett eljaras a FISH hivasoknal a fenti problema kapcsan? A 2-es lapra a stack-et nehezen tehetnem mert az a rendszerszegmens, vagy onhatalmulag tegyem csak oda a stack-et mondjuk a legalacsonyabb cim kozelebe a szegmensen belul, aztan remenykedjek, hogy nem irok semmit felul? :) Vagy van ott stack-nek kinevezett terulet, amit en is bitorolhatnek? Mert ugye a FISH hivasoknal a 2-es lapra a rendszerszegmens kerul.
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 11:10:18
A legegyszerűbb ha FISH 30-al kérsz egy szektorpuffert és oda teszed az ideiglenes vermet. De mindezt lehet if-elni, hogy akkor ha a verzió kisebb mint 1.2. Esetleg előtte a FISH 27-el hozzáadni egy plusz puffert, hogy ne okozzon lassulást a hiányzó puffer.
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 13:19:05
A legegyszerűbb ha FISH 30-al kérsz egy szektorpuffert és oda teszed az ideiglenes vermet. De mindezt lehet if-elni, hogy akkor ha a verzió kisebb mint 1.2. Esetleg előtte a FISH 27-el hozzáadni egy plusz puffert, hogy ne okozzon lassulást a hiányzó puffer.

Koszi. Az nem megoldas, hogy allokalok addig szegmenseket (video szegmens foglalas miatt ugy is vegig kell menni majdnem - az elso video ram szegmensig -, onnan meg csak egy "ugras"), amig shared segment uzenetet nem kapok, aztan exos boundary-t beallitom (gondolom veremnek fish hivas idejere nem kell tul sok)? Vagy ez tobb problemat vet fel, mint amennyit megold? Nekem, hogy oszinte legyek meg mindig nem tiszta, hogy mi van, ha a rendszerszegmens (0xFF) elfogy, akkor folytatja a 0xFE-n, es erre is fel kell keszulni?
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 13:50:47
Lehet úgyis, és igen ez esetben arra is fel kell készülni, hogy az FFh már elfogyott. (Bár ha a program elején csinálod, ez inkább elméleti eshetőség.)
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 14:55:39
Lehet úgyis, és igen ez esetben arra is fel kell készülni, hogy az FFh már elfogyott. (Bár ha a program elején csinálod, ez inkább elméleti eshetőség.)

Bocs, hogy itt ertetlenkedem, de van itt meg egy erdekesseg. Ha en szegmens allokacioval "felzabalom" az osszes szabad szegemnst, amig osztott szegmenst nem kapok, ott bellitok boundary-t, majd elengedem a tobbi szegmenst (ami csak azert kellett hogy odaig eljussak) akkor mi van? Marmint, ha elerkezik a rendszerszegmens "lefele menet" a boundary-ig, akkor is folytatja uj szegmensen (pl 0xFE) es kihagyja azt a "lyukat" amit az osztott szegmens okoz az EXOS szamara? Mert en erzik itt egy kis zavart az eroben: alapvetoen az osztott szegmens fogalma gondolom arra keszult, hogy ha mar elfogyott a memoria, akkor is legyen "valami" ami foleg mondjuk EP64 eseten lehet szerintem realisabb. Igen am, de ha utana felszabaditok egy rakas szegmenst, akkor ez logikailag olyan fura :) Vagy csak nekem van ezzel bajom?

Illetve FISH-ezes meg sok mas kapcsan is eszembe jutott mar, hogy sokszor kobe vesve ott van: rendszerszegmens = FF, holott ugye ez nem feltetlen igaz, mert az nyujtozhat lentebb is, extrem esetben (???) akar a program indulasanak pillanataban is.
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 15:07:54
Vagy csak nekem van ezzel bajom?
Csak neked :-)
A fő lényeg az, hogy a felhasználói program alulról kap RAM-ot, a rendszer meg fentről.

Quote
extrem esetben (???) akar a program indulasanak pillanataban is.
Ebben az esetben már rég nem működik a rendszer :oops:
Pl az EXDOS is belehal, ha nem a rendszerszegmensben kapta meg a RAM-ját.
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 15:19:58
Csak neked :-)
A fő lényeg az, hogy a felhasználói program alulról kap RAM-ot, a rendszer meg fentről.

Ez teljesen vilagos, csak az altalam vazolt esetben eloall az az allapot, hogy EXOS van "felul", user program "alul" de "kozepen" van egy folt ami a usere, am ezt alulrol es felulrol is kozreveheti nemi szabad RAM :)
Bar gondolom EXOS reszerol az a legegyszerubb viselkedes, hogy ha EXOS boundary van, es beleutkozik, nem megy tovabb, hiaba lenne szabad RAM meg "alatta" (ami azert allt elo, mert kozben felszabadult par szegmens, miutan osztott szegmens kiosztasra kerult). Na jo, nem hinnem, hogy ezek tul gyakori esetek lennenek azert.
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 15:41:16
Bar gondolom EXOS reszerol az a legegyszerubb viselkedes, hogy ha EXOS boundary van, es beleutkozik, nem megy tovabb, hiaba lenne szabad RAM meg "alatta" (ami azert allt elo, mert kozben felszabadult par szegmens, miutan osztott szegmens kiosztasra kerult).
Így van. Viszont a felhasználói igényléssel lehet a lentiből kapni.
Title: Re: EXDOS
Post by: lgb on 2015.February.03. 15:46:57
Így van. Viszont a felhasználói igényléssel lehet a lentiből kapni.

Szoval osszefoglalva: a szektor-pufferes eljaras megis jobbnak tunik nekem, hogy nyerjek egy kis rendszerszegmensen levo teruletet stack hasznalatara a FISH funciokhoz :) Ha jol tippelek, tyuk-es-tojas problemaja nem all fenn, hiszen ahhoz is FISH funkcio kell, hogy foglaljak, amde mivel az nem E: drive specifikus funkcio, ez EXDOS 1.0-ban sem okozhat gondot. Koszonom!
Title: Re: EXDOS
Post by: Zozosoft on 2015.February.03. 15:48:24
Szoval osszefoglalva: a szektor-pufferes eljaras megis jobbnak tunik nekem, hogy nyerjek egy kis rendszerszegmensen levo teruletet stack hasznalatara a FISH funciokhoz :)
Ezért is írtam egyből ezt a verziót :-) (Gondoltam a másikra is.)
Title: Re: EXDOS
Post by: lgb on 2016.April.12. 15:54:52
Eppen SD irast irok a Xep128-ba. Latszolag nekem mar megy, ami feltunt, hogy az :MD az lassu, igy erzesre kb 2 masodperc ... Ez a valosagban is ennyire lassan hajtodik vegre, vagy nalam van vmi gixer?
Title: Re: EXDOS
Post by: Zozosoft on 2016.April.12. 16:27:32
Ilyen bazi nagy FAT táblákkal lehet, főleg ha nem üres partíción próbálod. Esetleg a VERIFY is be van kapcsolva?
Title: Re: EXDOS
Post by: lgb on 2016.April.12. 22:39:13
Ilyen bazi nagy FAT táblákkal lehet, főleg ha nem üres partíción próbálod. Esetleg a VERIFY is be van kapcsolva?

Ha jol nezem az 255, tehat nem. Bar hat igen, SD kartyan ilyen max 12 bites FAT pariticio meretek vannak (~32M). Amugy jellemzoen az :MD lassu igazan csak ahogy nezem, tehat akkor ez talan normalis is lehet.

Masik erdekesseg, amit nem tudok megmagyarazni, de valoszinu, hogy en szurtam el: eddigi Xep128 verziokban is talan benne van, csak nem tunt fel: ha az ember irni akarna (az emulalt) SD kartyara, akkor mivel Xep128 nem tamogatja, persze hiba lesz belole, kerdi is szegeny EP hogy abort/retry. Nem ez az erdekes, hanem utana mar semmi nem megy, sima :DIR sem ... Holott barmennyire is nezem, egy elozo irasi kiserletnek a kodomban nem kene elrotania egy jovobeli olvasast. Vagy ez EXDOS-t keverte meg, hogy irni akart a disk-re es hibat kap? Ez azert zavaro viszont, mert akkor hogy emulalom az irasvedettseget, ha utana mar az olvasas se mukodik? :) Ez ugye emulator szinten ott jon elo, ha vagy nem akar az ember, hogy az emulalt EP irjon ra, vagy olyan file-t ad meg (vhd-nek, azaz image file-nak) ami nem irhato az emulator oldal csak olvashato. Eddig nyilvan ez olt az alapszitu (mivel Xep128 nem tudott irni ...) ezzel a verzioval mar tud: http://xep128.lgb.hu/files/xep128-sdext-wr-test.exe

Btw, mikor lesz 16 bites FAT EXDOS support? :) Az SD AU player-emmel oda jutottam, hogy nem erdemes addig csinalni vele semmit: egy 12 bites FAT particiora rafer 1-2 perc zene, aztan csokolom. Normalis felhasznalara alacsony szinten (FS nelkul) kell irni a kartyat, akkor viszont barkinek kirpobalasra eleg bonyolult muveletek kellenek, nem lehet csak ugy "ramasolni" a kivant zenet, stb. Nyilvan ez egy elhanyagolhato szempont, hogy miert lenne jo a 16 bites FAT-es cuccos, de azert ez is *egy* szempont legalabbis, meg ha nem is a vilag legfontosabb dolga :)
Title: Re: EXDOS
Post by: Zozosoft on 2016.October.18. 21:43:10
Végleges (nek szánt :oops: ) EXDOS 1.4

Kijavítva az utolsó béta verzióban az ATTR, ATDIR, és a nem romos ISDOS parancsok hibája (kiderült, hogy a disassemblálásnál két LD DE értékét is címkének kezelni, mert verembe rakja visszatérési címnek :oops: )

Újítások a korábban felsoroltakhoz képest:
-Legfontosabb: DISKIO-ba bekerült WD létezés vizsgálat (regiszterek írásával/olvasásával), így nincs többet külön nem floppys EXDOS pl. SD illesztőhöz
-ehhez új, 193-as kódú hibaüzenet is be lett vezetve, "Controller not ready".
-192-es kódú hibaüzenetet kapott a WD által jelzett Lost data hiba, ez Turbo Exdos esetén fordulhat elő, ha a gép órajele túl lassú HD lemezekhez. (Ez korábban sima Data error volt, amivel anno egy csomót szívtam mert azt hittem, hogy a WD nem bírja a tuningot, és hibázik...)
-DISKIO fixen az 1xh portokat használja, így az EXDOS ROM bármely szegmensre tehető
-német és spanyol verziókban a megfelelő nyelvű ISDOS van a ROM ISDOS-os verziókban
-nem ROM-os ISDOS esetén javítva az a hiba, amiről anno az Enterpressben volt cikk: sikertelen ISDOS betöltés esetén nullázza a BOOT_DRV változót.
-EXDOS.INI kezelésnél még egy plusz billentyű: jobb SHIFT kényszeríti az EXDOS.INI futtatást. Ez arra az esetre van, ha a bejelentkező képhez ugrásos trükkel van resetelve, ilyenkor alapból nem fut le újra.
-EXDOS.INI-t nem keresi a B: meghajtón, ha egy floppys a rendszer (MAPDISK-elt a B: meghajtó)
-floppykra modernizált boot szektor ír fel formatáláskor (Erről korábban már volt szó: PC-s helyére is beírja a a 32 bites lemezazonosítót, szerepel a FAT12 fájlrendszer azonosító, és módosított boot kód, hogy ne fagyjon le a PC ha véletlenül EP lemezre bootol :-) )
-van külön verzió WD1772-höz, ahol az alapértelmezett fejléptetés az 3. Ilyen volt korábban 1.3-ból is, ez esetben viszont már az EXDOS inicializálás során kerül beállításra, így már bejelentkező kép elötti meghajtó vizsgálatnál is a gyorsabb léptetést használja
-vannak nem rom ISDOS verziók, itt a második szegmens elején jókora hely, ahova kerülhet egy másik rom bővítő "társbérletbe"
Title: Re: EXDOS
Post by: lgb on 2016.October.20. 00:24:12
-floppykra modernizált boot szektor ír fel formatáláskor (Erről korábban már volt szó: PC-s helyére is beírja a a 32 bites lemezazonosítót, szerepel a FAT12 fájlrendszer azonosító, és módosított boot kód, hogy ne fagyjon le a PC ha véletlenül EP lemezre bootol :-) )

Ehmm, emulatort boot-oljon akkor a PC es mukodjon EP-kent :-D :-D Hamm, nem is rossz otlet, bare-metal programmed emulator, minek ala masik OS :)
Title: Re: EXDOS
Post by: Lacika on 2016.October.27. 18:58:07
-vannak nem rom ISDOS verziók, itt a második szegmens elején jókora hely, ahova kerülhet egy másik rom bővítő "társbérletbe"

Ez a "társbérlő" lehetne fixen a FILE, mint "ipari szabvány".
Title: Re: EXDOS
Post by: Lacika on 2016.October.29. 13:42:34
Floppyra csak egy Controller not ready üzenetet kapok. Hozzá sem szagol sem image-hez, sem igazi floppyhoz.(?)
Title: Re: EXDOS
Post by: Zozosoft on 2016.October.29. 13:53:43
Jól sejtem, hogy régi ep128emut használsz? Abban hibás a WD emulácio, a 2.0.10-ben javitva.
Title: Re: EXDOS
Post by: Lacika on 2016.October.29. 13:58:53
2.0.10 beta.
Van újabb?
Title: Re: EXDOS
Post by: Lacika on 2016.October.29. 14:02:13
Most már működik. Találtam újabb emut ugyanazzal a verziójelöléssel...
Title: Re: EXDOS
Post by: lgb on 2017.June.12. 02:42:07
Bocsi, lehet hulye kerdes, es volt is mar ... De miert tart olyan soka egy-egy DIR utan kiirni a szabad helyet? Na persze ertem en, hogy ehhez vegig kell nezni a FAT tablat ... De elvileg indulasnal (vagy esetleg az elso DIR elfordulasanal) ezt eltarolhatna, es minden FAT muveletnel ahol ujabb cluster kerul lefoglalasra ott csokkentheto lenne a szabad terulet "memorizalt" erteke, ahol meg felszabaditunk cluster-t, ott novelheto. Igy eleg gyors lenne. Legalabbis en a FAT32 driver-emben igy csinalom, csak azert kerdeztem, de ettol ez persze igaz FAT12 es FAT16-ra is (az megint mas kerdes, hogy FAT32-ben erre van eltarolt ertek is elvileg, de tok mindegy, attol a teoria ugyanugy igaz, hogy eleg egyszer ellenorizni, felszedni, stb valahonnan es utana az erteket "karban lehet tartani" es nem kell miatta allandoan ujra atnyalazni az egesz FAT tablat ...).
Title: Re: EXDOS
Post by: Povi on 2018.March.20. 20:34:35
Zozo, az SD-kártyát hogy lehetne működőképessé tenni az eredeti, nem buherált EXDOS kártyával? (amiben 1.0-ás EXDOS van).
Title: Re: EXDOS
Post by: Zozosoft on 2018.March.20. 20:39:24
Zozo, az SD-kártyát hogy lehetne működőképessé tenni az eredeti, nem buherált EXDOS kártyával? (amiben 1.0-ás EXDOS van).
Írni egy külön gyorsteszt verziót, ami kihagyja a 2xH-t a ROM keresésből.
Title: Re: EXDOS
Post by: Povi on 2018.March.20. 20:44:44
Írni egy külön gyorsteszt verziót, ami kihagyja a 2xH-t a ROM keresésből.
Na és az SD-kártyán lévő EXDOS az nem valami herélt változat? Az tudja a lemezeket is kezelni?

Az EPROM foglalatban van? (tudom, nézzem meg). Ha igen, és ha csak kiveszem, az is megoldja a dolgot, nem?
Title: Re: EXDOS
Post by: Zozosoft on 2018.March.20. 20:49:17
Na és az SD-kártyán lévő EXDOS az nem valami herélt változat? Az tudja a lemezeket is kezelni?
Ha az aktuális ROM verzió van benne, akkor már tudja!

Quote
Az EPROM foglalatban van? (tudom, nézzem meg). Ha igen, és ha csak kiveszem, az is megoldja a dolgot, nem?
Igen az megoldja. Vagy ha 1.4-es EXDOS ROM-ot raksz oda is.
Title: Re: EXDOS
Post by: Povi on 2018.March.21. 21:35:25
Valami olyan hack elképzelhető, ami az SD-kártya olvasó flash-jében van?
Arra gondolok, hogy ha bent van az SD-kártya olvasó, akkor hagyja ki 0x20-as szegmenst, de ha nincs, akkor viszont nézze ott is (azaz önnállóan is működjön a nem buherált gyári EXDOS kártya)
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.16. 19:18:36
Tiszteletem! EXDOS segítséget szeretnék kérni. Elkezdtem olvasni Zozo EXDOS leírását, mert szeretnék pár funkciót elérni (létező meghajtók lekérdezése, aktuális könyvtár lekérdezése, egy könyvtárban lévő fájlok listázása). Odáig eljutottam, hogy ezeket FISH hívásokkal lehet, de amit csináltam, arra egy szuper lefagyás az eredmény. Arra gyanakszom, hogy talán a szegmenseket nem lapozom be rendesen. A program C-ben készül és Z88DK SDCC-vel fordítom. A kérdéses rész most így néz ki:

Code: [Select]
void FISH()
{
  Out(0xB2, 0xFF);
  __asm__ (
    "ld     A,20\n"
    "call   0xC010\n"
    "ld     A,D\n"
    "ld     (_d),A\n"
    "ld     A,E\n"
    "ld     (_e),A\n"
    "ld     A,H\n"
    "ld     (_h),A\n"
    "ld     A,L\n"
    "ld     (_l),A\n"
  );
  ...
}

A 20-as funkcióval a DE és HL regiszterekben kéne megkapnom az elérhető meghajtókat, de helyette lefagy. Miért nem jó?
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.16. 23:15:08
3-as lapra belapozod az EXDOS ROM-ot? Illetve a verem se árt ha olyan helyen van ami nincs lapozgatva :-)
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.17. 00:38:49
3-as lapra belapozod az EXDOS ROM-ot?
Ööööő, nem. Akkor megvan, miért fagyott. Azt írja a leírás, hogy az EXDOS ROM-ja (IY-5E)-ről olvasható. Ez mit jelent? Valami port adja vissza? *

A verem szegmense kilapozható, miután visszatért a FISH hívásból? Pont a 2. lapot használom.

* Tovább olvastam, miután hülyeséget kérdeztem. Szóval IY a FISH-re mutat, gondolom a -5E a cím ehhez képest. IY-t pedig 0FDh-val lehet lekérdezni. Ez mit jelent?
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.17. 10:59:20
Így kérdezed le:
Code: [Select]
               LD DE,EXDOS_STR
                EXOS 26
JP NZ,NOEXDOS
                DI
                LD (FISH_VAR),DE
                PUSH DE
                POP IY
                LD A,(IY-5EH)
                LD (EXDOS_ROM),A


EXDOS_STR       DB 6,"EXDOS",0FDH

Amikor meg hívod, akkor:
Code: [Select]
               LD IY,(FISH_VAR)
                LD A,(EXDOS_ROM)
                OUT (0B3H),A
                LD A,0FFH
                OUT (0B2H),A
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.20. 02:00:27
Úgy néz ki, hogy sikerült működésre bírnom, le tudtam kérdezni a létező meghajtókat. Köszönöm a segítséget, Zozo!
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.21. 23:42:29
Zozo, nyúzhatlak még? A FISH hívás lefagy, ha az aktuális könyvtárat szeretném lekérdezni a 3-as funkcióval. Az EXDOS ROM lekérdezése megy, még a meghajtókat is visszaadja a 20-assal a DE és HL regiszterekben, de amikor a 3-as funkcióval hívom, megfagy.

Így kérdezem le az EXDOS ROM-ot és a FISH területet:
Code: [Select]
unsigned int FISH_VAR;
unsigned char EXDOS_ROM;
unsigned char RA, RB, RC, RD, RE, RH, RL; // Ezeket a regiszterek tartalmának tárolásához használom
unsigned int RDE;
...

  RDE = (unsigned int) &EXDOS[0]; // DE erre mutat, amiben ez van (szerintem jó): 6, 'E', 'X', 'D', 'O', 'S', 0xFD
  __asm__ (
    "ld      DE,(_RDE)\n"
    "rst     0x30\n"
    ".byte   26\n"
    "ld      (_RA),A\n"
    "ld      (_FISH_VAR),DE\n"
    "push    DE\n"
    "pop     IY\n"
    "ld      A,(IY-0x5E)\n"
    "ld      (_EXDOS_ROM),A\n"
  );

Itt pedig a 3-as funkcióval a 6-os meghajtón (F:) az aktuális könyvtárat szeretném lekérdezni:
Code: [Select]
 // Get current directory
  RB = 6;
  FISH(3);
...

// Ezt hívja meg:
void FISH(unsigned char Function)
{
  unsigned int Address;

SetEXOSVar(27,255);
  RA = Function;
  __asm__ (
    "ld      IY,(_FISH_VAR)\n"
    "ld      A,(_EXDOS_ROM)\n"
    "out     (0xB3),A\n"  // Page 3: EXDOS ROM
    "ld      A,0xFF\n"
    "out     (0xB2),A\n"  // Page 2: FFh segment
    "ld      A,(_RB)\n"   // B = drive (function 3)
    "ld      B,A\n"
    "ld      A,(_RA)\n"   // A = function
    "call    0xC010\n"
    "ld      A,D\n"
    "ld      (_RD),A\n"
    "ld      A,E\n"
    "ld      (_RE),A\n"
    "ld      A,H\n"
    "ld      (_RH),A\n"
    "ld      A,L\n"
    "ld      (_RL),A\n"
  );
  Out(0xB2, VideoSeg);
SetEXOSVar(27,7);
}

A 27-es EXOS változóban keretet állítom, hogy látszódjon, hol fagy le. Fehér marad, tehát valahol az assembly rész hal meg. Kb. két napja keresem, hogy miért. Megőrülök.

Módosítás: a DI parancsot nem tettem bele a lekérdezésbe. Ha jól láttam, ez a megszakításokat tiltaná le. Ez okozhatja? Ha kell bele, utána engedélyezni kell újra a megszakításokat?
Title: Re: EXDOS
Post by: geco on 2020.December.22. 14:02:24
kipróbáltam nagyjából azt a kódot, amit használsz, annyi, hogy én fix értékeket adtam meg, semmi lekérdezés, nekem nem fagyott, működik engedélyezett megszakítással.
IY-ban a FISH címe volt, A=03, B=01, és belapoztam a 2-es lapra az FF szegmenst, a 3-asra a 20-ast, mert pont ott volt az EXDOS.
2 tippem van, az egyik, hogy a kódod a 2-es, vagy 3-as lapra kerül, és így kilapozza saját magát, ez könnyen ellenőrizhető, ha a border 7-re állítást a lapozás utánra teszed, és nem EXOS 27-tel, hanem OUT (81h),a-val
A másik az, hogy valamelyik változód rossz értéket ad vissza, vagy a fish cím, vagy az EXDOS ROM
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.22. 17:32:08
Köszi a választ! Teleszúrkáltam különböző színű keretállítással a hívást, ebből egyértelműen a CALL 0xC010-nél fagy meg. Az EXDOS ROM értéke nálam 32 a számítás (IY-5Eh) után, a FISH_VAR-ban pedig 42081 a cím. Ez hihetőnek tűnik, ha a 2. lapon van a FISH, mert akkor 32768-49151 értéktartományban kell lennie. Azt hogyan tudom megnézni, hogy az EXDOS ROM valóban a 32-es szegmensen van? (Nálad a 20-as érték hexa vagy decimális? Ha hexa, akkor nekem is ugyanannyi.)

Ha nem fog működni, olyanra van lehetőség, mint PC-n, hogy egy DIR parancsot > jellel átirányítok fájlba? Így sokkal lassabb lenne, de abból be tudnám olvasni a könyvtár tartalmát. Próbáltam "dir > x.txt" formában, de "Wrong number of parameters" hibát ad az EXDOS.
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.22. 19:23:50
A verem melyik lapon van?
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.22. 19:34:10
A verem melyik lapon van?
Nem tudom. :) Azt nekem kell meghatározni? Nem az FFh szegmensen van?
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.22. 19:47:23
Nem tudom. :) Azt nekem kell meghatározni? Nem az FFh szegmensen van?
Igen, egy gépi kódú programot célszerű egy LD SP utasítással kezdeni, a későbbi bonyadalmakat elkerülendő. (Amikor EXOS hívást használsz, akkor az EXOS átvált a saját vermére az FFh szegmensen).
Leggyakrabban LD SP,100h használatos, ez a program alá teszi vermet.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.22. 20:05:00
Ok, köszönöm! Azt nem tudom, hogy a fordító mit fordít C-ből és beállítja-e a vermet. Ha beleteszem az LD SP,100h-t, és utána EXOS hívást használok, akkor mindig vissza kell állítani a vermet 100h-ra? EXOS hívás kell pl. az EXDOS ROM szegmens lekérdezéséhez, EXOS változók állításához, csatorna nyitáshoz/záráshoz, blokk olvasáshoz. Jól értem, hogy ezek után mindig be kell állítani a vermet? Nem fog összeomlani a program? (Mondjuk ennél jobban nem.)
Title: Re: EXDOS
Post by: geco on 2020.December.23. 08:45:20
bocs, elfelejtettem a h-t a 20 végéről, hexa 20 volt.
A vermet nem kell minden EXOS hívás után újraállítanod, az EXOS visszaállítja.
Az a tippem, hogy a C program alapból beállít egy vermet, és akkor az lesz rossz helyen, próbáld meg beállítani úgy, ahogy Zozó mondta, csak előtte mentsd el a verem helyét, és visszatérés előtt állítsd vissza, nehogy most meg a C programod pusztuljon meg,
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.23. 10:49:48
Maga az EXDOS is lapozgat, amikor meghívja a meghajtók kezelőprogramját.
Ezért vagy a 2. lapon a rendszerszegmensben legyen a verem (ez a helyzet, amikor EXOS-on keresztül történik lemezművelet), vagy a 0. lapon.

Az a gyanúm, hogy most a programodban az 1. lapon lehet. Mivel az egyszerűbb FISH hívás lefut, amihez nem kell az EXDOS-nak lapoznia.

Amúgy ha csak DIR listát szeretnél fájlba, azt úgy is lehet, hogy nyitsz egy fájlt, beállítod annak a csatornának a számát alapértelmezett output csatornának, hívsz egy DIR parancsot, lezárod a fájlt (és visszaállítod az output csatornát).
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.24. 01:22:04
Beletettem a program elejébe egy "LD SP,100h" utasítást, de így is lefagy a FISH hívás. Elkezdtem kísérletezgetni, hogy mi lehet a veremmutató értéke. Amikor a program elindul (még az SP beállítása nélkül), 32428 van benne. Miután voltak EXOS hívások, 32439 lesz az értéke. Ezek szerint a verem valóban az 1. lapon van. Amikor 100h-ra beállítom, azt megcsinálja, de utána visszaváltozik az 1. lapon lévő címre. Még nem találtam meg, hogy hol változik vissza, meg kell nézni az összes EXOS hívást, de most úgy látom, hogy vagy a FISH hívás előtt/után kéne átállítani/visszaállítani a veremmutatót valahogyan, vagy az EXOS hívások előtt/után. A 2. lapra azért nem tudom tenni a vermet, mert oda lapoztam be azt a szegmenst, amit használok (ezen van a videomemória is). A 0. és 1. lap erre nem használható, mert ha ellapozom, lefagy. A 3. lapra pedig az EXDOS ROM kerül. De a verem akkor lehet a 0. lapon, csak ne változzon meg az EXOS hívások után, vagy legyen visszaállítva.

Így kérdeztem le az SP értékét, mert akármelyik regiszterbe nem engedi másolni. HL-t azért teszi bele a verembe, hogy a végén visszaállíthassam. Így ugyan a veremhasználat miatt némileg más értéket kérdez le, de az látszik, melyik lapon van. (Bizonytalan vagyok, hogy jól kérdeztem-e le, mert furcsa, hogy az első bájtot kell 256-tal szorozni, hogy jó legyen. Máskor 16 bites címeknél úgy rémlett, hogy az alacsony bájt van elöl, viszont így ad "jó" értéket.)
Code: [Select]
__asm__ (
  "push    HL\n"
  "ld      HL,0\n"
  "add     HL,SP\n"
  "ld      A,H\n"
  "ld      (_RA),A\n"
  "ld      A,L\n"
  "ld      (_RB),A\n"
  "pop     HL\n"
);
RSP=RA*256+RB;

Több türelmem most nincs hozzá, majd folytatom. Boldog Karácsonyt és jó ajándék bontogatást mindenkinek!
Title: Re: EXDOS
Post by: geco on 2020.December.25. 10:18:36
jo a lekerdezes, ha egyben szeretned, akkor lehet igy is:
    ld (valtozo),sp
A szorzasnal meg azert teljesen jo a helyierteked, mert nem a memoriabol veszed sz erteket 2 8biteskent.
A vermet probald a directory lekerdezes elejen elmenteni, beallitani 100h-ra, majd a rutinod vege elott visszaallitani.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.25. 16:25:31
Elmentettem a FISH hívás előtt a stack pointert, hogy majd vissza lehessen állítani, utána beállítom 100h-ra, hogy a 0. lapon legyen, de a CALL C010h így is lefagy. Ha majd lesz fórumtalálkozó és valakinek lesz kedve megnézni, azt megköszönném. Félreteszem ezt a programot, mert nem tudok tovább haladni vele. Esetleg csatorna átirányítással megpróbálom megoldani, de sejtétem szerint nagyon lassú lesz. Köszönöm az ötleteket!
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.25. 19:48:42
Nem tudod felrakni, hogy megdebugoljuk?
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.25. 22:52:50
Dehogynem, feltöltöm és köszönöm! Nem tudom, melyik a hasznosabb, ezért feltöltöm a fordított .com fájlt és a C forrást is. A call utasítás fagy le a FISH() függvényben, ezt kikommentezve elindul. Igaz, még nem csinál semmit, mert a teszthez csak dummy fájlokat tölt a listába.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.26. 14:20:33
Amikor lefagy a call utasításnál, akkor ezek a szegmensek vannak belapozva: F8h, FAh, FFh, 20h. Amikor kikommentezem a call-t és tovább jut, ezeket látom: F8h, FFh, FFh, 20h. Az 1. lapon van a verem és pont itt van eltérés. Kipróbáltam, hogy a call előtt 8100h-ra állítom az SP-t, hogy a kettes lapon lévő szegmensen legyen. Így tovább ment a program, máshol állt meg, de annak sejtem az okát. Lehet, hogy lesz belőle valami. :)
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.26. 21:01:56
Amikor a FISH hívós részre ér a program, akkor a program saját verme már 100h alatt van (00FDh-n áll), így az ismételten 100h-ra állított verem a FISH hívás alatt felül írja a program saját vermében lévő adatokat.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.29. 00:38:40
Találtam egy hibát. Eddig a veremmutatót az Init() függvényben állítottam 100h-ra, amit a main() hív meg. Ha jól gondolom, amikor az Init() végez és visszatér a main()-be, akkor lesz rossz érték az SP-ben. Módosítottam, most mindjárt a main() legelején állítom be a veremmutatót, és látszólag végig jó érték van benne (F1-re kiírja alul), de ha nincs kikommentezve a call C010h, akkor továbbra is megfagy. Zozo, megnéznéd újra, légyszi? Ilyenkor az emulátorban nézed debug-gal? Megnéztem én is úgy, az SP-ben C4h van, viszont a 2. lapon az FDh szegmens van, ami nem tűnik jónak, pedig a call előtt van egy Out(0xB2, 0xFF), a 255-ös szegmensnek kellene ott lennie. Köszönöm!
Title: Re: EXDOS
Post by: geco on 2020.December.29. 13:18:26
szerintem az a baj, hogy a hulye C miatt nagyon alacsonyan van mar az sp (00bf)-en, amikor az exdos meghivodik, de nezem tovabb.
Title: Re: EXDOS
Post by: geco on 2020.December.29. 13:24:39
0083-ig megy le, 80 ala nem, elmeletileg ennek nem kene gondot okoznia
Title: Re: EXDOS
Post by: geco on 2020.December.29. 13:32:51
van egy jo hirem, meg egy rossz, nem fagy a program, olyan meghajtot kerdez le, amiben nincs lemez, Retry or abortra var nalam, es hiaba teszek be a b-be is image-et, marad a hiba.
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.29. 13:34:55
0083-ig megy le, 80 ala nem, elmeletileg ennek nem kene gondot okoznia
5Bh-ig lehet lemenni.
Title: Re: EXDOS
Post by: Zozosoft on 2020.December.29. 13:38:58
Retry or abortra var nalam
Ilyen esetre be kell állítani a megfelelő alapértelmezett csatornákat, hogy a hiba kiírás/válasz bekérés megfelelően működjön. Vagy pedig le lehet tiltani az EXDOS hiba kezelést, ilyenkor egyből Disk operation aborted hibával tér vissza, és külön EXDOS változóból olvasható ki a hiba, amit aztán saját hiba kezelővel lehet kezelni.
Title: Re: EXDOS
Post by: geco on 2020.December.29. 13:41:46
azert akad el a programod, mert az f meghajtorol szeretnel dirt, de a b erteke 5, es nincs ramdrive-od, belottem a ramdrive-ot, es tuljutott a call c010-en.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.29. 15:09:57
Ez fura. Úgy próbáltam, hogy csináltam ramdrive-ot, meg még két másik meghajtót assign-nal a ramdrive-ra hivatkozva (F: és H:), hogy lehessen tesztelni több meghajtót is. Ezek létezését lekérdezi FISH 20-as hívással, ezt eddig jól működőnek véltem, de ránézek. Az E: és F: meghajtót kéne lekérdeznie egyelőre, de FISH 3-nál megakad. Akkor itt valójában várakozik a válaszra a hiba miatt, hogy nincs bent lemez?
Title: Re: EXDOS
Post by: geco on 2020.December.29. 19:58:25
Ha van RAM Drive-od, akkor nem kéne, nálam nem volt, akkor arra várt, amikor csináltam egyet, akkor tovább ment, csak az első lekérdezésig teszteltem.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.29. 21:17:15
Nálam lefagy ramdrive-val és annyi tudásom nincs, hogy kinyomozzam az okát, a debug-ban látott infó kevés nekem. Azért köszönöm a nyomozást mindkettőtöknek! Elindulok az átirányított "dir" parancs felé, megnézem, mennyire lesz így használható sebességű. Viszont máris kérdésem lenne: Basic-ben kiadott EXT "xxx" parancsot hogyan lehet megvalósítani? Az EXOS leírásban a rendszerbővítők hívása részt olvasgatom. Találtam egy ilyet: 2-es akciókód: parancsfüzér. Itt a DE regiszterben kellene lennie egy címnek, ami a parancsra mutat, aztán... hogyan? Itt kéne egy EXOS 11-es funkciót hívni? Jó lenne, ha mármilyen EXDOS parancsra működne, mert akkor a "dir" mellett a többi funkciót is (pl. "cd", "copy") így oldanám meg.
Title: Re: EXDOS
Post by: geco on 2020.December.29. 21:57:20
valodi gepen probalod, vagy emulatoron? mert ha emu, akkor megnezhetjuk az altalad hasznalt konfiggal is.
ugy emlexem exos 26-os hivassal lehet.
  ld de,dir
  exos 26

dir db 3,"DIR"
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.29. 23:30:32
Emulátorral próbáltam, a "EP_128k_EXDOS_FileIO.cfg" konfig volt betöltve, hogy legyen EXDOS és a fordított .COM programot is be tudja tölteni vinyóról.
Title: Re: EXDOS
Post by: geco on 2020.December.29. 23:40:35
ugyanezt hasznaltam en is :-D, es egy ures 32K-s ramdisket hoztam letre, es addig neztem, mig a 0c010h-bol vissza nem ter. mekkora ramdisket hoztal letre?
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.29. 23:45:23
16K-s ramdisk-et csináltam, de most kipróbáltam 32K-ssal, assign nélkül, csak E: meghajtó van és ugyanúgy lefagy.
Title: Re: EXDOS
Post by: geco on 2020.December.30. 10:00:10
a program valojaban nem fagy, az lpt kezdocimet allitja at az fd szegmens legelejere az fc szegmens elejerol, ahol nincs lpt, ezert van a fekete kepernyo villanasokkal, ha kitartoan nyomsz egy gombot, akkor klikk is van.
Title: Re: EXDOS
Post by: Tomato77 on 2020.December.31. 01:49:57
Jé, tényleg van klikk! Azért reagál ilyen nehezen a billentyűleütésre, mert leköti a Nick-et a hibás LPT? Egyébként nem értem, mitől változik meg az LPT kezdőcím. A 82h és 83h porton keresztül változtatható, amit a program csak egyszer változtat (+1 a kilépésnél). Hibásan lennének a szegmensek belapozva és emiatt a C010h hívás felborít mindent? Vagy valahol felülírható a memóriában és felül is íródik?

Megnéztem emulátorban, mi látszik a Nick-en. Nincs call C010h, van kép:

Nick  80: 00 00 00 C0  Slot: 37
Nick  LPB: 01B0,FE  LD1: 0000  LD2: 0007

Van call C010h, nincs kép:

Nick  80: 00 00 00 C0  Slot: 2D
Nick  LPB: 4A80,BE  LD1: 0000  LD2: 0000

Ebből mondjuk nem látom*, hogy melyik jelenti az FC szegmenst, de az LPB-nél elég nagy eltérés van. Azt most fedeztem fel, hogy működik a debug és alul a Step gombbal tudom parancsonként léptetni a programot. 1024x768-as felbontásnál nem látszódtak a gombok, kilógott a debug képernyő alja. :) Tényleg fut a program, de nagyon nehéz felismerni assembly-ben a neki megfelelő C kódot.

* Módosítás: ha rátehénkedek a Step gombra, akkor folyamatosan változnak a fenti értékek a Nick-nél. Ha jól gondolom, az LPB-ben az éppen megjelenített sorparaméter blokk van, és a 0-val kezdődő cím van az FC lapon, a 4-essel kezdődő pedig az FD-n. Valamiért ez tényleg rossz és az FD-n keresi az LPT-t, ha van call C010h.
Title: Re: EXDOS
Post by: geco on 2020.December.31. 09:27:20
nem a c010h hivasa boritja fel az lpt-t joval a 3. hivas utan jon az lpt allitas, belapozza a page2-re FD-t, es atallitja C4-re a 83-as portot, ez pozicionalja rossz helyre az LPT-t, es maga a C program. Igen, ezert nem szeretem en se a C programokat, vagy egyeb mas nyelven irt programokat debuggolni, mert nehez rajonni epp hol is jar, mit csinal. A klikk azert olyan lassu, mert az "LPT" jelen esetben egy tobb ezer soros kepet definial, egeszen addig tart, amig eljut a megfelelo pozicioban egy olyan byte-ig, amiben a reload bit be van allitva. Azt nezd meg, hogy a C forrasodban allitod-e direektben a 82-83 portokat, ha nem, akkor melyik fuggveny teszi ezt a meghivottak kozul.
Title: Re: EXDOS
Post by: Povi on 2021.February.22. 19:03:07
Így kérdezed le:
Code: [Select]
               LD DE,EXDOS_STR
                EXOS 26
JP NZ,NOEXDOS
                DI
                LD (FISH_VAR),DE
                PUSH DE
                POP IY
                LD A,(IY-5EH)
                LD (EXDOS_ROM),A


EXDOS_STR       DB 6,"EXDOS",0FDH

Amikor meg hívod, akkor:
Code: [Select]
               LD IY,(FISH_VAR)
                LD A,(EXDOS_ROM)
                OUT (0B3H),A
                LD A,0FFH
                OUT (0B2H),A

elkezdtem nézegetni az exdos leírásában a fish hívásokat, kicsit zavaros...
hogyan lehetne pl. egy DIR parancsot megírni? milyen fish hívások kellenek hozzá, milyen sorrendben?
én pl. az 1-es hívás leírását nem tudtam értelmezni... és gondolom, az azért kellhet hozzá...
Title: Re: EXDOS
Post by: geco on 2021.February.22. 20:49:50
elkezdtem nézegetni az exdos leírásában a fish hívásokat, kicsit zavaros...
hogyan lehetne pl. egy DIR parancsot megírni? milyen fish hívások kellenek hozzá, milyen sorrendben?
én pl. az 1-es hívás leírását nem tudtam értelmezni... és gondolom, az azért kellhet hozzá...
Még nem foglalkoztam vele, de mintha lenne egy fish hívás erre a célra, mert az a tippem, hogy a dir parancs vége is így csinálja.
A Directory kérésben csíteltem, a FILE-t vettem alapul, és most megnézni se tudom, mert a céges gépen megy az FT pofozgatása.
Na, egy régi verzió van ezen a gépen is:
Fish 01 útvonal és KFCB készítése fájl névből (ez csak indulásnál hajtódik végre, hogy megtudjuk melyik könyvtár az aktuális)
Fish 02 aktuális katalógus megadása
Fish 04 első bejegyzés keresése
Fish 05 következő bejegyzés keresése addig, amíg 0-ás a futás

Az a tippem, hogy a Fish 21 fog lemez infót visszaadni.
Title: Re: EXDOS
Post by: Povi on 2021.February.22. 21:00:52
Még nem foglalkoztam vele, de mintha lenne egy fish hívás erre a célra, mert az a tippem, hogy a dir parancs vége is így csinálja.
A Directory kérésben csíteltem, a FILE-t vettem alapul, és most megnézni se tudom, mert a céges gépen megy az FT pofozgatása.
Na, egy régi verzió van ezen a gépen is:
Fish 01 útvonal és KFCB készítése fájl névből (ez csak indulásnál hajtódik végre, hogy megtudjuk melyik könyvtár az aktuális)
Fish 02 aktuális katalógus megadása
Fish 04 első bejegyzés keresése
Fish 05 következő bejegyzés keresése addig, amíg 0-ás a futás

Az a tippem, hogy a Fish 21 fog lemez infót visszaadni.

én az 1-es hívásnál elakadtam...
nem világos, h mit kell megadni a HL-ben és a DE-ben...
meg kicsit hülyén van tördelve itt a leírás: http://www.ep128.hu/Ep_Konyv/Exdos_Muszaki_Leiras.htm#11
és nem világos, hogy mi az input, és mi az output

a :file bővítőnek fönt van valahol a forrása egyébként? abból is tudnék tanulni
Title: Re: EXDOS
Post by: geco on 2021.February.22. 21:26:43
Ezt a topicot nézd meg:
https://enterpriseforever.com/programozas/file-bovites/

Biztos fent van, mert én is forrásból kezdtem el.
Nálam a Fish 1-es hívásnál csak a
DE KFCB, első hívásnál ez egy üres bájtot tartalmaz
HL útvonal\file, első hívás úgyszint üres bájt

eredmény:
HL útvonal
IX KFCB kitöltve

Ha nem találod a file source-ot, írj egy pm-et, és holnap felteszem az FT forrást