Ugyanezen a gépen az ep128emu az 28-30%
Mondjuk windows eseten fog'sincs, de elmeletileg csalhat ez a CPU terheltseg kimutatas, attol is fugg, adott program milyen hivasokat hasznal, hogyan "alszik el" (sleep stb call). Igy lehet pl ket program ami azonos dolgot csinal, de mas CPU terhelest lat az ember. Persze nem tudom, hogy ez a helyzet-e. Mas: az is lehet, hogy a fo ok az elteresben az ep128emu nagyobb pontossaga. Egy emulatornal gond, hogy ugye multitask OS-en fut altalaban (Windows, Linux, miegymas) tehat neha mas process fut eppen. Ugyanakkor kb tartania kell az emulalt gep sebesseget. Alapesetben pl en azt csinalom, hogy fut a program addig, amig egy frame-nyi nick slot nincs kesz (kozben persze Z80 stb is). Ha ez kesz van, megnezem mennyi ideig tartott ez a PC-n, illetve tudom, mennyi ido lenne ez az EP-n. Ha a PC gyorsabb (remelhetoleg ...) akkor a ketto kulonbsegere "elaltatom" az emulatort, hogy mas is tudjon futni normalisan, de 100%-on porogjon a PC CPU-ja az emu miatt. Persze, ez az "elaltatas" nem pontos (multitask OS-eknel azert nem mikroszekundumonkent van feltetlen context change a process scheduler altal), illetve lehet context change az emu futasa kozben is, ezert sleep utan merem mennyi ideig tartott valojaban a "kert" sleep, es az elterest probalom korrigalni es figyelembe venni a kov sleep-nel. Igy kb beall egy normalis idozitesre, jobb esetben. Lathato, hogy a host OS (windows, linux) viselkedese azert befolyasolja igy is az emu mukodeset. Elmeletileg novelheto a pontossag, ha csokkentjuk a sleep-et, akar addig, hogy nincs sleep es a CPU-t "porgetve" egy ciklusban varom ki, amig real time szerint a kov. frame jonne. Ekkor viszont az lenne, hogy az osszes szabad CPU-t megenne az emu. Viszont pontosabb lenne. Szoval siman lehet, hogy az ep128emu jobb idozitese miatt van, hogy tobb CPU-t kenytelen megzabalni. Bar ezt nem tudom, igy van-e, ez csak elmeleti fejtegetes volt a reszemrol
![Smiley :)](/Smileys/phpbb/smiley.gif)
Azt inkabb nem fejtem ki, hogy adaptiv algoritmus kell, mert kozben a PC esetleg terhelve van mas process altal, meg mi van, ha hosszabb idon at nem tudja korrigalni (tul lassu a PC, elindult vmi magasabb prioritassal rendelkezo program, ami zabalja a CPU-t stb). A Nick/Z80 szinkronizacio Xep128-ban jelenleg annyi, hogy van egy valtozo, amit Z80 emulacio pl novel minden op code utan annyival, ahany T-state-ig tartott. Ha az eleri azt a szintet, ami T state-re atszamitva egy nick slot-hoz kell, akkor csinal egy nick slotot, es csokkenti a szamlalot. Ez a "balancer" valtozo dolga a ketto egyensulyanak beallitasa, alkalmasint 0 kozeleben kell tartani nyilvan ...
Es ez csak az emu "alap" idozitese, nemileg mas az eset, ha a nick-et Z80-at kene szinkronizalni, vagy T state szinten nezni ezt, Xep128-ban (es JSep-ben) semmi ilyen nincs jelenleg, azert is van, hogy a VRAM elerese nem lassabb, mint mas RAM-e, ami ugye viszont pontatlan emulacio, ha egy valodi EP-hez hasonlitjuk. Stb, lehetne meg talalni ilyen pontokat, plusz jelenleg Dave counterek kozul _semmi_ nincs emulalva (kivetel az 1Hz int-et okozo belso cucc), amivel programozhato interrupt rate, es/vagy hang lehetne krealhato. A hang meg ugye btw, megint kulon tema
![Smiley :)](/Smileys/phpbb/smiley.gif)
Szoval azert nem tennem le az eskut, hogy Xep128 nem lenne-e meg lassab is, mint most az ep128emu, ha tudna mindezt, amit az tud.
Az JSep-hez kepest amugy igy is pontosabb: eloszor is, nezi mennyi ideig tartott valojaban a sleep. Masreszt, jobb felbontasu a sleep hivas, mint ami JS-ben van. harmadreszt, elvileg legalabbis a dave 0xBF portja annyiban legalabb figyelembe van veve, hogy wait state-ek beallitasa, igaz, ez ugye VRAM-ra nem vonatkozik. Ez nem volt bonyolult, mivel Z80Ex rendelkezik lehetoseggel hogy plusz wstate legyen "injektalhato" az opcode vegrehajtasaba, es meg M1-et is jelzi, ez alapjan is tudok donteni.
Remelem mindenki remekul lefaradt a sok irasom utan
![Smiley :)](/Smileys/phpbb/smiley.gif)