Welcome, Guest. Please login or register.


Author Topic: SymbOS magyar (Read 29143 times)

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #120 on: 2014.October.31. 16:41:29 »
Olvasgatom a doksikat, de még nem állt össze bennem a kép :oops: annyit értek, hogy a CPC vacakul tud memóriát lapozni, ezért az a alap, és lesz jó bonyolult minden :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #121 on: 2014.October.31. 16:51:41 »
Olvasgatom a doksikat, de még nem állt össze bennem a kép :oops: annyit értek, hogy a CPC vacakul tud memóriát lapozni, ezért az a alap, és lesz jó bonyolult minden :-)

Kb latod a lenyeget. Ha tobb gepen akarod ugyanazt, sajnos az kell amit minden gep tud :( Szerintem SymbOS-t is lehetne kicsit maskepp portolni EP-re, de az pl kihatassal lenne az applikaciok memoriakiosztasara stb, igy azonnal elveszne az elony, hogy a legtobb SymbOS app binaris formaban futtathato barmelyik gepen azonnal, amire van SymbOS. Mindennek ara van ... Mondjuk a CPC memoriakezelese kapcsan en is teptem a hajamat, azota se ertem, miert nem lehetett mas gepeken is szep megoldas, mint az EP, kulonosen Commodore-os korokben idegesito dolgokat csinalnak, ahelyett hogy vmi ilyesmi holt egyszeru ugyanakkor hatekony megoldast csinalnanak, mindig elbonyoiitjak ... Vagy csak en nem ertem a motivaciot :) Amugy - lehet mar mondtam - Commodore DTV "joystick gepben" csinalta meg jol a csaj (marmint Jeri Ellsworth - ha jol irom a nevet igy fejbol), kb ugyanaz mint EP-n, csak ott a 4Mbyte kette van osztva, 2MByte SDRAM-ra (amit burst modban tud kezelni, azaz 32 bit prefetch stb), es 2Mbyte flash.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #122 on: 2014.October.31. 17:42:25 »
Ha jól nézem MSX2-nél is ugyanolyan 4 portos lapozás van mint EP-n. Kérdés, hogy az MSX verziójú SymbOS-ben hogyan van a lapozás megoldva? A belsőleg használt CPC-s 0-15 bankok, hogyan vannak lefordítva?
Mert ugye EP esetén kéne egy táblázat, amibe minden bankhoz le van tárolva 4 szegmensszám. Ez ugye alapból 16x4=64 bájt. Ez vajon elfér a rendszerben?
Meg nálunk nem kéne megállni 16 banknál, az csak nevetséges 1MB :-)

Meg jön a 64-el nem osztható szabad memória kérdése, azzal nem is tud mit kezdeni? Mondjuk úgy elkönyvelni, hogy a nem létező része foglalt és kész.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #123 on: 2014.October.31. 18:48:31 »
Ha jól nézem MSX2-nél is ugyanolyan 4 portos lapozás van mint EP-n. Kérdés, hogy az MSX verziójú SymbOS-ben hogyan van a lapozás megoldva? A belsőleg használt CPC-s 0-15 bankok, hogyan vannak lefordítva?

Az I regisztert fenntartja a SymbOS arra, hogy abban van az aktualis mem config reg erteke, azt irogatja aztan ki meg modositja, hogy ne kelljen mindig memoriabol felszedni. Vagy vmi hasonlo :)

Quote
Mert ugye EP esetén kéne egy táblázat, amibe minden bankhoz le van tárolva 4 szegmensszám. Ez ugye alapból 16x4=64 bájt. Ez vajon elfér a rendszerben?
Meg nálunk nem kéne megállni 16 banknál, az csak nevetséges 1MB :-)

Meg jön a 64-el nem osztható szabad memória kérdése, azzal nem is tud mit kezdeni? Mondjuk úgy elkönyvelni, hogy a nem létező része foglalt és kész.

Jo, hat ezt forras hianyaban nehez megmondani, SymbOS hogy mux belulrol. Szerintem, hogy maskepp tarolja a "memoria configot" az nem gond, mivel app-nak azzal sok dolga nincs (bar az nekem sem tiszta, hogy egy app hasznalhat-e tobb memoriat, amihez mar _neki_ kene lapoznia, vagy ez nem megengedett SymbOS-ben?), a kernel portolasnal ez eldol kb. CPC-n meg komplex is (neztem disasm-ban ...) van ahol egy oldalon at azt szamolgatja, hogy lesz "valodi" cimbol CPC mem cfg ertek :) Ez Ep-n azert egyszerubb. Meg lehet, eleg letarolni vmi kernel process strukturaban az EP segmens szamokat, es akkor szamolni sem kell tobbe, hanem azokat out-ozza azonnal, oszt' csokolom.

Amit irsz megoldas (tablazat) az kb nalam jonne be (tehat a "gany" portolasnal!), ha szep forras bizrtokaban levo portolast csinal, akkor eleve nem is kell CPC-EP memcfg "forditast" csinalni hanem nativan EP-s lehet. Az, hogy a symbOS alkalmazasok futnak minden platformon nem jelenti azt, hogy a kernelt ne lehessen valtoztatni akar jobban is, max az van ugye, hogy azt meg kell tartani, hogy az app-ok hordozhatoak legyenek. Felteve, hogy az app-ok szamara tilos kozvetlenul lapozgatni (ami gondolom igaz, kulonben most sem lennenek hordozhatoak az app-ok!), akkor meg a kernelben hogy van megoldva ez, az talan kevesbe lenyeges.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #124 on: 2014.November.01. 10:59:56 »
Felmerult itt bennem is egy kerdes: tudom, hogy a video RAM elerese a CPU-nak lassabb, mert osztoznia kell a Nick-el (jobban mondva a VRAM-ba meno memoira muveletek a Nick-en at mennek, es Nick szegeny Z80 orajelet bizeralja, hogy ne zavarjon be neki), viszont kifejezheto-e kb szazalekben, hogy mennyivel lassabb lesz mint a nem VRAM elerese, mondjuk egy alap 4Mhz-en futo Z80 szamara ez?

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #125 on: 2014.November.01. 11:50:54 »
viszont kifejezheto-e kb szazalekben, hogy mennyivel lassabb lesz mint a nem VRAM elerese, mondjuk egy alap 4Mhz-en futo Z80 szamara ez?
Na ezt nehéz lenne kifejezni :-)
Itt írkáltam az elméletről.

A dolog erősen függ attól, hogy éppen melyik Nick fázisban próbálkozik a Z80, ha jól számol a legrosszabb esetben 772,6... nsot kell várnia (ez Z80 sebbeségétől független).
Normál memória elérésnél 2.5 órajel az MREQ, az 625ns, utasítás olvasás esetén 1.5 órajel, ami 375ns. Vagyis a legrosszabb esetben, utasítás esetén 3x, sima elérés esetén is több mint 2x annyi ideig tart. De persze ha pont jó pillanatban érkezik a Z80, akkor nincs várakozás.

Bonyolultabb kódra mutattam ott a Nickes témában példát, hogy a 4Mhz-es Z80 sok hozzáférési ablakról lecsúszik, egyre nagyobb turbóval egyre több lehetőséget tud elkapni.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #126 on: 2014.November.01. 13:03:29 »
Na ezt nehéz lenne kifejezni :-)

Tudom, inkabb csak olyan "erzes" kategoriaban gondolkoztam, bar tudom, hogy fugg konkretan attol, hogy pl ha Z80 kod van ott, mlyen utasitasok stb. Szoval csak ugy atlagosan nagysagrendileg stb :)

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #127 on: 2014.November.01. 23:17:06 »
Kipróbáltam az MSX verziót emulátorban (az még is csak közelebb áll az EP-hez, WD, 720-as DOS lemezek), és nekem úgy tűnik, hogy amikor dolgozik a floppy, akkor megáll az élet.

Offline geco

  • EP addict
  • *
  • Posts: 5430
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 31.0 Firefox 31.0
    • View Profile
Re: SymbOS magyar
« Reply #128 on: 2014.November.02. 08:38:03 »
A CPC verziót megnézve is ez történik, amikor tölt, akkor épp nem mozog a kurzor, én még mindig leragadtam az EXOS-osításnál, az nem megoldható, hogyha megkapod a betöltendő fájl nevét, azt EXOS-szak megnyitod, és utána 256/512 byteonként beolvasod, minden sikeres olvasás után ugyanúgy visszaadva a vezérlést a SYMBOSnak, mint ahogy a CPC floppyolvasásnál van, annyi, hogy minden EXOS hívásnál mindent állítgatni kell oda-vissza SYMBOS és EXOS között, de szerintem így is gyorsabb lenne a töltés EP-n, mint CPC-n.
Úgy látom az összes file-t könnyedén ki lehet nyerni az image-ekből.
« Last Edit: 2014.November.02. 08:47:06 by geco »

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #129 on: 2014.November.02. 09:19:55 »
Kipróbáltam az MSX verziót emulátorban (az még is csak közelebb áll az EP-hez, WD, 720-as DOS lemezek), és nekem úgy tűnik, hogy amikor dolgozik a floppy, akkor megáll az élet.

Nyilvan, kikerulni teljesen nem tudod, max ugy lehetne, ha DMA-val menne, meg ilyesmi. Amivel disasm soran talalkoztam az max az, hogy seek track-nal csinalja azt a jatekot, de ezt valoszinu ezek szerint hogy sector read-kor mar nem tudja eljatszani. Mondjuk imho ez nem olyan meglepo azert.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #130 on: 2014.November.02. 09:44:05 »
A CPC verziót megnézve is ez történik, amikor tölt, akkor épp nem mozog a kurzor, én még mindig leragadtam az EXOS-osításnál, az nem megoldható, hogyha megkapod a betöltendő fájl nevét, azt EXOS-szak megnyitod, és utána 256/512 byteonként beolvasod, minden sikeres olvasás után ugyanúgy visszaadva a vezérlést a SYMBOSnak, mint ahogy a CPC floppyolvasásnál van, annyi, hogy minden EXOS hívásnál mindent állítgatni kell oda-vissza SYMBOS és EXOS között, de szerintem így is gyorsabb lenne a töltés EP-n, mint CPC-n.
Úgy látom az összes file-t könnyedén ki lehet nyerni az image-ekből.

Nem tudom, hogy lassabb lenne-e a SymbOS jelentosen ... Egyreszt, ha fejet mozgatni kell (seek) akkor - ahogy irtam - van nemi trukk legalabb arra (igaz WD-nel nem tudom megoldotta-e!), hogy amig nincs kesz fut mas process, igy lehet lecsuszik arrol, hogy mar kesz, es kicsit kesobb jon ra, cserebe nem all meg addig az elet teljesen. De ez _csak_ a seek ugy tunik. Ha jol ertem. Maga a sector olasas: abban nem vagyok biztos, mennyire lassabb-gyorsabb, foleg ha tobb sector kell. Disasm alapjan a CPC fdc verzio ugy tunik ugy mux, hogy van egy "entitas" ami un logikai szektor szam (nincs fej/track/stb) alapjan ir X db sectort egymas utan vagy olvas. Nagyjabaol aztan az osszes szovevenyes al-rutin ebbol a ket rutinobol hivodik kozvetve vagy kozvetlenul, hogy atalakitja fizikai lemez fej/sav/szektor szamma, kiadja a konkret fdc parancsokat, hibakodot ad vissza, stb. Ezt probaltam meg lecserelni en ugye, hogy legalabb egy image file-bol dolgozzon valodi hw helyett, ami valamiert nekem nem ment eddig, de talan kiderul miert (amugy megkerdeztem az irot hehe, azt mondta, hogy valoszinu azt nem veszem figyelembe, hogy CPC-n is van FAT es CP/M disk, es mas sector offset-teket hasznalnak amit a kod megprobal detektalni elobb, hogy kitalalja milyen tipusu disk-et kell kezelni - hmmm).

Most ugye modern szohasznalattal elve a "block layer"-rol van szo, ez kb hasonlo feluletes peldaval elve, mint EXDOS-nal a diskio. Az megint mas kerdes, hogy mi van, ha kidobjuk a SymbOS-bol a fentieket is, sot azt is, hogy o kezeljen filerendszereket stb, es _mindenert_ az EXOS-t hivogassa. Az biztos, hogy az bonyolultabb lenne disasm alapjan megtalalni, az ilyen fdc fuggo hw bizeralast meg mindig egyszerubb IN/OUT alapjan megtalalni, de ugye a "filerendszer" kezeles eleg absztrakt kod lehet. Valoszinu, hogy nem lenne teljesen lehetetlen megoldani. Amde ez felvet egy masik kerdest: alap EP-vel azonnal nem menne a cucc :( Ui 128K RAM az kb eppen eleg a SymbOS-nek barmi mas hardware-en is. Viszont az EXOS-ra epulo verzio eseten meg kene tartani a rendszerszegmenst legalabb. Bar az is igaz, hogy a SymbOS kod merete viszont csokkenne, mivel ki lehetne gyomlalni belole kb az osszes low level fdc I/O es filerendszer kezelest ugyanugy, ha az EXOS-on at menne, de tartok tole, hogy nem lenne annyi megtakaritas, hogy igy 128K-ba meg EXOS hasznalata mellett is belefer.

Amugy igazad van, cool lenne valahogy az EXOS hasznalata, mar csak azert is, mert megse kene kulon SymbOS driver SD kartyanak, RAM disknek (ha eleg RAM van ...), WD-s EXDOS-nak, esetleg Zozo fele IDE-nek ... Ja, es raadasul a CPC SymbOS verzio (disasm alapjan ahogy nezem, kozben neztem CPC wiki-t hogy milyen port micsoda) elegge "monolitikus" azaz eleve benne van vmi IDE-s cucc abban is (CPC wiki mondta par portra amit lattam, nem tudom mi az pontosan), legalabbis latszik, hogy csomo hasonlo rutin ketszer van a memoriaban is, gondolom NEC fdc-re, es az emlitett IDE-s valamire legalabb. Erdekes modon MSX-es verzioban viszont betoltheto driver-ek vannak ugymond, nem biztos, hogy ertem, mi a kulonbseg es miert van ez a kulonbseg a CPC es az MSX verzio kozott ....

Es itt nem csak arrol van szo, hogy a SymbOS vagy az EXDOS lenne-e a gyorsabb, hanem arrol is, hogy EXDOS mar kesz van, es rajta at minden elerheto, mivel EP-n softrware-ek ugye altalaban EXOS/EXDOS-on at vegeznek file muveleteket, ergo kb ami hattertar megoldas letezik EP-re, arra mar kesz az sw, es nem kene SymbOS ala ujraimplementalni drivert. Mondjuk egyetlen hatrany az a FAT12 amit EXDOS-nal latok, SymbOS talan FAT32-ot (???) is tamogat, meg persze FAT16-ot (illetve CPC-n pl az AMSDOS CP/M szeru formatumat is, de EP eseten ez mondjuk mind1). Node, semmi nem lehet tokeletes.

Mondjuk egy dolog utott szoget a fejembe, de most jutott csak szembe igy nem neztem meg: van ugye az a videolejatszo app. Mennyire "erezheto" az akadas rajta ami miatt olvasgatnia kell a file-t? Ezek utan kivancsi vagyok :D Lehet, meg is nezem mindjart.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #131 on: 2014.November.02. 10:19:52 »
Ami furcsaságot még találtam: nézegettem az MSX floppy drivereket, és olyan funkció is van benne, hogy logikai szektorszám konvertálása fizikaira. Na de ezt hogyan tudná megtenni, ha a lemez felépítését a fájlrendszer kezelő ismerheti, nem pedig az alacsony szintű lemez IO?

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #132 on: 2014.November.02. 10:50:30 »
Ami furcsaságot még találtam: nézegettem az MSX floppy drivereket, és olyan funkció is van benne, hogy logikai szektorszám konvertálása fizikaira. Na de ezt hogyan tudná megtenni, ha a lemez felépítését a fájlrendszer kezelő ismerheti, nem pedig az alacsony szintű lemez IO?

Nem tudom pontosan mire gondolsz, de amivel en talalkoztam "logikai" szektor szam az valojaban fizikai :) Marmint ugy, hogy egyetlen szammal lehessen leirni track/head/sector helyett. Ennek atvaltasa legalabbis floppy-nal :) az nem igazan fugg a filerendszer tipusatol ugye. Ott vannak amugy a sector offset dolgok stb ami szinten alacsony szintu, es pl az a mar emitett skewing tartozik ide, meg olyasmi - ha jol ertem -, hogy az FDC readid paranccsal is lathato sector-ID-ek valoban 0xC0-vel tobb mint a szektor szam, ezzel detektalhato (?) hogy CP/M disk-rol van szo (raadasul AMSDOS eseten ketto ilyen is van 0x40 es 0xC0, gondolom data/system disk miatt - sajnos en nem feltetlen latom at a CPC-s vilagos, nem biztos, hogy ertem miert kell ez). DOS stilusu disk-en a sector offset allitolag nulla. Szoval ilyen es ehhez hasonlo dolgokat is konvertalgat vmi tablazat alapjan amit a unit aktivalo rutin irogat mint "detektalas" (bar lehet MSX-en ez pont nem focizik mert ott nincs talan CP/M disk formatum, ami CPC-nel kell mert ott lehet az, meg FATxy is!).

Amugy ha symbos.de-rol az MSX mass storage driver-t letoltod (gondolom azt nezed most is?) akkor pl lathato hogy ott az FDCOUT es FDCINP, ezek ami logikai szektorszam alapjan irnak/olvasnak. Az FDCACT az, ami inicializalja a disk-et, es pl megvizsgalja, hogy a sector offset mennyi, hany track van, sector/track stb, es ezt lejegyzi aztan: ez alapjan tortenik az FDCOUT es FDCINP-ben aztan a "logikai szektorszam" konvrtalasa a fizikaira. Es itt filerendszerrol meg szo sincs semmi! Amugy Amit pl latsz a FDC philips.asm-ban peldaul, ott latszik is, hogy fo rutin van kb 3 (amit mas dolgok hivnak), a tobbi mind olyasmi, amit valoszinuleg ezek a rutinok hivnak. A CPC-s memoriakep ugye kicsit talanyos volt, mivel nincs forraskod a CPC verziohoz (tudtommal ...) ezert azt is probaltam mar a vegen, hogy megnezem amihez van (pl MSX driverek) mert ott van legalabb comment hogy mi micsoda, es megprobalok hasonlot keresni a CPC disasm-ban is :) Ez nem olyan egyszeru, amde ha elotte az ember mar kb elnevezte maganak a rutinokat meg kb tudja 1-2-rol micsoda, akkor majdnem ranezesre is latszik, hogy felismertem, hogy hivhatta a szerzo a kerdeses rutinokat valszeg a CPC verzioban is, es mire valo 1-2 dolog benne amire eddig nem jottem ra. Szoval szep kis kirakosjatek :) Persze azt nem mondom, hogy teljesen ertem en ezt meg ...

Online Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #133 on: 2014.November.02. 11:01:49 »
Nem tudom pontosan mire gondolsz, de amivel en talalkoztam "logikai" szektor szam az valojaban fizikai :) Marmint ugy, hogy egyetlen szammal lehessen leirni track/head/sector helyett.
Ezt hívjuk LBA-nak, azaz Logical :-) ezt használja az EXDOS is.

Quote
Ennek atvaltasa legalabbis floppy-nal :) az nem igazan fugg a filerendszer tipusatol ugye.
Éppenséggel a FAT Boot szektorban van leírva, ami szerintem a fájlrendszerhez tartozik.

Quote
Az FDCACT az, ami inicializalja a disk-et, es pl megvizsgalja, hogy a sector offset mennyi, hany track van, sector/track stb, es ezt lejegyzi aztan: ez alapjan tortenik az FDCOUT es FDCINP-ben aztan a "logikai szektorszam" konvrtalasa a fizikaira.
Ok, így már működhet. Mondjuk az a rutin igen hiányosnak tűnik nekem, főleg az EXDOS után :-) Hiba és kompatibilitás ellenőrzést nem igen látok...

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: SymbOS magyar
« Reply #134 on: 2014.November.02. 11:28:34 »
Ezt hívjuk LBA-nak, azaz Logical :-) ezt használja az EXDOS is.

Oke, LBA fogalmat en csak hdd-nel szoktam hasznalni (CHS/LBA), de igazad van, es egyszerubb + korrektebb lett volna igy magyarazni :)

Quote
Ok, így már működhet. Mondjuk az a rutin igen hiányosnak tűnik nekem, főleg az EXDOS után :-) Hiba és kompatibilitás ellenőrzést nem igen látok...

Jo hat, EXDOS-t valoszinu azert alaposabban irtak meg megis, es az egesz EP project nem hobby project volt, a SymbOS meg ugye azert az.

Btw, foleg ha lesz EXDOS-ban 16 bites FAT support, akkor tenyleg mar komolyan erdemes elgondolkodni olyan SymbOS verzion, ami EXOS-t hasznal a file muveletekre, nem is csak disk block I/O szinten, hanem ugymond FS szinten is. Max akkor tenyleg az lesz, hogy nem igazan fog SymbOS futni 128K rammal (bar kerdeses, hogy a rendszerszegmens mennyi helyet foglal "atlag" config eseten, most csak igy JSep-vel azt mondja az IS-BASIC hogy kb 128K ram eseten ~18K foglalt, tehat kicsit tobb mint egy szegmens sajnos. Igaz, kell a videoram-nak is hely pl, stb (illetve nem tudom, hogy IS-BASIC maga is foglal vmennyi RAM-ot es a kijelzes nem feltetlen tukrozi, hogy mennyi szabad RAM lenne a rendszerben, ha csak az a cel, hogy EXOS/EXDOS mukodokepes legyen).