Olvasgatom a doksikat, de még nem állt össze bennem a kép annyit értek, hogy a CPC vacakul tud memóriát lapozni, ezért az a alap, és lesz jó bonyolult minden

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.

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?

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

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.

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 Lehet, meg is nezem mindjart.

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

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

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