Enterprise Forever
:HUN => Emulátorok => EP128Emu => Topic started by: Z80System on 2018.November.06. 00:41:09
-
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 ?
-
komolyan kezdek aggódni érted :)
amúgy szerintem neked a 8 vagy 16k monitor lesz a megoldás. ott már nem fogod nagyítóval se látni hogy 1 pixel az juj hajaj juj juj 1.01 pixelen jelent meg :)
:D
-
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ó. :oops: De megoldható olyan módosított verzió, ami levágja valamilyen kisebb fix méretre, például 240 sorosra.
-
De megoldható olyan módosított verzió, ami levágja valamilyen kisebb fix méretre, például 240 sorosra.
Na közben én néztem ezt az RPi -n, és ezen az új RPi -n (3B+) állítolag már megoldottak a 240p -t
(nem tudom a pontos sorszámokat most, de mind a pal mind a ntsc felbontású progressziv képet),
és az RPi azt tudja tolni a komponens video kimenetén (ami korábban csak az interlace -eket tudta),
ill. már csináltak hozza 15 KHz RGB scart kimenet kártyát (van az RPi -nek mindenféle precíz kép kimenete),
amivel állítólag tükör kép van (mert ugye a kompozit attól még kompozit minőség marad, hogy progresszív és nem zizeg).
Szóval maga az RPi ezt teljesen tudná, rá lehet kötni a 15 KHz SCART bemenetekre is, progresszívben.
Ha egy utolsó poszt processzing lépésben lenne a végső crop, az úgy teljesen jó volna, persze.
Nem is gondoltam, hogy belülre kéne tenni ...
csak az kéne, hogy valami shortcut key -jel mozgatni lehessen a window -t (amit látunk a teljes EP képből),
és ennek a window -nak a méretét be léhessen állítani a settingsben,
és a kimenetet pedig raw pixelekre lehessen állítani, semmi filter semmilyen irányban, 1:1 pixelek ... nem ?
És akkor a TV -n elvben ugyanazt kéne lássam, mintha az EP generálná a cuccot ... nem ?
És csak a TV "filtere" lenne a nyers pixeleken (video jelen) ...
-
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 ... :))
-
Na kozben ugy tunik sikerult az RPi -n bekapcsolni teljes OpenGL 2.1 -et ...
Mi az ep128emu2 OpenGL igenye vajon ? Hasznal modern OpenGL -t, vagy eleg neki a 2.1 is ?
-
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 ...
-
Mi az ep128emu2 OpenGL igenye vajon ? Hasznal modern OpenGL -t, vagy eleg neki a 2.1 is ?
Elvileg elég a 2.1.
320x240 felbontásúra módosított gldisp.cpp:
[attachurl=1]
-
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 ... :oops:
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 ... :)
-
Na eddig annyit sikerult elérnem vmware/ubuntu parossal,
hogy lefusson az elore leforditott binaris ... :)
Megy rendesen, OpenGL effektekkel is,
de az F9 -cel mikor fullscreen -ben kéne lennie,
akkor csak eltünteti a rendszer menüket,
de nem méretezi az ep128emu2 ablakát teljes képernyősre,
hanem hagyja akkorán mint amekkora volt,
és továbbra is látszik a többi ablak a desktop -on
(kivéve rendszer menük, rendszer bar -ok) ...
Ez valami ismert bug linux -on, vagy mi ?
-
Mielőtt még tele blogolnám az ep12emu topikot, nyitottam egy sajátot az RPi build -nek ...
-
Hopp ... hát ez váratlanul egyszercsak lefordult ... :)
De legalábbis úgy tűnik ... :)
Pedig csak a kötelező csomagokat tettem fel, és csak az FLTK -t fordítottam forrásból.
(Mert ha nem forrásból telepítettem az FLTK -t,
akkor miután már YES -t mondott az FLTK -ra a scons script az elején,
azután egy tömören informatív "NO" sorral leáll ... :))
Eléggé más lett a menü fontja, viszont a fullscreen hiba megmaradt ... :(
Na akkor most átmegyek egy RPi -s topikba, megpróbálom akkor lefordítani arra is ...
(Hátha vak tik is talál szeget ...)
-
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).
-
Ja, és persze ha a HW gyorsítás nélküli módon futtatom,
akkor működik az F9 fullscreen, de az 1280 -as felbontásomon az jelenleg használhatatlanul lassú
(még 0 -ás grafikai minőségnél is),
ha pedig alárakom a hardver gyorsítást, akkor itt sem veszi észre az alkalmazás ablak mérete hogy "kiváltották fullscreenbe",
marad azon ami utoljára volt beállítva a menüből. (Ilyenkor az ablak kerettel való átméretezésre sem reagál a renderelt kép.)
-
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 ...)
-
És íme ni :
[attach=1]
-
Most akkor ha szereznék ilyen RPi -hez való kompozit video kábelt,
vagy esetleg egy RGBHV SCART kimenet kártyát,
akkor el lehetne kezdeni kísérletezni a TV -immel ... :)
Vagy pedig má milyen meta lenne az,
ha miután ily módon generáltunk egy 15 KHz -es EP jelet,
akkor azt valami scaler -en keresztül valami modern VGA monitorra tolnánk ... :smt042 :ds_icon_cheesygrin: :smt043
-
Sziasztok, felújítanám ezt a topicot!
Most vettem egy RPi 400-ast, és érdeklődnék, hogy nincsen valakinek véletlenül Raspbianra lefordított csomagja az ep128emu-ból? Milyen sikereket sikerült elérni?
Köszi előre is!
K.
-
Ugyan nem tudok kész csomaggal szolgálni, de azt tudom, hogy egyszer valakinek sikerült Androidra lefordítani az ep128emu testvérét, a plus4emu-t. Itt (http://plus4world.powweb.com/forum/34979/-/android) van a recept hogyan sikerült. Ennek alapján nem tűnik túl nagy ördöngösségnek. És még azt a Debianos furcsaságot sem kell hozzá telepíteni.
-
Ma én megpróbáltam lefordítani mindkét emulátort.
Egy 4 gigás pi 4-et használtam friss, 64 bites raspberry os-sel, usb boot-os külső ssd-vel.
Látszólag rendben lefordult mind a kettő.
A lefordított programok el is indulnak hibaüzenet nélkül, de az emulációval valami nem ok.
Mellékeltem az ep128emu-ról egy képet.
Valakinek van ötlete, mi lehet a baj?
-
A teteje érdekes, a csíkozás meg sztem ROM hiány, adtál neki ROM-okat?
-
Igen, adtam.
ROM-ok nélkül teljesen fekete képernyőt adott.
-
Ha jól rémlik, akkor a sérült rendszer szegmens is ilyen csíkozást ad, debuggered van? Abban le lehetne követni, hogy minek következtében ugrik a csíkozásra.
-
Ugyanaz lehet, mint nekem volt anno (a másik "Raspberry Pi" topikban), ez volt a megoldás:
Lehet, hogy hibás a byte sorrend, ami elrontja a Z80 emulációt. A fordítási paraméterekhez a -DCPC_LSB_FIRST=1 hozzáadása után megszűnik a hiba ? Valószínűleg a Raspberry Pi-n ezt kellene beállítani, de csak x86 PC-n alapértelmezett.
-
Köszönöm szépen mindenkinek a segítséget.
A -DCPC_LSB_FIRST=1 volt itt is a megoldás. (https://enterpriseforever.com/emulatorok/raspberry-pi/msg38882/#msg38882)
-
A 64 bites raspberry os-en az emulátor kicsit lassú, még a billentyűleütéseket is jó sok késéssel érzékeli.
(Egyébként az egész 64 bites raspberry os önmagában is lomhábbnak tűnik.)
Lefordítottam egy korábbi 32 bites raspbianon is.
Amennyire meg tudom ítélni, ezen teljesen normális sebességgel futott és normális sebességgel futtatta a betöltött ep programokat is.
-
Kicsit kísérletezgettem most, mert RPi 2-n (és fölötte) simán fut mind az eredeti ep128emu, mind a libretro-core verzió, de az 1-esen nem igazán. (Mondjuk nem csoda, az 1-es egymagos, a 2-es meg 4.)
A legkézenfekvőbb lenne az, hogy az RPi saját HW gyorsított OpenGL driverét (libbrcmEGL) használjuk, sajnos ez nem jött össze. RPi 1..3-ig csak OpenGL ES 2 támogatás van hardveresen, és ez kevés ahhoz, amit az ep128emu használna. Azért valószínűleg át lehetne úgy írni, hogy ne kelljen neki, de lehet, hogy az FLTK-nak is van függősége ehhez, és azt már azért komplikáltabb..
32/64 bites választás csak Pi 3-tól van, azon már illene jó sebességgel futnia, hiába a 64 bit, alkalomadtán megnézem majd.
-
Egy dolgot találtam, ami miatt tud lassabb lenni újabb Linux kiadásokon: a raspi-config beállításai közt van egy Glamor nevű, ez alapesetben ki van kapcsolva, és a desktop OpenGL gyorsítását engedélyezi, ezt be kell kapcsolni ep128emu-hoz.