Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 197274 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14777
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #90 on: 2015.June.17. 08:51:26 »
de windóz alatt biztosan macerásabb.
Windows 7-tól kezdve tud VHD-t mountolni.

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: Xep128
« Reply #91 on: 2015.June.17. 08:59:55 »
Én most linuxom alatt próbálom, de mivel még nem csináltam ilyet, egyelőre nekem nem megy.
A VHD is új nekem. :oops:
Pedig tök egyszerű lehet...

Egy próbám:
Code: [Select]
attila:~/homok$ ls
sdcard.img  vhd
attila:~/homok$ file sdcard.img
sdcard.img: DOS/MBR boot sector
attila:~/homok$ ntfs-3g -o window_names sdcard.img vhd
NTFS signature is missing.
Failed to mount '/home/attila/homok/sdcard.img': Érvénytelen argumentum
The device '/home/attila/homok/sdcard.img' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
attila:~/homok$
« Last Edit: 2015.June.17. 09:12:54 by Attus »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #92 on: 2015.June.17. 09:12:13 »
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.

Code: [Select]
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 ...

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: Xep128
« Reply #93 on: 2015.June.17. 09:15:00 »
Az mtools -tmég soha nem használtam,mindig a sima mount -ot.

Code: [Select]
root:/home/attila/homok# mount -o loop sdcard.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
root:/home/attila/homok# dmesg | tail
[ 1666.027716] Buffer I/O error on device loop0p1, logical block 64001
[ 1666.027719] Buffer I/O error on device loop0p1, logical block 64002
[ 1666.027722] Buffer I/O error on device loop0p1, logical block 64003
[ 1666.027725] Buffer I/O error on device loop0p1, logical block 64004
[ 1666.027727] Buffer I/O error on device loop0p1, logical block 64005
[ 1666.027730] Buffer I/O error on device loop0p1, logical block 64006
[ 1666.027733] Buffer I/O error on device loop0p1, logical block 64007
[ 1666.027737] Buffer I/O error on device loop0p1, logical block 64000
[ 1666.027740] Buffer I/O error on device loop0p1, logical block 64001
[ 1766.354564] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
root:/home/attila/homok# umount /mnt
umount: /mnt: not mounted
root:/home/attila/homok#
« Last Edit: 2015.June.17. 09:20:41 by Attus »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #94 on: 2015.June.17. 09:22:00 »
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:

Code: [Select]
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 :)
« Last Edit: 2015.June.17. 09:33:25 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #95 on: 2015.June.17. 09:41:34 »
Magam is meglepődtem, hogy ez a sima SDL mi mindenre képes, az ablakméretezés is jó, hogy van már. A felbukkanó ablakok is megszaporodtak. Nem ástam bele magam túlzottan az

Az SDL nem rossz cucc. Most hirtelen nem tudom, de vmi jatek fejleszto ceg (talan a Loki?) kezdte meg el irni, amikor Linuxra akart portolni (v irni?) par jatekot. A lenyege tenyleg az lenne, hogy neked SDL ala kell megirnod, es akkor semmi (vagy keves) modositassal le lehet forditani a cuccost barmi ala, amit az SDL ismer. Mint a Windows is, de amugy elvileg talan Mac, Android es talan windows phone is, nem tudom. Sot, az emscripten project is SDL-t "emulal". Ez az emscripten a C-bol Javascript-re fordito cuccos. Igy portoltak par 3D-t hasznalo FPS jatekot is webre amugy. Ez persze normalisan ott fut csak el, ahol van tamogatas browser-ben es hardware-ben is a WebGL-re (ami talan vmi OpenGL ES-ben "vegozik" amugy). Erre mondjak, hogy allitolag egy ilyen JS succ csak kb 2-szer lassabb mintha nativ kod lenne, ez azert nem semmi :) Azt hozzatennem, hogy az JSep nem ilyen, az "kezzel" irt JS kod.

En magam is meglepodtem amugy, hogy mennyire konnyu volt Windows ala forditani Xep128-at. En oszinten sok eselyt nem is adtam (mert hogy engem nem erdekel a Windows). Kvazi egy apro probleman (_read nevet vmire hasznalja a cuccos windows-on) kivul azonnal lefordult, es mukodott is ... Mondjuk ehhez azert kellett, hogy amikor a Xep128-at elkezdtem, mar gondoltam erre, es nem hasznaltam UNIX specifikus fuggvenyeket stb, csak ami ANSI C es egyeb szabvanyokban is szerepel (masreszt a mingw fordito, amivel Linux alol forditok Windows ala emulal nehany POSIX cuccost is, valoszinu az is segit).

Amire nem jottem ra, es windows-hoz hulye vagyok: ugye kell neki az az SDL2.dll. Ez szamomra nem olyan szep, megprobaltam statikusan osszelinkelni, hogy egyetlen exe legyen. Itt jott egy kis meglepetes: a xep128.exe merete volt akkor kb 600K, az SDL2.dll meg ugy ~1Mbyte kornyeken. Ha statikusan linkeltem akkor viszont lett belole egy 7Mbyte-os exe, ami azert engem kisse zavart :) Ennyire sajna nem ertek a windpws-hoz, hogy megmondjam, ez miert van, mit kene csinalni ezzel a dll hulyseggel, hogy ne kelljen kulon ala allandoan, stb.

Egyik gyenge percemben az is eszembe jutott :) hogy ha mar van C fordito Z80/EP-re (ugye sdcc-vel nekem sikerult ezt-azt csinalni) kene SDL szeru cucc. Igy elvileg ugyanaz a C forraskod lefordulna mondjuk Windows-on es Linuxon, es mukodne, de EP ala is le lehet foridtani es ott is megy. Na ez mar nagyon futurisztikus, csak eppen elgurult a gyogyszerem, bocsi :) Persze, ez nem tul ertelmes otlet, ha valodi SDL portable kod lenne, akkor pl 32 bit egy pixel (ARGB buffer, alpha channel-el) ami azert EP-n kisse lassu lenne azt kirakni aztan EP screen formaban. Szoval ez max csak elmelet :) Bar lehetne irni olyan libet, ami specifikusan 8 bites gepekre van kihegyezve C kodilag, de fordul szokasos desktop OS-ekre is!

Windows kapcsan kozben elolvastam par API leirast az MSDN-en, hat az MS nem normalis. Ezt talan mar irtam, de olyanokat csinalnak win32 API-ban ami egy borzalom, C oran megbuktatnak oket, az is biztos :) Viszont pl file open dialog-ot ki tudok rakni. Ennek jelenleg sok ertelme nem lenne, mert nincs ami hasznalja, de kesobb majd esetleg :) Itt az SDL kevesbe segit, mert ilyeneket nem tud, az alapvetoen arra epul, hogy egy jatek (esetunkben emu ...) szamara "screen-t" emulal ami egy ablak vegulis. Olyan funkcio, hogy menuk stb nincsenek benne.
« Last Edit: 2015.June.17. 09:57:48 by lgb »

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14777
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #96 on: 2015.June.17. 09:58:31 »
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% :-)

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: Xep128
« Reply #97 on: 2015.June.17. 10:05:24 »
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:

Code: [Select]
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 :)
Jó a mount az offsettel.
:)
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.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #98 on: 2015.June.17. 10:40:46 »
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).

Quote
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.
« Last Edit: 2015.June.17. 12:16:23 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #99 on: 2015.June.17. 10:44:16 »
Most megnéztem egy régi gépen (XP, Core 2 Quad), itt 1-3% :-)

Nekem eros a gyanum amugy, hogy ezek az ertekek csalnak (nekem ez tul kevesnek tunik, de az is lehet, hogy en becsulom ala a PC-k teljesitmenyet hehe). Majd csinalok vmi kiirast, tudomisen window title par masodpercenkent frissul (?) amiben irna valami statisztikat.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #100 on: 2015.June.17. 10:47:51 »
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.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14777
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #101 on: 2015.June.17. 10:55:10 »
Nekem eros a gyanum amugy, hogy ezek az ertekek csalnak (nekem ez tul kevesnek tunik, de az is lehet, hogy en becsulom ala a PC-k teljesitmenyet hehe).
Ugyanezen a gépen az ep128emu az 28-30%

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #102 on: 2015.June.17. 11:43:22 »
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 :)
« Last Edit: 2015.June.17. 12:01:06 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #103 on: 2015.June.17. 19:54:57 »
Ujabb verzio, szokott helyen. Sok valtozas nincs, elvileg: F9 = exit, F10 = screenshot, F11 = toogle fullscreen, break/pause gomb tovabbra is reset, shift-el egyutt meg "super reset" (RAM torlese elobb). Meg a ...

Code: [Select]
:XEP emu
... tipikusan IS-BASIC-bol kiir path-eket is az emu kapcsan. Screenshot bar PNG, jelenleg mindig screenshot.png neven menti az aktualis konyvtarba, folulirva, ha volt ott vmi. Ha screenshot kapcsan van hiba (a fenti felulirasun tul persze), akkor azt - is - jelezzetek please. Mar ha vkit erdekel :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14777
  • Country: hu
    • http://enterprise.iko.hu/
Re: Xep128
« Reply #104 on: 2015.June.17. 20:22:56 »
A gombokat nem lehetne ep128emu kompatibilisre tenni? :oops: