Enterprise Forever

:HUN => Emulátorok => Topic started by: varrogy on 2012.January.16. 00:06:04

Title: iEP128emu
Post by: varrogy on 2012.January.16. 00:06:04
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?

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

Üdv,
Gyuri
Title: Re: iEP128emu
Post by: endi on 2012.January.16. 12:27:56
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.
Title: Re: iEP128emu
Post by: lgb on 2012.January.16. 14:12:44
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" :-)
Title: Re: iEP128emu
Post by: Zozosoft on 2012.January.16. 14:38:04
egy szem file-t nyit meg az ember gyereke
ep128emunál erre jó a snapshot fájl.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.16. 16:25:40
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?
Title: Re: iEP128emu
Post by: szipucsu on 2012.January.16. 16:59:43
ha jól tudom a snapshot elvileg kiváltja még a romok betöltését is?
Én is így tapasztaltam, és újabb indításnál újra a régi beállításokra fog emlékezni az emu, tehát nem kell visszaállítgatni se.
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.16. 17:58:45
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.
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.16. 18:27:49
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?

Csak a hardver emuláció forráskódját használva elkerülhetők a függőségek, így azonban természetesen újra meg kell valósítani a video és audio kimenetet, a billentyűzet kezelését, és a felhasználói felületet. A libep128emu.a, libz80.a, libep128.a, libzx128.a, és libcpc464.a forrás file-jait kell használni (illetve az utóbbi kettőt nem, ha elég csak az EP emuláció, de a többi gép támogatását nem nehéz beépíteni). A libep128emu.a-ból kihagyhatók ezek: fldisp.cpp, gldisp.cpp, guicolor.cpp, joystick.cpp, script.cpp, és esetleg a vmthread.cpp is. 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 törölhető a libsndfile és PortAudio függőség is. Szintén kihagyhatók ezek: cfg_db.cpp, cfg_db.hpp, emucfg.cpp, emucfg.hpp - de így csak a dotconf függőség kerülhető el, ami egyébként is opcionális, és újra kell írni a konfigurációs file-ok kezelését.
Az új emulátornak meg kell valósitania az audio és video kimenetet (lásd soundio.hpp és display.hpp). Az emulátor interface a vm.hpp-ben található, erre épül az ep128vm.hpp, zx128vm.hpp, és cpc464vm.hpp. A használatának a lényege röviden. hogy a run() függvény hívásával az emuláció tetszőleges időtartama "futtatható" (az ep128emu-ban ez fixen 2 ms), és ezen hívások között lehet billentyűzet adatot küldeni, konfigurációt módosítani, debug műveleteket végezni, stb. a megfelelő függvények hívásával. A run() hívja az audio és video interface-t, amikor az adott típusú adat készen áll a megjelenítésre vagy lejátszásra. A video megjelenítőnek sor adat, és VSYNC be-/kikapcsolás eseményeket kell feldolgoznia. Az audio drivert az emuláció pufferelt hangminta adatokkal hívja, ennek a feladata egyben a valós idejű sebességre lassítás is, de ezt máshogy is meg lehet oldani.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.17. 10:10:37
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.
 
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.17. 11:13:44
Itt egy "lebutított" forráskód csomag, GUI, FLTK, PortAudio, libsndfile, Lua, és SDL nélkül:
  [attachurl=#]
OpenGL-t továbbra is használ a gldisp.cpp és gldisp.hpp, ehhez azonban az ablakkezelést, ami eredetileg FLTK alapú volt, újra meg kell valósítani.
A cfg_db.cpp, cfg_db.hpp, emucfg.cpp, és emucfg.hpp használja a dotconf-ot.
A fenti forrás file-ok elvileg mind törölhetők, a kód többi része működik ezek nélkül is.
Néhány helyen még előfordulnak rendszerfüggő kód részletek (pl. system.cpp/hpp, és a Z80 emulációban a byte sorrendet felismerő #ifdef-ek).
Title: Re: iEP128emu
Post by: lgb on 2012.January.17. 15:49:44
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 :)
Title: Re: iEP128emu
Post by: varrogy on 2012.January.17. 21:10:52
Itt egy "lebutított" forráskód csomag, GUI, FLTK, PortAudio, libsndfile, Lua, és SDL nélkül:
  (Attachment Link)
OpenGL-t továbbra is használ a gldisp.cpp és gldisp.hpp, ehhez azonban az ablakkezelést, ami eredetileg FLTK alapú volt, újra meg kell valósítani.
A cfg_db.cpp, cfg_db.hpp, emucfg.cpp, és emucfg.hpp használja a dotconf-ot.
A fenti forrás file-ok elvileg mind törölhetők, a kód többi része működik ezek nélkül is.
Néhány helyen még előfordulnak rendszerfüggő kód részletek (pl. system.cpp/hpp, és a Z80 emulációban a byte sorrendet felismerő #ifdef-ek).


Köszi!!
Ebben a kódban a VSYNC kezelés és a Frame rajzolás elvileg benne van az OpenGL-en keresztül?

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?

Gy

Title: Re: iEP128emu
Post by: IstvanV on 2012.January.17. 22:20:46
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.

Quote
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.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.18. 09:17:32
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.

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.


Újabb kérdés  :oops:
Sikerült leforgatni kódot az openGL részlegesen portoltam opengl es-re és elindítja a vmThreadet amibe be is töltöttem egy snapshot filet.
úgy tűnik, hogy fut rendesen és időközönként be is billenti a VideoDisplay a haveFramesPending - változót!

Viszont az audió output sendAudioData callback nem hívódik meg soha ez pontosan mitől függ?
Elivleg ebben valahol kellene lennie egy buffernek amiben a hang adat van amit valamilyen formában ki kell írni az eszköz hangkimenetére.


Title: Re: iEP128emu
Post by: IstvanV on 2012.January.18. 12:09:43
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.

[attachurl=#]
Title: Re: iEP128emu
Post by: varrogy on 2012.January.18. 23:17:36
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.

(Attachment Link)


Jol mukodik, koszonom a kodot, egyelore csak simulatorban tudtam kiprobalni hang is van, kep egyelore nincs mert nem sikerult teljesen portolni még a gldisp.cpp-t opengl ES-re (desktopon ahogy irtad ott megy a kep MAC-en is, de ott van sima opengl)
illetve Azon gondolkodtam, hogy mekkora melo lenne sima SDL (bitmap, Az sdl-t sajnos nem ismerem ennyire :( ) displayre ratenni a renderinget?


Title: Re: iEP128emu
Post by: IstvanV on 2012.January.19. 01:02:22
illetve Azon gondolkodtam, hogy mekkora melo lenne sima SDL (bitmap, Az sdl-t sajnos nem ismerem ennyire :( ) displayre ratenni a renderinget?

Az FLTK software driver alapján valószínűleg nem túl nehéz megoldani. A plus4emu forráskódjában is van egy C példa program ami a hardver emulációt DLL-ként használja, és a video, hang, és billentyűzet kezelése SDL alapú.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.19. 14:13:00
Az FLTK software driver alapján valószínűleg nem túl nehéz megoldani. A plus4emu forráskódjában is van egy C példa program ami a hardver emulációt DLL-ként használja, és a video, hang, és billentyűzet kezelése SDL alapú.


Az emu library a byte order kulonbsegre mennyire erzekeny?
(korabban irtad, hogy elvileg a Z80 libraryban vannak ezek lekezelve)
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.19. 14:55:50
Az emu library a byte order kulonbsegre mennyire erzekeny?
(korabban irtad, hogy elvileg a Z80 libraryban vannak ezek lekezelve)

Ha jól emlékszem, csak a Z80 kódban van ilyen probléma, amit eredetileg nem én írtam. Ezt a részt kell kiegészíteni vagy módosítani a z80.hpp file-ban:
Code: C++
  1. #ifndef CPC_LSB_FIRST
  2. #  if defined(__i386__) || defined(__x86_64__) || defined(WIN32)
  3. #    define CPC_LSB_FIRST 1
  4. #  endif
  5. #endif
Title: Re: iEP128emu
Post by: varrogy on 2012.January.19. 23:20:54
Ha jól emlékszem, csak a Z80 kódban van ilyen probléma, amit eredetileg nem én írtam. Ezt a részt kell kiegészíteni vagy módosítani a z80.hpp file-ban:
Code: C++
  1. #ifndef CPC_LSB_FIRST
  2. #  if defined(__i386__) || defined(__x86_64__) || defined(WIN32)
  3. #    define CPC_LSB_FIRST 1
  4. #  endif
  5. #endif


Aha köszi megvan, megy iOS-en is de a sebesség sajnos nagyon lassú :(
iPhone 3G-n kvázi "NULL" displayyel is (kikommentezem a opengl renderinget) akadozik a hanglejátszás.
iPad-on kicsit jobb a helyzet, de igazából még az is nagyon lassú. viszont ott jóval nagyobb a felbontás (1024x768) :(
iOS Simulátorban megy jól (de az i7-es) ;)
Valószínűleg az SDL megeszi az erőforrást :(

Title: Re: iEP128emu
Post by: varrogy on 2012.January.20. 09:29:24
Valószínűleg az SDL megeszi az erőforrást :(

Letöltöttem spectrum, meg c64 emu-t iphonera,
azok mennek jól a régi 3G-s iPhoneon is.
Nemtudom, hogy azok sdl-t használnak-e vagy valami más megjelenítöt és hanglejátszót.
Esetleg az ep128emu-n az idözítéseket, precizitását lehet paraméterezni?
Esetleg más ötlet a sebesség kérdésre?
Title: Re: iEP128emu
Post by: Zozosoft on 2012.January.20. 09:34:31
Én csak ámulva nézem mikrõl csevegtek itt, ez nekem teljesen kínai  :oops: :oops: :oops: de remélem lesz belõle valami, egy jobb fajta Android telefonon billentyû is akad bõven!  :ds_icon_cheesygrin:

(Egy ici-pici apróság: ezzel a javítással (http://enterpriseforever.com/ep128emu/ep128emu_209-t595.0.html;msg23084#msg23084) nem tudna fordítani valaki egy hagyományos Windowsos EXE-t?)
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.20. 11:25:06
(Egy ici-pici apróság: ezzel a javítással (http://enterpriseforever.com/ep128emu/ep128emu_209-t595.0.html;msg23084#msg23084) nem tudna fordítani valaki egy hagyományos Windowsos EXE-t?)

Van még egy javítandó hiba: CPC emulációnál a teljes képernyős mód állítgatása után eltűnnek a floppy LED-ek. Ez szintén egy soros módosítással javítható.
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.20. 11:30:11
Esetleg az ep128emu-n az idözítéseket, precizitását lehet paraméterezni?
Esetleg más ötlet a sebesség kérdésre?

Érdemes lenne megnézni hang nélkül, hogy ha csak a hardver emuláció fut, akkor milyen sebesség érhető el. Az időzítéseken nem sokat lehet változtatni, esetleg EP-nél ki lehet kapcsolni a memória időzítés emulációját és a Z80 órajelet csökkenteni, de ez rontja a kompatibilitást, és nem sokat gyorsít. A hang konverziót viszont érdemes alacsony minőségűre állítani, bár ha jól látom, a vm.cpp-ben ez az alapértelmezés.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.20. 12:43:06
Érdemes lenne megnézni hang nélkül, hogy ha csak a hardver emuláció fut, akkor milyen sebesség érhető el. Az időzítéseken nem sokat lehet változtatni, esetleg EP-nél ki lehet kapcsolni a memória időzítés emulációját és a Z80 órajelet csökkenteni, de ez rontja a kompatibilitást, és nem sokat gyorsít. A hang konverziót viszont érdemes alacsony minőségűre állítani, bár ha jól látom, a vm.cpp-ben ez az alapértelmezés.

Ok, ránézek aztán írok majd,
ha jól értem akkor a hang driver lassítja valós sebességre az emulációt.
Ha csinálok egy NULL drivert akkor elméletileg az elérhető maximum sebességgel fog futni az emuláció?

OFF:
Processzorok

iPhone, iPhone 3G   
620 MHz (412 MHz-re lassítva) armv6

iPhone 3GS   
833 MHz (600 MHz-re lassítva) armv7

iPhone 4, iPhone 4S
1 GHz (800 MHz-re lassítva) armv7

iPad1
1 GHz armv7

iPad2
1 GHz (dual core) armv7
Title: Re: iEP128emu
Post by: varrogy on 2012.January.20. 13:01:42

(Egy ici-pici apróság: ezzel a javítással (http://enterpriseforever.com/ep128emu/ep128emu_209-t595.0.html;msg23084#msg23084) nem tudna fordítani valaki egy hagyományos Windowsos EXE-t?)


Sajnos nincs windowsom :(
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.20. 13:08:13
Ha csinálok egy NULL drivert akkor elméletileg az elérhető maximum sebességgel fog futni az emuláció?

Igen, de a meglevő driverrel is egyszerűen letiltható a hang az Ep128Emu::VirtualMachine::setEnableAudioOutput(bool) függvény használatával. Ez még a konverziót is kikapcsolja, ami további gyorsulást eredményez.
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.20. 13:10:38
Sajnos nincs windowsom :(

Esetleg készíthetek egy 2.0.9.2 verziót, ha van még más javítandó probléma (csak ezért a két kisebb hibáért talán nem érdemes kiadni).
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.20. 13:12:37
iPhone 4, iPhone 4S
1 GHz (800 MHz-re lassítva) armv7

iPad1
1 GHz armv7

iPad2
1 GHz (dual core) armv7

Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:
Title: Re: iEP128emu
Post by: Ep128 on 2012.January.20. 17:33:01
(... én meg itt már tûkön ülök szép csöndben, mert ugyan hozzászólni egy mukkot sem tudok, de évek óta iPhone -om van és álmodozom az "ottani" EMU -ról... :-) Még hang nélkül is eszelõs poén volna! (Persze hanggal pláne... :-) )
Title: Re: iEP128emu
Post by: varrogy on 2012.January.20. 22:12:27
Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:

Én sem tudom a pontos számokat, de ha saccolni kellene akkor talán P3 800-as körül lehet az 1GHz-es proci.

Kikapcsoltam a hangot, plusz próbálkoztam a frekvenciák állítgatásával is, valóban gyorsult a dolog,
 de sajnos még mindíg nagyon lassú pedig most iPad-en (armv7 1.0GHz) nézem.
Nézegettem az SDL-nek a softwares kép kezelőjét is, de azzal nem sokra jutottam, azt a kódot nem igazán látom át  :oops:
Illetve nem tudom, hogy azzal esetleg lehetne-e valamit gyorsítani.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.21. 01:01:56
Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:

IstvanV,
Profilerrel is megnéztem az emu-t hang nélkül és hanggal is mennie kéne, mert nem használ el minden processzoridőt!
Ahogy korábban említetted valóban a hang konverzió viszi el az idő nagyrészét, illetve most láttam, hogy a demo lejátszás is viszi a processzoridőt!
Próbáltam a vmThread-et is futtatni meg simán threaden nélkül is a virtuális gépet de valahogy mintha nem tudná, hogy ki kellene rajzolnia minden képkockát.
Tuti hogy nálam lesz valami gond, csak még nem jöttem rá, hogy mi az. :)
Lehet, hogy a thread lockok zavarják össze képernyő frissítést?
Csatoltam a profilerről képet is. (hang és hang nélküli futtatásról)
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.21. 12:24:31
Ahogy korábban említetted valóban a hang konverzió viszi el az idő nagyrészét

Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Quote
illetve most láttam, hogy a demo lejátszás is viszi a processzoridőt!

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Quote
Próbáltam a vmThread-et is futtatni meg simán threaden nélkül is a virtuális gépet de valahogy mintha nem tudná, hogy ki kellene rajzolnia minden képkockát.
Tuti hogy nálam lesz valami gond, csak még nem jöttem rá, hogy mi az. :)

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.21. 12:41:20
Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.


Elvileg tud menni desktopon egyelőre azokat az SDL osztályokat használja amit Te írtál,
főleg az OpenGL-t irogattam át (gldisp.cpp), hogy menjen OpenGL ES-en de az új kód elméletileg sima OpenGL kompatibilis.

Tettem egy fps countert az SDL main loopjába ami stabil 60-at mutat iPad-en a következő esetekben:
- csak az emuláció fut vm-run(2000) (nincs demo futtatás, nincs rajzolás és nincs hang)
- fut az emuláció vm-run(2000) + fut a batman.demo (nincs rajzolás és nincs hang)
- fut az emuláció vm-run(2000) + fut a batman.demo + hang is van de az akadozik (nincs rajzolás)

És akkor kezd el akadozni az dolog, ha bekerül a
checkEvent a képbe a rajzolással együtt!!!

void SDLGLDisplay::draw()
{
    if (checkEvents()) {
        OpenGLDisplay::draw();
        SDL_GL_SwapBuffers();
    }
}

A kódot később összeszedem és kiteszem ide, most eléggé összevissza van még!
Title: Re: iEP128emu
Post by: varrogy on 2012.January.21. 16:07:29
Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.



Osszecsomagoltam a kódot, ha valakinek van XCode 4.2-je akkor le tudja próbálni.
iOS simulatorban nincs gond, tökéletesen fut, de valós eszközön (iphone, ipad) nem jó (a hang akad, kép talán jó) és nem tudok rájönni, hogy mi okozhatja.
Ugyanis a framerate nem indokolja, hogy miért akadozik.
Más az architektura, és emiatt a byte oreder is de elvileg ez be van állítva ahol korábban jelezted. (illetve amig nem irtam át elég furcsa képeket adott :) )

(ez egyelőre csak egy tech demo,
- Betölti a batman.demo-t elkezdi játszani,
- Ha végig húzza valaki az újját képernyőn akkor az reset gombot emulál
- Ha megnyomja valaki a képernyőt akkor az gombnyomást (5-ös) emulál
)
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.21. 19:11:07
A main.mm-ben a ciklus, amely SDL eseményre vár és a képernyőt rajzolja, sok CPU időt fogyaszt. Ezen egyszerűen, de nem túl elegánsan várakozás (pl. Ep128Emu::Timer::wait()) beépítésével lehet javítani. Az eredeti FLTK-s megoldásban az emulátor thread jelezte a GUI-nak, ha van rajzolandó képkocka. A videoDisplay->draw() akkor is visszatér, ha éppen nem rajzol semmit, így a frame rate kijelzés nem jól működik, de ez kisebb probléma. Az alábbi kódrészlet mindkét hibát javítja átmenetileg, de ez nem tökéletes megoldás; a várakozás időtartama változhat attól függően, hogy az OS milyen felbontással tud időzíteni:
Code: C++
  1. void SDLGLDisplay::draw()
  2. {
  3.   while (!checkEvents())
  4.     Ep128Emu::Timer::wait(0.005);
  5.   OpenGLDisplay::draw();
  6.   SDL_GL_SwapBuffers();
  7. }
A dp.bufferingMode-ot érdemes 1-re állítani, ha az SDLGLDisplay létrehozásakor is double buffer mód van beállítva.

A hang problémát talán egyszerűen a puffer méret állításával javítani lehet (az audioOutput->setParameters() hívásnál). De mivel a hangkimenet lassítja az emulációt valós idejű sebességre, a nagy puffer rontja az időzítés pontosságát (akadozik a kép, stb.). Az eredeti PortAudio alapú driver ezt úgy oldja meg, hogy az Ep128Emu::Timer()-el időzít, és a sebességet az audio puffer állapotától függően módosítja, hogy a pufferben átlagosan kb. 50% adat legyen.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.21. 21:11:57
(... én meg itt már tûkön ülök szép csöndben, mert ugyan hozzászólni egy mukkot sem tudok, de évek óta iPhone -om van és álmodozom az "ottani" EMU -ról... :-) Még hang nélkül is eszelõs poén volna! (Persze hanggal pláne... :-) )

Milyen iPhoneod van?
Title: Re: iEP128emu
Post by: varrogy on 2012.January.21. 23:22:08
Code: C++
  1. void SDLGLDisplay::draw()
  2. {
  3.   while (!checkEvents())
  4.     Ep128Emu::Timer::wait(0.005);
  5.   OpenGLDisplay::draw();
  6.   SDL_GL_SwapBuffers();
  7. }
A dp.bufferingMode-ot érdemes 1-re állítani, ha az SDLGLDisplay létrehozásakor is double buffer mód van beállítva.

A hang problémát talán egyszerűen a puffer méret állításával javítani lehet (az audioOutput->setParameters() hívásnál). De mivel a hangkimenet lassítja az emulációt valós idejű sebességre, a nagy puffer rontja az időzítés pontosságát (akadozik a kép, stb.). Az eredeti PortAudio alapú driver ezt úgy oldja meg, hogy az Ep128Emu::Timer()-el időzít, és a sebességet az audio puffer állapotától függően módosítja, hogy a pufferben átlagosan kb. 50% adat legyen.


Köszi a tippeket, átírtam a draw() kódot, hogy helyesen jelezze az FPS-t.
Viszont így kiderült, ha kikommentezem a OpenGLDisplay::draw(); sort akkor az iPad-en futtatva 1300-1400 FPS volt a frissítés, azaz ennyiszer volt úgymond kész képernyő.
Ezután engedélyeztem a OpenGLDisplay::draw(); sort és leesett az FPS displaymódtól függően 4-8 FPS-re, kivéve a 0-ás módnál ott 40-50 FPS volt ez az érték.
Elkezdtem keresgélni a rajzolási kódban ahol már mindent kikommenteztem és kiderült, ha csak a GL_VIEWPORT-ot meghívom (csak ezt az egy sort, kvázi látható rajzolás nincs) már akkor leesik az FPS olyan 50-60 közöttre.

A kérdés, hogy szerinted a GL_VIEWPORT, stb.. openGl függvények össze van kötve az OS VSYNCjével (vagy ezt az SDL csinálhatja) és emiatt csökken a sebesség vagy tényleg ilyen lassú ez a függvény?

Title: Re: iEP128emu
Post by: IstvanV on 2012.January.22. 00:24:34
A kérdés, hogy szerinted a GL_VIEWPORT, stb.. openGl függvények össze van kötve az OS VSYNCjével (vagy ezt az SDL csinálhatja) és emiatt csökken a sebesség vagy tényleg ilyen lassú ez a függvény?

A draw() hívás törlésekor nem működik megfelelően az FPS kijelzés, mert a checkEvents() visszatérési értéke mindig true lesz; a draw() törli a redrawFlag változót, amely jelzi, ha van megjelenítendő képernyő adat.

Double buffer módban az SDL_GL_SwapBuffers() várakozik a VSYNC-re. Ha ennek a hívását nem törölted, akkor lehet, hogy ha nincs semmilyen OpenGL művelet, akkor nincs hatása, de ebben nem vagyok biztos - nálam legalábbis PC-n nem így van.
Title: Re: iEP128emu
Post by: Ep128 on 2012.January.22. 12:30:00
Milyen iPhoneod van?

4G S
(Ellenben -a mezei 3 G után- ezt már nem Jailbreak -eltem, (nem is szeretném, a béke kedvéért  :oops: ) tehát csak azt tudom rányomni, amit iTunes -ban szereztem. "Oda" kellene (1x majd...) eljuttatnod az EMU -t.  :) )
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.22. 12:46:36
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )

A Spectrum és CPC emuláció beépítése minimális nehézséget jelent, gyakorlatilag egy sort kell átírni ahhoz, hogy másik gép emulátora legyen.
Title: Re: iEP128emu
Post by: Zozosoft on 2012.January.22. 12:47:58
csak azt tudom rányomni, amit iTunes -ban szereztem. "Oda" kellene (1x majd...) eljuttatnod az EMU -t.  :) )
Beengednek oda már más programot futtató programot?
Quote
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )
Ezen már én is gondolkoztam :-) Mi legyen a neve?
Title: Re: iEP128emu
Post by: varrogy on 2012.January.22. 16:49:44
Beengednek oda már más programot futtató programot?Ezen már én is gondolkoztam :-) Mi legyen a neve?

Elméletileg igen, beengedik, viszont tényleg elég szigorúak a szabályok. Komolyan veszik a dolgot, eleve a regisztrációnak is éves díja van ami szükséges a beadáshoz.
Dobtak már vissza alkalmazást sokminden miatt. (alkalmazás ikonok helytelen mérete miatt, support url hiánya miatt, stb...)
Valószínűleg, csak olyan formában tud majd bemenni, hogy tartalmaznia kell a futtatható programokat. (pl. játék snapshotok)

Viszont a beadástól még messze van a projekt (sajnos).

A neve végülis lehetne iEP128Emu, amíg nincs jobb ötlet.
Title: Re: iEP128emu
Post by: Ep128 on 2012.January.22. 16:55:09

A neve végülis lehetne iEP128Emu, amíg nincs jobb ötlet.

Akkor valaki modi nevezze át a topic -ot...  ;-)
Title: Re: iEP128emu
Post by: Zozosoft on 2012.January.22. 19:16:30
Akkor valaki modi nevezze át a topic -ot...  ;-)
Így jó lesz?
Title: Re: iEP128emu
Post by: varrogy on 2012.January.22. 21:29:29
Így jó lesz?

Szuper!  :ds_icon_cheesygrin:
Title: Re: iEP128emu
Post by: varrogy on 2012.January.22. 21:38:39
Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

A hang része nem hagy nyugodni, hogy miért nem szól rendesen a iPaden a kód!
Egyelőre a rajzolást kikapcsoltam és kiiratom minden sendAudioData híváskor, hogy mennyi az epLock.wait(értéke)

iPhone szimulátorban 2 frame rate kiírás között pontosan 11x fut le a sendAudioData.
Eszközön, pedig jó ha egyszer hívja 2 frame rate kiírás között ugyanezt a fv-t!

A hang feldolgozása külön szálon menne?
vagy mihez van kötve a futása?
 
Title: Re: iEP128emu
Post by: IstvanV on 2012.January.22. 21:41:11
A puffer méretet próbáltad állítani ? Ha az nem megfelelő, akkor akadozhat a hang.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.22. 22:00:01
A puffer méretet próbáltad állítani ? Ha az nem megfelelő, akkor akadozhat a hang.


A puffer méret elvileg ebből a számításból jön (a frekvencia + késleltetésből), de desktopon mindegy mire állítom mindíg jól szól.
int     bufSize = int(totalLatency * sampleRate * 0.7071f + 0.5f);

Ha nagyobbra állítom iPad-en akkor is akadozik, csak hosszabb szeleteket játszik le.

Title: Re: iEP128emu
Post by: varrogy on 2012.January.23. 22:59:58
Estére egy kis video ;)
Sok tennivalo van még vele :)
Title: Re: iEP128emu
Post by: Ep128 on 2012.January.24. 00:35:37
Hûûû... :-) Ez eszelõs jó!  Grat! :smt041
(Micsoda sebességgel száguld a Qkac!  :lol: )
Nagyon tetszik, vagy 5x megnéztem, próbálom "ráképzelni" a saját, valódi iPhone -omra! :-)
(Nem baj, ha még sok a tennivaló, kivárjuk! ;-) )
Title: Re: iEP128emu
Post by: szipucsu on 2012.January.24. 12:12:26
Estére egy kis video ;)
És a sebességre panaszkodtatok? Ez még gyorsabb is, mint az eredeti. :D

Én nem használok ilyen hipermodern kütyüket, a PC-vel beérem, arra is nehéz volt átállni az EP után. Telefonból is valami régi van, iPhone-t sem használok, de azért érdekes, hogy az emulátort erre is el lehet készíteni és hogy ezzel foglalkoztok, további sok sikert!
Title: Re: iEP128emu
Post by: endi on 2012.January.25. 20:02:31
jó ez a videó, most megint eszembe jutott hogy fel kéne venni a kapcsolatot a wriggler jogtulajdonosával és kiadni ifonra a wrigglert
azt senki se kell lássa hogy emuval fut :)
még extra grafika készítését is vállalnám, persze %-ért :)
Title: Re: iEP128emu
Post by: Attus on 2012.January.25. 22:24:53
És a sebességre panaszkodtatok? Ez még gyorsabb is, mint az eredeti. :D

Én nem használok ilyen hipermodern kütyüket, a PC-vel beérem, arra is nehéz volt átállni az EP után. Telefonból is valami régi van, iPhone-t sem használok, de azért érdekes, hogy az emulátort erre is el lehet készíteni és hogy ezzel foglalkoztok, további sok sikert!

Eszelõs ez a videó!
 :lol:

Szívembõl szóltál szipucsu.
Én is nagy fenntartással viszonyulok ezekhez a "mindentudó" ketyerékhez.
Nekem is csak régi telefonom van, nem is akarom másra használni, mint amire való. Telefon, ébresztõóra.
Fényképezni fényképezõgépet használok.
A "tablet" ketyerékhez legalább nem kell nagyító, mint ehhez a zsebrevágható apróságokhoz, nekik nagyobb jövõt jósolok.
Title: Re: iEP128emu
Post by: varrogy on 2012.January.29. 11:17:53
És a sebességre panaszkodtatok? Ez még gyorsabb is, mint az eredeti. :D
Igen valóban nagyon gyors, de ez iPhone szimulátorban megy és ott a host gép az ami a sebességét adja, az pedig sokkal gyorsabb egy iPhone vagy iPad-nél.
Title: Re: iEP128emu
Post by: Zozosoft on 2012.January.29. 11:25:47
Igen valóban nagyon gyors, de ez iPhone szimulátorban megy és ott a host gép az ami a sebességét adja, az pedig sokkal gyorsabb egy iPhone vagy iPad-nél.
Egy ilyen szimulátornak nem az lenne a lényege, hogy lássa a fejlesztõ, hogy fog futni a kütyûn?
Title: Re: iEP128emu
Post by: varrogy on 2012.January.29. 12:35:29
Egy ilyen szimulátornak nem az lenne a lényege, hogy lássa a fejlesztõ, hogy fog futni a kütyûn?
Elvileg igen az a célja, de mivel ez csak egy szimulátor az arm architektúrát és a processzor sebességet nem utánozza.
Így jóval több processzor idő marad a programoknak mert natívan futtatja a lefordított forráskódot.
Ezért volt pl gond a Byteorderrel is, ami simulátorban sosem derült volna ki!
Title: Re: iEP128emu
Post by: varrogy on 2012.February.09. 21:35:39
Sziasztok
nem találtam a dave táblázatában néhány billentyű keyCode-ját tudna valaki segíteni?
köszi

ü -
* -
ö -
ä -
< -
Title: Re: iEP128emu
Post by: Tuby128 on 2012.February.09. 21:44:38
Így keresd:

ü - @
* szerintem te a + jelet keresed - [
ö - ;
ä - :
< - \
Title: Re: iEP128emu
Post by: varrogy on 2012.February.11. 22:51:55
Így keresd:

ü - @
* szerintem te a + jelet keresed - [
ö - ;
ä - :
< - \

Köszi, halad a dolog!


Title: Re: iEP128emu
Post by: Tuby128 on 2012.February.11. 22:56:27
Tegnap vagy tegnapelõtt jutottam el az ARM architektúrás processzorokig. (Elõrõl kezdtem egészen a 8086-tól és motorola 6809-tõl de ez most mindegy)
 Milyen szoftverekkel lehet ARM processzorokra szoftvert írni? Vagy ott is az ottani operációs rendszer függvényit kell használni? Milyen programozási nyelvet használasz te?
Title: Re: iEP128emu
Post by: varrogy on 2012.February.11. 23:05:33
Tegnap vagy tegnapelõtt jutottam el az ARM architektúrás processzorokig. (Elõrõl kezdtem egészen a 8086-tól és motorola 6809-tõl de ez most mindegy)
 Milyen szoftverekkel lehet ARM processzorokra szoftvert írni? Vagy ott is az ottani operációs rendszer függvényit kell használni? Milyen programozási nyelvet használasz te?

Az iOS (iPad, iPhone) speciális eset én XCode ide-t, objective-c és az emu miatt c++ -t is használok.
Attól függ milyen programot szeretnél írni ARM-ra, ha csak egy hello world-öt akkor elég a sima c nyel és az ansi c függvény könyvtárak (pl.: stdio, ...),
Mi a cél, milyen szoftvert szeretnél írni?
Title: Re: iEP128emu
Post by: Tuby128 on 2012.February.12. 00:32:55
A célom ismerkedés. Egy mikroprocesszoros rendszert sokmindenre lehet használni.
Akkor te most az iPhone operációs rendszerére fejlesztesz, jól értem?
Title: Re: iEP128emu
Post by: Ep128 on 2012.February.12. 00:54:28
A célom ismerkedés. Egy mikroprocesszoros rendszert sokmindenre lehet használni.
Akkor te most az iPhone operációs rendszerére fejlesztesz, jól értem?

Itt többen is erõsen reméljük, hogy igen!  :lol:
Title: Re: iEP128emu
Post by: varrogy on 2012.February.12. 18:22:02
Nagyjából összeállt az iOS-re az emulátor, egyre több mindenre fény derült.
Viszont rossz hír, hogy a iPhone 3G-s régi telefonon 10%-15% (~2.5fps) megy az emuláció. iPad-et és iPad2-t sajnos nem tudtam mérni, de a mértek alapján félek azok is lassúak lesznek.
Ugyanazt a tesztet próbáltam rekonstruálni, mint amit az ep128emu topicban néztetek desktopokon korábban (alt+w, no speed limit)
Egyelőre nem tudom, hol lehetne gyorsítani az emu-n, de sajnos úgy tűnik, hogy ehhez az emulátor implementációhoz kevesek az apple által használt arm procik!
Title: Re: iEP128emu
Post by: Zozosoft on 2012.February.12. 18:27:33
Egyelõre nem tudom, hol lehetne gyorsítani az emu-n, de sajnos úgy tûnik, hogy ehhez az emulátor implementációhoz kevesek az apple által használt arm procik!
Ha jól követtem, akkor itt az a baj, hogy nem gépikódban fut az emu, ha nem valami szoftverese izén, kvázi interpreterben? Ez alapján nem lep meg a dolog.
Ha jól tudom Androiddal is ugyanez a helyzet, talán még a régi Windows Mobilon lenne esély.
Title: Re: iEP128emu
Post by: varrogy on 2012.February.12. 18:55:05
Ha jól követtem, akkor itt az a baj, hogy nem gépikódban fut az emu, ha nem valami szoftverese izén, kvázi interpreterben? Ez alapján nem lep meg a dolog.
Ha jól tudom Androiddal is ugyanez a helyzet, talán még a régi Windows Mobilon lenne esély.
Sajnos iOSen gépikódról van szó (ugyanúgy gcc-vel kerül fordításra a kód ahogy pl linux alatt is), androidnál valóban virtuális gépben futna a dolog, de ott is van lehetőség natív kód futtatására. Jelenleg annyiról van szó, hogy a ~412mhz-es arm v6 processzor biztosan nem elegendő a nick, dave és a z80 emulációjához.
Az iOS szimulátorban egyébként ~900%-ot ér el az ep128emu. (de ott ugye nincs processzor limit)
Title: Re: iEP128emu
Post by: Zozosoft on 2012.February.12. 19:05:18
Mondjuk Android fronton terjedõben a 2 magos, 1Ghz vagy nagyobb procik. Persze ez csak akkor jelent számunkra valamit, ha valóban megoldható a natív kód.

Amúgy ha az emulátor Spectrum módját nézed, úgy mi a helyzet? Ott egyszerûbb a kép meg a hang.
Title: Re: iEP128emu
Post by: varrogy on 2012.February.12. 19:55:17
Mondjuk Android fronton terjedõben a 2 magos, 1Ghz vagy nagyobb procik. Persze ez csak akkor jelent számunkra valamit, ha valóban megoldható a natív kód.

Amúgy ha az emulátor Spectrum módját nézed, úgy mi a helyzet? Ott egyszerûbb a kép meg a hang.

Spectrum módban is 10-15% között van (48k-s rommal).
Title: Re: iEP128emu
Post by: IstvanV on 2012.February.12. 21:16:25
Spectrum módban is 10-15% között van (48k-s rommal).

Ha Spectrum módban nem gyorsul jelentősen, akkor talán nem a hardver emuláció fogyasztja a CPU idő nagy részét, hanem az audio vagy video driver, vagy valami más ? ~400 MHz-es Pentium II processzoron elvileg már el lehetne érni a 100% sebességet, bár nem tudom, az ARM az órajelhez képest mennyire gyors.
Title: Re: iEP128emu
Post by: varrogy on 2012.February.12. 22:32:32
Ha Spectrum módban nem gyorsul jelentősen, akkor talán nem a hardver emuláció fogyasztja a CPU idő nagy részét, hanem az audio vagy video driver, vagy valami más ? ~400 MHz-es Pentium II processzoron elvileg már el lehetne érni a 100% sebességet, bár nem tudom, az ARM az órajelhez képest mennyire gyors.


Átnézem újra, mert tuti valami felett elsiklott a figyelmem.
A sebességet az audió és a videó kódokat kikommentezve (null driverrel) néztem az alábbi kódrészletet felhasználva.

Code: [Select]
    Ep128Emu::VMThread::VMThreadStatus  vmThreadStatus(*vmThread);
   
    if (statsTimer.getRealTime() >= 0.5) {
        statsTimer.reset();
        int32_t newSpeedPercentage = int32_t(vmThreadStatus.speedPercentage + 0.5f);
        if (newSpeedPercentage != oldSpeedPercentage) {
            oldSpeedPercentage = newSpeedPercentage;
            printf("%i%%\n", oldSpeedPercentage);
        }
    }
Title: Re: iEP128emu
Post by: Ep128 on 2012.February.13. 00:10:40
Abszolút nem szakértek hozzá, csak csöndesen drukkolok, de azt nagyon! :-)
Remélem, igazad van és valami felett még elsiklottál (ennyi idõ után ez teljesen természetes lenne még)...
Nem rég jelent meg valamelyik PC -s játék Apple -re és egy az egyben szuperül megy ott is, nem eszi a procit, stb.
Ehhez kapcsolódóan ugrott be, hogy ha az megoldható volt (biztos nagyon más, de) akkor ennek is kell valami módjának lenni, hogy ne akarjon 900% -ot a prociból. :-)
Remélem, ha Istvánnal összedugjátok a fejeteket, valami kiderül, mi igényli ezt a hatalmas energiatöbbletet iOS -en!
Title: Re: iEP128emu
Post by: varrogy on 2012.February.13. 13:16:45
Abszolút nem szakértek hozzá, csak csöndesen drukkolok, de azt nagyon! :-)
Remélem, igazad van és valami felett még elsiklottál (ennyi idõ után ez teljesen természetes lenne még)...
Nem rég jelent meg valamelyik PC -s játék Apple -re és egy az egyben szuperül megy ott is, nem eszi a procit, stb.
Ehhez kapcsolódóan ugrott be, hogy ha az megoldható volt (biztos nagyon más, de) akkor ennek is kell valami módjának lenni, hogy ne akarjon 900% -ot a prociból. :-)
Remélem, ha Istvánnal összedugjátok a fejeteket, valami kiderül, mi igényli ezt a hatalmas energiatöbbletet iOS -en!

iPad 1 -en teszteltem ott 86%-90% az emuláció sebessége.
A korábban írt 900% nem azt jelentette, hogy annyit enne a prociból, hanem csak annyit, hogy az én számítógépemen szimulátorban futtatva az alkalmazást 9szer gyorsabban tudja futtatni mint amennyi minimum kell ahhoz, hogy elérjük az EP rendszer alap sebességet.

és ez a sebesség iPhone 3G-n 10-15%, iPad 1-en pedig 86%-90% (ez utóbbi már majdnem elegendő)
Title: Re: iEP128emu
Post by: IstvanV on 2012.February.13. 13:29:49
iPad 1 -en teszteltem ott 86%-90% az emuláció sebessége.

Spectrum és CPC módban mennyi ?
Title: Re: iEP128emu
Post by: varrogy on 2012.February.13. 14:07:02
Spectrum és CPC módban mennyi ?


Spectrumban 95%-100% (48k-s rommal)
CPC-t nem sikerült még beizzítani, ott melyik szegmensre kell betölteni a cpc464.rom-ot? 0xC0?
(amúgy rom nélkül, fut a képernyő és 60-65% a cpc mód)
Title: Re: iEP128emu
Post by: IstvanV on 2012.February.13. 15:03:49
Tehát a Spectrum mód nem gyorsabb jelentősen (PC-n legalább 1.5x a különbség Alt+W-nél). :???:

CPC 6128 konfiguráció beállítása:
Code: C++
  1.     vm.resetMemoryConfiguration(128);
  2.     vm.loadROMSegment(0x80, "cpc6128.rom", 0);
  3.     vm.loadROMSegment(0xC0, "cpc6128.rom", 0x4000);
  4.     vm.loadROMSegment(0xC7, "cpc_amsdos.rom", 0);
Elvileg az EP és a Spectrum között kellene lennie a sebességnek, de közelebb az EP-hez.
Title: Re: iEP128emu
Post by: Ep128 on 2012.February.13. 17:12:56
és ez a sebesség iPhone 3G-n 10-15%, iPad 1-en pedig 86%-90% (ez utóbbi már majdnem elegendõ)

Na, akkor (ha jól értelmezem) az iPhone 4G S -en már elvileg mennie kellene viszonylag normálisan. :)
Reménykedés...
Title: Re: iEP128emu
Post by: varrogy on 2012.February.14. 18:38:23
Tehát a Spectrum mód nem gyorsabb jelentősen (PC-n legalább 1.5x a különbség Alt+W-nél). :???:

CPC 6128 konfiguráció beállítása:
Code: C++
  1.     vm.resetMemoryConfiguration(128);
  2.     vm.loadROMSegment(0x80, "cpc6128.rom", 0);
  3.     vm.loadROMSegment(0xC0, "cpc6128.rom", 0x4000);
  4.     vm.loadROMSegment(0xC7, "cpc_amsdos.rom", 0);
Elvileg az EP és a Spectrum között kellene lennie a sebességnek, de közelebb az EP-hez.


Sehogy sem akar a speccy emu gyorsabb lenni az EP-nél :)
CPC-t még nem próbáltam idő hiányában.

Már ennyire leegyszerűsítettem a kódot, de minden esetben ugyanazok az eredmények jönnek ki!
Code: [Select]
int main(int argc, char *argv[])
{
    @autoreleasepool {
             
        Ep128Emu::AudioOutput    *audioOutput    = NULL;
        Ep128Emu::VideoDisplay   *videoDisplay   = NULL;
        Ep128Emu::VirtualMachine *vm             = NULL;
        Ep128Emu::VMThread       *vmThread       = NULL;
        Ep128Emu::Timer          statsTimer;

        int32_t oldSpeedPercentage = 0;     
             
        audioOutput     = new Ep128Emu::AudioOutput();
        videoDisplay    = new Ep128Emu::OpenGLDisplay();
       
        vm = new Ep128::Ep128VM(*videoDisplay, *audioOutput);

        NSString *path = [[NSBundle mainBundle] pathForResource:@"exos21" ofType:@"rom"];
        vm->loadROMSegment(0x00, [path cStringUsingEncoding:NSUTF8StringEncoding], 0);
        vm->loadROMSegment(0x01, [path cStringUsingEncoding:NSUTF8StringEncoding], 16384);
       
        path = [[NSBundle mainBundle] pathForResource:@"basic" ofType:@"rom"];
        vm->loadROMSegment(0x10, [path cStringUsingEncoding:NSUTF8StringEncoding], 0);
       
        vmThread = new Ep128Emu::VMThread(*vm);
        vmThread->setSpeedPercentage(0);
        vmThread->pause(false);

        while (1) {
            Ep128Emu::VMThread::VMThreadStatus  vmThreadStatus(*vmThread);

            if (statsTimer.getRealTime() >= .5) {
                statsTimer.reset();
                int32_t newSpeedPercentage = int32_t(vmThreadStatus.speedPercentage + 0.5f);
                if (newSpeedPercentage != oldSpeedPercentage) {
                    oldSpeedPercentage = newSpeedPercentage;
                    printf("%i%%\n", oldSpeedPercentage);
                }
            }
            usleep(10000);
        }
    }
}

Title: Re: iEP128emu
Post by: varrogy on 2012.March.28. 18:33:26
Tehát a Spectrum mód nem gyorsabb jelentősen (PC-n legalább 1.5x a különbség Alt+W-nél). :???:

IstvanV:
Az OpenGL ES lett a szūk keresztmetszet,
 az lenne a kérdésem, hogy tudnál-e nekem segíteni abban, hogy a
drawFrame_quality1(Message_LineData **lineBuffers_,
                                         double x0, double y0,
                                         double x1, double y1, bool oddFrame_)
hogyan lehetne módosítani, hogy minél kevesebb textura rajzolassal tudjon lefutni (glTexSubImage2D sor).
Ugyanis úgy láttam, hogy minden képernyõ renderelés (double buffer, display quality 1 esetében) 21db texturát rajzol!
Sajnos ez az iOS-en iszonyat sok processzort megeszik, viszont ha mondjuk a generaált textura magasságát (GLsizei txtHeight = 48;) ra emelneém akkor mindehez csak 7 textura kellen ami 3x gyorsabb renderelést eredményezne.
De akár lehet, hogy egy textura segítségével is meg lehetne oldani, ezt nem tudom.
Szerinted megoldhato lehet a fent leirtak valahogy?

Koszi
Gyuri
Title: Re: iEP128emu
Post by: IstvanV on 2012.March.28. 20:12:57
Valószínűleg megoldható, akár 1 textúrával is, ami egyszerűsítene is a kódon. A textúra "darabolását" egyébként eredetileg azért építettem be, mert (legalábbis 5-10 évvel régebbi PC hardveren) javította a sebességet.
Title: Re: iEP128emu
Post by: IstvanV on 2012.March.28. 23:59:15
Módosított verzió (nem biztos, hogy hibátlan):
  [attachurl=#]
  [attachurl=#]
  [attachurl=#]
Title: Re: iEP128emu
Post by: varrogy on 2012.March.29. 11:33:25
Módosított verzió (nem biztos, hogy hibátlan):
  (Attachment Link)
  (Attachment Link)
  (Attachment Link)


Tökéletesen mūködik és gyors lett köszi szépen!!
Az alábbi módosítást tettem még bele, a glBegin(GL_QUADS); ... glEnd(); sorok helyett.
így az openGL és openGL-ES1 is megeszi. 
Esetleg ezt a mostani emuba is lehetne használni, de a kompatibilitáson kívul megsporolhatunk vele egy plusz haromszoget :)


Code: [Select]
void OpenGLDisplay::drawFrame_quality1(Message_LineData **lineBuffers_,
                                         double x0, double y0,
                                         double x1, double y1, bool oddFrame_)
  {

.
.
.
      GLfloat textureCoords[] = {
          GLfloat(0.0), txtycf0,
          GLfloat(384.0 / 512.0), txtycf0,
          GLfloat(0.0), txtycf1,
          GLfloat(384.0 / 512.0), txtycf1,
      };
     
      GLfloat vertices[] = {
          x0, ycf0,
          x1, ycf0,
          x0, ycf1,
          x1, ycf1,
      };

      glEnable(GL_TEXTURE_2D);
      glEnableClientState(GL_VERTEX_ARRAY);
      glEnableClientState(GL_TEXTURE_COORD_ARRAY);
     
      glVertexPointer(2, GL_FLOAT, 0, vertices);
      glTexCoordPointer(2, GL_FLOAT, 0, textureCoords);
      glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
     
      glEnableClientState(GL_VERTEX_ARRAY);
      glDisableClientState(GL_TEXTURE_COORD_ARRAY);
      glDisable(GL_TEXTURE_2D);
     
.
.
.
}