Nem tudom, mit kell nézni a képen...
"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 :-)
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
Quote from: "MrPrise"Izgalmas! Tisztára mint valami nyomozás! :-D
Pontosan :-) Az IDA tud párhuzamosan 6 fájlt feldolgozni? :-)
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.
Úgy tünik el lehet indítani egyszerre több IDA-t :-)
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?
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)
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á.
Zozonak:
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 :-)
szerinted EXDOS(FD)-vel körbehív valaha, mert a sztringet látni benne.Az a parancs sztringek között van.
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:
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 Z80page 1, which can only occur before RAM is allocated, or if no RAM is requested.
Ezt hol látod? Amúgy:Quote from: Intelligent SoftwareNote 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 Z80page 1, which can only occur before RAM is allocated, or if no RAM is requested.
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
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.
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 :-)
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.
eredeti?Eredeti (http://enterpriseforever.com/dlattach.html;topic=170.0;attach=1130;image), legalábbis ezt árulták a Centrumban :-)
guy kopexy? mi ez???Ezt egy másik topicban boncolgatom :-)
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...
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.
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.
Ú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áltozattalAzért lett 40, hogy a túlformázott ED-s lemezt is kezelje. Viszont átírhatjuk akár 255-re is :-)
Azért lett 40, hogy a túlformázott ED-s lemezt is kezelje. Viszont átírhatjuk akár 255-re is :-)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 :)
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.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ó.
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?
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)
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ó.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ó :-)
A .7z csomagban egy 16 MB-os (4K cluster méret) és egy 30 MB-os (8K cluster méret) image található.
az eredeti csak 9 szektort fogadott el egy sávbanAz eredeti 10 szektort fogadott el!
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 ?Szerintem mehet! Jó ez a kvázi vinyó :-)
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?
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.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?
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. ;-)
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.
É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!
Remek! :) "Pen Drive" Ep -hez? :-DDe elszaladt a fantáziád!
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:
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:
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) :-)
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 :-)
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...
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. :)
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 :-)
Na elkezdtem felboncolni ezt a cuccot is, hátha tanulunk belõle valamit :-)
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.
É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á!
É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.
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...Lassan BIOS is kell EP-re, amiben be lehet állítani a BOOT sorrendet (is). :D
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:
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
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:
Kiegészítettem!Jó!
Így jó lesz?
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?
De lehet :-) már csak azt kéne kitalálni melyik?Tűt a szénakazalban :D
Tût a szénakazalban :DMeg van, Apricot!
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.
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:\>
Ez talán még az angol EXDOS dokumentációkban sincs benne?Benne van:
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
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.
ertsem mit beszelsz ...Szabad kérdezni! :-)
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?)
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).
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.
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.
Jól gondolom:Jól.
Halandók számára lefordítva ez mit jelent? :oops:Pl:
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
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
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.
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.
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.
Egy kis boot szektorológia :)Na, ez az elemzes siman megerdemelne egy otost :)
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...Így van!
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:
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.
(Érdekességként van olyan XT laptopom, ami úgy bootol ROM-ból, hogy egy MS-DOS floppy image van ROM-ba égetve :-) )
FAFO-ba beépítve.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.
(Attachment Link)
Találtam egy picike bugot az EXDOS-ban :twisted:
(Attachment Link)
É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 ...: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:
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:És ilyesmit?
Azt hiszem, ez az Invalid cursor coordinates német megfelelõje.Invalid beam position
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:
Mikre jössz rá még ennyi év elteltével is... :)Igyekszek :-)
És így amit megfaragtam:Code: ZiLOG Z80 Assembler
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 isEz igaz, viszont az IN A,(C) az állítja a flageket, így közvetlenül alkalmas a DRQ vizsgálatára.
A B regisztert el lehet rontani (PUSH BC-vel biztosan :)) ?B-ben van a szektorszámláló, így kell PUSH.
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 :-)
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!
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.
Ez még megfejtendõ kérdésAzt 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.
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ó.
Akkor a nagyobb méretû lemezre is lehet valami trükkel akár 400 KB-ot is írni?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.
(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.
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.)
Most vettem csak észre, hogy az 1.3-as EXDOS-ok help-jében van egy gépelési hiba:Következõ verzióban javítjuk :ds_icon_cheesygrin:
"Commands avaliable:"
Megnyitod olvasásra, és sikerül-e?tényleg, ez jó módszernek tűnik :-)
Ú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
Ú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:
Jön majd mesedélután :-)Bár nem értek hozzá, de ha szájbarágósan leírod, engem is érdekel! :-)
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:
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.
É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.
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ó ?
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.
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 ...
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.
Azok egyáltalán nem is láttak Ep-tEz 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.
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 ?)
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% ?
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.
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
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.
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.
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.
Vagy ez csak egy EXDOS bővítőknek dedikált bug, és semmi mást nem érint ?Így van.
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?
Ő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:Tuti azért, hogy minél jobb legyen a 2. szegmens kihasználtsága :ds_icon_cheesygrin:
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.
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.
É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.
É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 :-)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! :-)
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)
Ez a zöld szín szép és nagyon nyugtató lenne.... :)
Kipróbáltam sötét zölddel, nekem így jobban tetszik :-)
(Attachment)
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 :-) )
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.
Szerintem ez egy elfogadható kompromisszum lenne, az EP64-en is működő START sokkal fontosabb lenne.Szerintem ne. Ne a régebbi verzióhoz igazodjunk.
Legyen benne az EXDOS 1.4-ben?
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.Egyetértek, először néztem is nagyokat, milyen gombot nyomhattam meg, aztán kiderült, hogy pont azt, amit akartam :lol:
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...
Már működik :-):smt041 :smt041 :smt041
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.
Kérdés: a gyors videó kezelő be legyen kapcsolva alapértelmezésben?Igen.
(vélhetően EPDOS) hiba?Valószínű :oops:
Ebben a FAT16 benne van? Azt hogyan formázhatunk?Attól még messze vagyunk, majd az lesz az 1.6 verzió :-)
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.
Elvileg kész az egységes magyar EXDOS.Arról lesz majd lista, mi változott az új EXDOS-ban?
Elvileg kész az egységes magyar EXDOS. ......Ezt berakhatom az exdos kártyámba? (nem csak 16 kb-s lehet?)
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.
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á ?
Arról lesz majd lista, mi változott az új EXDOS-ban?Az utolsó magyar 1.3-hoz képest:
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 :-)
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?)
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.
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 :-)
Az új EXDOS -szal ennek szimulációja az, hogy az F: -ra rendszeresítek egy EXDOS.INI -t,Igen. Csak itt több utasítást is beletehetsz, pl ASSIGN-olod az A-t az EGI-nek.
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.
Fordítsak neked E-L-F EXDOS.INI-s, lila EXDOS-t? :-)
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:
ugy se valoszinu, hogy EXDOS 1.0-val talalkozom?Milyen céllal írod a programot?
Vagy az EXDOS 1.0 ugy ertendo, hogy 1.x?Nem.
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.
"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.
Milyen céllal írod a programot?
Bármely gyári EXDOS kártyával rendelkező felhasználó esetén 1.0 van...
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.
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.)
Vagy csak nekem van ezzel bajom?Csak neked :-)
extrem esetben (???) akar a program indulasanak pillanataban is.Ebben az esetben már rég nem működik a rendszer :oops:
Csak neked :-)
A fő lényeg az, hogy a felhasználói program alulról kap RAM-ot, a rendszer meg fentről.
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.
Í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 :)Ezért is írtam egyből ezt a verziót :-) (Gondoltam a másikra is.)
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?
-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 :-) )
-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"
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.
Í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?
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!
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.
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"
);
...
}
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? *
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 LD IY,(FISH_VAR)
LD A,(EXDOS_ROM)
OUT (0B3H),A
LD A,0FFH
OUT (0B2H),A
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"
);
// 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 verem melyik lapon van?Nem tudom. :) Azt nekem kell meghatározni? Nem az FFh szegmensen van?
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).
__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;
0083-ig megy le, 80 ala nem, elmeletileg ennek nem kene gondot okoznia5Bh-ig lehet lemenni.
Retry or abortra var nalamIlyen 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.
Í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...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.
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.
Pl. igy elsore, az EXDOS az elso floppys muveletnel megker, hogy nyomjak Entert. Van valami valtozo/regiszter/memoriaterulet/fustjel, amibol tudhatom elore, hogy az EXDOS kodja igy fog tenni? Vagy ossze kene hackelnem, hogy a sajat szoftverem feluleten meg tudjon jelenni, amit az EXDOS ki akar irni?
:dir
parancsot, akkor is megjelenik a press enteres uzenet. Ha ugyonezt a ROM csomagot, pont ugyonugy toltom be az emulatorban, ahogyan a fizikai gepben van, akkor nincs ilyen uzenet. Nekem 1 fizikai drive van radugva az EXDOS kartyara, mig az emulator 4 driveot emulal.Ha nyomod a BAL Shift-et, miközben továbblépsz a bejelentkező képről (EXDOS.INI kihagyása), akkor jó?
Meg van a bug!
Anno az Enterpressben írt leírás nem volt egyértelmű a FISH 22 kapcsán, és azt hittem B regisztert kell vizsgálni közben meg a C-t.
Csak egy meghajtós rendszerben jött elő, azaz emun sose :oops: