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