Egy ismerősöm arcade kabinetet akar építeni magának, és miután leszóltam a TFT verziót, elkezdte érdekelni a CRT ...

Ő is RPi -vel nyomul, és kiderült hogy az RPi -n van composite video out, és támogatja a 5xxi -t, 480i -t, meg ilyesmiket,
vagyis ilyen régi CRT TV -ket, composite video bemeneteket meghajtani tökéletes,

és erőlködnek rajta, hogy minnél korrektebb progresszív működésre is rábírják.


Szóval ezeken tipródunk itt, és közben eszembe jutott egy kérdés az ep128emu2 -vel is ...


Ha egy eszköz, amin fut az ep128emu2, az támogatna valami ilyesmit mint 240p vagy 312p, vagy mittudoménmit is kéne támogasson
(nem feltétlenül az RPi, csak elvileg),
akkor lehetne az ep128emu2 -t úgy futtatni rajta, hogy a pixelek 1:1 arányban legyenek kirajzolva ?

Tehát arra gondolnék, hogy ami az emulátorban az EP -nek 1 scanline, azt valóban 1 scanline -al rajzolja ki a monitor ?
Tehát ha mondjuk 240p -t támogatna valamelyik hardver amin fut az ep128emu2,
akkor azt tekintenénk annak a függőleges területnek, amit annó a TV meg tudott jeleníteni,
az itt az emulátorban mondjuk beállítható lenne, hogy a 312 sor melyik 240 sorát jelenítse meg,

de fontos lenne (nyilván), hogy az igazi (mondjuk 240p, PC monitor) szinkronjához legyen szinkronizálva az EP,
és mind vízszintesen, mind függőlegesen 1:1 legyen a pixelek aránya.

Így akkor el lehetne -e érni, hogy ami az emulátorban egy scanline, azt ténylegesen a monitor (TV) 1 scanline -al rajzolja ki ?
(Feltételezzünk mondjuk egy TV -t monitornak, ami ugye 15 KHz képes.)

Tudnánk kapni így "ugyanolyan, hardver scanline -os" képet egy TV -n az emuból,
mintha igazi vas EP lenne ugyanarra a TV -re kötve ?
(Azzal a különbséggel persze, hogy a szinkron az kötött maradna,
ha 240p, akkor mondjuk 240p, és szoftver vágná be a képet 240p -re.)

Ha igen, milyen nehéz lenne ezt beépíteni az emulátorba ?

A 288 soros (interlace nélkül) látható függőleges felbontást a forráskód több helyen "bedrótozva" tartalmazza, így nehezen módosítható. De megoldható olyan módosított verzió, ami levágja valamilyen kisebb fix méretre, például 240 sorosra.

Magára az RPi -re egyébként vannak kész image -ek, amiket csak rá kell másolni egy kártyára,
és a "világ minden emulátora" rajta van, tényleg rengeteg, én néztem,
az összes konzol, csomo arcade, 8 bites gépek, Amiga, minden ...


Az ep128emu2 -t egyébként mennyire lehet leforditani mondjuk Raspbian alá ?
A Raspbian az egy Linux disztró, a "hivatalos" RPi OS.

Maga az RPi ugye ARM, és a GPU -ja HW -ból OpenGL ES 2 -t tol ...


Nagyobb művészet lehet ?
(Én annó nekimentem desktop Linux -on hogy biztos pikpakk lefordítom,
hát tévedtem ... )

Sot szoftverbol emulalva ugy nezem van OpenGL 3.0 is ... csak hat az teljes kepernyon 10 FPS kb. 3 fogaskerekkel, "semmi" pixel shader -rel ...

De vegulis nekem epphogy az kene ugye, hogy ne legyen semmi effekt a kepen, es csak 240p -be menjen siman ...

Szoval ez valszeg siman mehetne ...

Lehet meg kene probaljak egy ilyen RPi ep128emu2 build szalat is parhuzamosan futtatni a tobbi vackommal ...

Oh, tankju, de meg az odebb lesz mire szukseg lesz ra ...

Eloszor megprobalom leforditani egy sima Ubuntu -n megint,
mert korabban meg azon sem sikerult ...

Es ha azon mar lefordult, akkor majd johet a Raspbian build ...


De Intel assembly optimalizacio nincs akkor az ep128emu kodban ?
(Mittomen CPU emulacional, vagy valami ...)


Mert ha van benne (nem opcionalis) Intel assembly,
akkor eselyem se lenne leforditani ARM -re ...

Mielőtt még tele blogolnám az ep12emu topikot, nyitottam egy sajátot az RPi build -nek ...

Na jól van, ez is simán ment a normál desktop Ubuntu build után. (IstvanV a király!)

(Csak itt még össze kellett hekkelni a curl -t is, mert addig nem voltak ROM -ok ...)


Viszont nem éppen rózsás a helyzet ...


Hardveres OpenGL támogatás mellett
(ha a Raspbian -ban bekapcsolom hogy hardver desktop GL legyen az OS alatt, ne a GLES),

akkor ugyan a CPU terheltség nem lesz nagy nagyobb ablakokban sem,
de maga a képfrissítés sebessége és a reszponzivitás leesik ha bármi nagyobb grafikai minőséget állítok be 0 -nál
(még a dublabuffer is lassít ... ),

ha pedig nem kapcsolom be a hardver GL -t a Raspbian alá, akkor még 0 -ás grafikai minőség mellett is jelentős a CPU terhelés,
legkisebb ablakméretben 45%, közepesen 75%, nagyon 85%.

Az emu közben végig azt mutatja hogy 100% -on fut.


A hangot egyből kikapcsoltam, azzal most nem akartam vacakolni,

viszont valamiért a billentyűzet sem működik jól,
valamiért szinte csak az alfanumerikus billentyűkkel lehet gépelni,
a jelekkel nem ... még nem jöttem rá miért ...
(ha kézzel beállítom, akkor működik a többi billentyű is).

Persze mindez nem akadályozná meg azt, mait én akarok:

Nekem a legkisebb ablakméret is elég,
és ugye azt akarom rendes 15 KHz -es display -en jeleníteni meg ...

Persze a keretekkel még majd meggyűlne a bajom,
de valószínűleg ha beleteszem a fullscreenbe váltást mindjárt az elején,
inicializálás környékén, akkor jó lesz ...

(Hiszen a menü 3 fázisú ablakméret változtatását elfogadja HW GL módban is,
valamint nekem igazából mégcsak be se kell kapcsoljam a HW módot,
mert 240p -ben elmegy CPU -val is 45 % -al ...)


Ki tudja egyébként használni a magokat az emu elvben ?
(Ki kéne tudja, ha az RPi -n a CPU mérőke nem teljesen sz**,
és azt jelzi, hogy kihasználja 85% -ra nagy ablak méretnél ...)