Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.
Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.
Kulonbozo dolgokrol beszelunk. x86-oson (legyen most 8088 az egyszeruseg kedveert, 80286, majd 386-on stb mar egeszen meg van ez kutyulva protected moban) egy "lap" (inkabb szegmensnek hivjak) mindig 64K, az a 16 byte az, hogy minden 16. byte-on kezdodik egy voltakepp. Azaz a fizikai cim egyenlo a szegmens cim szorozva 16-al (azaz balra shift-elve 4-szer, ugyanaz) plusz az offset. 8088 egy darab (64K meretu) szegmenst kepes latni, igaz kulon kodra, adata, veremre, illetve egy extra celra (persze allithato mindegyik uarra). EP-n ugye a 16K-s szegmensekbol lehet 4-et belapozni a Z80 cimtartomanyaba, es nem fugg attol aztan, hogy a hozzaferes celja mi (kod/adat/verem/stb). 286-ostol kezdve egy szegmens merete nem feltetlen fix, hanem 64K-nal kisebb is lehet, es hw szintu hozzaferes korlatozas is van (ie "biztonsagos" oprendszerhez), itt a szegmensek mar 16Mbyte-ban kevereghetnek, es a szegmensregiszterek un szelektorokat tartalmaznak, ami a GDT vagy LDT-ben (globalis/lokalis deszkriptortabla) irja le a szegmenseket. 386 es folotte a szegmensmeret alapjat byte-tol lapra (4K) lehet modositani, igy egy szegmens nagyobb lehet, mint 64K mar, es 32 bites cimzessel persze ezt ki is lehet hasznalni. Hozzatennem, hogy valojaban modern OS-ek nem igazan hasznaljak tul sok mindenre a szegmentalasi modelt, helyette az un lapozas technikat alkalmazzak (ez nem uaz a lap mint a fenti lap, meg a szegmentalas, itt fix meretu 4K-s lapok vannak, meg laptablak, de ebbe ne menjunk bele itt szerintem), ami csak 386-os ota van x86-ban. Mas ISA-kon meg mas dolgok is elfordulnak persze, nem csak x86 letezik.
Szoval x86-oson nem "16 byte-os lapok vannak"
Max real modban a szegmensek kezdetehez van koze annak a bizonyos 16 byte-nak. Valoban, ha egy "primitiv" OS-t veszel (nem multitask, miegymas) akkor elonyos az x86, lassuk pl a CP/M-bol orokolt stuffokat a DOS-ban: a programok a 100h cimre toltodnek be stb. Remek, mondhatni, mert egy 64K-s szegmens "belulrol" offset szinten "ugyanaz" fuggetlenul attol, hogy a szegmens hol kezdodik, es "majdnem" barhol kezdodhet, max 15 byte memoriat pazarolunk el. Az adott szegmensen belul pedig a 100h mindig 100h, az hogy a fizikai memoriaban ez hol van, az mas kerdes.
Node, amit szerintem te keversz, hogy "hogyan oldottak meg". Tuby128 modern, multitask peldat hozott fel, azt meg relokalni szoktak x86-oson is persze. Ha erdekel megmutatom hogy kell, Linux alatt kozvetlenul assembly-ben is dolgoztam sokaig anno. Az nyilvanvalo viszont, ha nem modern peldat veszel, akkor mas az abra. 8088-on nehez "modern" peldat venni, de Z80/EP-re pl ott a SymbOS. Nyilvan relokalni kell, ha nem akarsz elveszteni egy egesz 16K-s teruletet mert "fix" ertekekkel dolgozol. Ahogy irtam, modernebb x86-osokon is reloaklnak termeszetesen, sot nem is igazan hasznalnak szegmenseket, mert minek: megnehezitik azt, hogy a process-ek (megfelelo engedely birtokaban) pl IPC-t csinaljanak (InterProcess Communication) stb.
Masreszt ezt nem "assemblerben" szoktak megoldani, hanem az adott toolchain object file formatuma hordozza az osszes szukseges infot ami segitsegevel a linker ebbol valamit eloallit. Ami adott esetben lehet PIC (Position Independent Code) jellegu kod is akar. Tehat nem neked kell gondoskodni feltetlen, a relokaciorol, azt majd az OS megteszi. Ehhez persze vmi info kell neki az igaz,
EXOS-nal nyilvan alapvetoen szinte alomnak tunt a 4Mbyte cimtartomany, nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol, stb. De amugy ha mar itt tartunk, ahogy Zozo is emlitette, van am EXOS-ban is ilyesmi, hogy relokacio, ha jol remlik a "relocatable system extension" ami talan a 7-es (?) tipusu az exos file header szerint. Szoval meg csak SymbOS-re sincs feltetlen szukseg, mint "modern" pelda
No, remelem igy ertheto.