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).

Egyertelmu, tenyleg nincs figyelembe veve Jelenleg max a szerencse, hogy kb olyan sebeseggel jatszik le ahogy az emu megy, de ugye tokeletesen sose fog megegyezni, tehat valoban, ezt majd az idozitesnel tenyleg figyelmbe kene venni Mondjuk spec otletem sem volt, hogy az SDL-ben hogy tudom meg a puffer allapotat, en arra tippeltem, hogy az SDL altal meghivott audio callback altal allitott "lejatszasi pointer"-t (mert ugye az altalam hasznalt puffer az joval nagyobb mint az SDL-tol kert/altala kapott puffer meret amit a callback-nek fel kell toltenie) es a Dave altal irt "felvetele pointert" figyelem, mert az alapjan latszik.

Ja, hat nem nagy szam megcsinalni, csak egy kis copy&paste customizalas, lasd pl JSep-ben is van De ugyis ujrairom, addig nem akarok hozzanyulni nagyon. Illetve elobb config file meg ilyenek erdekelnek most eppen.

Ja, es felre ne ertsd, koszi, hogy erdeklodsz es segitesz Nem azert irom, hogy nem erdekes, csak mindig van valami ami eppen jobban foglalkoztat, vagy hasonlo. Persze lehet, en latom rosszul, es masnak a hasznalhatosag szempontjabol mas lenne a fontos pont

Na, belepakoltam egy csomo "hulyeseget" Eloszor is van config file, benne elvileg nemi hulyen megoldott billentyuzetkisztas is, de csak pozicio map megy (tehat ha vmi shift-elve van a PC keyboard-on, EP-re is ugy megy at, es viszont ...). Az elejen - ha meg nem volt config file - kiir egy mintat, aminek elmondja az utvonalat egy ablakban, azt elvileg at lehet irni, meg at kell nevezni config nevre. Illetve command line parameterek is vannak, azzal is allithatoak a dolgok. xep128.exe -help megmondja amit erdemes tudni ...

Masreszt, szabadon configolhato ROM/RAM kiosztas, nem kell folyamatosnak lennie a RAM-nak sem. Ezt mindjart harom modon is lehet vegezni:

command line:

xep128.exe -ram 128      normal, "folyamatos" 128K ahogy EP128-on van, persze 128 helyett mas szam is lehet.
xep128.exe -ram @E0,F0-F3,F7        ez olyat csinal, hogy a felsorolt szegmens/szegmens tartomanyok lesznek RAM

A command line persze mindig felulbiralja a config file-t, ami pedig felulbiralja a built-in default configot (config file nelkul is elindul persze az emulator, nem kotelezo hasznalni). Lehet, masnak ez nem nagy ertek, nekem hasznos, mert altalaban mindent command line-bol csinalok

Ugyanez config file-ban is megadhato, akkor nem kell mindig beirni:

ram = 128
ram = @E0,F0-F3,F7

Ugyanez az emulatort futtatva a :XEP interface-en at is elerheto:

:XEP RAM
Ez a parancs megmutatja a memoriakiosztast, pl a ROM-okat is egyben.

:XEP RAM !128
:XEP RAM !@E0,F0-F3,F7

Itt a felkialtojel biztonsagi intezkedes, mert error check csak minimalis van ... nehogy egy extra leutessel egy sima lekerdezeshez kepest atconfiguralja magat, ha nem akarjuk. Ezutan persze auto cold reset lesz, mondanom sem kell. Ez persze nem irodik ki, mint config, csak amig fut az emulator.

ROM-okat is lehet kulon is toltogetni, command line es config file is jatszik esetleg. Formatum:

xep128.exe -rom@00 exosromfilename -rom@10 valami-a-tizes-hex-szegmensre

Gondolom ez alapjan kitalalhato a config file formatum is:

rom@00 = .....
rom@10 = .....

A :XEP-hez kello ROM-ot sajat magabol veszi, egy nem hasznalt szegmensre rateszi, azt nem kell kulon megadni (valojaban kerdeses, hogy regi EXOS-sal menne-e, szerintem nem, mivel ott nem minden szegmenst nezett ha jol tudom ...)

Config file-ba akar az "audio = 1" is berakhato, akkor magatol is lesz hang. Vagy command line-ban az -audio 1   (a 0 ertek a default, hogy nincs)

Stb, SD kartya path stb is adhato persze. Itt fontos, hogy ahol allomanynevek vannak, ott a Xep128 vagy vegigprobal par konyvtarat (pl ahol az exe is van), vagy ha abszulut path (tehat \-el kezdodik win alatt, vagy X:\ szeru modon kezdodik) akkor ugy ahogy van hasznalja, vagy ha a filenev pl @akarmi, akkor a @ helyere a "preferences directory" kerul, ami rendszer (es SDL ...) fuggo, ez latszik amugy amikor kiirja a sample config-ot es elmondja, vagy a :XEP EMU paranccsal is megnezheto.

A primo emulator reszben (:XEP PRIMO) mar lehet gepelni is, hurra :-/ Sokra nem jo, mert betolteni vele vmit nem igazan. Viszont hang is emulalva van pl. Az hogy mennyire pontos - valoszinuleg semennyire, mert egyreszt alapbol is gaz meg a hang a Xep128-al, masreszt Primo-on csak 1 bites software vezerles van, tehat fugg a CPU sebessegetol, ami tutira nem annyi most, mint Primo-on lenne

SD kartya emulacio kicsit talan jobb, nem akasztja meg annyira az emulatort, meg par biztonsagi ellenorzes stb is bekerult. Iras tovabbra sincs (meg) ...

APU emulaciot kb atirtam JSep-bol, de sokra nem jo, mivel tesztelni azota sem tudtuk, se hw nincs amihez hasonlitani lehetne, se teszt program

A console-t (ez mondjuk nem erdekes, ha nem onnan lett inditva ...) mar nem szemeteli teli. -debug opcioval kerheto log file, es abba irja, ha nincs megadva, akkor nem csinal ilyet, es csak "erdekesebb" dolgokat jeleniti meg az emulator mukodese soran.

A Z80ex-et jocsakan atpofoztam, kiraly dolog az absztrakcio, foleg ha tobb Z80-at emulal az ember egyszerre, de sok ilyen-olyan pointeren at lassabb is volt az egesz, korulmenyesebb, es a kod is nagyobb volt. Igy eleg szepen custom-izaltam mar tobb helyen (pl a Z180 emulacios "kezdemenyrol" nem is beszelve).

Ize, mas nem jut az eszembe hirtelen. Biztos hasznosabbnak iteltetne, ha mas dolgokat irnek pl, pl Nick pontosabb emulacio, hang normalisabban, meg ilyenek Csak azert a dolog alapjait akartam volna rendbe tenni eloszor.

Lehet kívánság műsor?

A sd card flash-elosdit is azert kerult bele am ... Eszembe nem jutott volna magamtol ... Ja, meg a Z180 is , igaz azota sincs kesz, bar a Z180-on nem mukodo undocumented Z80 opcode-okra kb jo, hogy azzal sem megy akkor

Amugy ezek szerint akkor mux, vagy nem probaltad? En windows alol tesztelni sem tudom. Fura ugy irni win-es dolgokrol, hogy nem is hasznalom, programozni meg plane Szerencsere ritkan kell tudni a specialitasokat mert ott van kozben az SDL meg a MingW cross compiler, de azert elfofordul ... Azon is filoztam, de ilyet nem talaltam sehol, hogy vajon letezik-e Linux ala MacOSX-re fordito cuccos (cross compiler az is marmint). Hatha valakinek kene egy olyan, elvileg SDL amugy tamogatna (ahogy Android-ot es pl Raspberry Pi-t hoppa ....).

SRAM kéne még memóriatípusnak. Ez ugyanúgy fájlnévvel lenne megadva mint a ROM, de írható, valamint kilépéskor mentené a tartalmát. (EPDOS 2.x rendszer emulálásához

Ez miert jo? Valodi EP-n az vmi akksi taplalt cucc, hogy megmarad a tartalma? Mert ha nem, akkor rendes RAM csupan, nem latok kulonbseget ... Ehhez eleg egyetlen szegmens ilyen SRAM, vagy elfordulhat, hogy tobb kell belole?

ha jól értem ezt az emut majd pl futtatni lehet pl egy pi-n?

Elvileg az nem lenne tul nehez (kopp-kopp ...), foleg mivel azon is Linux van (is), szoval kulonbseg elenyeszo, en meg amugy is Linux-on fejlesztem (csak epp x86-on persze). Persze, ki kene probalni ... Figyel itt egy nalam egy pi, csak hat ido kene erre is. Az Android nehezebb dio, sok tutorial van hogy kell, oszinten en mar kb 10%-nal fejfajast kapok igy ranezesre is :-/

andoid szerintem nem érdekes. ki akar tapiképernyőn szenvedni? plusz elég erős hw kéne szerintem hozzá...
egy önálló kis hardveren viszont érdekes lehet, mint fake-igazi gép

az android miatt gondolom hogy lassú lenne