A 4.5 az a Z80 ciklusok száma 1 NICK slot alatt, közelítően (4000000 / 889846 = 4.49516). Én alapvetően úgy oldottam meg, hogy minen VRAM és NICK port hozzáférésnél várni kell a következő NICK slotig, 1/2 Z80 ciklus felbontással. Ezen kívül van még egy fix késleltetés is, ami kb. 5/16 NICK slot + egy néhány ns-os érték (ami függ a hozzáférés típusától, azaz kissé eltér M1, normál írás/olvasás, és port I/O esetén, de ez minimális mértékű). Itt található egy program, amellyel tesztelhető a VRAM időzítés, Zozosoft több valódi gépről is küldött eredményeket, amelyekkel az emulátorok összehasonlíthatók.

Az a baj, hogy en itt mar eleve, az elmeletet sem latom tisztan. Most elfeledkezve az emulator adta megvalositasi lehetosegekrol ... hogyan nez ki ez valodi gepen? Amennyire en tudom, a Nick ugye egy fix frekvenciaval olvas. Marmint egy Nick slot alatt 2 byte-ot. De pl mindig? Van olyan videomod ahol eleg egy is, pl LPIXEL, akkor mi van? Masreszt, ezt ugy kell elkepzelni, hogy a Nick altal adott olvasasi jel formaja az szep egyenletes, slot-on kivul, belul, minden, szabalyos? Na, ehhez jon akkor hozza - tudomasom szerint - hogy a Nick szepen kicsit "megnyomoritja" a CPU orajelet (ha o is VRAM-hoz ferne hozza v Nick I/O portjahoz), annak erdekeben, hogy ne utkozzenek. Na ezt eleg nehezen tudom elkepzelni. Egyreszt, mivel a CPU orajelet vmi generalja, azt hogy allitjak meg? Mert az szepen megy "magatol", ha a CPU fele "nyujtani" kell, akkor amikor ennek vege, lehet akar egy csunya tranziens is, mert kozben a kristaly (vagy ami generalja) mar epp a masik szintre menne, stb. Masreszt, a "nyujtas" ha jol tippelek nem is orajel egesz szamu tobbszorose, szoval ezt pontosan emulalni tenyleg nehez lenne (mar ha erdemes egyaltalan ...).

Vagy kiforditom az egesz Xep128-at: jelenleg CPU-ra orajelet szamolja ahhoz idozit, es abbol lesz a Nick slot frekvencia. Lehet inkabb ugy kene, hogy Nick slot-okat renderelek szepen, es ahhoz aztan a CPU-t. Igy "termeszetesebben" adodik, hogyan befolyasolja a Nick mukodese szegeny CPU-t Mondjuk tok jo, akkor mar csak a Dave kavar be, mert az meg jelenleg a CPU-hoz van szinkronizalva (/16 v /24), de ha meg nyujtogatjak szegeny CPU orajelet, abbol a Dave is kap, vagy hat nekem ez az egesz kicsit talanyos

Tudom, irtad, hogy lehet kb megoldani, de oszinten en a valodi mukodesbol szeretnem megerteni

A megvalósításnál problémát jelenthet az, hogy a Z80 utasításokon belüli időzítés is fontos, azaz hogy pontosan mikor történnek az egyes memória és I/O műveletek (pl. az OUT (C), A utasításnál 2.0, 6.0, és 11.5 ciklusnál), nem tudom, a z80ex támogatja-e ezt.

Hat ebben nem vagyok biztos, hogy korrektul, de amugy elvileg igen, a t-state infot opcode-on belul is szamolja. Az mas kerdes, hogy korrekt-e a megoldas, marmint a hasznalt ertekek, es nem csak pl a vegeredmeny jo Amit irtal abban mondjuk a 11.5 az elgondolkoztatott, mivel tort szamu orajelet viszont tuti nem tart nyilvan ... Mondjuk amit irtal az fura, az OUT (C), A az 12 (?) t-state, akkor ha 11.5-nel kezdodik a port iras, akkor csak fel orajelciklusa van a periferianak, hogy fogja? Vagy mire vonatkozik a 11.5, akkor mi tortenik?

https://github.com/lgblgblgb/xep128/blob/master/z80ex/opcodes/opcodes_ed.c

482. sortol, az OUT() macro 3. parametere, elvileg az (bar z80ex belsejet annyira nem ismerem, csak igy kb), hogy hanyadik ciklusnal. Az opcode ED resze mondjuk kulon van, tehat ugy nezendo a dolog Igy csak 8 ciklus, de az ED-re ramegy 4, tehat a 12 elvileg kijon.

Erről néhány oldallal korábban írtam, az ep128emu-ban gyakorlatilag a hang lejátszás lassítja 100% sebességre az emulációt. Ez a legegyszerűbb esetben annyit jelent, hogy ahol eredetileg usleep() vagy hasonló hívás volt, ott helyette arra vár, hogy legyen hely a hang pufferben. Ez azonban nem ad igazán jó eredményt, az audio puffer gyakran túl nagy ahhoz, hogy jó felbontással lehessen időzíteni, ezért így könnyen előfordulhat, hogy láthatóan és zavaróan akadozik a kép pl. scrollozásnál.

Na. Ismeros Amikor MPlayer fejleszto voltam (bar ebben a temaban ott sem jeleskedtem, inkabb mashol), ott is ugy epult fel, hogy az audiohoz van szinkronizalva minden, ha nincs hang vagy "noaudio" opcio akkor vmi fake cuccot csinal. Ott is az volt a gond, hogy nehany "vacak" drivernel a buffer kezeles csapnivalo volt, igy idozitesre hasznalva eleg fura dolgok adodtak neha

NOP futattása VRAM-ban, a képen Z80 clock, és RD:

[ Guests cannot view attachments ]
(Majdnem a "találjuk ki a kép alapján, melyik játék" topikba tettem ezt.)
Ez a folyosó nagyon szűk, elég nehéz lehet rajta átférni.

Vagy kiforditom az egesz Xep128-at: jelenleg CPU-ra orajelet szamolja ahhoz idozit, es abbol lesz a Nick slot frekvencia. Lehet inkabb ugy kene, hogy Nick slot-okat renderelek szepen, es ahhoz aztan a CPU-t. Igy "termeszetesebben" adodik, hogyan befolyasolja a Nick mukodese szegeny CPU-t Mondjuk tok jo, akkor mar csak a Dave kavar be, mert az meg jelenleg a CPU-hoz van szinkronizalva (/16 v /24), de ha meg nyujtogatjak szegeny CPU orajelet, abbol a Dave is kap, vagy hat nekem ez az egesz kicsit talanyos

Én a slot-ot használtam a fő emulációs ciklusban az egységnyi időnek, illetve Spectrum és CPC esetén ennek megfelelően egy karakter időtartamát vízszintesen:

A Spectrum és CPC emulációban még további trükköket alkalmaztam annak a megoldására, hogy a Z80 és a többi alkatrész (ULA, CRTC, stb.) között ciklus pontosságú legyen a szinkronizáció utasításon belül is, mivel egy utasítás hosszabb lehet, mint egy slot. Ez a Spectrumos Z80 port írás függvény például hívja az ULA/hang/stb. emulációt (vm.runOneCycle()) ha már elég idő telt el, és hasonló megoldás található a memória írásnál is:

Az EP emulátor egyelőre nem tud ilyet , de az EP-s programok szerencsére kevésbé érzékenyek az időzítés pontosságára.

A plus4emu-ban a 6502 emulátor nem utasításonként, hanem ciklusonként fut, és a TED emulátor hívja egy karakteren belül megfelelő időzítéssel legfeljebb kétszer.

Erdekes a fel ciklusos updateCPUHalfCycles() es hasonlok Amugy a z80ex egy library (csak kozben kisse kihereltem ...), amit a FUSE Specrum emu alapjan (is?) irtak. Tud olyat, hogy t-state callback, azaz minden t-state-nel meghiv egy fuggvenyt, az utasitas vegrehajtasa soran. De ilyen fogalom nem igazan van benne ahogy nezem, hogy half cycle ...

Az elég, ha a z80ex annyi információt ad, hogy milyen művelet történik (M1, memória, vagy I/O - ezeken belül az időzítés fix, illetve csak a NICK vagy a DAVE módosíthatja) és az utolsóhoz képest hány Z80 ciklus telt el, a többit már az emulátor valósíthatja meg.

https://github.com/lgblgblgb/xep128/commit/f942616de761b74e02913608a678b24aa5c1d87f

Elso roppant bena, pontatlan, elvi szinten hibas, stb megoldas. Viszont valamit legalabb csinal, haaat, fogjuk ra SD au player amugy vegy vele, csak hat neha csuklik, de ez nem is meglepo

Ja, es UNIX power, SD kartya device-t be-symlinkeltem sdcard.img -nek, igy az emulator vegulis igazi SD kartyat hasznalt, ha az OS-en at is

Ja, koszi, olvastam am azokat Csak ezzel meg nem foglalkoztam.

Működik

akkor utana elvileg lesz, max egy kis ido mulva csak Igen, frekvencia sem teljesen pontos, akad, szaggat, nincs ez, nincs az, stb

Az akadozást az okozhatja, hogy az időzítést továbbra is az emu_timekeeping_delay() végzi, és az audio puffer állapotát nem veszi figyelembe. Így idővel "elmászik" az időzítés, és a puffer megtelik (overrun) vagy elfogy az adat (underrun), azaz szaggat a hang. Erre az egyszerűbb megoldás az emu_timekeeping_delay() helyett az audio puffer írásánál várakozni (pl. SDL_SemWait()) ha megtelik, amíg újra lesz szabad hely. Így azonban teljesen az audio drivertől függ az időzítés, tehát könnyen előfordulhat, hogy a kép fog akadozni. Egy másik lehetőség az eredeti időzítő rutinban a sebességet szabályozni az audio puffer állapotától függően (gyorsítani 50% alatt, lassítani 50% felett).