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 ...

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 ?

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).

Koszi az infokat!

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

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.

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?

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.

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.