It works for me too.
Marvellous...
If it's so portable.....can you try an Android port? Please....
I have always thought that an writing an emulator needs a lot of code. Remeber having a look into the source of the winvice c64 emulator and found it really complicated with lots and lots of files.
I think that it would be great if there was an emulator with built-in assembler and better debugger than the one found in ep128emu (or it's just hard to use)... This is one of the "fields" on which a new emulator could really stand out (for programmers).
Hmm, debugger/assembler: exactly this is the area where ep128emu is good, at least with debugger :) I wouldn't be able to compete here, also ep128emu is quite accurate.Well I've got spoiled by winape's assembler/debugger;P. I really miss the ability to easily add breakpoints through the source file, for example.
Interesting name for the emulator. :)
Some offtopic:
Хер (typed in Cyrillic) - common in Russian language obscene euphemism for the word "dick".
It similar situation for Pidora (http://pidora.ca/) for RasberryPI (look at the link at the bottom of the page)
:) I guess almost every name can mean something odd in at least one other language :)To complete your list: "bunda" in Hungarian means fur (of an animal) or fur-coat but in Portuguese... this means ass. This word appears somehow everywhere... really interesting!
0x3f9800 - 0x3f9aff (marmint ez linearis cim a 4Mbyte-os cimtartomanyban)Ez ember nyelven hol van? :-)
Ez ember nyelven hol van? :-)
Egyébként az FE szegmens attributum területére kell írásnál NMI.
Na, ezt megnézem!
UHU-3 Linux csomagot kreálok, mivel azt használok.
diff -Naur orig/Makefile mod/Makefile
--- orig/Makefile 2015-06-03 21:19:21.000000000 +0200
+++ mod/Makefile 2015-06-03 21:33:46.509474758 +0200
@@ -38,11 +38,11 @@
$(SDIMG):
@echo "**** Fetching SDcard image from $(SDURL) ..."
- wget -O $(SDIMG) $(SDURL) || { rm -f $(SDIMG) ; false; }
+# wget -O $(SDIMG) $(SDURL) || { rm -f $(SDIMG) ; false; }
$(ROM):
@echo "**** Fetching ROM image from $(ROMURL) ..."
- wget -O $(ROM) $(ROMURL) || { rm -f $(ROM) ; false; }
+# wget -O $(ROM) $(ROMURL) || { rm -f $(ROM) ; false; }
$(Z80EX):
$(MAKE) -C z80ex static
compile...
+ ub_compile
make -j2
Compiler: gcc -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I.
Linker: gcc -L/usr/lib -Wl,-rpath,/usr/lib -pthread -lSDL2 -lSDL2_net z80ex/lib/libz80ex.a z80ex/lib/libz80ex_dasm.a
make xep128
make[1]: Entering directory `/var/uhubuild/work/compile'
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. main.c -o main.o
main.c: In function 'main':
main.c:267:6: warning: unused variable 'last_optype' [-Wunused-variable]
int last_optype = 0;
^
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. cpu.c -o cpu.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. nick.c -o nick.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. dave.c -o dave.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. input.c -o input.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. exdos-wd.c -o exdos-wd.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. sdext.c -o sdext.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. rtc.c -o rtc.o
sdext.c: In function '_block_read':
sdext.c:139:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. printer.c -o printer.o
gcc -c -Wall -O3 -ffast-math -pipe -I/usr/include/SDL2 -I/usr/include -D_REENTRANT -Iz80ex/include -I. zxemu.c -o zxemu.o
make -C z80ex static
make[2]: Entering directory `/var/uhubuild/work/compile/z80ex'
gcc -fno-common -ansi -pedantic -Wall -pipe -O3 -I. -I./include -DWORDS_LITTLE_ENDIAN -DZ80EX_VERSION_STR=1.1.21 -DZ80EX_API_REVISION=1 -DZ80EX_VERSION_MAJOR=1 -DZ80EX_VERSION_MINOR=21 -DZ80EX_RELEASE_TYPE= -c -o z80ex.o z80ex.c
gcc -fno-common -ansi -pedantic -Wall -pipe -O3 -I. -I./include -DWORDS_LITTLE_ENDIAN -DZ80EX_VERSION_STR=1.1.21 -DZ80EX_API_REVISION=1 -DZ80EX_VERSION_MAJOR=1 -DZ80EX_VERSION_MINOR=21 -DZ80EX_RELEASE_TYPE= -c -o z80ex_dasm.o z80ex_dasm.c
ar rs ./lib/libz80ex.a z80ex.o
ar: ./lib/libz80ex.a: No such file or directory
make[2]: *** [static] Error 1
make[2]: Leaving directory `/var/uhubuild/work/compile/z80ex'
make[1]: *** [z80ex/lib/libz80ex.a] Error 2
make[1]: Leaving directory `/var/uhubuild/work/compile'
make: *** [all] Error 2
Error: HIBA a(z) compile fazisban.
ccache-compress...
logpack...
1 error.
Fájlrendszerek leválasztása: dev, proc, ccache, forrás OK
LogPack kimásolása /usr/src/UHUBUILD/misc-3/logpack alá... OK
****************
*** HIBA !!! ***
****************
A buildelés befejeződött.
A következő ub csomagok utolsó fordítása hiba miatt megszakadt: qt5 xep128
Hmmm. a qt5 ne zavarjon, az egy más történet, már idejétmúlt.Most látom az80ex Makefiléből , hogy akár dinamikusra is megcsinálható külön libként, csomagként.
Sőt, hogy ez létezik debian csomagként is, Arch-linuxon is és van forrása a Sourceforge -n.
UHU-3 -on nincs, de nemsokára lesz.
* esetlegesen belenyulhatok a z80ex-be ha kell mondjuk vmiert ...Az mi? Maga a Z80 emuláció?
Az mi? Maga a Z80 emuláció?
Az.Van belöle Z180 verzió is? Ha nincs, akkor csinálsz? :-)
Most már van z80ex-1.21 csomagom, esetleg ezt dinamikusan lehetne belinkelni.
Legfeljeb hülyére patkolom a Makefile -ket. :)
-lz80ex -lz80ex_dasm
A statikus lib készítés,mint beidéztem, nekem most nem működik.
Persze megértem, a windózon előnyösebb a statikus, sőt mindenütt. Jó apró a z80ex...
Van belöle Z180 verzió is? Ha nincs, akkor csinálsz? :-)
Mire lenne jo a Z180 emulacio amugy?Ha már van Z180-as EP, lehessen emulálni is :-)
Eleve sok utasitas vegrehajtasi idejet kene modositani, nehany dolgot "lebutitani" (nincs IXL/IXH stb), van amit hozzaadni (uj utasitas).Pont erről van szó :-) És a legjobb lenne ha szólna az emulátor, ha "butításba" fut bele a program, így lehetne tesztelni mi kompatibilis.
Es marad meg sajna egy rakas extra feature, on-chip DMA miegymas, na ez biztos nem trivialis annyira.Egyelőre ezek hanyagolhatóak.
Ha már van Z180-as EP, lehessen emulálni is :-)
Pont erről van szó :-) És a legjobb lenne ha szólna az emulátor, ha "butításba" fut bele a program, így lehetne tesztelni mi kompatibilis.
Egyelőre ezek hanyagolhatóak.
Az EXOS-od hogyan detektalja, hogy Z180 vagy Z80?
Kezdetnek mondjuk a gyártó oldalán megnézni? :-) (http://zilog.com/index.php?option=com_product&Itemid=26&task=docs&businessLine=1&parent_id=139&familyId=19&productId=Z80180)
Lelkes vagy, bar nem tudom, a xep128 jelenlegi allapotaban sok mindenre nem jo, nem erdemes _szerintem_ csomagolni stb. Persze, ha akarod, nyilvan megteheted :)
Na, lelkes ugyan nem vagyok, csupán UHU csomagkészítő. Itt. (https://github.com/uhulinux/ub)
És mivel ep128 érdeklődésű is, megakadt a figyelmem a műveden.
Most már az a kérés, hogy a xep128 kerül e valaha olyan álloptba, hogy másokat is érdekelhessen és közkinccsé tehető legyen?
Ez ugyi rajtad múlik...
Külső z80ex libbel megy. Kiderült, hogy kell neki sdl2-net is a fordítás során.
Többet nem nagyon tudok vele kezdeni egyelőre,még azt sem tudom,miképp lehet kilépni belőle, egyszerűen becsuktam azablakját.
Epp most fejlesztem, es itt mar belso z80ex _kell_ mert abba is beleronditok :)Az nem zavarna,ha belsővel menne, ha nem lenne ar problémája! Utána kellne szaglászni.
Az nem zavarna,ha belsővel menne, ha nem lenne ar problémája! Utána kellne szaglászni.
Legfeljebb a z80ex lib csomagom semmi másra nem lesz jó,mint, hogy a helyet foglalja a repónkban. :ds_icon_cheesygrin:
Tippem szerint pl az INC IXH helyett ilyenkor Z180 siman azt hajtja vegre, ami DD/FD prefix nelkul lenne az opcode, azaz INC H -t jelen esetben.Majd igyekszem megnézni mi történik ilyenkor.
max randa lesz, mert nem nativ UI elem az adott OS-re :)Az meg kit érdekel? :-D
Btw Zozo! Partyn mondtad, hogy az EPDOS izebize meg ozaboza (magyarul mar nem emlexem a magyarazatra :oops: ), de hogy javitott EPDOS-szal jo lesz. Mert most Xep128 alol nezve csak villan 10 masodpercenkent hogy nincs eleg memoria, de semmit nem csinal mast. EPDOS 1.7/Z (2009) Hsoft latszik a kepernyon. Szoval, akkor ebbol van vmi hibajavitott, amit inkabb berakhatnak ebben a combined.rom-os file-ba, amit az emu hasznal? Illetve, otlet, mit lehetne meg esetleg, stb?Itt mi is a kérdés? :oops:
Majd igyekszem megnézni mi történik ilyenkor.
Az SD ROM az már 0.3-as? Abban irtottam ki az undocumentedeket, hogy lehessen végre programot is betölteni a Z180-on :-)
Hat ize, nem tudom hanyas :D Le lehet azt vhogy kerdezni?:HELP hasznos tud lenni :-)
Amugy ez is vicces story. Elkezdtem osszerakni az emut, akkor "valahogy" csinaltam azt a combined.rom -ot ami cimfolyamatosan egymas moge masolt ROM-ok, amit egyben tolt be a Xep128.Ilyet egyébként lehet sajátot is csinálni?
A 7-es szegmens pedig ha minden igaz, vhol az SDext kornyeken lesz ... Szoval, akkor most mi a legujabb SD ROM, illetve amiben nincs mar undoc opcode? Akkor kicserelem :)Raktam fel egy topickal arrébb :-)
:HELP hasznos tud lenni :-)
Ilyet egyébként lehet sajátot is csinálni?
Amúgy fontos dolog: a Spectrum EMU ROM-nak xxxxxx00B,xxxxxx01B szegmenseken kell lenni, mivel a szegmensszámok fel vannak használva a "DAVE átvariálja az A14/15 értékét" dolognak a helyrehozásához.
Raktam fel egy topickal arrébb :-)
A mellékelt folttal tudtam lefordítani UHU alá. A wget, a git nem működik a chrootban,ezért a buildinfo hiányos. A chrootba lépés és fordítás előtt történik itt a letöltögetés éa az unzip is a rom könyvtárba.
A build logot is csatolom, a jövöbe tekintőn.
make combined.rom
make sdcard.img
Vagyis egy debian könyvtár benne a rules, satöbbi fájlokkal.
A wget használatát csomagkészítésnél, vagyis telepítő fájl (deb, rpm, pkg.tar.gz,) készítésnél szintén senki nem használja a fordítás során.
Jó lenne onnan száműzni végleg.
Mindig a sources részben szerepel minden kiindulási forrás, és egyéb adathalmaz szinte minden disztribúciónál, azok beszerzése a fordítási fázis előtt történik. Debiannal is így van, Arch -nál is, Fedora -nál is, és gondolom windóznál is így lehet egy setup.exe előállítása során. Még Gentoo ebuild is,mely helyben fordítja bele a gépre a futtatható cuccot egy külön munkakönyvtárba fordítgat a letöltögetések után, majd onnan telepíti a terméket.
Örülök,hogy kivetted az sdl2-net -et, azt sem értettem, hogy mi a francnak vetted bele eredetileg? Esetleg a leendő hálózati rész emulációhoz?
Baromi sokat gürizel a cuccal, azt látom. A teljes képernyő az nagyon fontos, a videó hardveres gyorsítás a mai gépeknél esetleg nem fontos.
Jobb ötletem van.
Legyen külön rész a data, meg a rom! 257 Mb!
Mi a francnak mindig letöltögetni őket és újra összerámolni minden egyes fordításnál, meg telepítésnél?
Bele kell venni csupán runtime dependenciának őkelméket.
Igen, valoban az SD image resznel meg igazad is van, mert az tobbe/kevesbe konstans, vagy user sajatot hasznal, stb. A ROM-oknal mar nehezebb a helyzet (jelenleg! hogy nem igazan configolhato stb), lasd elozo hosszu hozzaszolasomat.Nem baj, hogy én másképp gondolkozom sok téren, tényleg szinte "végfelhasználói" fejjel.
attila:~$ xep128 >/dev/null
Program path: xep128
LOAD: cannot found combined.rom in base dir, trying: /usr/lib/xep128/combined.rom
ERROR: NOTE: File open from DATADIR instead of current directory: /usr/lib/xep128/combined.rom
That is OK, and it's only a DEBUG message for now ... :)
XEP ROM cannot be found :(
ERROR: Cannot find XEP EXOS ROM signature inside ROM image "combined.rom". You can use Xep128 but internal :XEP access won't work!
IO: WRITE: unhandled port B8h write with data 00h
IO: WRITE: unhandled port B9h write with data 00h
IO: WRITE: unhandled port BAh write with data 00h
IO: WRITE: unhandled port BBh write with data 00h
IO: WRITE: unhandled port BCh write with data 00h
IO: WRITE: unhandled port BDh write with data 00h
IO: WRITE: unhandled port BEh write with data 00h
BF register is written -> W_ALL=1 W_M1=0 CLOCK=8Mhz
LOAD: cannot found sdcard.img in base dir, trying: /usr/lib/xep128/sdcard.img
ERROR: NOTE: File open from DATADIR instead of current directory: /usr/lib/xep128/sdcard.img
That is OK, and it's only a DEBUG message for now ... :)
BF register is written -> W_ALL=0 W_M1=0 CLOCK=8Mhz
Z180: would be Z180 config port, ignored <no Z180 emulation> for writing port 32h with value of 00h.
Z180: would be Z180 config port, ignored <no Z180 emulation> for writing port 3Fh with value of 40h.
BF register is written -> W_ALL=0 W_M1=0 CLOCK=8Mhz
INFO: Szivacs van!
attila:~$
LOAD: cannot found sdcard.img in base dir, trying: /usr/lib/xep128/sdcard.img
ERROR: NOTE: File open from DATADIR instead of current directory: /usr/lib/xep128/sdcard.img
That is OK, and it's only a DEBUG message for now ...
Na, a XEP ROM cannot found az pont az amirol irtam: az emulator C-ben irt resze (maga az emulator) es az a nyulfarknyi sajat ROM-om osszefugg, tehat ha nem frissited a ROM-ot, mikozben valtozik az emu, ez lesz belole. Tobbek kozott azert is csinaltam ugy hogy "egyben" csinalja a ROM osszeallitasat es az emu forditast, amit te kifogasoltal :) Ez mondjuk amugy nem fatalis hiba, ahogy az uzenet is irja (illetve elvileg ablakba is kiteszi ...) ettol az emu megy, csak par controll funkcioja nem elerheto, ami jelenleg amugy is csak kb a Z80/Z180 valtas, szoval nem nagy szam :)
Nos, ha egérrel az ep ablakra kattintok, eszméletlen írkálás jő a terminálba az egér mozgatásról.
Az esc billentyűre megnyugszik.
És a sjasm -nak köszönhetőn jó lett a szeparálr rom és img cucc, meg a különálló xep128. Szépen működik,ujjgyakorlatnak jó volt.
Ilyen a gitt,folyton változik,már felejtős is a művem.
Ez volt az ezredik hozzászólásom,felsőbb osztályba léptem.
Grat! :) Es fontos 1000. hozzaszolasodat a Xep128-ra "pazaroltad"? :)Így jött ki.
Grat! :) Es fontos 1000. hozzaszolasodat a Xep128-ra "pazaroltad"? :)Ejnye, hát itt nem az 1024-et veszik kerek számnak?
A libpng létezik windózra (http://www.libpng.org/pub/png/libpng.html)is.
vagy van mar benne RTC tamogatas amugy?Emlékeim szerint még nincs.
Na ez hatareset lesz, nekem voltak vele bajok, de ... Ha vki kiprobalna a Xep128-at windows-on most (a szokott helyen). Elvileg ez most SDL streaming texture izebize. Elonye, hogy at lehet meretezni az ablakot, sot full screen (F11-et kell nyomni) is mukodik. Legalabbis Linux-on. Windows-ra lefordult, abban nincs hiba, de kiprobalni szokas szerint nem tudom. Wine alatt mondjuk (windows "emulator") mukodni latszik, de az nem tul mervado. Az is erdekes lehet, ha jelentosen elterni latszik a sebessege (mondjuk kiirni nem irja ki, vmi system monitor / akarmi erdekes lehet, hogy valtozott-e a CPU hasznalat az elozo verziohoz kepest). Koszi elore is!
Win7-en fullscreen működik, de a win-es Task Manager 0-1%-os terhelést ír ki... Ennyire jó a gépem vagy mi a szösz? Amúgy az nem tudom miért van, hogy az egérmutató SymbOS alatt amúgy normálisan jelenik meg, de ha videót játszok le, akkor a lejátszó ablaka felett tartózkodva elkezd villogni...
Átméretezés szintén megy, az 1-2 mp-es frissülést eddig még nem tapasztaltam.
Egyre jobban tetszik.
:)
Marmint a Xep128? Amugy ismerve magam, epp viccesen belegondoltam, hogy ideje lenne egy uj emulator projectbe kezdeni, a szokott keszultsegi szinthez kepest (ameddig eljutok) a Xep128 mar igy is tulsagosan kesz van :)Az.
de windóz alatt biztosan macerásabb.Windows 7-tól kezdve tud VHD-t mountolni.
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$
drive m: file="/home/lgb/vega/prog/xepem/git/xep128/sdcard.img" partition=1
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#
Code: [Select]attila:~/homok$ ntfs-3g -o window_names sdcard.img vhd
mount -o loop,offset=32256 sdcard.img /mnt
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
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% :-)
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:Jó a mount az offsettel.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.
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).Ugyanezen a gépen az ep128emu az 28-30%
Ugyanezen a gépen az ep128emu az 28-30%
:XEP emu
A gombokat nem lehetne ep128emu kompatibilisre tenni? :oops:
A kurzort az EDITOR villogtatja szoftveresen, az gyorsul a procival.
Az epdos keretvillogtatás közben elhasal, kezelhetetlen.A NEOS egér borítja meg, mivel külső joy-jal is kezelhető.
Az OSD-s otlethez mit szolsz?Érdekes poén :-) Végül is 90-es évek elején már elérhetőek voltak SCART-os kistévék, és azokon volt ilyen.
Érdekes poén :-) Végül is 90-es évek elején már elérhetőek voltak SCART-os kistévék, és azokon volt ilyen.
:XEP CPU 7.12
What does that command? to set the Z80 clock?
Ugyanezen a gépen az ep128emu az 28-30%
Milyen video és hang beállításokkal ?Quality 3, és resample, 48000 és High Quality.
Már csak a joy-egér-EPDOS kérdést kéne megjavítani :oops:
Nekem úgy 0-7% között írja.
Olyasmit lehetne valahogy, hogy addig nem is piszkalja a az emu a megfelelo port biteket egerkent, vagy hasonlo. Hiszen hasznalni akkor ugy sem tudja a user az eger emulaciot.Igen erre gondolok én is. Ilyenkor meg a numpad 4,8,6,2,0 lehetne a Joy1.
Van amikor lemegy nulla kozelebe? Ez erdekes.Konkrétan 0-át ír, akár pár másodpercig is.
Es kozben mas anomalia nincs, tehat az emulalt EP kb normal sebessegunek latszik, tudomisen, egyenletesen villog a kurzor, stb?Teljesen normálisan fut.
Konkrétan 0-át ír, akár pár másodpercig is.
Teljesen normálisan fut.
Gondolom a SymbOS detektálja, hogy joy vagy egér van bedugva.
És igazi gépen is elmászik a nyíl ha egér nélkül van egér indítva.
Tenyleg az a mouse.xr izebize is csinal ilyen detektalasi probalkozos jatekot?Nem, ott mászik, ha Neos nélkül van Neosra kapcsolva :-)
Fuu, vegtelenul gyors az emum :DKipróbáltam egy 4.3GHz-es i5-ösön, itt folyamatosan 0%-ot ír :-)
Kipróbáltam egy 4.3GHz-es i5-ösön, itt folyamatosan 0%-ot ír :-)
GPU mi azon?Ati Radeon HD6850
Kipróbáltam egy 4.3GHz-es i5-ösön, itt folyamatosan 0%-ot ír :-)
Ati Radeon HD6850
Az SDL 1 ms felbontással tud hordozható módon időt mérni és várakozni.
Reset megjavítva :-)
Nekem úgy 0-7% között írja.
Nekem 64 bites Linuxon stabilan 6% (3.3 GHz-es Sandy Bridge CPU, dd if=/dev/urandom of=/dev/null futtatása közben, hogy valóban 3.3 GHz-es legyen, és ne lassítsa le a rendszer energiatakarékosság céljából). Úgy látszik, valóban az "emulált", kis felbontású gettimeofday() lehet a hibás értékek kiírásának az oka. A top szerint ~6.3% a CPU fogyasztás.
Quality 3
A quality 2 mennyivel gyorsabb ?Majd megnézem. Az ALT+W egyébként kb 3500% azon a gépen.
Page Up/Dwn-ra lehetne turbo kapcsolót tenni? Mondjuk a valódi gépen szokásos 4/6/7.12/10 között kapcsolgatna fel/le.
A Lua-t nem csak egyszerűbb beágyazni, de sokkal kisebb és gyorsabb
A Lua-t nem csak egyszerűbb beágyazni, de sokkal kisebb és gyorsabb (különösen a LuaJIT használatával) is, mint a Python,
Amúgy ami a Xep128 forráskódját illeti, merre van a xep_rom.hex nevű file...? Nem találom, vagy csak én vagyok vak...?
xep_rom.hex: xep_rom.rom
od -A n -t x1 -v xep_rom.rom | sed 's/ /,0x/g;s/^,/ /;s/$$/,/' > xep_rom.hex
:shock:Code: [Select][quote author=lgb date=1434909519 link=topic=1198.msg47984#msg47984]
od -A n -t x1 -v xep_rom.rom | sed 's/ /,0x/g;s/^,/ /;s/$$/,/' > xep_rom.hex
:shock:
Ezt van ember aki érti? :oops:
attila:~$ od --help
Használat: od [KAPCSOLÓ]… [FÁJL]…
vagy: od [-abcdfilosx]… [FÁJL] [[+]ELTOLÁS[.][b]]
vagy: od --traditional [KAPCSOLÓ]… [FÁJL] [[+]ELTOLÁS[.][b]
[+][CÍMKE][.][b]]
A FÁJL egy egyértelmű ábrázolásának kiírása, alapértelmezetten oktális
bájtokkal, a szabványos kimenetre. Több FÁJL argumentumot összefűz a felsorolás
sorrendjében a bemenet kialakítása érdekében.
Ha a FÁJL nincs megadva, vagy -, akkor a szabványos bemenetet olvassa.
Az első és második hívási alak egyidejű alkalmazása esetén a második alak
feltételezett, ha az utolsó operandus +-al vagy (2 operandus esetén) számmal
kezdődik. Az ELTOLÁS operandus a -j ELTOLÁS kapcsolót jelenti. A CÍMKE az első
kiírandó bájt pszeudo-címe, amely a kiíratás előrehaladásával növekszik. Az
ELTOLÁS és a CÍMKE esetén egy 0x vagy 0X előtag hexadecimális ábrázolást jelez;
az utótagok a . (oktális) és b (szorzás 512-vel) lehetnek.
:shock:
Ezt van ember aki érti? :oops:
HIába ez is a linux gyönyörűséges része, mely a widows-ból sajna hiányzik.
Mas: annyira gaz lett az OSD, hogy inkabb nincs is rola velemeny? :)Még nem fordítottam újra, nem láttam.
Nem gáz :-)
Érdekes, hogy csak rövid ideig látszik az OSD és elhaványulva foszlik szét.
Szép kék alapon nyúlt betűkkel.
#define OSD_FADE_START 300
#define OSD_FADE_STOP 0x80
#define OSD_FADE_DEC 3
*(d++) = *s & mask ? 0xFFFFFFFFU : 0xFF0000FFU;
Az én észlelési képeségem a lassú és nem az OSD jelenléti ideje rövid.
Hja,a vénség. :roll:
Az én észlelési képeségem a lassú és nem az OSD jelenléti ideje rövid.
Hja,a vénség. :roll:
Egy elsőre értelmetlenek hangzó kérés :-)
Az SD cartridge FLASH ROM működést meg tudnád csinálni? Időzítés kb nem érdekes, csak a chip típus lekérdezés, törlés, írás. Poén lenne ha a ROM fájlban is frissítené a tartalmat :-)
Nem ártana már némi felhasználói felületet csinálni a FLASH progihoz :oops: ehhez jól jönne némi emulátor támogatás :-)
Bocsi, lehet volt mar rola szo, de pontosan milyen flash van a cuccon? Vmi specifikaciot csak megneznek, hogy mikepp is megy ez :)AM29F400BT, aminek az első két 64K-s szektora érhető el a két részben (4-5-6 szegmensek, ill. a lapozható 7-es szegmens). Itt van a Flash program is.
Bar mondjuk spec eleve az SD kartyara iras is jol johetne neha azert, flash ide vagy odaIgen, nem lenne rossz :-)
AM29F400BT, aminek az első két 64K-s szektora érhető el a két részben (4-5-6 szegmensek, ill. a lapozható 7-es szegmens). Itt van a Flash program is.
Csak emlekezetbol irom (sd cart emut regen irtam mar), de nekem ugy remlik, hogy a flash elso 48K-ra fixen latszik 4-5-6 szegmensen. A flash 64K-jabol az utolso 16K elvileg el sem erheto (?), mivel a 7 szegmensen ugyan van 8K (?) "flash ablak" de az meg a flash masodik 64K-jara "lat ra". Erre jol emlekszem, tudom?
Eleve lehet ez nincs is jol emulalva, tudtommal most nem nagyon hasznalja ki semmi ezt a lapozast ugy se ...Még nem, de kéne, pl rendes ISDOS-os EXDOS berakáshoz :-)
Az szinten remlik, hogy a "lapozas" 256 byte-os lepesekben tortenikNem, 8K-s lapok vannak.
Igen.Még nem, de kéne, pl rendes ISDOS-os EXDOS berakáshoz :-)
Nem, 8K-s lapok vannak.
Megjegyzések:
- SPI órajel: 16MHz
- nagysebességű olvasási módban a 0x0FC00..0x0FFFF tartományban minden címről az adat regiszter olvasható be
- a ROM lapregiszterbe egy virtuális 16-bites ROM cím felső 8 bitjét kell beírni
- a status regiszterből a két kártyafoglalat egyesített INSRT (kártya behelyezve) és DCHNG (kártyacsere történt) jele olvasható
- INSRT=1 -> egy kártya sincs behelyezve DCHNG=1 -> valamelyik kártyát kicserélték
Pl, ha a 7-es szegmensben szerepel valahol az "SDEXT" string, az alapjan eldonteni?Én is erre gondoltam :-)
Akkor látni kéne a kérdéses C programrészt :-)
Vakegér kérdések: Biztosan bele akarsz írni a COBUF-ba és nem csak át akarod adni SHORT_HELP címét? És az a COBUF elé írás biztosan teljesen jó lesz?
A-t kéne nulláznod, BC, DE változatlan kell legyen.
Hat, ez most igy igen amator, de a FLASH.ASM-ot leforditva, majd futtatva rajta egy olyan flash.rom-ot alatolva, amiben atirtam a verzioszamot :) a reset utan (pause/break gomb a Xep128-nak) mar azt a verzioszamot mutatta, tehat valamennyire muxik, ugy tunik. Viszont a Xep128 ezt nem fogja elmenteni disk-re, tehat legkozelebb a combined.rom -ot toltve ugye ujra az eredeti van. Csak amig fut az emulator, addig latszik az "ujra-flash-eles" eredmenye.Itt van ROM csomag, amivel lehet tesztelni. (https://enterpriseforever.com/hardver/sd-kartya-interface-cartridge-ben/msg47635/#msg47635)
Azon csodalkozom, hogy megy, mert a data status polling sincs implementalva, az erase/suspend semErase külön nincs ellenőrizve, csak a végén, hogy sikerült-e az írás.
, es az ID stb lekerdezes se :-/ Legalabbis most meg nincs.Az még a Flash progiban sincs benne :oops:
web emu, valami ilyesmi kéneMiért is, amikor ez nem web emu? :oops:
Az egy másik projektje :-)
A Boulder Dash nem működik a 4 színű karakteres mód hiánya miatt. :oops:
:) Az lehet, a nick resz elegge szedett-vetett, csak "odapiszkitottam" ami ugy altalaban kell video/colour mode, hianyos ...
Az interlace-es meglatast koszi, bar ahogy en kezelem vsync-et az mar eleve durva :-D
A hiányzó módok könnyen megvalósíthatók, a többségük valamelyik már létező mód másolata pár sor módosítással. :)
Ezeken kívül video RAM időzítéssel már elég pontos lenne
illete a legnagyobb még hiányzó rész a hang emuláció, de annak a hiánya nem akadályozza a programok futását.
Valójában az ep128emu EP emulációja sem igázán pontos (a CPC és különösen a Plus/4 esetében több figyelmet fordítottam erre) :oops:, csak az EP-s programok sokkal kevésbé érzékenyek erre, mint például a Commodore gépekre írt demók.
No igen, az tenyleg hatra van, arra meg ra se neztem, de emlekszem, hogy egyszer mar regeltel rola, vmi 4.5-os dolog volt vagy hasonlo :)
Hat a hang nalam total K.O. Otletem sincs, hogy kene megoldani. Mert ugye az egy dolog, hogy az ember lejatszik egy WAV-ot. A problema itt az, hogy Z80 kod piszkalja a Dave-et, kozben maga az emulator persze nyilvan nem allandoan fut (multitasking stb, neha sleep-el), es jobb esetben :) gyorsabb a Z80 emu mint a valodi Z80 (azert - is - kell ugye sleep-elni idonkent egyet), ugyanakkor az eloallitott hangnak azert normalisnak kell lennie. A sleep viszont sose lesz teljesen pontos, az meg a masik. Hogy ezt hogy lehet osszehozni, hogy pontos hang legyen, es raadasul akadasmentesen, az most igy hirtelen nem all ossze a fejemben. Foleg, hogy igy is a Z80 orajelbol van szarmaztatva a Dave-e (/16 vagy hat /24 attol fugg mit ir az ember a BF portra), a Nick pedig egy lebegopontos cuccossal van a Z80 orajelhez "szinkronizalva", de ugye ez azt is jelenti, hogy azert 1-2 nick slot-ttal mindig pontatlan lesz, mert azt nezi, hogy utolso opcode X cycle, abba belefert-e volna mar 1 (vagy tobb ...) Nick slot, ha igen, megcsinalja. Csak a tort ertek miatt is kell a lebegopontos cucc. Ez mondjuk a main fuggvenyben latszik, meg van az a SCALER nevu cucc, az irja le a Z80 es a Nick (slot frekvencia) aranyat, amihez probal idomulni. Na, ha ebbe meg bejon az is, hogy a lejatszas frekvenciajahoz is kell valahogy a Dave altal elkovetett dolgokat illeszteni, meg puffereles is van nyilvan, meg ne is akadjon stb, haaaaaaaaaaaaaaaaaaaaaaat :)
Na igen. Tenyleg, Plus4 emulator mennyire pontos?
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 (https://enterpriseforever.com/emulatorok/idozitesi-problemak-az-emulatorokban/msg14881/#msg14881) 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.
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.
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.
NOP futattása VRAM-ban, a képen Z80 clock, és RD:[attachimg=1]
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?
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?
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 :-P 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 :)
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 ...
AEgyreszt, 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 ...).
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 :)
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 :)
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 :)
Működik :-D
akkor utana elvileg lesz, max egy kis ido mulva csak :-P 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).
Lehet kívánság műsor? :-)
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
Valodi EP-n az vmi akksi taplalt cucc, hogy megmarad a tartalma?Így van.
Ehhez eleg egyetlen szegmens ilyen SRAM, vagy elfordulhat, hogy tobb kell belole?Mészáros féle EPROM/SRAM kártyán 32K volt alapból, de többet is bele lehet tenni. Ha jól emlékszem az EPDOS 2 az 16K-t használt belőle saját magának.
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
Így van.
Mészáros féle EPROM/SRAM kártyán 32K volt alapból, de többet is bele lehet tenni. Ha jól emlékszem az EPDOS 2 az 16K-t használt belőle saját magának.
Tenyleg, ha jol elol van SRAM, nem fogja megtalalni az EXOS es kikialtani nullas lapnak? Mert akkor aztan az EPDOS hogy hasznalja fel sajat maganak? Vagy "levedi" o ezt az "EXOS elol" az indulas alatt/elott?Ilyenkor az EPDOS RAM tesztje fut, és az kihagyja magának.
Ilyenkor az EPDOS RAM tesztje fut, és az kihagyja magának.
Hamár ilyen, akkor a DTM lejátszó által kezelt 4x8 bites kártyát (EXTERNAL D/A 4*8 bit on F0-F3) kéne berakni.
Ezt támogatja az ep128emu is, az F0 és F1 port a bal csatorna, az F2 és F3 pedig a jobb.:smt038
Ezt támogatja az ep128emu is, az F0 és F1 port a bal csatorna, az F2 és F3 pedig a jobb.
Ezt támogatja az ep128emu is, az F0 és F1 port a bal csatorna, az F2 és F3 pedig a jobb.
Attol feleg, hogy majd normalisabb hang emulacioval, meg normalis Nick emulacioval mar nem menne real-time-ban :(
A NICK emuláció már most is "normális", azaz slot felbontással fut és nincs lényeges hiányzó funkció, ami a CPU fogyasztását jelentősen növelné. Teljes hang emuláció az eredményezhetne lassulást, bár ebben az esetben lehetne például fordításnál vagy futás közben konfigurálhatóan kis CPU igényű mód.
Szerintetek van ertelme ennek az egesz Xep128-nak? :)Szerintem ez az egész EP-s programozgatás nagyon jó. Amiket pl. én csinálok bomber továbbfejlesztést basic-ben, azzal ki játszik? Gondolom, nem sokan, de nekem nagyon jó kikapcsolódás ilyenekkel foglalkozni. Felfrissíti, karban tartja az agyat, mert ilyesmivel egyébként nem foglalkozom, de érzem a pozitív szellemi hatását.
Szerintem ez az egész EP-s programozgatás nagyon jó. Amiket pl. én csinálok bomber továbbfejlesztést basic-ben, azzal ki játszik? Gondolom, nem sokan, de nekem nagyon jó
kikapcsolódás ilyenekkel foglalkozni. Felfrissíti, karban tartja az agyat, mert ilyesmivel egyébként nem foglalkozom, de érzem a pozitív szellemi hatását.
Szóval érdemes foglalkozni vele.
Meg különben is, milyen menő, ha kérdezi valaki, mit csinálsz szabadidődben, és a válaszod, hogy emulátort fejlesztesz. :D
Az en "muveimmel" se fogom a feszbok lajktengeret elnyerni :-D , nem is ez a celom , sajat "szorakozas", es megmutatni, hogy az EP masra is kepes, mint speccy konverziok futtatasara,
O jajj, azert nem felreerteni engem, en sem ezt varom, nem azert hoztam fel a temat ;) Bar egy ertelme mar tuti volt, ilyesmirol kevesbe szokott eszmecsere zajlani, pedig ilyen szempontbol is erdemes neha :)Jaa, nem is azért mondtam, csak kifejtettem az én álláspontom :)
Amugy a belso konfliktusom abbol is van, hogy csak emubol is van ket projectem :)Szokj hozzá :D , nekem is van vagy 5 függő tételem :)
De jó nektek, hogy csak ilyen kevés :oops:
Én hat napja használtam :-) és a napokban kelleni fog még.
Ha már magnó legyen relé hang. Meg esetleg az a jellegzetes hang a PAUSE után :-)
Floppyhoz meg kérek fejléptetés hangot! :-)
Ha már magnó legyen relé hang. Meg esetleg az a jellegzetes hang a PAUSE utánPAUSE után milyen az a jellegzetes hang? A relé hang a távvezérlő hangja, de van más is PAUSE után?
Lehetne valami aktuális összefoglalást, hogy mit tud az Xeo128, és azt hogyan tudja?
Annyit írkáltok az angol topicba, hogy én annyi angol szöveget már nem tudok felfogni :oops:
Ha jól értem lesz valami FILE: szerű eszköz. Ez EXOS számára is fájlkezelő eszköz lesz? Az ep128emu-é nem az, így pl az INCLUDE-ok nem mennek HEASS-sal :-(
Azt nem tudom, hogy a HEASS miert nem eszi meg ep128emu eseten ... Szerintem az "is" igazi EXOS device az EXOS szempontjabol.EXOS device, de nem fájlkezelő.
lehet, hogy seek-elni akar a file-ban? Ahhoz kene igy tippre az EXOS 10, lehet nincs implementalva.Fájlméretet is ott lehet lekérdezni, szerintem azt használja.
Illetve van a :XEP CD es :XEP DIR parancsok, amivel lehet nezegetni a host OS (az az op'rendszer ami futtatja a Xep128-at, pl Windows) cuccait, mondjuk tul sok ertelme nincs, de mind1 :)A CD-vel át is megy abba a könyvtárba, és a következő töltés már onnan megy? Ezt nagyon hiányoltam az ep128emu-ból :oops:
EXOS device, de nem fájlkezelő.
Lásd 3-as EXOS változó:
3 - DEF_TYPE
Az alapértelmezés szerinti periféria típusa.
0 esetén : nem file-kezelő periféria, például magnó.
1 esetén : file-kezelő periféria, például mágneslemez.
A CD-vel át is megy abba a könyvtárba, és a következő töltés már onnan megy? Ezt nagyon hiányoltam az ep128emu-ból :oops:
a megjeleno file valaszto windows ablakban mashova bongeszel, akkor elvileg annak is meg kell hogy valtoztassa a fileio_cwd-t.Ez is hiányzott az ep128emu-ból :-)
EXOS device, de nem fájlkezelő.
Lásd 3-as EXOS változó:
3 - DEF_TYPE
Az alapértelmezés szerinti periféria típusa.
0 esetén : nem file-kezelő periféria, például magnó.
1 esetén : file-kezelő periféria, például mágneslemez.
Fájlméretet is ott lehet lekérdezni, szerintem azt használja.
Mondom 3-as EXOS változó. Amikor beállítod az eszközödet alapértelmezettnek, akkor ezt is át kell állítani megfelelően.
Akkor azzal ne foglalkozz, csak legyen megcsinálva az EXOS 10 lekezelése.
Azaz pl: open channel: meglevo file-t nyit meg file pointer zeron, ha a file nem letezik, hiba. Amde, ez csak olvasasra nyit meg, vagy lehet irni/olvasni is?Lehet írni is.
Create channel: letrehoz file-t. Mi van ha elotte letezett a file? Hiba? Vagy "csonkolja" (nulla mereture allitja)?Igen, 0-ás lesz (ha nem volt read only a fájl vagy a lemez)
Olvasni is lehet (gondolom igen) ha create channel volt, vagy csak irni?Olvasni is lehet, ha visszamész a pointerrel.
Lehet en nem tudok doksit olvasni, vagy rosszat nezek :)Ehhez a részhez az EXDOS technikai leírás kéne, ami még nem került elő :-(
Írást ki kell próbálni, de nekem úgy rémlik, íráskor megnő a fájl akkorára ami be lett állítva.Találtam ilyet a FISH-nél:
Pl egy XEP parancs amivel a default lesz a FILE: es beallitja az EXOS valtozot is?Igen ez jó lenne. Meg esetleg egy alapértelmezés a config fájlban.
Igen ez jó lenne. Meg esetleg egy alapértelmezés a config fájlban.
Lehetne pl:
:XEP FILE:
:XEP DISK:
:XEP TAPE:
Ebből logikusan jön is, hogy mit kell beállítani :-)
A problémásabb része, hogy az EXDOS meleg resetnél állítja be a DISK-et, vagyis, hogy ezt felül tud írni, az XEP ROM-nak az EXDOS alatti szegmensszámon kéne lenni.
Monjuk, ha betoltok egy programot, akkor o mar nem azt latja (default device driver-nek), amit beallitottam. Szoval EXDOS gondolom szepen reset-eli sajnos a DISK-re, hiaba allitottam at, tehat amit mondtal mar?Igen.
Igen.
Bar kerdes, hogy mikor es minek hatasara iram at, ha ugyanugy 1/8 action code-kor, akkor lehet ugyanott leszek, ahol a part szakad? :(Így van :-)
Így van :-)
Marad az, hogy át kell rendezni a memória configot (ez így van az ep128emu-ban is). 4-5-re rakhatod az XEP-t.
Kipróbáltam a xep128-at, szenzációs! lgb - gratulálok hozzá, rengeteg olyan funkció van benne ami nagyon szimpatikus :)
Vicces, hogy az egesz annak koszonheto, hogy C++-hoz nem ertekAbban mi olyan rendhagyó? A C az C nem? :oops: hA ez megy C-ben, az a két plusz jel miért zavar? :)
Abban mi olyan rendhagyó? A C az C nem? :oops: hA ez megy C-ben, az a két plusz jel miért zavar? :)
Így most hónapokig dolgozhatsz mire minden benne lesz :ds_icon_cheesygrin:
Emlékeim szerint az OOP az arra jó, hogy baromi nagy és lassú programokat lehessen írni nagyon egyszerűen :-)
Anno jártunk objektum orientált programozás Turbo Pascalban fakultációra a suliban, a végén meg volt írva nagyon szépen a program, Run, Out of memory... Mire a tanár: persze, írd át simára...
Elvileg az objektum orientált programozásnak az lenne az értelme, hogy áttekinthetőbb, karbantarthatóbb programokat lehessen írni. Inkább lassabban mint gyorsan, mintegy
Valójában az lgb által citált idézetnek semmi köze a Linux kernelhez. Hacsak azt nem tekintjük komoly kötődésnek hogy egy kernel fejlesztő mondta.
Kapsz hozza hazifeladatot is :) combined.rom-ban C000-tol hex editorral (szoval a 3. szegmens) ird at az EXOS_ROM -ot XEP__ROM -ra (igen, ket alahuzas jel)!Gyártottam combined rom gyártót, hogy egyszerűbb legyen :-) Mindenki ízlés szerint átszabhatja.
Gyártottam combined rom gyártót, hogy egyszerűbb legyen :-) Mindenki ízlés szerint átszabhatja.
http://xep128.lgb.hu/files/xep128-test.zipEz valami régi lehet, mert DDN sincs benne.
http://xep128.lgb.hu/files/xep128-test.exeEbben van DDN, de a XEP DDN DISK után is a file ablak jön, sőt még a LOAD "DISK:"-re is :oops:
Ebben van DDN, de a XEP DDN DISK után is a file ablak jön, sőt még a LOAD "DISK:"-re is :oops:
Ez valami régi lehet, mert DDN sincs benne.
ROM-knál egy kérdés: Azt érti ha egy ROM fájl nem pont 16K-val osztható? (16K-ra kerekítés FF-el)
Ami nem vilagos, az a csatorna megnyitas/letrehozasnal a filenev ...
Az ALT gomb merre van? :oops:
Mar ha az EXOS-ban van egyaltalan es nem EXDOS-ban,Nem EXOS, nem EXDOS, hanem FILE.
egy olyan EXDOS is lenne, ami SD-cart-ot tud, de a WD-t is hajlando kezelni, viszont nem var ra mindenaron :)Ilyen még nincs :oops:
Csatorna nyitas nem ment, mert ilyen nincs, megis megprobalja lezarni a csatornat, holott ennek semmi ertelme, mert megnyitni sem sikerult :)Ebben semmi furcsa nincs. Ahhoz hosszabb analízis kéne, hogy pontosan mi a hiba, meg egyáltalán volt-e hiba. Egy fix EXOS 3-tól még semmi baj nem lehet, és akkor tuti le lesz zárva :-)
Bocs, ha hulyeseget kerdezek, de milyen FILE van javitva? A FILE.ROM? Mert olyan Xep128-ban nincs, ugyse teljesen sajat FILE implementaciom van. Vagy en ertettem felre, ami nagyon is lehetseges, sot valoszinu :oops:Neked "FILE:"-d van, ez meg "FILE" :-)
Neked "FILE:"-d van, ez meg "FILE" :-)
Ha jól hallom a bal-jobb hang fel van cserélve :oops:
Azt lehetne, hogy megjegyezze a legutóbb használt FILE: könyvtárt?
Elvileg megjegyzi. Nem igy tapasztalod?Nem :-(
Ha nem, pontosan mit/hogyan csinalsz, csak hogy reprodukalni tudjam, es javitani ...Elindítom, aztán XEP DDN FILE (ennek az állapotát is megjegyezhetné, meg az AUDIO-t is :oops: )
Nem :-(
Elindítom, aztán XEP DDN FILE (ennek az állapotát is megjegyezhetné, meg az AUDIO-t is :oops: )
Valami Roaming/akarmi/lgb-ből indul, meg keresem a rendes helyet.
Ha resetelek, akkor még ott van abban a könyvtárban.
Ha becsukom az emut, következő indításkor megint a Roaming/akármiből indul.
A masik: ha az emutol azt varod, hogy jegyezze meg, es ne kelljen gepelni, miert nem irod bele pl EXDOS.INI-be a XEP parancsokat? :D Elvileg annak is mukodnie kene.Az aktuális beállítást az se fogja megjegyezni!
Az aktuális beállítást az se fogja megjegyezni!
Amúgy meg nem használok EXDOS.INI-t, hanem nyomom a gombot Zozotools-szal induláskor, hogy B mint BASIC , A mint Asmon, H mint HEASS, stb :-)
Olyan Xep128-ban nincs igazan, hogy o maga ment el barmit ... Lehet, kene majd ilyen is, de az egy mas kerdes :)Na pont erre a más kérdésre célozgatok itt :-)
Na pont erre a más kérdésre célozgatok itt :-)
Muszáj kiírni, átírni nem lehet?
Ez meg a múltkor összeállított ROM csomag frissítve.
Akkor az is lehetne, hogy egy saját konfig fájlba menti ezeket, amit felülbírálhat a felhasználói konfig, ha ott meg van adva valami.
Valahogy így van az ep128emu-nál is.
Szerintem akinek ilyen extra igényei vannak, az úgyis ért hozzá :-)
Amúgy így van az ep128emu-ban is. Megjegyzi magának, de a config fájl felülírja, ha van benne az adott beállítás.
az egyik celom pont az volt, hogy a Xep128-nal lenyegesen egyszerubb valamit irjak, amivel meg tudok vizsgalni par alap SDL kerdest, amit esetleg Xep128-ban is aztan fel tudok hasznalni ...Ha elkészült, akkor lehet belőle emscriptennel js emulátort faragni. :ds_icon_cheesygrin:
Ha elkészült, akkor lehet belőle emscriptennel js emulátort faragni. :ds_icon_cheesygrin:
Te emulálni a Windows? Próbálja ki a XEP128 Linux verzió (https://github.com/lgblgblgb/xep128#xep128).Build was unsuccessful :D
-----------------------------
Are you emulating Windows? Try the XEP128 Linux version (https://github.com/lgblgblgb/xep128#xep128).
Ok, félreértettem.No, I spoke only from Windows version earlier :) I tried to build also, but I am not a linux expert so it can be my mistake.
-------------------------------
Ok, I misunderstood you.
Sajnos nem tudom tesztelni, nálam nem indul el, feljön a konzol ablak, aztán egy pillanatra felugrik az emu ablak is, majd az XEP128 stopped working ablakocska, és a debug fájlom se tartalmaz semmit :(
KVM alatt fut nálam egy Win7, igen a winfos dob ki egy ablakot, és próbáltam a debug file-ban is nézelődni, meg a konzolon is, természetesen a debug file üres, a konzolon se láttam semmi értelmeset :)
A Linux sztem az SDL2 hiányán bukott meg, kerestem az installt de, nem találtam, így feladtam. RED HAT-en próbálkoztam, úgy hallottam, hogy nem épp ez a legjobb, de munkahelyen ezt használjuk :D
Köszi szépen a segítséget, nem is szemrehányásként említettem a windowst, tudom, hogy nem használsz :)
Mentsegemre legyen szolva, hogy meleg van :-):XEP SUN OFF :-D
:XEP SUN OFF :-D
monitorozzuk a kornyezeti homersekletet is.Az a Limonádé című programban jól jöhet. A valós hőmérséklet alapján állítaná be a limonádét vásárolni óhajtó vevők számát.
:XEP SUN OFF :-D
Keso. Mar megvette az Oracle :D
...a Xep128 fejlesztoi kozpontban...
...analog modon - monitorozzuk a kornyezeti homersekletet...
...lasd a monitornak tamasztott meroeszkozt...
Más program hirtelen nem jut eszembe, ahol hasznosítható lenne.
Jól mutat a Windows gomb a billentyűzeten... :mrgreen: :twisted:
Én inkább a mérőeszköz alatt terpeszkedő eszköz pontos típusára lennék kíváncsi... :)
Miert erdekel, hogy erdemes-e betorni erte? :)
Hoppá, az milyen monitor (a Philips)? EP-hez való?
Sajnos segíteni nem tudok ebben a kérdésben, csak annyit, hogy nálam 64bites winfoson nem műxik :)
Ja, azt jo lenne tudni, mi a baja a windoznak vele, csak hat sok otletem nincs, hogy derithetned ki :( Pedig erdekelne ...Engem is érdekelne, de nem dobott semmi infót :(
Engem is érdekelne, de nem dobott semmi infót :(
Linuxon meg nem tudom fordítani, feltettem egy valagnyi SDL meg nemtom milyen csomagot, lehet nem a jókat :D
Ez spec windows eseten azert nem gond, mert max adok melle masik dll-t. De ugye Linux-on nem szokas ganyolni hogy dll-eket pakolunk ide-oda hanem szepen kozponti shared lib-ek vannak _altalaban_ :)
Csak épp az egyszeri user korlátai kb. ott végződnek, hogy "copy dll", oszt' jónapot... :)
Memoriaval stb sem tul takarekos, ha minden nyomoronc exe sajat dll-t hasznal sajat memoriat stb foglalva (akkor is ha uaz a dll lenne mondjuk csak tobb helyen megvan), egy kozponti helyett, ami igy egyben menedzselheto/frissitheto stb.
Na, mind1, nem flame-et akarok nyitni errol, szamomra az egesz Windows felepitese total erthetetlen semmi logika/elegancia nincs benne, mindent oda tesznek ahova eppen eszukbe jut ossze-vissza stb :)
...a linux-os binaris formatumban terjesztetett xep128 nem emiatt nem mux, hanem azert, mert windows-t az MS ad ki.
Azert is kerdem, mert amugy mingw 64 bites compilerrel lefordul 64 bitre isHa lefordul, akkor rakd fel azt is, megnézem elindul-e :-)
Na, mindegy, majd próbát teszek a Xep128-al Linux-on is (DLL hell vs. compiling hell :ds_icon_cheesygrin: )
Ha lefordul, akkor rakd fel azt is, megnézem elindul-e :-)
Valamit csinált :-)
Na, megpróbáltam Xep-et fordítani Linux-on...
Kiakad a fordító a következő hibaüzenettel:
console.c:32:31: fatal error: readline/readline.h: Nincs ilyen fájl vagy könyvtár
Amugy mifele linux pontosan disztrib/verzio/"bitszam"?
32 bites az mar "retro" :) Na jo nem feltetlen (bar btw, epp tegnap olvastam, hogy gondolkodnak Ubuntu-ek a 32 bites vonal tamogatasanak megszunteteserol), csak epp az jutott eszembe, hogy csinaltam deb csomagot, csak epp az 64 bites ...
(bar btw, epp tegnap olvastam, hogy gondolkodnak Ubuntu-ek a 32 bites vonal tamogatasanak megszunteteserol),
A 16.04 LTS 2021-ig támogatva lesz, addig még ráérünk... :)
pl ha jol tudom google chrome uj mar nincs 32 bites linuxokra, csak 64-re.
Akkor ideje petíciót benyújtani a Google-nak, mert az nem járja, hogy 64-re van Chrome, Ep-re meg még nincs... :mrgreen:
Akkor ideje petíciót benyújtani a Google-nak, mert az nem járja, hogy 64-re van Chrome, Ep-re meg még nincs... :mrgreen:Persze hogy még nincs, mert az EP már 128-as! :-D
Nincs valakinek _hasznalhato_ MacOSX cross compiler kornyezete Linux-ra? :) Valami nevetseges mennyire bonyolult, tolsd le az Xcode-ot, vadaszd ki belole a header stb file-okat, fogadd el az Apple licenc szerzodest BROAF. Ehhez kepest windows cross compiler megvan egyetlen parancs kiadasa utan, pedig az elobbi legalabb UNIX amugy, mig az utobbi nem :)
Attól tartok, nem igazán hemzsegnek errefelé az OSX iránt érdeklődő Linux-osok... :twisted:
Emlékeim szerint többen is hiányoltak almás EP emulátort. Valaki próbálkozott ep128emu fordítással, nem tudom mi lett belőle.
Hát, legfeljebb ez van, bár lehet hogy ismered is...:
https://github.com/tpoechtrager/osxcross (https://github.com/tpoechtrager/osxcross)
Amúgy az xcode vacakolástól úgy látom ez se ment meg... :smt017
Emlékeim szerint többen is hiányoltak almás EP emulátort. Valaki próbálkozott ep128emu fordítással, nem tudom mi lett belőle.
Egy 98%-ig kész iOS -es Ep emulátor lett belőle! (2 évvel ez előtt...) Aztán sajnos abbamaradt és az iOS frissítése miatt ma már aligha futna... :-( (Anno nálam volt tesztelésre hónapokig, NAGYON tetszett! Amúgy Varrogy fórumtársunk készítette.)
Az se rossz - marmint hogy iPhone stb -, de en sima osx cuccosra gondoltam csak :) Vagy ma mar azt is iOS-nek hivjak? Lehet, mert a Mac OSX-ben nem volt "i" betu, az meg ugye nem meno :) Vagy nem tudom hol tart az Apple, oszinten szolva ...Nem-nem... :-) iOS az továbbra is csak iPod, iPhone és iPad! Utóbbin nagyon komolyan lehetett használni az emut! :-) (Zozo is látta anno...)
... akkor mar lesz linux, win32, win64 es macosx build is.
Na, a Linux-ot átraktam 64bit-re, most már jöhetnek a .deb-ek... :)
Latom, a nemzetkozi helyzet fokozodik :-P :-P
sudo bash
apt-get update
dpkg -i xep128_0.3+20160720192823.deb
apt-get -f install
/usr/local/bin/xep128-download-data
exit
Nos, "csakazértis" grafikus tool-lal raktam fel :mrgreen:
:D :D Hat amugy lehet akkor is felajanlana a dependency korrigalast magatol, nem tudom, eletemben nem probaltam meg ezt a lehetoseget GUI-val pedig mar 20 eve Linuxon tolom :-P
De ezek szerint akkor legalabb mukodni latszik, ez is valami :)
Hey! Ez nem windows, root-kent nem futtatunk semmit ... foleg nem grafikus stb cuccot, az ilyen windows adminisztratorkent hasznalja a gepet cuccos az szerintem egy security remalom lehet :)
Hehe, sejtettem, hogy botrány lesz... :mrgreen:
Mentségemre szolgáljon, hogy hirtelen felindulásból követtem el a dolgot (Windows-os befolyásoltság alatt álltam, tisztelt bíróság...), a jövőben tartózkodok az efféléktől... :)
brew update
brew install sdl2
Nekem csak iOS van, szóval nem tudok hozzászólni... :-D (Amúgy poén lenne, ha valaki kitalálná az iPhone -on futó Ep128emu -t /Xep128 -at. :-) )
Nem ijesztettél el :) Hasonló parancsokat, mint a linuxnál én is tudok futtatni pl. sudo stb.
De hozzáteszem, nem vagyok nagy guru a programozásban ezét lehet, hogy több segítségre lenne szükségem :D
Utánanéztem de a google képtelen hasznos infókat adni az .osx kiterjesztésről...Idézőjelbe kell rakni, hogy ne arra keressen, amire szerinte keresel, hanem arra amit keresel... (az utóbbi években egyre jobban elb...ák a googlét (is)).
Idézőjelbe kell rakni, hogy ne arra keressen, amire szerinte keresel, hanem arra amit keresel... (az utóbbi években egyre jobban elb...ák a googlét (is)).Azt hittem, hogy a MacOS intelligensebb a Microsoft termékeknél, és a típus információkat metaadatokban tárolja. Ez az el*ott fájlnév kiterjesztés elég gagyi.
Ha jól értem, ez olyasmi mint a .BAT a DOS-nál, valami parancssoros izében kell futtatni.
Oké, itt most a legnagyobb gond, hogy az .osx kiterjesztést nem ismeri a rendszer, .dmg az installálható kiterjesztés.
Utánanéztem de a google képtelen hasznos infókat adni az .osx kiterjesztésről...
chmod +x xep128.osx
./xep128.osx
Azt hittem, hogy a MacOS intelligensebb a Microsoft termékeknél, és a típus információkat metaadatokban tárolja. Ez az el*ott fájlnév kiterjesztés elég gagyi.
amugy akkor is szokas (gondolom emberi szemne is segito) modszer, hogy "ismerteto kiterjeszteseket" biggyesztunk a file nevekbe, meg ha az adott OS szigoruan nem is varja el ezt amugy.Lásd Enterprise :ds_icon_cheesygrin:
Nem tudom segit-e, de irtam ilyet:
https://github.com/lgblgblgb/xep128/wiki/Installing
Az OSX-es xep128.osx-et sehogy nem tudom futtatni. Viszont amit most írtál az nagy segítség, mert egyszer a Homebrew kellett valamelyik fura progi telepítéséhez, de látom, hogy az SDL2 is kell hozzá :) Ha lesz kis időm kipróbálom :)
chmod +x xep128.osx
./xep128.osx
Code: [Select]chmod +x xep128.osx
./xep128.osx
Ezt az OSX parancssorból nem tudta értelmezni, azt írta, hogy nincs ilyen parancs...
ls -la
-rwxr-xr-x 1 travis staff 531216 Jul 25 09:51 xep128.osx
Mac-es exkollegat megkertem, hogy probalja ki, azt mondta neki megy (bar o azert eleg melyen ert is hozza, nem ugy mint en, hehehe) :-)Akkor már csak írja le, hogy hogyan csinálta :-)
Anno még kb. 5 éve telepítettem Debian Linuxot (amikor még nem volt kiforrott grafikus felülete), alá web szervert stb. Tehát valamennyire még emlékszem a parancsokra. Ahogy írtad is, MAC OSX Unix alapú, tehát van a kettő között hasonlóság.
Nem tudom mit cseszhettem el, ha hazaérek megnézem újra :)
Oké, rossz helyre másoltam a xep128.osx fájlt, de most ezeket a hibaüzeneteket kapom:
(A combined.rom is ugyanott van)
(http://www.enterpress.news.hu/osx.jpg)
otool -L ./xep128.osx
http://xep128.lgb.hu/files/xep128_osx.zip
Ujabb probalkozas :) Ezuttal zip, es benne van minden - elvileg - amit nyilvan egy helyre kell kibontani. Benne most xep128 es nem xep128.osx a filenev, de ez filenev kerdese, amugy ez total mindegy. Annyi valtozas van, hogy vmi otool varazslattal a futtathato allomanyban az SDL dylib dependency eleresi utja at van irva az Apple fele "trukkos" @executable_path/... ertekre, igy ott fogja keresni, ahol a xep128 file maga van. Remelhetoleg ... Ezert is van a libSDL2-2.0.4.dylib file is a "csomagban". Igy viszont elvileg legalabb SDL-t sem kell kulon installalni, csak melle tenni, tehat kb mint a dll windows eseten a "mellekeve" szitu eseten marmint.
Nagyon köszi! :) Este próba (csak tudod, itt bent a munkahelyen PC-n dolgozom és otthon van a Mac :) ).
Csak összehozzuk valahogy (vagyis Te :D )
hm, most nézem a forrást, hogy az Am9511 emu is benne van :-)
egyszer már jó lenne egy működő példányt találni a kártyából!
és végre igazi hw-n is lefuttatni a teszteket!
JSep-ben is volt :) Oda irtam meg eloszor
Amugy - bar offtopic es volt is szo mar rola - jo lenne valami konyebben elerheto, esetleg "nagyobb teljesitmenyu" FPU szeru cucc.Az a baj, hogy már a umega FPU (http://micromegacorp.com/umfpu-v3.html) se kapható. Egyébként nekem az nem is szimpatikus, eleve megy valami 30MHz-cel, meg igazából ez csak egy MCU, amire írtak valami fw-t, szóval nem igazán hardveres FPU.
Ja, ja, arra emléxem.
Az a baj, hogy már a umega FPU (http://micromegacorp.com/umfpu-v3.html) se kapható. Egyébként nekem az nem is szimpatikus, eleve megy valami 30MHz-cel, meg igazából ez csak egy MCU, amire írtak valami fw-t, szóval nem igazán hardveres FPU.
Előtte azért még dob brutál hibaüzeneteket, majd megjelenik egy kis ablak valami üzenettel és egy egy OK gombbal, ezt megnyomva full screenben indul. Azt még ki kell deríteni, hogyan lehet kisebbre venni az ablakot, de engem nem zavar így sem.
Majd csütörtök este küldök print screent az indulás előtti dolgokról :)
De a lényeg, hogy megy Mac-en is :D
Persze, ha van már belőle valódi release, nem csak pre-release.
Ha nekiállok, biztos, hogy zargatni foglak egy, s más kérdéssel, javaslattal.
Nekem nem sürgős, amúgyis nagyon leköt most a leendő RIA.
Várok vele, de magamnak újra megnézem!
:)
Most mi a legfrissebb Windowsos verzió?
Nálam 06.29-es 64 bites van, és 04.14-es 32 bites.
Működnek. Akkor maradok a 64 bitesnél, ha jól értem a jövőben ez is automatikusan készül?
Van egy bug: működik az SD emuláció :ds_icon_cheesygrin:
Az a hiba, hogy SD kártya azonosító információkban nem az image mérete adódik át, hanem valami 14 megás méret.
És itt jön a másik hiba, hogy nem lesz sector not found, ha a kártya méretén túlról van olvasva.
És egy apróság: az ikon csak az ablak sarkában jelenik meg, az EXE fájlon nem.
:smt041 :smt041 :smt041
Nem tudom mi történt, de már nálam is működik a Winfos verzió :ds_icon_cheesygrin:
Erre gondolsz? Ezzel tisztaban vagyok, es utdom, hogy javitani kellene. Amugy miert fontos ez? Amikor csinaltam az SD supportot, beleraktam a card ID-et fixen, csak ugy random. Mivel ugy lattam, hogy a cuccnak (SDEXT ROM) ez nem gond, ezert igy maradt ... Gondolom azert nem gond neki, mert amugy sem nezi, hanem a particios tablabol kiszedett adatok alapjan olvas, es nem ellenorzni, hogy amugy a kartyara nezve valid-e egyaltalan az ertek (pl olyan particio leirasa van benne ami ra sem ferne a kartyara ...) Neked hol jott elo, hogy ez problema? Azert erdekel, mert en nem lattam olyan esetet, ahol ez gond lenne, bar beismerem, hogy ez igy tenyleg gaz azert :oops:FDISK...
FDISK...
Amúgy meg pont arra készülök, hogy a SDEXT-ben legyenek mindenféle ellenőrzések :oops:
mennyit írtok ide... kár hogy engem meg pont nem érint a téma :(
mert milyen jogon piszkalok beleSzerintem dobjon fel egy kérdést, hogy akarod-e.
Szerintem dobjon fel egy kérdést, hogy akarod-e.
Amúgy a "sok programos" VHD az direkt valódi kártyán készült (amiből van egy nagy marékkal SzörG-nek, és ezt osztogatja az illesztőkkel), és onnan lett lementve. (256-os kártya ami valójában 244MB)
Majdnem jó :-) Fele akkora méretet mond.
És amit nem értek, hogy a valódi kártyáról csinált image miért nem jó neki... Talán lehet, hogy a kisebb/régebbi kártyáknál másként ment a számolás? Ott a CSD-nél emlegetnek különféle verziókat is.
De nem tette tönkre az image-t, csak egy rakás nullát írt a végére.
En azt gondolom, hogy 2Gbyte legyen mar eleg az EP-nek azert, nem tudom te hogy vagy vele, Zozo :)Átmenetileg elfogadható kompromisszum :-)
Egyaltalan az SD kartya cartridge + SDEXT tud/tudna SDHC-s kartyat kezelni?Tud, így 32GB-ig tuti. Maga az EXDOS bővítő rész az 128GB-ig jó (32 bit LBA), amit még meg kéne nézni, hogy SDXC-re is működik-e a Detect eljárás CSD-ből számolója :-)
Ja meg a masik, ami magyarazatot adhat valodi kartyameret problemara: tenyleg lehet, hogy mas CSD verzioval volt az eredetiHa jól látom az eredeti valami ősi 16 megás kártya CSD-je.
Ha jól látom az eredeti valami ősi 16 megás kártya CSD-je.
Itt az adott kártya ID fájlja.
00000000010111100000000000110010010111110101100110000011110011111110110110110110111111111000011110010110010000000000000000111111
CSD_STRUCTURE CSD[127:126] = ('00', 0, '0x0')
READ_BL_LEN CSD[83:80] = ('1001', 9, '0x9')
C_SIZE CSD[73:62] = ('111100111111', 3903, '0xf3f')
C_SIZE_MULT CSD[49:47] = ('101', 5, '0x5')
{'C_SIZE_MULT': 5, 'CSD_STRUCTURE': 0, 'READ_BL_LEN': 9, 'C_SIZE': 3903}
Mult = 128
BlockNR = 499712
BlockLen = 512
Card size = 255852544
-----------------
MAY HIT with blen=512,mult=128,result=3903
MAY HIT with blen=512,mult=256,result=1951
MAY HIT with blen=512,mult=512,result=975
MAY HIT with blen=1024,mult=64,result=3903
MAY HIT with blen=1024,mult=128,result=1951
MAY HIT with blen=1024,mult=256,result=975
MAY HIT with blen=1024,mult=512,result=487
MAY HIT with blen=2048,mult=32,result=3903
MAY HIT with blen=2048,mult=64,result=1951
MAY HIT with blen=2048,mult=128,result=975
MAY HIT with blen=2048,mult=256,result=487
MAY HIT with blen=2048,mult=512,result=243
Igen ez stimmel.
A probléma lehet, hogy ott van, hogy a VHD nem RAW image, hanem a végére oda van írva még valami (ha jól nézem 512 bájt). És úgy tűnik ebben mindig megtalálható a "conectix" string.
Hat ha, pont 255852544 + 512 ami neked lett, akkor valoszinu :)Pont :-)
lehetne bele detektalas, ha fel lehet ismerni, hogy mi az a vegen, es egyertelmuen tutira azonosithato, nehogy baj legyen belole. Es akkor max ugy tekintem, hogy a valodi meret 512 byte-al kisebb.Erre gondoltam én is.
Persze, ha ugy sem jon ki, erdekes, mert azt felboviteni nehez, hacsak nem szurom el (mivel ha utana irok akarmi, az mar vhd-ban nem valid akkor, mert hianyzik ez a "vege"?).Esetleg figyelmeztetés, hogy RAW image-be lesz konvertálva, és akkor azzal a plusz vacakkal nem kell foglalkozni.
a dll-nek elvileg jonak kell lennie belole legalabb a teszt verziohoz isÍgy már jó.
Itt a demonstracio:
http://xep128.lgb.hu/web-demo/
Ez tehat *nem* az JSep, hanem a Xep128, ami C-ben van irva, csak Emscripten-el le van forditva javascript-re. Persze, igy sokra nem jo (es amugy az idozitese is csapnivalo, mert azt viszont maskepp kell emscripten alatt csinalni elvi okok miatt), meg igy SD sincs alatta ...
nem követem ezeket a topikokat, ez most új webes emu?
én arról álmodok hogy könnyen és egyszerűen futtatható legyen minden ep játék weben :)
Almodni en is szoktam :) :) De amugy igen, vegulis az ertelme az lehetne. Ettol valoszinuleg meg nem helyettesit semmilyen "nativ" emulatort, mert vannak ugye a technika elvei miatti hatranyai is (es a performancia sem feltetlen olyan jo, bar ma mar legalabb hasznalhato erre is azert a html/js vilag ... legalabb ezt elmondhatjuk). Szoval mondjuk olyan ertelmet el tudom kepzelni, hogy jo lehet "preview-nek" vagy aki nem tud/nem akar emulatorozni mert annyira nem 'fanatikus' stb. Na mind1, erted, szoval talan vmi ertelme lenne azert ...
az a helyzet hogy már én is évek óta ott tartok hogy van a jól bejáratott ep128emu, és nincs másra energiám hogy kipróbáljam. pontosabban ha ep-zni akarok akkor nem arra akarom az időmet szánni hogy új emut meg ilyesmiket próbálgassak. hanem konkrétan az emut használom amit ismerek.
az átlag usernek ma már erre sincs ideje... se energiája... ők azok akiknek jól jönne ha egy kattintással weben nosztalgiázhatnának egy kicsit...
Most meg foleg, hogy ep128emu-ban is van SD meg eger :) :)
na én erről is le vagyok maradva...
Elvileg meg akar ep128emu snapshot-ot is be tud tolteni webes verzioban is - mar amennyire amugy a Xep128 ilyet tud, eleg gyengusan csinalja azert meg :-P
Kettőspontot ebben se lehet beírni :oops: (Gondolom a magyar billentyűzeten bukik a dolog...)
Kettőspontot ebben se lehet beírni :oops: (Gondolom a magyar billentyűzeten bukik a dolog...)Tuti, TVC emulátornál már találkoztam ezzel a problémával, átváltottam angolra :D
off-topic/szemelyes: Na, ezert nem kell bena magyar kiosztast hasznalni, ahol minden fontos karaktert eldugtak amugy is :DAzért izéke... :-D Magyar emberként Magyar szövegeket bepötyögve nap mint nap had ne használjon az ember már angolt / egyebet... :-) Szóval amelyik program nincs jóban a HUN kiosztással PC -n, azt én ívben kerülöm... :-D
Azért izéke... :-D Magyar emberként Magyar szövegeket bepötyögve nap mint nap had ne használjon az ember már angolt / egyebet... :-) Szóval amelyik program nincs jóban a HUN kiosztással PC -n, azt én ívben kerülöm... :-D
Ha német EP-n nöttél volna fel, akkor nem zavarna a magyar kiosztás sem :-)
Amúgy én, ahogy megtaláltam az első ékezetes karaktereket, már igyekeztem használni őket. Késöbb PC-n ALT+számos módszerrel, amíg el nem terjedt a magyar kiosztás.
de pont ez az amiert sokan meg utaljak a Chrome-ot, mert emiatt szeret tobb RAM-ot is enni ugyebar
Ez egyébként szerintem azért hülyeség (mármint, hogy emiatt egyesek utáják a Chrome-ot), merthogy ugyebár a RAM az egy erőforrás. Ha ugyanis ott a 4-8 GB RAM a gépben, akkor miért ne töltse ki az adott sw, ha van rá lehetősége?
Ez olyan, mint egy extrásított EP progi. Ha kell, elfut 128k-s alapgépen is, de ha van bőven RAM, akkor kihasznnálja, és betöltődik az extra digi zene, meg az extra szuper grafika is :-) Vagy éppenséggel 32kB-nál nagyobb forrásfájlt is be lehet tölteni (pl. a HEASS-ban).
Az, hogy valami sok RAM-ot használ, nem feltétlenül jelenti azt, hogy rosszul van megírva, vagy rosszul gazdálkodik a RAM-mal, és teleszemeteli... Hanem éppenséggel jelentheti azt is, hogy ha már ott van a gépben, akkor miért ne használja fel arra, hogy szebb / jobb / biztonságosabb legyen?
hogy neha 60 bongeszo tab-om is vanNa én ezt nem értettem meg soha, hogy ez mire jó :-)
Na én ezt nem értettem meg soha, hogy ez mire jó :-)
A Xep128 es a ROM-ja (ami magabol a Xep128-bol jon) annyira szorosan integralva van, hogy az sjasm-al forditott XEP ROM symbol tablajabol kapott cimkek hasznalva vannak a C forraskodban konkretan, tehat lathato, hogy a ketto nem igazan szetvalaszthato ...
Erre ugyan van egyszerű megoldás: az emulátor funkciók hívására használt (eredetileg érvénytelen) utasítás kódjába beépíthető a funkció száma, a paraméterek pedig a Z80 regiszterekben adhatók át. Én 0xED 0xFE 0xFE N-t használok az epfileio.rom-ban, ami a kód speciális értelmezése nélkül NOP, NOP, CP N lenne. A 0xED 0xFE 0xFE 0x05 például az EXOS 5 hívásnak felel meg, és a használata is azonos (bemenet: A = csatornaszám, kimenet: B = olvasott karakter, A = állapot). Ha a ROM fel van készítve arra, hogy ezek az utasítások hatástalanok is lehetnek, akkor a másik emulátorban való betöltés nem okoz különösebb problémát, bár a speciális funkciók természetesen nem működnek.
Az volt az alapelkepzelesem, hogy en nem akarom nyilvantartani, hogy milyen funkciora milyen "ED trap"-et hasznalok, hanem szimbolum nevekkel operalok, es igy az "trap" _cime_ szamit ... Ez amugy tenyleg kenyelmes, es jobban latszik (legalabbis szamomra ...) az egeszben, hogy mi mihez tartozik (es kulon "konyvelni" sem kell)
xepsym_fileio_open_channel equ 1
xepsym_fileio_create_channel equ 2
xepsym_fileio_close_channel equ 3
xepsym_fileio_destroy_channel equ 4
xepsym_fileio_read_character equ 5
;...
MACRO TRAP sym
DB 0xBF, 0xED, xepsym_ed_trap_opcode, 0x20, sym
JP NC, error_noemu
sym = $
ENDMACRO
Az xep_rom_syms.h pedig ugyanúgy generálható, ha fontos, hogy a fenti táblázat csak egy helyen legyen tárolva. Ez a makró egyben azt is ellenőrzi, hogy a funkció valóban támogatott-e, ha igen, akkor az emulátornak be kell állítania a C jelzőbitet, egyébként (mivel a CP A (0xBF) utasítás mindig C=0,Z=1-et állít be) a ROM hibát jelez.
A címek helyett funkciókódok használata nem jelentene különösebb nehezítést, és elkerüli a ROM címek emulátorba építésével járó problémákat:Code: [Select]xepsym_fileio_open_channel equ 1
Az xep_rom_syms.h pedig ugyanúgy generálható, ha fontos, hogy a fenti táblázat csak egy helyen legyen tárolva. Ez a makró egyben azt is ellenőrzi, hogy a funkció valóban támogatott-e, ha igen, akkor az emulátornak be kell állítania a C jelzőbitet, egyébként (mivel a CP A (0xBF) utasítás mindig C=0,Z=1-et állít be) a ROM hibát jelez.
xepsym_fileio_create_channel equ 2
xepsym_fileio_close_channel equ 3
xepsym_fileio_destroy_channel equ 4
xepsym_fileio_read_character equ 5
;...
MACRO TRAP sym
DB 0xBF, 0xED, xepsym_ed_trap_opcode, 0x20, sym
JP NC, error_noemu
sym = $
ENDMACRO
Ehm :) Na szoval, a "bare metal" programming igen, elvileg azt jelenti, hogy nincs OS egyaltalan, tehat kozvetlenul a hw (a "vas", "metal") folott vagy. Ez azert nem olyan trivialis dolog, mert akkor tenyleg mindent neked kell csinalni, amit ugye altalaban az OS megold (file access-tol kezdve minden, ami OS alatt nyilvan ugy szokas h meghivunk csak egy file open/read stb funkciot, amit az OS rendelkezesre bocsajt). Elvileg persze lehetne ilyet barmilyen sw-vel csinalni, Xep128-al, massal is, de azert ehhez jocskan meg kell dolgozni a dolog jellege miatt. Legyen a "vas" rapsberry pi, vagy akar PC is stb (regen PC-re is voltak jatekok amit bootolni kellett, azaz nem kellett ala OS voltakeppen, bar igaz, hogy pl DOS-ra keszult cuccok egy resze amugy is felig kozvetlenul hw-t hasznal mert DOS nem igazan egy "igazi" operacios rendszer amugy sem). Ilyesmit a Xep128 jelenleg nyilvan nem tud.Tehát akkor félreértette :)
Tehát akkor félreértette :)
És ugye a XEP128 fejlesztését nem fejezted abba? :)
Köszi szépen a kimerítő választ, tolmácsolom :)
Gondolom pont a könnyebb portolhatósága miatt érdeklődött az érdeklődő :)
hm ez érdekes hogy kompozit kimenet. nem pont ez ami plusz áramköröket igényel??
Lehet, velem van a baj, de nem ertem, miert hardware-es emu a Z80MU. Ha jol ertem, azon is software fut, tehat software-es. Vagy csak azert "hardwares" mert nem egy atlag PC-n fut, hanem valami "neki csinalton"? Attol meg szerintem a szitu uaz kb az emulator szempontjabol. Vagy van mas kulonbseg is?+1
Öööö, igen, akkor én írtam rosszul :) Szoftveres, csak egy kis kütyü az egész.
Kommentar nelkul cimu sorozatunkbol ... (Attachment Link)Wow! :smt038
Kommentar nelkul cimu sorozatunkbol ... (Attachment Link)Az igen!!! :) :smt038
ROM-ok nincsenek fent valahol egy kupacban az emuhoz?
en az osszes emu varians romjaira gondoltam, hogy ki lehessen probalni oket, vagy le kell oket vadaszni egyesevel valahonnan?
ep128emu-nak is van valahol rom pack-jaTelepítés után van egy külön könyvtár az EP128emu könyvtárán belül romokkal. Még onnan lehet esetleg próbálkozni.
na, az ep-vel nincs is baj, a tobbi gep romjara gondoltam:-D Ezek szerint vadaszosak?
Bocsi a hosszu leirasert :) Valoszinu EP eseten ebbe senki nem kotne bele. En ugyan nem tudom, hogy pontosan kie a jog az EP ROM-okra manapsag (ha van egyaltalan ilyen ...)Kopácsy őrzi páncélszekrényben, és addig nem lesznek szabad felhasználásúak, amíg az összes SZJA88 program el nem fogy a raktárakból... :-D
Kopácsy őrzi páncélszekrényben, és addig nem lesznek szabad felhasználásúak, amíg az összes SZJA88 program el nem fogy a raktárakból... :-D
Jut eszembe errol, ezt is visszaallitottam: http://ep.lgb.hu/club-logo/Belerakhatnád még az 5.25" floppy meghajtókkal teli Borg űrhajót is :lol:
ezt is visszaallitottam: http://ep.lgb.hu/club-logo/Ez már nagyon hiányzott, most újra végigolvastam. Lehet, lementem, hogy nehogy megint elvesszen.
Jut eszembe errol, ezt is visszaallitottam: http://ep.lgb.hu/club-logo/:lol: :lol: :lol: I havn't seen that before :lol: :lol: :lol:
... akkor w5300 emulacio folytatasa, hogy legyen net, na meg hogy aztan, SymbOS tudjon EP-n futni w5300-al nezegetessel egyutt (btw, w5300 -> EPNET voltakepp ugyebar), de akkor mar akar valodi gepen is, nem csak emun, persze.
:lol: :lol: :lol: I havn't seen that before :lol: :lol: :lol:
ki tudtuk adni a 2020-as számokat2020-ban hány szám volt? Tudom, a vírus miatt extrém helyzet volt. Valamikor nyár elején jelent meg egy online szám, más nem volt? Csak azért kérdezem, nehogy lemaradjak valamiről.
Hell! :)
Igaz, hogy ígértem Neked egy EPNET kártyát fejlesztésre, de sajnos sok minden közbejött, vírus, nem vírus (?) és lehetetlen helyzetek ...
Tehát nem tudom (tudod, hogy én nem értek ezekhez...) esetleg ha emu-n (akár ep128emu vagy a Te XEP128 EMU-d alatt) meg lehet oldani EPNET futtatást, akár egy fasza SymbOS drivert is... És lehet, hogy az eredeti gépen is működne! Hát az nagyon jó lenne. Ettől függetlenül áll az ajánlatom, hogy készítek Neked egy EPNET kártyát!
És elmondom, igen, mert én mindig ugatok (annak ellenére, hogy sokan a HOBBI szót használják erre ...), hogy hiába várunk Prodatronra, semmi sem történik!!!! Évek telnek már el, de akkor könyörgöm, ne ígérjünk semmit és NE készítsünk olyan hardvereket, melyek felcsillantják az EP felhasználó szemét! Ne készítsünk "látvány" SymbOS-t és hasonlókat, mert minek is??? Bocsánat, ezek most nagyon éles kritikák! Ez van! Én is megtehetném, hogy lazítanék az Enterpress magazin kiadásával, de nem tehetem! Szerencsére a nagyon fos helyzet ellenére is ki tudtuk adni a 2020-as számokat, mert engem érdekel és sok lelkes szerzőtársamat is!
Peace! :)
DEF OFF2020-ban hány szám volt? Tudom, a vírus miatt extrém helyzet volt. Valamikor nyár elején jelent meg egy online szám, más nem volt? Csak azért kérdezem, nehogy lemaradjak valamiről.OFF
END OFF
CALL OFF
Nezd, en nem akarok kotekedni, de azert - mondjuk ahogy irod is - szerintem a velemenyed kicsit eros, foleg mivel hobbirol van szo. Prodatron nem keves energiat olt a SymbOS-be, tobben a "legnagyobb 8 bites sw fejlesztesnek" tekintik napjainkban (spec a forraskod full z80 asm, es nem epp kicsi .... van alapja). Egyatalan Ep-re nem is portolta volna, akkor most senkinek nem fajna hogy nem tamogatja az EPNET-et. Szoval en ugy erzem ez egy ketelu fegyver: nem latott volna sose EP-t, nem portolta volna ra, most senki nem hianyolna az EPNET support-ot belole, nyilvan. De nem keves idot szant arra, hogy EP-re portolja, de az eredmeny az, hogy koszonet helyett nemi ellensegeskedest kap cserebe, hogy EPNET support miert nincs benne :) Legyszi felre ne ertsd, nem ellened akarom beallitani a szitut, vagy szemelyeskedni! De azert igy belegondolva, kicsit talan eros. Szerintem a kulcs az, hogy nem vagyunk egyformak, mindenkinek minden mast jelent, es nem tudhatjuk azt sem hogy Prodatron amugy miert elfoglalt, miert tunik el, csak "nem erdekli" vagy mas oka van. Es ugyanakkor ossze kenbe hasonlitani azzal is, hogy mit tett le eddig az asztalra (es nem csak EP-re ugyebar ...).
Jogos, ebben igazad van! Egy kivétellel! A SymbOS-nak nem csak az EPNET driver a hiányossága, tulajdonképpen ez csak egy extra lenne... Jóval több alapvető hiányossága van, ezeket nem sorolom, lásd. SymbOS topic. Azt hiszem kb. 4-5 éve kértük, hogy kezelje az SD extended partícióit és pár apróbb dolgot...
Igen, talán jobb úgy csinálni ezt az egészet, hogy nem közölni semmit a tervekről. Ha valamikor elkészül, akkor szépen publikálni.
Semmi harag, se Rád, és senki másra, csak a szokásos türelmetlenség ami előjön 2 évente :D
Jut eszembe, majd lehet, hogy XEP128 ügyben zaklatlak (ha már ez egy XEP128 topic! :D ), mert SSD került a MAC-embe és valahogy újra fel kellene idézni, hogy mit és hova kell másolni :)
Előre is köszi!