Sziasztok!
A fórumon már többször felmerült (jogosan), hogy miért nem létezik Android, iOS, stb... eszközökre Enterprise emulátor. De nézzük sorra miért is van ez, mi az oka ennek és merre fele lehetne tovább lépni, hogy közelebb kerüljünk a megoldáshoz.
A fórumon alapvetően két Enterprise emulátor találhatunk.
Az EP32 amely Windows desktop platformon fut és Visual C++ fejlesztő környezet használatával készült. A másik pedig az ep128emu ami “elvileg” platform független, mivel nagyrészt C++ ban készült.
Mind a két emulátort tanulmányoztam forráskód szinten is, legutóbb az ep128emu-t forgattam le OSX platformra. Annak idején pedig az EP32-bekerült egy két apróbb fejlesztésem, melyet EGZO kolléga is megemlít. Amelyet ezúton is köszönök neki!

De nézzük mik azok az akadályok ami miatt nem tud elkészülni az iOS vagy Android változat?

1. Függőségek
Nézzük először az EP32-őt. Az EP32 teljes egészében a Microsoft által készített keretrendszereire épül. A képernyő megjelenítéshez a DirectDraw-t, a hanghoz  a WaveOut és DirectSound a billentyűzet kezeléshez pedig a DirectInput APIket használja a floppy és egyéb fájlműveletekhez pedig a Win32 SDK-t. Innentől kezdve gyakorlatilag ennek a szoftvernek egy iOS mutációjához újra kellene írni a forráskód ~80%-át.

De térjünk rá az ep128emu-ra amely alapvetően Linux alá/alatt készült, de könnyen leforgatható és tökéletesen működik Windows és OSX környezetekben is. Hogyan lehet ez és akkor miért nem lehet 10 perc alatt leforgatni iOS-re vagy Androidra?
A válasz a felhasznált könyvtárakban (SDK) keresendő! Egy alap funkciókkal rendelkező ep128emu-hoz szükség van a libsndfile, portaudio, fltk könyvtárakra, néhány esetben pl kellhet még LUA és SDL is. Ezek a könyvtárak széleskörben használatosak és elsősorban desktop számítógépekhez készültek ez utóbbi kettő (LUA és SDL) már létezik mobil eszközökre is, de sajnos az libsndfile, portaudio és az fltk egyelőre nem és a jelenlegi forrás ezekre támaszkodik.

2. Kezelőfelület
Itt a kérdés, mire is szeretnénk használni az emulátorunkat egy Android vagy iOS eszközön? Első ötletem a demók futtatása és a játékok lennének, de ez csak az én véleményem. A kezelőfelületet ennek fényében kell újra alkotni a kisebb telefon felbontásra illetve a táblagépek kijelzőjére. Ezzel el lehet lenni, de ha már megy az emuláció akkor kezelőfelületet lehet igazítgatni.

Mi lehet a megoldás?
A böngésző! (Javascript + HTML5)

Felmerül a kérdés, hogy mi ez a hülyeség, hogyan lehet ilyet egyáltalán mondani???
De mégis, nem kevés Webes alkalmazás fut már világszerte (pl. Angry Birdsnek is van ilyen változata) és akkor még nem is említettük a Chrome OS-t ahol minden program a böngészőben fut.

Előnyei:
Platformfüggetlen megoldás
Online lehetne játszani az EP-s játékokat
Nem kell leforgatni az a forráskódot

Hátrányai:
Nagyobb erőforrásigény
Régebbi böngészőkben nem biztos hogy fog futni

És amiért úgy gondoltam, hogy összefoglalom ezeket infókat az az volt, hogy találtam egy javascriptben írt ZX Spectrum emulátort az http://ispeccy.com/ mely opensource és az ep128emu Z80 emulációjának alapjául szolgáló C++ library-t használták fel. Talán ezt a projektet alapul véve és az ep128emu forrását felhasználva el lehet kezdeni egy böngésző alapú emulátor projektet. Mit gondoltok?

  bocs ha már erről volt itt szó és azért is ha egy kicsit hosszú lett!

Üdv,
Gyuri

Szerintem nem kell keretrendszer. Sõt, egyszerûen annyit tudjon hogy elõre beállított-bekonfigolt programokat futtat. Azaz az user csak rányom egy linkre és játszik pl. a Batman-al.
Miért jó ez? A legtöbb usert csak ez érdekli. Ha több érdekli, majd a többi emut használja.
Sõt. A legtöbb emut szerintem sok régi EP-s azért nem használja mert nincs ideje foglalkozni azzal hogy megtanulja a használatukat. Meg is értem õket, én is így vagyok már egy ideje.
De ezek az userek szívesen megnéznének játékokat, demókat. Ha weben futtatható emu lenne, szerintem csak erre használnák.

Sot ... Mas (vice [commodore xyz], ep128emu, stb) kapcsan mar regen gondolkoztam azon, hogy lehetne egy olyan lehetoseg (igaz, ezt meg "sima" desktop PC-nel gondoltam), hogy egy szem file-t nyit meg az ember gyereke, es az tartalmaz config-ot, betoltendo esetleges ROM-okat (vagy arra vonatkozo eloirast), emulalando extra hw-ket, stb, es magat a software-t is, amit futtatni kene (legyen ez disk image, vagy barmi). Ugyanis gyakran gond, hogy adott valami, ami kicsit is extra cfg-t kivan, akkor egy orokkevalosag, mire az ember beallit mindent ugy, aztan maskor meg megint kezdheti elolrol, ha legkozelebb nezi (vagy egyeb trukk kell, cfg elmentese adott neven, miegymas). Mennyivel szebb lenne, ha egy szem file-ban lenne minden megmondva az emunak, raadasul ez pl kulon elony lenne egy olyan esetben, mint az okostelefon, ahol amugy is nehezkesebb azert a fel vilagegyetemet atconfiguralni minden alkalommal.

Ha igy mukodne, nem is kene semmi cfg lehetoseg magaba az app-ba. Max desktop OS-re lehetne egy cfg editor, ha valaki ossze akar allitani valamit, amit aztan hasznal. Persze a szep az lenne, ha ezt tobb emulator is megertene, igy tobbe-kedvesbe standard eljaras lenne, legalabb egy adott emulator "tobb verzioja" kozott, ha mas nem is - pl ep128emu for iPhone/Android and desktop "edition"

ep128emunál erre jó a snapshot fájl.

így van,
ha jól tudom a snapshot elvileg kiváltja még a romok betöltését is?

ha jól tudom a snapshot elvileg kiváltja még a romok betöltését is?

Igen, a snapshot tartalmazza a ROM-okat, a demo file-ok pedig a CPU és egyéb órajelek konfigurációját is.
A snapshot vagy demo betöltéssel módosított hardver konfiguráció visszaállítható a "Reset machine configuration" (Shift + F11) segítségével.

Ezzel azonnal megszűnik az FLTK, OpenGL, SDL, és Lua függőség. A soundio.cpp és soundio.hpp néhány perces módosításával

Köszi az összeíraást sokat segített!
Nézegettem a forrást és az lenne a kérdésem, hogy az OpenGL mennyire van ráeépítve ebben a kódban az FLTK-ra?
Mert az opengl igazábol maradhatna is.
 

ep128emunál erre jó a snapshot fájl.

Aha, koszi. Oszinten ez nem jutott volna eszembe, a snapshot hallatan nekem inkabb mindig az ugrik be, hogy "majd folytatom ott, ahol abbahagytam", es nem ez a funkcio Btw, akkor az egy file, amiben minden benne van? Csak mert fejlesztes soran gyakran jol jonne, ha a kerdeses file pl valami text formatum lenne, amiben pl betoltendo program megadhato mint hivatkozas (a kerdeses file path-ja), szerkesztheto konnyeden, stb. Persze egy okostelefonra nyilvan pont az "egy az egyben" jo, bar ott is erdekes lehetne, hogy pl egyes ROM-okra, file-okra stb mondjuk URL-el is lehetne hivatkozni a "config file-on" belul, igy nem kene mindegyikbe feltetlen mindent belezsufolni. Ok, leallok es elolvasom az emu hasznalati utasitasat (RTFM), mivel kiderul a vegen, hogy olyasmiket akarok, ami mar reg megvan, lasd pl snapshot file

Ebben a kódban a VSYNC kezelés és a Frame rajzolás elvileg az OpenGL-en keresztül rajzol?

Igen, a rajzolást nem töröltem, de ahhoz, hogy használható legyen, néhány részletet - pl. ablakkezelés - újra meg kell írni.

A debugger szerint az alábbi fv. meghívásra kerül
void FLTKDisplay_::frameDone()

de a gldisp.cpp-be nem jut el a kód, ezt az ablakkezelőnek kellene meghívnia?

Ezt az FLTKDisplay_::drawLine() hívja, máshol nem kell foglalkozni vele. Az FLTKDisplay_ az FLTKDisplay (az eredeti FLTK software video driver, amelyet töröltem) és OpenGLDisplay közös részeit tartalmazza, mint például a video és szinkron adatok feldolgozása. A nevével ellentétben valójában nem használ FLTK-t.

Itt egy nagyon kezdetleges példa program, ami betölti a "qs_ep128.dat" snapshot file-t az aktuális könyvtárból, és 10 másodpercig futtatja az emulációt. Hang és video van (Linux alatt legalábbis, más rendszeren nem teszteltem), billentyűzet kezelés nincs, nem használja a VMThread-et, és a megvalósításon sokat lehetne javítani, de talán használható minimális SDL alapú működő példának.

 main.cpp (4.93 kB - downloaded 493 times.)