de windóz alatt biztosan macerásabb.

Windows 7-tól kezdve tud VHD-t mountolni.

Na igen, nem atlag usernek valo. Ugye ezt le is szogeztem, hogy inkabb olyasmikre mint Z180 jatszadozas, SD kartya emulalas, majd a w5300, szoval ilyen "elvetemultebb" dolgok. Nyilvan debug-olni is joval nehezebb lenne benne, mint ep128emu-ban Azert nagy falat lenne irni egy ep128emu szintu emulatort, foleg, hogy IstvanV lathatoan igen beleasta magat a dologba, es nagyon sok mindent tud a dolgok "melysegeirol" ami a Dave/Nick pontos viselt dolgaival stb kapcsolatos. Ha csak ugy "altalanos" celra kell, en is inkabb ep128emu -t hasznalnek

Az epdos tenyleg nem jo, azt en se ertem, mit lehet vele kezdeni, Zozo egyszer magyarazta, hogy ujabb EPDOS kell, de most :HELP szerint 1.9-es, de ezzel sem jo. Azt, hogy miert nem, nem tudom, nem ertek az EPDOS-hoz En csak remelem, hogy ez nem az emulator hibaja, bar ki tudja.

Windows / VHD ugyben en nyilatkozni nem tudok Linux alatt siman lehet mountolni mar evtizedek ota kb (alap UNIX filozofia, hogy "minden file" ugye, a disk image ugyanugy, mint a /dev/fd0 ami a valodi floppymeghato lenne - bar gondolom Attusnak nem kell magyarazni, csak hatha vkinek erdekes az info), szoval ott nem gond, habar ilyen esetben en inkabb (Linux-rol van szo) az mtools-t ajanlanam.

drive m: file="/home/lgb/vega/prog/xepem/git/xep128/sdcard.img" partition=1

Szoval nekem pl ez van beallitva /etc/mtools.conf -ban. Ezek utan mdir m: az listaz, stb, a DOS-hoz hasonlo parancsok, csak "m" van az elejen.

Az viszont igaz, hogy igy is kenyelmetlen. Amit tervezek, az az ep128emu szeru FILE: implementalasa, azert az jol tud jonni sokszor.

Kozben Bruce-al email-ezgetunk a w5300/stb viselt dolgairol, btw. Kicsit "tyuk es tojas" problema: amig nincs valodi hw, nincs sw amivel tesztelni lehetne, hogy megy-e emu alatt. Viszont sw nem lesz, ha nincs hw, vagy legalabb egy emu, ami tud ilyen hw-t emulalni ...

Code: [Select]

attila:~/homok$ ntfs-3g -o window_names sdcard.img vhd

Uhh. Hat, ha NTFS-kent akarod hasznalni, biztos jo lenne, de tartok tole, hogy csak FAT12 Szoval szerintem maradjunk a sima mount-nal, ha mindenkeppen mount-olni akarod:

mount -o loop,offset=32256 sdcard.img /mnt
Ha jol tippelek, nem probaltam Az offset= onnan jon, hogy a disk image particios tablaval rendelkezik, azaz kell egy offset neki, hogy hol kezdodik ebben maga az FS. Nyilvan az sdcard.img az a disk image, az /mnt meg hogy hova mount-olja az fs-t fel. Na ez persze nem tunik tul kenyelmesnek, es tenyleg nem is az annyira, de konnyu lenne (biztos van, nem keresetem soha) irni hozza egy helper cuccot. En inkabb az mtools -t szoktam meg ilyen esetben. Veszelyes dolog a mount-olas ui, ha kozben vmi irja is (mondjuk a Xep128 nem mert read-only ...) akkor annak csunya vege lehet, ha mount-olva van kozben az FS.

Hogy erthetobb legyen az offset dolog, illetve mi volt a baj, amikor te mount -o loop-oztal siman offset nelkul:

Ha van egy disk pl /dev/sda az maga a teljes disk, ami particios tablaval kezdodik. Azt mountolni igy nyilvan nem lehet, ott is annak egyes particioit tudod mountolni, pl /dev/sda1 es nem a /dev/sda. Ugye egy disk image file-nal az van, hogy annak nincs device fs beli reprezentacioja, tehat neked kell az offset-et meghatarozni. Persze - mint irtam - biztos van erre vmi szep tool, meg akar GUI-s is, en altalaban maradok a CLI-nel es a script irasnal az az igazi

A masik ok amiert en nem mount-olnek: ha kernel szinten mount-olod, onnantol az hasznalja cache-eket stb, tehat irsz ra vmit, az lehet inkonzisztens allapotban lesz, amikor rainditod az emut, mert meg nem irta ki. Ha meg - mint irtam - az emulator is irkal az image-re, az meg kulonosen eletveszelyes, ezt gondolom nem kell elmargyazni, hogy miert

Win7-en fullscreen működik, de a win-es Task Manager 0-1%-os terhelést ír ki...  

Most megnéztem egy régi gépen (XP, Core 2 Quad), itt 1-3%

Jó a mount az offsettel.

Az offset elvileg szamithato, ha pl fdisk-el megnezed az image-et, hogy adott particio hol kezdodik, csak persze byte-ban kell megadni mount-nak. Azert vigyazz, ha irtal ra, mount-old ki emu inditasa elott, vagy legalabb sync-eld le. Amig Xep128 csak read-only-ban hasznalja legalabb nincs meg az a hibalehetoseg, hogy be van mount-olva, igy kernel hasznalja, es kozben egy user app is beleir (Xep128).

Most már tudok írkálni rá, és az emu elsőbb a  ~ alatt keresi az sdkártya imágót, majd, ha nincs akkor /usr/lib/xep128 alatt. Ergo a módosítmányomat a home könyvtáramba nyomom majd.

Hat ezen gondolkoztam egy darabig, hogy mikepp csinaljam A ROM es az SD card image keresese a kovetkezo, ha valahol megtalalja a listabol igy szep sorban vegignezve, akkor azt hasznalja, ha egyik sem nyert, akkor "error" (ami sd card eseten nem fatal error, csak nem lesz SD tartalom, ROM eseten nyilvan az):

* aktualis konyvtar (current directory)
* ha Linux, akkor itt jon a DATADIR (alaphelyzetben /usr/local/lib/xep128 hacsak nem irod at Makefile-ban)
* "app base" dir, SDL fogalom, elvileg az a konyvtar, ahol maga a futtathato allomany van (mert ugye current dir lehet mas!)
* "app pref" dir, SDL fogalom (kb ilyen user beallitasok, stb ahova irhat is az app elevileg), ahogy eszrevettem, ez:
   * Linux eseten (~ = user home):  ~/.local/share/APP_BASE/APP/
   * Windows eseten: C:\users\USERNAME\Application Data\APP_BASE\APP\

Ahol az APP_BASE Xep128 eseten a nemesys.lgb, az APP meg xep128. Azt meg ne kerdezzetek, honnan van a windows-os app pref, fogalmam sincs, SDL ezt mondja

Ez a keresesi strategia "uj", marmint amikor eloszor irtam itt a forumon a Xep128-rol, akkor csak az aktualis konyvtarban nezte, sehol mashol.

Masik: en tok jol elszorakozok ezzel a Xep128-al, de az onszorakoztato mod mellett azert erdekelne, hogy barkinek van-e velemenye, mit kene/lehetne, stb. Marmint sok mindent kene/lehetne, de pl mi a fontos. Persze a Xep128 eredeti scope-jan belul, jelenleg legalabbis nincs terve veve ep128emu-t helyettesiteni, majd X ev mulva talan, ha addig az ep128emu nem fejlodik, mert akkor van realis valoszinusege utolerni Pl Z180 dolgot is Zozo otlete alapjan kezdtem el, hogy az esetleg hasznos lehetne. Igaz, az sincs meg kesz de legalabb invalid opcode trap mar OK. A w5300 meg gondolom ertheto: azert EP a neten az fontosnak tunik, es orulnek, ha lenne valami, amivel mar az elott lehet probalkozni, hogy a valodi hw elerheto lenne, igy addig is lehetne irni sw-ket talan. Ahogy pl SymbOS topic-ban is emlitettem.

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

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

A gombokat nem lehetne ep128emu kompatibilisre tenni?