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.
egy szem file-t nyit meg az ember gyerekeep128emunál erre jó a snapshot fájl.
ep128emunál erre jó a snapshot fájl.
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.
ha jól tudom a snapshot elvileg kiváltja még a romok betöltését is?
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?
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
ep128emunál erre jó a snapshot fájl.
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).
Ebben a kódban a VSYNC kezelés és a Frame rajzolás elvileg az OpenGL-en keresztül rajzol?
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?
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.
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)
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ú.
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++
#ifndef CPC_LSB_FIRST # if defined(__i386__) || defined(__x86_64__) || defined(WIN32) # define CPC_LSB_FIRST 1 # endif #endif
Valószínűleg az SDL megeszi az erőforrást :(
(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?)
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.Ok, ránézek aztán írok majd,
(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?)
Ha csinálok egy NULL drivert akkor elméletileg az elérhető maximum sebességgel fog futni az emuláció?
Sajnos nincs windowsom :(
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:
Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:
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. :)
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.
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.
(... é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... :-) )
Code: C++A dp.bufferingMode-ot érdemes 1-re állítani, ha az SDLGLDisplay létrehozásakor is double buffer mód van beállítva.
void SDLGLDisplay::draw() { while (!checkEvents()) Ep128Emu::Timer::wait(0.005); OpenGLDisplay::draw(); SDL_GL_SwapBuffers(); }
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.
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?
Milyen iPhoneod van?
(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. :) )
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?
(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?
Beengednek oda már más programot futtató programot?Ezen már én is gondolkoztam :-) Mi legyen a neve?
A neve végülis lehetne iEP128Emu, amíg nincs jobb ötlet.
Akkor valaki modi nevezze át a topic -ot... ;-)Így jó lesz?
Így jó lesz?
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 puffer méretet próbáltad állítani ? Ha az nem megfelelő, akkor akadozhat a hang.
Estére egy kis video ;)És a sebességre panaszkodtatok? Ez még gyorsabb is, mint az eredeti. :D
É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!
És a sebességre panaszkodtatok? Ez még gyorsabb is, mint az eredeti. :DIgen 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.
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?
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 keresd:
ü - @
* szerintem te a + jelet keresed - [
ö - ;
ä - :
< - \
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?
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?
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 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.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.
Ha jól tudom Androiddal is ugyanez a helyzet, talán még a régi Windows Mobilon lenne esély.
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).
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.
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);
}
}
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.
Spectrum és CPC módban mennyi ?
és ez a sebesség iPhone 3G-n 10-15%, iPad 1-en pedig 86%-90% (ez utóbbi már majdnem elegendõ)
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++Elvileg az EP és a Spectrum között kellene lennie a sebességnek, de közelebb az EP-hez.
vm.resetMemoryConfiguration(128); vm.loadROMSegment(0x80, "cpc6128.rom", 0); vm.loadROMSegment(0xC0, "cpc6128.rom", 0x4000); vm.loadROMSegment(0xC7, "cpc_amsdos.rom", 0);
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);
}
}
}
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). :???:
Módosított verzió (nem biztos, hogy hibátlan):
(Attachment Link)
(Attachment Link)
(Attachment Link)
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);
.
.
.
}