Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra... :oops:
Egy másik topic témája lehetne esetleg, hogyan is mûködik!
Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra... :oops:
Quote from: "Lacika"Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra... :oops:
Csatlakozom. :oops:
Quote from: "gafz"Quote from: "Lacika"Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra... :oops:
Csatlakozom. :oops:
Szerintem vagyunk még egy páran... :roll:
Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra... :oops:
Egy másik topic témája lehetne esetleg, hogyan is mûködik!
Másik hibája, hogy az összes ROM fájlt fel kell aprítani 16K-s darabokra.
Addig eljutottam, hogy a letöltött ROM-okkal elindítottam az emulátort, de hogy tudok lemezrõl, vagy "magnóról" (HDD-rõl) betölteni valamit? Hogy lehet konfigurálni?
Köszi az infot!
Így már mindjárt be tudtam tölteni egy programot lemezrõl, bár nagyon sokat tekereg az FDD.
És még a helikopter is elõrefele indul el a Tomahawkban! :P
RESET-et hogy kell eszközölni?
hello!
lehet,hogy hülye vagyok,sőt biztos,de beállítottam a romot,a könyvtárat amiben a játékok vannak, és engedélyezem az I/O-t és most hogyan tölti be a játékot?
:def_dev_fileaztán csak simán START
beirom hogy :def_dev_file és entert nyomok akkor not under...Akkor nem fileio-s konfigod van betöltve!
mi az hogy aztán start?Beírod, hogy START, vagy megnyomod az F1-et.
megint not understood
utolsó szalmaszálként a tape editorral próbálkozom. szép sorban importáltam a wriggler com,wA,wB,wC-t. ha viszont ezek után a save-ben kiválasztottam az emu tape file könyvtárat,"error opening tape file" hibát jelzett. aztán rájöttem,hogy alul nevet kell adni minden programrésznek.Elolvastad amit a wiki-n írtam? Nem kell azoknak nevet adni külön, csak a teljes file-nak a végén.
a :def_dev_file-os töltés mûködik is meg nem is. Pl ha a batman scr-re klikkelek,akkor betölti a screent, aztán egyet villan és visszavált a villogó enterprise képre. Ha a batman apl-re klikkelek elindul a játék a screen kihagyásával. más játékok viszont egyáltalán nem indulnak, csak fekete képernyõ van. van erre megoldás?
En inkabb azt nem tudom, hogy indulasnal miert olyan lassan kapom meg a basic- et az ENTERPRISE felirat utan, vagy miert olyan lassan kapom meg az ASMON- t a :ASMEN utan... 128K- s gep, 100% proci sebesseg, megfelelo sebessegu PC, megis a fent emlitett dolgok lassabbak mint eredeti enterprise- on ...Mert az emulált floppy kezelés lassabb mint az igazi.
Az ep128emu-val dolgozom linux alatt. Az emu többszöri reset (4-5) után beledöglik az exdos emulációba! Az EP újraindul, de az exdosba belefagy. Az emulátort ki kell lőni, és újra indítani.Ezt a hibát egyelőre nem sikerült reprodukálnom. :???: Ha elküldenéd a pontos EP konfigurációt és a lemezt, amellyel a probléma jelentkezik, akkor talán meg tudnám nézni, hogy mi lehet a hiba.
Arról van szó, hogy az emu kb az 5-6. F11 (Sh F11) után az exdos.ini-vel rendelkező disk.img elindításánál különféle szakasznál leáll. Pl kiírja, hogy EXDOS, vagy EXD, vagy csak egy ( jelet, vagy fekete képpel merevszik le.
Ujabb: UHU 2.0 alá is lefordítottam, ott tök jónak tűnik. Nyúzni fogom!A letölthető binárisokkal nem fordul elő a probléma ?
Ezt a hibát egyelőre nem sikerült reprodukálnom. :???: Ha elküldenéd a pontos EP konfigurációt és a lemezt, amellyel a probléma jelentkezik, akkor talán meg tudnám nézni, hogy mi lehet a hiba.A letölthető binárisokkal nem fordul elő a probléma ?Megpróbálom reprodukálni. :shock:
Valaki mondja már meg hogy a felvett videót mivel lehet más formátumba konvertálni? A Virtualdub nem ismeri a codecet.A mindentudó Mencoder!
Valaki mondja már meg hogy a felvett videót mivel lehet más formátumba konvertálni? A Virtualdub nem ismeri a codecet.Én a mencoder (http://www.mplayerhq.hu/)-t használom. Ez egy parancssorból használható program, de elég sokat tud, bár elsőre bonyolultnak tűnhet a sok opció. A dokumentációt érdemes elolvasni :)
mencoder -oac lavc -ovc lavc -lavcopts acodec=mp3:abitrate=256:vcodec=mpeg4:vbitrate=2048 -o video_mpeg4.avi video_rle8.avi
Én a mencoder (http://www.mplayerhq.hu/)-t használom. Ez egy parancssorból használható program, de elég sokat tud, bár elsőre bonyolultnak tűnhet a sok opció. A dokumentációt érdemes elolvasni :)Remélem Endi is rászokik, a Windows-ban is el lehet vele elég jól boldogulni, (Offtopic: De hol van a Batch döcögőssége a Bash ruganyához képest?)
Valaki mondja már meg hogy a felvett videót mivel lehet más formátumba konvertálni? A Virtualdub nem ismeri a codecet.Én a WinAVI Video Converter 7.7-t használom.
áh már megint egy új programot megtanulni...:smt120 Ha a régi már nem jó, akkor mindenképpen meg kell tanulni az újat, hogy hova kattints és mikor, avagy miket írkálj.
nem férnek már bele a fejembe ezek a dolgok
Hogy lehet átírni a memóriát az emu debuggerjével?>cím érték érték érték...
Köszi és regisztert?r-rel lekérdezd, visszamész, átírod.
Na közben rájöttem hogy kérdőjelre kidob helpet és az mindenre választ ad.
Mit csinál a B4h portra küldött 30h?Videómegszakítás engedélyezése.
megj: Érdekes az az LD HL :)Nyomokban Spectrum ROM rutint tartalmaz :-)
Hogy tudom használni a hdd emuba ?Olyan konfigurációt kell betölteni amiben van IDE.ROM, a DISK menüben betenni az image-t. F-tõl lesznek a vinyós meghajtók.
Benne van csak nem tudom hogy kell kilistáztatni a hdd tartalmát !!
Olyan konfigurációt kell betölteni amiben van IDE.ROM, a DISK menüben betenni az image-t. F-tõl lesznek a vinyós meghajtók.
Ez meg van csak nem tudom a parancsot amivel kitudom listázni a particiok tartalmát !!
Azt lehet tudni, hogy az emulátór mit kezd az USB-s floppy meghajtókkal?Nem közvetlenül kezeli, hanem ha jól értettem, valami speciális windows fájlként, így szerintem mûködnie kell.
case 0x071:
{
doOut(R.BC.W, 0);
ADD_PC(2);
R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
}
Szuper, pár programban használtam az OUT (C),0-át a DAVE regisztereinek nullázására :(Hmm, lehet, hogy ez csinálta a zúgást az IK-ban egyes gépeken?
Hmm, lehet, hogy ez csinálta a zúgást az IK-ban egyes gépeken?Simán elképzelhető, OUT (C),00h használatban ott is, úgy fest kénytelen leszek leszokni róla.
Vagy az LD A,I/R-t kéne elrontani vagy az OUT-nál FFh-re cserélni az értéket. Ha jól sejtem ez utóbbi a könnyebb megoldás :-) ha jól tippelem itt kell a 0-át átjavítani:Módosított, CMOS Z80 emulátor.
Módosított, CMOS Z80 emulátor.
Hmm, lehet, hogy ez csinálta a zúgást az IK-ban egyes gépeken?
Istvánt elõ kellene keríteni, csinálni "hivatalos" install-os verziót a honlapjára.Igen, már csak a korábbi hibajavítások miatt is!
h = CreateFileA(fileName, (DWORD) 0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
(LPSECURITY_ATTRIBUTES) 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, (HANDLE) 0);
Igen, már csak a korábbi hibajavítások miatt is!]
Van még egy bosszantó bug: Windows 7 alatt nem tud floppyra írni az emulátor :(
Ezek szerint ebben benne van az a javítás is, miszerint a debugger lapon két mezõ értéke fordítva jelent meg?Természetesen, meg volt egy CPC-s hibajavítás is. (http://enterpriseforever.com/ep128emu/ep128emu_209-t595.0.html;msg25062#msg25062)
Szuper, pár programban használtam az OUT (C),0-át a DAVE regisztereinek nullázására :(Ezekbõl lehetne kérni akkor egy javított verziót? :oops:
Ezekbõl lehetne kérni akkor egy javított verziót? :oops:
Ezt már én is meg akartam kérdezni... :oops:Kérni lehet :D, be is terveztem, csak az a kérdés, hogy mikorra lesznek készen :oops:
Kérni lehet :D, be is terveztem, csak az a kérdés, hogy mikorra lesznek készen :oops:
Remélem nem használtam sok programban, annyira megörültem, amikor rátaláltam az OUT (C),00h utasításra, és nem írták sehol, hogy ez valahol OUT(C),0FFh lol
Az emulátoron most viszont ellentmondásos a dolog, az LD A,I/R nem hibás, tehát CMOS proci van emulálva.
De az OUT (C),0 valóban 0-át küld ki, így meg NMOS procinak látszik.
Vagy az LD A,I/R-t kéne elrontani vagy az OUT-nál FFh-re cserélni az értéket.
Szerencsére az IK+ Reloaded esetében, ha jól látom, nem is hasznos az OUT (C), 0, mert ott az A regiszterben már 0 van, tehát lehet helyette egyszerűen OUT (C), A.Azt nem is vettem észre, de most hogy mondod, eszembe jutott, hogy az programrész elején ott ficeg a XOR A, és utána semmi módosítás, mindegy betettem a többi helyen is használt módosítást, nullázom a B-t, és OUT (C),B -t használok. Tegnap vettem észre, hogy a Dave nullázás nem is volt jó, mert 16-szor írtam az AF regiszterre 00h-t :oops:
Igen, már csak a korábbi hibajavítások miatt is!Sajnos csatlakozni kényszerülök ehhez, mert nem csak Windows 7, hanem Pista (Vista) alatt is ugyanez a gubanc!
Van még egy bosszantó bug: Windows 7 alatt nem tud floppyra írni az emulátor :(
Más programokkal is volt ilyen (Pl régebbi Winimage-val készült önkicsomagoló boot lemezek), valami jogosultsági gond lehet.
Ha "futtatás rendszergazdaként" indítom, akkor se mûködik.
Tippem szerint itt lehet valahol a bibi a wd177x.cpp-ben:Code: [Select]h = CreateFileA(fileName, (DWORD) 0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
(LPSECURITY_ATTRIBUTES) 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, (HANDLE) 0);
Az itt (http://enterpriseforever.com/jatekok/eggs-of-death/msg28681/#msg28681) említett WAV gyártás nem volt zökkenő mentes :-(Ezt egészen pontosan hogyn tudnám tesztelni ?
Eredeti elképzelésem az volt, hogy az emulátor Record Audio funkciójával veszem fel a magnóhangot.
Bár első ránézésre működött, de a programfájl hibás lett, ezért egy idő után lefagyott a program, binárisan összehasonlítva, egy csomó bájt nulla lett.
Ezt egészen pontosan hogyn tudnám tesztelni ?Itt egy komplett save csomag
Jó lenne ha a többiek is kipróbálnák, náluk mi a helyzet.Pontosan mit is kéne kipróbálni? Én már ott elakadtam, hogy az Eggs of Death játéknak miért kellene újra előállítani az eredeti, másolásvédett csipogását, már ha tényleg azt akartad előállítani...
Pontosan mit is kéne kipróbálni? Én már ott elakadtam, hogy az Eggs of Death játéknak miért kellene újra előállítani az eredeti, másolásvédett csipogását, már ha tényleg azt akartad előállítani...Azért, hogy jó minőségben, működően lehessen archiválni az eredeti verziót is a programból, amit aztán lehet emulátorral használni, vagy akár kimenteni kazettára valód géphez.
Mikor bejön a debugger, akkor a második oldalon a bal felső parancs ablakba kell ezte a két sort beírni:Egyszerűbb megoldás (feltételezi, hogy az emulátor "látja" az scr és prg file-okat a file I/O könyvtárban) a v (verify) parancs használatával:
s "s" 0 8000 a7ff
s "p" 0 0480 7ddd
Ez megcsinálja a mentést (az emulátor munkakönyvtárába, ami ALT+F-el választható).
Utána össze kell hasonlítani az s fájlt a csomagban lévő scr fájlal, a p-t a prg-vel. Pl. a Total Commander fájl/összehasonlítás tartalomra.
Normál esetben egyezni kell, ha eltérés van, az a probléma.
v "scr" 0 8000
v "prg" 0 0480
Azonban nekem az alapértelmezett hang beállításokkal mentett WAV file magnó image-ként való használatakor nem volt eltérés. Talán nem mindig fordul elő a hiba, vagy csak bizonyos beállításoknál ?
Az hiba, ha a mentés végén a SAVE.BAT keretcsíkozással lefagy ? :oops:Nem, ezzel jelzi, hogy végzett.
Talán nem mindig fordul elő a hiba, vagy csak bizonyos beállításoknál ?Nagyon úgy tűnik, hogy nem mindig. Az otthoni gépen vagy 10x próbáltam, ott mindig rossz lett :-(
Ennek a hang felvétel funkciónak van köze a hangkártyához?Nincs, az emulátor digitális hangkimenetét menti. Az sem probléma, ha például floppy művelet miatt akadozik a hang. Viszont a sebesség változtatása (Alt+W) letiltja a hangot, és ilyenkor a mentés se használható.
Viszont a sebesség változtatása (Alt+W) letiltja a hangot, és ilyenkor a mentés se használható.Ezt sejtettem, ezért direkt nem is használtam.
Azon a gépen, amelyen mindig rossz a WAV, nem változtattad meg a hang beállításokat (pl. kisebb hangerő) ?Ez jó kérdés, ki tudja, hogy az évek alatt lett-e tekergetve :oops:
Mindenesetre akkor azt javaslod, próbáljam ki Reset default settings-el?Én azzal teszteltem.
Hiba esetén érdemes még megpróbálni a mintavételezési frekvencia növelését.Ok, este próbálkozok!
A legegyszerűbb megoldás nem az egész sávot olvasni/írni egyszerre a pufferbe/pufferből, hanem a szektorokat egyenként ciklusban.Ez nem lenne nagyon lassú (elforog a lemez két olvasási parancs között)? Vagy a mai gépek már bőven elég gyorsak ehhez?
De lehetne a hibás szektort átugorva újra próbálkozni a sáv többi szektorával is.Igen ennél a ciklusosnál lehetne menni a következőre, ami meg hibás volt az valami flaggel megjelölni a pufferben, hogy ha azt olvasná az EP akkor valami hiba legyen generálva.
Par szot tud valaki mondani az ep12emu2 build- eleserol ?Itt volt szó ilyesmiről (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg25044/#msg25044), ami alapján nekem sikerült fordítani.
Itt volt szó ilyesmiről (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/60/?action=post;quote=25044;last_msg=30051), ami alapján nekem sikerült fordítani.
Az emulátor 2.0.9.1 verziójának kiadása óta megtalált néhány kisebb hiba is javítható, ezek valahol megtalálhatók a fórumon a régi hozzászólások között.Nálam ezek a fájlok lettek módosítva.
Kulsag, esetleg azt is leirhatnad, hogy linux- on hogyan modosul mindez ?Ott egyszerűen telepíteni kell a disztribúció csomagjai közül az emulátor függőségeit (SCons, Python - az SCons-hoz, libsndfile, portaudio, FLTK, OpenGL, Lua, SDL, és dotconf). Az FLTK esetében figyelni kell arra, hogy --enable-threads paraméterrel legyen fordítva, ez csak az újabb (1.3.x) verzióknál alapértelmezett. Amit a disztribúció nem tartalmaz (vagy nem használható), azt le kell fordítani, és vagy telepíteni, vagy - statikus (.a) libraryt fordítva - az emulátor forrás könyvtárába másolni.
Kene valami kontribucios rendszer, amit idonkent istvan jovahagyna, berakna a kodbazisba... nem ?Ha valaki fejleszteni szeretné az emulátort, annak engedélyezni lehetne a SorceForge-on SVN hozzáférést, de akár letölthető file-ok kiadását is.
Image- ekbe sem, vagy csak fizikai lemeznel van ?Csak a fizikainál, de gyakorlatilag az is fájlként van kezelve, \\.\A: speciális névvel. Valahol írta is István, hogy mi is ez a trükk :oops:
Nincs valami jellemzo hiabauzenet ? Nem ir ki semmit ? Elszall ? Siman csak nem mukodik ? Mit csinal ? Nincs floppy a gepembe ...Semmi hibaüzenet nincs, egyszerűen csak nem ír rá a lemezre. Amíg az EXDOS puffere emlékszik, addig észre se veszed, csak mondjuk egy reset után már nincs ott a kimentett fájl.
Próbáltad a kompatibilitást XP-re és rendszergazdára átállítani az emunál?Igen, és semmi hatása.
Kipróbálnám. Hogy is kell egy basic programot lemezre menteni? Elfelejtettem.SAVE "A:PRG"
SAVE "A:PRG"A VFD-t próbáltam, de az emuból nem ír rá, csak ha előbb készítek virtuális floppyt, azt be az emuba, majd a Winimage programmal kibontom a VFD-re.
Na, megismerkedtem az ep128emu2 debuggerevel ...Eddig nem is próbáltad???
Az egyetlen szepseghibaja a dolognak, hogy mikor a build utan automatikusan elindul az emulator, az ENTERPRISE felirat megakasztja a procedurat, es csak space utan indul el a frissen build- elt program ... :(
Erre nincs mas megoldas, csak ha csinalok neki egy betolto extension- t, ami letiltja az ENTERPRISE feliratot es egybol lefut ?
Jo ez igy sebesseg szempontbol, csak valahogy el kell tuntetni az ENTERPRISE feliratot ... valaki nem mond okosabbat, akkor irok egy ROM extension- t, ami letiltja az ENTERPRISE feliratot, es nem csinal semmit ... es mar tokeletes is lesz ...EPDOS-ból van olyan változat ami letiltja.
Az tetszik ebben a megoldasban, hogy pontosan olyan, mintha a felhasznalo inditana EP- n ...
A 128K gyorstesztje sztm 1 masodperc alatt van, az exdos.ini elinditasa meg 1-2 masodperc. Igazabol az ENTERPRISE felirat az egyetlen amitol nem szupercsucs, maga a projekt build nagysagrendileg hosszabb a lefuttatasnal ...
Azt meg egy snapshot- ban eloallitani, hogy pont olyan legyen a snapshot, mintha a user toltotte volna be a programot, az nem lenne tul egyszeru ... hanem valszeg tok nehez ... :)
Z80System, ha nem titok mit akarsz alkotni? Demó, játék? (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)Most egyenlore csak osszelovom a dolgokat, kicsit olvasgattam az exos- t, mert ezek hosszu idobe kerulnek, es az ember azert nem kezd bele semmibe, mert ez az elso ismerkedesi fazis, meg kitalalni a "pipeline" kerdeskort olyan hosszu ...
Én a EP_128k_Tape_FileIO_TASMON.cfg konfigot használom, itt marha gyorsan megtörténik az BASIC-be jutás is, csak a Logót kéne eltűntetni, amit lehet, egy jólirányzott jp, vagy ret utasítás megoldana a romban :DSpeciel nem, mert a bejelentkező képernyő a trükkösen védett részek közé tartozik az EXOS ROM-ban :-)
*E676 3A EF BF LD A, (BFEF)
E679 B7 OR A
E67A CC 9D E6 CALL Z, E69D
Nem lehet valahogy a trükkös védelmet megkerülni?
Akkor fölöslegesen találtam meg a helyét? :DA legegyszerűbb egy ROM-mal ami kikapcsolja a logót :-)Code: [Select]*E676 3A EF BF LD A, (BFEF)Nem lehet valahogy a trükkös védelmet megkerülni?
E679 B7 OR A
E67A CC 9D E6 CALL Z, E69D
Hogy hivjak ubuntu alatt az opengl konyvtarat ? amit fel kell tenni az apt- vel.
Mar csak azon elmelkedem, hogy scons alatt mi lehet a szokasos "make clean" es "make distclean" megfelelojeEzt korábban már leírtam itt (http://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713), de a make clean megfelelője az scons -c, ami azonban nem törli a következőket: .sconf_temp, .sconsign.dblite, és config.log.
ja en is ezt a mesa cuccot lattam legvaloszinubbnek, csak valahogy ki volt hangsulyozva, hogy az software implementacio, es azt nem hinnem hogy linuxon nem megy hw- bol az emu.A lényeg, hogy legyen használható gl.h és glext.h, a mesa devel csomag csak ezek miatt kell.
Ezt korábban már leírtam itt (http://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713), de a make clean megfelelője az scons -c, ami azonban nem törli a következőket: .sconf_temp, .sconsign.dblite, és config.log.
ja en is ezt a mesa cuccot lattam legvaloszinubbnek, csak valahogy ki volt hangsulyozva, hogy az software implementacio, es azt nem hinnem hogy linuxon nem megy hw- bol az emu.
Ez az scons-os megoldas nekem pont azert nem tetszik, mert tul fixnek tunik minden, az std pkg-config-os dolog ami sima Makefil eseten is altalaban hasznalatos (vagy autoconf-al) azonnal megtalalja:Az SCons valójában támogatja a pkg-config-ot, csak én nem használtam (illetve csak az fltk-config-ot): :oops:
env.ParseConfig(command, [function, unique])
Calls the specified function to modify the environment as speci-
fied by the output of command. The default function is
env.MergeFlags(), which expects the output of a typical *-config
command (for example, gtk-config) and adds the options to the
appropriate construction variables. By default, duplicate val-
ues are not added to any construction variables; you can specify
unique=0 to allow duplicate values to be added.
Interpreted options and the construction variables they affect
are as specified for the env.ParseFlags() method (which this
method calls). See that method's description, below, for a ta-
ble of options and construction variables.
De akkor ezek szerint azt valahogy nekem kell beledrotozni az SConstruct file-ba, hogy hol van a lua.h ?Ez a 40. sor körül megtehető a CPPPATH és LINKFLAGS módosításával. Egy másik megoldás a Lua .h és .so (vagy .a) file-okra symlinkeket létrehozni az emulátor forrás könyvtárában. Természetesen a legjobb lenne megvalósítani a pkg-config használatát.
Az SCons valójában támogatja a pkg-config-ot, csak én nem használtam (illetve csak az fltk-config-ot): :oops: Ez a 40. sor körül megtehető a CPPPATH és LINKFLAGS módosításával. Egy másik megoldás a Lua .h és .so (vagy .a) file-okra symlinkeket létrehozni az emulátor forrás könyvtárában. Természetesen a legjobb lenne megvalósítani a pkg-config használatát.
Ezt hol kéne módosítani?A wd177x.cpp-ben. Nem egy helyen definiált konstans vagy makró, igy keresés/csere kell a növeléséhez. :oops: Ha fontos, hogy a több sáv kézi beállítására is legyen lehetőség, akkor cserélni kell még az emucfg.cpp-ben, és a gui/disk_cfg.fl-ben is (ami szerkeszthető egyszerű szöveges file-ként, vagy a fluid.exe segítségével).
Debug verzióhoz azonban célszerű "enableDebug = 1" és "buildRelease = 0" beállításokat használniAz, hogy debug verzió az mit jelent pontosan?
A fordításhoz szükséges csomagok Windowson:Eddig én a tőled 2012 februárban kapott MinGW csomagot használtam, most megpróbáltam lecserélni erre, a fordítás látszólag rendben lefut, de az EXE nem működik "hibát észlelt és leáll"...
1. MinGW + FLTK + libsndfile + portaudio + SDL + lua + dotconf + OpenGL (https://www.dropbox.com/s/v9b0e3kij9ai7ug/mingw.7z)
2. Python 2.7.4 (http://www.python.org/download/) (az SCons futtatásához)
3. SCons 2.3.0 (http://www.scons.org/)
4. NSIS 2.46 (http://nsis.sourceforge.net/Download) (opcionális, csak installer készítéséhez)
a debugger környezethez debug információt is tartalmazÉs milyen környezetben lehetne debuggolni?
Lehet az a gond, hogy nekem a tavalyi 2.7.3 a Python, és 2.2.0 az SCons?Frissítettem, ugyanaz :-(
Frissítettem, ugyanaz :-(Nincsenek valahol régi file-ok az előző MinGW csomagból ? Elsősorban a gcc és stdc++ DLL, és - fordításnál - az FLTK okozhat problémát.
Nincsenek valahol régi file-ok az előző MinGW csomagból ? Elsősorban a gcc és stdc++ DLL, és - fordításnál - az FLTK okozhat problémát.A régi MinGW könyvtárat átneveztem, és kicsomagoltam az újat.
A wd177x.cpp-ben. Nem egy helyen definiált konstans vagy makró, igy keresés/csere kell a növeléséhez. :oops: Ha fontos, hogy a több sáv kézi beállítására is legyen lehetőség, akkor cserélni kell még az emucfg.cpp-ben, és a gui/disk_cfg.fl-ben is (ami szerkeszthető egyszerű szöveges file-ként, vagy a fluid.exe segítségével).Ez úgy tűnik sikerült :-) (régi MinGW-vel)
ep128emu.exe (http://enterpriseforever.com/ep128emu/ep128emu/?action=dlattach;attach=9037) (1283.5 kB - letöltve 83745 alkalommal.)Ez mi? Mi a verziószáma?
Ez mi? Mi a verziószáma?2.0.9.1
Akkor ez csak a floppys újítást tartalmazza?
Van még egy bosszantó bug: Windows 7 alatt nem tud floppyra írni az emulátor :(Ezt találtam. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx)
Más programokkal is volt ilyen (Pl régebbi Winimage-val készült önkicsomagoló boot lemezek), valami jogosultsági gond lehet.
Ha "futtatás rendszergazdaként" indítom, akkor se mûködik.
Tippem szerint itt lehet valahol a bibi a wd177x.cpp-ben:Code: [Select]h = CreateFileA(fileName, (DWORD) 0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
(LPSECURITY_ATTRIBUTES) 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, (HANDLE) 0);
Physical Disks and VolumesDirect access to the disk or to a volume is restricted. For more information, see "Changes to the file system and to the storage stack to restrict direct disk access and direct volume access in Windows Vista and in Windows Server 2008" in the Help and Support Knowledge Base at http://support.microsoft.com/kb/942448 (http://Http://go.microsoft.com/fwlink/p/?linkid=117121).Amennyire kigoogléztam, lock-olni kéne a meghajtót, hogy működjön az írás.QuoteWindows Server 2003 and Windows XP: Direct access to the disk or to a volume is not restricted in this manner.
harmadik paraméterét (FILE_SHARE_READ | FILE_SHARE_WRITE) 0 -ra kéne írni,Ezt próbáltam, de önmagában semmit nem segített :-(
akkor tegyél be egy lemezt, és disk manager -ben unmount -old, és akkor már lehet hogy műxik is ...Gondoltam erre, de a floppy nem látszik a disk manager-ben.
Még egyszer sem futtattam azt ...De fordítottál EXE-t?
Floppytlan gépen meg ezzel (http://www.totalcmd.net/plugring/virtdisk.html) tudok floppyt csinálni.Ezt egyébként mással már próbáltad, tehát működőképes dolog ? Vagy csak az emuval probáltad ?
Az így be mountolt image-re, pont ugyanúgy nem ír, mint a valódira.
Ezt egyébként mással már próbáltad, tehát működőképes dolog ? Vagy csak az emuval probáltad ?Mással lehet rá írni.
Na, a mai alkalom akkor annyira volt elég, hogy lefordítsam a cuccot, összelőjem a GDB -t ( mindenféle vackok kellenek meg az IstvanV mingw -jéhez hogy a GDB is menjen ), meg begerjesszem a virtuális floppy mókát, meg kicsit megismerkedjek a GDB -vel, de mostmár akkor a következő időkben tudok majd effektíven a problémával is foglalkozni.Ehhez akkor tudnál receptet írni? Lenne majd még más debuggolni való probléma is. (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)
Ha megnézed az első 2 if -et, akkor látod, hogy ha a bejövő filename (ami a mi esetünkben most : "\\.\A:" ugye ...) hossza kisebb mint 5 karakter, vagy az eleje megegyezik a "\\.\" -rel, akkor ez a függvény egyből visszatér ...A másodiknál van egy not az elején :oops:
Szal ennek a CreateFile -nak semmi köze a dologhoz ...
Ehhez akkor tudnál receptet írni? Lenne majd még más duboggolni való probléma is. (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)(http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)
A másodiknál van egy not az elején (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)De. Valóban... az úgy akkor logikailag helyrerakná a dolgokat, a gyakorlatban meg most akkor 2 dolog lehet: vagy benéztem valamit a GDB -ben (ugye most láttam először) és nem is tért vissza, vagy pedig nem az a karakterszekvencia van megadva a fileName -ben, mint ami kéne. Furcsa is volt, hogy a fileName -re a gdb azt írja ki hogy "\\\\.\\a:", de azt hittem, hogy ez valami output formázási gáz csak, és a változóban a jó string van ... persze még mindíg lehet az első is, hogy csak benéztem ... na majd megnézem.
Vagyis akkor tér vissza, ha 5-nél rövidebb, vagy az eleje nem "\\.\"!
Furcsa is volt, hogy a fileName -re a gdb azt írja ki hogy "\\\\.\\a:"Ez nem hiba, a \ a C nyelvben speciális "escape" karakter, amit valóban kétszer kell írni ahhoz, hogy egyszerű nyomtatható \ karaktert jelentsen.
Ez nem hiba, a \ a C nyelvben speciális "escape" karakter, amit valóban kétszer kell írni ahhoz, hogy egyszerű nyomtatható \ karaktert jelentsen.Természetesen, de attol meg ha a változó ezt írja ki a GDB -ben runtime, az gáz mert az escape szekvenciák compile time információk, amik a fordítónak szólnak, a változóban már csak átverésként szerepelhetnének. Márpedig az volt benne.
Debug fordításnál célszerű letiltani az optimalizálást (-g -O0), mert az "megkeverheti" a változókat és az utasítások sorrendjét, és egyes változók el is tűnhetnek. Optimalizálás nélkül gyorsabb is a fordítás, ezzel és párhuzamos (-j) módban másodpercek alatt lefordítható az egész forráskód.Thx, optimalizációt nem vettem ki, lehet hogy a változó tartalmát is azért írja ki rosszul ...
Természetesen, de attol meg ha a változó ezt írja ki a GDB -ben runtime, az gáz mert az escape szekvenciák compile time információk, amik a fordítónak szólnakA GDB is ezt a formátumot használja, így a nem nyomtatható karaktereket (pl. '\n') is ki tudja írni.
Ez nem hiba, a \ a C nyelvben speciális "escape" karakter, amit valóban kétszer kell írni ahhoz, hogy egyszerű nyomtatható \ karaktert jelentsen.
Juhúúúúú !Így már kezd szimpatikus lenni a dolog :-)
http://www.affinic.com/?page_id=137 (http://www.affinic.com/?page_id=137)
István! Arra tudnál tippet adni, hogy a bekapcsoláskori véletlenszerű regiszter feltöltődést hogyan lehetne emulálni?A z80funcs2.cpp-ben a Z80::Z80() függvény a Z80 első inicializálása. Ez csak az emulátor indításakor fut le, minden más esetben (bármilyen reset, snapshot betöltés, stb.) csak egyszerű Z80::reset() történik. Tehát a véletlenszerű regisztereket ide lehetne beépíteni, a memset() és a reset() közé, de elvileg kerülhetne a reset()-be is, hogy mindig véletlenszerű legyen, ha ez nem is felel meg pontosan a valódi gépnek. Egy másik lehetőség az Ep128VM::reset()-ben (ep128vm.cpp) 'isColdReset' esetén véletlenszerűsíteni a Z80 regisztereket. Hasonló reset függvény azonban van még külön a Spectrum és CPC emulációhoz is.
#include "system.hpp"
...
{
int seed = 0;
Ep128Emu::setRandomSeed(seed, Ep128Emu::Timer::getRandomSeedFromTime());
R.AF.W = Z80_WORD(Ep128Emu::getRandomNumber(seed) & 0xFFFF);
...
}
A z80funcs2.cpp-ben a Z80::Z80() függvény a Z80 első inicializálása. Ez csak az emulátor indításakor fut leEz szerintem elég jó lesz bekapcsoláshoz :-)
A file buffer kikapcsolása nem lett megvalósítva a javított kódban, vagyis mostmár bufferelten fog működni. Ez miért lett kikapcsolva vajon az eredetiben, ill. nélkülözhetetlen -e ? Működni nekem így is működik ...Én sejtem, legalábbis nagyon úgy tűnik visszajött az a hiba, amit István egyszer kijavított :oops:
Egy apróság, nem az utolsó WD177x.cpp (http://enterpriseforever.com/ep128emu/ep128emu/msg32006/#msg32006) lett módosítva, megint írhattam át rakás 240-t 254-reHasználj valami ilyen programot forrás file -ok összefésülésére:
Én sejtem, legalábbis nagyon úgy tűnik visszajött az a hiba, amit István egyszer kijavított (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)Jó, akkor megkeresem hogy kell kikapcsolni winen a bufferelt írást, hogy ugyanúgy működjön ... Időzítésről én mit sem tudok ...
Az emulált EP befejezi az írást, visszajön a prompt, az ember dolgozna tovább, erre megakad egy kicsit, mert az emu nekiáll kiírni a lemezre a puffert.
Mondjuk úgy emlékszem, hogy akkor valami időzítést vett István kicsire.
A lockolás jól működik, nem kell rendszergazdaként indítani.Szupi akkor (nem ezt olvastam), de biztos nem ragadt át az emura a TC -ből, vagy valahonnan máshonnan az admin jogkör ?
A megnyitott Totális Parancsnok ablak se baj, attól még nyugodtan lockolja az emu a lemezt, és ha esetleg újra a Parancsnok lesz az aktív ablak, akkor mondja, hogy nem tudja olvasni az A:-tOk, én csak egyik irányt próbáltam (mikor a TC nem látja már az emu -ban lockolt drive -ot, pontosabban nem fér hozzá), ha másik irányból el tudja venni az emu a drive -ot a TC -től, akkor még jobb. ( Bár gondolom, ha éppen írja a TC a lemezt, akkor azért mégsem fog az neki sikerülni... nem ? )
Sőt ez így sokkal jobb lett, mert korábban tapasztaltam adatvesztést amiatt, hogy a Parancsnok nem vette észre, hogy az emu írt a lemezre, ezért én mindig azt csináltam, hogy kivettem a lemezt, ráolvastam az üres A-ra, majd utána a visszatett lemezre, hogy biztosan az aktuális adatokat olvassa.
Most, az emu futása után a Parancsnok egyből frissít, gondolom megtudja a Win-től, hogy ez közben lockolt meghajtó volt, frissíteni kell.
Tudunk erről valamit ? Hogy az emu szektoronként írja -e a floppy -t ?Igen úgy írja, mivel az igazi WD is úgy írja.
Valami 512 -es értékkel szorozza meg fixen a kiírni akart szektorok indexét/számát. Lehetséges hogy floppy -nál mindíg 512 byte egy szektor (track) ?EP-s lemezen mindig 512 bájt egy szektor.
Szupi akkor (nem ezt olvastam), de biztos nem ragadt át az emura a TC -ből, vagy valahonnan máshonnan az admin jogkör ?Nem, parancsikonnal indítom, direkt leellenőriztem, hogy nincs bejelölve a rendszergazdaság.
Bár gondolom, ha éppen írja a TC a lemezt, akkor azért mégsem fog az neki sikerülni... nem ? )Igen, ez esetben az EP Write only disk hibát dob. Szerintem ez így teljesen korrekt.
Igen úgy írja, mivel az igazi WD is úgy írja.Oks, akkor kiraly, itt van a nem bufferelt verzio, kiprobaltam, irni ez is ir, azt nem tom hogy kell kiprobalni hogy "ne akadjon", de gondolom te majd ugyis megnezed.
Akad vagy nem akad, elvileg most mar ez is ugyanolyan unbuffered, mint a javitas elott volt.Én nem vettem észre semmi különbséget :oops:
a most utánajártam egy XP-s gépen, ahol működik a régi EXE-vel is az írás.De hogy lehet ezt az hibat tapasztalni ? Mit tegyek pontosan, hogy tapasztaljam a hibat ?
Úgy tűnik ott is megvolt az effekt (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif), bár mintha egy picit rövidebb időre.
Mindegy, ennyi belefér, fő, hogy megy új windowson is az írás! Image fájlon nincs gond, mivel az gyors.
De hogy lehet ezt az hibat tapasztalni ? Mit tegyek pontosan, hogy tapasztaljam a hibat ?pl :MD PROBA visszajön az OK, villog a kurzor, majd egyszer csak kihagy egy "ütemet".
pl :MD PROBA visszajön az OK, villog a kurzor, majd egyszer csak kihagy egy "ütemet".Hát olyanom egyenlőre nincs, akkor maradsz te a teszter,
De ez csak valód lemezzel látszik, mert ott kell várni a meghajtóra.
most akkor már a legutolsó verzióval is tesztelted, vagy még azzal nem ? Avval amelyik ma reggelre virradólag volt feltéve ?Igen azzal is.
Oszinten szolva, nekem ez a C++ meg mindenfele custom build system kicsit sok (SConstruct vagy mi a neve, normal Makefile legalabb ertheto), annak ellenere hogy pl mplayer fofejleszto voltam, nekem se sikerult meg build-elnem sajat magam, pedig nem keves C project-et (koztuk az emlitett mplayer-t) is csinaltam ... Anno a Yape nevu Plus/4 emulatort is inkabb forkoltam es atirtam normalis C-re a C++ helyett, meg stb, hogy kezdeni tudjak vele valamit YapeNG neven :( C++-nal mar csak a Java idegenebb szamomra a sajat dolgaival (pl ant stb) egyutt ...Ugyan ez is C++, de talán említést érdemel a plus4emu (http://sourceforge.net/projects/plus4emu/), amely az ep128emu-hoz hasonló, csak Plus/4-et emulál. Eredetileg az ep128emu 2.0 beta verzió része volt, csak később lett külön program. A fordítása is gyakorlatilag azonos módon történik az ep128emu-val.
Na akkor itt van egy utolsó verzió, ha ez sem oldja meg, akkor egyenlőre nincs több tipp, nyomozni kéne, hogy ezeken kívül hogy lehet még direktebben és azonnalibban írni a lemezt ...Ez szerintem van olyan jó, mint az eredeti volt.
Ez szerintem van olyan jó, mint az eredeti volt.Érdekes ... az első "buffertelítéskor" egy flag -gel lekapcsoltam a buffer használatot, mikor nem volt "elég jó", akkor az msdn help szerint bekapcsoltam még egy "write through" flag -et is, mert azt írták, hogy a kettő együtt már garantált buffertelenség lesz, aztán mikor még az sem lett jó, akkor az írás művelet után betettem egy explicit buffer flush műveletet ... ettől jobb lett ... hogy ki lett flush -ölve a már nem használt és keresztül írt buffer ... érdekes ...
Ez lenne még egy fontos kijavítandó bug! (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)Na néztem a kódot, de ennek most nem állok neki. Vagy az kéne hogy értsem a WD működését, hogy könnyedén értsem hogy a kód mit miért akar úgy csinálni, ahogy,
Ha jól tippelem a bool WD177x::readTrack() eljárást kéne fejleszteni.
Elvileg ha jól nézem adna vissza valami errorFlag-et, így nem értem miért tud hibátlannak tűnő olvasást generálni...
Van, úgy hívják USB floppy :-)
Nincs valami olyan floppy egység, mint az USB DVD meghajtók ? Tehát amolyan "külső floppy", amit USB -re dugok, és lesz tőle fizikai floppy a gépben ?
A WD egy low level floppy vas kezelő IC, nem ? Az biztos nem ismer semilyen adatot a lemezen, magasról tojik rá hogy mi van a szektorokban, fizikailag beolvassa a raw bájtokat, aztán kezdjen vele akármit aki akar, nem ?Ez a sáv olvasása parancsnál van így. Ilyenkor egy nagy rakás kriksz-krakszot kapunk, ami ráadásul minden alkalommal más és más, mivel a szinkronizáció sem történik meg.
Ha ez nem lenne a WD -ben, akkor az EXOS -nak kéne valami ilyen biztosító/ellenőrző módszert megvalósítania ?Így van.
Viszont ezt a CRC értéket (gondolom több bájt) valahova tennie kell a WD -nek, nem ? Tehát akkor valahogy már a floppy vezérlője mégis meghatároz lemez formázást, nem ? Ha azt nem is definiálja, hogy vannak ábrázolva a sector láncok a file -okhoz, ezt a CRC helyet csak ő határozza meg, nem ?A szektorfejléc utáni, ill. az adatterület utáni két bájt az.
És egyebként hova határozza meg ? Szektoron belülre, vagy kívülre ?
Ezt befolyásolni lehet a formázáskor, amikor a RAW adatfolyamatba kiírt F7h bájt jelzi a CRC bájtok kiírását. Viszont ha nem oda tesszük, ahol majd olvasásánál várja, akkor CRC hiba generálódik, erről szólt a korábbi trükk.És ezt a fícsört (hogy befolyásolni lehet) direkt trükközéshez tették bele ? Mert ha a beolvasást nem lehet "szinkronban" befolyásolni, akkor a trükködön kívül semmire nem jo ...
A szektorfejléc utáni, ill. az adatterület utáni két bájt az.Na ez lenne a lényeg, tehát igenis meghatároz akkor a floppy vezérlő formázási információt ... akkor mitől kompatibilisek a floppy -k a különbözö vasakon ? Minden vezérlő ugyanúgy határozza meg a CRC bájtok helyét ? Vagy a világon mindenben (pld. a mai PC -k floppy vezérlőjében) is a WD ic (logika) van benne ? A WD licenszeli a világnak a floppy vezérlő okosságait ? Nyilván nem ...
Vagy az is lehet, hogy a teljes file kezelő (fájlokhoz szektor lánc nyilvántartó) logika is a WD -ben van ? Hat az csaknem azért ... annál alacsonyabb szintű dolog az, nem ?
Dehogy. Az mar a FAT resze,Ok, de akkor a kérdés másik része még mindíg él:
A CRC érték letárolásához is van egy szabvány, amit a WD (és mindenki más is) tulajdonképp csak megvalósít ?Így van, itt linkeltem is a szabványokat. (http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)
Így van, itt linkeltem is a szabványokat.(http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)
(http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078) (http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)Ennek kb a 95%-a a meghajtó, lemez, és floppyvezérlő IC gyártók mérnökeinek szól :-)
Ó, babám fsza ! Ennyi szirszart elolvasni, és megérteni, és akkor már képes is vagyok egy redvás szektort beolvasni egy lemezrol ... Hát ez király ...
vagy pedig a header az külön van az 512 bájtunktól, és vélhetően azokat az infókat a win file API -ja vissza sem adja ?Igen külön van, ezt már maga a lemezvezérlő IC se adja vissza szektorolvasásnál. (WD-nél van ezekhez külön fejléc olvasás parancs.)
Igen külön van, ezt már maga a lemezvezérlő IC se adja vissza szektorolvasásnál. (WD-nél van ezekhez külön fejléc olvasás parancs.)Akkor pedig (HA nem adja vissza a bad sector info -t a win a file api -kkal, vagy azzal a DeviceControl api -val, amivel a lock -ot is kellett allitani, illetve amivel a fizikai paramétereket is lekérdezi a WD kódja) gonban leszünk, mert sztm a win file api -ja csak a raw szektorokat adja vissza, így mindegy is hogy azokban mi lesz bad sector esetén, mert CRC info -nk az nem lesz.
size_t bytesRead =
std::fread(&(tmpBuffer[offs]), sizeof(uint8_t), nBytes, imageFile);
errorFlag = (bytesRead != nBytes);
És akkor generálna hibát, ha nem annyi bájt lett beolvasva, mint amennyi kéne. De ez valahogy mégse jelződik.
Persze (ha ki tudnám próbálni) ha lefalsol egy bad sector -nál, akkor lehetne azt hogy a track- et szektoronként olvassuk ( egy ciklusban a track szektorait ), és szektorosan jelöljük, hogy melyik volt rossz, így akkor lenne szektoronként hiba informacionk.Igen ez lenne majd jó megoldás, csak legyen hibakód.
// reading sector
if (currentTrack != bufferedTrack || currentSide != bufferedSide)
(void) updateBufferedTrack(); // FIXME: errors are ignored here
if (!flagsBuffer[bufPos >> 9]) {
if (!readTrack()) {
setError(0x08); // CRC error
dataRegister = 0x00;
return 0x00;
}
}
Több helyen van ez a wd177x.cpp-ben: // FIXME: errors are ignored hereEzek nem olvasásnál, hanem írásnál fordulnak elő, többnyire olyan helyeken, ahol a pufferelt sáv írásánál (flushTrack()) történő hibát az emulált WD nem tudja egyszerűen jelezni. Az olvasási hibáknak elvileg nem kellene elveszni, de a kezelésükön javítani lehetne, és valószínűleg valahol hibás a kód. A legtöbb probléma a sáv puffereléssel kapcsolatos, ami azért került az emulációba, hogy ne legyen nagyon lassú valódi lemezekkel Windowson.
Elvileg itt lenne CRC hiba jelzés:Ez nem ideális megoldás, mert bármelyik szektor hibája esetén az egész sávot hibásnak jelzi. :oops: De valamiért a hiba elveszik.
Vagy pont az a gáz, hogy ha a track sector -ait szektoronként olvasnám be, akkor az marha lassú lenne ?Lehet, hogyha maga az emulátor programkód olvasná be így egyből az nem lenne lassú.
Ez nem ideális megoldás, mert bármelyik szektor hibája esetén az egész sávot hibásnak jelzi. :oops: De valamiért a hiba elveszik.Na ez már egy nyom, hogy elvileg így kéne működni, már csak azt kéne kitalálni, hol veszik el!
Lehet, hogyha maga az emulátor programkód olvasná be így egyből az nem lenne lassú.Na de akkor ez eredeti EP -n is ilyen lassú ? Vagy emu -n gyorsabbat akartunk mint eredeti EP -n ?
Az eredeti nem puffereltben gondolom az volt a baj, hogy az emu beolvasta a a szektort, majd utána WD-ként átadta az EP-nek, majd utána ha az EP feldolgozta, kérte a következő szektort. Eközben a lemez továbbfordult, meg kellett várni egy fordulatot a következő szektorhoz.
Na de akkor ez eredeti EP -n is ilyen lassú ?Nem, de ott az átvitel pontosan annyi ideig tart amíg a szektor elhalad a fej alatt.
Ez nem ideális megoldás, mert bármelyik szektor hibája esetén az egész sávot hibásnak jelzi. :oops: De valamiért a hiba elveszik.István! Ha a kérdéses helyen a (bytesRead != nBytes) kifejezés helyett fixen True lesz az errorFlag értéke, akkor az egész lemeznek hibásnak kéne látszódnia?
István! Ha a kérdéses helyen a (bytesRead != nBytes) kifejezés helyett fixen True lesz az errorFlag értéke, akkor az egész lemeznek hibásnak kéne látszódnia?Hát ha elveszik ... próbáltad már beállítani ? Simán lehet hogy nem elveszik, hanem meg sem jelenik ...
Így akkor hibás lemez, floppy meghajtó, stb nélkül is lehetne keresni, hol veszik el a hibajelzés.
Ha a kérdéses helyen a (bytesRead != nBytes) kifejezés helyett fixen True lesz az errorFlag értéke, akkor az egész lemeznek hibásnak kéne látszódnia?Igen.
Hát ha elveszik ... próbáltad már beállítani ? Simán lehet hogy nem elveszik, hanem meg sem jelenik ...Most fordítottam egy ilyet, de működésben nem látok változást. Ami alapján nekem nagyon gyanús, hogy ez az errorflag nincs feldolgozva :oops:
Most fordítottam egy ilyet, de működésben nem látok változást. Ami alapján nekem nagyon gyanús, hogy ez az errorflag nincs feldolgozva :oops:Hoppá mégis találtam valamit!!!
if (currentTrack != bufferedTrack || currentSide != bufferedSide)
(void) updateBufferedTrack(); // FIXME: errors are ignored here
if (!flagsBuffer[bufPos >> 9]) {
if (!readTrack()) {
setError(0x08); // CRC error
dataRegister = 0x00;
return 0x00;
}
}
A readTrack akkor fut le, amikor változott a sáv vagy oldal, azaz frissíteni kell a puffert.A readTrack akkor fut le, amikor változott a sáv vagy oldal, azaz frissíteni kell a puffert.A hiba valójában nem itt van, mert az ismételt olvasásnál újra kellene hívnia a readTrack()-et. Már most is van egy flagsBuffer[] tömb, amely azt tárolja, hogy az egyes szektorok a pufferben jók-e, és hogy tartalmaznak-e kiíratlan adatot. A readTrack() csak azokat a szektorokat próbálja újraolvasni, amelyek még nem jók. Itt azonban hiba van:
De a visszaadott errorFlag csak itt van vizsgálva! Ha hiba volt vissza is megy hibajelzés, de nincs letárolva a hiba ténye, ezért az ismételt olvasásnál, amikor már a pufferből dolgozik, nem lesz hibajelzés.
else {
size_t bytesRead =
std::fread(&(tmpBuffer[offs]), sizeof(uint8_t), nBytes, imageFile);
errorFlag = (bytesRead != nBytes);
}
}
for (uint8_t i = firstSector; i <= lastSector; i++)
copySector(i);
return (!errorFlag);
A copySector() az, ahol a "szektor OK" jeélzőbit beállítódik, de ez azokon a szektorokon is lefut, amelyeket az std::fread() esetleg nem tudott beolvasni. Tehát hiba esetén a lastSector változót a sikeresen beolvasott adat mennyiségének megfelelően csökkenteni kellene, de ez kimaradt. :oops:A rendes szektoros jó lenne, ha nem lenne brutálisan lassú. Anno amikor még nem rakta be a pufferelést István, kb 10x lassabb volt mint az igazi...Hát ha így, akkor így. Én ezekről a történelmi előzményekről nem tudtam ... Nekem még biztos mindíg a lassú verzió lenne ilyen megkötésekkel, de nyilván ez azért van, mert kb. te vagy az egyetlen, aki használja is a fizikai floppy -t PC -n ... :) De ha nem, akkor is biztos, hogy nem én, szal a sebesség engem legkevésbé zavarna.
Most érzésre kb ugyanolyan gyors mint az igazi, és ez szerintem így jó.
Ezt emlegettem.(http://simonowen.com/fdrawcmd/)
Tehát ha ezt a driver -t használnánk akkor félig vagy egészen, de az USB floppy -kat elbuknánk úgy tűnik, ami a fejlődés irányát nézve (gépekből sorra maradnak ki a floppy meghajtók, szinte nem is gyártják őket már) lehet gázos lesz a jövőben.Igen, ez így van, tehát a mostanit (kijavítva) meg kéne tartani, és plusz lehetőségként lehetne berakni ezt (Mondjuk lenne egy Fdraw direct access pipácska a lemez választó menüben.)
De a jelenlegi file -os módszer 99% menne akkor az USB floppy -kon is, sztm ...
Egyébként filerendszer szinten ugyanaz a FAT12 van a floppy -kon is, mint az EP winyón ?
Amiből az is következik, hogy ha olvassa az EP floppy -kat egy mai modern OS (márpedig tudtommal az összes olvassa), akkor egy mai modern OS -ben még mindíg benne kell legyen az ős régi FAT12 fájlrendszer írása/olvasása (ha már a formázására nem is képesek) ?
Egyébként filerendszer szinten ugyanaz a FAT12 van a floppy -kon is, mint az EP winyón ?Igen.
Engem az is erdekelne, hogy mi a helyzet a FAT16-el. Zozo mintha azt mondta volna, hogy valoszinu megoldhato lenne az is EP-n tobb-kevesebb munkaval.Előbb végére kéne érni az EXDOS visszafejtésnek :oops: de már sejtem, hogyan lehetne megoldani...
Előbb végére kéne érni az EXDOS visszafejtésnek :oops: de már sejtem, hogyan lehetne megoldani...
Ott egyszerűen telepíteni kell a disztribúció csomagjai közül az emulátor függőségeit (SCons, Python - az SCons-hoz, libsndfile, portaudio, FLTK, OpenGL, Lua, SDL, és dotconf). Az FLTK esetében figyelni kell arra, hogy --enable-threads paraméterrel legyen fordítva, ez csak az újabb (1.3.x) verzióknál alapértelmezett. Amit a disztribúció nem tartalmaz (vagy nem használható), azt le kell fordítani, és vagy telepíteni, vagy - statikus (.a) libraryt fordítva - az emulátor forrás könyvtárába másolni.Nekiugrom újra és megcsinálom a forrásból az UHU 2.2 ubk verzióhoz, http://uhu.ubk.hu/pkg/2.2/ újra a telepítő csomagját.
A fordítás Linuxon is scons paranccsal történik, azonban szükség lehet az SConstruct módosítására fordítási hibák esetén, a különböző GCC verziók, Linux disztribúciók, stb. inkompatibilitása miatt. Ha ilyen hiba fordul elő, azt célszerű jelezni a fórumon.
Nekiugrom újra és megcsinálom a forrásból az UHU 2.2 ubk verzióhoz, http://uhu.ubk.hu/pkg/2.2/ újra a telepítő csomagját.Bocs az off-ért: mi van az UHU-val?
UHU 2.2 alatt minden jóval frisebb már, mint 2 éve, akkor még a kész binárisból csináltam, de sokkal elegánsabb, és nehezebb :twisted:, nem statikus libekkel megcsinálni, a kész bináris is jóval rövidebb lesz.
Ha valahol komolyabban elakadok, akkor jelzem majd.
Kicsit régészkedtem a régi emulátor verziók között:Most ha jól értem, csak megerősítetted, amit már eddig is mondtatok: volt ez jó is, csak lassú, és mikor bekerült a cylinder cache, elszúrt pár (mostanra általatok beazonosított) dolgot.
2.0.5.1 esetén még nem volt probléma a bad sectoros lemezekkel, jó szektorokat beolvassa, hibás esetén az EP is megkapja a hibát.
Viszont ebben a verzióban meg ha hosszabb ideig vár a lemezre, akkor eltűnik az EP kép. Ha jól sejtem ezért is jött a pufferes dolog a 2.0.6-ban.
A konverziót a ZX128VM::convertKeyboardState() függvény végzi.És ennek a táblázatnak mi a felépítése?
Valami gond lehet a módosított emuval.Demo felvétel és lejátszás közben mindig is tiltott volt a lemezkezelés és egyéb file I/O. Ezt ugyanis csak az image file tárolásával lehetne felvenni, ami jelentősen növelhetné a demo méretét (különösen IDE emulációnál).
Ha a demo felvétel be van kapcsolva, nem működik a lemezkezelés. Sem igazi floppyval, sem image el. Not ready üzenet az eredmény. Az avi felvételben meg rosszak a színek, ez nem tudom mióta ilyen.
Az AVI-t mivel játszottad le ?VLVPlayer 1.1.11
Nem tudom, hasznos-e ez még, de itt egy rövid leírás az ep128emu file I/O funkciójának a működéséről:Elvileg lehetséges lenne új funkciókat hozzáadni, amivel egyes emulátor funkciókat lehetne az emulált EP-ből vezérelni?
A ROM az EDh FEh FEh n "utasítással" tudja hívni az emulátort, ahol n az elvégzendő művelet kódja. Ez többnyire az EXOS csatorna műveletekkel azonos, a teljes lista a következő:
Nekem nincs fekete csík. Biztos, hogy nem az LPT hibája (túl sok fekete sor a VSYNC után) ?Megnéztem az EXOS LPT -jeivel és az tényleg jó. :oops:
aztán tökkkéletes legyen ám az a gameCsak game demo. Nem game.
nehogy két fekete csík legyen fent meg lentRajta vok.
Megnéztem az EXOS LPT -jeivel és az tényleg jó. :oops:Ha túl hosszú a kép, akkor az extra sorokat az emulátor egyszerűen levágja a kép alján. Azonban ha 40 vagy több sorral hosszabb 312 sornál, akkor fut a kép (ez igazi gépen is így van, de a TV/monitortól függően változik, hogy mikor kezd futni a kép). BASIC-ben egyszerű POKE parancsokkal kipróbálható. :)
Tehát nálam lesz a hiba ... csak tudnám mi ... hát elvileg precízen kiszámolom az egész LPT -t 312 sorra ...
És egyébként, még ha rossz is az LPT -m, a fekete sor miért indokolt ? Valami egyszerűsítés ? Vagy éppenhogy lehet modellezni 312 -nél több soros képeket is az emuban ?
A fekete csíkot a kép tetején az okozza, ha a VSYNC után túl sok a fekete sor. Azaz egészen pontosan több, mint 21 sor az első VSYNC sorral (ahol 0 a video mód és a képnek van aktív - nem keret - része) együtt. Ha a VSYNC előtt van 3-nál több fekete sor, akkor a kép alján jelenik meg fekete csík.Aham ... tehát akkor te nem az LPT össz soraira gondolsz, hogy túl sok (amit azóta teszteltem is, és biztosan 312 sor az LPT össz sorainak száma),
hanem a szinkron után szerinted nem lehetnek "fekete sor" -ok, de az meg mi a mák ? Milyen legyen, fehér ? :)Keretszínű.
Keretszínű.Dehát nekem keretszínű, nem ? Azért van a placeholder LPB -kben gondolom a kicsavart 63,0 keret, nem ?
szinkron:Itt a hiba, mert ez 21 helyett összesen 22 sor. Sőt, valójában 23 lesz fekete (amiből 2 látható a kép tetején a 288 sort megjelenítő emulátoron), mert a margó beállítások miatt a felső keret első sora elveszik. Tehát a 19 soros LPB-t 17-re kell rövidíteni, a felső keret hosszát pedig 2 sorral növelni, és akkor pont eltűnik a fekete csík.
256- 3, D_MB_VideoMode_Vsync, 63, 0, 0,0,0,0,0,0,0,0,0,0,0,0,
256- 2, D_MB_VideoMode_Vsync, 6, 63, 0,0,0,0,0,0,0,0,0,0,0,0,
256- 1, D_MB_VideoMode_Vsync, 63, 32, 0,0,0,0,0,0,0,0,0,0,0,0,
256- 19, D_MB_VideoMode_Pixel|D_MB_Reload, 6, 63, 0,0,0,0,0,0,0,0,0,0,0,0
Itt a hiba,Márpedig én ezt nem magamtól találtam ki:
Márpedig én ezt nem magamtól találtam ki:A TV-k általában jóval többet vágnak le (overscan) a képből, mint az emulátor, így azokon általában nem látszik. De ez változó, Zozosoft monitorán például akár 300 sor is látható lehet megfelelő beállításokkal. Mindenesetre a 26-ról 24 sorra való rövidítés nem lenne probléma igazi gépen, mert például Commodore gépeken csak 18 fekete (blank+sync) sor van összesen.
http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/hardware/Nick.html#10 (http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/hardware/Nick.html#10)
Rossz az EXOS leírás példája ? Vagy ez csak egy emu dolog, vas gépen ez nem hiba ?
A TV-k általában jóval többet vágnak le (overscan) a képből, mint az emulátor, így azokon általában nem látszik. De ez változó, Zozosoft monitorán például akár 300 sor is látható lehet megfelelő beállításokkal. Mindenesetre a 26-ról 24 sorra való rövidítés nem lenne probléma igazi gépen, mert például Commodore gépeken csak 18 fekete (blank+sync) sor van összesen.Hát pedig akkor ezek szerint indokolatlanul sokra adták meg, mégha csak ritkán is jön elő. Tehát ez akkor egy EXOS leírás hibának tekinthető ...
mert például Commodore gépeken csak 18 fekete (blank+sync) sor van összesen.Ebben is jobb a Kommondor. :(
Hát pedig akkor ezek szerint indokolatlanul sokra adták meg, mégha csak ritkán is jön elő. Tehát ez akkor egy EXOS leírás hibának tekinthető ...Ennek csak az mond ellent, hogy mivel az EXOS LPT -knél nem volt felül fekete csík, ezért valószínűleg az EXOS kódjában a jó szinkron sorszámok vannak ... nem ?
, a BRD.ROM viszont az EXOS könyvhöz hasonlóan ezt 26-ra növeli.Ami azt jelenti, hogy ezzel a BRD.ROM -mal megjelenik felül a fekete csík az emuban EXOS képernyőkön is, meg olyan TV -ken, ami elég sok sort meg tud mutatni ?
Ami azt jelenti, hogy ezzel a BRD.ROM -mal megjelenik felül a fekete csík az emuban EXOS képernyőkön isIgen. Csak általában fekete a keret, ezért nem feltűnő. :)
Igen. Csak általában fekete a keret, ezért nem feltűnő. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)Tehát az eredetiek, az angolok, tudták hogy mit csinálnak, és az EXOS úgy van megírva, ahogy kell, de csináltak egy rossz doksit, és a BRD -sek meg már a rossz doksi alapján németesíthettek ?
Ebben is jobb a Kommondor. :(Pont fordítva, nem? Commodore-on csak 18 van, EP-n nekünk több jutott, 26, nekünk több van!
Milyen gáz ez az EP... :(
:)
öööö, hova? és hogy működik? :oops:Igen, ez közérdekű info lenne... :oops:
öööö, hova? és hogy működik? :oops:Már belinkeltem :-)
az, hogy a FILE: eszköz nem működik a HEASS-ban, az emulátor hiba, vagy HEASS hiba?Mit értesz nem működés alatt?
a MERGE parancs nem működikAz a baj, hogy a FILE nem fájlkezelő eszköz :-( (EXOS 10-et nem kezeli)
Gondolom hosszabb a megszakítási rutin...Így van. Meg az is számíthat, pl egy csatorna nyitásnál, ha az EXOS-nak több eszköz között kell keresgélni.
hogyan lehet a debuggerben megmondani, hogy álljon meg egy helyen a futás, hogy kiolvashassam a regiszterek értékeit?A page2-n a jobb felső ablakban. Példák
De ezt hova kell írni?"A művelet végrehajtásához használt alkalmazás"-hoz, azaz például a -snapshot elé (...ep128emu.exe" -no-opengl -snapshot ...).
Esetleg azt meg tudná írni valaki, hogyan lehet teljes képernyőre váltani?F9
Linux alatt valahogy el lehet érni a windowsos ikonokat? Szeretném beállítani az asztalra kitett parancsikonnak rendesen az ikonját....A forráscsomagban a "resource" könyvtárban vannak .ico formátumú ikonok.
Sziasztok!Windowsos ikont sehogy.
Linux alatt valahogy el lehet érni a windowsos ikonokat? Szeretném beállítani az asztalra kitett parancsikonnak rendesen az ikonját....
A SourceForge-on vagy hol volt ez, ott nem találtam csomagot, csak becsomagoltat amit kitömörítettem az /opt/ könyvtárba. Parancsikont cserélni tudom hogyan kell, köszönöm a részletes leírást, csak nem találtam abban a becsomagolt állományban az ikonokat.A Sourceforge-on fent levő forrásarchívumban (ep128emu-2.0.9.tar.bz2) találod.
lehet olyat csinálni a debuggerben, hogy adott helyen megáll a program, és én ott megadhatom, hogy egy portról milyen értéket kéne olvasnia ez EP-nek?A regiszter módosítás egyszerűen megoldható Lua script segítségével. A portról olvasott érték már nehezebb, de az sem lehetetlen. Ott az olvasás utáni utasításra kell átmenetileg töréspontot beállítani, és a regisztert módosítani.
Vagy értéket adni regiszternek?
köszi - nem jött be a módszer... :-)
és azt hogyan lehet beállítani, hogy ha egy bizonyos tartományon kívül van a PC, akkor legyen töréspont?
ha "atlag" Ep usert nezzuk, neki az ep128emu szerintem tobb mint tok jo.A nagy baj az, hogy úgy tűnik Istvánnak nincs már kedve foglalkozni vele :cry: más meg nem ért hozzá :cry: Még egy utolsó ismert-hibák-kijavítva-és-friss-romok-benne verzió se készült el évek óta :cry:
A nagy baj az, hogy úgy tűnik Istvánnak nincs már kedve foglalkozni vele :cry: más meg nem ért hozzá :cry: Még egy utolsó ismert-hibák-kijavítva-és-friss-romok-benne verzió se készült el évek óta :cry:
Hat, ha valaki ki tudja javitani a forrasban, az alapjan csak le lehet forditaniAz megtörtént... csak most úgy néz ki egy ep128emu telepítés:
Az megtörtént... csak most úgy néz ki egy ep128emu telepítés:Akkor egyszerűbb lenne egy service pack készítése az ep128emu-hoz, amiben benne van a javított exe, a javított rom-ok és a konfig file-ok felülírása.
Az megtörtént... csak most úgy néz ki egy ep128emu telepítés:
-töltsd le a telepítőt, és telepítsd fel
-guberáld ki a fórumról a javított EXE-t, és írd felül a régit
-guberáld ki a fórumról és/vagy az ep128.hu-ról minden ROM-nak az újabb verzióját
-az újabb ROM-okhoz javítsd ki majdnem az összes konfig fájlt
Vagy nem tudom, windows alatt eletemben nem telepitettem meg semmit :) tehat lehet en nem ertem, mi itt a gond :DAz, hogy windows alatt a zip az nem telepítés. A telepítő program írja be a konfig fájlokba az elérési utakat, a registrybe a fájlhozzárendeléseket, a start menübe az ikonokat.
Az megtörtént...A forrásban történt a javítás csak és a kész binárisokban nem?
Az, hogy windows alatt a zip az nem telepítés. A telepítő program írja be a konfig fájlokba az elérési utakat, a registrybe a fájlhozzárendeléseket, a start menübe az ikonokat.
A forrásban történt a javítás csak és a kész binárisokban nem?Ott az István által elkövetett hivatalos verzió lenne...
És hol van az a javítás?
Ez az utolsó,amiről tudok:
http://ep128emu.cvs.sourceforge.net/viewvc/ep128emu/ep128emu2/NEWS?revision=1.29&view=markup
nem lehet csinalni egy telepitos izet aztan az egeszbol? Sajat telepitoje van, vagy hogy megy ez?Saját telepítője van, amit István tud csinálni.
Ott az István által elkövetett hivatalos verzió lenne...Ebben ezek vannak:
Itt vannak. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg36039/#msg36039)
debugger.cpp
disk_cfg_fl.cpp
emucfg.cpp
gui.cpp
wd177x.cpp
z80.cpp
z80funcs2.cppSaját telepítője van, amit István tud csinálni.
meg mindig nem ertek valamit. :) Sot, biztos :)Előbb már leírtam, hogy mit csinál a telepítő :-)
http://ep128emu.enterpriseforever.com/roms/ep128emu_roms.binHa ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.
Előbb már leírtam, hogy mit csinál a telepítő :-)
Ha ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.Az.
Lehet, nem jól értem a problémát. Olyat Windows alatt is lehet(ett) csinálni, hogy egy txt fájlba dos parancsokat írunk, amik a romokat a megfelelő helyre másolják kicsomagolás után, és ezt átnevezni BAT fájllá...Jobb híján meg lehetne csinálni batch parancssorozattal is az egészet.
A disk_cfg_fl.cpp régi fájlt nem lelem a letöltött és kicsomagolt forrásban. Ez új?
Kár, hogy a frisebb fluid-al már nem megy az ep128emu.
Saját telepítője van, amit István tud csinálni.
Ha ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.
epcompress -a -m2 -9 @rom_list.txt ep128emu_roms.binAz _fl.cpp/hpp file-okat a FLUID generálja a megfelelő .fl-ből (pl. disk_cfg.fl -> disk_cfg_fl.cpp, disk_cfg_fl.hpp). Tehát a módosítást célszerűbb a forrás .fl-ben végezni.A módosítási patch jól jönne.
Csak FLTK 1.1.x és 1.3.x támogatott, a 2.x nem kompatibilis ezekkel.
En a C++-tol kapok elmebajt, mar ha ranezek akkor is ... Ezert is nem nyultam hozza, es inkabb irtam egy sajatot ... pedig C++-t parszor nekialltam tanulni, de nekem vmi remesen eroltetett/tulbonyolitott cuccnak tunik.
Nem használtam "túlbonyolított" C++-t (pl. template talán egy file kivételével), a hardver emuláció részben gyakorlatilag csak a nyelv alapvető OOP elemei találhatók.
Hasonló felépítésű a plus4emu (http://sourceforge.net/projects/plus4emu/files/) is, amely az emulátor API-hoz C wrappert is tartalmaz, egy egyszerű SDL példa programmal.
Természetesen új emulátor írását éppen az teszi érdekessé, ha mindent újra meg kell valósítani (és közben megfejteni a hardver működését és a nem dokumentált tulajdonságait), és nem csak "újrahasznosítani" már létező régi forráskódot. :)
En mar ezt a namespace stb dolgokat se ertem :)
A plus4emu ezekhez kepest hogy all?
Ebben ezek vannak:Code: [Select]debugger.cpp
disk_cfg_fl.cpp
emucfg.cpp
gui.cpp
wd177x.cpp
z80.cpp
z80funcs2.cpp
A disk_cfg_fl.cpp régi fájlt nem lelem a letöltött és kicsomagolt forrásban. Ez új?
Ezen kívül az összes módosítással készült folttal elkészült a módosított telepítő csomagom UHU-3 -hoz.
Ez a rom még jó?
http://ep128emu.enterpriseforever.com/roms/ep128emu_roms.bin
A disk-cfg.fl -el nem boldogultam, az még hiányzik, Ráadásul a birtokomban lévő disk_cfg_fl.cpp fájl sorvégei windózosak, át kellett alakítanom, hogy lássam a változást az eredi fl fájll által készített fordítási snapshot-hoz képest. A diff ugyanis a sorvégek miatt mind változásnak jelölte. Végre láttam a konkrét változásokat, de nem tudtam rájönni, hogyan is kellene az eredt fl fájlt megváltoztatni, hogy a kívánt cpp jöjjön létre.
A diff ugyanis a sorvégek miatt mind változásnak jelölte.
Win7 alatt hogyan lehet megoldani, hogy dupla kattintással a snapshot file software módban induljon el?Társítanod kell hozzá a Start menübe feltett szoftveres megjelenítéses ikont (szerintem). Ha csak egy felhasználónak elérhető a telepített ep128emu, akkor a C:\Users\_felhasználónév_\AppData\Roaming\Microsoft\Windows\Start Menu\Programs útvonalon kell keresni az ikont. Ha minden felhasználónak elérhető, akkor a C:\Users\All Users\Microsoft\Windows\Start Menu\Programs útvonalon. Ezzel egyenértékű a C:\ProgramData\Microsoft\Windows\Start Menu\Programs elérési út. Természetesen ez függ attól, hogy melyik meghajtóra van telepítve a Windows (tehát C: helyett lehet mást kell írni), illetve ha nem angol a Windows, akkor a Users mappát lehet más néven kell keresni. Ezen felül a ProgramData és az All Users rejtett mappák, ezért be kell kapcsolni az ilyenek megjelenítését.
olyan funkciót nem lehetne az emuba rakni, hogy a hangcsatornák hangerejét külön állítani lehessen? tök jó lenne meghallgatni pár zenét csatornánkéntAzt a hex editorban is ki lehet lőni.
Azt a hex editorban is ki lehet lőni.
Te akarsz lenni az EP-s DJ? :D
van az abyss c. játék zseniális zenéjeCsak ehhez új emulátor funkció? Nem hinném, hogy neked gondot okozna a hex editorból ezt elintézni, 1-2 perc alatt meglenne. Vagy még Lua szkripttel is meg lehetne csinálni szerintem.
Csak ehhez új emulátor funkció? Nem hinném, hogy neked gondot okozna a hex editorból ezt elintézni, 1-2 perc alatt meglenne. Vagy még Lua szkripttel is meg lehetne csinálni szerintem.
hangok kielemzéséhez is hasznos lehet.Akkor már érdemesebb lenne valami programot, rendszerbővítőt vagy tényleg Lua scriptet írni erre. Vagy valami olyat, ami a kottát kiírja, akár midibe. Az poén lenne.
Még a Windows XP-ben volt a mappa beállításainál valami, ahol a társított programokkal lehetett valamit még megadni, de Win7-ben nem is találok ilyet...
Azt hogy lehetne megcsinálni, hogy a snapshot az emulátor software mode-jában nyíljon meg dupla kattintással?Ahogyan IstvanV írja, és ahogy azt már tavaly júliusban én is említettem.
Nekem a laptop nem támogatja az opengl-t, és ha duplán kattintok egy snapshotra, sosem indul el semmi az emuban.
Még a Windows XP-ben volt a mappa beállításainál valami, ahol a társított programokkal lehetett valamit még megadni, de Win7-ben nem is találok ilyet...
miért kell ehhez registry-ben turkálni?Működne az is, ha alapból vinné a gép az opengl módot, ami az emunál az alap.
a file association nem műxik?
nálam szerintem installkor beállította
Nekem a laptop nem támogatja az opengl-tMilyen laptop, milyen VGA-val?
Milyen laptop, milyen VGA-val?Valami ősrégi és kopott, használtan vett, nehéz. :D HP van ráírva. Az eszközkezelő szerint Mobile Intel(R) 965 Express lapkakészletcsalád - WDDM 1.1 a videovezérlő.
Az eszközkezelő szerint Mobile Intel(R) 965 Express lapkakészletcsalád - WDDM 1.1 a videovezérlő.Na akkor szerintem neked is az Intel oldaláról kéne drivert leszedni.
Na akkor szerintem neked is az Intel oldaláról kéne drivert leszedni.Az az emulátor opengl módján kívül másban is érintené a gép működését?
ez vajon mi lehet?
For any of you who do not know what an Archive Bomb is, it is basically an archive file (zip or rar, for example) that when decompressed, it takes up a LOT more space than the original file.
Illetve egy gonddal talalkoztam: Zozo vmi ZIP-et egyszer kuldott a forumra. Abban van egy file, a disk_cfg_fl.cpp
Na ezt nem fogom tudni commit-olni mert ez egy generalt file ... Nem tudom mi lett benne javitva, de ugye abban kene javitani, ami ezt legeneralja - gondolom.
Note that '(null)/.local/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:
- /home/lgb/.local/share
- /usr/local/share/
- /usr/share/
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.Amugy fura az egesz, mert *iszonyat* lassan fordul win ala, ahogy a wine-al hivogatja ugye a cuccosokat. Tehat fluid.exe es gcc.exe egy parancs kb 5-10 perc. Egesz ejjel csinalta, utana meg az installer. Kozben meg neha ilyet mondott:
Nekem nem volt ilyen probléma, bár én X alatt fordítottam, és nem távoli gépen.
A GitHub-ról letöltött aktuális verzió nekem kb. fél perc alatt lefordul. De lehet, hogy azért, mert megelehetősen régi scons, Wine, és MinGW (https://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713) verziókat használtam. :oops: De nem volt DISPLAY hiba sem.
Szerintem is lehetne vegre 2.1 :-)
Azon gondolkodtam, hogy nem lehet megszabadulni a wine-tol? Tehat siman hivnam a i686-w64-mingw32-gcc/g++ -t (Ubuntu alatt csomagbol felteve hogy hijjak szegenyt) ami ugye nativ Linuxos ELF binaris, de windowsra fordit.
De az FLTK-t valószínűleg újra kell fordítani, mert a C++ ABI változhatott néhány év alatt. :)Én csak az ep128emu kedvéért tartok fenn és ápolgatok egy fltk1-1.1.10 csomagot, melyet legszívesebben kihajítanék, szinte hülyére kellett foltozni (https://github.com/uhulinux/ub-3/tree/master/fltk1/patches), hogy leforduljon és használható legyen.
Én csak az ep128emu kedvéért tartok fenn és ápolgatok egy fltk1-1.1.10 csomagot, melyet legszívesebben kihajítanék, szinte hülyére kellett foltozni (https://github.com/uhulinux/ub-3/tree/master/fltk1/patches), hogy leforduljon és használható legyen.
Az új fltk-1.3.3 meg alkalmatlan a mostani állapotú ep128 emuhoz, ehhez Istvánnak kellene átdolgoznia az emu forrását, amihez meg úgy vélem nincs sok kedve.
scons: Reading SConscript files ...
Checking for C++ library jpeg... no
Checking for C++ library png... no
Checking for C++ library z... no
*** error: libjpeg, libpng, or zlib is not found
Persze még előtte lehet, hogy átállok a github forrására, hisz jobb, ha a forrásba már be vannak emelve a legújabb foltok és nem helyben kell barkácsolni.
Csak ki tudja, hogy melyik a stabilabban megmaradó forrás? A forráskovács, vagy a github?
Esetleg 2.0.10 ? 2.1-hez kellene valamilyen új feature is. :)Új feature mehet 2.2-be :-)
#!/bin/sh -eux
celdir="$UB_INSTALLDIR"/usr/share/ep128/
install -d -m 0775 "$celdir"/roms "$celdir"/disk "$celdir"/config
mv ep128emu_roms.bin roms/
cp ep128emu tapeedit "$UB_INSTALLDIR"/usr/bin
cp -r roms config disk "$celdir"
cp makecfg "$celdir"/makecfg.bin
usrbin="$UB_INSTALLDIR"/usr/bin/makecfg
bashstr='#!/bin/bash
if test ! -d ~/.ep128emu/roms
then
mkdir -p ~/.ep128emu/roms
cp /usr/share/ep128/roms/ep128emu_roms.bin ~/.ep128emu/roms
fi
/usr/share/ep128/makecfg.bin'
# bash indító
for sorok in "$bashstr"
do
echo "$sorok" >"$usrbin"
done
chmod +x "$usrbin"LGB!
Kaptál egy PR-t!
;-)
if not win32CrossCompile:
instDir = os.environ["HOME"] + "/bin"
ep128emuEnvironment.Install(instDir, [ep128emu, makecfg, tapeedit])
ep128emuEnvironment.Alias("install", instDir)scons -j 4 installUninstall (az scons -c működik az "install"-on is):scons -c install*Szamomra* ez utobi azert celravezetobb, mert lehetne normalis cross compile win-re, mindenfele wine es egyeb trukk nelkul.
ep128emuLibEnvironment['AR'] = 'wine C:/MinGW/bin/ar.exe'
ep128emuLibEnvironment['CC'] = 'wine C:/MinGW/bin/gcc.exe'
ep128emuLibEnvironment['CPP'] = 'wine C:/MinGW/bin/cpp.exe'
ep128emuLibEnvironment['CXX'] = 'wine C:/MinGW/bin/g++.exe'
ep128emuLibEnvironment['LINK'] = 'wine C:/MinGW/bin/g++.exe'
ep128emuLibEnvironment['RANLIB'] = 'wine C:/MinGW/bin/ranlib.exe'
Ahhoz elvileg csak ezt kellene módosítani (53. sor), és még egy pár helyen egyéb parancsokat ahol a "wine" előfordul (fluid - ez lehet a natív Linuxos verzió, és windres):
win32CrossCompile = ARGUMENTS.get('win32', 0)Az install funkció megvalósítható az SConstruct-ban is, erre egy egyszerű példa (a file végén):Code: [Select]if not win32CrossCompile:
instDir = os.environ["HOME"] + "/bin"
ep128emuEnvironment.Install(instDir, [ep128emu, makecfg, tapeedit])
ep128emuEnvironment.Alias("install", instDir)
Fordítás és telepítés:Code: [Select]scons -j 4 installUninstall (az scons -c működik az "install"-on is):Code: [Select]scons -c install
Természetesen az instDir-t megfelelően módosítani kell, itt ~/bin. Esetleg még a LINKFLAGS kiegészíthető lenne -s opcióval (strip) buildRelease=1 esetén.
Igen, ez tiszta, csak az elmelet es a gyakorlat elmeletben ugyanaz, de gyakorlatban nem, attol felek mar elore
architektura fuggo object file-ok. Magyaran pl zx128vm.cpp mellett ne egy szem zx128vm.o legyen, hanem kulon win32-re, linux-ra stb (ha tobb is van). Ez azert jo, mert nem kell allandoan ujrabuild-elni mindent, ha az ember csinal egy kis vacak modositast, es tesztelne az osszes architekturara.
ep128emuLibEnvironment["OBJSUFFIX"] = "_linux64.o"Így például az src/dave.cpp-ből src/dave_linux64.o lesz.
A legegyszerűbb lenne kipróbálni, ha nem működik, akkor egyelőre marad a Wine. :)
Erre biztosan van megoldás (pl. VariantDir()), bár ezt még nem próbáltam. Nem túl elegáns, de talán még ez is működhet:Code: [Select]ep128emuLibEnvironment["OBJSUFFIX"] = "_linux64.o"Így például az src/dave.cpp-ből src/dave_linux64.o lesz.
Oke, de ettol fuggetlenul az scons nem fogja elolrol kezdeni?
Jó is a scons is installálásra, azt tudom, hisz van egy pár project, mely ezt használja.
Csak nem tudom, hogy nem lehetne e majd egyszerű környezeti változóval definiálni a cél installálási területet anélkül, hogy belerondítanék egy folttal a leendő scons install részbe?
Azt is fel kellne sorolni valahol, hogy milyen fájlokat és hova telepítsen az insDirbe, ahhoz relatívan persze.
Szerintem LGB meg tudná írni a makefilében az install részt linuxokra, az őhozzá még közelebb áll (hozzám is), mint a scons-ba belegyűrni a kívánalmakat.
Én meg csak a kötőszavakat értem abból amit beszéltek :oops:
Ahogy pl a C++ sem jon be, mert nekem a C az a C ahogy isten megteremtette mindenfele plusszok nelkul ... :-/ Az meg mar egyesen elborzaszto, hogy ilyen youtube-os oktato videokban ami C-ben egy sima cast egy tipusra, oda C++-ban odairnak valami fel kepernyosornyi fortelmet, es buszkek ra, hogy megoldottak. Na ezt en mar nem ertem, hogy miert jo ennyire tulbonyolitani szandekosan :)OFF
Ahogy pl a C++ sem jon be, mert nekem a C az a C ahogy isten megteremtette mindenfele plusszok nelkul ...
Nem hiszem, hogy egy Makefile install rész-nek sok köze lenne a C++-hoz.
Ha már az ep128emu a GitHub-ra került, akkor a teljesség kedvéért plus4emu (https://sourceforge.net/projects/plus4emu/files/plus4emu/plus4emu-1.2.9.2/) is lehetne. :) Itt több lehetőség is van a fejlesztésre, például a debugger GUI kissé elavult az ep128emu-hoz képest, viszont ez az emulátor tartalmaz C API-t SDL példa programmal. Nagyobb kihívást jelentene a két emulátort újra egy programba építeni, az ep128emu 2.0 beta verzióhoz hasonlóan.
g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
Compressor_M0::CompressionParameters::CompressionParameters&
^
https://github.com/lgblgblgb/plus4emuMegnézni nem fogom rendesen, de arra panaszkodik, hogy típus helyett egy konstruktor kapott, vagis hogy ezt jelenti a hibaüzenet. Meg lehet próbálni javítani a kifejezés végére '&' jel biggyesztésével, de miután nem néztem meg, fogalmam sincs használ-e?
Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):Code: [Select]g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
Compressor_M0::CompressionParameters::CompressionParameters&
^
https://github.com/lgblgblgb/plus4emu
Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):Code: [Select]g++ -o util/compress/compress0.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DENABLE_GL_SHADERS -DFLTK1 -I. -Isrc -IFl_Native_File_Chooser -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Iutil/compress util/compress/compress0.cpp
util/compress/compress0.cpp:607:3: error: 'Plus4Compress::Compressor_M0::CompressionParameters::CompressionParameters' names the constructor, not the type
Compressor_M0::CompressionParameters::CompressionParameters&
^
Ja, közben a romhalmazt elhelyeztem a gitt forkomba, talán a megfelő helyre és küldem Pull request -et a fő gittbe.A békesség és jogviták elkerülése végett inkább visszacsináltam.
Ez is nélkülözhetetlen a működéshez. Mármint a romhalmaz, amik remélem, hogy már nem jogvédettek.
Így egyedileg fogja majd az esetleges jogvitákat elszenvedni, ha lebukik, hogy jogvédett ROM-ot használ a ROM alkotóinak tudta és engedélye nélkül.Eddig nem sok ROM alkotóról tudok. De például Bruce nem hiszem, hogy mérges lenne ránk emiatt. :D
Így egyedileg fogja majd az esetleges jogvitákat elszenvedni, ha lebukik, hogy jogvédett ROM-ot használ a ROM alkotóinak tudta és engedélye nélkül.Nem az alkotó számít, hanem a jogtulajdonos. Érdekes lenne megpróbálni kinyomozni, hogy mi történhetett a szellemi jogokkal a cég vége után. Gondolom a német vonalon kellene elindulni. Hacsak nem ez már le van írva valahol, csak még nem találkoztam azzal az írással.
Nem az alkotó számít, hanem a jogtulajdonos. Érdekes lenne megpróbálni kinyomozni, hogy mi történhetett a szellemi jogokkal a cég vége után. Gondolom a német vonalon kellene elindulni. Hacsak nem ez már le van írva valahol, csak még nem találkoztam azzal az írással.Fontos dolognak tűnik, ami most kibukott, hisz az emulátorok használhatóságáról van szó.
Legfeljebb a továbbfejlesztett ROM-okat kell betenni, amikben pl. már a Zozosoft-féle memóriateszt van és az Endi-féle villogó EP felirat, esetleg ahelyett valami más, hogy az se hasonlítson az eredetire. A WP amúgy is felejtős, azt pl. le lehet cserélni a HWP-re. A karakterkészletet HFONT-ra, vagy még jobban eltérőre, stb.Ez sem megoldás. Legfeljebb akkor lenne az, ha nem továbbfejlesztettről, hanem újraírt és továbbfejlesztett ROM-ról beszélnénk. Ha ez nem lenne baj, akkor nem ugrana a Tecső, illetve a jogtulajdonos például egy 2-3 másodperces drum loop-ra valami Kraftwerk számból, ami egy C64-es demó esetében például megtörtént.
Ez sem megoldás. Legfeljebb akkor lenne az, ha nem továbbfejlesztettről, hanem újraírt és továbbfejlesztett ROM-ról beszélnénk. Ha ez nem lenne baj, akkor nem ugrana a Tecső, illetve a jogtulajdonos például egy 2-3 másodperces drum loop-ra valami Kraftwerk számból, ami egy C64-es demó esetében például megtörtént.
EP ROM amugy nem hinnem, hogy barkit is zavarna ma mar, de azert egy GNU/GPL emulatorba csak nem raknam *bele* mert igy is olyan hmmm fura erzes :)Ezzel teljesen egyetértek.
https://github.com/lgblgblgb/plus4emu
Csak ugy kivancsisagbol :) Igaz, szokasos C++ elmebajom miatt amugy se mennek sokra ezzel se, nomeg le sem fordul (es otletem sincs mit jelent a hibauzenet):
A fordítási hibák és figyelmeztetések (ezek közül az egyik valóban bug volt :oops:) javítása:
(Attachment Link)
g++ -o p4fliconv -L. -Wl,-Bsymbolic-functions util/p4fliconv/main.o -lp4fliconv -lcompress -lplus4emu -lfltk_images -lfltk_gl -lfltk -lX11 -lz -ldotconf -lpthread
/usr/bin/ld: ./libp4fliconv.a(flidisp.o): undefined reference to symbol 'glOrtho'
//usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
scons: *** [p4fliconv] Error 1
scons: building terminated because of errors.Ha "manualisan" kiadom a fenti g++ sort, egy -lGL vegere biggyesztese mellett, akkor jo. Viszont nem jottem ra, hova kene ezt beirni az SConstruct-ba, talalomra ide-oda beleirtam, ami hasonlonak tunik, de nem segitett ...
Ha csak a p4fliconv hibás, akkor például az 513. sorban lehetne a GL-t hozzáadni a p4fliconvEnvironment-ben a LIBS-hez. Ha az emulátornál is ugyanez a hiba fordul elő, akkor estleg a 85. sornál a plus4emuGLGUIEnvironment-et lehetne kiegészíteni hasonló módon (elvileg az fltk-config kimenetének már tartalmaznia kellene az -lGL-t).
lgb@vega:~$ which fltk-config
/usr/bin/fltk-config
lgb@vega:~$ dpkg -S `which fltk-config`
libfltk1.3-dev: /usr/bin/fltk-config
lgb@vega:~$ fltk-config --version
1.3.3
lgb@vega:~$ fltk-config --libs
/usr/lib/x86_64-linux-gnu/libfltk.a
lgb@vega:~$ fltk-config --ldflags
-Wl,-Bsymbolic-functions -lfltk -lX11
lgb@vega:~$ fltk-config --ldstaticflags
-Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXfixes -lXext -lXft -lfontconfig -lfontconfig -lXinerama -lpthread -ldl -lm -lX11lgb@vega:~$ fltk-config
Usage: fltk-config [OPTIONS]
Options:
[--version]
[--api-version]
Options telling what we are doing:
[--use-gl] use GL
[--use-images] use extra image formats (PNG, JPEG)
[--use-glut] use glut compatibility layer
[--use-forms] use forms compatibility layer
[--use-cairo] use cairo graphics liblgb@vega:~$ fltk-config --use-gl --ldflags
-Wl,-Bsymbolic-functions -lfltk_gl -lfltk -lX11
lgb@vega:~$ fltk-config --ldflags
-Wl,-Bsymbolic-functions -lfltk -lX11
lgb@vega:~$ fltk-config --use-gl --ldstaticflags
-Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk_gl.a -lGLU -lGL /usr/lib/x86_64-linux-gnu/libfltk.a -lXfixes -lXext -lXft -lfontconfig -lfontconfig -lXinerama -lpthread -ldl -lm -lX11
lgb@vega:~$ fltk-config --ldstaticflags
-Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXfixes -lXext -lXft -lfontconfig -lfontconfig -lXinerama -lpthread -ldl -lm -lX11/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command lineattila@gubigep:/usr/src/UHUBUILD/UB-3/ep128emu$ fltk-config --use-gl --ldflags
-Wl,-rpath,/usr/lib -lfltk_gl -lGLU -lGL -lfltk -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11
attila@gubigep:/usr/src/UHUBUILD/UB-3/ep128emu$ Az ubival való összevetésképp felraktam az fltk-dev csomit, ami amúgy nem kell az ep128emu működéshez...
Code: [Select]attila@gubigep:/usr/src/UHUBUILD/UB-3/ep128emu$ fltk-config --use-gl --ldflags
-Wl,-rpath,/usr/lib -lfltk_gl -lGLU -lGL -lfltk -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11
attila@gubigep:/usr/src/UHUBUILD/UB-3/ep128emu$
lgb@vega:~$ fltk-config --use-gl --ldflags
-Wl,-Bsymbolic-functions -lfltk_gl -lfltk -lX11
lgb@vega:~$ fltk-config --version
1.3.3
lgb@vega:~$ fltk-config --use-gl --ldstaticflags
-Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk_gl.a -lGLU -lGL /usr/lib/x86_64-linux-gnu/libfltk.a -lXfixes -lXext -lXft -lfontconfig -lfontconfig -lXinerama -lpthread -ldl -lm -lX11
Az UBUNTU-nak is megvan a maga hülyeséghalmaza, meg az UHU-nak is, meg bármely más disztrónak, még a windózoknak is, ha mélyebben belemászunk és a másik oldalról nézzük, nem a megszokottabbról.
A lényeg, hogy lefordítható, telepíthető és használható legyen az azonos forrásból származó forráshalmaz, jelesül az ep128emu az illető OS változaton.
* SDL (http://www.libsdl.org/) 1.2 for joystick input (optional);
NOTE: on Linux, version 1.2.10 and newer do not work, so using 1.2.9
is recommended
Minek az a sok ico fájl? Nem elegendő a leendő plus4emu.desktop fájlomhoz a Cbm4.ico, amit persze átkonvertálok plus4emu.png fájlra?
Az alábbi patch a következő kisebb módosításokat tartalmazza ...
Különböző ikonok vannak az egyes ablakok számára, a Cbm4.ico az "alapértelmezett" ikonJó jó, de ezek az ikonok (*.ico) a windóz számára készült grafikák.
Linux installáláskor hova kerüljenek, ha kell őket egyáltalán rakni valahova?
Azonban az FLTK 1.3.3-ban újdonság az Fl_Window::icon(const Fl_RGB_Image *) függvény, így megoldható lesz minden rendszeren az ikonok megjelenítése.Hú, ez nagyszerű lenne, hisz amúgyis FLTK 1.3.3 a manapság használt az 1-es sorozatból. (Kivéve régebbi Linuxokat)
#!/bin/sh -eux
IPREFIX="$UB_INSTALLDIR"/usr
BINDIR="$IPREFIX"/bin
DATADIR="$IPREFIX"/share/plus4emu
PIXMAPDIR="$IPREFIX"/share/pixmaps
DESKTOPDIR="$IPREFIX"/share/applications
#célkönyvtárak
mkdir -p "$BINDIR" "$PIXMAPDIR" "$DESKTOPDIR" "$DATADIR"/{roms,disk,config}
#ico fájlok konverziója
for i in `ls -1 resource/*.ico`;do
convert $i $PIXMAPDIR/$(basename $i .ico).png
done
cp plus4emu "$BINDIR"/plus4emu.bin
cp tapconv "$BINDIR"/
cp makecfg "$BINDIR"/plus4makecfg
cp plus4emu "$BINDIR"/plus4emu.bin
cp -r roms config disk "$DATADIR"/#!/bin/bash
#/usr/bin/plus4emu
if test ! -d ~/.plus4emu/roms
then
mkdir -p ~/.plus4emu/roms
cp /usr/share/plus4emu/roms/* ~/.plus4emu/roms/
plus4makecfg
fi
plus4emu.bin[Desktop Entry]
Type=Application
Name=plus4emu
Comment=CBM+4 emulator
Comment[hu]=Commodore+4 emulátor
Exec=plus4emu
Icon=Cbm4
Categories=Game;Emulator;
A makecfg-ep128emu.bin -t akartam futtatni, de szegmetációs hibával kilép! Nem jelenítette meg az fltk beállító ablakot.
gdb -ben is futtattam, de glibc valamire hivatkozott a szegmenshibánál, feladtam.
lgb@vega:~$ pkg-config --cflags lua53
-I/usr/include/lua5.3
lgb@vega:~$ pkg-config --cflags lua52
-I/usr/include/lua5.2lgb@vega:~$ lua-config --include
-I/usr/include/lua50Az Fl_Native_File_Chooser::show() száll el, amit a makecfg.cpp az 1349. sorban hív. A file választó ablak az FLTK 1.3.3 verzióban GTK alapú lett Linuxon, tehát itt lehet valamilyen változás vagy hiba. De az emulátornál nincs ilyen probléma, ott működik az Fl_Native_File_Chooser.
Az okozhatja a hibát, hogy a makecfg-ben nincs másik ablak ennek a megjelenítése előtt, talán erre a lehetőségre még nem készítették fel az új változatot. :) Ha a "Select installation directory..." előtt megjelenítek egy tetszőleges FLTK ablakot, akkor már nincs hiba.
attila@gubigep:/usr/src/UHUBUILD/UB-3/ep128emu/addons/usr$ gdb makecfg-ep128emu.bin
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-uhu-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from makecfg-ep128emu.bin...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/makecfg-ep128emu.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb65f6b40 (LWP 28020)]
[New Thread 0xb5bffb40 (LWP 28021)]
[New Thread 0xb51ffb40 (LWP 28022)]
[New Thread 0xb47ffb40 (LWP 28023)]
Program received signal SIGSEGV, Segmentation fault.
0xb7d4b0b5 in XEventsQueued () from /usr/lib/libX11.so.6
(gdb) backtrace
#0 0xb7d4b0b5 in XEventsQueued () from /usr/lib/libX11.so.6
#1 0xb7f5cd62 in Fl_GTK_File_Chooser::fl_gtk_chooser_wrapper() () from /usr/lib/libfltk.so.1.3
#2 0xb7f5cf66 in Fl_GTK_File_Chooser::show() () from /usr/lib/libfltk.so.1.3
#3 0xb7f5d702 in Fl_Native_File_Chooser::show() () from /usr/lib/libfltk.so.1.3
#4 0x0804a4f4 in ?? ()
#5 0xb79dd5ac in __libc_start_main () from /lib/libc.so.6
#6 0x0804bf81 in ?? ()
(gdb) A pkg-config --cflags --libs lua mit ír ki ? Az újabb (5.2 és 5.3) Lua verziókkal kompatibilitási problémák is előfordulhatnak.
Package lua was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua' foundlgb@vega:~$ pkg-config --cflags --libs lua-5.3
-I/usr/include/lua5.3 -llua5.3
lgb@vega:~$ pkg-config --cflags --libs lua-5.2
-I/usr/include/lua5.2 -llua5.2
Ja, hogy azt nezne?
Az ablakkeretben az ikonok nem jelnnek meg GNOME, MATE, ICEWM, LXQT alatt, ellenben fluxbox, kwin (KDE4), openbox ablakkezelőknél igen.
Csatolok pár képernyőképet a fluxbox alól, amelyekben változást tapasztaltam a menüben megjelenő ikonokat illetőleg.
A makecfg problémák javítására Linuxon a régi FLTK file választó ablakot (Fl_File_Chooser) fogom használni, azzal nincs hiba FLTK 1.3.3 esetén sem.
Ellenben az ep128emunál nem így van, ott mindig a zöld E betűs ikon van minden ablaknál.
scons: done reading SConscript files.
scons: Building targets ...
fluid -c -o gui/debug_fl.cpp -h gui/debug_fl.hpp gui/debug.fl
g++ -o gui/about_fl.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -DHAVE_DOTCONF_H -DHAVE_SDL_H -DHAVE_LUA_H -DENABLE_GL_SHADERS -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I. -Isrc -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Igui gui/about_fl.cpp
In file included from gui/gui.hpp:35:0,
from gui/about_fl.cpp:3:
src/script.hpp:29:19: fatal error: lua.h: No such file or directory
compilation terminated.
scons: *** [gui/about_fl.o] Error 1
scons: building terminated because of errors.Checking for C header file lua.h... (cached) no
Egy apróság, ha meg lehetne oldani: a Spectrum meg CPC emu használjon saját kiterjesztéseket snapshot meg demo mentéshez, és ezek legyenek megfelelően társítva. Mert most ezekben is EP-s néven van a mentés, de betöltéskor az ep128emu mód indulna, ami persze kifagy :-)
b) verzió ha az emu felismerné a fájlból, hogy milyen mód kell
Pedig meg sem talalta:Code: [Select]Checking for C header file lua.h... (cached) no
Valamit elvileg talált, ha a HAVE_LUA_H definiálva van. A pkg-config teszt eredménye lenne érdekesebb, és esetleg a config.log file.
Checking for C header file lua.h... noscons: Configure: Checking for C header file lua.h...
.sconf_temp/conftest_10.c <-
|
|#include "lua.h"
|
|
gcc -o .sconf_temp/conftest_10.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -I. -Isrc -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 .sconf_temp/conftest_10.c
.sconf_temp/conftest_10.c:2:17: fatal error: lua.h: No such file or directory
compilation terminated.
scons: Configure: no
for pkgName in ['lua-5.1', 'lua51', 'lua', 'lua52']:gcc -o .sconf_temp/conftest_11.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DHAVE_STDINT_H -I. -Isrc -I/usr/local/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm .sconf_temp/conftest_11.c
.sconf_temp/conftest_11.c:2:17: fatal error: lua.h: No such file or directory
compilation terminated.
lgb@vega:~$ pkg-config lua-5.1 --cflagsEzért nem leli, mert ubinál az 5.1 is el van szeparálva egy külön lua5.1 mappa alá, nem közvetlen a /usr/include alatt van.
-I/usr/include/lua5.1
Ennek ellenere tovabbra is leakad, hogy nincs lua.h, pedig igy tenyleg probalnia sem kene ...
if not haveLua and sys.platform[:5] == 'linux' and not win32CrossCompile:
for pkgName in ['lua-5.1', 'lua51', 'lua']:
try:
if not plus4emuLibEnvironment.ParseConfig(
'pkg-config --cflags ' + pkgName):
raise Exception()
except:
continue
luaPkgName = pkgName
haveLua = 1
breakTehát arról kellene többet tudni, hogy itt pontosan mi történik.plus4emuGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
plus4emuGLGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGLGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
Na, ez a rész nekem szinte kínai.
Szerk.: az okozhatja a hibát, hogy ez a rész (276. sor) nem másolja a CPPPATH-t, a ParseConfig() pedig ahhoz adja hozzá az /usr/include/lua5.1-et. :oops:Code: [Select]plus4emuGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
plus4emuGLGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGLGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
--- a/SConstruct
+++ b/SConstruct
@@ -277,6 +277,9 @@ plus4emuGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
plus4emuGLGUIEnvironment['CCFLAGS'] = plus4emuLibEnvironment['CCFLAGS']
plus4emuGLGUIEnvironment['CXXFLAGS'] = plus4emuLibEnvironment['CXXFLAGS']
+plus4emuGUIEnvironment['CPPPATH'] = plus4emuLibEnvironment['CPPPATH']
+plus4emuGLGUIEnvironment['CPPPATH'] = plus4emuLibEnvironment['CPPPATH']
- a lua.h hiba remélhetőleg javítva, és nincsenek hibaüzenetek sem a nem talált csomagok miatt; talán érdemes lenne azonban az újabb Lua verziókat is keresni
diff -Nur orig/SConstruct mod/SConstruct
--- orig/SConstruct 2016-08-12 08:20:42.000000000 +0200
+++ mod/SConstruct 2016-08-12 09:11:54.967325322 +0200
@@ -260,7 +260,7 @@
haveLua = haveLua and configure.CheckCHeader('lauxlib.h')
haveLua = haveLua and configure.CheckCHeader('lualib.h')
if not haveLua and sys.platform[:5] == 'linux' and not win32CrossCompile:
- for pkgName in ['lua-5.1', 'lua51', 'lua']:
+ for pkgName in ['lua-5.1', 'lua51', 'lua52', 'lua']:
print 'Checking for Lua package ' + pkgName + '...'
try:
if not plus4emuLibEnvironment.ParseConfig(src/script.cpp: In member function 'void Plus4Emu::LuaScript::registerLuaFunction(lua_CFunction, const char*)':
src/script.cpp:651:28: error: 'LUA_GLOBALSINDEX' was not declared in this scope
lua_setfield(luaState, LUA_GLOBALSINDEX, name);
^
src/script.cpp: In member function 'virtual void Plus4Emu::LuaScript::loadScript(const char*)':
src/script.cpp:771:28: error: 'LUA_GLOBALSINDEX' was not declared in this scope
lua_getfield(luaState, LUA_GLOBALSINDEX, "breakPointCallback");
^
scons: *** [src/script.o] Error 1
scons: building terminated because of errors.István!
Ha már ilyen jól sikeredett linuxhoz a plus4emu scons install része, nem lehetne az ep128emu -ba is beletenni egy ilyesmit?
;-)
Ezt valóban tervezem, a következő patch remélhetőleg már tartalmazni fogja.Gondolom LGB már alig várja már, hogy írási jogot adhasson neked az emulátorok tárolóira, hisz a TE projected valamennyi, továbbá jóval egyszerűbb lenne, ha a változtatásaidat egyszerűen oda committolnád.
Gondolom LGB már alig várja már, hogy írási jogot adhasson neked az emulátorok tárolóira, hisz a TE projected valamennyi, továbbá jóval egyszerűbb lenne, ha a változtatásaidat egyszerűen oda committolnád.
Ekkor nem kellene neki letöltögetve a foltokat neki committolnia.
Én nagyon megkedveltem a githubot, már többször volt, hogy megdolgoztattam, vagy segítettem egyes projectek tulajdonosait.
Például itt egy magyarításom az lxqt-about (https://github.com/lxde/lxqt-about/pull/11/commits/3f9712727657868226bad69f4bb5567145e67eb2) forrásához, melyet azóta belevettek a fejlesztők, így manapság már az lxqt-about például UBUNTU alatt is magyarabb.
Ez megoldható, bár nem tudom, melyik megoldást lenne érdemesebb választani.Szerintem a kiterjesztés legyen más, és a megfelelő emuhoz legyen társítva. Mégis jobb, ha már ránézésre tudjuk a kiterjesztésből, ikonból is, mi az pontosan.
Ez egyelőre még patch :oops:, de az installer részt beépítettem az ep128emu-nál is az SConstruct-ba. Az "installer/ep128emu" file indítja az emulátort, ha csomag készül, ezért ennek futtathatónak kell lennie. A ROM csomag letöltéséhez a curl-t használja.
diff -Nur orig/SConstruct mod/SConstruct
--- orig/SConstruct 2016-08-12 21:34:11.000000000 +0200
+++ mod/SConstruct 2016-08-12 21:53:51.886114783 +0200
@@ -581,9 +581,7 @@
"resource/eptapeedit.desktop",
"resource/zx128.desktop"])
makecfgEnvironment.Command(
- instROMDir + "/ep128emu_roms.bin", None,
- ['curl -o "' + instROMDir + '/ep128emu_roms.bin" '
- + 'http://ep128emu.enterpriseforever.com/roms/ep128emu_roms.bin'])
+ instROMDir + "/ep128emu_roms.bin", None, [])
if not buildingLinuxPackage:
makecfgEnvironment.Command(
instROMDir + "/exos232uk.rom",#!/bin/sh -eux
scons install
cp ep128emu_roms.bin ${UB_INSTALLDIR}/usr/share/ep128emu/roms/Már megint a romhalmaz problematika...
A plus4emu GPL forrásában benne vannak az illető ROM -ok. Az ep128emu forrásából most hiányoznak.
A plus4emu romjainak licenszeiről halvány lövésem sincs.
Istvan: amugy, ha erdekel, es van github accod, akkor megoldhatjuk tenyleg, vagy azt, hogy adok iras jogot, vagy azt, hogy atadom neked a repokat, elvileg lehet olyat.
Módosítom az "ep128emu" scriptet, hogy letöltse a ROM csomagot ha nem található, az SConstruct pedig nem használja a curl-t, ha csomag készül.Szerintem ez jó megoldás lesz, kikerüli a licensz problémát, és első futtatáskor remélhetőleg lesz a júzer rendszerén elérhető curl parancs, meg működő rom url.
Istvan: amugy, ha erdekel, es van github accod, akkor megoldhatjuk tenyleg, vagy azt, hogy adok iras jogot, vagy azt, hogy atadom neked a repokat, elvileg lehet olyat. Persze, te is konvertalhatod SF-rol, mondjuk nem volt egyszeru, nem emlekszem melyiknel, az egyik project-nel sima github import tool megette az svn url-t sf-rol, a masiknal viszont cvs-be leszedtem aztan vadasztam konvertalo tool-t ami tud belole git repot csinalni minen commit history-val, aztan csak change origin kellett kb.
Amugy ez a ROM licenc kerdes, felig elmeleti, felig gyakorlati is. Attus pl nem egyszer mondta, hogy UHU build kornyezet igy meg ugy ... Volt arrol is szo, hogy nem illik build kornyezetben halozatrol huzni valamit stb. Viszont ha mar ilyen generic megoldas kell, akkor ilyen elven az is erv, hogy mas disztribek meg nem tesznek binary blob-ot csomagokba, max kulon csomagba a non-free szekcioban pl Debian eseten, igy valojaban van pl az emu egy csomag, meg _esetleg_ a ROM-ok egy masikban. En csupan filozofiai megfontolasbol azon az allaspont vagyok, hogy lehetoleg legyen minnel jobban distrib fuggetlen a megoldas. Persze lehet UHU-only compatible is az "installer" v csomag build resz, nem kotekedni akarok, csak valahogy nem erzem a ROM-okat szerves reszenek a dolognak egy emulator eseten sem ...Ha külön van a non-free szekciójú csomagok közt egy szeparált rom csomag, arra is vonatkozik a licenc kérdés. Ráadásul, az emulátorok bináris ROM függők, análkül működésképtelenek, ezért úgy tisztességes Debian esetén is, hogy belerámolja a deb csomag depends leírójába a nonfree ROM csomagot is, ezáltal csak álcázva az egészet.
pkgname=ep128emu
pkgver=2.0.9.1
pkgrel=1
pkgdesc="Enterprise128 Emulator"
arch=('i686' 'x86_64')
license=('GPL')
url="http://ep128emu.enterpriseforever.com/"
depends=('fltk' 'lua' 'dotconf' 'glu' libjpeg' portaudio' fontconfig')
makedepends=('scons')
source=("https://github.com/istvan-v/ep128emu/archive/ master.zip"
build() {
scons
}
package() {
export UB_INSTALLDIR="${pkgdir}"
scons install
}Ha külön van a non-free szekciójú csomagok közt egy szeparált rom csomag, arra is vonatkozik a licenc kérdés. Ráadásul, az emulátorok bináris ROM függők, análkül működésképtelenek, ezért úgy tisztességes Debian esetén is, hogy belerámolja a deb csomag depends leírójába a nonfree ROM csomagot is, ezáltal csak álcázva az egészet.
nyugta után elhagynia a terepet.Nyugtával kell dicsérni a napot! :D
Töröltem én is az ep128emu forkomat, hogy ne zavarjon.
Istán megengedte, van írási hozzáférésem a repóihoz, így nem sok értelme volt már a forkomnak.
Egyet módosítottam az ep128 wrapperen pár napja, most már Istvánnál pattog a labda.
Aham, max leforkolom majd Istvanet, ha kellene, bar sok ertelme nincs, ha en is tudok bele irni mar eleve, marmint az ovebe :) Nekem ugy tunt logikusnak, hogy legyen o az upstream, csak azert mondtam. A masik, hogy ha mar nem kell, a Makefile bozalmamat nyugodtan lehet am torolni, felesleges/zavaro is adott esetben ...Ha van hozzá jogod, letörlöd a Makefile csinálmányod, ha nincs, akkor én. Engem nem zavar. :cool:
A nagy fordítási és patch roham után mi a helyzet, különös tekintettel az egyszerű mezei Windows-os felhasználók számára? :oops:Erről (https://bintray.com/lgblgblgb/generic/ep128emu) a címről van egy csapat letölthető kész exe fájl.
Erről (https://bintray.com/lgblgblgb/generic/ep128emu) a címről van egy csapat letölthető kész exe fájl.Van ott egy exe, meg egy beta exe...
Van ott egy exe, meg egy beta exe...Szerintem ezek az exe fájlok, melyek a bintray -on vannak mindent tartalmaznak, mert a legfrisebb forrásból készültek most 4 napja.
De egy szép install verzió kéne, hogy megszűnjön az a sok éves helyzet, hogy töltsd le a 2.0.9-et, aztán töltsd le friss exe-t, és írd felül a telepített verzióban...
Erről (https://bintray.com/lgblgblgb/generic/ep128emu) a címről van egy csapat letölthető kész exe fájl.
Gondolom, ezek minden újítást, foltot satöbbi tartalmaznak, mellyel LGB ezeket legyártatta.
Nekünk, linuxosoknak meg marad a saját fordítás a gitgub forrásból. Vagy abból a disztrónak megfelelő telepíthető csomag készítése.
Csak a kerdes, hogy megeri-e 10 kulonbozo Linux ala build-eltetni mindig, ez megint az a kerdes, hogy ez nem eppen az upstream dolga lenne, ha nem a distributore :)
Egyáltalán nem éri meg, mert nem 10, hanem nagyságrendileg több Linux megvalósítás is létezik.
LGB?
ilyen filter nem lesz valamelyik emuban? különféle konzol emulátorokban divatos. a lényege hogy úgy mossa el a képet hogy igazából éles marad. (photoshopban noise: median)
pl ez gba emuból van:
http://www.somebits.com/~nelson/weblog-files/centerimages/hq3x.png
vagy ez:
http://www.gamesetwatch.com/depixelizingpixels.jpg
Hat nem tudom, nem lenne egyszeru. Eleve legalabbis Xep128-ban egy EP pixel az egy textura pixel. Ehhez jobb felbontasu textura kene ---> performancia a toredekere esne. Amugy erdekes cucc, bar kicsit "futurisztikus" egy 8 bites gepre ranyomni, de teny, hogy erdekes ...
hát én kb 15 éve is így játszottam gba játékokkal :)
Lehet, mondjuk nem neztem meg, mi az algoritmus stb :) Bar most rakerestem, GBA az 260*140 felbontas, azert ott egyszerubb, EP emuk eseten ugye a textura meret a legnagyobb lehetseges felvontas szoval olyan tudomisen 736-szor tudomisen kb 600 pixel (ha interlaced).
gpu-n is mehet ez gondolom, és szerintem nem túl bonyolult filterek ezek
itt van több jó kép meg forrás
http://www.scale2x.it
"Scale2x is real-time graphics effect able to increase the size of small bitmaps guessing the missing pixels without blurring the images."
"SMALL bitmaps" :) Ep-je nem az, a GBA-je tenyleg kicsi :) Ha ezt meg tovabb noveleg ~1400 pixeles lesz a textura, bele sem fer par monitorra az emulator ablak :-P Aztan scaling-el lehet osszenyomni az eredmenyt hogy elferjen, na ez is fura lenne igy egyutt :D
hát ha a 15 évvel ezelőtti pc-m bírta a gba felbontást, nem hinném hogy gond lenne egy ep egy mai gépnek :) főleg gpu-val
hát nyilván nem hires 2 módra nyomja rá az ember ezt az effektet :)
de azon kívül mindenre :D
szerintem te nem érted ezt a filtert...
Van ott egy exe, meg egy beta exe...
De egy szép install verzió kéne, hogy megszűnjön az a sok éves helyzet, hogy töltsd le a 2.0.9-et, aztán töltsd le friss exe-t, és írd felül a telepített verzióban...
Ep128emu-ban lehet - passzolom - mivel OpenGL ha hasznalva van ...
Akkor magyarazd el kerlek :) En a forraskodot is megneztem stb. Ez persze nem jelenti azt, hogy meg is ertettem, es helyesen, az is igaz :)
A gond ott van, hogy EP-n lehetseges, hogy nem egyseges a pixelsurruseg, ugymond, pl a kepernyo fele ilyen felbontasu, a masik olyan.A téma "szakértőjeként" :D hozzászólok. Ha arra gondolsz, hogy több, eltérő felbontású videolap is van a képernyőn: azok általában nem érintkeznek egymással. Nem tudom, a játékok, demo programok stb. mit használnak, használnak-e ilyen képernyőket. Kivéve az Iview képeket, de ott is a paletta változhat soronként, ott sincs olyan tudtommal, hogy a kép egy része attribútum módú, másik része 4 szín módú, harmadik része 2 szín módú.
A téma "szakértőjeként" :D hozzászólok. Ha arra gondolsz, hogy több, eltérő felbontású videolap is van a képernyőn: azok általában nem érintkeznek egymással. Nem tudom, a játékok, demo programok stb. mit használnak, használnak-e ilyen képernyőket. Kivéve az Iview képeket, de ott is a paletta változhat soronként, ott sincs olyan tudtommal, hogy a kép egy része attribútum módú, másik része 4 szín módú, harmadik része 2 szín módú.
Nem tudom, ez a probléma konkrétan milyen programoknál jelentkezne.
UI.: Miért jó, hogy van külön EP128emu és külön EP128emu 2.0.9 topik?
Szerk.: egy hibát már találtam: a hang újra engedélyezése (pl. Alt+W után) az emulátor elszállását eredményezi. :( Talán a régi PortAudio DLL file használatával ez nem fordul elő?
Na igen, de erre mondtam, hogy az altalanos algoritmus EP-n kicsit bonyibb vagy egysegesen a "renderelt emu screen-re" kene alkalmazni es nem tulbonyolitani.Szerintem opcióként be lehetne építeni, legfeljebb ritkán vagy sose lesz használva. Viszont abból a szempontból, hogy "na, ilyet is csináltam már" lehetne érdemes foglalkozni vele annak akit érdekel. Természetesen csak egyszerű módon, a maximális EP felbontású emulátor képernyő pufferen kellene futtatni, akkora erőfeszítést valószínűleg nem ér meg, hogy felbontástól függően adaptívra legyen továbbfejlesztve.
Amugy van annak azert letjogosultsaga amit Endi emleget itt, csak altalanos emulnal - en szemely szerint - kicsit furcsalom (ott meg csak-csak ahol amugy az emulalt gep felbontasa tenyleg "picike" mar eleve). Viszont lehetne belole jo jatekkonverziokat csinalni nativ platformra jobb grafikaval :-P
Szerintem opcióként be lehetne építeni, legfeljebb ritkán vagy sose lesz használva. Viszont abból a szempontból, hogy "na, ilyet is csináltam már" lehetne érdemes foglalkozni vele annak akit érdekel. Természetesen csak egyszerű módon, a maximális EP felbontású emulátor képernyő pufferen kellene futtatni, akkora erőfeszítést valószínűleg nem ér meg, hogy felbontástól függően adaptívra legyen továbbfejlesztve.
Na, meg lassan kopogtat a "4k forradalom" ;) is, manapság már kezdenek az emészthető ársáv közelébe ereszkedni a QHD monitorok, és ha valakinek 4k, 5k, vagy neadj' isten 8k képernyőre is futja, az futtathassa már simított skálázással az EP emulátorokat. :D
LUA-nál be lehetne tenni olyan memória írás parancsot ami a ROM-ba is tud írni? Ezzel egyszerűen megoldódna a Spectrum ROM lapozási kérdésem :-)
Elvileg megoldható, bár egyszerűbb lenne egy loadROMSegment() függvényt (ROM file betöltése a megadott szegmensre) megvalósítani, ezt ugyanis az emulátor már tartalmazza, csak nincs Lua változata.Ez jó lenne, ebben az esetben nem is kéne LUA tömbökkel bajlódni.
Az is könnyen megoldható lenne, hogy a writeMemoryRaw() írni tudjon ROM szegmensekbe is, de ez elronthatna scripteket amelyek feltételezik, hogy a ROM nem írható.Valami más néven berakni a módosított verziót? Ezzel különböző illesztőket lehetne emulálni (pl SpeccyDOS), amik memórián keresztül végzik az I/O-t.
* a különböző segédprogramok hozzáadása a csomaghozEz jó ötlet. Így könnyebb lenne megtalálni mindet. Nekem összevissza kallódnak pl. az epimgconv, ide is letöltöttem, oda is, és sose találom. Jó lenne mind egy helyen, nagy helyet úgyse foglalnak.
:) :) Jo, mondjuk ebben az esetben mar tenyleg lehet benne racio :)Lehet, nem lenne rossz, de érdemesebb a fontosabb fejlesztésekre koncentrálni szerintem. Bár kinek mi fontos. :D (Mármint a pixelesség simítós kütyüre gondoltam.)
Lehet, nem lenne rossz, de érdemesebb a fontosabb fejlesztésekre koncentrálni szerintem. Bár kinek mi fontos. :D (Mármint a pixelesség simítós kütyüre gondoltam.)
Ez jó lenne, ebben az esetben nem is kéne LUA tömbökkel bajlódni.
Valami más néven berakni a módosított verziót? Ezzel különböző illesztőket lehetne emulálni (pl SpeccyDOS), amik memórián keresztül végzik az I/O-t.
Mindkét megoldás már megtalálható a GitHub verzióban:Jól hangzik!
Néhány további lehetséges ötlet a fejlesztésre:Nem tudom, hogy ez mennyire lenne hasznos. No, mondjuk hízna egy kicsit tőle az emulátor, de ez menapság senkit nem zavarna.
* a dotconf beépítése az emulátor forráskódjába, mivel több éve nem változott, talán nem valószínű, hogy új verziók miatt elavulna, és kevesebb lenne a függőség
* a különböző segédprogramok hozzáadása a csomaghoz, hasonlóan a plus4emu-hoz, például (nem tudom, ezek közül melyik lenne hasznos):Nem tudom, de szerintem ezek küzül be lehetne építeni egy párat, legalább egybe lenne az egész cucc.
- epimgconv
- epcompress
- dtf
- epsndconv
- epvideoconv
- cpccolor
* Win64 verzió fordításaEz szerintem a windózos használókat tekintve nagyon hasznos és hiánypótló lenne.
* Lua 5.3 használata: nem biztos, hogy teljesen kompatibilis az eddigi 5.1-el, viszont hasznos újdonságokat is tartalmaz, például a bináris műveleteket (AND, OR, XOR, stb.) a nyelv részeként tartalmazza, azaz például az AND(a, b) helyett a & b lenne használható, ami nem csak elegánsabb, de gyorsabb is. Azonban a LuaJIT csak az 5.1-et támogatjaMegfontolandó, hogy hány olyan rendszer lehet még, ahol csak a lua 5.1 az elérhető és a teljes lua 5.3 -ra történő átállás mennyiben tenné lehetetlenné azokon az emu használatát?
Jól hangzik!
EXE-t merre találok? :oops:
Jól hangzik!
EXE-t merre találok? :oops:
Mindig csak ezek az EXE-k :D Hozzavagtam a travis/bintray duohoz, hogy jo-e ... passz:Majd Zozo megmondja, hogy milyen!
https://bintray.com/lgblgblgb/generic/ep128emu
Ez már remélhetőleg javított PortAudio verziót tartalmaz
Mindig csak ezek az EXE-k :D Hozzavagtam a travis/bintray duohoz, hogy jo-e ... passz:Viszont ez működik! :-) Érdekes, hogy más is az EXE mérete, mint az István féle verzióban.
https://bintray.com/lgblgblgb/generic/ep128emu
Viszont ez működik! :-)
Viszont ez működik! :-)
Akkor ez a MinGW csomagommal lehet valamilyen probléma, talán ideje lenne az egészet újabbra cserélni. :oops:
- writeROM(), writeWordROM() - ezek hasonlóak a "Raw" függvényekhez (22 bites cím), de bármilyen típusú memóriába tudnak írni ha a szegmens érvényes; a nevek talán lehetnének jobbak iswriteROM(0,0) után INTERNAL CHECKSUM ERROR lesz resetnél :-) szóval működik.
Szerintem en is azzal nyomtam travis-on :-P https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/mingw-win.7z
Nem értem.
:oops:
Ezt a foltot (https://github.com/istvan-v/ep128emu/commit/6277d32dc1e9c621632af38744c2d53964438f34) hol és miképp kell alkalmazni az emulátorhoz?
ezek amúgy most mik? új verzió, amiben van valami új?
A segédprogramoknál is van újabb CPU-kra optimalizálás?
Egy csomagon belül minden program ugyanazzal a fordítóval és fordítási paraméterekkel készült, tehát például a fenti x86 installerben az epimgconv is Pentium 2 kompatibilis CPU-t tételez fel (azaz nem használ SSE-t), az x64-esben viszont az epimgconv is 64 bites és elvileg használ SSE-t és SSE2-t.Szerintem az sse2 utasításkészlet manapság már általános követelmény és tudják is a mostani CPU-k. A pentium2 kompatibilitást nyugodtan el lehetne felejteni a 32 bites esetében is, a pentium4 az alap manapság ott is.
Szerintem en is azzal nyomtam travis-on :-P https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/mingw-win.7z
Ezzel, de szerintem ez meg az, amit te adtal. A forditas "kimenete" (az elejen levo gcc ize az mind1, azt meg a travis mondja):
https://travis-ci.org/lgblgblgb/ep128emu/jobs/157955734
Szerintem ki lehetne nyugodtan irtani az leendő újabb release -nál a Pentium2 kompatibilitást.
Valóban, bár az újabb gépeken egyébként is célszerűbb a 64 bites csomagokat használni, a 32 biteseknél a kompatibilitás a cél.Linux esetén viszont a 64 bites használata szinte semmilyen előnnyel nem bír a 32 bitesekkel szemben, a 64 bites biárisok használata a windows rendszereknél jelenthet csak előnyt, tudtommal a memóriaelérés miatt.
Linux esetén viszont a 64 bites használata szinte semmilyen előnnyel nem bír a 32 bitesekkel szemben, a 64 bites biárisok használata a windows rendszereknél jelenthet csak előnyt, tudtommal a memóriaelérés miatt.
int foo = 1;
int testfunc(int bar)
{
return foo * bar;
}
gcc -m32 -Wall -O2 -fPIC -c test.c -o test.o ; objdump -d -M intel test.o
Disassembly of section .text:
00000000 <testfunc>:
0: e8 fc ff ff ff call 1 <testfunc+0x1>
5: 81 c1 02 00 00 00 add ecx,0x2
b: 8b 44 24 04 mov eax,DWORD PTR [esp+0x4]
f: 8b 91 00 00 00 00 mov edx,DWORD PTR [ecx+0x0]
15: 0f af 02 imul eax,DWORD PTR [edx]
18: c3 ret
Disassembly of section .text.__x86.get_pc_thunk.cx:
00000000 <__x86.get_pc_thunk.cx>:
0: 8b 0c 24 mov ecx,DWORD PTR [esp]
3: c3 ret
gcc -m64 -Wall -O2 -fPIC -c test.c -o test.o ; objdump -d -M intel test.o
Disassembly of section .text:
0000000000000000 <testfunc>:
0: 48 8b 15 00 00 00 00 mov rdx,QWORD PTR [rip+0x0] # 7 <testfunc+0x7>
7: 89 f8 mov eax,edi
9: 0f af 02 imul eax,DWORD PTR [rdx]
c: c3 retA memória az emulátornál nem probléma, mivel lényegesen kevesebbet használ 2 GB-nál. :) A gyorsulás ugyan nem sok, de jobb a semminél, és ha valaki 64 bites rendszert használ, akkor általában nem sok értelme van a 32 bites binárisokat futtatni (nagyobb programoknál esetleg előny lehetne a kisebb memóriaigény).
Hogy 5-10 %-al gyorsabb legyen az UHU, a mintegy 6000 darab 32 bites binárisát kellene 64 bitesre fordítani és összecsiszolni.
Megéri, vajh?
Néhány EnterMice (http://wiki.enterpriseforever.com/index.php/EnterMice) kérdés: :oops:
- az elmozdulásoknál (X és Y) milyen érték felel meg 1 legnagyobb felbontású (2 színű PIXEL interlace módban) pixelnek "normál" érzékenységnél ?
- az elmozdulás az utolsó olvasáshoz képesti pozíció eltérés (minden olvasás nullázza), ha túl nagy, akkor -128..127 tartományra kell korlátozni az értéket ?
A "K" egyszerűbbnek tűnik, mert nem ütközik a normál joystick bemenettel, de a régi programok talán fixen a "J"-t használják ?
Of course I am eager of answer, but in English please.
Ha ugy ertetted a kerdest, hogy "normal erzekenyseg", hogy adott sw szinten, akkor meg kell kerdezni Gflorez-t, hogy pl az o mouse drivere milyen elmozdulast minek feleltet meg
Xep128-ban olyan feature is van, hogy "kitalalja", hogy a program joystick-ot kerdez vagy egeret, akkor is, ha amugy utkozes lenne, es aszerint valaszol.
Yes, that is what I meant, I need to convert the coordinates of the mouse pointer to the dX/dY values sent to the emulated hardware in a way that gives a reasonable sensitivity with most Enterprise software.
If the majority of software with mouse support assumes or supports a certain resolution for dX/dY, for example dX = +16 moves one character to the left, then it is possible to write the emulation in a way that in those software the sensitivity of the emulated mouse matches that of the host OS. That is, if you move the pointer by one character on the screen, then it will also move by one character in the EP software, even if the actual position cannot be matched.
The same applies to the mouse wheel, although in that case there might not be a real sensitivity, and it is more like simple up/down buttons that should send +1/-1 as the delta whenever such events are received?
I planned a similar feature, while the 1500 us (is that value correct?) timer is active, reading the B6h port returns data from the mouse buffer, otherwise it is the joystick input like before. It would also be possible to send the mouse data on both columns (bits 0 and 1 of port B6h at the same time), if that is of any use and it does not break any software.
The Ps/2 mouse works the same, with deltas, but on 9 bit signed. The eight bit is discarded.In Entermice exactly discarded the least significant bit, while the ninth bit is slide to the oldest position in a byte and moving the other bits to the right.
Is there a Win executable to try?
Fifth: In any case, you can clear the unused half byte.
4- {...} The last is Pear sign.Exactly there are the EnterMice serial number.
You must use my SymbOS hack (https://enterpriseforever.com/programming/symbos-106/?action=dlattach;attach=15397). I modified it to work with K column, but it still uses right button for main(row 0 on L column), and it is still not detected with your beta emulator while inside SymbOS. Estrange, isn't it?.
I can do easily the first fix, but for swapping the buttons we need 1 byte more. Is for that I leaved the left button as Main.
Szerintem én voltam, azon az alapon, hogy egyébként meg CMOS-ként müködik (nem bugos).
Ha jól látom, a GitHub-on a Z80 típusa CMOS lett (https://github.com/istvan-v/ep128emu/commit/a7fc4f8608aa807f861bb36979252d48c902a694). :oops: Ez valószínűleg a 2.0.9.1 után összegyűjtött módosítások egyike, mert nem emlékszem ilyen változtatásra. Azonban nem tudom, ez valóban jó ötlet-e, mert elronthat régebbi programokat, különösen Spectrumon és CPC-n, ahol a 16 bites port címzés miatt egyébként is gyakran használnak "OUT (C)" utasításokat. Talán célszerűbb lenne visszaállítani az NMOS-t, vagy esetleg konfigurálhatóvá tenni?
Nem ez volt?
https://github.com/istvan-v/ep128emu/commit/a7fc4f8608aa807f861bb36979252d48c902a694
Ezt meg en commit-oltam az alapjan amiket kuldozgettel a forumon modositasokat.
Ez valószínűleg nem az én ötletem volt :oops:, mindenesetre a GitHub-on egyelőre visszaállítottam az NMOS CPU-t, viszont most már emulálja a bugos LD A,I/R utasításokat, és ennek megfelelően lefagy a Pinball Power javítás előtti verziója (https://enterpriseforever.com/cpc-r337l/pinball-power/msg21196/#msg21196), illetve a Z80 bug tesztelő programom (https://enterpriseforever.com/cpc-r337l/pinball-power/msg21403/#msg21403) is jelzi a hibát. :)
A pascal11.rom szerintem már felesleges. pasians.rom-ból van új, egeres.
A Pascal-t esetleg 1.2 verzióra lehetne cserélni, de ebből nem látok ROM változatot.Igen ez jó lenne, már anno is kértem Povit, hogy legyen belőle ROM verzió. :oops:
EXDOS 1.4-et, ezeknek van valamilyen előnye emulátoron a korábbi verziókhoz (2.32 és 1.3) képest?Az SD illesztő kapcsán egy súlyos bug derült ki az EXDOS-ban, ami érinti az IDE-t is.
Az EXOS-t is frissítsem 2.32-ről 2.4-re, vagy az utóbbi csak olyan újdonságokat tartalmaz, amelyeknek emulátoron nincs jelentősége (pl. Z180 támogatása vagy fejlettebb memória tesztelés)?Emulátoron nincs jelentősége.
Ha jól látom, az új EXDOS ROM angol és magyar hibaüzeneteket tartalmaz, de lehet, hogy más nyelveket is tömörítve?Van belőle német meg spanyol verzió is, fordítok egy komplett csomagot.
Az új EPDOS-nál mi a különbség az EPD17L12.ROM és EPD17Z12.ROM között? Eddig csak egy "epdos_z.rom" file volt, és az 1.9-es verzió (az hasznos még egyébként?).Az L-es az külön Lacika verzió :-) A felső menüben van különbség. A Z az általános.
Spectrum ROM-okhoz: Gosh Wonderful ZX Spectrum ROM
Ez a zx48.rom-ot helyettesítheti? Akkor talán célszerű lesz átnevezni "zx48gw03.rom"-ra.Igen.
Hasznos lehetne még a MOUSE.XR-ből ROM verzió, de nem tudom, ezt mennyire lenne nehéz megoldani, ha önmódosító kódot tartalmaz vagy a változókat a bővítő szegmensén tárolja.Ha jól tudom, jó adag RAM-ot használ a saját szegmensében.
A FILE bővítő is elavult lehet azokban a .ext változatokban, amelyek tartalmazzák.Abból itt az aktuális (https://enterpriseforever.com/programozas/file-bovites/msg55291/#msg55291) amit bele lehetne rakni.
Abból itt az aktuális (https://enterpriseforever.com/programozas/file-bovites/msg55291/#msg55291) amit bele lehetne rakni.
illetve az EXDOS 1.4-ből még nincs nem magyar nyelvű változat.Lesz, angol, magyar, német,spanyol.
A jelenlegi EXDOS14ISDOS10UK-HFONT.ROM az angol konfigurációkon is magyar üzeneteket ír ki, bár lehet, hogy ez állítható valamilyen változóval, mert a ROM file tartlamazza az angol üzeneteket is?:VAR 144 OFF
más ROM nem frissült az előző néhány oldalon már megtalálhatóakon kívül?Az EDCW (https://enterpriseforever.com/programming/entermice-option-on-edcw/msg58753/#msg58753)-ből is készült EnterMice-s verzió.
Lesz, angol, magyar, német,spanyol.
Az EDCW (https://enterpriseforever.com/programming/entermice-option-on-edcw/msg58753/#msg58753)-ből is készült EnterMice-s verzió.
A file nevek várhatóan mik lesznek, illetve melyik konfigurációkban kell használni az egyes ROM-okat (ha nem egyértelmű a név alapján)?EXDOS14ISDOS10UK-1770.ROM
Ezt és az új - 32K-sra tömörített és egeresített - PASZIANS.ROM-ot érdemes lenne beépíteni valamelyik konfigurációba?Igen az utils-osba mehetnének.
A ROM csomag jelenlegi állapota:A config lista is elérhető valahol?
Thanks to:
Zozosoft - hardware testing and information
MrPrise - ep128emu.enterpriseforever.com web site
Attus - Linux binary packages
Martin Bantz - PCLinuxOS RPM spec file
A config lista is elérhető valahol?
A github Readme fájljában a végén én már szerintem nem vagyok időszerű, mivel csak és kizárólag UHU linux alá csináltam és csinálok bináris csomagot.
Szerénységem csupán a linux rendszerekhez szükséges csomagkészítéshez nyújtott talán hasznosítható és a kódba általad már beépített ötleteket, amik alapján a forrásból már bármely linux disztribúcióhoz az illető disztribúció karbantartója könyedebben készíthet hozzá bináris telepítő pakkot.
A WD regiszterekhez csak akkor lehet hozzáférni, ha a 18h porton ki van választva egy meghajtó.Végülis igazi gépen se fog nagy baj okozni (max egy pillanatra felvillan a led), a legnagyobb baj, hogy pár plusz bájt lesz :-)
Módosítottam:
Zozosoft - hardware testing and information, ROM packages
MrPrise - ep128emu.enterpriseforever.com web site
Attus - Linux fixes and binary packages for the UHU distribution
Martin Bantz - PCLinuxOS RPM spec file
LGB - GitHub import from SourceForge, Linux testing and fixes
Gyors javitásként esetleg: a nincs meghajto és az A: WD-je lehetne közös?
Valószínűleg vannak hamarosan javítandó új hibákEzt játszom éppen az EXDOS 1.4-el is :oops:
Az EXDOS 1.4 file-ok közül a BRD és az UK változat valójában csak a HFONT-os másolata, illetve az ESP az 1.3-as verzió átnevezve. :oops: Természetesen a kész csomagban nem ezek lesznek, de egyelőre megfelelnek arra a célra, hogy a hiányzó ROM-ok ne okozzanak hibát.Itt vannak az aktuális verziók, bugtalanítva az ATTR, ATDIR, ISDOS parancsok. (És az újabb berakott bug is kiszedve :-) Módosítás dátumához akartam berakni, hogy 2014-16, csak a kötőjeltől megkergült a szövegkezelő rendszer...) Valamint megfelelő nyelvű IS-DOS van beépítve
szerk.: már találtam is, hiányzó lemez esetén nem megfelelő a hiba emulációja :oops:
Javítva a GitHub forráskódban, hamarosan új beta verziót készítek a frissített EXDOS 1.4 ROM-okkal. Javítandó probléma még, hogy az IDE emuláció használhatatlanná válik snapshot töltés után. Bár lehet, hogy van valamilyen IDE.ROM parancs, ami újra lefuttatja a meghajtók detektálását? Jelenleg az emulátor snapshot töltéskor minden lemezes eszközt a hidegindítás utáninak megfelelő állapotba hoz, és mindegyiken lemezcserét jelez, mivel nem garantálható, hogy töltésnél ugyanazok az image file-ok, mint amik a mentéskor voltak.
Bár lehet, hogy van valamilyen IDE.ROM parancs, ami újra lefuttatja a meghajtók detektálását?Nincs, a vinyók alapból nem cserélhető lemezek :oops:
Tenyleg, azt nem lehetne megoldani, hogy a disk image is belekeruljon a snapshot-ba? Oke, egy IDE cucc esetn "kisse" nagy lenne :) De pl egy floppy eseten meg elmegy, es neha hasznos lehetne (foleg, ha mondjuk vmi egyszerun tomorites is van rajta, egy kevesbe kihasznalt disk csomo blokkja "ures").
Vagy esetleg legalabb vmi checksum, igy ellenorizheto, hogy a hasznalt image ugyanaz-e, es az alapjan dontest hozni (pl akkor nem ad lemezcsere "jelet" ha uaz).
Ja, spec vmi egyszeru tomorites pl memorianal sem rossz otlet talan ... Nem kell vmi extra, talan valami RLE is jo ilyesmikre ...
Nincs, a vinyók alapból nem cserélhető lemezek :oops:
Az SD-nél viszont kidolgozás alatt van az ügy (ott van a hardverből érkező kártyacsere jel). Esetleg az Lgb által elkezdett ep128emu-s SD emulációt lehetne rendesen adaptálni?
Megoldható lenne, bár nem tudom, mennyire lenne hasznos, valószínűleg ritkán okoz problémát a szabad lemezterület hiánya a snapshot file-ok számára, viszont a fórumon csatolt file-ként küldve talán praktikus lenne például egy 4 MB-os konfigurációról készült snapshot tömörítése. De ha az emulált konfigurációban nincs sok kihasználatlan RAM, akkor nem jelent nagy különbséget.
Talán be lehetne építeni, de nem tudom, a felhasználó szempontjából mennyire hasznos ha van IDE és SD emuláció is, valódi gépen az utóbbi praktikusabb, azonban emulátoron mindkettő VHD formátumú image-t tesz láthatóvá az EXDOS számára. Az Xep128 sdcard.img-je működik is IDE lemezként. :)
Ha az IDE kezd elavulttá válni, akkor érdemes lehetne az SD-t megvalósítani, de ennek az emulációja problémásabbnak tűnik, ha jól látom, egy 64K-s ROM-ot használ a 04-07h szegmenseken, amelyen belül található SRAM és memóriába ágyazott I/O is (I/O portok helyett)?
Elvileg létezik cserélhető lemezes IDE eszköz, és az ezekhez kapcsolódó parancsokat az IDE emuláció támogatja is, bár az újabb dokumentációk szerint elavultak.Akkor elvileg későbbi IDE verzióban meg lehet majd oldani, vissza kell majd portolni az SD-ből. (Az egész ügyben a nehézség, hogy itt nem csak egy egyszerű lemezcseréről van szó, mint a floppynál, hanem vinyók/kártyák száma is változhat, és persze mindegyiken újra fel kell deríteni a partíciós struktúrát , aminek végeredményében egy rakás EXDOS logikai meghajtó alakul át, vagy lesz belőle több vagy kevesebb, amihez hackelni kell az EXDOS táblázatait.)
Talán be lehetne építeni, de nem tudom, a felhasználó szempontjából mennyire hasznos ha van IDE és SD emuláció is, valódi gépen az utóbbi praktikusabbIsmerek olyan embert, többet is, aki valódi gépen is ragaszkodik mindkettőhöz! :-) A legutóbbi SDEXT verzió éppen ezért született, hogy együtt működjön az IDE-vel.
egy 64K-s ROM-ot használ a 04-07h szegmenseken, amelyen belül található SRAM és memóriába ágyazott I/O is (I/O portok helyett)?A 04-06h azok szabványos ROM szegmensek, tartalmuk sem kötött. SD emulációba csak akkor kell belevenni, ha a FLASH ROM írása is meg lesz valósítva.
Persze, tok mind1 neki, az is sima "lemezkep" csak, ha IDE, ha SD ... Annyi van meg a Xep128-ban (bar ez meg nincs fenn talan a github-on), hogy egyreszt erzekeli az MS-tudomisen milyen VHD image-t (utolso sector nem adat valojaban hanem a forumatum resze).
Annyi van még, hogy a SymbOS jelenleg csak SD-t kezel. Valamint az SD gyorsabb valamivel, az olvasás az LDIR-rel is tud működni, míg az IDE-nél rakás I/O utasítás kell, különösen a 8/16 bit konverzió miatt.
Nekem meg azért hasznos, mert mindkettőt lehet fejleszteni, sőt az Lgb féle hackelt ep128emu-val lehet mindkettőt egyszerre, tesztelni az együttműködést (csak most kéne majd a 2.0.10-ből is hackelt :oops: )
A VHD formátumot az ep128emu eddig is támogatta, bár éppen most javítottam egy hibát: csak akkor működött ez a formátum, ha a file neve .vhd kiterjesztésű, ezért például az sdcard.img-t át kellett nevezni. :oops: A javított változatban már csak az utolsó szektor tartalma a lényeges.
Ennek a hackelt verziónak a forráskódja megtalálható valahol?
A WD hiba javítva:Működik is a WD vizsgálat, régi emuval not ready lesz, az újjal működik :-)
Ha ez az IDE szektor olvasó rutin, akkor talán lehetne gyorsítani rajta:Köszi az ötletet, majd a következő verzióba beépítem! Biztos lehet még mit optimalizálni rajta :oops:
Az image file az IDE secondary slave helyett választható, ami ebben a verzióban nem használható IDE lemezként. A lapozható ROM csak a 07h szegmens tartalma (16 KB, a többi FFh byte), az eredeti változattal ellentétben nem használ külön (fix nevű) file-t erre a célra. Ebből a csomagból (http://xep128.lgb.hu/files/rom_pack.zip) az sd-cart-0.1-64k.rom a 04-07h szegmensekre töltve működik.
Ezeken, es azon kivul, hogy amugy is randa, meg az a baj a megoldassal, hogy esetleges hiba eseten (I/O error emulator szinten, seek-eles az image mereten kivul, esetleg read-only modban nyitott image-re iras) en az SD kartya parancsra adok vissza hibat. Na ezt lathatoan EXDOS/DISKIO/akarmi nagyon rosszul viseli, es onnantol _semmit_ nem hajlando csinalni, mindenre error-t ad, ez mondjuk nem tudom miert van.Elvileg működni kéne :oops: Mondjuk rendes EXDOS hibakódok a 0.2 verziótól lettek :-) Sőt úgy emlékszem, hogy ezt a kártyán kívüli olvasást teszteltem is.
Elvileg működni kéne :oops: Mondjuk rendes EXDOS hibakódok a 0.2 verziótól lettek :-) Sőt úgy emlékszem, hogy ezt a kártyán kívüli olvasást teszteltem is.
Egy bad sectoros kártyát is már begyűjtöttem a teszthez.
Mivel ezek a pufferelt I/O miegymas funkciok tapasztalataim szerint nem tul elonyesek aztan image-nek (magyaran lassu), ezert aztan a fileno()-val lekerem a normalis UNIX file descriptorat a megnyitott file-nak, es utana mar azt kezelem read()/write()/lseek()-el.
Ami - tobbek kozott - igen ronda ebben az az, hogy ugye adott SD parancsra a file muvelet "azonnal kesz", kb nulla (emulalt) Z80 orajelciklus. Szoval, ha van egy EP-s program ami SD kartyat olvas intenziven, akkor remekul elrontja az idozitest, hiszen itt azert libc, majd kernel funkciot kell hivni a file olvasashoz, ugyanakkor az emulator szempontjabol nem telt el ido :( Foleg, ha egymas utan olvas szektorokat szegeny EP-s program, akkor erdekes lesz ...
Amitől biztosan kiakad jelenleg, az a kártyacsere, utána not ready lesz, resetig. Ez nem is baj egyelőre, hiszen itt jönne a korábban tárgyalt partíciók újradetektálása, és egyeztetése az EXDOS-szal. Ehhez kell egy rakás belső átszervezés is, ami a 0.4-el már elkezdődött.
Az stdio lassúságának emulátorban nem sok jelentősége van, ha az emulált gépen 100 KB/s adatátvitel már nagyon gyorsnak számít. :) Ezért én nem is használom az Unix specifikus alacsony szintű függvényeket, csak akkor, ha a probléma nem megoldható stdio-val (pl. stat() használata). A pufferelés letiltható setvbuf()-al, bár ha a blokk méret kisebb mint a puffer, akkor valójában a puffer gyorsít. Egy egyébként nagyon lassú és elavult laptopon egy 900 MB-os - már cache-elt - file olvasása 512 byte-onként fread() függvénnyel pufferelés nélkül kb. 2 másodperc (0.3 user és 1.7 system), puffereléssel pedig 0.9 (0.3 user és 0.6 system). A read() a nem pufferelt fread()-hoz képest kb. 0.1-0.2 másodpercet gyorsít.
Ha valódi gépen az SD kártya nem igényel várakozást (azaz regiszter vagy port hozzáférések között nem kell legalább X us-t várni), akkor ez valószínűleg nem nagy probléma, szekvenciális olvasásnál egy "lassú" SD kártya is lényegesen gyorsabb, mint amit egy EP-s program követni tud. Én az IDE vezérlőnél nem emulálok semmilyen időzítést, bár a 0 időtartamú seek nem egészen felel meg a valóságnak. :) Nagyobb probléma, hogy a WD-nél sincs időzítés, ezt (és a lemez forgását stb.) csak a CPC-nél és Plus/4-nél valósítottam meg. :oops:
Hat nem tudom :) En tapasztalatbol mondom. Eloszor igy csinaltam meg Xep128-ban, es ha vmit nagyon toltott SD-rol kb 50% cpu-t zabalt es akadozott is. Atterve a sima read-re/fread-rol, 20% ala esett, es folyamatos is ... Kulonosen pl az SD audio player-nel ahol ugye multiblock-read SD command van.
Ha meg igazan durvan nyomatja a program a cuccost, ez akar idozitesi gondhoz is vezethet. Azon elmelkedtem anno, hogy kulon thread-be tenni az olvasast
valódi gépen az SD kártya nem igényel várakozást (azaz regiszter vagy port hozzáférések között nem kell legalább X us-t várni)Nincs ilyen, 10MHz-en, 0 wait-tal is működik.
Én az IDE vezérlőnél nem emulálok semmilyen időzítést, bár a 0 időtartamú seek nem egészen felel meg a valóságnak. :)Ha CF kártya van rákötve, akkor már megfelel :-)
Nagyobb probléma, hogy a WD-nél sincs időzítés, ezt (és a lemez forgását stb.)Viszont így nem kellett Turbo EXDOS meg turbó gép, hogy az 1.44-es lemezek is menjenek emu alatt. Szóval az adatátvitel maradhat így.
Most kipróbáltam (i5-ös Lenovo X220), 10MHz-es EP, SymbOS 2 videó lejátszás egyszerre (ez ugye folyamatosan SD-t olvas, rakás LDI-vel), kb 2-3 CPU%, így lesz összesen kb 5-6 :-)
Az Xep128 esetében valamilyen más probléma lehetett, talán a Wine vagy a már említett debug printf()-ek miatt (az biztosan lassítja az emulátort ha a lemezműveletek közben több ezer üzenetet kell kiírni a konzolra).
Írható SD kártya:
(Attachment Link)
Jól veszem észre, hogy az SD hardver akkor kapcsol be, ha a secondary slave-be be van rakva a VHD, egyébként normál szegmens a 7-es?
Magánál az emulációnál még a kártyaméret kiszámolás hiányzik, ami elvileg az Lgb féle friss forrásban már benne van.
Jól veszem észre, hogy az SD hardver akkor kapcsol be, ha a secondary slave-be be van rakva a VHD, egyébként normál szegmens a 7-es?
sdext.imageFile "C:\\Program Files\\ep128emu2\\sdcard.img"
sdext.romFile "C:\\Program Files\\ep128emu2\\sdcard1.rom"
sdext.enabled Yes
memory.rom.04.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.04.offset 0
memory.rom.05.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.05.offset 16384
memory.rom.06.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.06.offset 32768
memory.rom.07.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.07.offset 49152Ezen kívül már emulált a 64K flash ROM, és írható is, de csak a lapozható része, a 04-06h szegmensen normál ROM található. A ROM írás használhatóságát még nem tudtam tesztelni, tehát nem biztos, hogy működik. :oops: A flash ROM emuláció hátránya, hogy már nem használja a 07h szegmenst, és ez a ROM nem kerül snapshotba, illetve jelenleg a 7K SRAM sem.Magánál az emulációnál még a kártyaméret kiszámolás hiányzik, ami elvileg az Lgb féle friss forrásban már benne van.
Ebben mennyire tertel el az en kodomtol? Neztem, elsore most tul faradt vagyok hogy a melyere nezzek, de erdekel amugy :)
Lényeges eltérés nincsen az írás működésében, az esetleges új bugoktól eltekintve. :oops:
:) az irassal amugy ovatosan, elvileg ez "testing" fazisban volt nalam is csak ...Szedjem elő a pszeudo véletlenszámos írástesztelőmet, amivel anno az igazi SD tesztelésénél kibukott az EXDOS bug? :-)
Most már grafikus felületen konfigurálható az SD kártya emuláció:smt038
A kártya detektálásának lépései:
1. kártyacsere ellenőrzése
2. ha volt kártyacsere, akkor az inicializáló rutin meghívása -> ez már jelzi, hogy van-e működőképes kártya az adott foglalatban
3. inicializálás után lehet hívni a blokkszám lekérdezését
Az SD kártyákat mindig inicializálni kell behelyezés után, addig semmilyen művelet nem végezhető velük. A 2 foglalat INSERT és DISKCHNG jeleit közösítettem, mert a CPLD-ben már fogytán voltak az erőforrások. Így, ha bármelyik kártyát kiveszik vagy újat tesznek be, a DISKCHNG bit aktiválódik (sajnos mind kivételre, mind pedig behelyezésre aktiválódik a bit, ezzel nincs mit tenni). Az inicializáló rutin az összes foglalatban lévő kártyát újrainicializálja, függetlenül, hogy ott nem is volt változás. Ezt érdemes figyelembe venned, ha az a terved, hogy az 1Hz-es megszakításból figyeled a kártyacseréket.
Azt esetleg lehetne, úgy általában is, hogy rövidebb ROM fájlt FF-ekkel felkerekítsen a szükséges méretre?
Ennek az emulációja még hiányzik. (Azaz, hogy csere után várjon az inicializálásra.)
Ez megoldható lenne, bár a file méret ellenőrzésnek az is a célja, hogy ne lehessen nem ROM file-t betölteni. :)Esetleg legyen egy figyelmeztető kérdés, hogy tényleg akarod-e :-)
talán a flash emuláció helyett elég lenne a korábbi megoldás ami csak a 7-es szegmenst lapozza és nem írható?Végülis emulátoron a fájlok frissítésével/konfigurálásával meg lehet oldani a ROM frissítést, flash emuláció már csak flashelő program fejlesztéshez érdekes. De az megoldható Xep128 alatt is.
Itt pontosan mit is kell tenni az emulátornak?Az írás/olvasás parancsok Not ready-t adnak vissza (sd_wait_ready), amíg nincs inicializálva (sd_init) a kártya (típustól függően CMD1 vagy CMD41 parancs).
Itt pontosan mit is kell tenni az emulátornak? Az Xep128 forráskód szerint ez olvasható az 1-es regiszteren, és ennek az írásakor az 5. bit beállítása törli a lemezcserét:
case 1: // status reg: bit7=wp1, bit6=insert, bit5=changed
(insert/changed=1: some of the cards not inserted or changed)
A 9-es parancsnál hiányzik még a lemez méretének a lekérdezése, ezt ugyan VHD megnyitásakor az emulátor kiszámítja, de jelenleg nem olvasható. :oops:
Vagy ugy ertetted, hogy ep128emu-ban nincs?
Most már lehetőség van snapshot mentésre is, de ez csak az SRAM és flash ROM tartalmát tárolja és a ROM lapozóregisztert, illetve hogy a hardver engedélyezett-e.
bár az image file nélküli E0h/C0h érték nem biztos, hogy helyes.A nem használt bitek 1-esek, ill. a csak írható regiszterek, és nem aktív adat regiszter is FFh-nak olvasható.
de a fo problemam mindig az volt, hogy WD/disk support-ot lusta voltam csinalni,Mire megcsinálom neked, hogy ne fagyjon le az EXDOS WD nélkül, már nem is érdekel? :oops:
eddig volt par elonye azert a Xep128-nak (SD kartya, eger ...).Z180? :-) Elöbb-utóbb aktuális lesz :-)
Mire megcsinálom neked, hogy ne fagyjon le az EXDOS WD nélkül, már nem is érdekel? :oops:
Z180? :-) Elöbb-utóbb aktuális lesz :-)
A nem használt bitek 1-esek
Ez biztosan így van?Ezt láttam, amikor ASMON-ban nézegettem a regisztereket :oops:
Nem lehetne átírni az új romhalmazra?
talán a már nem használt exdos13.rom helyére kerülhetne az IS-DOS nélküli EXDOS 1.4?)Nem lényeges, az ISDOS nélküli verzióknak valódi gépen van jelentősége, ahol korlátozott mennyiségű ROM hely érhető el, Így lehetőség van az ISDOS helyett más programot választani társbérletbe, amit gyakrabban használ az adott felhasználó. Pl az egyik spanyol srácnak a HXC-re volt szüksége, és csak 32K ROM hely van az EXDOS kártyáján.
A friss verzió nem fogadja el a sok programos VHD-t (http://enterprise.iko.hu/SD244MB.zip), ami valódi kártyáról lett lementve.
Próbáltam egy 2GB-osról lementettet is, az se tetszett neki, egy 8GB-osra meg azt mondta, hogy "Error seeking IDE disk image".
:oops:
16 megás volt amit elfogadott :-)
A friss verzió nem fogadja el a sok programos VHD-t (http://enterprise.iko.hu/SD244MB.zip), ami valódi kártyáról lett lementve.
Próbáltam egy 2GB-osról lementettet is, az se tetszett neki, egy 8GB-osra meg azt mondta, hogy "Error seeking IDE disk image".
:oops:
16 megás volt amit elfogadott :-)
2 GB-nál nagyobb image nem támogatott. :oops: Bár ennek EP-n FAT12 file rendszerrel egyébként sem lenne sok értelme a ROM tesztelésén kívül. Az "Error seeking..." hibaüzenetet a 32 bites fseek() használata okozza 2 GB-nál nagyobb file-on. A 244 MB-os image esetében a CHS alapján számított méret nem "SD kompatibilis", talán figyelmen kívül kellene hagyni a CHS-t, de a C=1007,H=16,S=31 paraméterekből számított szektorszám (499472 = 2*2*2*2*19*31*53) nem 1 és 4096 közötti egész 2 hatványával (4,8,...,512,1024 tartományban) szorozva, ezért az emulátor az image-t nem fogadja el.
2 GB-nál nagyobb image nem támogatott. :oops: Bár ennek EP-n FAT12 file rendszerrel egyébként sem lenne sok értelme a ROM tesztelésén kívül.Jelenleg nincs, de célkitűzésben van a FAT16, FAT32 is.
talán figyelmen kívül kellene hagyni a CHS-tSzerintem nyugodtan el lehet felejteni, SD kártyánál eleve nincs is értelme, de az IDE is végig 32 bites LBA-t használ belül, ill. a HDD-t is LBA módban kezeli alapértelmezetten. (Csak a nagyon régi LBA-t nem támogató (ezek úgy 22-23 évesnél régebbiek) HDD-k esetén konvertál CHS-re, közvetlen a parancs kiadásnál) Az ep128emu emulált vinyója is LBA módban megy.
Nalam legalabbis Xep128-ban itt volt bug, amire Zozo fel is hivta a figyelmem, hogy nem fogadja el, amit valodi kartyarol szedett le pedig (ez - elvileg - azota Xep128-ban javitva mar egy ideje, mar biztosat Zozo tudna mondani, hogy tenyleg igy talalta-e ...).Igen, ott a javítás után jó lett.
Lehet, hulyseget mondok, de ellenorzesnel a meretbol leszamitottad a VHD vegerol az "info block-ot" ha ez nem raw hanem tenyleg MS/conectix VHD cuccos?
Szerintem az emuban is feleljtsük el a C/H/S-t, egyedül az IDE információs blokkba legyen kiszámolva valami közelítő érték.
Jelenleg nincs, de célkitűzésben van a FAT16, FAT32 is.
Aztán ott van az SD Audio Player, hasonlót gondolom lehetne az EPVideo-ból is faragni. Ilyesmivel már lehet bőven fogyasztani a tárhelyet :-)
Az is ott van, hogy manapság 4 gigás a legkisebb kapható új kártya, így könnyen előfordulhat, hogy egy teljes kártya mentés az nagyobb lesz mint 2 giga :oops:
if (totalSectors > 65535 * 16 * 255)
{
totalSectors = 65535 * 16 * 255;
}
if (totalSectors >= 65535 * 16 * 63)
{
sectorsPerTrack = 255;
heads = 16;
cylinderTimesHeads = totalSectors / sectorsPerTrack;
}
else
{
sectorsPerTrack = 17;
cylinderTimesHeads = totalSectors / sectorsPerTrack;
heads = (cylinderTimesHeads + 1023) / 1024;
if (heads < 4)
{
heads = 4;
}
if (cylinderTimesHeads >= (heads * 1024) || heads > 16)
{
sectorsPerTrack = 31;
heads = 16;
cylinderTimesHeads = totalSectors / sectorsPerTrack;
}
if (cylinderTimesHeads >= (heads * 1024))
{
sectorsPerTrack = 63;
heads = 16;
cylinderTimesHead = totalSectors / sectorsPerTrack;
}
}
cylinders = cylinderTimesHead / heads;
Megoldható, hogy LBA módban a teljes image címezhető legyen, bár így az IDE emulációnál a lemez mérete változik a CHS vagy LBA mód használatától függően.Mivel LBA módú vinyó van emulálva, így csak LBA használat van. (De mint írtam ez az eltérés valódi vinyóknál is előfordult.)
Ebben a Microsoft dokumentumban (http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc) írják, hogyan kell a C/H/S-t számolni:
Az ugyan nem egyértelmű, miért fontosabb az S-t néhány fix értékre (17, 31, 63) korlátozniEzt én se, de a Microsoftnál nagy hagyománya van az ilyesminek (lásd pl a fix 2 FAT példány és társai).
Jelenleg nincs, de célkitűzésben van a FAT16, FAT32 is.
Módosítva a GitHub forráskódbanAz EXE-kben még nem?
Apróság, de lehetne nevet adni az emulált SD-nek, ahogy az IDE meghajtó is kap?
Bár itt nincs annyi karakter, de az OEMID/Product Name mezőkbe beférne, hogy "EP128SD"
Az SD kártya mérete, ez az ID fájlból is kiderül 7A000h szektor, 255852544 bájt = F400000h, ami jól is van tárolva.
Ebben a Microsoft dokumentumban (http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc) írják, hogyan kell a C/H/S-t számolni:
Az EXE-kben még nem?
ROM csomagban régi az ASMON, ez a javított gyorstesztes. (https://enterpriseforever.com/programozas/tegyuk-rendbe-az-ep-programokat/msg23962/#msg23962)
A következő: EP64 TASMON-os konfigokból kimaradt a BASIC.
Az IDE/SD configokban lehetne alapértelmezetten kikapcsolva a FILEIO-? Ezeket pont azért választja az ember, hogy a VHD-ről töltögesse a sok programot :-)
De ha már késznek tekinthető a ROM csomagMég Zozotoolsban jön egy frissítés a hétvégén (EXDOS 1.4 féle EXDOS.INI kezelés beépítése (régebbi EXDOS-ok esetére), valamint alapértelmezett meghajtó kiválasztása a gombnyomkodás esetére is. Magyarán, ha van SD/IDE és gombnyomással indítjuk az EPDOS-t, akkor is F: legyen az alap meghajtó :-) )
az sdext05 és esetleg az ide12 még támogathatná a lemezcserét, vagy az későbbi terv, amit nehéz megvalósítani?Ez még későbbi, alaposabb átszervezést igényel (jelenleg egy tömbben adja be a logikai meghajtókat az EXDOS-nak, ezt szét kell szedni, hogy egyesével legyenek, mivel a partíciók változásával ezekből lehet kevesebb vagy több is.)
Ezt valójában az ASMON 4-5 szegmensekre való áthelyezése okozta, mivel a BASIC is ott lenne, csak az egyik tud betöltődni. :) Annak lenne valamilyen hátránya, ha az ASMON visszakerülne a korábbi helyére (05-06h), vagy a BASIC szegmensét kellene változtatni?Az ASMON 4-5, BASIC legyen a 6-os, mint az EP128-TASMON configokban, így van gyors teszt.
de a file I/O a "Machine configuration" alatt kikapcsolva (ilyenkor az epfileio.rom nem állítja be a FILE:-t alapértelmezett eszköznek, de hidegindítás nélkül újra engedélyezhető)?Így gondoltam.
A ROM csomagot hamarosan frissítem, bár a fórumról való letöltés hátránya, hogy a "dinamikus" URL miatt a meglevő installer nem tudja az új verziót használni.Amíg nincs stabil cím, addig csak statikusan lehetne beépíteni az emulátor telepítő halmazába, legyen az linuxos, vagy windózos.
Az ASMON 4-5, BASIC legyen a 6-os, mint az EP128-TASMON configokban, így van gyors teszt.
Így gondoltam.
Amíg nincs stabil cím, addig csak statikusan lehetne beépíteni az emulátor telepítő halmazába, legyen az linuxos, vagy windózos.
Ez meg LGB szerint nem ildomos.
Aért továbbra is érdekes ez a romhelyzet...lgb kifogása licenc szempontból teljesen jogos. Nem tudod a ROM-okat GPL-lel licencelni. Az általad említett NVIDIA meghajtót is ezért kell külön letölteni, ezért nem lehet rész GPL licenccel terjesztett Linux distronak.
Azert, mert en azt mondtam, meg nem kell ram hallgatni, a velemenyem volt :) Csak max megtamogattam azzal, hogy mas sem szokott ilyesmit csinalni, de ettol meg mindig az en (vagy eppen akkor mas ...) velemenye. Szoval nem akarom en a "tutit" itt megmondani, de ugy vedd!
Hehe, azt irtam volna, hogy "NE" ugy vedd, nem azt, hogy "DE" :DMost miért? Így sem rossz, szerintem. :D
lgb kifogása licenc szempontból teljesen jogos. Nem tudod a ROM-okat GPL-lel licencelni. Az általad említett NVIDIA meghajtót is ezért kell külön letölteni, ezért nem lehet rész GPL licenccel terjesztett Linux distronak.Persze, hogy jogos, tudom.
A plus4 -es romjai is bele vannak építve a plus4emuba, azoknak sem tudom a jogi helyzetét.
A GPL-es ep128emu -nak meg nem lenne szabad a júzer tudta (és egyetértése nélkül) letöltenie semmilyen wget, vagy curl használatával valahonnan egy nem GPL-es romhalmazt, hisz ezzel jogsértést követ el maga az ep128emu.
Még a windózós verzióinál is, amikre még inkább vonatkozna ez, hisz egyik windóz sem GPL.
Még Zozotoolsban jön egy frissítés a hétvégén (EXDOS 1.4 féle EXDOS.INI kezelés beépítése (régebbi EXDOS-ok esetére), valamint alapértelmezett meghajtó kiválasztása a gombnyomkodás esetére is.
Bár nem tudom pontosan hogy ezekkel mi a jogi helyzet, mindenesetre a VICE (https://sourceforge.net/projects/vice-emu/) GPL 2-es emulátor, és egy meglehetősen régi és - elsősorban a C64 emuláció miatt - jól ismert projekt, tehát feltételezem hogy ezt a kérdést a fejlesztői rendezték (a Commodore vagy a jogutódja engedélyezte a ROM-ok használatát emulátorokban?), mivel minden ROM amelyet a plus4emu csomagja tartalmaz megtalálható a VICE SourceForge-os Git forráskódjában (https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/data/).
A GPL-es ep128emu -nak meg nem lenne szabad a júzer tudta (és egyetértése nélkül) letöltenieA telepítő megkérdezi, bepipálható lehetőségként, hogy "Download and install ROM images"
Vagy mi van az epdos rommal?Haluska Laci az össze programját, forráskóddal együtt publikussá tette.
When you put the sources on your website, than please mark them as untouched historical/original versions. Do not remove anything, especially not the copyright stuff. You should also not remove the original copyright information when doing further development work on it. If you make an EXDOS version 1.X out of it, than leave the original copyright message from 1985/IS as it is and put your name underneath. Do not sell anything out of it ;-), because your work will be based on the original stuff. Then everything should be fine.
Viszont pl disztribuciokban mas, legalabbis Ubuntu csomagban mar pl nincs benne ... Amugy pl a Mega65 project kapcsan megallapodast kotott a Mega as Commodore jelenlegi jogtulajdonosa (ami nem tudom ki) hogy hasznalhatjak a ROM-okat (sot talan fizetnek is erte - bar ebben nem vagyok biztos - igaz ott a szitu kicsit mas, mivel nem sw es "ingyenes" termekrol van szo, ezert penzbe fog kerulni, ami viszont tartalmazza a CBM "tulajdonat" is, ha ugy nezzuk). Lehet, hogy bar nem vagyok jogasz, hogy azert mas a disztribucioban torteno terjesztes mar "fogyasztaskeszen" mint a forraskod szintu upstream forrasokat, bar oszinten, fogalmam sincs, ezek inkabb csak tippek/megerzesek a reszemrol ...
Mindenesetre az ep128emu GitHub forráskódjában a Windows installer (ep128emu.nsi) kivételével töröltem a ROM letöltéseket:
-
Linuxon forráskódból így érdemes fordítani és telepíteni (ha a ~/bin-t tartalmazza a PATH):
mkdir -p ~/.local/share/ep128emu/roms
curl -o ~/.local/share/ep128emu/roms/ep128emu_roms-2.0.10.bin 'https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/?action=dlattach;attach=16433'
scons sdext=1 -j 4 install
Ez pedig eltávolítja:
scons -c install
Túl nagy kérés lenne, ha a linux rendszerekre is lenne a windows installerhez hasonlóan egy grafikus, a júzer egyetértő jóváhagyásával és általa indított rom letöltő rész?
Meg lehetne oldani, hogy a makecfg opcionálisan ROM letöltést is tartalmazzon, bár ennek hátránya, hogy a függőségek listájához valószínűleg a libcurl is hozzáadódna.Ez semmi lenne az előnyhöz képest.
de egyébként a ROM csomag késznek tekinthető?Pascalból kéne még ez 1.2-t összehozni, Povi azt mondta, hogy az eredeti is csak annyit csinált, hogy odamásolta 100h-ra.
Ez semmi lenne az előnyhöz képest.
Már előre is nagy köszönet érte, mert megoldja a felmerült romhalmaz letölrési problémát.
Engem egyáltalán nem zavarnak az újabb függőségek. A wget -et is bevettem anno, a curl meg amúgyis az alaprendszerek része, az eddigi curl parancs sem ment a curl függvénytárak (libcurl) nélkül.
Lehet en ertettem rosszul, de a libcurl-rol van szo, nem a curl-rol.
Ez semmi lenne az előnyhöz képest.
1 db file letöltéséhez az extra függőség nem feltétlenül semmi
Valóban, a fordításhoz a libcurl devel csomagra van szükség. Egyébként a GitHub forráskód már tartalmazza a letöltést támogató makecfg változatot, bár ebben hibák még előfordulhatnak. Az engedélyezéséhez az scons-nak curl=1-et kell megadni, mert alapértelmezés szerint curl nélküli verziót fordít, illetve Windowson például nem is lenne sok értelme.Nagyjábol elmondom, hogy miért semmiség nekem egy újabb függőség.
1 db file letöltéséhez az extra függőség nem feltétlenül semmi ha valaki forráskódból telepít és nincs libcurl csomagja, és a megvalósításához szükséges kód (ami itt (https://github.com/istvan-v/ep128emu/commit/920b998e6ec586466ffd38ce7b80f00324df90a1) látható) sem teljesen jelentéktelen, ugyanezt a feladatot a Windows installerben néhány sor oldja meg.
attila@localhost:/usr/src/UHUBUILD/UB-UBK1$ grep curl.h$ ContentsA Contents fájl tartalmazza az összes leendő UBK1 kiadásunk csomagjainak alkotórészeit.
curl-dev: 0 0 f 644 92191 /usr/include/curl/curl.h
attila@localhost:/usr/src/UHUBUILD/UB-UBK1$
most akkor van új ep128 emu ami kezeli az egeret?Igen, a 2.0.9.2 már egeres volt, a 2.0.10 pedig már SD kártya illesztőt is emulál.
most akkor van új ep128 emu ami kezeli az egeret?
Pascalból kéne még ez 1.2-t összehozni, Povi azt mondta, hogy az eredeti is csak annyit csinált, hogy odamásolta 100h-ra.
Még Zozotoolsban jön egy frissítés a hétvégénNincs elfelejtve a dolog, de most már Zozotools 1.9 lesz belőle :-)
Eszembe jutott még egy apróság: a PNG screenshot mentést nem lehetne el lesni az Xep128-ból? A fórum nem támogatja a BMP-t, és mindig át kell konvertálni. (Meg a PNG kisebb is.)
Már készül a PNG formátumú screenshot mentés, a feladat nagy részét a Deflate (https://www.ietf.org/rfc/rfc1951.txt) tömörítés teszi ki (amelynek a megvalósításához fel tudom használni a már létező epcompress kód részeit is), ettől eltekintve a formátum viszonylag egyszerű.
Pascalból kéne még ez 1.2-t összehozni, Povi azt mondta, hogy az eredeti is csak annyit csinált, hogy odamásolta 100h-ra.
attila@gubigep:/usr/src/UHUBUILD/packages-3$ dpkg-deb -I ep128emu_2.0.10~beta-2.1_i386.ubk.uhu
new debian package, version 2.0.
size 510630 bytes: control archive=4129 bytes.
5177 bytes, 235 lines buildinfo
635 bytes, 23 lines changelog
883 bytes, 18 lines control
1441 bytes, 22 lines md5sums
52 bytes, 2 lines * postinst #!/bin/sh
50 bytes, 2 lines * postrm #!/bin/sh
49 bytes, 2 lines * prerm #!/bin/sh
2475 bytes, 25 lines stat
Package: ep128emu
Source: ep128emu_2.0.10~beta-2
Version: 2.0.10~beta-2.1
Architecture: i386
Distribution: UHU Linux 3
Priority: extra
Installed-Size: 1908
Installed-Sizes:
1908 /usr
136 /usr/share
72 /usr/share/doc
Maintainer: UBK <ubk@ubk.hu>
Vendor: UHU Linux Baráti Kör
Depends: bash, curl (>= 7.37.0), fltk (>= 1.3.3), fontconfig (>= 2.11.1), gcc-lib (>= 4.8.5), glibc (>= 2.19), glu (>= 9.0.0), libsndfile (>= 1.0.25), libstdc++ (>= 4.8.5), libx11 (>= 1.6.2), libxext (>= 1.3.2), libxfixes (>= 5.0.1), libxft (>= 2.3.1), libxinerama (>= 1.1.3), licenses, lua, mesa (>= 11.1.0), portaudio (>= 20~20140130+r1963), pulseaudio, sdl (>= 1.2.15), uhu-pkg
Section: Applications/Emulators
Homepage: http://ep128emu.enterpriseforever.com
Description: EP128,zx48/128,cpc464 Emulátor
ENTERPRISE-128, ZX-Spectrum48/128 és Amstrad cpc464 Z80-as számítógépek emulátora
attila@gubigep:/usr/src/UHUBUILD/packages-3$[/size]
De amugy volt vmi vicces forraskodocska, ami vegulis csak "atveri" a dolgokat, es nem toromorit semmit, csak epp normal unpacker megeszi, cserebe igen egyszeru olyan file-t irni :D
Még egy icipici apróság: a GUI-ban a disk configuration-nál az IDE fülecskét át kéne nevezni IDE/SD-re.
SD nélkül fordított verzióbanIlyen verziónak van még értelme? Mivel már konfigolható, ki/be kapcsolható az SD emu.
Ilyen verziónak van még értelme? Mivel már konfigolható, ki/be kapcsolható az SD emu.
Még mindig gyorsabb mint betölteni képszerkesztőbe a BMP-t, és elmenteni PNG-nek :-)
Szerintem lehetne lassan egy normál újabb release is belőle.
Még egy felvetés: floppy emulációnál a választható szektor méret megvalósítása nagy munka lenne?
sok helyen feltételezi a fix 512 méretet. :oops:Erre tippeltem én is :oops:
Természetesen ahhoz, hogy valóban hasznos legyen, még Spectrumos floppy emulációt is kellene írni (nem használ ez is memóriába ágyazott I/O-t vagy egyebet ami a memóriakezelés átalakítását igényelné?).Van olyan is ami I/O-s (Pl TR-DOS), és van olyan is ami memóriás (Pl SpeccyDOS). Viszont mindegyiknél van ROM lapozás, ill. van ahol kombinált ROM/RAM szegmens lapozódik be (ahogy az SD-nél is).
Működik a 4 (és kevesebb) bites PNG mentés:Ilyenkor végig nézi az LPT alapján az egész képet, hogy mennyi szín van használva, és az alapján dönt?
Ilyenkor végig nézi az LPT alapján az egész képet, hogy mennyi szín van használva, és az alapján dönt?
Tényleg, és interlace képeknél hogyan működik a screenshot? Összerakja a két félképet?
Ilyenkor végig nézi az LPT alapján az egész képet, hogy mennyi szín van használva, és az alapján dönt?
Tényleg, és interlace képeknél hogyan működik a screenshot? Összerakja a két félképet?
a Spectrum és CPC emuláció, illetve hamarosan a - jelenleg még mindig TGA formátumban mentő - plus4emu is :))A sort nem lehetne majd egyszer folytatni egy TVC emuval is? :) A létező TVC emulátoroknak nagyon bénácska a debuggere :oops: Meg különben is úgy megszoktam az ep128emu felhasználói felületét, hogy minden géphez ilyet akarok :ds_icon_cheesygrin:
Meg különben is úgy megszoktam az ep128emu felhasználói felületét, hogy minden géphez ilyet akarok :ds_icon_cheesygrin:Én is :D Minden bajom van, ha más emulátorban kell használni a debuggert.
Minden bajom van, ha más emulátorban kell használni a debuggert.Pontosan!
Még a ROM csomagot kellene újra frissíteni (asmon15.rom, iview.rom, pascal12.rom, zt19.rom)ZT 1.9 (https://enterpriseforever.com/programozas/zozotools/msg59240/#msg59240) lassan elkészül :-)
az új emu miatt be kell konfigolnom a fileio-t, de nem jó:def_dev_file
:def_dev_file
na sikerült helyre hoznom
viszont...
a runner játékom snapshotban van csak meg... és nem tudom kimenteni belőle .bas-ban
valaki meg tudná csinálni nekem?
itt a legutóbbi verzió:
Ez volna az?
ZT 1.9 (https://enterpriseforever.com/programozas/zozotools/msg59240/#msg59240) lassan elkészül :-)
ep128.hu/Emu/ep128emu_roms-2.0.10.bin (http://ep128.hu/Emu/ep128emu_roms-2.0.10.bin)
Nagyon időszerű lenne már végre egy nem béta.
Szerk.: ha ezek a ROM-ok már késznek tekinthetők a 2.0.10 verzió számára, akkor esetleg fel lehetne tölteni például az ep128.hu-ra vagy más "állandóbb" címre, hogy a nem beta kiadás ne fórumos csatolt file-t töltsön le. :)
A Screen Quality beállítások pontosan mit csinálnak? Ha jól nézem:
0: ez az elképzelhető legjobb kép, amikor minőségromlás nélkül kerül kijelzésre
1: ez kb a compositnak felel meg
2: egy átlagos, de nem túl jó SCART-os kijelző
3: egy jó éles képű SCART-os monitor, a scanline-ok is látszanak
4: az antenna kimenet pocsékságát adja vissza :-)
Az installereket módosítottam, hogy a ROM csomagot először az ep128.hu-ról próbálják letölteni, és csak utána (hiba esetén) a fórumos csatolt file-t.Ezek szerint illő a csomagjaimat is hozzáigazítanom.
Ide (http://ep128emu.enterpriseforever.com/) is fel fog kerülni az új emulátor?
Az ep128emu.enterpriseforever.com-ra problémásnak tűnik a feltöltésItt volt az a jelszó probléma? Mert írhatok MrPrise-nak, ha még nem tud róla.
Itt volt az a jelszó probléma? Mert írhatok MrPrise-nak, ha még nem tud róla.Ha nem sikerül, van még tárhely bőven csak szóljatok:
Itt volt az a jelszó probléma? Mert írhatok MrPrise-nak, ha még nem tud róla.
Az ep128emu.enterpriseforever.com frissítése csak azért lett volna lényegesMeg azért, mert minden oldalról az van linkelve :oops: Vagy közvetlenül, vagy mint http://ep128emu.sourceforge.net/ ami egyből átdob rá.
Vagy közvetlenül, vagy mint http://ep128emu.sourceforge.net/ ami egyből átdob rá.
Már írtam, de úgy látszik, az ep128emu.enterpriseforever.com már nincs aktív fejlesztés alattSzerintem ez nem jó így. Én pl. mindig itt a fórumon szoktam nézni, ez fix oldal. A githubról laikusként azt gondoltam, azt csak fejlesztéseknél használják. És a githubos legfrissebb emulátor linkje elkallódik a fórum dzsungelében... Én ezért is tettem be ide az aláírásomba a fontosabb EP-s linkeket, hogy kéznél legyenek. Kéne talán a főoldalra vagy valami stabil helyre egy link a legfrissebb emuhoz, úgy gondolom.
Hozzám kirakhatnánk egy helyre az összeset(?)Vagy ide is a letöltések közé.
Én ezért is tettem be ide az aláírásomba a fontosabb EP-s linkeket, hogy kéznél legyenek.
Az ep128emu.entepriseforever.com linket szerintem érdemesebb lenne ep128emu.sourceforge.net-re cserélni (ami egyébként is átirányítható lenne az oldal esetleges más helyre költözésekor, és a Links alatt megtalálható az ep128emu.enterpriseforever.com is), az előbbit nem tudom frissíteni, ezért az ott található információ elavulttá válik, például a letöltéseknél:
Ezt szerintem MrPrise-al meg kene beszelni, mivel - legalabbis ha jol tudom/emlekszem - nemreg mondta, hogy koltoztette a site-ot pont hasonlo problemak miatt, hogy nem tudtal belepni. vagy hasonlo :)
Az ep128emu.entepriseforever.com linket szerintem érdemesebb lenne ep128emu.sourceforge.net-re cserélniAz aláírásomban lecseréltem.
Lehet, én vagyok béna, sőt biztos, de honnan lehet letölteni a legújabb működő emulátort? Az ep128emu.sourceforge.net oldalon vagy 2.0.9-es verziókat lehet elérni, vagy egy újabbat (githubra visz a link), ami a gép szerint nem kompatibilis a Windows jelenlegi verziójával. Endi feltett egy snapshotot, amit nem tudtam megnyitni.
UI: Lehet, nincs jelentősége, de ide (https://sourceforge.net/projects/ep128emu/) vitt valamelyik link. Oda az van írva, hogy 1 napja volt update, de a régi verziójú emulátor jön le.
Most a disableSDL = 1 foltozást is kivettem, mivel módosítottad a forrástban a megjegyzést.
Nekem sdl-1.15 van, jól gondolom, hogy ez jó?
Azt esetleg lehetne, úgy általában is, hogy rövidebb ROM fájlt FF-ekkel felkerekítsen a szükséges méretre?Most vettem észre, hogy ez is meg lett csinálva :smt038
dinamikus SDL-el (amit a disztribúció is használ) nincs probléma.Engem csak ez érint, mert forrásból történő fordításkor elv szinte minden disztribúciónál, hogy kerülik a statikus, illető programba belerámolt libeket és külső libekkel igyekeznek azt használni.
Engem csak ez érint, mert forrásból történő fordításkor elv szinte minden disztribúciónál, hogy kerülik a statikus, illető programba belerámolt libeket és külső libekkel igyekeznek azt használni.
Hogy lehet kikapcsolni a linuxos installhoz az openGL-t? Már összeszenvedtem majdnem mindent, erre most elhal az openGL hiányával. :(
Linux teszt verzió:
Frissítettem a dokumentáció egy részét az ep128emu.sourceforge.net-en, így most már a 2.0.10 telepítéséről van leírás itt (http://ep128emu.sourceforge.net/manual.html).
István, fordítanál nekem egy ilyen verziót? Megpróbálnám Mac-en.
Nincs Mac rendszerem, így nem tudok ilyen verziót fordítani. :oops:Ahogy Lgb csinálta az Xep128-al, azt nem lehetne itt is használni?
Ahogy Lgb csinálta az Xep128-al, azt nem lehetne itt is használni?
de ha sikerülne is valamit fordítani, nem tudnám futtatni.Lgb se tudta, de aztán valahogy mégis összefaragták Tutussal :-)
Ha forráskódból telepíted, akkor az jelenleg nem működik OpenGL nélkül, OpenGL/Mesa devel csomagok kellenek hozzá. De talán megoldható lesz, hogy OpenGL nélkül is lehessen fordítani.Esetleg nem lehetne belevenni egy OpenGL/Mesa header létezési tesztet, hogy ne kelljen foltozni senkinek, ha forrásból telepít?
Ha forráskódból telepíted, akkor az jelenleg nem működik OpenGL nélkül, OpenGL/Mesa devel csomagok kellenek hozzá. De talán megoldható lesz, hogy OpenGL nélkül is lehessen fordítani.Forrásból próbáltam, más lehetőségről nem tudtam, nem vagyok nagy linuxos :oops:
Szerk.: patch OpenGL nélküli fordításhoz:
(Attachment Link)
Nincs Mac rendszerem, így nem tudok ilyen verziót fordítani. :oops: A tesztelés hiánya miatt jelenleg valószínűleg nem is működne SConstruct és egyéb módosítások nélkül. Az itt (https://enterpriseforever.com/emulatorok/mac-emulator/) található régi Mac binárisokat sem én fordítottam.
Forrásból próbáltam, más lehetőségről nem tudtam, nem vagyok nagy linuxos :oops:
Valahogy csak lehet elvileg, mert tango nick nevű fórum felhasználó fordított nekem az előző változatból, íme:
A Mac fejlesztéshez nem értek :oops:, de ha valaki küld patchet vagy binárisokat, akkor azokat beépítem/feltöltöm.
En ugyan win-hez nem nagyon ertek, de nem lehet, hogy 32 bites windows-od van, es a 64 bitest (x64) toltotted le?32 bitest itt (https://github.com/istvan-v/ep128emu/releases/) nem is találok. Csak 64-es és 86-os van.
32 bitest itt (https://github.com/istvan-v/ep128emu/releases/) nem is találok. Csak 64-es és 86-os van.
Az x86-os a 32 bites. :)Köszi! Már csak azt nem értem, hogy lesz a 86-ból 32. Annyira nem régi a gépem, hogy 86-ban adták ki. :D
o util/dtf/dtf.o -c -Wall -O3 -fno-inline-functions -fomit-frame-pointer -ffast-math -DUSING_OLD_PORTAUDIO_API -DHAVE_SDL_H -DENABLE_SDEXT -I. -Isrc -I/usr/local/include -I/usr/include/freetype2 -I/usr/include/SDL -Iutil/epcompress/src util/dtf/dtf.cpp
sh: o: command not found
Itt egy újabb hibát vettem észre: a GTK-s file választó ablakok elrontják a billentyűzet bemenetet, de csak gyorsbillentyűvel megnyitva, egérrel menüből nem. A debugger vagy egyéb ablak megnyitása és bezárása után újra működik a billentyűzet.
Az o utasítás hiánya milyen csomag hiányának köszönhető?
A másik, letöltöttem a linux binariest, be van lőve az ep128emu-ra az executable, mégse tudom elindítani (command not found-ot kapok az ep128emu-ra)
Parancssorból indítva működik?Miután a jól bevált dupla klikk nem működött, indítottam egy console-t, és onnan próbáltam, ott kaptam a command not foundot, a 2.0.9-es verzió működött, és az is bináris bemásolós verzió volt.
Köszi! Már csak azt nem értem, hogy lesz a 86-ból 32. Annyira nem régi a gépem, hogy 86-ban adták ki. :DAz Intel 8086 processzor nevéből, amit aztán követett a 186,286,386,486... az erre épülő processzor architectúrát nevezik összefoglaló néven x86-nak. Bár 32 bitről csak a 386-ostól beszélhetünk :-)
Miután a jól bevált dupla klikk nem működött, indítottam egy console-t, és onnan próbáltam, ott kaptam a command not foundot, a 2.0.9-es verzió működött, és az is bináris bemásolós verzió volt.
Az "o" helyén g++-nak kellene lennie, a CXX változó hibásan lehet beállítva.Ez érdekes: (gúgli az ember barátja, na nem mindig :D ) Az nem lehet, hogy verziólemaradásom okozhat problémát ? Az FLTK 1.1.10-es pl
Ha az aktuális könyvtárban megtalálhatók a binárisok, akkor a ./ep128emu működik? Linuxon a PATH gyakran nem tartalmazza az aktuális könyvtárat, ezért kell a "./".jobb a helyzet, /lib64/libm.so.6 és /lib64/libc.so.6 hiányát jelzi 64bites verzióban, és 32 bitesen meg csak /lib/libm.so.6, amit ha jól értelmezek a gúgli segítségével glibc 2.15-nek kéne lennie a gépen, de nálam a 2.12 van fent, és úgy látom a repositorykon nincs is fent frissebb (Red Hat)
A Configure - Memory részben, ahol a szegmensekre lehet a romokat betenni, milyen configuration file-t lehet betölteni? Ha a configuration file melletti gombra kattintok, nincsenek olyan kiterjesztésű fájlok. Ha a kiterjesztést átállítom univerzálisra, akkor pedig nem tölthetők be a talált kiterjesztésűek.Olvasd el a readme.txt, 542. sorától kezdődően a "Memory configuration files" szakaszt. (Hiába, olvasott embernek nincs párja. :evil:)
Még egy Linux probléma, amit most vettem észre az előbbi hiba tesztelése közben: lenyomva tartott billentyűnél az ismétlés felváltva küld FL_KEYDOWN/FL_KEYUP eseményeket, Windowson viszont csak az FL_KEYDOWN ismétlődik, ami előnyösebb az emulátor számára. Bár az érintkezési hibás billentyűzet emulációja Linuxon akár "feature" is lehet. :) Nem tudom, ez az FLTK 1.1-ben is ilyen volt-e, mert nem emlékszem hogy régen ilyen probléma lett volna. Legalább most már tudom, miért akadozik a billentyűzet például a :FILE használatakor, már csak az a kérdés, hogyan lehetne javítani. :evil:
// Stupid X sends fake key-up events when a repeating key is held
// down, probably due to some back compatibility problem. Fortunately
// we can detect this because the repeating KeyPress event is in
// the queue, get it and execute it instead:
// Bool XkbSetDetectableAutoRepeat ( display, detectable, supported_rtrn )
// Display * display ;
// Bool detectable ;
// Bool * supported_rtrn ;
// ...would be the easy way to correct this issue. Unfortunately, this call is also
// broken on many Unix distros including Ubuntu and Solaris (as of Dec 2009)Az XkbSetDetectableAutoRepeat használata valóban javítja a billentyűismétlést, bár állítólag nem működik bizonyos disztribúciókon. De ha ez 7 évvel ezelőtt volt így, akkor talán nem nagy probléma. Esetleg csak akkor használnám, ha az FLTK nem túl régi verzió (pl. >= 1.3.2), ez remélhetőleg kiszűrné az elavult disztribúciókat is. Érdekes, hogy a kód további része az Fl_x.cxx-ben próbálja javítani a hibát más módon, de ez jelenleg nem működik, talán az X verziójától függhet?Ez érdekes: (gúgli az ember barátja, na nem mindig :D ) Az nem lehet, hogy verziólemaradásom okozhat problémát ? Az FLTK 1.1.10-es pl
A Configure - Memory részben, ahol a szegmensekre lehet a romokat betenni, milyen configuration file-t lehet betölteni? Ha a configuration file melletti gombra kattintok, nincsenek olyan kiterjesztésű fájlok. Ha a kiterjesztést átállítom univerzálisra, akkor pedig nem tölthetők be a talált kiterjesztésűek.
Egy újabb disztribúció valószínűleg nem ártana, a glibc 2.12 2010-es, a 2.15 pedig 2012-ben jelent meg. :oops: Bár a disztribúció frissítése sok munkával jár, csak az emulátor miatt nem érné meg.Frissítettem 2.16-ra, nem volt sok munka, csak sok idő :D, amúgy ha más kiabált volna frissítésért, akkor inkább nem használom a programot, nekem csak az EP128EMU miatt érte meg ;) , mégha a linuxon ritkábban is használom.
Olvasd el a readme.txt, 542. sorától kezdődően a "Memory configuration files" szakaszt. (Hiába, olvasott embernek nincs párja. :evil:)Abszolút nem érdekel a véleményed, se az RTFM. Hogy finoman fejezzem ki magam. Ezzel a stílussal pont az ellenkezőjét éred el annak, amit szeretnél, mert még inkább meg fogom utálni az utánaolvasgatást.
Direkt takarja el a teljes képernyős emulátor a Windows tálcát? Nem tudom, az előző verzióban is így volt-e. Másik programra váltáshoz mindig vissza kell állítanom az emu méretét. Nem lehetne olyan módot is teljes képernyőn, ahol a tálca megmarad?
Ha a kész SD-s konfigot betöltöd, az nem jó? :-)
Amúgy a külön ROM helyre kell betölteni egy SDEXT ROM-ot, ez azért külön mert meg van a lapozható rész is a 7-es szegmensen. Ezért ez így külön 64K ROM.
Ha SD engedélyezve van, akkor ez él a 7-es szegmensre, plusz az SD hardver, a fenti 7-es szegmens nem játszik.
ÉS ezen kívül kell egy EXDOS a normál részen.
00 50 17 00 00 B4 1F 00
00 00 00 00 00 00 00 00Jelenleg milyen CPU (utasítás készlet) a minimum követelmény?
Szerintem az, amire es amilyenre forditod, gondolom akar 386-osra is lehetne, ha valaki eleg perverz :DJó, ok. A letölthető 2.0.11 béta milyenre van fordítva.
Az a jelenség, hogy nem jelenik meg semmi sem, csak a feladatkezelőben látszik, szoftveres üzemmódban is.
Egyikről kiderült, hogy Core 2-es azon tuti menni kéne, mert most éppen én is azon használom :-)
Az volt az érdekes, hogy a ROM csomagot sem tudta letölteni, pedig így külön: http://ep128.hu/Emu/ep128emu_roms-2.0.11.bin
le tudta tölteni az illető.
Nekem ötletem sincs, 3 XP-s gépre is felraktam, és semmi baja.
Azt még megnézem, hogy egy frissen telepített XP SP3 esetén mi a helyzet.Simán működik, semmi más nem volt telepítve csak az alaplapi driverek. (Celeron + Intel G31-be integrált VGA (grafikus lassító :-) )).
Jelenleg milyen CPU (utasítás készlet) a minimum követelmény?Pár éve Win98-ra próbáltam telepíteni az emulátort, és nem akart működni. Bár az amúgy se volt valami stabil gép.
Pár éve Win98-ra próbáltam telepíteni az emulátort, és nem akart működni. Bár az amúgy se volt valami stabil gép.
GCC 6.2.0
A fenti problémák QT specifikusnak tűnnek és nem egyértelmű, hogy valójában a GCC vagy a QT a hibás, mert ha jól látom, későbbi QT verzióban javították. A ROM letöltésnél mindenesetre a GCC verziómnak nincs jelentősége, mivel azt egy NSIS plugin (INetC) végzi, amit és az installert nem én fordítottam. Ezen kívül Zozosoft XP-s gépein nincs hiba. De fordítottam egy optimalizálás nélküli 32 bites verziót, talán jelent valami különbséget, bár valószínűleg csak lassabb. :)A ROM letöltési részhez nem tudok hozzáfűzni semmit.
(Attachment Link)
Hmmm... ha a plus4emu-ban van SID, akkor az ep128emu-ba is be lehetne tenni Balagesz SID kártyáját? (https://enterpriseforever.com/hardver/sid-illesztes-ep-hez/msg48161/#msg48161)
Elvileg igen, de erről a kártyáról nem sokat tudok. :oops: Például hogy milyen port címeken érhető el, mi a SID órajele, ha sztereó a hang akkor azt hogyan oldja meg, stb.
(Frissítés) Kimaradt: a Fake-SID a C64-es sebességet, a 985.248 KHz-es órajelet (17.73447 MHz / 18) emulálja.
Ettől eltekintve nem lenne különösebben nehéz EP-s SID kártyát emulálni, de tartok tőle, hogy nem lenne olyan program ami ténylegesen használná is. :oops:A Geco féle SID Playerből készült hozzá.
A DTM lejátszóhoz emulált 4x8 bites D/A konvertert sem használja semmi más, és a hardver sem készült el.A Pear féle All in one kártyába remélem mind belekerül. Meg egy AY kéne meg :-)
A Pear féle All in one kártyába remélem mind belekerül. Meg egy AY kéne meg :-)
D/A: Tennek ra egy min par szaz byte-os FIFO RAM-ot, pl FULL es HALF-EMPTY jellel (ez utobbit lehetoleg interrupt-ot triggerelheto modon), programozhato "lejatszasi sebesseggel" az olvasasi oldalon.Olyanokat mondasz, amiről még az életben nem hallottam :oops:
Olyanokat mondasz, amiről még az életben nem hallottam :oops:
sid.0.model 0
sid.0.volumeL 0.0
sid.0.volumeR 0.0
sid.1.model 0
sid.1.volumeL 0.0
sid.1.volumeR 0.0
sid.2.model 2
sid.2.volumeL 1.0
sid.2.volumeR 0.0
sid.3.model 2
sid.3.volumeL 0.0
sid.3.volumeR 1.0Ez két 8580-at emulál a 0C-0Fh portokon, az elsőt a bal, a másodikat a jobb oldalon. A "model" értéke 0 lehet (SID tiltva), 1 (6581) vagy 2 (8580). Legfeljebb 4 emulálható (két kártya), de ennek magas a CPU igénye.- a 4x8 bites DTM lejátszós D/A konvertertIlyen volt eddig is? :oops: Ezt hogyan kell engedélyezni?
Ilyen volt eddig is? :oops: Ezt hogyan kell engedélyezni?
Szerk.: egy hibát már találtam, a szűrő Plus/4-es órajelet tételez fel (ezt nem módosítottam), így túl magas a frekvenciája. :oops:
Ez két 8580-at emulál a 0C-0Fh portokon, az elsőt a bal, a másodikat a jobb oldalon. A "model" értéke 0 lehet (SID tiltva), 1 (6581) vagy 2 (8580). Legfeljebb 4 emulálható (két kártya), de ennek magas a CPU igénye.
- a SID órajel a hang (DAVE) számára beállított érték kétszerese, azaz alapértelmezés szerint 1 MHz.
Természetesen a SwinSID bővítései (extra hullámformák, 6 oszcillátor, stb.) nem emuláltak, de ezeket a C64-re írt zenék valószínűleg egyébként sem használják.
Ha a "végleges" irányba tendál majd a kód, célszerű lesz (szerintem) a sima 1×-es verziót emulálni monóban, ekkor jobb, ha szól az mindkét csatornán.Ez már csak config fájl kérdése.
Ez az eltérés (1.000Mhz vs. 0.985MHz) vajon hallható? :)
Ha a "végleges" irányba tendál majd a kód, célszerű lesz (szerintem) a sima 1×-es verziót emulálni monóban, ekkor jobb, ha szól az mindkét csatornán.A legjobb talán az lenne, ha 1 mono 6581 és 1 mono 8580 lenne, és a lejátszóban lehetne ide-oda váltogatni :-)
És megértem, hogy egyesek miért is ragaszkodnak a 6581-hez... :razz: )Gyorsan át is konfigoltam arra, aztán még gyorsabban kiderült, hogy rögtön az első SID amit kipróbáltam, az pont 8580-ön szól jól :-)
Amúgy sztereó SID-es zenék léteznek? C64-hez is láttam 2 SID-es bővítést.
Ennél a SwinSID-es cuccnál lehet szoftverből választani a típust?
Gyorsan át is konfigoltam arra, aztán még gyorsabban kiderült, hogy rögtön az első SID amit kipróbáltam, az pont 8580-ön szól jól :-)
Egy hazai programozó faragott rajta azóta jó sokat, de azt a projektet nem követem túl szorosan... :(Én azt hittem a hazaiból indultál ki :oops:
Én azt hittem a hazaiból indultál ki :oops:Miután azt a tag árusította SwinSID HC néven, én meglepődnék ha nyílt lenne a forrása. De ne legyen igazam! Azóta készült újabb módosítás is, aminek a világpremierje az idei Árok partin volt. Ennek szerényen SwinSID Ultimate a neve. Itt (http://kompjut0r.blogspot.hu/2016/04/c64-sid-shootout-part-4-sid-8580-vs.html) és itt (http://kompjut0r.blogspot.hu/2016/05/c64-sid-shootout-part-5-sid-6581-vs.html) lehet olvasni összehasonlító tesztet eredeti SID-ekkel. Itt (https://ilesj.wordpress.com/2016/04/24/swinsid-ultimate/) olvastam róla először, és ez (https://www.facebook.com/swinsidultimate/) a fácséja, ha valakinek ehhez van gusztusa. Mondjuk ez már nem teljesen az hardverileg, mint a SwinSID, került még rá fekete soklábú kocka meg egyéb ez-meg-az, és úgy világít mint egy rossz karácsonyfa. :evil:
A legjobb talán az lenne, ha 1 mono 6581 és 1 mono 8580 lenne, és a lejátszóban lehetne ide-oda váltogatni :-)
Én azt hittem a hazaiból indultál ki :oops:
Miután azt a tag árusította SwinSID HC néven, én meglepődnék ha nyílt lenne a forrása. De ne legyen igazam!
Így első próbálkozásra fontosnak tűnik a kétféle SID lehetősége, vagy csak én futottam bele csupa válogatós zenébe? :oops:
Balagesz! Az általad felhasznált SwinSID kód az mit tud? Tud kétféle SID fajtát? És ha igen, akkor hogyan megy a váltás? Lehet programból, vagy akkor kell eldönteni amikor beprogramozod az IC-t? Netán jumperek?
Aztán ha megvan, mit lehet igaziból kihozni, azt kéne emulálni is.
Ha nagyot tévednék akkor majd jól kiröhögtök. Az eredeti SwinSID tudta a hullámformákat, ADSR-t, PWM-t, szinkronizálást és gyűrűmodulációt. Nem volt szűrő, regiszter olvasás, órajel bemenet (igaz, ezt még a SwinSID Ultimate sem veszi figyelembe), hang bement, potméter bemenet és az analóg viselkedést sem szimulálta. Ennek megfelelően igazából egyik SID típust sem emulálta.
A tapasztalatom az, hogy az "újabb" zenészek használják előszeretettel az új verzió pár módosítását, a régiek nem. Látványos ("hallványos" :) ) különbség amúgy inkább a szűrők működésében van, sokan a régi verzióra esküsznek ebben a témában.Én az 1988-as Cybernoid 1-t néztem elsőnek. A régivel elég satnyán szó, tán még a Dave-s lejátszással is jobb :-)
Bár az is igaz, hogy a régi csipek közül szinte nincs két egyformán szóló darab. :)Igen, olvastam valami C64-es oldalon, hogy az igazi ínyencek gyártási hét alapján is válogatnak :-)
Én az 1988-as Cybernoid 1-t néztem elsőnek. A régivel elég satnyán szó, tán még a Dave-s lejátszással is jobb :-)
Igen, olvastam valami C64-es oldalon, hogy az igazi ínyencek gyártási hét alapján is válogatnak :-)
Ha gyanúsan nagy az eltérés, az lehet emulátor bug is. :oops: Mivel ugyanazt az új SID kódot beépítettem a plus4emu-ba is, az esetleges hibát nem ártana javítani a következő beta verzió kiadása előtt. :)Ezt olyannak kéne meghallgatni, aki ismeri mindkét SID hangját :oops:
Ha gyanúsan nagy az eltérés, az lehet emulátor bug is. :oops:
Illetve lehet az még az is, hogy EP-n az eredeti lejátszó kód emulálva fut, ami jóval lassabb az eredeti 6502-es tempónál. Emiatt a regiszterírások között jóval több idő telik el, ez is okozhat ám anomáliákat bizonyos lejátszórutinoknál.Kipróbáltam, Z80 órajel növelés nem változtat semmit.
A régivel a fő hangszer (elektromos gitár vagy mi) nem igazán szól.
Image fájl esetén Windows alatt lehet az is a baj, ha valami más programban be van csatolva (pl virtuális floppy program), és ezért nem kap teljes hozzáférést az emu.Jogos.
Igen, ezt már én is akartam írni, hogy az ékezetes karaktereket se szereti :oops:
Úgy látszik, a hibát valójában az okozta, hogy görög karakterek voltak a file nevében, viszont Windowson a fopen() függvény nem működik Unicode karaktereket tartalmazó file név esetén (ilyen célra külön Microsoft specifikus függvény van, de még az se támogatja az UTF-8-at, előbb konvertálni kell). :roll: Az FLTK régi verziói még nem használtak UTF-8 kódolást, talán ezért működhetett a 2.0.9.1.Meg vagyok döbbenve, hogy az általam nagyrabecsült windows esetében nem működik az UTF8 az újabb FLTK-ban.
Tehát a teljes javításhoz gyakorlatilag az összes file műveletet módosítani kellene, mert nem csak a floppy image esetében fordul elő a hiba.
Linuxon működik, csak Windowson problémás az ilyen file megnyitása, ott kellene hozzá írni egy fopen() wrappert és az összes fopen() hívást arra cserélni.
Na ezert nem kell ekezeteket hasznalni file nevekben :) Csak a gond van veluk :)Én nem is használok. És ha lehet, akkor a 8.3-hoz is ragaszkodok :-)
Ahol lényeges lehet: floppy/SD image fájl, ROM fájl, FILEIO-s fájlok
Nem tudom, hogy ez mennyire szűkíti a javítások körét :oops:
-szintén esetleg: EP-s képfájlok betöltése, és PNG-be mentési lehetőség?
Beta verzió IVIEW->PNG konvertáló programmal, az ékezetes karaktereket tartalmazó file nevek is tesztelhetők:Csak én nem tudom letölteni?
(Attachment Link)
(Attachment Link)
(Attachment Link)
Csak én nem tudom letölteni?Nagyon úgy tűnik :oops:
Nagyon úgy tűnik :oops:
az ékezetes karaktereket tartalmazó file nevek is tesztelhetők:Jónak tűnnek! (ezeket próbáltam: fileio, ROM fájl, image fájl, mindez ékezetes könyvtárban is)
Olyat lehetne a lejátszóba, hogy egy programban legyen a Dave-es meg a SID-es, netán még ide-oda kapcsolgatni is lehessen? :oops:Ezt most így hirtelen nem tudom megmondani, de megnézem.
Olyat lehetne a lejátszóba, hogy egy programban legyen a Dave-es meg a SID-es, netán még ide-oda kapcsolgatni is lehessen? :oops:Elméletileg kész (https://enterpriseforever.com/sound/sid-lejatszo/msg61594/#msg61594) is, csak magnós konfigon teszteltem, igaz a file-kezelő részt nem piszkáltam.
ioctl(8, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0x7ffd4994cdf0) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffd4994bde0) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffd4994ce40) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffd4994ce10) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0x7ffd4994cdf0) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffd4994bde0) = 0
ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffd4994ce40) = 0Ilyennel még nem találkoztam, talán AMD OpenGL driver probléma lehet. -no-opengl használatakor is előfordul a hiba?
Nem léptetünk egy verziót a SID miatt ? :)
A SID egyébként ebben csak a 0Fh port írása után lesz aktív resetig, így az engedélyezése nem lassítja az emulációt ha nem fut SID kártyát használó program, és a DTM-es D/A-t is csak akkor rontja el amikor aktív.:smt041 Az jó, elég sokat dobott a CPU használaton a SID emu, holnap fel is teszem az új bétát :)
Ez lesz a 2.0.11 ha nincsenek javítandó hibák, a legújabb nem beta verzió jelenleg a 2.0.10.
Látom, a világ összes kincséért sem szeretnél 2.1 -et. :-D ;-) (Előbb el kell jussunk a 2.0.99 -ig? :-) )
Látom, a világ összes kincséért sem szeretnél 2.1 -et. :-D ;-) (Előbb el kell jussunk a 2.0.99 -ig? :-) )Amíg meg lehet különböztetni a verziókat egymástól, addig nekem aztán mindegy hogyan számozzák. ;)
Más. Az emulátor féltestvérének riválisa bevezetett egy kevéssé hasznos, ám nagyon látványos szolgáltatást. Az itteni közönség vajon szeretne-e olyat, és egyáltalán bele lehetne az ep128emu-ba varázsolni?Milyen szolgáltatást? Gondolom a Yape-ról lehet szó.
Kézzel hogyan kell makecfg-zni?
De ami a legérdekesebb, hogy van akinek korábbi béta az működik!
Mennyivel korábbi béta?Az utolsó publikus a githubon.
Az egyetlen jelentősebb változtatás mostanában csak a file név konverzió (UTF-8), talán ékezetes karakterek vannak valamelyik telepítési könyvtárbanEz lett próbálva C:\ep12emu2 módon is.
vagy a felhasználó nevében a C:\users alatt?A users-ba mit rak?
A users-ba mit rak?
De ilyesmi könnyen előfordulhat ha a beta verziókat csak nagyon kevesen tesztelik.Igen, a Zozo-ban nincs ékezet :oops:
Az UTF-8-azás után meg még nem volt githubos publikus béta.
A fórumon volt volt legalább két újabb verzió (UTF-8 "javítás" és SID).Igen, csak a hülye Facebook nem eszi meg a fórumról linkelt EXE-k linkjét (a főlapra dob ki), így a nem fórum függőkhöz nehéz eljuttatni :oops: ezért írtam időnként, hogy jöjjön Githubos béta.
a javítás már 2.0.12 beta lenne csak a GitHub-on.Szerintem bármilyen verziószámon örülni fognak neki :-)
Egy új észrevétel:
Lehetne, hogy az összes géptípus ikonját kirakja az asztalra is?
Most már lehetnek ott is, bár az eredetileg start menübe tervezett kis felbontású ikonok nem túl jól néznek ki nagyítva.Én eddig is kipakoltam mindet :-) Kinézettel nincs bajom, mondjuk az igaz, hogy mindig "kis ikonok" módot használok az asztalon.
Én az 1988-as Cybernoid 1-t néztem elsőnek. A régivel elég satnyán szó, tán még a Dave-s lejátszással is jobb :-)
Talán ezt hasznos lehetne megjeleníteni a lejátszóban ha 01b vagy 10b az érték.Kész (https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/?action=dlattach;attach=17154) :)
Nem tudom milyen módszerrel csinálja a hangrendszerek és hangeszközök észlelését az emulátor, de itt csődöt mond.
A hangeszközök észlelését nem az emulátor végzi, hanem a PortAudio. Az UHU 2.2 talán régi (ha jól látom, 2007-es?) verzióját tartalmazza. A PulseAudio használata problémás lehet, én általában egyszerűen törlöm ezt a csomagot :oops:. A PortAudio közvetlenül csak az ALSA-t támogatja.Köszi a nyomot.
Mellékelek egy foltot, ami kellett ahhoz, hogy lefordíthassam az emut ehhez a régibb rendszerhez, Az Fl_Native_File_Chooser egyes részei ugyanis nincsemek meg az itteni fltk1 1,1,10 verzióban.
Ezt szerintem helyesebb lenne az SConstruct-ban javítani, mert így akkor is az emulátor csomagjában található (FLTK 1.1-es) Fl_Native_File_Chooser.H-t használja a makecfg és tapeedit, ha egyébként FLTK 1.3 van a rendszeren. A probléma valójában az, hogy itt kimaradt a makecfgEnvironment és a tapeeditEnvironment:Code: Python
if configure.CheckCXXHeader('FL/Fl_Cairo.H'):
^
IndentationError: unexpected indentA Git forráskód már tartalmazza a javítást.Köszönök mindent, a 2.2 -t (is) már hagyom úgy ahogy van az én foltjaimmal, hisz működik. Nem hiszem, hogy javítana rajta funcionálisan, (a szépségen túlmenőn) ha most github commit számhoz tapadón letöltött forrásból csinálnán újra a foltjaim kidobásával.
Szerk.: a letöltéseket (http://ep128emu.sourceforge.net/downloads.html) frissítettem az új UHU csomagokkal.
It is ZX41ES.ROM (https://enterpriseforever.com/hardware/zx-spectrum-emulator-card/?action=dlattach;attach=17241), the Spanish translated Rom for the Hardware Spectrum Emulator.
Még lehet, hogy összedobok egy PKGBUILD -ot, ha lesz rá időm és kedvem, egy kicsit konyítok hozzá, és ki is tudnám próbálni az Arch-64 telepítményemen.
A SID lejátszó programok tesztelése közben újabb bosszantó GTK file választó ablak hibát vettem észre: ha a FILE: eszköz file nevet kér, akkor az ezt az eseményt kiváltó billentyű "ragad", mert az emulátor nem tud a billentyű elengedéséről. Ezért végtelen ciklusban újra megjelenhet az ablak. Ezt is javítom a 2.0.11.2 verzióban.Az mitől lehet, hogy a winfosban, magnós konfignál ha felugrik a fájlválasztó ablak, és a fájlnyitáshoz közel van egy breakpoint, akkor feldob egy hibaüzenetet, amit sose sikerült még elolvasnom, és az emulátor bezár? ( nem mindig fordul elő, régen is megvolt)
Nekem nem lép ki, de bezáródik a file választó ablak (10:c060x breakpoint beállítása után egyszerű START (F1) BASIC-ben), bár ez nem Windows, hanem Wine. Megnézem, pontosan mi okozhatja a hibát, valószínűleg azzal lehet összefüggésben, hogy a debugger ablak csak késve záródik be (azért, hogy a Step gombok használata közben ne villogjon). Ha Esc billentyűvel lépek ki a debuggerből, akkor nincs késleltetés, illetve az ablak egyszerű bezárásakor sem, és ilyenkor nem tűnik el a file választó ablak.Ha jól emlékszem akkor esc-re is tudja produkálni, mondjuk én is KVM alatt használom WIN7-en, de gondolom ez WIN7-es fícsör, nem befolyásolja az "emuláció". Nekem a fájlválasztó ablakkal megy az emulátor is :D
érdekes dolgot vettem észre! ha elindítom az emulátort, általában nem fekete képpel indul, hanem random lpt adat van a képernyőn, különböző szép mintákat generálva. mint az igazi hw-n! hogy lehet ez? :)Úgy, hogy véletlenszerű adattal van feltöltve a Nick, ahogy az igazi gépen is bekapcsoláskor. Ez főleg EP64-en érdekes, az EXOS 2.0-ban elfelejtették feketére állítani a keretet, így a memória teszt alatt véletlen színű keret tölti ki a képernyőt. Ennek kapcsán javasoltam anno Istvánnak, hogy legyen induláskor ez a véletlen feltöltés.
Úgy, hogy véletlenszerű adattal van feltöltve a Nick, ahogy az igazi gépen is bekapcsoláskor. Ez főleg EP64-en érdekes, az EXOS 2.0-ban elfelejtették feketére állítani a keretet, így a memória teszt alatt véletlen színű keret tölti ki a képernyőt. Ennek kapcsán javasoltam anno Istvánnak, hogy legyen induláskor ez a véletlen feltöltés.
Ments ki egy BASIC-et snapshootba és azzal indítsd az emulátort. (Amúgy meg rakj gyorstesztes konfigot be)
Ments ki egy BASIC-et snapshootba és azzal indítsd az emulátort. (Amúgy meg rakj gyorstesztes konfigot be)Valamikor ezt csináltam. Már nem tudom, miért szoktam le róla. Gyorstesztes konfig volt bent sokáig, de valamire mondták, hogy a kompatibilitás miatt az eredetit érdemes használni, azért az van bent.
Azon gondolkodtam még, érdekes lenne, ha programokba lehetne emulátort vezérlő utasításokat tenni. Pl. basic programba REM vagy ! után. Ilyen utasítással pl. az emulátor sebességét lehetne állítani. Pl. ha egy basic programon dolgozik valaki, és az elején sok mindent beállít, tömbök tartalmát feltölti változókkal, stb. akkor arra az időre beállíthatja, hogy pl.
10 ! emu_speed=1000%
semmilyen emulátorra, talán mert nincs rá igény és csak nekem jutott eszembe.
de, ez jó ötlet, bár én elvagyok nélküleDe lehet, nem is lenne olyan hatékony. Mert amikor kiadjuk a START parancsot, akkor még eltelik jó pár másodperc (nem tudom, miért egyébként), mire az első sorig eljut a program. Ez főleg hosszú programoknál van.
amikor kiadjuk a START parancsot, akkor még eltelik jó pár másodperc (nem tudom, miért egyébként)
Azon gondolkodtam még, érdekes lenne, ha programokba lehetne emulátort vezérlő utasításokat tenni.Xep128-ban lehet ilyeneket.
... 10 ! emu_speed=1000% ...Mások is eljutottak eddig a gondolatig. Például +4-en az az olasz jómunkásember, aki táblázatkezelőt (http://plus4world.powweb.com/software/SVS-Calc_2_5) (Excel!) faragott a gépre. Ő is emlegette, hogy milyen jó lenne ha az emulátor valahogy jelezni tudná a program felé, hogy nem igazi vas, a program meg felcsavarhatná a sebességet.
Xep128-ban lehet ilyeneket.
Nekem már az gyanús, hogy az ep128.hu-n sérültek meg a programok, de az azért biztos nem.
A problémát az okozza, hogy írásvédettek a file-ok, és a 2.0.10 verzió óta a FILE: minden file-t írásra és olvasásra próbál megnyitni. Azonban ha ez nem sikerül, akkor elvileg újra próbálkozik csak olvasható módban, de ez jelenleg hibás, nem az Alt+F-el megadott, hanem az aktuális (rendszer) könyvtárban keresi a file-t.
UI: A snapshotot először az asztalra akartam menteni, de nem engedte, valami error volt. Csak az emuból kijelölt mappába engedte menteni, és az ékezetes karakterek helyett ott krixkrax jelent meg. Erről a laptopról ritkán használom az emulátort, más gépen nem volt ilyen probléma.
Ez melyik verzió? A 2.0.11.1 elvileg javította az ilyen hibákat.Tényleg, nekem a 2.0.10-es van fent, mert ritkán használom ezt a gépet. Akkor frissítem itt is.
ja és továbbra is csak max z80 frekivel megy jól.Mennyi az a max? Én az emu Configure részében a CPU frekihez 4 helyett beírtam 64-et, de még azt is bírja az emulátor.
Mennyi az a max? Én az emu Configure részében a CPU frekihez 4 helyett beírtam 64-et, de még azt is bírja az emulátor.nálam 250000000
nálam 250000000Sajnos nehezen számolok meg ennyi nullát. :D Nem lenne egyébként jobb az emulátorban nullák nélkül ez a szám? Vagy van, amikor kicsi változtatás is számít?
Sajnos nehezen számolok meg ennyi nullát.
.mid fájlt ha be lehetne adni neki, na az hasznosabb lenne :)
Az lehetséges, hogy az alap EP gép órajele nem pont 4 MHz, hanem picivel több?Valamennyi eltérés lehetséges, hiszen az alkatrészek nem teljesen egyformák az egyes gépek között, bár szerintem a különbségeknek kb. a ±10 Hz-es tartományba szabad csak esniük. Az órajel generáló áramkörök elég stabilak szoktak lenni.
Majdnem 25 éves "fantasztikus" soundtrackeres (digi hangmintás) szerzeményemben egy hang máshogy szól 4MHz-en az emulátorral, mint anno igazi gépen szólt (az eleje felé, a gitár hangjában):
Ha a CPU frequency-t akár 4.1 vagy 4.2 MHz-ra állítjuk, egy magas hang máshogy szól, mint 4MHz-en. 4 MHz-en nem tud magasabb hangot kiadni, pedig magasabb hang van megadva. Ez mitől lehet?
Igazi EP-n olyan volt, mint kb. az emulátoron 4.1 MHz-en.
azt nem teljesen értem hogyan lenne lehetséges, hogy csak egy hangot játszik vissza magasabban. Illetve lehet, hogy nem sikerült helyesen dekódolni a második bekezdésedet. :oops:Jól dekódoltad. Nos, a Soundtracker 2.1 még nem olyan kiforrott zeneszerkesztő, mint pl. a Rockdigi. 8 oktáv adható meg a digi hangmintáknak, de csak a legfelső két oktávot érdemes használni, mert itt szólnak rendesen. Az ismertetőben is azt írják a programról, hogy a legfelső oktáv kissé hamiskásan szól. Ez sajnos érezhető is. Nos, a legfelső oktávban van ez a bizonyos legmagasabb hang, és ez tényleg hamisan szól eredetileg is, 4.1 MHz-en is. 4 MHz-en pedig ez a hang nem különbözik a nála kicsivel mélyebb zenei hangtól.
A Rockdigi valami teljesen más módszerrel játssza le a digi hangmintákat, sokkal jobb. Ráadásul 4 csatornás, míg a Soundtracker 2.1 csak 1 változtatható magasságú, 1 fix hangmagasságú digi csatornát kezel, és 2 négyszögjelest.
Volna lehetőség módosítani egy mostani PC alapú EP emulátort úgy, hogy a Z80-at az FC..FF lapokhoz való hozzáféréskor nem várakoztatja a NICK chip?
Szeretnék először is egy TAPE konfigot használni (exdos nélkül), aztán a PC merevlemezemen kibontott EP file-t betölteni. Ezt hogyan tehetem meg?
Továbbá szeretnék megszabadulni a sorok közötti üres résztől. (interlace)
Találtam olyat a Machine Config -> General -> File I/O-nál, hogy
"Enable virtual I/O"
Ami csak akkor működik, ha az epfileio.rom a 10. szegmensre be van téve.
Betettem. Betöltöttem a Nether Earth-ot, és kockákat látok.
Néha pedig újraindul.
Volt az egyik régi emuban egy olyan menüpont, hogy select directory for tape files.
- Linuxon a GTK file választó ablak megjelenítése után nem "ragad" az előtte lenyomott billentyű (pl. Enter)Lehet akkor winfoson se ragad be a billentyű, ha alt+W mellé más is lenyomásra kerül? Majd letesztelem :)
Lehet akkor winfoson se ragad be a billentyű, ha alt+W mellé más is lenyomásra kerül? Majd letesztelem :)
Windowson nincs különbség, Linuxon volt nagyon zavaró, hogy a GTK-s file választó ablak megjelenítésének a pillanatában éppen lenyomott billentyű (pl. F1 vagy Enter) elengedésének az eseménye elveszett, így a billentyű a file választása után "beragadt", rosszabb esetben az ablakot végtelen ciklusban újra megjelenítve.Sajnos linuxon már pár hónapja nem megy az emulátor, a legutóbbi bináris kiadása óta, próbáltam befordítani, pár dolgot hiányolt, azokat még pótoltam, aztán amikor a libpng-t hiányolta, ott feladtam, majd megnézem linuxon az új binárist is. Az utoljára működőképes verzióban nem emlékszem ilyen hibára :)
Egy másik FILE: probléma még, hogy több program Cancel esetén (A6h hiba) új file nevet kér. Ez is végtelen ciklust eredményezhet, amit valahogy megszakíthatóvá kellene tenni, hogy az emulált gépen futó programok ne tudják "lefagyasztani" az emulátort a folyamatosan újra megjelenő file választó ablakkal.
nem lehet olyan funkciót írni emulátorba, ami méri a rendszer/z80 felhasználtságot. :)
Ezt a debugger Lua programozásával már most is meg lehet oldani. A Z80 kódtól függően változhat, hogy hogyan kell mérni, tudni kell, hogy hol számít "nem használtnak" a CPU.
amúgy ha az emuban a z80 frekit maxra állítod, szerintem elég kényelmes az EP editora is :)
Az a progi ami IstvanV hozzászólásában látható elég szimpatikus, csak pont nem látszik a neve :)
De Windowsra van több programozás céljára készült szövegszerkesztő ami könnyen kezelhető.Programmer's Notepad (http://www.pnotepad.org/)-ot részletesen be lehet állítani az általunk használt nyelvhez (pl az utasítás szavakat megadni), én Z80 assemblyhez használom, de IS-BASIC-hez is be lehetne állítani.
Programmer's Notepad (http://www.pnotepad.org/)-ot részletesen be lehet állítani az általunk használt nyelvhez (pl az utasítás szavakat megadni), én Z80 assemblyhez használom, de IS-BASIC-hez is be lehetne állítani.Notepad ++-t is, és ha jól emléxem a Context is ilyen.
mondjuk az utóbbi időben elég sok basic programot csináltam ep-re, és lényegében semmi bajom az ep editorával.Mondjuk tényleg marha jó az EP editora, egy csomó kényelmi funkció benne van, ami manapság elvárható, egyedül a copy-paste hiányzik belőle, bár az is megvalósítható Basicben egyszerűen, én mindig egy létező sort sorszámoztam át, majd módosítottam :)
főleg azt imádom hogy ferdén lehet menni a kurzorral, amit egy modern rendszer sem tud (sőt, talán az ep-n kívül semmi)
Mondjuk tényleg marha jó az EP editora, egy csomó kényelmi funkció benne van, ami manapság elvárható, egyedül a copy-paste hiányzik belőle, bár az is megvalósítható Basicben egyszerűen, én mindig egy létező sort sorszámoztam át, majd módosítottam :)
Megpróbáltam most az XP-s gépemre felrakni a Midis beta-t, de jó nagy fagyás lesz belőle :cry:Előtte a legfrissebb emulátor verzió volt fent, amit frissítettél?
Előtte a legfrissebb emulátor verzió volt fent, amit frissítettél?Természetesen.
Még esetleg a 32 vagy 64 bites oprendszerre a külön csomag lehet probléma, nekem legalábbis.Ide természetesen a 32-est raktam.
Meg kell neveznie a végrehajtható fájlt "ep128emu.exe" -nekÚgy csináltam. / Yes, I do it.
Ide természetesen a 32-est raktam.Én otthon Win7 alatt 32 bites gépen használom a midis emulátort, működik. Gondolom, nem a 32/64 bit lesz a probléma, hanem az XP.
célszerű először a 2.0.11.1 (https://github.com/istvan-v/ep128emu/releases/tag/2.0.11.1)-et (NMOS/nem LuaJIT-es változat) telepíteni, ha nem az futott már eddig is.Ez volt előtte.
2.0.11.1-es emulátorban az Ep-s ALT billentyű nekem most nem működik a számbillentyűkre(?)
Alapértelmezés szerint a jobb Alt (Alt Gr) felel meg az EP-s Alt billentyűnek.Ez biztos? :oops: Réges-régen az volt, 2009-ben (https://enterpriseforever.com/archivum/ep128emu-2-0-6/msg15111/#msg15111) a Menü gombra került. Nekem azóta is ott működik, ALT GR-el viszont nem.
Csak az 1-9 billentyűkön nem működik, az összes többin jó.Ezt miből lehet észre venni, hogy az 1-9-en nem jó?
Ezt miből lehet észre venni, hogy az 1-9-en nem jó?
Csak mert az EXOS-ban nincs ALT-os karakter definiálva az 1-9-re ugyanúgy a számok jönnek (CTRL esetén is) :oops:
Most megnéztem HIDTEST-el, az ALT GR az egyszerre generál CTRL és ALT lenyomást, amiből az EXOS a CTRL-t veszi észre.
Biztos, hogy nem régi DLL-ek okozzák a hibát? :oops: Vagy esetleg nagyon régi CPU2.0.11.1-el nincs baja. A proci Core 2 Quad.
ha 64 bites az XP, akkor az is elképzehlető, hogy csak ott hibás.32 bites.
Hangkártya driver bajra tudok még tippelni... pláne, hogy 2 hangkártya is van abban a gépben :oops:
I have one PC working flawlessly on the emulator with two sound cards. But it has Win XP 32bit.With the beta MIDI version?
na most hangra miért nincs ilyen? lehetne szimulálni a béna kis ep hangszórókat :)
esetleg a korabeli kis olcsó fejhallgatókat, vagy a videoton tévé hangszóróit (na persze az ep hang nem ment ki erre, de van aki megoldotta hogy kimenjen).
vagy ep magnóra kivezetett hangot. (sose értettem amúgy hogy ez miért nem volt lehetséges alapból)
vicces ötlet jutott eszembe :)Akkor már lehetne a toggle rem1 hangját is utánozni, és a legközelebbi midizésnél majd azt is használjuk a ritmushoz. Ha elég gyorsan kapcsolgatjuk ki-be, még talán dallamot is lehet rajta játszani.
lehetne szimulálni a béna kis ep hangszórókatHangszórókat? Nem csak egy van belőle?
most leszedtem pár játékot, nodes, punk star, nem mentek emun.A legfrissebb emulátort kell használni. A régivel az írásvédett fájlokat nem olvasta.
mondjuk a nodesnek valami dtf verziója ment
A legfrissebb emulátort kell használni. A régivel az írásvédett fájlokat nem olvasta.
Most lebuktál, a midit sem használtad, mert ahhoz is a legfrissebb emulátor kell. :D
a legutóbbi snapshot amiben sok zene volt azt próbáltam és ment is.Ahhoz nem is kell újabb verzió, az igazi EP-n is fut. (Mármint konvertált zenék lejátszása a midiplay-jel.)
leszedtem a legújabbat, azzal se jó pl a punk starNem tudom, mi lett abban elizélve :-) Ha floppyra teszed, onnan jó.
leszedtem a legújabbat, azzal se jó pl a punk star
Ha valóban új az emulátor, akkor 2.0.11.2 verziót ír ki, és a hang beállításoknál lehet MIDI eszközt is választani.Az új emulátorban van már midi? Az nem egy frissítés volt, amivel az emulátor fájljait felül kellett írni? Vagy azóta van telepíthetős is?
Az nem egy frissítés volt, amivel az emulátor fájljait felül kellett írni? Vagy azóta van telepíthetős is?
https://github.com/istvan-v/ep128emu/releases/download/2.0.11.1/Ez nekem 404-et dob.
ep128emu 2.0.11.2 frissítés (https://enterpriseforever.com/ep128emu/ep128emu/1140/) (először a 2.0.11.1-et kell telepíteni)Itt nem ez lenne az inkább? (https://enterpriseforever.com/ep128emu/ep128emu/msg65290/#msg65290) Legalábbis én a wikis midi leírásból ezt találtam.
Itt nem ez lenne az inkább? (https://enterpriseforever.com/ep128emu/ep128emu/msg65290/#msg65290) Legalábbis én a wikis midi leírásból ezt találtam.
Ez nekem 404-et dob.Bocsi, nem jó, mert fájlnév nélküli.
2.0.11.2 beta Windows installerek, új epcompress verzióval:Ebben már a midi bemenet kezelése is benne van alapból?
Ebben már a midi bemenet kezelése is benne van alapból?
2.0.11.2 beta Windows installerek, új epcompress verzióval:Köszönjük!
2.0.11.2 beta Windows installerek, új epcompress verzióval:
A 2.0.11.1 elvileg még működik, a 2.0.11.2-vel már problémák vannak, valószínűleg a PortMidi miatt. De egyes gépeken előfordult már hasonló hiba, talán driver függő lehetNálam volt ilyen. (https://enterpriseforever.com/ep128emu/ep128emu/msg66200/#msg66200) Most felfrissítettem a gépet Win10-re, és megy 2.0.11.2!
Nálam volt ilyen. (https://enterpriseforever.com/ep128emu/ep128emu/msg66200/#msg66200) Most felfrissítettem a gépet Win10-re, és megy 2.0.11.2!
Annak ellenére, hogy maradt a gépben a 20 éves rádiós hangkártya, amit XP-s Windows update-ből kinyert driverrel erőszakoltam rá a 10-re :ds_icon_cheesygrin:
én egy 2002-es képnézegetőt használok a mai napig, de nem gondoltam hogy valaki hw-ben is megelőzi ezt :)Az semmi. Én 1985-ös számítógépet is használok!
jut eszembe, egy 1998-as képkonvertálót is használok :)
Az semmi. Én 1985-ös számítógépet is használok!de a legújabb szoftverekkel!!! :-D
de a legújabb szoftverekkel!!! :-DIgen, kell hozzá külön szoftver meg hardver, hogy a midi, mod és mp3 fájlokkal elboldoguljon. ;)
én egy 2002-es képnézegetőt használok a mai napig, de nem gondoltam hogy valaki hw-ben is megelőzi ezt :)A Cakewalk, amit EP-s midizéshez is használok, 1994-es. Csoda, hogy felmegy a Win7-re.
jut eszembe, egy 1998-as képkonvertálót is használok :)
A Win10-es laptopon az emulátor sokszor nem reagál a STOP gombra, az a Pause/Break gombra van beállítva. Nem az emulátor hibája, mert más gépen jól működik. Van, hogy 5-ször megnyomom, mégsem reagál semmit. Ennek mi lehet az oka? Pl. listázom a programot, és nyomkodom, nem áll meg.
A Pause helyett célszerűbb az End billentyűt használniKöszi, most már jó lett!
Nem lehet, hogy nyitva volt a debugger ablak, vagy más okból foglalt állapotban volt az emuláció?Nem volt nyitva. A basic ment rajta. Egyébként innen a fórumról töltöttem le régebbi snapshotokat és azokat próbálgattam. Lehet, hogy még régi verziójú emulátorral készültek a snapshotok, esetleg az lehetett a gond. (2015 novemberéből nyitottam meg a Karakteres grafikus módok (https://enterpriseforever.com/video/karakteres-grafikus-modok/) topikból snapshotokat. Volt, ami 400Kb körüli, ha ez számít valamit.) De ez a számítógép, amiről most vagyok, lassú, az emulátor is sokszor lassan nyílik meg, inkább a gépem hibája lehet.
István, EP128emu-t el lehet indítani úgy, hogy egy megadott fájl automatikusan betöltődjön, és az nem snapshot?Én a midivel mindig úgy csinálom, hogy egyből betöltse az envelope.txt-t, hogy ilyesmiből mentem el a snapshotot
István, EP128emu-t el lehet indítani úgy, hogy egy megadott fájl automatikusan betöltődjön, és az nem snapshot?
Jelenleg nem támogatott ilyen funkció, illetve csak a plus4emu tudja, ahol egyszerűbb volt megvalósítani. :oops:Köszi szépen. :)
Azonban ha a betöltendő file fix nevű, akkor snapshot vagy ROM bővítő használatával megoldható az automatikus indítás. Azaz például snapshotot menteni a betöltést végző .com file indítása közben, és utána -snapshot paraméterrel már egyszerűen tölthető a program. Továbbfejlesztett megoldás lenne a snapshotot megfelelő file névvel automatikusan generáló segédprogram.
Az nem jó, ha START fájlt készít, és akkor fileios konfigban csak egy F1-t kell nyomni?Mondjuk az F1-et nem emltette, amikor a load, meg a run begépelését, igaz az F1 mellett még a fájlt is ki kell választani.
igaz az F1 mellett még a fájlt is ki kell választaniÚgy emlékeztem a fileio is tölti a START-ot, mint az EXDOS :oops:
Emu hangerőt nem tekerted le?
Néha a CPU órajelet 12MHz-ra állítom, majd vissza 4-re. Van valami egyszerűbb módja, hogy ne kelljen mindig átírni, hanem könnyen lehessen váltogatni a kettő között? Régebben mintha lett volna valami billentyűparancs erre.
én úgy csinálom hogy pgup gpdown vált két profil között.Ááá, ott van a Quick config menüpont, most vettem észre, azért így eléggé könnyű. :D
;------------------------------------------------------------------------------
;
; NOTES ON TRACKS, SECTORS AND GAPS
; *********************************
;
; Disk spins at 300rpm = 5rps.
; Data rate is 250kb/s = 31,250 bytes/s.
; 31,250/5 = 6250 bytes/track
; (padding added to 6500 to allow for tolerances in disk speed).
;
; 9 sector format has an Index Address Mark (IAM) for PC compatibility but the
; WD177x doesn't need that for operation. So the PC-incompatible 10 and 11
; sector formats do not have this feature on the track to save track space for
; the extra sector(s).
;
;
; TRACK FORMATS
; ==============
;
; datasheet 9 10 11
; miniumum sectors sectors sectors GAP Description
; -------- ------- ------- ------ ------ ---------------
; TRACK HEAD:
; 32x4Eh 60x4Eh 60x4Eh !10x4Eh Gap 1a Index postamble \
; |
; 12x00h |
; 3xC2h IAM preamble |
; FCh IAM > HEAD
; 60x4Eh Gap 1b IAM postamble |
; --- -- -- |
; 136 60 10 BYTES IN TRACK HEAD /
;
; EACH SECTOR:
; 8x00h+ 12x00h+ 12x00h+ ! 3x00h+ \ \
; 3xA1h 3xA1h 3xA1h 3xA1h Gap 2 ID preamble | |
; FEh FEh FEh ID Mark | |
; 1xTRA 1xTRA 1xTRA Track # | |
; 1xSID 1xSID 1xSID Side # > ADDR |
; 1xSEC 1xSEC 1xSEC Sector # | |
; 1xLEN 1xLEN 1xLEN Length # | |
; 2xCRC 2xCRC 2xCRC | |
; 22x4Eh 22x4Eh 22x4Eh 22x4Eh Gap 3a ID postamble / > SECTOR
; 12x00h+ 12x00h+ 12x00h+ 12x00h+ \ | x n
; 3xA1h 3xA1h 3xA1h 3xA1h Gap 3b Data preamble | |
; FBh FBh FBh Data Mark | |
; 512xDAT 512xDAT 512xDAT User data > DATA |
; 2xCRC 2xCRC 2xCRC | |
; 24x4Eh 84x4Eh 40x4Eh ! 1x4Eh Gap 4 Data postamble / |
; --- --- --- |
; 658 614 566 BYTES PER SECTOR /
;
; TRACK TAIL:
; 16x4Eh 192x4Eh 50x4Eh !14x4Eh Gap 5 Index preamble \
; --- --- -- > TAIL
; 192 50 14 BYTES IN TRACK TAIL /
; ^
; ! = EXCEEDS DATASHEET MINIMUM !
;
;
; 136+ 60+ 10+
; 9*658+ 10*614+ 11*566+
; 192 50 14
; ===== ==== ====
; 6250 6250 6250 BYTES ON DISK
;
; 136+ 60+ 10+
; 9*656+ 10*612+ 11*564+
; 192 50 14
; ===== ==== ====
; 6232 6230 6228 BYTES IN BUFFER
; different because CRC is 2 bytes
; on disk but 1 byte (F7) in buffer
;
; Padding 250x4Eh 250x4Eh 250x4Eh
; 18x4Eh 20x4Eh 22x4Eh
; ===== ==== ====
; 6500 6500 6500 BYTES IN BUFFER TOTAL
;
; The extra padding to bring the size up to 6500 is to allow for variation in
; disk speed - bytes from the padding will be written as long as the WD177x is
; requesting more bytes.
;
; So the differences between the images are:
;
; 11 sector format has a smaller Gap1a Index Preamble
; 9 sector format has the IAM and pre- and post-amble
; 11 sector format has a smaller Gap 2 ID Preamble
; all formats have a different Gap 4 Data Postamble
; All formats have a different Gap 5 Index Preamble
So the PC-incompatible 10 and 11 sector formats10 sector format are only incompatible with MS-DOS, but Windows least from the last 20 years :-) (2000, XP, Vista, 7, 8, 8.1, 10) can use it. (MS-DOS need a disk handler utility (800.COM, FDREAD.EXE, etc), but DR/Novell DOS can handle it). As I know the Linux also don't have a problem about it.
Thanks Zozo, I wasn't 100% sure - the 10 (and 11) sector formats do not have the Index Address Mark field. The WD177x doesn't need this according to the datasheet but I read something somewhere which suggested the IBM PC floppy controller might need it.My FAFO still using it at all formats except the 11/22 sectors.
I wonder why IBM/MS did not use the 10 sector format in the beginning, and get bigger floppys?i'm also :-) And at the beginnig used a 8 sectors format! Only at version 2.0 added the 9 sectors format. Probably because the first PCs have a belt driven drives, which need a more speed tolerance?
My FAFO still using it at all formats except the 11/22 sectors.Can it show the track pattern, gaps etc? It would be interesting to see!
i'm also :-) And at the beginnig used a 8 sectors format! Only at version 2.0 added the 9 sectors format. Probably because the first PCs have a belt driven drives, which need a more speed tolerance?And the 5 1/4" formats grew from 8" formats, which had to work with even older 1970s technology. I don't know what the IAM is for - it tells you where the start of the track is, but there is a little hole in the disk for that! I thought maybe that came from 8" disks too.
Can it show the track pattern, gaps etc? It would be interesting to see!
00000000 4e 00 00 00 00 f5 f5 f5 fe 4f 00 06 02 f7 4e 4e |N........O....NN|
00000010 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |NNNNNNNNNNNNNNNN|
00000020 4e 4e 4e 4e 00 00 00 00 00 00 00 00 00 00 00 00 |NNNN............|
00000030 f5 f5 f5 fb d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
00000040 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000230 d9 d9 d9 d9 f7 00 00 00 00 f5 f5 f5 fe 4f 00 01 |.............O..|
00000240 02 f7 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |..NNNNNNNNNNNNNN|
00000250 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 00 00 00 00 |NNNNNNNN........|
00000260 00 00 00 00 f5 f5 f5 fb d9 d9 d9 d9 d9 d9 d9 d9 |................|
00000270 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000460 d9 d9 d9 d9 d9 d9 d9 d9 f7 00 00 00 00 f5 f5 f5 |................|
00000470 fe 4f 00 07 02 f7 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |.O....NNNNNNNNNN|
00000480 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 |NNNNNNNNNNNN....|
00000490 00 00 00 00 00 00 00 00 f5 f5 f5 fb d9 d9 d9 d9 |................|
000004a0 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000690 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 f7 00 00 00 |................|00000000 4e 00 00 00 00 00 00 00 00 f5 f5 f5 fe 4f 00 06 |N............O..|
00000010 02 f7 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |..NNNNNNNNNNNNNN|
00000020 4e 4e 4e 00 00 00 00 00 00 00 00 00 00 00 00 f5 |NNN.............|
00000030 f5 f5 fb d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
00000040 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000230 d9 d9 d9 f7 00 00 00 00 00 00 00 00 f5 f5 f5 fe |................|
00000240 4f 00 01 02 f7 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |O....NNNNNNNNNNN|
00000250 4e 4e 4e 4e 4e 4e 00 00 00 00 00 00 00 00 00 00 |NNNNNN..........|
00000260 00 00 f5 f5 f5 fb d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
00000270 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000460 d9 d9 d9 d9 d9 d9 f7 00 00 00 00 00 00 00 00 f5 |................|
00000470 f5 f5 fe 4f 00 07 02 f7 4e 4e 4e 4e 4e 4e 4e 4e |...O....NNNNNNNN|
00000480 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 00 00 00 |NNNNNNNNN.......|
00000490 00 00 00 00 00 f5 f5 f5 fb d9 d9 d9 d9 d9 d9 d9 |................|
000004a0 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 d9 |................|
*
00000690 d9 d9 d9 d9 d9 d9 d9 d9 d9 f7 00 00 00 00 00 00 |................|
I have changed track writing in the Git source code, FAFO seems to work now with 11 sectors per track.:ds_icon_cheesygrin: Thank you!
These are the first few sectors in "11a" mode:
On the RDY and disk change signals, how are these expected to work exactly? I also tried to find where the EXDOS ROM is checking RDY, but I could not find it anywhere during simple usage like :DIR or saving a small BASIC program.Disk change: it is working in ep128emu, all that is missing is to set it when a the disk image is changed. in ep128vm.cpp it is initialized during cold reset
if (isColdReset)
floppyDrives[i].setDiskChangeFlag(true);
and it is reset at the right time if (value & 0x40)
vm.wd177x.getFloppyDrive().setDiskChangeFlag(false);
but it is never set from anywhere else - just need to set it when a new disk image is set so the z80 code knows there is a new disk. BIT 7,E ;Test if motor on delay is needed
JR NZ,NO_MOT ;If not then skip.
SET 7,E ;If it is then set motor on flag
;
SET 3,C ;Get current state of /RDY signal
IN B,(C) ; in order to test for a change.
;
LD HL,0E935h ; (E935h*67)/4 = 1000000us = 1s
MOT_LP: IN A,(C) ;14T
XOR B ;5 T Test if /RDY line has changed
RRCA ;5 T
JR NC,NO_RDY ;13T Skip if not
IN B,(C) ; Get new /RDY state
LD A,00CH ; If timeout is more than 50ms
CP H ; from its epiry then set it to
JR NC,NO_RDY ; 50 ms, otherwise leave it alone.
LD H,A
NO_RDY: DEC HL ;7 T Decrement timeout count
LD A,H ;5 T
OR L ;5 T
JR NZ,MOT_LP ;13T Loop 'til expired. 67T per loop
;
NO_MOT: CODE LXI H ;Skip the next instruction.
;
;
NO_DLY: RES 2,E ;For read sectors and verfiy sectors,
; clear "settle delay" flag.
LD (IY+DELAY_FLAGS##),E ;Store new delay flags.
EXDOS 3 fejlesztése közben
Már a 3 készül??? :shock:A prototípus Modell 911-hez készült a 2.0, ami csak DISKIO időzítésekben különbözött az 1.2-től. (Illetve fordítottam 1.3-nak megfelelő 2.1-et is).
Én még csak az Exdos 2.0-ról tudok,
de az ügyben is nagy a titkolódzás! :-)Akkora a titkolódzás, hogy még saját topicja is van (https://enterpriseforever.com/programming/exdos-3-0/) :ds_icon_cheesygrin:
it would work if I set RDY to 0 only when the motor is at full speed and there is a disk image opened, and 1 at any other time? Because of the LED display, there is already a timer that simulates spinning down, so it is not difficult to add a spin up period as well, but it would only affect RDY.Yes that sounds perfect.
In theory, ep_fdd.cpp (https://github.com/istvan-v/ep128emu/blob/master/src/ep_fdd.cpp) sets the disk change flag at line 269 whenever an image file is opened or closed, but maybe this is buggy for some reason?Yes I agree that looks right! I will see if I can reproduce my original problem, maybe it was an EXDOS problem after all.
Akkora a titkolódzás, hogy még saját topicja is van (https://enterpriseforever.com/programming/exdos-3-0/) :ds_icon_cheesygrin:
I made EXDOS look at RDY by copying files to a nearly-full disk. Current EXDOS is very inefficient allocating disk space on a nearly-full disk, so it takes a long time, and the motor turns off before the write.
In EXDOS 1.3/1.4 the code that looks at RDY goes:
Teszt céljára Windows csomag az eddigi javításokkal:Köszi!
You are being very sharp with the 3.0 update.... Disk change was a feature I loved on the A500. When the system asks for a particular system directory\file inside a unique system disk, that signal allowed the OS to ask for the correct disk if the file is not found on the actually inserted disk. MS/DOS can't do it. It is blind to a disk change.I don't know if this is the same thing - in EXDOS it is a performance thing. (It has always been n the code, but nobody knew how to enable it :lol: and it very quickly became outdated anyway as post-1985 disk drives introduced new variations.)
Teszt céljára Windows csomag az eddigi javításokkal:
Ez a verzió kiadható a GitHub-on, vagy van még javítandó hiba?Szerintem mehet.
Feltöltöttem: https://github.com/istvan-v/ep128emu/releases/tag/2.0.11.2-beta2 (https://github.com/istvan-v/ep128emu/releases/tag/2.0.11.2-beta2)Én meg le :-) Köszi!
Nemrég jöttem rá, hogy önmagában az alt+w még nem feltétlen a legnagyobb sebesség. 4 helyett 12 MHz-re állítottam az órajelet, és így használtam az alt+w-t, még gyorsabb lett. Alapból alt+w-vel is eltart egy darabig, mire egy hosszabb basic program lefordul a Zzzippel. A két módszert együtt alkalmazva jelentősen gyorsabb volt a fordítás.
az emuban nincs olyan funkció, amivel az épp a képernyőn látszó videómemóriát lehet valami értelmes módon nézegetni?Pedig pont a Debug menüben lehet. Ha tudod, hol kezdődik a használt videomemóriád, akkor tök jól meg lehet nézni, mi van ott. Múltkor így jöttem rá, hogy miért nem jó az LPT.
sose használtam ezt a debugger részét.
Egy kis furcsaságot találtam: Ha a set working directory-t átállítom, és megnyitok újabb emulátor ablakokat is, akkor azokban még a régebbi directory az aktuális. Ha átállítás után bezárom az emulátort, és utána nyitok meg újabbakat, akkor lesz az új beállítás érvényben.Igen, gondolom kilépéskor menti az emulátor a dolgait :)
- Az EP128 emulátort le lehetne fordítani ... AndroidraValaki már megtette ezt az emulátor testvérével. Lásd a Plus4world fórumát (http://plus4world.powweb.com/forum/34979).
emulátoron file bővítéssel nem tudok betölteni fájlokatMármint :FILE vagy FILE: bővítés?
És oda mutat a munkakönyvtár ahol a fájlok vannak?igen, különben file not found jönne
igen, különben file not found jönneNem lehet, hogy kevés a memória, és pl. 128-ról 256-ra kellene megnövelni? Én amikor ramdisket használtam, akkor az túl nagy volt, megette a memóriát és nem akart betölteni.
És milyen könyvtár? Valami amit te hoztál létre, valami egyszerű C:\EP vagy ilyesmi?én hoztam létre, e: meghajtó
Vagy pedig valami valami Windows által generált agyonbonyolított nevű, vagy az alatt lévő?
én hoztam létre, e: meghajtóGyanús, hogy itt valami NTFS jogosultság gond van. Ha azt a régi könyvtárat saját tulajdonba veszed, akkor nem javul meg?
de érdekes, C:-n működik
az E-n létrehozott meghajtó még win xp alatt lett létrehozva
most win 10 van
Ha azt a régi könyvtárat saját tulajdonba veszed? ez alatt mit értesz?
? ez alatt mit értesz?Jobb klikk a könyvtáron, Tulajdonságok, Biztonság fül, alul Speciális, fönt a Tulajdonos mellett a Módosítás gomb. És ott megadni a jelenlegi Windows felhasználódat.
az emulátorban a debug ablakban lehet valahogy egy byte-ot átírni a memóriában?igen, akár többet is :D
az emulátorban a debug ablakban lehet valahogy egy byte-ot átírni a memóriában?
Miután az A: meghajtóról indítod a 0 nevű batch fájltNa, pont erre nem gondoltam. Valamiért azt hittem, mint egy basic programot, betölti a batch file tartalmát, majd elfelejti, honnan töltötte be és csak végrehajtja. Nem is értettem, hogyan lehet batch file-okat programozni, ha még a sorszámot se írja ki, ahol a hiba történt, és még sorszám sincs.
akkora a file, hogy extra csatorna nyitásnál a csatornának szükséges hely, felülírja a program végét, elméletileg nem kéneAnnyira nem vészesen nagy az a program. A DATA sorok direkt 9000-nél kezdődnek, de renumberrel jóval előrébb kerülnének. Ha új pályákat teszünk be, csak a 9000 utáni sorokat kell lecserélni, és mindig 9000-nél kezdődnek a pályaadatok, így egyszerűbb.
És EXOS 2.4-el?
Lehet, hogy IstvanVHa nem tűnt volna el évekkel ezelőtt :cry:
Erre azt tudom javallani, mivel egér letiltó opciót nem találtam, hogy egérrel pozicionálj oda, és billentyűzettel indítsd a videó felvételt, egér piszkálása nélkül.Az a baj, a felvétel indításához mindenképpen kell egér, az emulátor menüjéhez csak így lehet hozzáférni. De azzal meg lehet oldani, hogy messzire viszem az egérkurzort, miután a menüben kattintottam.
akkor kapcsol be, amikor egy program lekérdezi az egeret, és resetre kapcsol ki.Akkor lehet, nem is praktikus emulátorban kikapcsolhatóvá tenni, ha az a pár program állítja, amelyek használnak egeret.
Az a baj, a felvétel indításához mindenképpen kell egér, az emulátor menüjéhez csak így lehet hozzáférni. De azzal meg lehet oldani, hogy messzire viszem az egérkurzort, miután a menüben kattintottam.Hm, bocs, rosszul emlékeztem, azt hittem, hogy az alt+f a file menübe visz, de az a working directory állítás, nem mintha nem használnám rendszeresen :D
Akkor lehet, nem is praktikus emulátorban kikapcsolhatóvá tenni, ha az a pár program állítja, amelyek használnak egeret.
Esetleg nem lehet olyat, hogy miután megjelent a :FILE fájlválasztó, debuggerben átírni egy-két bájtot, ami az egérfigyelést kilövi?
Legegyszerübb ha előveszel egy régebbi FILE-t, ami még egeretlen :-)Ha jól sejtem, a Mididisp össze van hegesztve a legújabb File bővítéssel, nem lehet másikat tenni be alá. Régebbi File verzió honnan lenne letölthető? Az ep128.hu-n (http://ep128.hu/Ep_Util/Ep_Util.htm) lévő rar-ban, ha jól láttam, a legújabb van csak.
És miért nem a Linux verziót próbáltad? :oops:
Sziasztok!
Próbálkoztam az ep128emu-val. Mivel nincs Windowsom, ezért Virtualboxban Win7-en és XP-n próbáltam, de egyikkel sem jutottam túl a fekete képernyőn. Menü van, működik, de az emuláció nem indul.
Utolsónak kipróbáltam a Wine-ben és csodák csodája elindult. Villog az ENTERPRISE felirat!
Szia!
Nem akartam küszködni a fordítással.
A billentyű konfigurálásnál lehetne egy figyelmeztetés a törlés-hez, hogy az megszüntet minden definiálást és nem lesz billentyűzet! Egy szemvillanás alatt megszüntettem így a billentyűzetemet és nem jutottam tovább a villogó ENTERPRISE feliratnál. Szerencsére csak két kattintás az újratelepítés.Ilyenkor nem kell újratelepíteni. A Load gombra kattintva be lehet tölteni egy, már működő billentyűzetkiosztást. Alapból a C:\ep128emu2\config mappában az EP_Keyboard_HU.cfg és EP_Keyboard_US.cfg áll rendelkezésre, bár még sose próbáltam betölteni. Kimenteni is lehet kedvenc billentyűzetkiosztásunkat, ezt se próbáltam még.
Ep128:Azóta is / most is van OS/2! :-) Csak előbb eComStation -nek hívták, most meg ArcaOS -nek. :-)
OS/2-t használtam, amíg volt...
A fordítás Linux alatt elég nyűgösnek tűnik a leírás alapján -- kihagynám.Megértem, próbálkoztam én is anno, már nem emléxem, hogy sikerült-e végül, vagy nem.
A fordítás Linux alatt elég nyűgösnek tűnik a leírás alapján -- kihagynám.
Kicsit tanácstalan vagyok. 🙁És mivel én a TVC csoport tagja is vagyok ,így ezt az utat láttam legjobbnak :)
Beültettétek a bogarat a fülembe, hogy tegyem bele a DevTool-ba más gépek támogatását is. Futottam néhány kört bemelegítésképp ebben az ügyben csak, hogy felmérjem a lehetőségeket.
Mivel a DevTool fő erőssége a program fejlesztés során a debuggolhatóság, ebből nem vagyok hajlandó engedni: ha lesz más z80-as gép támogatása is, akkor minden támogatott gép esetében működnie kell a debuggernek! Viszont ehhez minden alkalmazott emulátorba be kell építeni a dtdebug.dll támogatást. A dll úgy van felépítve, hogy az emulátorba integrálás a lehető legegyszerűbb legyen. Attila Grosz annak idején játszi könnyedséggel tette bele ezt a fícsört a WinTVC-be. Egyébként Attila jelezte, hogy ha ténylegesen elszánom magam, akkor segít a Primo ill. a HomeLab emulátorokba is beépíteni ezt.
És akkor az Enterprise.. Na ezért vagyok tanácstalan. 🙁
Ahogy nézegettem a legjobb lenne, ha az ep128emu-ba sikerülne beépíteni a dll támogatását. (Ekkor esetlegesen megnyílna az út a Speccy és az Amstrad gépek támogatásához is.) Viszont ehhez be kellene nyúlni az egyébként nyílt forráskódú emulátorba. Ezt egyedül nem tudom megoldani (egyszerűen nincs annyi időm, hogy kitököljem hogyan lehet a cuccot újra fordítani 🙁 ). Beléptem az Enterprise csopiba, és feltettem a kérdést hátha van ott valaki aki tudna ebben segíteni. 3x írtam be a kérdést mindhárom alkalommal eltünt a bejegyzésem. (Valószínű az admin kiszedte: úgy látszik Ők nem tartják ezt fontos dolognak 🙁 ).
Most a TVC csopi tagjait kérdezem: Van-e köztetek valaki, aki tud ebben segíteni? Akár aki bevállalja, hogy belenyúl az ep128emu-ba, akár úgy, hogy ismer valakit, aki ezt meg tudná oldani és hajlandó is lenne erre.
EXOS 2.1 esetén:Köszi, működik! A 00-t átírtam 01-re. Egy idő után visszaáll 00-ra, de nincs túl nagy jelentősége. (Egyébként a :FILE-lal bővített Mididisppel próbáltam, ott a zenéből visszatérés után kapcsol be a click is újra.)