Welcome, Guest. Please login or register.


Author Topic: SymbOS magyar (Read 29045 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #45 on: 2014.October.20. 10:16:17 »
Kisse elakadtam az orult projectemmel. Az egy dolog, hogy 128K-nyi RAM image van nekem disasm-olva es abban probalok rajonni, hogy mit csinal ... Ami mar sikerult: keyboard scan, hogy mikodik, EP-sites. Memorialapozas: tobbe-kevesbe ertem, EP-siteset halasztottam (a kvazi felig CPC/felig EP JsEP modositasom igy kezeli most). Ami viszont problema, es anelkul semmire sem lesz jo (egy alkalmazast sem lehet elinditani, max eger kurzort ide-oda vinni a kepernyon ...) az e lemezkezeles. Ebben kernem a segitseget, ha valakinek van otlete ... A tervem ugye egyenlore az, hogy (mivel extra bonyolult lenne forras hianyaban atirni), hogy a CPC verziohoz adott disk image-t lassa az EP-re "portolt" SymbOS, vagy ugy, hogy memoriaba betoltom (nyilvan 128K rammal nem fog menni, de amugy se menne, mert mar az LPT-hez sincs eleg RAM igy sajnos ...), es onnan "olvasok disk-et", vagy pedig EXOS file muveleteken at, visszalapozva azon idore a rendszerszegmenst stb, mivel azt erintetlenul hagyom.

A terv szep, amde a megvalositasa nem konnyu. A disasm alapjan haladtam vele, a CPC fdc controller IC-jenek leirasa alapjan mar egy csomo dolgot azonositottam, mindenfele csunya dolgokat csinal, rekalibracios seek muvelet stb, haaaat. Ezeket kvazi kiNOP-oztam :-) Amde most odaig jutottam, hogy nem jutok tul egy reszen, ahol vmi readID nevu muveletet nyom el, es nem ertem, azzal mi a celja, vagy az mire valo egyaltalan. A CPC wiki-n van nemi leiras, a kerdeses controller IC-nek is van datasheet-je elerheto, de meg igy sem ertem, mire jo ez a readID, es miert kell neki. Az vilagos, hogy seek-el track-ra all, es akkor ott pl nyomna egy readsector-t (ezt latom is hol van a kodban). Viszont ez a readID baromsag bezavar, es azt se ertem miert kell, miert nem eleg a track seek majd read sector. Illetve, hogy a readID-nek mi az eredmenye, az se vilagos. Valakinek van otlete mire jo ez? Koszi elore is!

Masik: a disasm orakig tarto bamulasa kozepette par dolgot megertettem a SymbOS multiask mukodesebol, erdekel valakit, hogy hosszabban irjak rola, mint erdekesseg, vagy tartsam meg magamnak? :)

Offline geco

  • EP addict
  • *
  • Posts: 5430
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 31.0 Firefox 31.0
    • View Profile
Re: SymbOS magyar
« Reply #46 on: 2014.October.20. 10:29:32 »
Engem érdekel a Symbos multitask.
Az FDC readID-ban sajnos nem tudok segíteni.

Offline Povi

  • EP addict
  • *
  • Posts: 1873
  • Country: hu
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://povi.fw.hu
Re: SymbOS magyar
« Reply #47 on: 2014.October.20. 10:42:28 »
engem is érdekel a lelkivilága :-)
lemezkezelés ügyben pedig lehet, hogy magát a szerzőt kéne megkérdezni
bár kérdés, vajon hogy fogadja, hogy félig már disassembláltad a progiját, gondolom nem véletlenül nem publikus a forráskódja :-)

*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #48 on: 2014.October.20. 10:58:30 »
Egy erdeklodo mar van, ezert remek lehetoseg, hogy kieljem grafoman maniamat, mondjuk a szokasos modon ekezetek nelkul, es nem keves gepelesi hibaval, mint mindig :D

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

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13521
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #49 on: 2014.October.20. 10:59:59 »
Lelkivilága érdekelne engem is! Semmit nem tudok erről az egészről, csak annyit, hogy valami ablakos izé :oops:
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 :-(

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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #50 on: 2014.October.20. 11:15:35 »
Lelkivilága érdekelne engem is! Semmit nem tudok erről az egészről, csak annyit, hogy valami ablakos izé :oops:
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 :)

Quote
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?

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13521
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #51 on: 2014.October.20. 11:24:53 »
És memória térképet is lehetne kérni? :oops:

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #52 on: 2014.October.20. 11:54:23 »
És memória térképet is lehetne kérni? :oops:

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

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13521
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #53 on: 2014.October.20. 12:13:55 »
Kicsit részletesebben lehetne? :oops:

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?

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #54 on: 2014.October.20. 13:16:08 »
Kicsit részletesebben lehetne? :oops:

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

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #55 on: 2014.October.20. 13:22:41 »
Meg egy dolog elozokhoz kepest: valahol olvastam is, hogy a CPC memoriaszervezes miatt a SymbOS kulonbseget tesz, hogy a memoria egyes 16K-s reszein mi lehet es mi nem (EP-nel barmi, CPC-n ez sokkal korlatozottabb). A 0xC000-0xFFFF az a tartomany, amit adatcserere hasznalnak a process-ek kozott, ha jol remlik, gondolom ez is az oka annak, hogy a video pixel adatokat epp ide tettek, hogy elerheto legyen azon system process (process-ek) szamara, aminek kell. Amugy kesz horror, neha egesz hosszu szubrutinok vannak ami memoriacim alapjan kitalalja, hogy mit irjon a CPC gate array-nak RAM config-ra, haat nem mondom, EP-n ez azert egyszerubb lenne :)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #56 on: 2014.October.20. 13:41:14 »
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 :(

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #57 on: 2014.October.20. 13:59:01 »
Mivel a legtobb (mind?) SymbOS alkalmazas a screen manager process-en at rak ki dolgokat (mondjuk video lejatszo az erdekes kerdes, ha igy lenne, holt lassu lenne, de lehet, az nem atlagos alkalmazas, eleve pl abbol van kulon video forumatum is cpc-re es msx-re!), elkepzelheto, hogy SymbOS "normalis" port eseten, bar megmaradnak a cpc-re jellemzo lapozasi korlatok, a screen manager esetleg kicsit at lenne irva, hogy mondjuk tobb mint 16K helyen lasson video adatot. Igy az alkalmazasokat ez a bovites nem erinti, max a specialisokat ahol felig-meddig kozvetlen eleres van (vagy lehet?) pl a video lejatszo app. Persze ezek tippek, ehhez egesz melyen ismerni kene a rendszert, forraskod szinten ...

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13521
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://enterprise.iko.hu/
Re: SymbOS magyar
« Reply #58 on: 2014.October.20. 15:23:19 »
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 :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • 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 #59 on: 2014.October.20. 15:55:46 »
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

No igen, ez erdekes kerdes. A SymbOS irojat kene megkerdezni, de elmeletem azert van ra, mondjuk ellenorizni kene, de azert ime:

Ami biztos: nezzuk eloszor a seek-et (peldakent, kov bekezdes mar a sector olvasas)! Az olyan muvelet, hogy nem kritikus, ha tovabb varsz, mint hogy vege van, de azt meg kell varni, hogy vege legyen azert, es az adott track-re keruljunk.  Ilyenkor, a SymbOS ha varina kell FDC-re szandekosan abba is hagyja a process futtatasat es atadja masnak (aka multitasking, sleep-on-I/O a processnek), es majd ha ujra hozza kerul a vezereles remelhetoleg kesz az eredmeny. Szoval ez nem bug, ez feature :D Ezt probaltam az elso hosszu mesemben kifejteni: SymbOS nem var I/O-ra seek-nel, inkabb atadja a kovetkezo process-nek addig a futas lehetoseget, mert kulonben mi ertelme lenne a multitaskingnak, hogy ott varjon amig vegez, amikor kozbe futhatna masik process ("program") akinek esetleg nem kell a disk, csak CPU idoszeletre ahitozik, mikozben az I/O-t vegzo cucc-nak nem kell CPU mert csak varakozik az I/O-ra. Bolondsag lenne nem kihasznalni, igy mindketten jol jarnak :) Igen, ez kicsit mas feeling mint egy monotasking rendszer pl EXDOS, ahol o szepen varja (kozben nem csinal semmi hasznosat szegeny CPU csak ott varakozik tesztelgetve, hogy kesz van-e) az wd-t, hogy mikor keszul el.

Node, azt nem tudom, valoszinuleg abban igazad van, hogy a sector olvasas _NEM_ ilyen, mert ott ha a megtalalja a megfelelo szektort, ugye azonnal olvasnod kell az eredmenyt, es nincs ido szorakozni, hogy addig mas process fusson, mert mire ujra rad kerul a sor, lehet, mar le is maradtal rola (gondolom a WD es a NEC sem buffereli az eredmenyt, hanem "real time" olvasnod kell!). Jo kerdes, hogy ilyenkor mi van. Egyreszt time critical cuccoknal latni neha, hogy DI ... EI kozott van nemi kod. Lehet egyszeruen azt csinalja, hogy ha nem megszakithato resz van ami fontos, akkor egyszeruen letiltja az interrupt-okat, igy biztosan nem veszi el tole a kernel a vezerlest addig, meg akkor sem, ha amugy nagyon szeretne :) Ez persze olyan szabaly, ami zavarja a multitaskingot nemikepp, hisz "darabosabb" lesz a valtas a processek kozott, mert pl a device manager eroszakkal (megszakitas leiltasaval) maganal tartja hosszabb ideig a vezerlest (atlag user app ne csinaljon DI-t, de van ahol pl system process-nel nem kikerulheto). Dehat ez van, gondonolom vannak dolgok (mint pl ez is) amit nem igazan lehet maskepp megoldani (pl DMA nelkul ...). Persze segitene (de imho EP-n es CPC-n sincs ilyen hasznalva), ha a floppy vezerlo interrupt-ot kuldhetne a CPU-nak ha kesz, igy OS szabadon csinalhatna mast, ugyis kap megszakitast a CPU, ha elkeszul, an interrupt kezelesre kello ido talan nem lenne tul sok (bar ki tudja ...), hogy elkezdje az adattransfert konkretan. Mert ahogy irod is, kozben lehet, hogy a lemeznek majdnem egesz fordulatot kell tennie, es addig mast nem lehet tenni, attol felven, hogy lemaradsz.

Bar most ahogy igy mondod :) Eszembe jutott az, hogy nem lehet-e, hogy pont ezert kell az altalam ertetlenul fogadott readID command? Azaz, elolvassa mi van a fej alatt eppen. Ha a keresett sector eleg messze van, azaz 1/50 masodpercnel tobb ido, akkor megeri masik process-t futtatni addig, es utana probalni ujra. Lehet ezen szepen finomitgatni, ami eleg alien fogalmaknak hangzik a megszokott (nem multitask) 8 bites OS-ek vilagaban azert :) Nemt tudom meg, hogy ezzel a trukkel el-e a SymbOS, vagy csak seek track-nel csinal ilyen soft interrupt dolgot, hogy masnak adja a vezerlest. Ha van kedved megnezni: ahogy nezem 0xADAE cimen van az a kod, ami kikuld egy sector read v sector write parancsot az FDC fele, ez a disasm listam alapjan ket helyrol van hivva, valoszinu az egyik a sector read a masik a sector write, es egyik regiszterben (talan a B? most hirtelen ranezve van eleg trukkos POP/PUSH magia) adja at, hogy a ket FDC parancs kozul melyik. Szoval ezt visszakovetve (megnezni mi hivja azokat a subrutinokat, aztan azokat amiket az hiv, stb) elvileg kiderulne, hogy mit csinal. Epp itt tartottam amugy en is az elemzessel, de 1-2 napja inkabb irkalok/firkalok rola ide a forumba, es nem volt vele idom foglalkozni :(

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

Jo kerdes, ahogy mondtam is, CPC-t azota ismerem, miota par napja erdekel a SymbOS visszafejtese es EP-n futtathatova tetele. MSX-et meg ennyire sem ismerem ... Bar a CPC wiki-n azt irjak emlekeim szerint, hogy az a NEC controller ami abban van floppy-ra tudna DMA-t, de CPC-n nem lehet hasznalni, mert nem ugy van megoldva a dolog. MSX-et meg konkretan nulla egesz nulla szinten ismerem, azon kivul, hogy tudom mi a fogalom.

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

Ja, az cool am :) Foleg egy SymbOS szintu OS-nel ahol mindig kerulendo (de neha nem kikerulheto sajnos!) hogy letiltsa a schedulert az ember (azaz letiltsa az interrupt-ot), mert annak mindig negativ hatasa van a multitasking "folyamatossagara".
« Last Edit: 2014.October.20. 16:19:02 by lgb »