Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 164806 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #135 on: 2015.June.19. 10:55:30 »
Kipróbáltam egy 4.3GHz-es i5-ösön, itt folyamatosan 0%-ot ír :-)

Talán megbízhatóbb módszer lenne kikapcsolni a sebesség korlátozást, és azt mérni, hányszor gyorsabb így az emuláció a normál 100% sebességnél.

Ati Radeon HD6850

Az AMD driver nem biztos, hogy optimálisan működik az ep128emu OpenGL video kimenetével. :oops:

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #136 on: 2015.June.19. 11:15:33 »
Az SDL 1 ms felbontással tud hordozható módon időt mérni és várakozni.

Nalam az is a baj, hogy ez a Xep128 nevu szornyedveny (tenyleg az, foleg, ha valaki megnezi a forrast ...) eredendoen Linux alatti probalkozasaim eredmenye. Van benne jo par dolog, ami nincs atirva igazan SDL alapura, es egyaltalan fura, hogy mux Win alatt, ez gondolom annak koszonheto, hogy a MinGW "emulal" nemi POSIX API-t, es azzal igy megy. Pl konkretan ugye a gettimeofday() -t hasznalom, illetve az usleep()-et aztan.

Ja, es koszi az infokat persze, latszik, hogy te mar tapasztaltabb vagy az ugyekben, erdekes volt ez az idomereses okfejtes is, foleg, ha mar windows teruletekre tevedunk, amirol - oszinten szolva - fogalmam sincs :)
« Last Edit: 2015.June.19. 15:01:12 by lgb »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #137 on: 2015.June.19. 18:23:23 »
Reset megjavítva :-)
Nekem úgy 0-7% között írja.

Nekem 64 bites Linuxon stabilan 6% (3.3 GHz-es Sandy Bridge CPU, dd if=/dev/urandom of=/dev/null futtatása közben, hogy valóban 3.3 GHz-es legyen, és ne lassítsa le a rendszer energiatakarékosság céljából). Úgy látszik, valóban az "emulált", kis felbontású gettimeofday() lehet a hibás értékek kiírásának az oka. A top szerint ~6.3% a CPU fogyasztás.

Ugyanezen a gépen az ep128emu 2.0.9.1 (64 bites SourceForge Linux verzió) kb. 7.6% (video minőség = 2, single buffered, Nvidia OpenGL, alacsony hangminőség). Alt+W-nél 3010% a sebesség, és 103.5% a CPU fogyasztás.
« Last Edit: 2015.June.19. 18:37:49 by IstvanV »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #138 on: 2015.June.19. 19:08:57 »
Nekem 64 bites Linuxon stabilan 6% (3.3 GHz-es Sandy Bridge CPU, dd if=/dev/urandom of=/dev/null futtatása közben, hogy valóban 3.3 GHz-es legyen, és ne lassítsa le a rendszer energiatakarékosság céljából). Úgy látszik, valóban az "emulált", kis felbontású gettimeofday() lehet a hibás értékek kiírásának az oka. A top szerint ~6.3% a CPU fogyasztás.

Kivancsi lennek (majd kiprobalom), hogy amugy a POSIX altal javasolt (gettimeofday() elvileg elavult ...) clock_gettime()-al mi a szitu: van-e Windows-ban / MinGW-ben, akarmi, es jobb-e. Vagy jobb-e mint a nativ SDL-es megoldas egyaltalan. Vagy inkabb azt kene hasznalnom :) Ha lehet, nem szeretnek sok windows specifikus reszt, azert se, mert nem ertek hozza :)

Tenyleg, ha mar itt beszelgetunk :) Egy dolgot sose ertettem, igaz nem is probaltam (na jo JSep-ben webaudio ballepeseim voltak, de sokra nem volt jo): hogy a fenebe szokas emulatorba audio feature-t tenni? :) Ezen elgondolkodtam, de hirtelen nem jutott normalis megoldas az eszembe. Ugyanis: az Xep128 jelenleg eleg primitiv modon egy valtozo (balancer) segitsegevel probalja a megnevezett ertek korul tartani a Nick es a Z80 sebessegenek aranyat, majd egy frame-nyi slot utan ugye szamol idot, stb, ez alapjan alszik, az alvas valos hossza alapjan beleszamitja a kovetkezobe, stb stb. Ami a lenyeg: tegyuk fel, hogy Dave emulacio kozben irkalok vmi bufferbe, amibol lesz az audio. Az en gondolatmenetem itt akadt el. Alapvetoen azt mondanam, hogy legyen pl egy "cirkularis" buffer, iras es olvasas mutatoval, Dave irja hang emunal, nyilvan vmi meg lejatszast csinalgat, olvasas jelleggel. Na, az nem tiszta nekem, hogy lehet ezt real-time idoziteni. Hiszen _tokeletesen_ pontos tuti nem lesz a Z80 emulacio real time-ban, mert multitask OS van alatta, idomeres sose lehet teljesen pontos (gettimeofday() nelkul sem, stb). A hanglejatszasnal meg vmi fix sampling rate van. En azon tovabb nem jutottam, hogy itt tuti vmi buffer overrun vagy underflow lesz allandoan ossze vissza, otletem nincs, hogy lehetne egymashoz szinrkonizalni a lejatszast az emulaciot, es mindezt meg realtime-ban az EP sebesseget emulalva is, sleep-elgetve neha ugye.

Na szep hosszan kielemeztem problemamat :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #139 on: 2015.June.19. 20:00:24 »
Az audio API-k általában két alapvető megoldás valamelyikét használják:

"blocking" - ilyenkor az alkalmazás szempontjából a hang kimenet egyszerű file íráshoz hasonlóan működik, és ha megtelt a puffer, akkor várakozik, amíg újra van szabad hely. Ilyen vagy hasonló elven működik az OSS (/dev/dsp), az ALSA, és Windowson az MME (régi waveOut* interface, ami már a 16 bites verziókban is megtalálható volt).

"callback" - az alkalmazás definiál egy függvényt, ami bizonyos időközönként meghívásra kerül a főprogramhoz képest külön szálon, és fel kell töltenie egy puffert. Ezt a megoldást használja például az SDL és a JACK.

Az ep128emu által használt PortAudio mindkettőt ismeri, de a "blocking" mód (amit egyébként az emulátor preferál) csak bizonyos API-k esetén elérhető.

Ha az API a programnak nem megfelelő elven működik, akkor cirkuláris pufferrel konvertálható a másik megoldásra. Erre (callback -> blocking konverzió) található példa az ep128emu-ban is a soundio.cpp-ben.

Emulátorban a legegyszerűbb, de nem optimális megoldás a blocking módot használni (vagy emulálni, ha nem elérhető), és csak azzal lassítani az emulációt valós idejű sebességre. Ennek az a hátránya, hogy sok audio API nem tud elég pontosan és nagy felbontással időzíteni, hogy az emulátor futása egyenletes legyen, azaz például ne akadozzon jól láthatóan az 50 Hz-es scrollozás.

Ezért az ep128emu (soundio.cpp) tartalmaz egy olyan trükköt blocking módban (ALSA, OSS, MME, és WASAPI), hogy gettimeofday/usleep (illetve Windowson QueryPerformanceCounter/Sleep) megoldással időzít, de a sebességet dinamikusan változtatja az audio puffer töltöttségétől függően. Ha ez 50% körüli, akkor normál 100% sebességgel próbál futni, ha valamivel több/kevesebb van a pufferben, akkor kissé (először csak +/-5, aztán 10% mértékben) lassul/gyorsul, extrém esetben - ha tele vagy majdnem üres a puffer - pedig teljesen az audio kimenet szabályozza a sebességet. Ez a soundio.cpp-ben a 250. sor után található. Így a sebesség átlagban követi a hang kimenetet, de a nagy felbontású időzítés előnyével.

Probléma még, hogy a DAVE sokkal magasabb frekvencián fut, mint amit a hangkártyák támogatnak, ezért a kimenetet konvertálni kell. Erre az ep128emu-ban az snd_conv.cpp tartalmaz egy viszonylag rossz (de gyors) és egy jó minőségű megoldást, amelyek értelemszerűen a "high quality" hang beállítás két értékének felelnek meg. A konverzió alapértelmezés szerint 500 kHz-ről (250 és 166 2/3 kHz legkisebb közös többszöröse) történik a választott mintavételezési frekvenciára, például 48 kHz-re. Található a konverterben még felüláteresztő szűrő is, ugyanis a DAVE kimenete mindig pozitív (pl. maximális hangerejű négyszögjel 0 és 63 között váltakozik), ezért a DC offszetet el kell távolítani.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #140 on: 2015.June.19. 20:36:34 »
Quality 3

Ezen a módon valószínűleg javítani lehetne shader alapú megoldással. A quality 2 mennyivel gyorsabb ?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #141 on: 2015.June.19. 21:01:59 »
A quality 2 mennyivel gyorsabb ?
Majd megnézem. Az ALT+W egyébként kb 3500% azon a gépen.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #142 on: 2015.June.20. 12:14:15 »
A korábban említett (lassú) AMD laptopon a shaderre átalakított quality 3 mód valóban eredményezett némi gyorsulást, bár lehet, hogy ez a módosított verzió még tartalmaz hibá(ka)t. :oops: Az eredeti kód CPU használata 61-62% körül volt (single buffered, hang letiltva), a shader ezt 41%-ra csökkentette, most a GPU-nak kell valamivel többet dolgoznia, de modern gépeken ez a hatékonyabb.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #143 on: 2015.June.21. 03:02:46 »
Page Up/Dwn-ra lehetne turbo kapcsolót tenni? Mondjuk a valódi gépen szokásos 4/6/7.12/10 között kapcsolgatna fel/le.

Hat ... vmi hasonlo kesz (= szokott hely, stb, nem kell mondani), de hogy muxik-e ... Ja, meg van OSD. Hat eleg furan nez ki, de mind1 :-) Normalis 16x16 bitmap fontot nem talaltam hozza, ami latszik az egy google kep kereses :) funkcioval talalt kep, amibol kivagtam (na nem kezzel, programommal) az egyes karakterek mintait, igy sikerult ilyenre ...
« Last Edit: 2015.June.21. 03:47:46 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #144 on: 2015.June.21. 11:30:59 »
@IstvanV: amugy kozben rajottem, hogy talan miert a Lua-t valasztottad beagyazott scriptnyelvkent az ep128emu-ba. Legalabbis tippelek. Ui par hete en is gondolkodtam, hogy esetleg ha lesz valami normalis UI, stb, akkor nem kodolom le C-ben, hanem lenne egy interface, amivel vmi scriptnyelv tudna rangatni, es abban lenne megirva vegulis az UI/stb. Meg hat masra is jo, ugye. Mivel en python parti vagyok, meg is neztem. Haaaat, nem trivialis azt igy beagyazni, de a gugli keresesek kozott szamtalan lua-s cucc felbukkant, es elolvasva tenyleg egyszeru+nagyszeru a lua ilyen celu hasznalata ...

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Xep128
« Reply #145 on: 2015.June.21. 11:57:36 »
A Lua-t nem csak egyszerűbb beágyazni, de sokkal kisebb és gyorsabb (különösen a LuaJIT használatával) is, mint a Python, és nincsenek függőségei, ami egyszerűsíti a bináris csomagok készítését. Több PC-s játék is Lua-t használ valószínűleg hasonló okokból. A sebesség fontos, mert hasznos, ha a debuggerben lehet minden Z80 utasításnál script kódot futtatni, és nem csak 1-2 sort.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #146 on: 2015.June.21. 12:11:48 »
A Lua-t nem csak egyszerűbb beágyazni, de sokkal kisebb és gyorsabb

Jo, hat elso korben nekem ez tunt fel, meg gyakorlati tapasztalat hianyaban ... :)

Ezert is gondolom, hogy hasznos emulatort irni: az ember olyasmikkel is megismerkedik, amit teljesen mas teruleteken is hasznositanit tud aztan, mint tudast.
« Last Edit: 2015.June.21. 12:55:11 by lgb »

Offline DrPrery

  • EP user
  • *
  • Posts: 264
  • Country: hu
Re: Xep128
« Reply #147 on: 2015.June.21. 19:05:29 »
Quote
A Lua-t nem csak egyszerűbb beágyazni, de sokkal kisebb és gyorsabb (különösen a LuaJIT használatával) is, mint a Python,

Úgy találtam én is, hogy a Lua kb. 2-2.5x gyorsabb a Python-nál. Ha JIT-et akar az ember Python-on, arra meg van a PyPy, de a LuaJIT meg annál is gyorsabb 2-szer... :)

Amúgy ami a Xep128 forráskódját illeti, merre van a xep_rom.hex nevű file...? Nem találom, vagy csak én vagyok vak...?

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #148 on: 2015.June.21. 19:58:39 »
Amúgy ami a Xep128 forráskódját illeti, merre van a xep_rom.hex nevű file...? Nem találom, vagy csak én vagyok vak...?

Lasd Makefile. Forditaskor allitja elo a xep_rom.rom -bol:

Code: [Select]
xep_rom.hex: xep_rom.rom
        od -A n -t x1 -v xep_rom.rom | sed 's/ /,0x/g;s/^,/ /;s/$$/,/' > xep_rom.hex


Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #149 on: 2015.June.21. 20:00:26 »
Code: [Select]
[quote author=lgb date=1434909519 link=topic=1198.msg47984#msg47984]
        od -A n -t x1 -v xep_rom.rom | sed 's/ /,0x/g;s/^,/ /;s/$$/,/' > xep_rom.hex
:shock:
Ezt van ember aki érti? :oops: