Engem érdekel a Symbos multitask.
Az FDC readID-ban sajnos nem tudok segíteni.

Egy erdeklodo mar van, ezert remek lehetoseg, hogy kieljem grafoman maniamat, mondjuk a szokasos modon ekezetek nelkul, es nem keves gepelesi hibaval, mint mindig

Szoval, a SymbOS alapvetoen mikrokernel felepitesu rendszer. Errol azt kell tudni, hogy ilyen modern OS-eknel is van, alapvetoen monolitikus- versus mikrokernel szokott lenni a ket irany. A monolitikus kernel az, hogy a kernel es funkcioja "egyben" van (ebbe beletartozik az is, ha be tud tolteni egy dolgot, amit "belancol" a kernelbe, innentol viszont resze lesz!). Anno amugy Linuxnal ez okozott vitat Linus Torvalds (aki irta a Linux kernelt ugye) es a professzora kozott: az utobbi szidta tanitvanyat, hogy miert monolitikus kernelt tervez, amikor a mikorkernel elmeleti megfontolasok alapjan modernebb. Amde hozza kell tenni, hogy a mikorkernel valamivel lassabb is az un context switch-ek miatt, ami regebben foleg problema volt szerenyebb teljesitmenyu hardware-ek eseten. Mivel egy 8 bites rendszernel (lasd pl EP ...) alapvetoen nem szokott hw-es context fogalma meg hw-es memoriavedelem stb lenni, itt ez kevesbe erdekes

Szoval mikrokernel: a kernel alapvetoen picike, minimalis dologra jo. Meg egy modern hw-n levo mikokernel is akar csak par Kbyte koddal rendelkezik! A lenyeg az, hogy minden mas funkcionalitast ado dolog az ugy fut, mintha userapp-okhoz hasonlo process-ek lennenek (tehat nem a kernel resze), es ezek kommunikalnak egymassal. A mikrokernel egyeduli feladata kb csak az, hogy ezt koordinalja. Alapvetoen tehat a mikokernel onmagaban semmire sem jo persze, nem ad "funkcionalitast", max pl uzenetkuldes lehetoseget mas process-nek, de ha nincs ott az a masik process, meg disk-et sem eri el stb, mert azt is ilyenek csinalnak. Na, a SymbOS valahogy igy epul fel. Alapvetoen egy user process (de amugy egy system process is ...) uzeneteket fogadnak es kuldenek egymasnak. Azaz pl file olvasas nem ugy van, hogy a kernelt hivod (pl EP-s pelda egy EXOS funkcio), hanem uzenetet kuldesz a device manager process-nek, hogy legyen szives tenni mar vmit, es varakozol a valaszra.

SymbOS-ben a 0x38-as cimen ulo hw interrupt 50Hz-es rataval erkezik (valojaban CPC-n 300, azt hiszem ott kotott a 300Hz, de azt csinalja a SymbOS, hogy minden hatodiknal csinal csak vmit, kulonben visszater kb azonnal, tehat effektive 50Hz, EP-sites soran pl ezt en kiirtottam - igy gyorsabb is vmivel nem kell vizsgalni - es a nick VINT okozza az interrupt-ot). Egy-egy futo process/app/ahogy hivjuk (legyen az user vagy system jellegu is) csinal amit akar, amde amikor jon ez a megszakitas, akkor a SymbOS szepen felfuggeszti azt (letarolva aktualis regiszter ertekeket stb) es atadja egy masik futasra varo process-nek a CPU-t (itt fontos, hogy SymbOS-ben process prioritasok vannak, ez a modszernel csak olyan kaphatja meg a vezerlest, akinek nem alacsonyabb a prioritasa, ez gondolom arra jo, hogy egy vegtelen ciklust futtato user app ne okozza azt, hogy szegeny system process-ek sem kapnak CPU idot az utemezotol - scheduler). Van viszont arra is lehetoseg, hogy egy process "onkent lemondjon" (hw interrupt nelkul) a futasrol, mert pl var valamire, pl egy uzenetre egy masik processtol. Ez az un "soft interrupt" amit a process maga kezdemenyez. Ez persze jo, mert minek foglalja a CPU-t a kovetkezo "hard interrupt-ig" (amit a valodi VINT okoz), ha amugy nincs mit csinalnia. Amugy a soft interrupt az RTS 0x30 (ami jelen esetben ugye nem az EXOS hivasa ...). Hasonlo muvelet meg az uzenet fogadasa, ahol pl process addig "alszik" (= nem kap ujra CPU idot) amig nem kap uzenetet egy masik process-tol.

Namost, ami erdekes a disk kezeles kapcsan: a disasm-ot tanulmanyozva lattam, hogy milyen okos modon van ez SymbOS-ben megcsinalva. Legyen a kovetkezo a gond: valaki file-t szeretne olvasni. Most ugorjunk rogton oda, hogy mar konkret disk block-ot kene olvasni. Ez ugye idobe kerul, seek-elni kell, stb. Ez egy egyszeru monolitikus/monotasking rendszer eseten nem ugy: var szepen addig, amig nincs kesz. Ez SymbOS eseten kisse gaz lenne, ui akkor addig mas program nem futhatna. Ergo addig "megfagyna" a felulet. Amde a SymbOS ennel okosabban van megirva, hala a mikorkernel architekturanak, es ami ebbol kovetkezik, hogy a disk I/O -t vegzo cucc is csak egy "process" es nem a kernel resze. Az van, hogy a megfelelo process ami ezt csinalja (es ami ugye uzenetet kapott egy pl user app-tol hogy neki kell olvasnia disk-rol, ez a user app valoszinuleg kozben "alszik" amig nem kap valaszt) elkezdi a muveletet, eloszor is pl masik track-re kell seekelnie. Ebben az esetben pl CPC-n az FDC vezerlot nezi, hogy meg busy-e. Ha igen, akkor nyom egy soft interrupt kerest a mikrokernel fele. Ergo, amig a disk dolgozik, megkapja mas process a CPU-t hogy fusson, a rendszer "nem akad meg" addig! Megakadas nyilvan akkor lesz, ha masik process is van, ami disk I/O-zna, hiszen ha megprobal uzenetet kuldeni a device manager-nek, az mar alszik az elozo I/O befejezetlensege miatt, vagy ha eppen csinalja is a konkret olvasast, addig nem fog ujabb uzenetet venni, tehat az a masik I/O-s msg-t kuldo process mar aludni kenyszerul.

Ebbol kovetkezik az en orult projectemnek a limitacioja is: ha tegyuk fel, hogy szimulalom a CPC disk-et EXOS funkcio hivasaval, nyilvan a fenti trukk nem fog mukodni, mert ehhez magat az EXOS-t kene SymbOS processkent megirni Azaz, ha ezt meg is tudom oldani, a valodi es rendes EP SymbOS verziotol elteroen megakadast fog okozni azonnal ... Ez mutatja azt is amugy, hogy miert nem lehet normalisan meg forras eseten sem SymbOS-t raultetni EXDOS/EXOS-ra, es miert kell neki hw szintu hozzaferes mindenhez, kikerulve az dott gep eredeti OS-et, mivel a SymbOS felepitese egyszeruen nem osszegyeztetheto az EXOS/EXDOS mukodesevel, ahol szo sincs mikrokernelrol, de foleg nem multitaskrol.

No, nem tudom erdekelt-e vkit, amit osszehordtam itt, szerintem erdekes. Ez azonban az en velemenyem

Fontos: mivel az infokat nagyreszt disasm alapjan szereztem, en olyan fogalmakat hasznaltam ami OS-eknel szokasos, lehet SymbOS iroja tok mas nevekkel illetne ezeket, nem ahogy en elveneztem, de funkcioban kb azt jelenti

Lelkivilága érdekelne engem is! Semmit nem tudok erről az egészről, csak annyit, hogy valami ablakos izé
Az angol topicban is írtam, hogy többet kéne tudni róla, hogy lehessen a legalkalmasabb EP verzióról gondolkodni, de a szerző még nem kezdett mesedélutánba

Elkestel, fentebb mar kiadtam magambol a novellat

ReadID, ha jól tippelem WD-s tapasztalataim alapján megmondja neked, hogy melyik oldalon/sávon állsz, ezt használja az EXDOS is lemezkompatibilitás ellenőrzésére.
Ha a 1. oldalról olvas ID-t, és 0. oldalit talál, akkor egy kétoldalas lemezt raktunk egy oldalas meghajtóba. Hasonlóképpen ha 4. sávról olvas, és 2. sávot talál, akkor 80 sávos lemez van 40 sávos meghajtóban.

Na igen, kb azert gondolom mire jo, csak nem sikerul rajonnom, milyen ertekeket kene visszaadnia, SymbOS-t futtatva es emulalva a dolgot nem lesz tobb I/O es kozli, hogy disk error 00 vagy hasonlo. Valoszinu, azert, mert ellenorzi a kapott ertekeket (ami jelen esetben 7 byte a readID-re) de a kod itt olyan szovevenyes, hogy eddig mindig belekeveredtem, amikor megprobaltam rajonni, hogy mi nem tetszik az emulalt ertekeimen neki Pl a SectorID nem tudom mit jelent. A SymbOS oldalarol letoltheto CPC verzio (amibol kiindultam) ugye tartalmaz egy disk image-et, amit elobb meg kellett fejtenem: kisse misztikus, mert nem sima data stream a byte-okrol hanem olyan infok is vannak benne hogy pl gap meret, es igen, sectorID. A gond az, hogy a diskimage-ben a sectorID-re minden letezo helyen az van hogy (ha jol emlekszem most!) 193, semmi mas. Ha ez a sectort azonositja, mert nem mas mindenhol, pl az adott track/head-en levo sector szama?

És memória térképet is lehetne kérni?

http://lgb.hu/temp/symbos-cpc-memory-dump-128k.dump

Ez a 128K mentve a CPC memoriajabol. Ugye ezt probalom patch-elgetni, hogy EP-n elfusson majd Ebbol az also 64K az ami a CPC-n a "base page", ebben van a video RAM is, elvileg ha jol emlekszem 0xC000-tol, tehat ha ott megnezed mi van a dump-ban epp a felulet kepet kapod, 4 szinu modban a CPC-re jellemzo "8 reszre szetszort" cimzessel. A felso 64K pedig a "memory expansion" vagy mi persze. EP-n ez valojaban nalam forditva van (de mindegy, mivel EP szegmensegeket lat, neki mind1, hogy "valojaban" milyen sorrendben van) azaz, ami a memory dump-ban az elso 64K az EP-n nalam az F9-FC szegmens, a masodik CPC 64K pedig az F5-F8. Ezt azert csinaltam igy, mert lattom, hogy alap 128K-ban ugyse fer el (a plusz CPC-t emulalo hosszu LPT miatt pl, meg amugy is akartam majd ugye EXOS-on at emulalni a disk-et disk image file-bol akkor meg pl a rendszerszegmenst sem art nem felulirni stb), akkor meg mar legyen ugy, hogy csak a SymbOS altal hasznalt 0xC000-0xFFFF tartomany essen EP-n videoram-ra, mert annak elerese ugyis lassabb Meg eleve teljesen video ram-ra tenni a CPC also 64K-jat nem tul jo otlet a fenti okok miatt (exos hasznalhatosag kozben, illetve LPT-nek kell videoram, amihez kell nem hasznalt ep vram szegmensbol kb 3Kbyte minimum).

Szoval az en tervezett amator EP-s SymbOS-em max demonak jo es alap EP-n nem is futna 128K rammal Nyilvan hivatalos port eseten, foleg, ha kiirtjak belole a CPC-s videoram szervezest, az LPT bezsufolhato a normal 128K ram-ba, illetve eleve EP-s driverekkel nem kell az OS-hez se beszelni kozben (mint nalam a tervezett emulaljuk a disk-et disk image-bol funkcio ...), igy az normal 128K-s EP-vel is mukodhetne elvileg, ahogy 128K-s CPC-n is megy (az mas kerdes, hogy irja: 128K az valojaban nem eleg normalis futasra, vmi 21K szabad RAM marad, ha semmi alkalmazas nem fut, eleve pl hatterkepet ajanlja kikapcsolni ekkor: amugy bar 21K elegnek tunik hogy az LPT-t bezsufoljam CPC-s szervezes eseten is, a gond az, hogy nincs fix cimem, es SymbOS kozbe ossze-vissza hasznalja a RAM-ot, nem tudom garantalni hogy LPT-t ne irja felul, ha csak bevagnam valahova).

Kicsit részletesebben lehetne?

Ilyenekre gondolok hol lakik a kernel, a driverek, az alkalmazások...
A videó RAM-ot említetted, ez egyben azt is jelenti, hogy max 16K videó memóriát tud kezelni? Magyarán akkor az kizárva, hogy EP-n teljes képernyős legyen (border nélkül), mivel az már nem fér egy szegmensbe?

Fogalmam sincs, hogy oszinte legyek, hogy a nagy "katyvasz" (128K memoria tartalom) pontosan hogy oszlik meg, azaz ebbol melyik a kernel stb. Pont az volt a lenyege, hogy forras ismerete nelkul csak memoria dump-bol abbol indultam ki, hogy a SymbOS mar inicializalva van, nem kell torodnom vele, hogy ki kivel mivel stb. En azt csinaltam, hogy az "epbas" projectem kereteben levo disassemblerrel disasm-oltattam az elso 64K-t es a felso 64K-t kulon. Adtam neki "code hints"-et (tehat hol biztosan kod van) az RST cimekre, es mivel a disassembler a projectemben koveti az ugrasi stb utasitasokat, eleg turheto eredmenyt adott (aprobb vicc benne, hogy az RST 0x30-at a kov byte-tal elnevezte EXOS n -nek, hehe). En ebbol indultam ki, pontosabban kezdve a hw interrupt vectorral, tehat a 0x38 cimen. Ugy tunik, hogy a felso es also 64K egy darabig azonos, nem csoda, mert interrupt akkor is lehet, ha a felso van belopzva, ezert talalkozunk mar az elejetol nem messze CPC memorialapozassal. Illetve azonnal latszik az is, hogy az AF' regisztert hasznalja arra, hogy a velhetoen 300Hz-es (oszinten fog'sincs CPC-t semennyire nem ismertem elotte, ez a project miatt kezdtem tanulmanyozni!), hogy 50Hz-et "csinaljon" belole, ugy, hogy minden 6.-nal csinal erdemben csak valamit. Gondolom a speed miatt is van, hogy az AF' erre van fenntartva, masra nem hasznalhato (ne kelljen menteni mindig). Amit meg tudok, hogy az I regisztert erdekes modon szinten fenntartja, es abban a CPC memoria config van, gondolom ugyanazert: ne kelljen letarolni memoriaba es beolvasni kulon mindig.

Ezek utan azt a modszert alkalmaztam, hogy a modositott EP emulatormban (ahol loggolok most 16 bites I/O-t, es emulalok is jelenleg par dolgot az alapjan) lattam, hogy melyik PC erteknel van valami port iras/olvasas. Ezt persze korrigaltam a CPC  memoriaconfiguracio szerint, hogy "linearis" 128K-s cimet kapjak, ami a memoria dump-ban ertelmezheto. Ez alapjan nezegettem a disasm listat, hogy mi van azon a kornyeken, igy jottem ra par dologra, pl hol a keyboard scan, mi alapjan csinalja, stb, ezt sikeresen modositottam is. Amugy 0x1527-nel kezdodik, HL altal letarolja a kbd matrixot 10 bytenyi memoriaba (az elotte levo sok OUT az gondolom CPC-n azert kell hogy felprogramozza ehhez a megfelelo adatiranyt miegymas, EP-n ez total nem kell es felesleges). Ezek utan a "modosito" billentyuket (SHIFT, ALT - ez utobbi valojaban a COPY gomb a CPC-n ha jol nezem a matrixat, es CTRL) kiirja egy kulon byte-ba (0x14FC). Ezek utan a 10 byte-ra bitenkent hivatkova ad egy "billentyu indexet" (0...79), es ez alapjan hivatkozik a billentyukre innentol. 0x15B2-nel nezi caps lock-ot pl, utana meg hogy alt le van-e nyomva aztan kurzorvezerlo gombokat (ALT+kurzor gombokkal lehet eger nelkul SymbOS-ben navigalni). Ilyesmik. Ami meg feltunt: 0x15711 cimen (azaz a masodik 64K -ban) van 4 tablazat egymas utan ami gyanusan a CPC matrix gombokat mutatja, imho a fenti "system level" kbd.index-ek utan ezen tablazat alapjan konvertalja az egyes gombok erteket arra, hogy minek felel meg (pl karakterkod). Gondolom azert van 4db tablazat egymas utan, mert sima, shifted, ctrl-al es alt-tal, talan

Most tobb peldat nem irok, szovegesen hosszu lenne, es igazabol egyben csak text file-ba rittyentettem le magamnak, a disasm listat se igazan dekoraltam meg ezekkel fel A disk kezeles kapcsan is van persze par cimem, ahol latom es kb ertem is, hogy mi tortenik, a ket alapveto rutin amugy: 0xACDD/0xACE0 (1 byte-ot kuld ki, elotte var az RQM jelre az FDCctrl status regiszterben az 0xACD4 kornyeken, ket cimet azert adtam, mert egyiknel I/O cimet beteszi BC-be, masiknal meg nem, ez utobbi nyilvan azert mert mar ott van, ha vmi ezt hivja) es az 0xACF3 (1 byte-ot olvas, szinten RQM-re var). Ha ezek alpajan nezed, hogy mi hivja ezeket a rutinokat, egesz jol kirajzolodik a dolog, a write elso hivasa a command fdc-nek, ami CPC wiki-ben szepen ott van, tehat igy nem tul macera modon kb megvan, hogy a kodban hol, milyen FDC muvelet zajlik.

Bocsi, hogy csak leirom, tenyleg lusta voltam ezt asm-ban felkommentezni, foleg mivel sajat diassembleremet hasznalom ami ugye sajna nem eleg intelligens: ha ujra kene disasm-olnom, akkor kezdhetnem elolrol a comment irast Tudom van IDA miegymas, de nekem az Linux alatt sose jott ossze igazan, meg mindig a sajat cuccom volt szamomra a hasznalhato.

A video memorias kerdesed: legalabbis ugy tunik, hogy a CPC-n adott a 320*200-as felbontas 4 szinnel (symbos site-on emlitenek 2 szines 640*200-at is amire at lehet allitani), ugye mindket fenti felbontas pont 16ezer byte. Gondolom CPC-n nem lehet olyan szabadon allitani a felbontast CRTC-vel (vagy igen?), ezert lett ez a felbontas. Vagy talan azert is, mert a CPC memoriaszervezese (lapozas) eleg gaz (EP-hez viszonyitva). Szerintem nem lehet igazan vele olyat csinalni, hogy ket egymas melle eso 16K-s reszt "egyszerre" lapozni. De mondom, CPC-hez csak feluletesen ertek par napja. Az iroja is egyszer emlitette ugye, hogy alapvetoen a CPC korlatai minden portnal megvannak, ott is, ahol amugy a hw tudna tobbet, mert az a cel, hogy menjen minden eddigi rendszeren, es az applikaciok is "hordozhatoak" legyenek, azaz barmelyik CPC porton ugyanugy fussanak valtoztatas nelkul. Amennyire tudom, a CPC is tudna elvileg talan felbontast novelni valahogy, csak a memorialapozas miatt kevesbe lehetne egy ilyen OS-ben ezt normalisan kihasznalni. Nem tartom kizartnak, hogy esetleg forras szinten nezve a screen manager (vagy hogy hivhatjak) process modosithato ugy, hogy nagyobb legyen a kep, ez viszont szerintem olyan jellegu modositas ami 128K memoria dump alapjan allat nehez lenne vegigverzni a rendszeren csak binarisan "patch-elve". Bar nyilvan nem lehetetlen ... az is lehet, nekem nincs ehhez akkora tehetsegem, az FDC-vel is azert szenvedek

Bocs, ha esetleg csalodast okoztam, de en csak ilyen modszerekkel ismertem meg a dolgot, nem tettem kulonbseget hol a driver hol a kernel hol a system app, stb, csak sima memoriatartalomkent kezelem es probalgatom atirni

Amugy amit mondtam FDC-rol, es multitaskrol SymbOS-ben az elozo hosszu leirasomban, pl nezd meg a kodot kb itt: 0xAD76
Ez kuld egy 8-as parancsot (LD A,8 majd hivja a write byte-ot) az FDC-nek ami a sense interrupt state. Utana azonnal olvassa az eremdenyt, majd nezi az 5-os bit-et ami a seek end, ha jol remlik. Ha a seek meg folyamatban van, nyom egy RST 0x30-at. Na ez az, amit taglaltam a multiasknal: ha az FDC-ra varni kell, akkor inkabb soft interrupt-ot ker a system app, es azt mondja: "varni kell a seekelesre, addig fusson mas process es ne unatkozzon a CPU az fdc-re varva". Kb

Nem tudom ezekkel a leirasokkal mit segitettem ...

Ize, na bocsi, sorban jutnak eszembe a dolgok Szoval egy CPC app egy relokacios tablaval es fejleccel ellatott file-ban vannak, amit a fejlecben levo SymExe10 alapjan en is ennek hivok Azt nem tudom, hogy driver-ek is ilyen formatumban vannak-e, szerintem nem (az se vilagos, hogy ezt mar SymbOS tolti be, vagy a loader meg a kernel valodi futtatasa elott). Ami viszont erdekes (errol vhol leiras is volt ...), hogy a SymExe10 formatum alapvetoen harom kulonbozo memoriat kulonboztet meg, es meg van szabva, hogy melyiket hova lehet tenni, illetve ennek a korlatozasnak is pont a CPC memoriaszervezese az oka, nevesint: nem lehet barmilyen kombinacioban 16K-kat lapozni sajna (nem ugy mint EP-n). Elvileg csak EP-re lehetne SymbOS-nel optimalisabb OS-t irni de szerintem egy SymbOS-nek is orulhetunk siman Vagyhat orulhetnenk.

Talan amugy az MSX portnal irja, hogy az MSX hw is sokkal rugalmasabb memorialapozast tenne lehetove, de a CPC-vel valo kompatibilitast meg kell tartani, mivel nyilvan nem akar kulon OS-t fejleszteni mindegyik gepre, a memorialpozas pedig erinti pl maganak az applikacioknak a felepiteset is, tehat innentol mar az app-ok se lennenek mindegyik SymbOS porton futtathatoak, ha itt komoly elteres lenne

Tehát ha jól értem egy driver vagy akármi, max 1/50-ed (0.02) másodpercig futhat?
Ep-n ezzel a korláttal szerintem nem lehet floppyt kezelni.
Legrosszabb esetben egy teljes fordulatot kell várni a szektor írás/olvasás parancs kiadása után, és egy fordulat az 1/5 (0.2) másodperc, ami már 10x annyi idő...
Maga az 512 bájtos szektor átvitele 0.016386 másodperc, vagyis 0,003616 másodperc jutna a parancs kiadására, és a szektor megtalálására. Olvasásánál még ugyan lehetne hagyni a fenébe, ha nem sikerül időn belül elkezdeni, de írásnál ha nem toljuk az adatot a WD-nek amikor kéri, akkor tele írja 00 bájtokkal a szektort.

CPC/MSX esetén van hardver IRQ-ja vagy esetleg DMA-ja a floppynak? És ha van, akkor azt használja a SymbOS?

IDE/SD esetén nincs gond, ott a parancskiadási részen kívül akár BASIC-ből is mehet az átvitel