Enterprise Forever

:HUN => Emulátorok => EP128Emu => Topic started by: Lacika on 2006.August.08. 12:46:11

Title: EP128emu
Post by: Lacika on 2006.August.08. 12:46:11
Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra...  :oops:
Title: Re: EP128emu
Post by: MrPrise on 2006.August.08. 13:09:16
Quote from: "Lacika"
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!

Nekem tetszik, de tényleg nem elég felhasználóbarát. Írtam már Istvánnak ez ügyben, de nem nagyon jár erre :-(
Title: Re: EP128emu
Post by: gafz on 2006.August.08. 18:06:58
Quote from: "Lacika"
Szégyenlem, de az Ep128Emu-val nem vergõdtem zöldágra...  :oops:


Csatlakozom. :oops:
Title: Re: EP128emu
Post by: Ep128 on 2006.August.08. 23:42:35
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:
Title: Re: EP128emu
Post by: MrPrise on 2006.August.08. 23:56:24
Quote from: "Ep128"
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:

Nem olyan bonyolult és megéri megismerkedni vele.
Title: Re: EP128emu
Post by: geco on 2006.August.09. 23:14:04
Quote from: "Lacika"
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!


Én leginkább azt használom, ha nincs debuggerre szükség.
Az az egyik fõ hibája, hogy szinte mindent csak image-eken keresztül lehet használni ( kivétel a Floppy meghajtó. ), és ha egy másik image-et szeretnél használni, akkor ki kell lépni a programból, és módosítani a config file-t.
Title: Re: EP128emu
Post by: Zozosoft on 2006.August.09. 23:24:10
Másik hibája, hogy az összes ROM fájlt fel kell aprítani 16K-s darabokra.
Title: Re: EP128emu
Post by: geco on 2006.August.09. 23:31:18
Quote from: "Zozosoft"
Másik hibája, hogy az összes ROM fájlt fel kell aprítani 16K-s darabokra.


Errõl teljesen meg is feledkeztem, az EXOS 2.3-at nem is sikerült beizzítanom.

Az EP32 és az EP128 jól kiegészítik egymást.
Title: Re: EP128emu
Post by: Lacika on 2006.August.10. 08:39:24
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?
Title: Re: EP128emu
Post by: geco on 2006.August.10. 22:53:16
Quote from: "Lacika"
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?


Az .ep128rc config file-ban be kell állitani a használni kívánt disk image-(ek)et, vagy a PC-s floppy meghajtót.

nálam pl.:
disk_a = ./disk/alien.img

Ha a PC-s floppyt akarod használni (csak 2000/XP), akkor:
disk_a = \\.\A:@80,2,9

Egyszerre négy floppy meghajtót lehet használni.

Én disk image-eket használok, a "magnó" használata elég macerásnak tûnik a digizés miatt.
Windows NT/XP/2000 alatt ajánlom a VFD, vagy VFDWIN (Virtual Floppy Driver) programot, amivel a floppy image-eket be lehet mountolni B meghajtóként, így egyszerûen feltölthetõ adatokkal/programokkal.

Magnót, nem használtam sokszor, üres tap file-ba mentettem ki floppyról egy játékot, majd visszatöltöttem. Az itt használatos tap file valójában egy sima WAV file, a config file-ban van egy kis leírás, hogyan lehet bedigizni EP-rõl a file-t, hogy az emulátor is megegye:

; tape files, in 24 kHz mono headerless 1-bit most significant bit first format
; To create a tape from a set of existing files, use tapeutil/tape_enc.
; An empty tape of 'nseconds' length can be created with
;   'dd if=/dev/zero of=tapefile.tap bs=3000 count=<nseconds>'
; It is also possible to save data to tape from the emulated machine (using
; the low transfer rate of 1000 bits/second ('SET FAST SAVE 255', or
; ':VAR 33 255' if available) may reduce the risk of getting CRC errors,
; although the higher rate seems to work in recent versions of the emulator);
; the saved files can be extracted with tapeutil/decode1.
; Copying files from real tapes can be done with tapeutil/decode8; this utility
; can extract data from headerless 48 kHz stereo unsigned 8-bit sound files,
; but the signal must be sufficiently clean (if the recording is of good
; quality, it may be enough to amplify the sound by a factor of at least 10,
; so that it gets clipped to the maximum amplitude, but old tapes may require
; more complex processing).
Title: Re: EP128emu
Post by: Lacika on 2006.August.10. 23:59:06
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?
Title: Re: EP128emu
Post by: geco on 2006.August.12. 06:42:56
Quote from: "Lacika"
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?


Floppy image-dzsel pikoszekundumok alatt betölt mindent. :)

F12, majd ESC, majd F12.

Az F12-vel lehet a billenyûzetet váltani a normál EP billentyûzet, és az emulátorban funkciókkal ellátott billentyûk között.
Title: Re: EP128emu
Post by: osva on 2008.January.15. 16:54:47
Az én pc-men nincs floppy a merevlemezre mentettem csomó játékot,de nem tudom elindítani őket. mi a legegyszerübb modja? nincs ehhez magyar leírás?

az ep32 szerintem egyszerübb csak ott meg nem megy a joy.
oldjuk már meg a problémát, napok óta csak kepesztek.
Title: Re: EP128emu
Post by: Lacika on 2008.January.15. 19:17:30
Itt (http://www.ep128.hu/Ep_Emulator.htm) Az Ep128Emu-ról szóló részben olvasható a megoldás: VIRTUAL FILE I/O menüpont.
Title: Re: EP128emu
Post by: osva on 2008.January.15. 21:50:07

hello!

ujabb ep128emu kérdés. remélem az utolsó.



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?
Title: Re: EP128emu
Post by: IstvanV on 2008.January.15. 22:28:51
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?

A FILE: eszközt kell használni, azaz 'start "file:"' ha a játék csak egy file - ami nem túl gyakori - vagy ':def_dev_file' és aztán egyszerűen 'start'. A def_dev_file után a FILE: az emulátorból való kilépésig, vagy más eszköz (:def_dev_tape vagy :def_dev_disk) beállításáig marad alapértelmezett.
Title: Re: EP128emu
Post by: szipucsu on 2008.January.15. 22:36:48
Arra gondoltam, aki már kitapasztalta, írhatna egy "lépésrõl-lépésre receptet" errõl az emulátorról, hogy hogyan kell pl. betölteni egy játékot, mert úgy látom, sokaknak problémái vannak ezzel. Szerintem egy szájbarágós lépésrõl-lépésre recept is jól jönne. Bevallom, én sem használom ezt az emulátort, mert amikor elõször elindítottam és megnéztem a lenyíló menüket, annyira megijedtem, hogy el se mertem többet indítani. Tudom, elõször mindenki olvassa el a használati utasítást, a helpeket, de sokaknak nagy segítség lenne egy ilyen "recept". Csupa jó dolgot olvastam a debuggerrõl és hasonlókról, szóval biztos nagyon tuti emulátor lehet.
Szerintem itt a fórumon a fõoldalon lehetne egy link az emulátorok használatáról, és az idetévedõ rögtön képben lenne. Engem is kerestek frissen regisztráltak emulátor ügyben, aztán nem tudtam az EP128-ról mondani semmit sajnos.
Title: Re: EP128emu
Post by: Ep128 on 2008.January.16. 00:32:46
Ezt megerõsíthetem, engem is kerestek, és én sem tudtam válaszolni.  :oops:
Ok, én a mai napig is floppy -ról töltögetek programokat, ha Ep -rõl van szó, de aki nem szeret (nem tud) flopy -ról betölteni, azoknak jó volna egy "lámpa gyújtás kezdõknek" -féle szájbarágós útmutató.
 ;-)
Title: Re: EP128emu
Post by: MrPrise on 2008.January.16. 00:57:02
Arról, hogy még mindig nincs hozzá részletes leírás én is tehetek. Ugyanis még régebben megígértem Istvánnak, hogy majd csinálok hozzá egyet.
Ebben tudtok ti is segíteni. Először is írjátok le mit szeretnétek tudni ami nem derül ki első ránézésre vagy nem világos a működése. István ugyan eddig is megválaszolta itt a felmerülő kérdéseket, de gondolom ő is jobban örülne ha lenne egy részletes leírás az emuhoz, amit elég lenne mindig csak frissíteni. Talán a legjobb lenne a wiki-t használni erre a célra, mivel azt mindenki tudja szerkeszteni (regisztráció után). Oda beírhatjátok a kérdést, problémát, aki megtalálja rá a választ korábbi hozzászólásban az másolja oda ill. aki tudja rá a választ, az írja meg rá.
Title: Re: EP128emu
Post by: gafz on 2008.January.16. 13:21:34
Csatlakozom az EP128 leírást kérõk táborához :)
Title: Re: EP128emu
Post by: Zozosoft on 2008.January.16. 16:36:45
Én Istvánnak javasolnék két dolgot, amivel szerintem javulna a progi felhasználóbarátsága:
1) ennél a FILEIO-s ROM-nál legyen alapértelmezett a FILE: periféria használata
2) valódi floppy lemez használatához kéne egy külön gomb, pl "Disk in drive A:" vagy hasonló... azt a sokperjeles dolgot amit most be kell írni, még én se tudtam fejbõl megjegyezni, mindig Laci oldaláról puskázok, hogy mit is kell beírni :-)
Title: Re: EP128emu
Post by: osva on 2008.January.16. 21:48:49



ez nekem kínaiul van.
tehát: 1 beállítom az I/O-t  2 beállítom a rom-ot  3 beállítom a working directoryban a mappát amiben a játékok vannak (vagy magát a tölteni kívánt játékot?)

4 ezután pirosan villog a kurzor az OK alatt.
5 ha beírom hogy START "def_dev_file" akkor hibát jelez
6 ha beírom hogy START "file"  akkor is

valamit tuti hogy nem jól csinálok , csak azt kéne megtudnom,hogy mit.

lépésről lépésre szájbarágósan kéne leírni,mert én 20 éve is hülye voltam az enterpriséhez,csak játszani szerettem,és ez nem sokat változott azóta.
Title: Re: EP128emu
Post by: Zozosoft on 2008.January.16. 21:55:17
5) azt kell beírni, hogy:
Code: [Select]
:def_dev_fileaztán csak simán START
Title: Re: EP128emu
Post by: osva on 2008.January.16. 22:09:39


beirom hogy :def_dev_file és entert nyomok akkor not under...   mi az hogy aztán start?
Title: Re: EP128emu
Post by: Zozosoft on 2008.January.16. 22:18:22
beirom hogy :def_dev_file és entert nyomok akkor not under...
Akkor nem fileio-s konfigod van betöltve!
File/configuration/load from ASCII file
Itt válaszd ki a EP_128k_Tape_FileIO.cfg-t
Utána mehet az I/O beállítás, working directory.
És ezután a :def_dev_file
mi az hogy aztán start?
Beírod, hogy START, vagy megnyomod az F1-et.
Ezután felbukkan egy fájl kiválasztó ablak, hogy melyik fájlt akarod betölteni a PC-s könyvtárból.
Title: Re: EP128emu
Post by: osva on 2008.January.16. 22:27:24


megint not understood

ha utára startolok, akkor searching piros téglalappal
Title: Re: EP128emu
Post by: IstvanV on 2008.January.17. 11:04:23
megint not understood

Ez azt jelenti, hogy vagy nem állítottad be megfelelően a ROM konfigurációt, vagy a :def_dev_file-t írtad be rosszul. De talán egyszerűbb, ha letöltöd ezt (http://www.sharemation.com/IstvanV/epfileio.snapshot.zip), és a .zip-ben található epfileio.snapshot file-t (nem a zip-et !) betöltöd a "File/Load snapshot" menü használatával, utána elég kétszer lenyomni az 'Enter'-t. Előbb azonban ne felejtsd el engedélyezni a "Machine/Configure.../Enable virtual file I/O"-t és beállítani az "Options/Set working directory"-t.
Title: Re: EP128emu
Post by: MrPrise on 2008.January.17. 11:16:26
Elkezdtem a wiki-n csinálni a leírást. Jelenleg a magnóról betöltésnél járok. Akinek van kedve/ideje nyugodtan írjon hozzá/bele, akár kérdéseket is.
Title: Re: EP128emu
Post by: osva on 2008.January.17. 11:43:19
a load snapshot új office dokumentumnak látja és nem tölti be.
tényleg nehéz eset vagyok,de tartsatok ki.
Title: Re: EP128emu
Post by: osva on 2008.January.17. 11:48:37
a working directoryban a játék nevét még látom,de ha belelépek akkor a com. prg. scr. stb-t már nem. ez baj?
Title: Re: EP128emu
Post by: osva on 2008.January.17. 21:27:16


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.

szóval köszi a segítséget,be tudtam tölteni végre a játékot!!

a probléma viszont ua mint az ep32-nél :nem tudom a pc joyra belőni.   a keyboard mapban beállítom,aztán mégsem műkődik.

a :def_dev_file móka viszont teljes csőd,pedig halál pontosan végigcsináltam kb 30szor.
Title: Re: EP128emu
Post by: Ep128 on 2008.January.17. 21:35:59
Tanulság: Mégis csak kell az a fránya floppy meghajtó abba a PC -be. ;-)
Mennyivel egyszerûbb a ":i"  után a nyilakkal kiválasztani az indítandó file -t, és Enter...  ;-)
Title: Re: EP128emu
Post by: MrPrise on 2008.January.17. 22:18:26
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.
Title: Re: EP128emu
Post by: osva on 2008.January.18. 15:25:07


S.O:S.

valaki mondja meg hogyan tudom pc gamepadal irányítani a játékokat bármelyik emun. minden megoldás érdekel,csak kipróbált legyen.
Title: Re: EP128emu
Post by: MrPrise on 2008.January.18. 16:11:06
Bedugod a gamepadot a PC-be, elindítod az EP128Emu-t, bemész a Options|Keyboard map-ba, szépen sorban végignyomkodod a Joystick 1 (Ext 1) paneljén lévő 4 irányt és a tüzet, minden kattintás után a megfelelő irányt kell megnyomni a gamepadon ill a tüzet. Két gombot lehet megadni, ha a másodikat nem akarod beállítani, akkor ott F9-et kell nyomni. Ja és persze az Enable Joystick legyen bejelölve bal oldalt.
Elméletileg így megy, de nekem a jobbra, balrával van egy kis gond. Konkrétan: azzal megy jobbra amit balrának állítottam be, amivel jobbra kellene mennie az viszont nem csinál semmit. Bármit állítok a jobbra-balrának be, mindegy. Bill-t is próbáltam, azzal is így csinálja. A többi irány ok.
Joystick 1-nek próbáltam meg beállítani. Ha belső joynak állítom be akkor nincs gond.
A 2.0.5.1-es verziót próbáltam.
Kipróbáltam Joystick 2 / Ext2-t is, azzal a jobbra jobbra megy, de amit balnak állítottam be az semmit sem csinál.
Szóval osva, amíg István nem orvosolja ezt a gondot, használd belső joystickra állítva!
Title: Re: EP128emu
Post by: osva on 2008.January.18. 17:10:43


végül ext 1-re sikerült beállítanom,teljesen jók az irányok is. köszi. remélem a batmannél a shift-et is sikerül a gamepadra varázsolnom.
Title: Re: EP128emu
Post by: MrPrise on 2008.January.18. 17:19:59
Hm, akkor lehet a hiba az én készülékemben van?
Title: Re: EP128emu
Post by: osva on 2008.February.02. 19:47:18
hello!

 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?
Title: Re: EP128emu
Post by: szipucsu on 2008.February.02. 21:01:42
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?

Szerintem az lehet a gond, hogy a játékokat mindig a COM vagy TRN fájlra kattintva lehet elindítani (Na jó, Batman-nál APL, ami helyett elegánsabb lett volna a TRN...). Ha egybõl PRG vagy SCR fájlt akarsz betölteni pl. basicbe, akkor annak tényleg lehet az az eredménye, amit írsz.
(Itt off, de miért maradt a Batman indítófájlja APL, miért nem TRN? Ha a neten valahol így van fent, át kéne nevezni TRN-re. Ezt majd átmásolom valamelyik másik topikba, ahol on a téma... Ja, ha osva saját kazettáján/lemezén van így, akkor bocsi.)

Egyébként ami APL kiterjesztésû Batman file van neked, olyan nekem is volt, és annak nincs is screenje. Lehet, hogy a program hibás.

Egyébként én osva módszerével a több fájlból álló programokat nem tudtam betölteni az emuba, mert az elsõ fájl után nem töltött tovább, de ez egyelõre az én problémám, mert nem olvastam el végig minden dokumentációt az emuhoz.
Title: Re: EP128emu
Post by: Z80System on 2008.February.02. 21:32:13
Nekem is frankon mukodik ez a :def_dev_file dolog (meg a :def_dev_disk, :def_dev_tape is, olyannyira, hogy nagyon elgondolkodtam, hogy ez a ketto meg eredetileg EP- n miert nem volt megvalositva ? Ott is hasznosak lettek volna. na mindegy ...), szoval probalkozz csak, menni fog:

legyen a config file- ban az epfileio.rom egyik szegmensre berakva, legyen engedelyezve a configuracional az "enable virtual file I/O", legyen a "set working directory" a helyes PC konyvtarra beallitva, es ha beindult az emulalt ep, legyen beirva a :def_dev_file

innentol kezdve egy

load "valami.com"
load "valami.trn"
load "valami.dem"
load valami.app"

hibatlan toltodeseket szokott eredmenyezni nekem a PC konyvtarbol. kb ez a fontossagi sorrend is, ha valamibol van tobbfajta kiterjesztesbol is, celszeru ebben a sorrendben probalni ki.





Title: Re: EP128emu
Post by: Z80System on 2008.February.02. 22:03:51

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


Title: Re: EP128emu
Post by: Zozosoft on 2008.February.02. 22:09:13
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 elsõ esetben az EXDOS.INI-t keresi a gép, a másodikban meg ha jól értem 1.5-ös ASMON-ról van szó, az is keresi a saját ini fájlt.
Title: Re: EP128emu
Post by: Z80System on 2008.February.02. 22:22:16

:) Lassabb a PC floppy- mint az EP- e ??? :) Az mar oreg hiba ... :) EP rules! Legyozte a 3Gigas p4- et ... :)


Title: Re: EP128emu
Post by: Z80System on 2008.February.02. 22:53:54

Es milyen reszeken kene valtoztatni ahhoz, hogy ez eltunjon ? Azt hogy gyorsabb valami es nem 100% ugyanolyan sebessegu meg megbocsajtja az ember, de hat 700 billiardszor gyorsabbak vagyunk mint anno, ne legyen mar lassabb ... Ez valami emulator hiba, hogy mittomen bizonyos layer alatt (gondolom kb. ugy a hardvereleres korul) mar nem azok a kodok futnak mint ep- n, hanem PC- n implementalt kodok, de elkepzelhetetlennek tunik szamomra, hogy ez lassabb legyen mint EP- n. A Floppy HW/driver nem hinnem hogy lassabb mint anno volt, a kod meg ugye sokszor annyi sebesseggel is futhatna... mit nem ertek ? Nem mintha tudnam hogy emulalodik le egy floppy HW, de akkor se hinnem hogy lassabb kene legyen.
Title: Re: EP128emu
Post by: osva on 2008.February.03. 17:00:15
 :)

megvan a megoldás. a working dirctoryban nem a mappát jelölöm be amiben a játékok vannak,hanem a játszani kívánt játékba lépek be (egyébként üresnek mutatja a gép). ha ezután start-olok és kattintok a com v trn file-ra 100%-os a sikeres betöltés,bármit próbáltam bejött.
nem értem,de működik.
Title: Re: EP128emu
Post by: Z80System on 2008.February.03. 17:51:44

A working directory nem mukodik rekurzivan, nem lehetnek mar benne konyvtarak (illetve lehetnek, csak ne probaljon meg tolteni azokbol semmi, mert nem mukodnek, mintha ott sem lennenek), szoval egy program osszes resze, konyvtarszerkezet nelkul a working directory - ban kell legyen. Ha

valami.com
valami.scr
valami.dat

egy program reszeit kepezik, es valami.com inditasa utan tolti valami.scr -t es valami.dat -ot, akkor mindharom file kozvetlenul a working directory- ban kell legyen.

Ha a harom file egy sajat, a parogramra vonatkozo "valami" nevu konyvtarban van, akkor ennek a "valami" nevu konyvtarnak kell a working directory- nak lennie.

Hogy ez azt jelenti- e, hogy ha az ep programjaink (elegge el nem itelheto modon) kulon konyvtarakban vannak, akkor minden program betoltese elott working directory- t kell valtsunk ?! Hat igen, sajnos igen. En azt szoktam, hogy atmenetileg osszemasolok mindent egy atmeneti konyvtarba ami working directory lesz, igy megtalal mindent, es kis szerencsevel nem lesz a masolaskor nevutkozes sem, persze ez nem garantalt.

A legjobb az lenne, hogyha mar ki lehet valasztani egy ures load- nal a betoltendo file- t, akkor automatikusan a betoltott programot tartalmazo konyvtarra atvaltana a working directory. De nem valt. A budos. :) Kene meg melle egy pipa a menube, hogy autoselect working directory, es akkor igy mukodhetne... :) Beszeld meg a szerzovel. Es akkor akarmit lehet majd tolteni akarhonnan kenyelmesen.

Title: Re: EP128emu
Post by: Z80System on 2008.February.03. 22:06:08
Hopp, megvan hogyan lehet kikuszobolni a hosszu varakozast,
felinstallaltam VFD- t, es betettem mind a negy lemeznek egy VFD- s drive- ot,
ettol franko "gyors" lett, mint EP- n ... :)

Nem tom hogy kell- e mind a negy feltetlen, nem eleg- e mondjuk csak egy, de az bizta ha mind a negy bent van, akkor nincs extra varakozas. Hurra.
Title: Re: EP128emu
Post by: Attus on 2008.September.26. 20:35:36
Nekem edigg ez az egyetlen, mely megy linux alatt!
Title: Re: EP128emu
Post by: nyuzga on 2008.September.26. 21:04:48
Az emulátor tényleg szuper. Újra 30 évesnek érzem magam. :)
Title: Re: EP128emu
Post by: Attus on 2008.October.01. 14:28:17
:smt084
ep128emu bug ?
Az ep18emu-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.
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. Lehet, hogy az emu nem szabadítja fel a használt memóriát a reset-nél és sok reset után elfogy a hely? Vagy a forrásból történt fordításnál szúrtam el valamit? Csak linuxos a bug ??  :cry:
Ujabb: UHU 2.0 alá is lefordítottam, ott tök jónak tűnik. Nyúzni fogom!
Title: Re: EP128emu
Post by: IstvanV on 2008.October.01. 22:47:21
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.
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.
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.
Quote
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 ?
Title: Re: EP128emu
Post by: Attus on 2008.October.02. 18:28:22
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:
A bináris installállhatatlan UHU alá elég sok függőségi probléma miatt, kibróbálni ezért nem tudtam.  :!:
Ezért kényszerültem a fordítással való telepítésre, ahol még egy pár csomagot (fltk, dotconf, portaudio, a 2.0 alá a jack is) szintén forrásból kellett feltelepíteni előbb. :???:
Title: Re: EP128emu
Post by: Attus on 2008.October.03. 22:43:16
  :smt038 Egyszerűen szuper a disk img kezelés Linux alatt. Nem kell hozzá külön segéd, mint a Winfoson a VDISK. Egyszerű mount szkriptet ítam, minden terminál ablakban elintézhető, tartalomjegyzék készíthető és pl az MC -vel máris rendeztem  a lemezeimet.
  :smt031 Óriási ez a bash! Pezseg tőle régi crackeres vénám. Köszönet, hogy az emu linux alatt is megy!  :bow:
Title: Re: EP128emu
Post by: endi on 2008.October.03. 22:59:37
Valaki mondja már meg hogy a felvett videót mivel lehet más formátumba konvertálni? A Virtualdub nem ismeri a codecet.
Title: Re: EP128emu
Post by: Attus on 2008.October.03. 23:09:35
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!
És az magyar!  :)
Winfos alatt is van. Igaz, hogy parancssororos, de szuper! Én a TV felvételeket is azzal kódolom át bármifélére egyszerű szkripttel. Winfos alatt is kipróbáltam, de Linux alatt az igazi. Szokj rá! Nem vagy te csak egyszerű kattintgatós szerzet szerintem. :smt039
Title: Re: EP128emu
Post by: IstvanV on 2008.October.03. 23:10:22
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 :)

Egy egyszerű példa, az alábbi parancs 2048 kpbs MPEG4 video és 256 kpbs mp3 audio formátumra konvertál:
Code: [Select]
mencoder -oac lavc -ovc lavc -lavcopts acodec=mp3:abitrate=256:vcodec=mpeg4:vbitrate=2048 -o video_mpeg4.avi video_rle8.avi
Title: Re: EP128emu
Post by: Attus on 2008.October.03. 23:19:10
É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?)
Title: Re: EP128emu
Post by: endi on 2008.October.04. 00:17:56
áh már megint egy új programot megtanulni...
nem férnek már bele a fejembe ezek a dolgok
Title: Re: EP128emu
Post by: nyuzga on 2008.October.04. 08:18:38
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.

DE nem árt még feltelepiteni a K-Lite Codec Pack-ot. (http://www.szoftverbazis.hu/szoftver/?id=JW12)
Title: Re: EP128emu
Post by: Attus on 2008.October.04. 19:56:27
áh már megint egy új programot megtanulni...
nem férnek már bele a fejembe ezek a dolgok
  :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.
Érdekes, hogy a két linuxos szinte egyidőben a Mencoder-t ajánlotta. Nemde?  :ds_icon_cheesygrin:
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 16:52:00
Hogy lehet átírni a memóriát az emu debuggerjével?
Title: Re: EP128emu
Post by: Zozosoft on 2012.May.11. 17:37:18
Hogy lehet átírni a memóriát az emu debuggerjével?
>cím érték érték érték...
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 18:02:22
Köszi és regisztert?
Title: Re: EP128emu
Post by: Zozosoft on 2012.May.11. 18:08:48
Köszi és regisztert?
r-rel lekérdezd, visszamész, átírod.
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 18:11:14
Na közben rájöttem hogy kérdőjelre kidob helpet és az mindenre választ ad.
Title: Re: EP128emu
Post by: IstvanV on 2012.May.11. 18:31:44
Na közben rájöttem hogy kérdőjelre kidob helpet és az mindenre választ ad.

Az egyes parancsokról valamivel részletesebb információt is ki lehet íratni, például ? TR.
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 18:40:25
Van lua scripted ami megmondja éppen mi okozta az INT-ot amiben vagyok?

bruce lee interrupt rutin kezdete:

  0038  F5           PUSH  AF
  0039  E5           PUSH  HL
  003A  21 78 5C     LD    HL, 5C78
  003D  00           NOP
  003E  E1           POP   HL
  003F  3E 30        LD    A, 30
  0041  D3 B4        OUT   (B4), A
  0043  F1           POP   AF
  0044  C3 03 C0     JP    C003

Mit csinál a B4h portra küldött 30h? megj: Érdekes az az LD HL :)
Title: Re: EP128emu
Post by: Zozosoft on 2012.May.11. 19:15:04
Mit csinál a B4h portra küldött 30h?
Videómegszakítás engedélyezése.

Quote
megj: Érdekes az az LD HL :)
Nyomokban Spectrum ROM rutint tartalmaz :-)
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 20:51:07
Gondolom az engedélyezés a logikai 1 és ha nem törlöm az INT1 és INT2 tárolókat attól még keletkeznek a továbbiakban is megszakítások, az csak az ISR -nek jelzés. Viszont nem értem miért áll meg a játék ha itt a 30-at kicserélem 10-re, tehát megszakítások továbbra is keletkeznek, viszont a továbbiakban nem olvassa a B4 portot, akkor honnan tudja mi okozta az interruptot?
Title: Re: EP128emu
Post by: Mayer Gábor on 2012.May.11. 21:43:37
Jah hogy pont ez a gond, hogy folyamatosan interrupt keletkezik és nem tud továbbmenni a főprogram.
Title: Re: EP128emu
Post by: csigabig on 2012.May.25. 21:56:27
Hogy tudom használni a hdd emuba ?
Benne van csak nem tudom hogy kell kilistáztatni a hdd tartalmát !!

Üdv Csiga
Title: Re: EP128emu
Post by: Zozosoft on 2012.May.25. 22:34:13
Hogy tudom használni a hdd emuba ?
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.
Title: Re: EP128emu
Post by: csigabig on 2012.May.25. 23:03:49
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 !!
Title: Re: EP128emu
Post by: csigabig on 2012.May.25. 23:12:04
Ez meg van csak nem tudom a parancsot amivel kitudom listázni a particiok tartalmát !!

Közben már meg van csak rá kell erre is érezni.
Tisztára mint a dos !! :)
Jó lenne egy NC = Norton Commander szerü program Epire !!
Title: Re: EP128emu
Post by: Zozosoft on 2012.June.16. 13:29:50
HSOFT féle FILE fájlválasztó eszköz módosítva, hogy ha rendelkezésre áll az István féle virtuál I/O FILE: eszköz, akkor annak a nevét adja vissza, így a FILE-t használó programoknál virtuál file I/O esetén nem a lemezen próbál keresgélni, hanem a Windowsos fájlválasztó ablak jelenik meg ahogy a sima LOAD esetén is ilyenkor.

Azt ezt tartalmazó ZT is frissítve.
Title: Re: EP128emu
Post by: Lacika on 2012.July.16. 08:47:29
Azt lehet tudni, hogy az emulátór mit kezd az USB-s floppy meghajtókkal?
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.07. 11:27:20
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.
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.07. 11:43:36
Találtam egy kis emulátor bug-ot:
Itt (http://enterpriseforever.com/cpcr337l/pinball_power-t580.0.html;msg21403#msg21403) volt szó arról, hogy NMOS Z80-ak bugosak az LD A,I/R utasításoknál.
Az EXOS 2.4 már ki is írja a CPU típusát induláskor, ehhez találtam egy egyszerûbb módszert: (http://mamedev.org/source/src/emu/cpu/z80/z80.c.html)
Az EDh,71h kódú utasítás, ami az utasítás táblázatban a helye alapján OUT (C),F lenne (HEASS így ismeri), a netes Z80-as köznyelv szerint OUT (C),0-ként szerepel (emulátor debugerben így szerepel), 0-t küld ki NMOS procival, FFh-t CMOS procival.
Tehát pl így nagyon egyszerûen lehet tesztelni:
Code: ZiLOG Z80 Assembler
  1. LD C,0B1H
  2. OUT (C),0
  3. IN A,(0B1H)
  4. OR A
  5. JR Z,NMOS

Ez mûködik is valódi gépen, több darabon is próbáltam, a Z80bug progival is ellenõrizve a eredményt.

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. Ha jól sejtem ez utóbbi a könnyebb megoldás :-) ha jól tippelem itt kell a 0-át átjavítani:
Code: [Select]
    case 0x071:
      {
        doOut(R.BC.W, 0);
        ADD_PC(2);
        R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
      }
Title: Re: EP128emu
Post by: geco on 2012.August.07. 15:38:25
Szuper, pár programban használtam az OUT (C),0-át a DAVE regisztereinek nullázására :(
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.07. 15:48:02
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?
Title: Re: EP128emu
Post by: geco on 2012.August.07. 17:00:18
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.
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.11. 12:46:49
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.
Title: Re: EP128emu
Post by: Lacika on 2012.August.11. 17:27:10
Módosított, CMOS Z80 emulátor.

Istvánt elõ kellene keríteni, csinálni "hivatalos" install-os verziót a honlapjára.
Title: Re: EP128emu
Post by: Lacika on 2012.August.11. 18:24:21
Hmm, lehet, hogy ez csinálta a zúgást az IK-ban egyes gépeken?

Kipróbáltam a Zozo-féle javított emuval az IK+ Reload-ot. Bizony, így már zúg!
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.11. 19:14:42
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!

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);
Title: Re: EP128emu
Post by: Lacika on 2012.August.11. 19:32:14
Igen, már csak a korábbi hibajavítások miatt is!]

Ezek szerint ebben benne van az a javítás is, miszerint a debugger lapon két mezõ értéke fordítva jelent meg?
Title: Re: EP128emu
Post by: Lacika on 2012.August.11. 19:33:26
Van még egy bosszantó bug: Windows 7 alatt nem tud floppyra írni az emulátor  :(

Még szerencse, hogy eddig nem váltottam át rá...
Ez - ezek szerint - addig biztosan nem fog megtörténni, amíg ez a hiba nincs javítva.  :ds_icon_cheesygrin:
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.11. 19:43:03
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)
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.14. 10:28:34
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:
Title: Re: EP128emu
Post by: Lacika on 2012.August.14. 11:00:26
Ezekbõl lehetne kérni akkor egy javított verziót?  :oops:

Ezt már én is meg akartam kérdezni...  :oops:
Title: Re: EP128emu
Post by: geco on 2012.August.14. 14:34:08
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:
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
Title: Re: EP128emu
Post by: IstvanV on 2012.August.14. 16:06:04
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

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.
Title: Re: EP128emu
Post by: IstvanV on 2012.August.14. 17:29:50
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.

Az ep128emu az eredeti (tehát NMOS Z80-as) EP-t próbálja emulálni, több-kevesebb sikerrel. Az LD A, I és LD A, R hibássá tétele új programok fejlesztésénél, vagy tesztelésnél lehet hasznos, az nem valószínű, hogy valami csak akkor működik jól, ha ezek az utasítások hibásak. A hiba felismeréséhez itt egy egyszerű teszt program:
Code: ZiLOG Z80 Assembler
  1.         org   00f0h
  2.         defw  0500h, codeEnd - main, 0, 0, 0, 0, 0, 0
  3.  
  4.     macro exos n
  5.         rst   30h
  6.         defb  n
  7.     endm
  8.  
  9. main:
  10.         di
  11.         ld    sp, 0100h
  12.         ld    a, 0ffh
  13.         out   (0b2h), a
  14.         ld    hl, resetRoutine
  15.         ld    (0bff8h), hl
  16.  
  17.         ld    hl, 0e9ddh                ; = JP (IX)
  18.         ld    (0038h), hl
  19.         ld    ix, .l2
  20.         ld    a, 03h
  21.         out   (0b4h), a
  22. .l1:    in    a, (0b4h)
  23.         and   02h
  24.         jr    z, .l1
  25.         ei
  26.         ld    a, i
  27. .l2:    pop   hl
  28.         ld    a, 30h
  29.         out   (0b4h), a
  30.  
  31.         ld    a, 92h
  32.         jp    pe, .l3
  33.         rrca
  34. .l3:    out   (81h), a
  35. .l4:    jr    .l4
  36.  
  37. resetRoutine:
  38.         di
  39.         ld    sp, 0100h
  40.         ld    a, 0ffh
  41.         out   (0b2h), a
  42.         ld    hl, resetRoutine
  43.         ld    (0bff8h), hl
  44.         ld    c, 40h
  45.         exos  0
  46.         ld    a, 01h
  47.         out   (0b3h), a
  48.         ld    a, 6
  49.         jp    0c00dh
  50.  
  51. codeEnd:
Title: Re: EP128emu
Post by: Zozosoft on 2012.August.14. 21:26:51
A legtökéletesebb megoldás az lenne, ha lenne egy CPU beállítás a Configure alatt, hogy NMOS vagy CMOS  :oops:
Title: Re: EP128emu
Post by: geco on 2012.August.15. 08:49:50
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:
Title: Re: EP128emu
Post by: Ep128 on 2012.November.13. 23:28:50
Quote from: Zozosoft
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  :(
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);
Sajnos csatlakozni kényszerülök ehhez, mert nem csak Windows 7, hanem Pista (Vista) alatt is ugyanez a gubanc!
István, ha látod ezt az üzenetet, kérlek reagálj! (Köszi! :-) )
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.14. 22:56:54
Az itt (http://enterpriseforever.com/jatekok/eggs-of-death/msg28681/#msg28681) említett WAV gyártás nem volt zökkenő mentes :-(
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.
Kipróbáltam úgy is, hogy más programmal veszem fel a hangkártya wave kimenetét, de ugyanez lett az eredmény.
A megoldás az lett, hogy valódi gépen futtattam a mentést, és az EP kimenetét kötöttem a PC hang bemenetére, és vettem fel WAV-ba.

István van ötleted, mitől nem sikerült az emulátorral?
Title: Re: EP128emu
Post by: IstvanV on 2012.November.15. 18:02:26
Quote from: Zozosoft
Az itt (http://enterpriseforever.com/jatekok/eggs-of-death/msg28681/#msg28681) említett WAV gyártás nem volt zökkenő mentes :-(
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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.15. 18:48:50
Quote
Ezt egészen pontosan hogyn tudnám tesztelni ?
Itt egy komplett save csomag
:EXDOS SAVE.BAT
RAMDISK-ből csinálja, hogy az esetleges lemezkezelés miatti akadás is ki legyen zárva.
Ezt Record Audio-val felvenni.

Betöltéskor 014ex breakpoint kell, majd
s "s" 0 8000 a7ff
s "p" 0 0480 7ddd
És összehasonlítani az eredeti scr és prg fájlokkal.

Itt (http://enterprise.iko.hu/emulatorbol.zip) van a WAV is, amit nekem sikerül így az emuból felvenni, az scr az ok, a prg eleje hibás.

Valódi gépről felvett hanggal rendben működött a dolog.
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 11:08:46
Na ez most egyre érdekesebb!
Kipróbáltam egy másik számítógépen, ott jól működik!

Vajon mi lehet a hiba oka? Windows? Hangkártya? Egyáltalán a hangkártyának van köze ehhez, vagy saját magában veszi fel a kiküldött hangot?

Amin gépen nem jó: Windows 7 64 bit, Asus Xonar DS
Amin most működött Windows XP, több mint 10 éves ESS Maestro2

Jó lenne ha a többiek is kipróbálnák, náluk mi a helyzet.
Title: Re: EP128emu
Post by: szipucsu on 2012.November.16. 11:54:52
Quote from: Zozosoft
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...
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 13:23:23
Quote from: szipucsu
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.
Ezt már jó pár másik programmal megcsináltuk, a sima EP magnó formátumú programokkal ez könnyű, gond ezekkel a másolásvédett programokkal van, ahol a gyári kazettáról wav-ba felvétel a lehetséges út, azonban a magyar kazettákban használt borzalmasan pocsék szocialista gyártmányú szalagok miatt sokszor az is lehetetlen, hogy használható WAV legyen, és még ha ez sikerül is nagy nehezen, akkor meg a TAP-ba konvertáló progi nem tudja feldolgozni.

Jelen esetben szerencsésen előkerült a gyári kazettára a csipogást előállító eredeti program, így lehetséges az, hogy a folyamatból kihagyjuk a 25 éves Polimer kazetta által okozott minőségromlást.

A dolog működik is, csak felmerült az a probléma, hogy nem minden gépen működik a legegyszerűbbnek gondolt módszer, azaz, hogy az ep128emu beépített hangfelvevő funkciójával vegyük fel a program által előállított csipogást.
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 13:36:49
Kipróbálás: az eggsave.zip tartalmát kimenteni egy lemezre.
Emulátorban betölteni egy sok ramos EXDOS-os konfigot.
:EXDOS SAVE.BAT
Ez bemásolja a RAMDISK-be a mentendő cuccot, majd vár egy ENTER-re.
Ekkor elindítani az emulátor Record Audio funkcióját, majd nyomni egy Entert, ekkor elkezdődik a kimentés.
Végigvárni a csipogást (kb 3 perc), majd Record Audio Stop.
Ezután betölteni egy magnós konfigot, töltésnél az elöbb felvett WAV-ot megadni kazettának (ALT+T, majd ALT+P a magnó indítása).
Töltés elött adjuk meg a debuggerben (ALT+B) töréspontnak: 014ex (a 2. oldalon a jobb felső ablak).
Ekkor a program meg fog állni a betöltés után, bejön a debuger.
Itt kimentjük a képernyő ill. programmemóriát, hogy összehasonlítsuk az eredeti adatfájlokkal.
Mikor bejön a debugger, akkor a második oldalon a bal felső parancs ablakba kell ezte a két sort beírni:
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.
Title: Re: EP128emu
Post by: IstvanV on 2012.November.16. 13:52:31
Az hiba, ha a mentés végén a SAVE.BAT keretcsíkozással lefagy ? :oops:
Title: Re: EP128emu
Post by: IstvanV on 2012.November.16. 13:59:45
Quote from: Zozosoft
Mikor bejön a debugger, akkor a második oldalon a bal felső parancs ablakba kell ezte a két sort beírni:
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.
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:
Code: [Select]
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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 14:08:41
Quote from: IstvanV
Az hiba, ha a mentés végén a SAVE.BAT keretcsíkozással lefagy ? :oops:
Nem, ezzel jelzi, hogy végzett.
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 14:13:49
Quote from: IstvanV
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 :-(
De itt a munkahelyi gépen meg egyből jó. Majd próbálok más gépeket is, meg otthon más windowst is.
 
Ennek a hang felvétel funkciónak van köze a hangkártyához?
Title: Re: EP128emu
Post by: IstvanV on 2012.November.16. 14:19:34
Quote from: Zozosoft
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ó.
Ha "véletlenszerű" a hiba, akkor a hangerő, időzítés, stb. eltérései miatt fordulhat elő, hogy néha működik a mentett file, máskor pedig nem. Azon a gépen, amelyen mindig rossz a WAV, nem változtattad meg a hang beállításokat (pl. kisebb hangerő) ?
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.16. 14:30:34
Quote from: IstvanV
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.

Quote
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? (Hétfőn tudom majd megnézni).

Annyi biztos, hogy itt ezen a gépen amin működött, le van halkítva (0.272-t mutatt a voluménál).
Title: Re: EP128emu
Post by: IstvanV on 2012.November.16. 14:34:40
Quote from: Zozosoft
Mindenesetre akkor azt javaslod, próbáljam ki Reset default settings-el?
Én azzal teszteltem.
Title: Re: EP128emu
Post by: IstvanV on 2012.November.19. 16:21:22
Hiba esetén érdemes még megpróbálni a mintavételezési frekvencia növelését.
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.19. 16:28:39
Quote from: IstvanV
Hiba esetén érdemes még megpróbálni a mintavételezési frekvencia növelését.
Ok, este próbálkozok!
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.19. 21:55:15
Meg van a megfejtés!
A hang felvételnek semmi baja.

Viszont a lemezkezelésben találtam egy súlyos hibát :cry:

A lemez, amit használtam, hibás szektorokat tartalmaz, amit EP-n a FAFO szépen be is jelölt. EP-n is, Windows alatt is rendben használható.
Pont úgy adódott, hogy a PRG fájl elött egy hibás cluster van.
Ha jól tudom az emulátor egész sávokat olvas be a pufferébe, így a PRG olvasáskor ráolvas a hibás részre, a sáv olvasás nem sikerül, a pufferbe 00-k maradnak, eredményként az emulált EP által beolvasott PRG fájl eleje csupa 00-t fog tartalmazni.

Megoldási javaslat:
Egyszerű: ha nem sikerült a sáv olvasás, akkor generáljon pl Sector not found hibát a sáv minden szektorára.
Bonyolultabb, de "rendesebb": sáv olvasás hiba esetén letiltani az adott sávra a pufferelést, és mindig a kívánt szektort olvasni egyenként. Ha az hibás, akkor hibát generálni. Másik sávra lépés újra engedélyezi a pufferelést.
Így, mivel az emulált gép csak a jó szektorokat akarja olvasni a fájl betöltéskor, a beolvasás hibátlan lenne, csak egy pici lassulás lenne.
Title: Re: EP128emu
Post by: IstvanV on 2012.November.21. 10:18:25
A legegyszerűbb megoldás nem az egész sávot olvasni/írni egyszerre a pufferbe/pufferből, hanem a szektorokat egyenként ciklusban. De lehetne a hibás szektort átugorva újra próbálkozni a sáv többi szektorával is.
Title: Re: EP128emu
Post by: Zozosoft on 2012.November.21. 10:37:44
Quote from: IstvanV
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?

Quote
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.
Title: Re: EP128emu
Post by: Z80System on 2013.March.30. 16:09:02
Arra van mod, hogy command line-bol betoltsek valamit az ep128emu memoriajaba, valamelyik segmensekre, aztan elkezdjem futtatni vele ? tehat pld. valami olyasmi, hogy megadok szegmensszamokat, azokat belapozza, meg egy file- t, amit ratolt egy cimre, es aztan raugrik arra a cimre ?

Ha ilyet el lehetne erni kivulrol, akkor lehetsegesse valna, hogy egyeb rendszereken forditott binarisokat lefuttassunk kivulrol, vagyis egy forras editorban funkciobillentyure lefusson az emulatorban a program ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 15:23:49
Par szot tud valaki mondani az ep12emu2 build- eleserol ?

Win- en pld. scons- al kell build- elni, vagy a VS sln- nel, ilyesmi alap infok, amit akkor nem kene kideritgetni, vagy esetleg par gondolat amire erdemes figyelni ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 15:34:14
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 15:54:03
A wines mingw- s verzio, vagy maradtal linuxon ?
Title: Re: EP128emu
Post by: lgb on 2013.April.07. 15:57:58
Quote from: Zozosoft
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.

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 ...
Title: Re: EP128emu
Post by: IstvanV on 2013.April.07. 16:03:40
Hamarosan készítek egy rövid leírást, hogyan kell Windowson lefordítani az emulátort (az installer .exe készítését is). Linuxon egyszerűbb, mert a disztribúciókban általában megtalálható minden, amire a fordításhoz szükség van.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.07. 17:46:11
A fordításhoz szükséges csomagok Windowson:
1. MinGW + FLTK + libsndfile + portaudio + SDL + lua + dotconf + OpenGL (https://www.dropbox.com/s/v9b0e3kij9ai7ug/mingw.7z) (ezt célszerű a C:\ könyvtárban kicsomagolni, hogy a gcc például C:\MinGW\bin\gcc.exe legyen). A libsndfile, portaudio, SDL, lua, és dotconf meglehetősen régi ebben a csomagban, de működik, és a 2.0.9.1 installerbe is ezek kerültek :) A MinGW és FLTK azonban újabb, és az új C++ fordító egyben kis mértékű gyorsulást is eredményez a korábban kiadott verzióhoz képest
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)

Szerk.: a GitHub verzióhoz újabb fordító csomagok találhatók itt (https://enterpriseforever.com/ep128emu/ep128emu/msg58125/#msg58125).

A PATH környezeti változóhoz ezeket a könyvtárakat kell hozzáadni (természetesen az útvonalakat módosítva, ha szükséges):

C:\MinGW\bin
C:\Python27
C:\Python27\Scripts
C:\Program Files\NSIS    (opcionális)

Ezek után következhet a fordítás :) Az SConstruct file-ban a win32CrossCompile változót 1-re kell állítani, és a "wine " összes előfordulását törölni (tehát például "wine C:/MinGW/bin/gcc.exe" helyett csak "C:/MinGW/bin/gcc.exe" legyen, feltéve, hogy a MinGW a fent ajánlott könyvtárba került). 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. Lehet kísérletezni az optimalizálási paraméterekkel is, a "Pentium III" csomagba például ezek kerültek (a változásokat kiemeltem):

compilerFlags = ''
if buildRelease:
    if linux32CrossCompile or win32CrossCompile:
        compilerFlags = ' -march=pentium2 -mtune=pentium3 '
if enableDebug and not buildRelease:
    compilerFlags = ' -Wno-long-long -Wshadow -Winline -g -O2 ' + compilerFlags
    compilerFlags = ' -Wall -W -ansi -pedantic ' + compilerFlags
else:
    compilerFlags = ' -Wall -O3 -ftracer ' + compilerFlags
    compilerFlags = compilerFlags + ' -fno-inline-functions -frename-registers '
    compilerFlags = compilerFlags + ' -fweb -fomit-frame-pointer -ffast-math '


Debug verzióhoz azonban célszerű "enableDebug = 1" és "buildRelease = 0" beállításokat használni, illetve törölni az "-ansi" fordító paramétert, ami az új GCC verzióval hibát okoz. De a MinGW csomagomban található GDB nem működik :oops:, a használatához további DLL file-okat kell letölteni (libiconv (http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/libiconv-1.14-2/), libintl (http://sourceforge.net/projects/mingw/files/MinGW/Base/gettext/gettext-0.18.1.1-2/), és libexpat (http://sourceforge.net/projects/mingw/files/MinGW/Extension/expat/expat-2.0.1-1/) - elég csak a legtöbbet letöltött csomag mindegyiknél :)) (http://sourceforge.net/projects/mingw/files/MinGW/Extension/).

A fordítás egyszerű scons paranccsal történik; elvileg használható a -j N paraméter a párhuzamos fordításra, ahol N a párhuzamosan futtatandó fordító parancsok száma. Ez gyorsabb több magos processzorokon, de a megbízható működéséhez telepíteni kell a pywin32 Python bővítést is. Az scons -c parancs törli a fordítás során létrejött file-okat, de a következők csak manuálisan törölhetők: .sconf_temp, .sconsign.dblite, és config.log.
Ha nincs hiba a fordítás során, akkor már futtatható az ep128emu.exe, de a strip *.exe paranccsal még törölhető a debug információ a programokból, ha nincs rá szükség (így valamivel kisebbek lesznek a file-ok).

Installer készítéséhez az installer könyvtárban az alábbi parancs használható:
makensis ep128emu.nsi
természetesen ha a makensis.exe elérési útvonala nem került a PATH környezeti változóba, akkor azt is meg kell adni.
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 17:53:52
Kulsag, esetleg azt is leirhatnad, hogy linux- on hogyan modosul mindez ?

Gondolom egyszerubb is, meg lehetne csak a kulonbsegeket leirni.

Itt lenne egy helyen akkor mindketto, meg mostmar felraktam egy ubuntut, sztm semmikepp sem art ha ide van irva ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 18:00:07
Quote from: IstvanV
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 18:03:20
Tenyleg, ezek hogyhogy nincsenek visszarakva a kodbazisba ?

Kene valami kontribucios rendszer, amit idonkent istvan jovahagyna, berakna a kodbazisba... nem ?

Vagy hogy fog bekerulni a final cuccba mondjuk az, amit zozo most felrakott ?
Title: Re: EP128emu
Post by: IstvanV on 2013.April.07. 18:04:19
Quote from: Z80System
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.
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.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.07. 18:10:37
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 18:16:56
Hat az svn hasznalat nyilvan kenyelmes meg jo lenne, de az jo, ha mindenki elkezdi kommittalgatni a "nagy nehezen" osszerakott dolgaidat ?

Csak ugy kene, hogy te nyomd ra a kommittot, nem ? Meg ha csak a trunk- ot kommittalgatjak masok, akkor is ossze tudjuk egymasnak ugy kavarni, hogy aztan mar senki nem ert semmit a vegere ... nem ?

Persze meg lehet probalni ... ha nem lesznek "tomegek", vagy direkt trollok, lehet mukodhet ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 18:27:03
Meg hat valahol ficsorok szintjen is ...

En pld. most szeretnek egy plussz menupontot a felbontas menube, a meglevo harmom menupont melle (1X, 2X, 3X -os pixelmeret) szeretnek egy 4X -es opciot is ... mert 1900X1200- ra kifer, es zavarni meg gondolom senkit nem zavar, legfeljebb majd nem valsztja ... Ezek a fix egesz szammal tobbszorozo felbontasok meg kellenek ahhoz, hogy minden pixel sor es oszlop ugyanakkora es negyzet legyen.

Szal egy ilyen ficsorrel gondolom nincs gaz, de egy masik mar siman lehet, hogy csak egyeni igeny, es masokat zavar, osszekever, idegesit ...

Vagy nem passzol a koncepcioba ...

Vagy akarmi ...

Ha azt barki csak ugy berakja, akkor a kovetkezo build- ban benne lesz ... mindenki megkapja ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 18:47:04
Erre a floppys (http://enterpriseforever.com/ep128emu/ep128emu/msg27786/#msg27786) problémára nincs valakinek ötlete?
Nem biztos, de lehet, hogy azért nem megy az írás, mert valami "manifest" nevű dolog is kéne az EXE-hez az újabb Windowsok alatt?
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 18:53:45
Image- ekbe sem, vagy csak fizikai lemeznel van ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 18:59:22
Quote from: Z80System
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:
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 19:05:07
És mint írtam, nem csak az ep128emu-nak nem sikerül a lemezre írás Windows 7 alatt, pl a Winimage, vagy az azzal készült önkicsomagoló lemezképek se működtek, csak abból már kiadtak új verziót, ami már Win 7 kompatibilis.
Title: Re: EP128emu
Post by: Z80System on 2013.April.07. 19:33:50
Nincs valami jellemzo hiabauzenet ? Nem ir ki semmit ? Elszall ? Siman csak nem mukodik ? Mit csinal ? Nincs floppy a gepembe ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 19:45:36
Quote from: Z80System
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.
Egyébként image fájlból meghajtót csináló programmal előállított A/B meghajtón is ugyanez a helyzet.
Title: Re: EP128emu
Post by: nyuzga on 2013.April.07. 21:39:53
Próbáltad a kompatibilitást XP-re és rendszergazdára átállítani az emunál?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 21:43:58
Quote from: nyuzga
Próbáltad a kompatibilitást XP-re és rendszergazdára átállítani az emunál?
Igen, és semmi hatása.
Title: Re: EP128emu
Post by: nyuzga on 2013.April.07. 21:50:12
Kipróbálnám. Hogy is kell egy basic programot lemezre menteni? Elfelejtettem.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.07. 21:51:47
Quote from: nyuzga
Kipróbálnám. Hogy is kell egy basic programot lemezre menteni? Elfelejtettem.
SAVE "A:PRG"
Title: Re: EP128emu
Post by: nyuzga on 2013.April.08. 00:05:53
Quote from: Zozosoft
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. 

De majd még ennek utána kell nézni a neten is. Hátha...
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 00:30:09
Na, megismerkedtem az ep128emu2 debuggerevel ...

MEGAKULSAG ! VERIRULEZ ! UBERKIRALY !

Istvan(V) a kiraly !
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.08. 00:31:39
Quote from: Z80System
Na, megismerkedtem az ep128emu2 debuggerevel ...
Eddig nem is próbáltad???
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 00:52:06
Eddig ASMON- ban debuggoltam ... :)


Most viszont megcsinaltam azt, hogy PC- n build- elek egy C vagy Assembly forrasokbol fordulo allo EP 5- os fejlecu programot, tehat a teljes 5- os binaris totalkeszre eloall Pc- n,

aztan ha sikeres volt a build, akkor lefuttat a build egy ep128- emut egy projektnek dedikalt konfiguracios file- lal,
aminek resze a beallitasok kozott az, hogy van A drive benne exos.ini -vel mely FILE eszkozt allit alapertelmezettnek, es utana EXDOS hivasal betolti az iment lefordult 5- os fejlecu programot ... :) !


Vagyis PC build utan, automatikusan elindul az elkeszult EP program az emulatorban eppugy, mintha user toltotte volna be ... :)

Ez mondjuk meg nem a debugger, de tok allat ... Es igy lehet hasznalni a megamajer emulator debuggert a frissen forditott koddal ... :smt041


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 ?
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 09:24:40
Quote from: Z80System
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 ?

Nem emlekszem, de mintha pont errol lett volna szo, hogy snapshot-ot kene neki fake-elni ugymond, mert akkor egy pillanat alatt meglenne, nem lenne memtest, enterprise felirat stb, semmire nem kene varni? Ui en is probaltam hasonlot amit te is irsz, csak nekem kisse korulmenyesnek tunik hogy mindig sokat kell varni (ha sok kis modositas van fejlesztes kozben akar par masodperc is idegesitoen sok tud lenni!). Tudom, el vagyok kenyeztetve ...

Valami szep megoldas engem is erdekelne erre a "problemara" :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 09:41:06
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 ... :)

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 ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 09:52:21
Ha meg ujra akarja az ember inditani a programot, mert tobbszor akarja lefuttatni, akkor meg alt+b, g100, es mar elolrol is indult ... megakulsag ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.08. 10:04:42
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 10:16:27
Kerdes hogy az EPDOS inicializalasa milyen gyors... ha nem ad hosszu masodperceket az elindulashoz, akkor tokeletes lehet, mert a fejleszteshez ugysem kell maga az EPDOS, csak ez a funkcio belole.
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 10:31:12
Quote from: Z80System
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 ...

Nekem forditva :) Igaz nekem IDE, ~512K RAM, EXDOS stb emulacio is mind be van kapcsolva, es igy nekem hatarozottan soknak tunik, mire vegre eljutok addig, hogy az - emulalt - gep hasznalhato allapotba kerul. A build az ellenben 1 masodperc alatti, mig ez neha fel percig is elszomszomtol vagy tobb (marmint az emulalt EP) ami mar szamomra idegesitoen lassu :(

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

Ok, teny hogy en se probaltam a gyakorlatban, csak egyszer annyit, hogy betoltes utan kimentettem az egeszet, aztan eppen arra gondoltam h most max a programot kene mar modositani a snapshot-on belul, mert a gep allapota stb adott, de itt veget is ert az almodozas, mert azota sem volt idom vele foglalkozni ............. Szoval akar igazad is lehet persze.
Title: Re: EP128emu
Post by: endi on 2013.April.08. 10:42:28
Z80System, ha nem titok mit akarsz alkotni? Demó, játék? :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 10:52:08
Na, az epdos17b rom- javal ha 4- es szegmensre rakom akkor azt csinalja amit akarok, vagyis gombnyomas nelkul lefut a cucc ...

Egy kicsit rosszabb a helyzet mint gondoltam, igy ezzel az epdos+exdos.ini komboval 7 masodperc az entertol a program lpt bevaltasaig ... de a build meg hosszabb ...

Gondolom egy custom betolto rommal, ami nem hasznalja az epdos- t es az exdos.ini- t, hanem csak gyorsan bevaltja a file eszkozt, es modultoltessel ratolt a program nevere, azzal tovabb roviditheto olyan 3-4 masodperccel ... de most jo lesz igy, nem kell bovito rom- ot irjak ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 10:57:23
Quote
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 ...

De igen jatekokat, demokat akarok irogatni hobbi idoben, szep lassacskan, mindig mikor van egy kis idom.
Igy mar majd mindig csak hozzarakni kell egy kicsit, ez a hosszu baszkuralas nem lesz a projektek elejen.

Eloszor a jatek a valoszinubb ... eloszor probalgatni akarom mit lehet megmozgatni, szkrollozni, kirakni ... aztan az eredmenyeket felhasznalva egyszeru, de technikailag es gameplay- ben is okes jatek, jatekok ... de mindegyik kicsi lesz, tehat nem larry,dizzy,r-type stb. dolgokra gondolok, hanem ilyen arcade stilus ... rovid gamek, inkabb ugyessegi cuccok.
Title: Re: EP128emu
Post by: endi on 2013.April.08. 11:00:00
aha. volt itt szó egyszer space touch jellegű játékról, azaz tunnel anim, rajta űrhajó
fel is raktam egy nem használt tunnelt ide, és valaki át is konvertálta ep videóvá, bár úgy emlékszem sokkal jobbra lehetett volna
mindenesetre látványos lenne ep-n
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 11:02:27
Nem rossz otlet egynek (ha tenyleg szep animot lehet), de eloszor scroll iranyba akrok menni ...

Bar ez itt mar OFF.

Ezt az "uj ep fejleszteseknel" kene ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 11:05:06
Van egy erdekes dolog ...

A total commander nalam egy drive- ot akkor nem lat ( nem is listazza mint elerheto drive ) HA ADMINISZTRATORkent futtatom. Egyebkent latja. Ez egy mappolt drive, nem igazi. De mindegy, a lenyeg hogy siman futatva latja, adminkent futtatva viszont nem ...

Nem lehet hogy a floppy- nal is epp ilyen a jelenseg ? Hogy adminkent futtatva NEM mukodik ?
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 11:21:41
Egy gondolatra meg offolva a topikot:

Tulajdonkepp jatek-demokat akarok csinalni ... :)
Title: Re: EP128emu
Post by: geco on 2013.April.08. 13:22:40
É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 :D
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.08. 13:25:11
Quote from: geco
É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 :D
Speciel nem, mert a bejelentkező képernyő a trükkösen védett részek közé tartozik az EXOS ROM-ban :-)
Title: Re: EP128emu
Post by: geco on 2013.April.08. 13:51:26
Akkor fölöslegesen találtam meg a helyét? :D
Code: [Select]
  *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?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.08. 14:06:58
Quote from: geco
Akkor fölöslegesen találtam meg a helyét? :D
Code: [Select]
 *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?
A legegyszerűbb egy ROM-mal ami kikapcsolja a logót :-)
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 14:39:03
Lehet, hulye kerdes, szoval ussetek ha az :) Ha mar az ep128emu itt van, es van benne ep128, cpc, spectrum (? mondjuk soha nem probaltam oket, csak valahol olvastam) emulacio, es legalabb multi-platform, ill open source is, akkor nem lehetne TVC-t is emulalni benne? Van ket TVC-m is valahol elfekvoben, jo lenne abba is kicsit bemelyedni, de ahhoz jol jonne egy emulator, ami linux alatt (win-em nincs, soha nem is volt, nem is lesz) is megy, lehetoleg van benne debug cucc, stb. Eleve, ha jol tippelek par dolgot lehetne reuse-olni az emuban, hisz Z80 az uaz, talan meg a CRT vezerlo is hasonlo tipusra mint CPC-ben, stb stb. Sot, akkor mar Primo is johetne. En anno Linux ala elkezdtem Primo emut irni (mellesleg ep128 emulatort is ...) ami azonban elegge linux specifikus volt, plusz sose fejeztem be. Sajnos az ep128emu az szamomra ertelmezhetetlen C++  nyelven irodott :) es nem C, igy erdemben barmit beleirni nem tudnek :( Ha sima C lenne, akkor talan menne. Bar akkor ez mar nem ep128emu lenne mar talan hanem "magyar viszonylatban erdekes Z80 alapu 8 bites gepek emulatora" lassan :) Mar csak a HT1080Z kene hozza.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.08. 14:43:50
Én is tudnék örülni TVC módnak, különösen a debugger miatt!
Szerintem kb a hang kivételével minden adott a kódban, csak össze kéne hozni :oops:
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 18:56:58
Na probalom linuxon a forditast. Mar fordul, amde ha megprobalom az eredmenyt lefuttatni:

 *** error: error initializing PortAudio

strace-el nezegetve az ok lathato:

open("/dev/dsp", O_RDONLY)              = -1 ENOENT (No such file or directory)
open("/dev/dsp", O_WRONLY)              = -1 ENOENT (No such file or directory)


Csak epp nem ertem miert ezt akarja, ugyebar pulseaudio van meg ALSA (ubuntu 12.10 eppen) alatta, /dev/dsp nevu OSS oskovulet se kozel se tavol nincs a rendszerben mar ...

NA A MEGOLDAS KOZBEN:

Ez 18-as portaudio volt ... 19-est felrakva (az emlitett ubuntu alatt trukkos, mert libportaudio-dev kapcsan jon a 18-as verzio, portaudio19-dev neven - lib nelkul az elejen - pedig a 19-es). Igy tok jol mux az altalam forditott ep128emu cvs-bol linux alatt! COOL.

Mar csak azon elmelkedem, hogy scons alatt mi lehet a szokasos "make clean" es "make distclean" megfeleloje, mivel a portaudio lecserelese utan az scons lathatolag becache-elte az eredmenyeket es nem volt hajlando maskepp csinalni, igy empirikus alapon toroltem par ponttal kezdodo konyvtarat "kezzel" ami scons szerusegnek tunik. Utana mar hajlando volt az ujabb portaudio-val fordulni majd linkelodni es mukodik is, mint irtam :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 19:01:47
Hogy hivjak ubuntu alatt az opengl konyvtarat ? amit fel kell tenni az apt- vel.
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 19:25:10
Quote from: Z80System
Hogy hivjak ubuntu alatt az opengl konyvtarat ? amit fel kell tenni az apt- vel.

Mesa -s cuccok gondolom, ami open source OpenGL implementacio. Most megneztem ldd-vel mihez linkelodik az eredmeny binaris, es azon shared object-ek (ahol szerpel a "gl" string benne legalabb) melyik csomagban vannak, igy ezt kaptam:

libfltk1.1
libgl1-mesa-glx
libglapi-mesa
libxcb-glx0
Title: Re: EP128emu
Post by: Z80System on 2013.April.08. 19:42:34
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.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.08. 19:47:33
Quote from: lgb
Mar csak azon elmelkedem, hogy scons alatt mi lehet a szokasos "make clean" es "make distclean" megfeleloje
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.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.08. 19:49:21
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 20:23:02
Quote from: IstvanV
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.

Thx! Igazabol most vettem eszre, egy problem van meg: a lua ... Az elejen ezt irja:

Checking for C header file lua.h... (cached) no

Ezzel az a baj hogy barmit is teszek fel ez sosem valtozik, ami nem veletlen, mivel lua.h ugyan van, csak epp nem kozvetlenul az /usr/include/ alatt, hanem:

lgb@antares:~$ find /usr/include -name lua.h
/usr/include/luajit-2.0/lua.h
/usr/include/lua5.1/lua.h

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:

lgb@antares:~$ pkg-config --libs --cflags lua5.1
-I/usr/include/lua5.1  -llua5.1 

De akkor ezek szerint azt valahogy nekem kell beledrotozni az SConstruct file-ba, hogy hol van a lua.h ?
Title: Re: EP128emu
Post by: lgb on 2013.April.08. 20:38:38
Quote from: Z80System
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.

Amugy amennyire tudom nem, lehet annak indult (sw only OpenGL open source implementacio) de messze nem az ma mar, DRI stb driverrekkel siman adja a hw accel. cuccokat is.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.08. 23:28:16
Quote from: lgb
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:
Quote
      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.

Quote from: lgb
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.
Title: Re: EP128emu
Post by: lgb on 2013.April.09. 10:16:59
Quote from: IstvanV
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.

Aha. Erdekes amugy ez az scons, ha eltekintunk attol, hogy ez vegulis egy python program (marmint az SConstruct) akkor megfeleltethetjuk nemi Makefile / configure mechanizmusnak. Csak pont ez a bajom vele: ha fel akarsz keszulni sok disztribuciora sot OS-re, es jonnek a gondok (mas a csomag neve, tobbfele header file, tobb verzio ugyanabbol, mas a lib neve stb stb) akkor ott van pl az automake/autoconf ahol ugye rengeteg generic check van amit nem kell megirnod. Viszont itt - ha jol ertem - pl csinalhatod meg magadnak az SConstruct file-ban mindent nullarol leirva, hogy hol mit ellenorizz stb, amikor autoconf/automake-ben ez mar evek/evtizedek alatt teljesen kiforrott es hasznalhato, es kb minden letezo dologra adott mar megoldast, amiben unix v unix szeru rendszerek elterhetnek (es persze a linux disztribuciok).  :-)

Bar kicsit vicces, hogy pont en irom ezt, mert mplayer-hez sajat configure megoldast irtunk mert nem tetszett nekunk az autoconf-os jatek :) :)
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 13:59:29
Jól nézem, hogy max csak 240 sávos floppyt enged meg az emulátor?
Ennek kapcsán (http://enterpriseforever.com/hardver/hxc-floppy-emulator/msg31937/#msg31937) kiderült, hogy valódi gépen is lehet 254 sáv :-)
Ezt hol kéne módosítani?
Title: Re: EP128emu
Post by: IstvanV on 2013.April.12. 14:31:29
Quote from: Zozosoft
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).
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 14:47:08
Köszi, este megpróbálok javított EXE-t fordítani.
Ha sikerül lehetne "nagy floppys" lemezképeket is gyártani ep128emu, ill valódi gépen floppy emulátor számára.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 19:43:52
Quote from: IstvanV
Debug verzióhoz azonban célszerű "enableDebug = 1" és "buildRelease = 0" beállításokat használni
Az, hogy debug verzió az mit jelent pontosan?
Title: Re: EP128emu
Post by: Z80System on 2013.April.12. 19:51:49
Elméletileg jelenthet bármit, csak egy flag, aminek hatására valahogy másképp fordulhat, build -elődhet le a az adott program.

A gyakorlatban a Debug/Release páros azt szokta jelölni, hogy a Debug esetben egy olyan bináris készül, mely sebességben nincs optimalizálva, illetve a debugger környezethez debug információt is tartalmaz, mellyel a forrás szintű hibakeresés lehetővé válik, és minden egyéb tekintetben is olyan kód fordul, melyet alapvetően hibakereséshez szántak, nem igazi felhasználásra, disztribúcióra.

A Release verzió meg ennek az ellentéte, arra való, hogy mindenki hasznalja, lehető leggyorsbban fut, stb.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 20:02:35
Quote from: IstvanV
A fordításhoz szükséges csomagok Windowson:
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)
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"...
Lehet az a gond, hogy nekem a tavalyi 2.7.3 a Python, és 2.2.0 az SCons?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 20:06:28
Quote from: Z80System
a debugger környezethez debug információt is tartalmaz
És milyen környezetben lehetne debuggolni?
Konkrétan pl, hogyan lehetne megnézni, hogy Win 7 alatt floppyra íráskor mi történik?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 20:23:38
Quote from: Zozosoft
Lehet az a gond, hogy nekem a tavalyi 2.7.3 a Python, és 2.2.0 az SCons?
Frissítettem, ugyanaz :-(
Title: Re: EP128emu
Post by: Z80System on 2013.April.12. 20:24:00
Hát konkrétan nem tudom, mert azzal, hogy felismertem, hogy az emu config file -jait használva mindent meg tudtam csinalni, amit akartam, feleslegessé vált az emu hekkelése, így nem mentem végig a build- jén, ami nem 1Xu feladat ... megtalálni melyik lib -et épp hogy hívják, melyik verzió kell, stb ...

Winen olyan értelemben egyszerűbb, hogy ugye kaptunk hozza csomagot, de én ott is magamnak tenném ossze úgyis ...

Kérdésre visszatérve, mivel win -en mingw -vel fordul, 99% hogy GCC -t használ, és nem "nyúl ki" mingw alól az ms compiler -hez (anális inkább, mert nem volt req, hogy telepítsük, csak a mingw), és ha így van, akkor nyilván debug -olni a GDB -vel lehet, normalisan, mint linux -on. De magának a GDB -nek a használata nekem fekete doboz, világ életemben GUI debugger -ekkel nyomultam. Amolyan C/C++ -hoz szant "monitor" program lehet a GDB, mint a "monitor" az ep128emuban, pont arra jó, csak forrás szinten, változó és függvénynevekkel, nem memória ofszetekkel.

Sosem használtam.

Szal ezzel a GDB csodával kell, parancssorból futtatni, break -elni és monitorozni a C/C++ konstrukciókat, lépkedni a sorokon, ellenőrizni a változókat, stb.

Ha alapból a GDB nincs fent a mingw alatt, mikor telepíted winre (azért gondolom csak fent kéne lennie), akkor esetleg külön fel kell tenni alá.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 20:56:17
Olyan szavakat használsz aminek a tizedét se értem, csak azt látom valami iszonyat bonyolult dolog manapság programot írni :smt088 :smt089 :smt010
Title: Re: EP128emu
Post by: Z80System on 2013.April.12. 21:07:22
Hmmm ... pedig ponthogy 1Xuen próbáltam ...

Mikor bent vagy az ep128emu monitorában, akkor azt (nyilván) érted. Van az az ablak a második debugger fülön, ahol ilyen parancsokat adhatsz ki (m, d, a, l, stb.) es akkor ott valamit csinal az emulator állapotaival, vagy lép egyet, vagy listáz egy memóriacímet, vagy beír egy assembly utasítást a memóriába, vagy amit választottál.

Na ugyanez a GDB, mondjuk képzeld hogy a GDB az emu, a GDB -nek is van ilyen parancssora, és ugyanúgy léptetheted vele a programot a c/c++ sorain, illetve vizsgálhatod a memóriát, ill. a c/c++ változóit. De ha a c/c++ tőled messze áll, akkor nyilván debug -olni sem fogod tudni.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.12. 21:26:54
Quote from: Zozosoft
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.12. 21:31:16
Quote from: IstvanV
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.
Vagy átkerülhetett valami az emulátor forrás könyvtárba is?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 00:03:21
Quote from: IstvanV
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)
Title: Re: EP128emu
Post by: endi on 2013.April.13. 00:27:26
Miért nem tudok Fraps-al felvenni az emulátorból?
Vagy nem lehet konfigolni valahogy az emu videó felvétel inditást-leállítást egy gombra?
Title: Re: EP128emu
Post by: szipucsu on 2013.April.13. 00:36:01
Quote from: Zozosoft
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?
Akkor ez csak a floppys újítást tartalmazza?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 07:25:52
Quote from: szipucsu
Ez mi? Mi a verziószáma?
Akkor ez csak a floppys újítást tartalmazza?
2.0.9.1
Meg természetesen minden előző hibajavítást.

Lassan ideje lenne összerakni egy 2.0.9.2-t, frissített ROM és config fájlokkal.

A forrásban ezek a fájlok változtak.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 11:42:02
Quote from: Zozosoft
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);
Ezt találtam. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx)
Azt írja:
Quote
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).
Quote
Windows Server 2003 and Windows XP:  Direct access to the disk or to a volume is not restricted in this manner.
Amennyire kigoogléztam, lock-olni kéne a meghajtót, hogy működjön az írás.
Title: Re: EP128emu
Post by: Z80System on 2013.April.13. 13:00:16
Na, ahogy sikerült megértenem, a következőket kell(ene) tenni:

a

h = CreateFileA(fileName, (DWORD) 0,
                      FILE_SHARE_READ | FILE_SHARE_WRITE,
                      (LPSECURITY_ATTRIBUTES) 0, OPEN_EXISTING,
                      FILE_ATTRIBUTE_NORMAL, (HANDLE) 0);

harmadik paraméterét (FILE_SHARE_READ | FILE_SHARE_WRITE) 0 -ra kéne írni,
így exkluzív jogokat kapunk a file- on, és működni fog a direkt lemez hozzáférés az új (restricted) os -eken is,

de sajnos a fopen/fclose/fread/fwrite hívásokat helyettesíteni kéne CreateFile/WriteFile/ReadFile hívásokkal, es az összes CreateFile exclusive kell legyen,

mert nem hinném, hogy egy ilyen hívás:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364575(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364575(v=vs.85).aspx)

legalizálná a fopen/fwrite típusú file kezeléseket az emuban ...

De ehhez forduló cucc kell, nekem meg még nincs. Mindezeket ki is kellene sajnos probálgassam a gyakorlatban, mert nem pontosan látom át azt a komplex funkciósereget, ami a file kezelés a winben.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 13:08:57
Quote from: Z80System
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 :-(

Ilyeneket emlegetnek még: FSCTL_LOCK_VOLUME meg FSCTL_DISMOUNT_VOLUME.
Title: Re: EP128emu
Post by: Z80System on 2013.April.13. 13:13:52
FSCTL_LOCK_VOLUME hívást ott linkeltem, de akkor úgy látszik nem nagyon kaparom a működését,

a dismount meg nem tudom floppy -nál játszik -e, de ha igen, akkor tegyél be egy lemezt, és disk manager -ben unmount -old, és akkor már lehet hogy műxik is ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 13:22:53
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.13. 13:24:44
Hát feltételezem azért nem, mert az nem egy mount -olt dolog ... nem ? Vagy mi más okból ne látszana ...
Title: Re: EP128emu
Post by: lgb on 2013.April.13. 14:56:35
Lenne egy kerdesem: ep128emu eleg sokat "var" az EP logo es az IS-BASIC kozott kozben felvillan fd ledeket emulalo GUI elemek. Ez a delay valojaban tehat az EXDOS-nak koszonheto? Csokkentheto/eliminalhato ez valahogy? Volt anno is szo errol (csak nem tudom kapcsolodik-e a tema!) hogy EXDOS-nak van talan Zozo-fele :) valtozata ahol ki van aktitva nemi WD test, vagy hasonlo ... Vagy az "valodi" EXDOS kartya meglete mellett problema lenne, ha ki lenne veve (emunal meg annyira se tudom)? Thx.
Title: Re: EP128emu
Post by: Z80System on 2013.April.13. 14:59:28
Lemezt kell tenni az a: meghajtoba. Akkor csokken a delay sokat.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 15:02:19
Az a EXDOS.INI keresése. Legegyszerűbb, ha a BASIC-et az EXDOS fölé rakod a konfigurációban.
Title: Re: EP128emu
Post by: Lacika on 2013.April.13. 15:43:24
Vagy, ha van Zozotools, bejelentkező képernyőnél B-t kell nyomva tartani egy kicsit, így egyből a BASIC indul. Ha I-t nyomunk, EPDOS,
Title: Re: EP128emu
Post by: endi on 2013.April.13. 16:16:53
fel kell gyorsítani maxra az emut, alt+w :)
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 23:02:36
Z80System! Nekem így sikerül fordítani:
Az István által tavaly adott MinGW csomag. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg25044/#msg25044)
Ehhez feltettem a Python 2.7-et, és a PATH-hoz hozzáadtam az itt is említett (http://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713) MinGW és Pyhon útvonalakat.
Itt van a módosított SConstruct file, ill. a kényelem kedvéért még csináltam két BAT fájlt is.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.13. 23:05:59
Floppytlan gépen meg ezzel (http://www.totalcmd.net/plugring/virtdisk.html) tudok floppyt csinálni.
Az így be mountolt image-re, pont ugyanúgy nem ír, mint a valódira.
Title: Re: EP128emu
Post by: Z80System on 2013.April.14. 22:37:29
Debuggolnám az emut ...

GDB nem találja a debug szimbólumokat ...

Nem tudom, hogy azért mert nincsenek is a fordított exe -ben, vagy csak valahol máshol vannak, és külön kéne megmondani a GDB -nek ...

Bármi infó welcomed.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.14. 22:44:44
Ha a Strip (pck.bat) le lett futtatva, az törli a debug infót, hogy kisebb legyen az EXE.
Title: Re: EP128emu
Post by: Z80System on 2013.April.14. 22:49:38
Még egyszer sem futtattam azt ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.14. 22:57:21
Quote from: Z80System
Még egyszer sem futtattam azt ...
De fordítottál EXE-t?
Title: Re: EP128emu
Post by: Z80System on 2013.April.14. 22:59:48
Hát persze ... :) Mit debuggolnék, ha nem fordítottam volna.

Csak a pck -t nem futtattam.
Title: Re: EP128emu
Post by: Z80System on 2013.April.14. 23:20:57
Ok, meglett. A scons file -ban kellett kapcsolni -g flag -et a gcc -nek.
Title: Re: EP128emu
Post by: Z80System on 2013.April.14. 23:33:29
Quote
Floppytlan gépen meg ezzel (http://www.totalcmd.net/plugring/virtdisk.html) tudok floppyt csinálni.
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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.14. 23:41:45
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 00:26:43
Normál file floppy image -be jól működik az emu ?

Csak direkt floppy -ra íráskor vacakol ? (Most mindegy, hogy a direkt floppy az vas vagy emulált floppy)
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 01:14:06
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.
(Nem is baj, hogy kicsit ezzel is megismerkedek, ki tudja mikor fog kelleni...)

Egyetlen kézzelfogható eredmenye a mostani szessönnek, hogy a mérhetetlen debuggolások közepedte felismertem, hogy amit mondasz CreateFile, az le sem fut a mi esetünkben ... :)

Ezért kell a debugger, mert ketten is néztük, mégsem lattuk:

#ifdef WIN32
    if (std::strlen(fileName) < 5)
      return 0;                 // return value == 0: regular file
    if (!(fileName[0] == '\\' && fileName[1] == '\\' &&
          fileName[2] == '.' && fileName[3] == '\\')) {
      return 0;
    }
    DISK_GEOMETRY diskGeometry;
    HANDLE  h = INVALID_HANDLE_VALUE;
    DWORD   tmp;
    bool    retryFlag = false;
    while (true) {
      h = CreateFileA(fileName, (DWORD) 0,
                      FILE_SHARE_READ | FILE_SHARE_WRITE,
                      (LPSECURITY_ATTRIBUTES) 0, OPEN_EXISTING,
                      FILE_ATTRIBUTE_NORMAL, (HANDLE) 0);
      if (h == INVALID_HANDLE_VALUE)
        return -1;              // return value == -1: error opening device
      if (DeviceIoControl(h, IOCTL_DISK_GET_DRIVE_GEOMETRY,
                          (LPVOID) 0, (DWORD) 0,
                          &diskGeometry, (DWORD) sizeof(diskGeometry),
                          &tmp, (LPOVERLAPPED) 0) == FALSE) {


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

Szal ennek a CreateFile -nak semmi köze a dologhoz ...

Ezt az első 2 if -et esetleg már hekkelte valaki ? Vagy ez így volt már akkor is, mikor még jól működött az emu ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.15. 09:18:12
Quote from: Z80System
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)

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

Szal ennek a CreateFile -nak semmi köze a dologhoz ...
A másodiknál van egy not az elején :oops:
Vagyis akkor tér vissza, ha 5-nél rövidebb, vagy az eleje nem "\\.\"!
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 09:29:59
Quote
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)
Igen, 3 dolgot le kell tölteni, be kell másolni, és a scons -ban egyet módosítani, és megy a GDB, összeírom ezeket nemsokára.

Quote
A másodiknál van egy not az elején (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)
Vagyis akkor tér vissza, ha 5-nél rövidebb, vagy az eleje nem "\\.\"!
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.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.15. 13:59:26
Quote from: Z80System
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.

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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 14:44:57
Quote
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.


Quote
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 ...
Title: Re: EP128emu
Post by: IstvanV on 2013.April.15. 14:59:55
Quote from: Z80System
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 GDB is ezt a formátumot használja, így a nem nyomtatható karaktereket (pl. '\n') is ki tudja írni.
Title: Re: EP128emu
Post by: lgb on 2013.April.15. 15:00:49
Quote from: IstvanV
Ez nem hiba, a \ a C nyelvben speciális "escape" karakter, amit valóban kétszer kell írni ahhoz, hogy egyszerű nyomtatható \ karaktert jelentsen.

Ezert utalom a DOS baromsagat, hogy pont a \-t valasztottak dir separatornak, UNIX-nal ez pl /. Bar allitolag amikor DOS-ba a UNIX szeru konyvtarak fogalmat behoztak akkor eredendoen /-t akartak ahogy ott is van, csak rajottek h gaz van, mert DOS-os command-oknal a / azok altalaban kapcsolok ugye (ez UNIX-nal altalaban minusz jel viszont), es sok program onnan akarta megmondani hogy a parancssoraban file nev van vagy kapcsolo, hogy a / jellel kezdodik akkor kapcsolo ... Ezert inkabb \-t hasznaltak. Mondjuk a DOS amugy is oszver, mert a CP/M meghajtobetujel otletet sikeresen kevertek a UNIX-ok hierarchikus konyvtarszerkezetevel (UNIX-ban ugye nincsenek meghajtobetujelek) es lett egy ilyen ize belole. Bar ahogy remlik DOSRUN-os idokbol, a DOS-ban megvan a nyoma hogy /-t is felismeri dirseparatornak valahol, sot pl a UNIX style device specifikaciot (CON helyett pl \DEV\CON, utalva a szokasos unix-os /dev/ strukturara). Ize, lehet tenyleg kene egy "elkalandoztam" topic, mert ez se igazan ide illik :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:04:17
Akkor nem marad más hátra mint hogy benéztem valamit, vagy hogy esetleg a szimbóluminformáció és az optimalizáció összeveszett és mást mutatott.

Majd megnézem.
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:19:06
Debuggolni pedig úgy lehet winen, hogy a korábbi Zozosoft összefoglalóhoz képest még az ember letölti ennek a három libnek a binárisát:

http://sourceforge.net/projects/mingw/files/MinGW/Extension/expat/expat-2.0.1-1/
http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/libiconv-1.13/
http://waterlan.home.xs4all.nl/libintl.html

És bemásolja a mingw\bin mappába.

Ekkor a GDB már elkezd működni, es a Sconstruct file -ba pedig ideiglenesen át kell írni, hogy a használt konfiguráció mellett (amelyik ág lefut a debug/release flag- ek hatására) a compilerFlags változó -g kapcsolót és -O0 kapcsolót tartalmazzon. (Ha van másik optimalizációs flag, pld. -O3, akkor azt gondolom el kell távolítani, csak a -O0 maradjon a debuggolni szándékozott verzió fordításának idejére.)

Egyébként pedig a GDB -hez vannak tutorial -ok a neten, számottevően számtalan számra ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:23:27
Pld. itt van egy GDB for dammiz:

http://www.dirac.org/linux/gdb/ (http://www.dirac.org/linux/gdb/)
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:36:59
Tényleg, Linux baglyok !

Nem lehet hogy van windows -ra valami GUI frontend a GDB -hez ? Mert ha lenne, akkor nem kellene kínlodjunk itt a parancssoros GDB -vel, nyomhatnánk kényelmesen ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:41:23
Juhúúúúú ! Sztm ez lesz a mi barátunk:

http://www.affinic.com/?page_id=109 (http://www.affinic.com/?page_id=109)

Van ilyen is de ez nem ingyenes:

http://www.wingdb.com/ (http://www.wingdb.com/)
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 15:42:41
Juhúúúúú !

http://www.affinic.com/?page_id=137 (http://www.affinic.com/?page_id=137)
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.15. 16:15:38
Quote from: Z80System
Juhúúúúú !

http://www.affinic.com/?page_id=137 (http://www.affinic.com/?page_id=137)
Így már kezd szimpatikus lenni a dolog :-)
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 17:19:41
A WinGDB semmiképp nem nyerő, az nem standalone, hanem egy plugin, és nem támogat VS -hoz express verziókat:

WinGDB supports:
[ul][/ul]All editions are supported except Express editions.
Title: Re: EP128emu
Post by: Z80System on 2013.April.15. 17:20:17
Jó lesz az a másik szerintem ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.17. 10:24:07
Az itt említett (http://enterpriseforever.com/programozas/z80-reset/msg32201/?topicseen#msg32201) Z80 resetelés javítva (módosított forrás fájl csatolva).

István! Arra tudnál tippet adni, hogy a bekapcsoláskori véletlenszerű regiszter feltöltődést hogyan lehetne emulálni? Emlékeim szerint a Nicknél már lett ilyen csinálva, hogy az EXOS 2.0 keretszín bugja látható legyen, ahogy az igazi gépen is.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.17. 11:15:36
Quote from: Zozosoft
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.

A véletlenszerű inicializálásra egy lehetséges megoldás:
Code: [Select]
#include "system.hpp"
...
{
  int     seed = 0;
  Ep128Emu::setRandomSeed(seed, Ep128Emu::Timer::getRandomSeedFromTime());

  R.AF.W = Z80_WORD(Ep128Emu::getRandomNumber(seed) & 0xFFFF);
  ...
}
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.17. 12:27:34
Köszi!
Quote from: IstvanV
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
Ez szerintem elég jó lesz bekapcsoláshoz :-)
Akkor itt kiegészítettem a rnd feltöltéssel.
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 21:25:21
Na végre megint lett időm, itt az eszközös floppy kezelés javítása win -re.

Természetesen lehet benne hiba, abszolút nó varangy, úgyhogy nem nekiesni a pótolhatatlan lemezeknek vele, hanem próbálgatni. Szerintem jó lesz.

Csak win -en fordítottam, de mivel egy #ifdef van csak benne, mas rendszereken is fordulnia kéne. Maga a módosítás csak az adott fordítási modulra terjed ki, vagyis csak a floppy kezelésre lesz hatással, mást nem módosít. És azt is csak win -en, más platformokon nincs különbség.

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 ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 21:28:47
Ja, és eszközzel próbáltam ugye, de image -dzsel meg nem ... tehát azt is ellenőrizni kell, hogy az meg jó maradt -e ... :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 21:40:44
És még valami. Mivel az eszköz floppy -t mostantól lock -olni kell, ezért ha valahol listazva van a floppy tartalma (explorer, totál kapitány), akkor csak read -only -ban nyílik majd meg a lemez, tehát az emuban úgy fog látszani, mintha írásvédett lenne a lemez.

Ugyanez fordítva, ha emu be tudta lock -olni a floppy -t, akkor nem lehet majd listázni előző helyeken, hibát fognak dobni az iménti programok.

Szintén nem próbáltam ki, de 99% hogy a lock -olás csak akkor sikerül majd ha admin jogokkal fut az emu. Ha nem, akkor megintcsak read- only lesz a lemez.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.23. 22:38:53
Első próbák alapján működik! :smt038

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-re :oops:

Quote from: Z80System
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:
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.
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:-t
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.

Itt a lefordított EXE, hogy a többiek is tudják próbálgatni.
Meg 254 track-esre javított CPP :oops:
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 23:17:47
Quote
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-re

Használj valami ilyen programot forrás file -ok összefésülésére:

http://winmerge.org/ (http://winmerge.org/)

Ez pld. egy ingyenes példány.

Ha egy ilyennel ránézel 2 forrás file -ra, akkor egyből megmutatja grafikusan, hogy hol vannak az eltérések közöttük, és egyből láttad volna, hogy én csak egy darab összefüggő blokkot szúrtam be a forrásba, azt az egy blokkot 2 klikkeléssel át tudod benne dobni az általad már hekkelt file -ba, és nem kellett volna újraírogatni semmit ...

Egyébként pedig idővel kapni fogunk majd svn hozzáférést az emu repójához, akkor csökkennek a kézi összefésülések majd.

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

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

Quote
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:-t
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.
Ok, é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 ? )
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 23:29:59
Magát a buffert kikapcsolni egy flag használatával is ki lehet ezzel a jelenlegi file API -val, viszont az megkoveteli hogy szektorhatárra legyen align -olva az írás ... Tehát hogy csak egész szektorokat írjon.

Tudunk erről valamit ? Hogy az emu szektoronként írja -e a floppy -t ? Mert ha úgy írná, akkor egy pillanat műve berakni.
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 23:31:54
ráadásul "fizikai" szektor -ra igazítva, nem pedig "logikai" szektorra ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 23:35:49
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) ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.23. 23:36:24
Quote from: Z80System
Tudunk erről valamit ? Hogy az emu szektoronként írja -e a floppy -t ?
Igen úgy írja, mivel az igazi WD is úgy írja.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.23. 23:38:56
Quote from: Z80System
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.
Viszont majd egyszer jó lenne ezt is beállítható paraméterré tenni, hogy lehessen majd a zx128emu módba floppyt varázsolni, ott pedig mint a SpeccyDOS mind a Beta Disk 256 bájtos szektorokat használ.
Egyébként a WD 128/256/512/1024 bájtos méreteket ismer.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.23. 23:41:41
Quote from: Z80System
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.
Kipróbáltam az emu telepítő által Start menübe rakott indítót is, azzal is megy!

Quote
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.23. 23:51:43
Quote
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.24. 00:12:54
Quote from: Z80System
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:
Title: Re: EP128emu
Post by: Z80System on 2013.April.24. 00:22:56
És mi a teszt környezet ? Mit csinaljak, honnan hova menjek, hogy akadjon ?
Title: Re: EP128emu
Post by: Z80System on 2013.April.24. 00:30:46
Itt van egy "még jobb" verzió (bekapcsoltam +1 flag -et) ...

Ha esetleg ez sem javítaná meg, akkor van még egy módszer, hogy explicit hívunk egy flush -t minden íráskor. De reméljük így már jó lesz.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.24. 11:37:16
Na most utánajártam egy XP-s gépen, ahol működik a régi EXE-vel is az írás.
Úgy tűnik ott is megvolt az effekt :oops:, 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.

Egyébként itt volt erről a dologról szó. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-7/msg17848/#msg17848)
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.24. 11:47:27
Ez lenne még egy fontos kijavítandó bug! (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)
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...
Title: Re: EP128emu
Post by: Z80System on 2013.April.24. 14:31:20
Quote
a most utánajártam egy XP-s gépen, ahol működik a régi EXE-vel is az írás.
Ú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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.24. 14:52:01
Quote from: Z80System
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".
De ez csak valód lemezzel látszik, mert ott kell várni a meghajtóra.
Title: Re: EP128emu
Post by: Z80System on 2013.April.24. 15:01:46
Quote
pl :MD PROBA visszajön az OK, villog a kurzor, majd egyszer csak kihagy egy "ütemet".
De ez csak valód lemezzel látszik, mert ott kell várni a meghajtóra.
Hát olyanom egyenlőre nincs, akkor maradsz te a teszter,

most akkor már a legutolsó verzióval is tesztelted, vagy még azzal nem ? Avval amelyik ma reggelre virradólag volt feltéve ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.24. 16:12:22
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.24. 17:36:13
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 ...
Title: Re: EP128emu
Post by: IstvanV on 2013.April.25. 10:46:57
Quote from: lgb
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.25. 11:41:21
Quote from: Z80System
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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.25. 12:57:47
Quote
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 ...

Lehet hogy ezekkel csak a file buffereket ignorálom ki, és talán van még más alacsonyabb szintű, tudomisén device szintű, vagy OS szintű bufferek is ... Elég fura hogy nem tudjuk elérni, hogy ténylegesen végigmenjen a kiírás ...

Még azt lehetne kipróbálni, hogy ténylegesen lezárom a (kérdéses esetben egész lemezt jelképező) file -t minden írás után, és újra nyitom ... hatha azt már tényleg komolyan veszi ... persze ha van valami driver szintű, vagy eszköz szintű bufferelés is, akkor az még lehet arra sem halgatna ...

Mondjuk érdekes hogy az az írás művelet ( amit mondasz ) megakasztja az emulátor szálat ... Ha ilyen os szintű valami flush/írás művelet, akkor miért kéne emu szalat blokkoljon ? Nem is ertem ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.26. 23:08:11
 (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)
Quote
Ez lenne még egy fontos kijavítandó bug! (http://enterpriseforever.com/ep128emu/ep128emu/msg28765/#msg28765)
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...
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,

vagy pedig kéne egy fizikai floppy, egy rossz sector -okkal rendelkező lemezzel, hogy jobb hijján a gyakorlatban kipróbálgassam, hogy mi történik a rossz szektorokkal, milyen infót kapok vissza róluk, mikor állnak azok az információk endelkezésre, és mit módosíthatok a WD kódon úgy, hogy az mást ne vágjon haza.

Majd ha lesz egy rendes gépem (floppy -val megáldott), akkor megnézem hogy lehet ezt megcsinálni.

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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.26. 23:18:20
Quote from: Z80System

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 ?
Van, úgy hívják USB floppy :-)
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 08:32:57
Hát jó, ki gondolta volna ...

http://www.argep.hu/trend/USBF/Usb-floppy-drive.html (http://www.argep.hu/trend/USBF/Usb-floppy-drive.html)

És egy ilyen akkor valszeg 100% -ban úgy működik mint egy floppy vezérlőre dugott példány, tehát ott és akkor lennének késlekedések, blokkolások mint a floppy vezérlősnél, ill. a rossz szektorokat is ugyanúgy jelzi a windows felé, mint a floppy vezérlőre dugott példány ? Vagy annyi a hasonlóság hogy floppy -t kell beledugni, de egyébkén más hardware, másfajta csatlakozás, másfajta API, és igazából semmi hasonlóság nincs a működésben ? Tehát arra gondolnék, hogy mittudomén ez nem track -enként tudja visszaadni hogy rossz a lemez, hanem lemezenként, megsérül rajta bármi, akkor nem olvassa a lemezt, vagy mittudomén, bármi más nem floppy vezérlős floppy -ként működés ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 09:47:25
Jó kérdések, amik addig nem derülnek ki, amíg valaki nem vesz egyet :oops:
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 10:55:42
Egyébkén szektorhibás lemezt hogy lehet hekkelni ? Átszúrom a lemezt egy helyen, akkor az szektorhiba lesz ? Egyébként meg olvassa majd a lemezt ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 11:02:14
EP-n simán tudsz szoftverből írni olyat! (Másoltam is anno ilyen védelmet használó PC-s lemezt.)
Legegyszerűbb, ha EPDOS Disk Editorban, Track Editor-ban elkészíted a Forma-t, majd kitörölsz a szektor adat területből pár bájtot, és úgy írod ki.
Title: Re: EP128emu
Post by: endi on 2013.April.27. 11:14:23
szektorhibáról jut eszembe: én egy hibás lemezemet úgy mentettem meg (nagylemez) hogy nyomtam a retry-t és közben a lemezt az ujjammal fel le nyomtam (nagylemez kicsit kilóg a driveból)
jópár perc után végig beolvasta a hibás fájt

rajta volt egy játékom, ami így nem veszett el :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 11:17:33
Hmmm ... ezt nem értem. Én eddig azt hittem, hogy a szektorhiba az egy fizikai hiba ... Most akkor kiderül, hogy egy szimpla formázási hiba is bad sector ?

Dehát egy ilyen szoftveres bad sector akkor hogy kezelődik a wd által ? 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 ?

Nem értem hogy a wd mit vesz észre bármilyen floppy -ra írt adatszerkezet hibából ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 11:26:34
Akkor lesz data error, ha az adatbájtokból számolt és a beolvasott CRC bájtok értéke összehasonlítva nem stimmel.
Ez lehet attól is, hogy sérült a lemez, és nem azok a adatbájtok olvashatóak, mint amik fel lettek írva (amihez az íráskor számolt CRC bájtok fel lettek írva).
Az említett trükknél, 512 bájtnál rövidebb szektort formázunk, ehhez íródik fel a CRC (a formázó adatcsomagban benne van a CRC felírása utasítás). Olvasáskor viszont 512 bájtra fog számolni CRC-t, ami nem stimmel a felírttal, már jön is a Data error hiba.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 11:37:51
Quote from: Z80System
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.
Szektor olvasásnál egyrészt szinkronizál, így már értelmes értékeket fog olvasni. Keresi a kívánt szektor fejlécét, ebből fogja majd tudni, hogy mekkora adatterület jön (128/256/512/1024), majd ha meg van az adatterület szépen adogatja a beolvasott bájtokat. Azt is figyeli, hogy a CPU minden bájtot kiolvasott-e, ha úgy jön a következő bájt, hogy az előző még nem került kiolvasásra, akkor ezt adatvesztés hibával jelzi.
Az adatbájtokra CRC-t számol, és ha ez nem stimmel a lemezről beolvasott CRC-vel, akkor fog data error-t jelezni.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 11:41:43
Aham ... tehát akkor valójában olyan, hogy a WD valahogy megtudja a floppy vas -tól, hogy nem sikerült beolvasni egy szektort hardveres hiba folytán, olyan nincs is, valójában hardveres szinten mindíg sikerül a beolvasás, "legfeljebb" atomhülyeségek vannak a beolvasott adatokban, és ezt a floppy vezérlőjének kell már megoldania, hogy felismerje ?

És akkor a WD IC -be ezek szerint be van építve egy ilyen CRC alapú teszt ( ami mellesleg ugye képes hibázni, tehát nem felismerni hogy hiba van ... jó kis régi világ, mikor még mindennek "lelke volt" ), ami alapján jelezni képes, hogy nesze itt a szektorod, de vigyazz vele, mert szerintem hibás adatok vannak benne ? Ha ez nem lenne a WD -ben, akkor az EXOS -nak kéne valami ilyen biztosító/ellenőrző módszert megvalósítania ?

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 ?

És egyebként hova határozza meg ? Szektoron belülre, vagy kívülre ?

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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 11:57:02
Quote from: Z80System
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.
Quote from: Z80System
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 ?

És egyebként hova határozza meg ? Szektoron belülre, vagy kívülre ?
A szektorfejléc utáni, ill. az adatterület utáni két bájt az.
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.
Szektorirásnál automatikusan teszi oda az adatterület végére az új CRC-t.
(Azaz ha a korábban trükkösen formázott hibás szektorunkba beleírunk, akkor már hibátlan lesz.)
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 12:06:27
Quote
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 ...

Quote
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 ...
Title: Re: EP128emu
Post by: lgb on 2013.April.27. 12:32:30
Quote from: Z80System
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, ami ugye egy konkret (jelen esetben Microsoft) filerendszer, annak nicns koza a hw szintu disk kezeleshez. Nyilvan tok mas filerendszer is teheto ra, a FAT csak egy egyszeru am elterjedt filerendszer a sok kozul. Pl volt szo a commodore floppy-krol: 1541 es tarsai un GCR kodolast hasznalnak, sajat cucc. Amde - ha jol tudom - az 1581 (ami mar 3.5"-os!) szinten WD-t hasznal, megis a filerendszere egyaltalan nem FAT, hanem a szokasos commodore fele (minden szektorban pointer a kovetkezore, nem kulon FAT-ben, a BAM csak allokaciora hasznalt [Block Allocation Map - ha jol remlik]).

A WD nem tudja mi az a file stb, az kvazi un block layer szintu dolgot operaciokat hajt vegre, az OS/sw/stb valosit meg filerendszer (ha akar, de van amikor nem hasznalnak filerendszert sem csak siman a diszk minden blockja egymas utan, struktura nelkul).
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 12:37:56
Hmmm ... lassan át kéne rakni a WD/lemezkezelés részt az ep128emu topikból sajátba ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 13:00:22
Quote
Dehogy. Az mar a FAT resze,
Ok, de akkor a kérdés másik része még mindíg él:

Ha a WD elvárja valahol a CRC bájtokat, akkor ahova ő (WD) írja/olvassa a CRC értéket ( zozo hekkje nélkül :) ), az egy másik IC -nek miért lesz jó ? 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 ? De mi van ha valaki nem CRC -s biztosítékot akar ? Akkor az majd nem lesz kompatibilis a lemezeinkkel, de az iparban akkor is ez terjedt el, vagy mi ?

Értem hogy a szektorokba írt formátum már FileSystem függő dolog, de a szektorok maguk meg ugye WD függőek ... de nem mindenhol WD van ... nem ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 13:12:57
Quote from: Z80System
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)

Aztán voltak olyanok akik saját dolgokat találtak ki, mint pl a Commodore a 1541 és társaiban, és Amigánál is, meg az Apple is sokáig más úton járt.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 13:26:49
 (http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)
Quote
Így van, itt linkeltem is a szabványokat.
(http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)
Ó, 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 ...

Nem véletlenül volt a világon mindíg csak 3 ember, aki értett a hardverekhez.

Na ezeket én most mély tisztelettel nem tanulmányozom át ... Ha majd szereztem floppy -t, akkor maradunk a kérdezősdinél ... Még jó hogy nem akartam nekikezdeni megértéssel, jó lesz az az élő floppy -val kísérletezgetős megoldás is.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 13:34:53
Quote from: Z80System
(http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078) (http://enterpriseforever.com/programozas/exdos-283/msg24078/#msg24078)
Ó, 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 ...
Ennek kb a 95%-a a meghajtó, lemez, és floppyvezérlő IC gyártók mérnökeinek szól :-)
Ami "közérdekűbb" azt belerakták a WD leírásába is (milyen adatokat kell kiírni formázásánál).

Ami a lényeg most számodra, hogy az adott módon lehetséges data error-os lemezt készíteni, amivel aztán lehet vizsgálni, hogy mit csinál az emulátor ha ráolvas.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 13:36:47
És akkor aki írta a WD kezelőt az ep128emu -ba, az ezeket mind áttanulmányozta és megértette ?

Vagy tulajdonképp most így belegondolva, lehet hogy pont ez a rész hibádzik most az emu WD kódjából, nem ?

Tehát ha belegondolunk ez a CRC -s kezelés valahol megtorténik a PC lemezkezelőjében, de mi nem közvetlen azzal kommunikálunk, hanem egy win file API -val, ami nyilván valahogy majd elnyeli azt, hogy X sectorokban CRC hiba van, es vagy nyujt a hibákról valami információt, vagy nem, ha nyújt, akkor majd azt kell kiolvasni, ha nem nyújt, akkor nekünk kell a CRC  tesztet a szabványok ismeretében elvégezni (ha a file hozzáféréssel hozzáférunk a CRC adathoz egyáltalán), meg még az is lehet, hogy mondjuk a win file API mondjuk a hibás szektorokra nem adja vissza a szektor adatot, amiből a CRC -t elvégezhetnénk, ÉS bármi is az előzőek közül a helyzet, az fix hogy ez csak egy windows -os módszer lesz, másik OS -eken is meg kell oldani ...

Nem tűnik eccerű mókának ...
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 13:45:01
Ez a "sector header" amit mondasz, hogy a CRC abban van, ez a 512 byte -os szektorunk része (amit vélhetőleg a win file API olvas), tehát 512 bájtonként le van foglalva a header, így szektoronként annyival kevesebb értékes bájtot tárolhatunk,

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 ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 13:59:52
Az emulátornak ilyen szinten nincs köze az egész floppys dologhoz, ő fájlt olvas. A nagy kérdés az, hogy mi történik, ha a fájolvasás során lemezhiba történik? Elvileg ilyenkor vissza kéne jutni egy hibakódnak az operációs rendszertől a programhoz (azaz az emulátorhoz).
Ez jelenleg nem történik meg, ki kéne találni, hogy a Windows sumákolja el, vagy az emulátor nem kérdezi le jól?
A lockolásos dolog kapcsán kiderült, hogy a Write Protect az nagyon szépen visszajut egészen az emulált EP-ig is. Vajon az olvasási hiba hol veszik el?
Az egyébként jól hallatszik, hogy retryzik a rendszer olvasáskot, tehát valamelyik szinten észlelve van a hiba.

A hiba összefoglalva az, hogy pl egy sávon az 5. szektor hibás. Ez be is van jelölve a FAT-ban, így az emulált EP fájlműveleteknél nem is akarná beolvasni.
Azonban az emulátor a puffereléshez beolvassa az egész sávot, így a hibás 5. szektorra is ráolvas. Itt az olvasás elakad, és az 5. szektortól a sáv végéig 00 bájtok lesznek a pufferben.
Így hiába olvasná az emulált EP a hibátlan 6. szektort, már nem azt kapja meg.

Ami eszembe jutott most: ez vajon általában a fájolvasás hibája, vagy a spéci \\.\A: fájlé?
Kipróbálom majd, hogy egy hibás lemezre ráírok egy IMG fájlt, és azt adom meg az emunak, vajon ekkor se lesz hibajelzés?

A másik ami eszembe jutott: megnézni Linux alatt ugyanazt a lemezt, vajon ott is jelentkezik-e a probléma?
Ehhez kérdezném a Linux gurukat, hogy milyen Linux verzióval lehetne egyszerűen ep128emu próbálgatni?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 14:01:45
Quote from: Z80System
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.)
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:14:00
Quote
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.

Reméljük visszaadja a DeviceControl vagy más hasonló api a bad sector info -t.

A FAT -ból meg egyrészt nem kéne nekiállni kiolvasgatni ( gondolom nem 1Xu ), meg hát mikor kerül oda bele az info ? Mondjuk először még jó volt a lemez, de közben elromlott. Akkor ráolvasunk a win -nel, vajon mire visszatér a beolvasott szektor info, addigra már frissítve lett a FAT az új rossz szektorral ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 14:16:32
Ha jól nézem ez végzi a beolvasást:
Code: [Select]
       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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:22:50
ja, de nem hinném hogy egy ilyen "fizikai" lemez file olvasása egy rossz szektortól meghiúsulna ... sztm be fog olvasni, valami akarmi lesz a rossz szektorok helyen, amit kitalaltak, es kesz.

lehet olyan hogy nem olvas be ez a sor, ha kivettek a lemezt vagy ilyesmi, de egy bad sector sztm ezt nem fogja lefalsoltatni.

De ha esetleg megis, akkor is ez egy teljes track beolvasasa, nekunk meg szektoronkent kellene a hiba.

Illetve hat lehet hogy mikor a wd- t track -re hivtak (ha van benne olyan) akkor meghalhatnank a teljes track- re is, de gondolom az EP nem olvasgat track -enkent vele, inkabb sector -osan talalnam elkepzelhetonek, szal nekunk sector -osan kell a hiba, nem ?
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:27:09
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.

Csak ahhoz az kell hogy megdogoljon egy bad sector- ra.
Amit en nem hiszek.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:35:30
Linux:

Szerintem sima ubuntu -val tudsz probalgatni siman, viszont ha forditani, debuggolni akarsz az kulon sztori lesz. Akkor is jo az ubuntu, de az nem olyan kompakt mint a win -es fordito csomag.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 14:45:20
Quote from: Z80System
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.
Lehet, hogy van, csak az emu nem foglalkozik vele? :oops:
Több helyen van ez a wd177x.cpp-ben: // FIXME: errors are ignored here
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:50:47
Ja. Simán.

Mindenesetre kell egy fizikai floppy + egy rossz ( bad sector -os ) lemez, hogy kiprobalgathassam.

Te is ki tudod, ha begerjesztetted azt a debuggert, amit múltkor itt reklámoztam, én begerjesztettem, simán ment, vizuálisan lehet debuggolni.

És akkor egy bad sector ( -os track ) olvasásakor megnezed, hogy mit csinál az az fread, ad -e vissza hibát.

Mivel mostmár a forrásban felül lévő kódok futnak le win -en (amit írtam újonnan), és ott külön változó van a beolvasott byte -oknak meg tudod nézni mennyit sikerül beolvasni a teljes track -ből.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 14:51:11
Elvileg itt lenne CRC hiba jelzés:
Code: [Select]
     // 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;
        }
      }
Title: Re: EP128emu
Post by: IstvanV on 2013.April.27. 14:55:59
Quote from: Zozosoft
Több helyen van ez a wd177x.cpp-ben: // FIXME: errors are ignored here
Ezek 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.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 14:57:35
Hát ebből 2 dolog következhet:

Úgy van ahogy gondolom, és ilyen fizikai lemez file- nál a
errorFlag = (bytesRead != nBytes);
sor sosem állítja be errorFlag -et,
mert mindíg "sikerül" a beolvasás, rossz szektor esetén is,

vagy pedig nem ezt a track -es beolvasó kódot hívja az EXOS, hanem egy szektoros verziót, ahogy korábban mondtam, szal ha ez lenne hivva, akkor lenne hiba, de mivel nem ezt hívja, ezért valszeg a szektorosnál meg nem jó a hiba jelzés.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 15:00:09
Nincs a WD- nek szektoros interfésze ?

Ha van (tutkó kell legyen), akkor sztm az EXOS azzal kommunikál, és akkor tudod te azt, hogy az hol van a WD kezelő kódban ?
Title: Re: EP128emu
Post by: IstvanV on 2013.April.27. 15:01:30
Quote from: Zozosoft
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.
Talán a legjobb lenne, ha megoldható lenne, hogy Windowson is gyors legyen a floppy kezelés sáv pufferelés nélkül, és akkor a pufferelést törölni lehetne.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 15:06:33
Nincs ezzel a puffereléssel szerintem semmi baj, csak szektoronként kell beolvasni a sávot, es szektoronként kell a hibát is (valahonnan szedni, mert a mostani valszeg nem működik) letárolni, és kész, nem ?

Vagy pont az a gáz, hogy ha a track sector -ait szektoronként olvasnám be, akkor az marha lassú lenne ?

( Mellesleg ha így lenne, a bad sector info -t lehet elő lehet kaparni más API -val, és akár az egész lemezt is be lehet cache -elni, nem csak egy track -et. )
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 15:13:56
Quote from: Z80System
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ú.
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 15:15:18
Quote from: IstvanV
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!
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 15:20:21
Quote
Lehet, hogyha maga az emulátor programkód olvasná be így egyből az nem lenne lassú.
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ú ? Vagy emu -n gyorsabbat akartunk mint eredeti EP -n ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 15:31:45
Quote from: Z80System
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.
Míg az emulátorban az után kezdődik az EP-s átvitel*, miután már elhaladt a szektor. És előtte még ott vannak az operációs rendszer rétegei is, azok is okoznak némi késleltetést, amíg a valódi beolvasásából az emu megkapja az adatot. Lehet, hogy ebben van nagy különbség a Linux meg a Win között, mert ha jól értem amit István mond, csak Windowson volt lassú a puffer nélküli mód.

*az emulátoron gyorsabb az átvitel, mivel a WD időzítések nincsenek emulálva.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 15:40:35
Quote from: IstvanV
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?
Így akkor hibás lemez, floppy meghajtó, stb nélkül is lehetne keresni, hol veszik el a hibajelzés.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 15:42:40
Na jo, tehát köv opciók vannak:

Kell egy vas floppy+bad sector környezet, és meg kell nézni, hogy most akkor milyen formában jelez vissza a jelenleg windows -on futó ReadFile a bad sectorra. Az is lehet, ha igy több sectort olvasva nem jelez vissza a bad sector- ról, ha csak 1 sector- t olvasok, akkor majd visszajelez.

Ha semmiképp nem jelez vissza, akkor keresni kell masik API -t amivel a bad sector info kinyerhető egy lemezről. Egyenlőre ilyet nem találtam.

Ha nem találunk, akkor reménykedjünk benne, hogy a FAT táblában a bad sector info frissítve van az olvasások (és ráadásul ennel a speciális drive -ot jelképező file olvasásánál is) közben, és mikor beolvastuk a szektorokat, akkor a FAT táblában lehet ellenőrizni, hogy van -e rossz az imént beolvasott szektorok között.

Talán a harmadik módszer azért is lenne mindjárt a legjobb, mert az minden platformon egyből működne, az előző megoldások nyilván csak winen működnének.
Title: Re: EP128emu
Post by: Z80System on 2013.April.27. 15:43:58
Quote
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?
Így akkor hibás lemez, floppy meghajtó, stb nélkül is lehetne keresni, hol veszik el a hibajelzés.
Hát ha elveszik ... próbáltad már beállítani ? Simán lehet hogy nem elveszik, hanem meg sem jelenik ...
Title: Re: EP128emu
Post by: IstvanV on 2013.April.27. 15:47:37
Quote from: Zozosoft
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 15:47:55
Quote from: Z80System
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:
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 16:17:44
Quote from: Zozosoft
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!!!
Amikor FISH-en keresztül van kezelve a lemez, azaz normál EXOS/EXDOS fájlműveletek, vagy az EPDOS Disk Editor SECTOR EDIT módja, akkor hibátlannak látszik.
Viszont amikor DISKIO-n keresztül van kezelve, azaz az TRACK/SECTOR EDITOR-ban nézve, már vannak Data Error-ok!
De! Mindig csak akkor ha változott az sáv vagy oldal (azaz a sáv puffer tartalma). Ha ismételten ugyanott olvasunk, akkor már nincs hiba!

Így már úgy tűnik az a pufferbe olvasásból még jól megjön a hibajelzés, csak az első szektorolvasás után veszik el.

A FISH pedig nyom egyből egy Retry-t amikor hibát talál, és mivel a második szektorolvasás már nem kap hibajelzést az emutól, ezért nem látszott a dolog normál használat során.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.27. 16:30:14
Már látom is hol a hiba!
Code: [Select]
      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.
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.

Tehát akkor a readTrackben kéne egyből megnézni, hogy volt-e hiba, ha igen, akkor szektoronként újraolvasni, és egy tömbben letárolni, hogy melyik szektor hibás.
Majd itt a szektor olvasó rutinban ezt a tömböt nézni mindig, és annak megfelelően generálni a hibát.
Title: Re: EP128emu
Post by: IstvanV on 2013.April.27. 16:41:11
Quote from: Zozosoft
A readTrack akkor fut le, amikor változott a sáv vagy oldal, azaz frissíteni kell a puffert.
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.
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:
Code: [Select]
     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:

További javítandó hiba, hogy a readTrack() hívása után CRC hibát csak akkor kellene jelezni, ha az adott - olvasandó - szektor még mindig rossz, és nem akkor, ha a sáv bármelyik szektora hibás. Tehát nem a readTrack() visszatérési értékét kellene vizsgálni, hanem a flagsBuffer[] tartalmát újra.

Azt is meg lehetne még oldani, hogy a hibás szektor után a többi szektort próbálja újra olvasni, akkor nem veszne el egy hibás szektor után az összes többi a sávban.
Title: Re: EP128emu
Post by: Z80System on 2013.April.28. 16:13:54
És akkor most a WD emulációja az emunak valahogy úgy egyszerűsít, hogy fejléptetéseknél, ilyesmiknél csak magának regisztrál, de a floppy meghajtót nem bizergálja, hisz nincs is neki rá interfésze jelenleg az OS felé, hanem file olvasással a beolvasást track szinten cache -elve elkerülvén a továbbforgások miatti, forgásonkénti 1 szektor beolvasási lassulást, a track bufferből szolgálja ki az "adatolvasási" hívásokat az EXDOS felől ?

Amiből (ha majd ki lesznek javítva a jelenlegi hibák, akkor is) az eredeti EP/WD floppy IC kezeléshez képest olyan hátrányok származnak, mint:

- A floppy fej/motor/mittudoménmégmik nem pont ugyanúgy mozognak, működnek, mint ahogy azt az EP működtette volna a vas WD IC -n keresztül. (Tehát ha valaki írt valami floppy kattogtató/zenéltető programot, az itt nem működne, nem beszélve az értelmesebb felhasználás különbségeiről
- Mikor egy szektort beolvas az EXDOS akkor a WD emuláció egy teljes track -et betölt a floppy -ról, ami jelentős lassulást eredményezhet az első szektor kiolvasásáig, ha a file -ok töredezettek és több track -en vannak elszórt szektorokban, akkor meg még sokkal nagyobb lassulást
- Előbbi jelenség kiírásnál ugyanúgy megvan
- Ráadásul mivel egész track -eket írunk ki, egy bizonyos szektor kiírásakor bekövetkező CRC/bad sector hibáról csak később szerzünk tudomást, mint mikor az eredeti VAS -on a szektor írása megtörtént volna, és ahol a szektor írási hibát az eredeti EXDOS kód, vagy akár az alkalmazás kezelni tudta volna
- Ha viszont a track -en belül ír/olvas szektorokat az EXDOS, akkor fejmozgás, lassulások, ilyesmik elmaradnak, és a vasnál sokkal gyorsabb lesz minden
- Mivel kiírni csak akkor írja ki a track -et a floppy -ra az emulált WD, mikor másik track -re léptünk, ezért olyankor lesznek floppy írásra várakozások, mikor az eredeti EP -ben nem voltak. Ettől lehet zozo szívfájdalma, hogy mikor valamit ráírunk egy lemezre, és a funkcióból rég kiléptünk, az emu még csak akkor blokkolódik, ráadásul egy egesz track floppy -ra írásának erejéig, talán épp azért, mert a fej csak akkor lett még elmozgatva onnan, ahol az utolsó írás történt, és ekkor ír csak track -et az emu.

Mindezeket teljesen megszüntetni gondolom csak úgy lehetne, ha valami driver szinten OS alól hozzáférnénk WD szintű lemezkezelési parancsokhoz, és azokra fordítanánk a WD -hez érkező parancsokat.

Na mindennek vajon hány % -a igaz ? :)
Title: Re: EP128emu
Post by: Z80System on 2013.April.28. 16:22:57
Hopp még egy (talán legsúlyosabb) hiba eszembe jutott, beírom ide külön is:

- Ráadásul mivel egész track -eket írunk ki, egy bizonyos szektor kiírásakor bekövetkező CRC/bad sector hibáról csak később szerzünk tudomást, mint mikor az eredeti VAS -on a szektor írása megtörtént volna, és ahol a szektor írási hibát az eredeti EXDOS kód, vagy akár az alkalmazás kezelni tudta volna
Title: Re: EP128emu
Post by: Z80System on 2013.April.28. 16:28:00
Ha mindaz igaz amit leírtam, ha magamnak írnám az emut, en elfelejteném ezt az egész track cache dolgot, és megírnám normálisan szektorosra.

Akkor az maradna, hogy a fej/motor/akármik nem pont ugyanúgy mozognának mint a vas esetében, illetve sokkal lassabb lenne, de a többi hiba magától eltűnne, és szoftveres értelemben minden program ugyanúgy működne mint az eredeti EP -n.

Lévén ez egy emulátor, sztm az a legmagasabb prioritás. Nem ?
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.28. 17:04:52
Nagyjából igaz amit írsz.
Olvasásnál legrosszabb esetben (fájl minden szektora más sávon) lenne kétszer lassabb, mint az eredeti, ami kb annyi mintha 9/10 szektoros lemez helyett az interleave-s 11 szektorosat használnánk.
Gyakorlatban ilyen lemezt már úgy is rég formáznánk vagy defragmentálnánk.
Írásnál akkor írja ki, ha másik sávra megyünk, vagy 1 másodperce nem volt lemezművelet.

Az igaz, hogy az esetleges írási hibáról nem értesül az emulált EP. De talán nem túlzó elvárás, hogy jól leformázott lemezt használjon aki floppyzni akar :-)
Esetleg lehetne, hogy ilyen esetben feldob egy Retry/Abort/Ignore választást az emu.
De windows alatt nagy általánosságban szintén lehetetlen észrevenni az írási hibát.
Nagyjából úgy oldható meg, hogy írás után kicseréled a lemezt, majd vissza, és ezután összehasonlítod tartalomra a fájlokat.

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...
Most érzésre kb ugyanolyan gyors mint az igazi, és ez szerintem így jó.

Ebbe szerintem nem érdemes több energiát fektetni, mint az István által már vázolt hibákat kijavítani, plusz még az íráshoz betenni egy hibaüzenet ablakot.

Esetleg amit érdemes lenne pluszban berakni, hogy csináltak egy pluszban telepítendő "Floppy API"-t, amivel közvetlenül lehet kezelni a meghajtót, mint a normál Windows módon, így lehetséges nem Microsoft formátumú lemezek kezelése is. Pl EP esetén lehetne a plusz sávokat tartalmazó lemezeket kezelni.
Ennek főleg akkor lenne értelme, ha a Spectrum emulációs módba is lennének lemezkezelések beépítve, ezeknek a lemezeit csak így lehet használni.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.28. 17:09:56
Ezt emlegettem. (http://simonowen.com/fdrawcmd/)
Title: Re: EP128emu
Post by: Z80System on 2013.April.28. 17:29:45
Quote
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...
Most érzésre kb ugyanolyan gyors mint az igazi, és ez szerintem így jó.
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.

 (http://simonowen.com/fdrawcmd/)
Quote
Ezt emlegettem.
(http://simonowen.com/fdrawcmd/)
Na, ez pont annak a driver -nek tűnik, amit emlegettem, azzal a plussz további opcióval, ha jól értem, hogy a PC lemezvezérlőbe ezek szerint nincsenek huzalozva a CRC kezelés részletei úgy ahogy a WD -ben vannak, és így szoftveresen (a driver -ből) lehetőséget tudnak adni nekünk nem csak az EP által használt elterjedt, hanem mindenféle más szektor formázások kezelésére is, nem ?

Ebből viszont az következik, hogy ennek használatával mindkét legyet lehetne ütni egy csapásra:

- Megvalósíthatóvá válna a WD kommunikáció szintjén végzett lemez kezelés, tehát a valóságban, a WD szintjén lehetne emulálni a WD -t, vagyis pont ugyanúgy tudnánk vele sztm a floppy -t kezelni, mint ahogy a WD is kezeli a vas floppy -t. Minden pont ugyanúgy mozogna, olvasna, időzítene, hisz a gyakorlatban pont azt csinalnánk a driver -en keresztül a floppy -val, mint amit a WD is csinálna.

- Mellesleg lehetne írni más (nem WD) floppy vezérlő logika emulációkat is ( egy másik osztályba mondjuk ), ami jó lenne a spectrumhoz, vagy akármihez, amit még emulál az ep128emu
Title: Re: EP128emu
Post by: Z80System on 2013.April.28. 17:39:53
És mellesleg itt a válasz a tegnapi USB floppy -s kérdésre is a driver FAQ -jából:


Can I use a USB floppy drive?
No — USB floppy drives contain a separate floppy controller chip, which is not directly accessible from the host PC. Without access to that it's simply not possible to support formats beyond what the drive chooses to expose (typically DOS 720K and 1.44M formats only).



Én ezt úgy értem, hogy az USB floppy valahogy másképp kommunikál mint a floppy vezérlő, így nem lehetne ezzel a driver -rel hajtani. Magában az eszközben, az USB géppel ellentétes oldalán van a floppy vezérlő IC, amiben huzalozva van valószínűleg a nekünk szükséges szektor kezelés és formázás.

Persze fentiektől esetleg még az is lehetséges, hogy alacsonyszintű ("lemezvezérlő szintű") parancsokat attól még esetleg átvisz az USB, csak a CRC paraméterek vannak belehuzalozva a vezérlőbe, és azon nem tudnak változtatni a driver -ükkel. Inkább az elsőre tippelnék sajnos.

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.

De a jelenlegi file -os módszer 99% menne akkor az USB floppy -kon is, sztm ...
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.28. 17:45:00
Quote from: Z80System
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.

De a jelenlegi file -os módszer 99% menne akkor az USB floppy -kon is, sztm ...
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.)

LS120-as IDE-s floppyval is ugyanaz lehet a helyzet mint az USB-sel.
Title: Re: EP128emu
Post by: Zozosoft on 2013.April.28. 17:57:12
Fontossági sorrendre én ezt mondanám:
-kijavítani a tegnap felderített hibás szektor vs pufferbe olvasás problémát
-így akkor ki lehetne adni 2.0.9.2 verziót, ebben frissíteni a ROM és konfig fájlokat is
-WD emulációban a szektor méretet is beállítható paraméterré tenni
-ezután image fájlokkal már használhatóak lennének a Spectrumos lemezek, be lehetne tenni a zx128emu-ba a SpeccyDOS-t, és Beta Disk-et. (Ez lehetne 2.0.9.3)
-ezután jöhetne ez az új fajta API
Title: Re: EP128emu
Post by: Z80System on 2013.May.01. 14:59:39
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) ?
Title: Re: EP128emu
Post by: lgb on 2013.May.01. 15:20:26
Quote from: Z80System
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) ?

Szerintem 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. Ez azert is erdekes, mert ha HDD-t nezzuk, ott azert a FAT12 limitacioi komolyabbak, jol jonne a FAT16. Floppy eseten ez kevesbe problema persze :)
Title: Re: EP128emu
Post by: Zozosoft on 2013.May.01. 16:05:49
Quote from: Z80System
Egyébként filerendszer szinten ugyanaz a FAT12 van a floppy -kon is, mint az EP winyón ?
Igen.
Title: Re: EP128emu
Post by: Zozosoft on 2013.May.01. 16:07:20
Quote from: lgb
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...
Title: Re: EP128emu
Post by: lgb on 2013.May.01. 16:46:33
Quote from: Zozosoft
Előbb végére kéne érni az EXDOS visszafejtésnek :oops: de már sejtem, hogyan lehetne megoldani...

Tenyleg, lehet en emlekszem/tudom rosszul, de olvasgatva az EXDOS-rol en azt latom, hogy elvileg elegge modularis; ugye nem csak az alacsony szintu rutinokat lehetne helyettesiteni (pl IDE a WD helyett ...) hanem magat a filerendszer kezeleset is. Es itt nem csak FAT12->16-ra gondolok hanem pl vmi tok mas filerendszerre ... Bar kicsit elvesztem igy a DISKIO/FISH/egyeb dolgok kozott, ami most igy remlik, bar regen neztem mar :)
Title: Re: EP128emu
Post by: Zozosoft on 2013.May.02. 22:55:25
Kicsit régészkedtem a régi emulátor verziók között:
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.
Title: Re: EP128emu
Post by: Attus on 2013.May.03. 11:13:50
Quote from: IstvanV
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.
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.
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.
Title: Re: EP128emu
Post by: szalai56 on 2013.May.03. 13:56:35
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.
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.
Bocs az off-ért: mi van az UHU-val?
Title: Re: EP128emu
Post by: Attus on 2013.May.03. 15:18:17
[offtopic]
Él és virul a gépemen, sokunk gépén az ubk frissített változata.
A gnome_3.4 is üzemel jóvoltomból, ami ki is nyírta a gnome2 -őt, helyette most ott a mate felület Rezső barátom jóvoltából, és a legújabb kde meg Bandi jóvoltából. Mi tartjuk életben és frissen.
A dev ágon meg ki szerették volna hozna májusra a gnome-3.8 alapú új kiadást, de valami miatt nem megy még mindig a gdm, és a gnome3.
Remélem pár hónap és meglesz az új hivatalos kiadás, ha sikerül megoldani a aproblémát.
Most mate felületen írok, kernel-3.8.4,  gcc_4.7.2-2, firefox_20.0.1-2 [/offtopic]
Title: Re: EP128emu
Post by: Z80System on 2013.May.03. 17:18:10
Quote
Kicsit régészkedtem a régi emulátor verziók között:
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.
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.
Title: Re: EP128emu
Post by: Zozosoft on 2013.May.03. 18:22:27
Lacika kérésére aktuális EXE
Title: Re: EP128emu
Post by: Attus on 2013.May.06. 20:36:02
Végül sikerült megcsinálnom az ep128emu_2.0.9 UHU csomagját, de gond van.
Az fltk-1.1.10 -et meg kellett csinálnom. Ennek ellenére nem találta a jpeg, png, zlib fejeket, hiába adtam meg neki az illető fejéc csomagokat a fordításhoz.
Rájöttem, hogy az fltk-t ezekkel az opciókkal kellett lefordítanom:
 
   ub_configure \
    --enable-threads \
    --enable-xinerama \
    --enable-xft \
    --enable-xdbe \
    --enable-largefile \
    --enable-localjpeg \
    --enable-localpng \
    --enable-localzlib

Először a gentoo dead ( mivel már rég túlhaladott) ebuildjei szerint akartam csinálni, ott --disable-localjpeg cuccok voltak, azzal az fltk csomaggal nem volt jó, mert nem találta a libjpeg cuccot még mindig az ep128emu scons -a.
Továbbá át kellett neveznem az fltk cuccost fltk1 -re, hogy ne ütközzön a rendszerem lévő fltk2 és efltk2 csomagok fájljaival, az új fltk1 csomagban a flud.desktop fájlt átnevezni fluid1.desktoppá, továbbá a fluid.1 -et is átneveztem fluid1.1 -é, így már telepíthetővé vált a fluid1 csomag.

Most az a gondom, hogy a feltelepített ep128emu aszongya, hogy nincs hang eszköze.
Pedig a fordításhoz megkapta a portaudio-dev ás libsndfile-dev csomagokat.

Az egykori, a binárisból készített ep128emu csomag hangos, annak mérete 2.1 Mb, ezé, a forrásból készülté meg mindössze 1 Mb.

Pulseaudio rendszerem van itt a gnome3 alatt.
Csatolom a csomagkészítési logot. Én nem látok benne a hangra vonatkozóan semmit.

Nincs valami tipped István?
Title: Re: EP128emu
Post by: Attus on 2013.May.07. 14:17:46
Nekem van.:)
A parancs: padsp ep128emu
És van hang!
Egyébként, ha hozzáveszem, hogy az fltk1 csomag mérete, amit az ep128emuhoz a telepítő felránt 700 Kb, akkor 400 Kb a spórolás, ami csak az EP valós világában számottevő méret.
Egy teljes 360 -as floppy több szektorra formázva!
:ds_icon_cheesygrin:

Ujjgyakorlatlatnak jó volt ez a fordítási móka, most még csinálok egy kis csiszolást, hogy egértologatós júzerkámnak is hangos legyen az ep128emu, ha az indító ikonra, vagy menüponra kattint.
Oszt így lesz egy frissebb verziójú ep128emu telepítő csomagjuk az UHU -soknak.
Title: Re: EP128emu
Post by: Attus on 2013.May.07. 19:57:36
Elkészült, letölthető innen: ftp://ubk.hu/pkg/2.2/
Title: Re: EP128emu
Post by: Zozosoft on 2013.July.10. 15:19:46
Spektrum emulátor részben hogyan lehetne átdefiniálni a billentyűzetet, ha több billentyűt szeretnék? :-)
Adott egy orosz Spektrum (http://www.leningrad.su/museum/show_calc.php?n=319), amire több gombot raktak az átlagnál, oly módon, hogy az ULA port olvasásánál eredetileg nem használt 5-ös és 7-es bitre is raktak 8+3 gombot.
[attach=1]
Köztük van a ciril-re kapcsolás gombja is :-)

Ezeket hogyan lehetne beüzemelni a zx128emu-ban?

A zx128vm.cpp-ben a keyboardConvTable-t kéne piszkálni? :-)
Vagy az emu-ból mentett konfig fájl is tartalmaz egy csomó keyboard sort, ezekkel is lehetne?

Itt a gép ROM-ja, debuggerben 5c37h címre kell 39h-t vagy 3ch-t írnia karakterkészlet váltáshoz.
:-)
Title: Re: EP128emu
Post by: IstvanV on 2013.July.11. 09:45:22
A keyboardConvTable[] az EP-s billentyűket konvertálja Spectrumra. Egy EP billentyűhöz két Spectrum billentyű rendelhető, azaz lehetőség van az EP billentyűket Spectrumos billentyű kombinációra konvertálni. A konverziót a ZX128VM::convertKeyboardState() függvény végzi. Ha a billentyűzet mátrixnak ötnél több oszlopa van, akkor szükség lehet az ula.cpp módosítására is, hogy az eddig nem használt bitek ne legyenek fix értékűek.

A konfigurációs file-okban csak EP billentyűzet lehet, a Spectrum és CPC emulátorok ezt konvertálják egy táblázat alapján.
Title: Re: EP128emu
Post by: Zozosoft on 2013.July.11. 10:01:58
Quote from: IstvanV
A konverziót a ZX128VM::convertKeyboardState() függvény végzi.
És ennek a táblázatnak mi a felépítése?
Title: Re: EP128emu
Post by: IstvanV on 2013.July.11. 10:15:34
keyboardConvTable[EP_billentyű * 2] = ZX_billentyű_1
keyboardConvTable[EP_billentyű * 2 + 1] = ZX_billentyű_2

Az "EP_billentyű" egy 0 és 127 közötti érték, amelynek az értelmezése azonos a konfigurációs file-okkal (sor[0..9] * 8 + oszlop[0..7], EXT1: 112-116, EXT2: 120-124), és a táblázatnál a megjegyzésekben is látható.

A "ZX_billentyű" 0 és 63 között Spectrum billentyű kód (sor[0..7] * 8 + oszlop[0..4]), 64 és 68 között joystick (Kempston), és a 69 vagy nagyobb érték nem használt billentyű. Az oszlopok számának a növeléséhez az ula.cpp-ben az ULA::setKeyboardState() függvényt kell módósítani, ebben a "| 0xE0"  művelet állítja 1-re az eredetileg nem használt biteket; ez a művelet megtalálható a snapshot/demo betöltésnél is (ULA::loadState()).
Title: Re: EP128emu
Post by: Zozosoft on 2013.July.11. 11:01:56
És ha jól tippelem, az ULA::readPort-ból kell kivenni azt a részt ami a lebegést állítja be a nem használt bitekre.
Title: Re: EP128emu
Post by: Lacika on 2013.July.17. 22:21:07
Valami gond lehet a módosított emuval.
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.
Title: Re: EP128emu
Post by: IstvanV on 2013.July.18. 09:19:14
Quote from: Lacika
Valami gond lehet a módosított emuval.
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.
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).

Az AVI-t mivel játszottad le ? Egyes programoknak problémát okozhat a 8 bites RLE formátum lejátszása. mert ez meglehetősen ritka (filmeknél például nem is lenne értelme), és ezért nem támogatják a palettát használó formátumokat. A mencoder (http://www.mplayerhq.hu/design7/news.html) segítségével a file tetszőleges egyéb formátumra (MPEG4 stb.) konvertálható. Egy másik megoldás az emulátorban a kis felbontású YV12 formátum beállítása, de ez rontja a kép minőségét.
Title: Re: EP128emu
Post by: szipucsu on 2013.July.18. 10:26:22
A színek szerintem is rosszak. Régebben jók voltak. Régebben tettem be ide képeket is ezt bemutatni, ebben a hozzászólásban. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg25596/#msg25596)
Title: Re: EP128emu
Post by: Lacika on 2013.July.18. 18:06:01
Quote from: IstvanV
Az AVI-t mivel játszottad le ?
VLVPlayer 1.1.11
Title: Re: EP128emu
Post by: IstvanV on 2013.July.18. 18:46:25
VLC Player ? Azzal nekem is hibásak a színek, illetve a 2.0.7 verzióval nincs is kép. Az MPlayer működik, csak "Next line is beyond picture bounds" figyelmeztetéseket ír ki.
Title: Re: EP128emu
Post by: varrogy on 2013.July.21. 19:48:43
Sziasztok

Valahogy szerintetek megoldható, hogy begépeltessünk programkóddal szöveget az Ep128Emu-ba?
Tehát úgymond nem billentyűzetről, hanem egy pl saját C függvénnyel amit fel lehetne paraméterezni és azt végrehajtaná az emu a kurzorral jelzett helyen.


Gyuri
Title: Re: EP128emu
Post by: Zozosoft on 2013.August.30. 16:43:25
Quote from: IstvanV
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:

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ő:
Elvileg lehetséges lenne új funkciókat hozzáadni, amivel egyes emulátor funkciókat lehetne az emulált EP-ből vezérelni?
Ilyenekre gondolok, hogy pl, munkakönyvtár váltás, lemezkép váltás.
Pl:
:SWD C:\EP\GAMES\NODES
vagy
:DRVA C:\EP\IMAGES\GAMES01.IMG
Title: Re: EP128emu
Post by: IstvanV on 2013.August.30. 16:45:43
Igen, bár a funkciók korlátozásának "biztonsági" célja is van, azaz például hogy egy hibás EP program ne tudjon bármit felülírni a PC-n.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 17:23:38
Ha az emuban átváltom a keretet fehérre, akkor a kép tetején a keret "felett" lesz egy fekete csík. Az emu menüjének alja, és az emulált kép (felső keret) teteje között.

Ez a vékony fekete csík akkor is ottmarad, ha az ablakot extra szélesre húzom, és így kopptól koppig ki kéne használja a függőleges kiterjedést.

Nem nagy baj, de legyen leírva, hátha adott alkalomkor csak két sor módosítás lesz.
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 17:27:11
Nekem nincs fekete csík. Biztos, hogy nem az LPT hibája (túl sok fekete sor a VSYNC után) ?
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 17:40:44
Quote
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:

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 ?
Title: Re: EP128emu
Post by: endi on 2013.November.15. 17:50:28
aztán tökkkéletes legyen ám az a game
nehogy két fekete csík legyen fent meg lent
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 17:53:05
Quote
aztán tökkkéletes legyen ám az a game
Csak game demo. Nem game.


Quote
nehogy két fekete csík legyen fent meg lent

Rajta vok.
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 17:59:45
Quote from: Z80System
Megnéztem az EXOS LPT -jeivel és az tényleg jó. :oops:

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 ?
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ó. :)

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.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 18:17:50
Quote
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 ? :)

Nálam olyan az LPT, hogy:

- Placeholder LPB. Csak azért van, mert az EXOS leírásban megadott szinkron LPB sorainak száma és a hasznos LPB -im sorainak száma még nem adja ki a 312 -t.

- Értékes LPB -k. Konkrétan 272 rasztersornyi.

- Mégegy placeholder LPB. Ugyanazért van, amiért a másik is, és azért fogják közre az értékes sorokat, hogy az értékes sorok középen legyenek függőlegesen a képen.

- Szinkron LPB -k. Szám szerint 4 darab, az EXOS leírásból "kimásolva".

Az értékes LPB -kben annyi raszter van, amennyit írtam, a szinkronokban annyi, amennyit az EXOS leírás megadott, és a két placeholderben a maradék elosztva két részre.

Az összes együtt tutkóra 312.

Szal mi az a "szinkron után túl sok fekete sor" ? Ez egy új szabály, amit eddig még sosem hallottam ...
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 18:32:02
A "placeholder LPB" meg így néz ki, mindkettő:

sorszam, D_MB_VideoMode_Pixel, 63, 0, 0,0,0,0,0,0,0,0,0,0,0,0
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 18:49:02
Idemásolom a többit is:

felső placeholder:
 0, D_MB_VideoMode_Pixel, 63, 0, 0,0,0,0,0,0,0,0,0,0,0,0

alsó placeholder:
 0, D_MB_VideoMode_Pixel, 63, 0, 0,0,0,0,0,0,0,0,0,0,0,0,

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

és persze a két placeholder között ott vannak a hasznosak
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 19:02:18
Quote from: Z80System
hanem a szinkron után szerinted nem lehetnek "fekete sor" -ok, de az meg mi a mák ? Milyen legyen, fehér ? :)
Keretszínű.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 19:06:29
Quote
Keretszínű.
Dehát nekem keretszínű, nem ? Azért van a placeholder LPB -kben gondolom a kicsavart 63,0 keret, nem ?

Mégis ilyen:

[attach=1]
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 19:06:43
Quote from: Z80System
szinkron:
 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, 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.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 19:12:13
Quote
Itt a hiba,

Márpedig én ezt nem magamtól találtam ki:

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 ?
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 19:18:08
Quote from: Z80System
Márpedig én ezt nem magamtól találtam ki:

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.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 19:25:41
Quote
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ő ...

Egyébként elég volt a 19 -et átírnom 17 -re, és eltűnt felülről a hézag.

Pedig a felszabadult 2 sort a kódom így a placeholder LPB -imbe osztotta el, 1-1 sor formájában.
Title: Re: EP128emu
Post by: endi on 2013.November.15. 19:28:36
Quote from: IstvanV
 mert például Commodore gépeken csak 18 fekete (blank+sync) sor van összesen.
Ebben is jobb a Kommondor. :(
Milyen gáz ez az EP... :(
:)
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 19:32:45
Quote
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 ?

Vagyis csak a doksi rossz, maga az EXOS szinkron kódja jó kell legyen ...
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 20:21:22
EXOS 2.1-en BRD.ROM nélkül csak 13 fekete sor található az LPT-ben a függőleges visszafutásra, a BRD.ROM viszont az EXOS könyvhöz hasonlóan ezt 26-ra növeli.
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 20:24:48
Quote
, 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 ?
Title: Re: EP128emu
Post by: IstvanV on 2013.November.15. 20:27:11
Quote from: Z80System
Ami azt jelenti, hogy ezzel a BRD.ROM -mal megjelenik felül a fekete csík az emuban EXOS képernyőkön is
Igen. Csak általában fekete a keret, ezért nem feltűnő. :)
Title: Re: EP128emu
Post by: Z80System on 2013.November.15. 20:32:28
Quote
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 ?

( Egyébként ez mi, hogy a BRD -ben LPT kód van ? Az EXOS nincsen nyelvesítve, nem ? EXOS csak egy van, es a BRD cucc az a cartridge -ban van, és a BASIC -et tartalmazza németesítve ... nem ? Miért kéne a német ROM -nak LPT kódot tartalmaznia ? )
Title: Re: EP128emu
Post by: szipucsu on 2013.November.16. 13:19:29
Quote from: endi
Ebben is jobb a Kommondor. :(
Milyen gáz ez az EP... :(
:)
Pont fordítva, nem? Commodore-on csak 18 van, EP-n nekünk több jutott, 26, nekünk több van!
Title: Re: EP128emu
Post by: Povi on 2013.November.22. 16:32:09
emulátorban a PRINTER: csatornára küldött cuccok a nyomtatóra mennek?
vagy ki lehet őket küldeni egy fájlba valahogy?
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.22. 16:46:59
Korábban raktam fel Printer LUA scripteket:
Debugger ablakba író (http://enterpriseforever.com/emulatorok/lua-scriptek-fejlesztese/?action=dlattach;attach=7143)
Fájlba író (http://enterpriseforever.com/emulatorok/lua-scriptek-fejlesztese/?action=dlattach;attach=7144)

Speakeasy dekódoló (http://enterpriseforever.com/emulatorok/lua-scriptek-fejlesztese/?action=dlattach;attach=7152)
Title: Re: EP128emu
Post by: Povi on 2013.November.22. 18:00:29
öööö, hova? és hogy működik? :oops:
Title: Re: EP128emu
Post by: Lacika on 2013.November.22. 18:04:27
Quote from: Povi
öööö, hova? és hogy működik? :oops:
Igen, ez közérdekű info lenne... :oops:
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.22. 18:12:34
Quote from: Povi
öööö, hova? és hogy működik? :oops:
Már belinkeltem :-)
Betöltöd a debuggerbe, RUN aztán CONTINUE.
Ezután ami a Printer portra ki lesz küldve, az megnézhető a debugger ablakban, vagy el lesz mentve a fájlba (alapból PRINTER.TXT, a RUN megnyomása előtt átírható).
Title: Re: EP128emu
Post by: Povi on 2013.November.22. 20:43:59
az, hogy a FILE: eszköz nem működik a HEASS-ban, az emulátor hiba, vagy HEASS hiba?
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.22. 20:50:45
Quote from: Povi
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?
Title: Re: EP128emu
Post by: Povi on 2013.November.22. 20:58:31
a MERGE parancs nem működik
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.22. 21:11:28
Quote from: Povi
a MERGE parancs nem működik
Az a baj, hogy a FILE nem fájlkezelő eszköz :-( (EXOS 10-et nem kezeli)
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.22. 21:13:19
Úgy lehet kikerülni, hogy kell egy .BAT fájl ami az ilyen cuccokat bemásolja RAMDISK-be, és a forrásban E:-ről kell tölteni, úgy megy.
Title: Re: EP128emu
Post by: Povi on 2013.November.22. 22:24:06
ez jó ötlet, a RAMDISK eszembe se jutott! :-)
Title: Re: EP128emu
Post by: Povi on 2013.November.25. 20:39:33
az normális dolog, hogy a munkahelyemen (intel i5, windows 7) más időeredmények (rövidebbek) jönnek ki a timer.lua-val, mint itthon (pentium G860, windows xp)? az emulátor verziója ugyanaz
Title: Re: EP128emu
Post by: IstvanV on 2013.November.25. 22:53:19
Mennyivel rövidebbek ? A PC-s CPU sebessége elvileg nem befolyásolhatja az eredményt, mert a script nem valós, hanem "emulált" időt mér, és Alt+W módban is pontos marad. Nem lehetséges azonban, hogy a két gépen nem azonos az emulátor konfigurációja (Z80, NICK, DAVE sebesség, RAM méret, ROM-ok) ?
Title: Re: EP128emu
Post by: Povi on 2013.November.26. 09:15:54
a két emulált ep config-ja nem egyforma (más ROM-ok). Érdekes, nem gondoltam volna, hogy ez befolyásolja, pedig logikus :-) Most kipróbáltam EXDOS nélkül, és majdnem 10%-al gyorsabb lett a futás. Gondolom hosszabb a megszakítási rutin...
Title: Re: EP128emu
Post by: Zozosoft on 2013.November.26. 09:24:28
Quote from: Povi
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.
Title: Re: EP128emu
Post by: Povi on 2013.December.03. 22:37:33
hogyan lehet a debuggerben megmondani, hogy álljon meg egy helyen a futás, hogy kiolvashassam a regiszterek értékeit?
Title: Re: EP128emu
Post by: Zozosoft on 2013.December.03. 23:03:06
Quote from: Povi
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
0100
Megáll ha bármi történik 0100h-n.
5800-5aff
Megáll ha bármi történik 5800h-5affh között.
b1
megáll ha bármi történik a B1h porton
b0-b3
megáll ha bármi történik B0h-B3h portokon
Lehet utótagokat is tenni: r, w, x, i azaz olvasás, írás, végrehajtás, figyelmen kívül hagyás (ignore)
0100-01ffx
0180-018fi
Ez esetben megáll ha utasítás olvasás van a 0100-01ffh területen, kivéve a 0180-018f területet.

Lehetséges szegmensre is hivatkozni, pl
20:c00ax
Ez estben az EXDOS ROM rendszerbővítő belépési pontján fog megállni.
Title: Re: EP128emu
Post by: szipucsu on 2013.December.17. 12:40:16
Már volt szó róla, de nem találom:

Hogyan lehet átállítani (Windows XP alatt), hogy a snapshotokat opengl vagy software módban indítsa el az emulátor? Azt sejtem, hogy valaminek a végére oda kell írni, hogy -opengl vagy -no-opengl, a windowsos parancsikonokból. De ezt hova kell írni? A mappa beállításai - fájltípusok menüpontnál az Explorerben van Speciális gomb, azon belül kell beírni, gondolom, csak nem tudom, hova. A DDE-üzenetnél nem volt hatása, az Alkalmazás felirat alatt sem, úgy látom. "A művelet végrehajtásához használt alkalmazás" végén sem volt hatásos.
[attachimg=1]

Ha elindítom előbb az emulátort software módban, csak onnan tudom betölteni a snapshotot software módban.
Title: Re: EP128emu
Post by: IstvanV on 2013.December.17. 13:09:18
Quote from: szipucsu
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 ...).
Title: Re: EP128emu
Post by: Tuby128 on 2014.August.16. 23:04:36
Üdv!

 Most ismerkedem ezzel a szoftverrel, és keresem a lehetőséget, hogy német billentyűzetű PC-hez betöltsek egy billentyűzet-map fájlt. A program könyvárában csak magyar és UK elérhető. Nincs valakinek valahol egy ilyen MAP file készen?
Title: Re: EP128emu
Post by: Tuby128 on 2014.August.17. 11:31:48
Esetleg azt meg tudná írni valaki, hogyan lehet teljes képernyőre váltani?
Title: Re: EP128emu
Post by: szipucsu on 2014.August.17. 11:44:34
Quote from: Tuby128
Esetleg azt meg tudná írni valaki, hogyan lehet teljes képernyőre váltani?
F9
Title: Re: EP128emu
Post by: Kapitany on 2014.September.07. 21:02:54
Sziasztok!

Linux alatt valahogy el lehet érni a windowsos ikonokat? Szeretném beállítani az asztalra kitett parancsikonnak rendesen az ikonját....
Title: Re: EP128emu
Post by: dp304 on 2014.September.07. 22:01:32
Quote from: Kapitany
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.
Ha a deszktop környezet ezt nem kezeli, akkor át lehet konvertálni pl. .png-re, pl. az ImageMagick csomagban levő "convert" programmal.
Title: Re: EP128emu
Post by: Attus on 2014.September.07. 22:33:44
Quote from: Kapitany
Sziasztok!

Linux alatt valahogy el lehet érni a windowsos ikonokat? Szeretném beállítani az asztalra kitett parancsikonnak rendesen az ikonját....
Windowsos ikont sehogy.
Linuxonként, asztalkezelőként változó módon lehet az asztalra indítóikont rakni.

Ha már kinn van, akkor megeditálod valamilyen szövegeditorral a desktop fájlt.
Nálam a ~/Desktop könyvtárban vannak az asztali alkalmazás "parancsikonok"

Ilyen az enyim:
[Desktop Entry]
Type=Application
Name=Ep128emu
Comment=
Exec=ep128emu
Icon=/usr/share/pixmaps/ep128emu.png
Terminal=false
StartupNotify=false

Van olyan desktop felület, melynél egér jobbszemmel rákattintva lehetőség van az ikonkép beállítására a felbukkanó fájlkezelővel.
Az icon sorba írd be az ikonképet útvonallal.

Illetve olyan is, ha feltelepíteddel csomagkezelővel, akkor a menüsorból az asztalra húzható ikonostul együtt.
pl. KDE, XFCE4 felület alatt.
Nézd meg, hátha van a disztródhoz kész csomag a csomagkezelőddel.

(icewm, fluxbox alatt másképp, de ott is működik a dolog :cool: )
Title: Re: EP128emu
Post by: Kapitany on 2014.September.08. 15:09:38
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.
Title: Re: EP128emu
Post by: dp304 on 2014.September.08. 23:51:12
Quote from: Kapitany
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.
Bináris csomagban lehet, hogy nincs benne.
Title: Re: EP128emu
Post by: Povi on 2014.September.14. 17:08:07
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?
Vagy értéket adni regiszternek?
Title: Re: EP128emu
Post by: IstvanV on 2014.September.14. 20:44:54
Quote from: Povi
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?
Vagy értéket adni regiszternek?
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.
Title: Re: EP128emu
Post by: szipucsu on 2015.March.28. 17:28:30
Nem lehet valahogy úgy videót rögzíteni az emulátorral, hogy az emulátor hangja mellett a mikrofonról bejövő hangot is felvegye? Így lehetne "oktató videót" készíteni pl. a Music Box kezeléséhez.
Vagy külső programmal sem tudom, ezt hogy lehetne megoldani, mert ott is egyszerre kéne a mikrofonról és a belső hangforrásból is felvenni...
Title: Re: EP128emu
Post by: IstvanV on 2015.March.29. 18:41:53
Egy lehetséges megoldás a mikrofonról felvételt készíteni az emulátor futása közben, és utána video szerkesztő programmal hozzákeverni az AVI file-hoz.
Title: Re: EP128emu
Post by: nyuzga on 2015.March.29. 21:36:24
Ez meg egy másik megoldás. :)
Title: Re: EP128emu
Post by: Povi on 2015.April.17. 16:46:19
hogyan lehet olyan töréspontot tenni az emulátorba, hogy PC=érték és (HL < 2000h vagy HL > 4000h)?

Title: Re: EP128emu
Post by: IstvanV on 2015.April.17. 17:52:55
Lua script (a 0x3000 a töréspont címe):

Code: Lua
  1. setBreakPoint(4, 0x3000, 3)
  2.  
  3. function breakPointCallback(t, a, v)
  4.   if t == 0 and a == 0x3000 then
  5.     return (getHL() < 0x2000 or getHL() > 0x4000)
  6.   end
  7.   return true
  8. end
Title: Re: EP128emu
Post by: IstvanV on 2015.April.17. 17:54:23
Az első sor csak a töréspontot állítja be, ez lehet a scripten kívül is.
Title: Re: EP128emu
Post by: Povi on 2015.April.17. 19:29:05
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?
Title: Re: EP128emu
Post by: IstvanV on 2015.April.18. 08:47:39
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?

Az script nélkül is megoldható, "i" töréspont használatával. Például a "2000-3fffi" figyelmen kívül hagyja a 2000h-3fffh területet.
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 11:16:00
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:
Title: Re: EP128emu
Post by: lgb on 2015.June.04. 11:20:55
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 forditani, es akkor kis lehetne tenni vhova. Elvegre GNU/GPL az is, licenc problema nincs, barki modosithatja, ha kozkincse is teszi aztan forrasostul. 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. A masik nyelv, amit soha nem voltam kepes megtanulni, pedig probaltam, az a perl. Nekem az inkabb vonali zaj, mint programozasi nyelv, igy ranezesre :)
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 15:15:00
Velem is az a baj, hogy tök megfelelő az ep128emu nekem, a C nyelvhez meg jóformán tök vagyok.
Kár, hogy a frisebb fluid-al már nem megy az ep128emu.
Leragadtam még anno a z80 assemblernél, meg egy kicsit később a 8086 -os masm -nál, a C fejlesztésbe nem is tudnék beszállni.
Nagyon elfoglal mostanság az UHU-Linux életben tartása.
Mint anno az EP életben tartása.
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 15:25:33
Hat, ha valaki ki tudja javitani a forrasban, az alapjan csak le lehet forditani
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
Title: Re: EP128emu
Post by: szipucsu on 2015.June.04. 15:49:13
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.
Title: Re: EP128emu
Post by: lgb on 2015.June.04. 15:49:30
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

Ezt en ertem, csak erre mondtam, hogy meg kell csinalni egyszer, aztan a "jo" cuccokat becsomagolni egy zip-be, tudomisen, es ugy feltenni valahova, hogy "itt a javitott verzio, ezt vigyetek". Vagy nem tudom, windows alatt eletemben nem telepitettem meg semmit :) tehat lehet en nem ertem, mi itt a gond :D
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 16:10:06
Vagy nem tudom, windows alatt eletemben nem telepitettem meg semmit :) tehat lehet en nem ertem, mi itt a gond :D
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.
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 16:24:02
Az megtörtént...
A forrásban történt a javítás csak és a kész binárisokban nem?
É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
Title: Re: EP128emu
Post by: lgb on 2015.June.04. 16:28:59
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.

Ez a windows, mindig csak a gond van vele :) Nade komolytalanra forditva a szot: nem lehet csinalni egy telepitos izet aztan az egeszbol? Sajat telepitoje van, vagy hogy megy ez? Lehet rohogni, total otletem sincs a windows dolgai kapcsan.
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 16:43:25
A forrásban történt a javítás csak és a kész binárisokban nem?
É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
Ott az István által elkövetett hivatalos verzió lenne...

Itt vannak. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg36039/#msg36039)
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 16:52:21
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.
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 17:04:18
Ott az István által elkövetett hivatalos verzió lenne...

Itt vannak. (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg36039/#msg36039)
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
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 17:56:06
Csináltam egy foltot a forrásból az eddigiekből.

Belevettem még ezt (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg35956/#msg35956), meg ezt (http://enterpriseforever.com/ep128emu/ep128emu-2-0-9/msg35958/#msg35958) is.
Van még valami módosítás, ami még nincs benne?
Title: Re: EP128emu
Post by: lgb on 2015.June.04. 18:23:58
Saját telepítője van, amit István tud csinálni.

Akkor nem ertem, elobb az volt a mondas, hogy a windows-ban mindent a rendszer felugyel, azert nem jo egy zip kibontasa stb. De akkor ez ugyanaz, csak helyetted bontja ki, annyi a kulonbseg. vagy meg mindig nem ertek valamit.  :) Sot, biztos :)
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 19:43:02
meg mindig nem ertek valamit.  :) Sot, biztos :)
Előbb már leírtam, hogy mit csinál a telepítő :-)
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.04. 19:44:02
http://ep128emu.enterpriseforever.com/roms/ep128emu_roms.bin
Ha ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.
Title: Re: EP128emu
Post by: lgb on 2015.June.04. 20:04:44
Előbb már leírtam, hogy mit csinál a telepítő :-)

Ok, feladom, ezt a windowst az eletben nem fogom megerteni, olyan nyakatekert sz** :) Maradok inkabb a UNIX rendszereknel, ahogy isten megteremtette a dolgokat :)
Title: Re: EP128emu
Post by: szipucsu on 2015.June.04. 20:14:07
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á...
Title: Re: EP128emu
Post by: DrPrery on 2015.June.04. 20:29:22
Talán az InnoSetup-ot lehetne használni...?  :smt017

http://www.jrsoftware.org/isinfo.php (http://www.jrsoftware.org/isinfo.php)
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 20:41:02
Ha ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.
Az.
Bele tudnék valami jobbat is tenni az UHU telepítőbe, ha lenne jobb valahol.
Title: Re: EP128emu
Post by: Attus on 2015.June.04. 20:45:42
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.
Nem hiszem,hogy csak az egerészés lett meghagyva a windóznak,legyen bár az akár a tizes és ne tudna futtatni kötegelt utasításfájlt.
XP-n még lehet, az biztos, abból van még nekem, amit úgy félévente bekapcsolok.
Title: Re: EP128emu
Post by: szipucsu on 2015.June.04. 21:48:35
Mintha valamelyik WinZip verzióban lett volna olyan lehetőség, hogy önkicsomagoló fájl készítése. Tehát kicsomizza magát, akkor is, ha nincs is Zip telepítve. Talán van még ilyen valamelyik ingyenes tömörítőben is.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.16. 00:01:23
A disk_cfg_fl.cpp régi fájlt nem lelem a letöltött és kicsomagolt forrásban. Ez új?

Az _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.

Kár, hogy a frisebb fluid-al már nem megy az ep128emu.

Csak FLTK 1.1.x és 1.3.x támogatott, a 2.x nem kompatibilis ezekkel.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.16. 00:13:58
Saját telepítője van, amit István tud csinálni.

Illetve bárki más, aki letölti az NSIS 2 (http://sourceforge.net/projects/nsis/files/)-t (Nullsoft Scriptable Install System). :) A használata egyszerű, csak makensis.exe ep128emu.nsi-t kell futtatni az ep128emu2/installer könyvtárban, és ez elkészíti az installert, amely természetesen az .nsi file szerkesztésével módosítható is.

Az installer létrehozása előtt még futtatható a strip az összes .exe-n (így valamivel kisebb lesz a méretük), illetve a már meglevő telepített verzióból a LICENSE file-ok, amelyeket a forrás csomag nem tartalmaz, az ep128emu2 könyvtárba másolhatók.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.16. 00:23:28
Ha ez a gyári csomag, akkor biztos, hogy csomó minden elavult benne.

Az ep128emu_roms.bin csomag az epcompress (https://enterpriseforever.com/programozas/fajltomorites-enterprise-on/msg31929/#msg31929) segítségével készíthető:

Code: [Select]
epcompress -a -m2 -9 @rom_list.txt ep128emu_roms.bin
[attachurl=1]
Title: Re: EP128emu
Post by: Attus on 2015.June.16. 08:35:34
Az _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.

Nekem nem nagy gond, mert fltk_1 és fltk2 egymással nem ütköző csomagkészlet létezik, legalábbis UHU -n, direkt az ep128emu kedvéért kreáltam az fltk1 készletet.
Más már talán nem is igényli.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.19. 11:31:04
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. Ezen kívül az emulációs "motor" jól elválasztható a magasabb szintű részektől, mint például a GUI, video és hang kimenet, debugger, stb., és az egész egy API-n keresztül elérhető, ami beépíthető más programokba. Ezért viszonylag könnyen lehetne például egy minimális SDL-es emulátor verziót készíteni. Az összes hardver komponens (Z80, NICK, DAVE, AY, stb.) szintén könnyen használható az emulátor többi része nélkül.

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. :)
Title: Re: EP128emu
Post by: lgb on 2015.June.19. 11:37:38
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.

En mar ezt a namespace stb dolgokat se ertem :) Hogy egyaltalan mire jo, es miert kell. C++-t parszor nekialltam tanulni, de kb olyan, mintha egy osembernek kezdenel kvantumfizikat magyarazni, csak neztem nagy szemekkel, hogy WTF, es elvesztem a tutorial eleje fele mar :) Az OOP sem nagy baratom valahogy, bar erdekes, hogy pl Python-nal ez nem zavar :)

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

En Plus4 eseten mindig kicsit elveszve erzem magam. Van a VICE-ban ugye emulacio ra, de sokak szerint finoman szolva is "pontatlan". Mivel Plus4-el igazan sose foglalkoztam, nem tudom ezt megitelni. Aztan ott van pl a Yape, amit anno en is fejlesztgettem, ott is a C++-t akartam kidobni :) Sajnos az ujabb Yape verziok mar Windows-only cuccok, ha jol remlik. A plus4emu ezekhez kepest hogy all?

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

Na igen :) Meg emu fuggetlen haszna is van: az ember tanul egy csomo dolgot, amit aztan total mas helyeken tud hasznositani akar, adott esetben. Pl JSep eseten en Javascript-et kozben tanultam meg, meg is latszik rajta :) A masik meg: valoban, ha az ember emulal vmit, arrol is tanul egy rakas dolgot.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.19. 12:33:26
En mar ezt a namespace stb dolgokat se ertem :)

A namespace gyakorlatilag arra jó, hogy egyszerű globális neveket lehessen használni anélkül, hogy mással ütköznének. Itt például

namespace Ep128 {
  class Z80 {
    ...
  };
}

a namespace-n belül a "Z80"-ra egyszerűen Z80-ként lehet hivatkozni, azon kívül viszont Ep128::Z80 lesz. De az "using Ep128::Z80" után már itt is csak Z80, az "using namespace Ep128" pedig mindent "importál" a namespace-ből.

Ez C-ben talán így nézne ki:

typedef struct {
  ...
} Ep128_Z80;

Egyszerű OOP gyakran fordul elő C-ben, ez például:

Ep128_Z80 *Ep128_Z80_new(void);
void Ep128_Z80_delete(Ep128_Z80 *z80);
void Ep128_Z80_run(Ep128_Z80 *z80, int cycles);

C++-ban így néz ki (maradva a fenti példánál):

namespace Ep128 {
  class Z80 {
    ...
  public:
    Z80();
    ~Z80();
    void run(int cycles);
  };
}

és a namespace-n kívül így használható:

Ep128::Z80 *z80 = new Ep128::Z80();
z80->run(4);
delete z80;

Ez a C-hez képest csak szintaktikai eltérés, amit viszont a C nem (vagy legalábbis csak nehézkesen) tud emulálni, az a "virtual" típusú függvények, amelyeket alosztályokban módosítani lehet.

Quote
A plus4emu ezekhez kepest hogy all?

A plus4emu meglehetősen pontos (és lassú :oops:), amikor még fejlesztettem, lényegesen pontosabb volt, mint a VICE és a régi nyílt forráskódú (0.32 ?) YAPE, és legalább annyira, mint az akkori Windowsos/zárt kódú YAPE (talán 0.7x vagy 0.8 lehetett). Természetesen azóta ezek fejlődhettek, de a plus4emu (és különösen a 6502/TED emulációja, ami részletesebb, mint bármi az ep128emu-ban) már elég pontos volt ahhoz, hogy gyakorlatilag minden fusson rajta, ami nem igényel valamilyen speciális hardver bővítést, amit az emulátor nem ismer.
Title: Re: EP128emu
Post by: lgb on 2015.June.19. 14:58:46
Hmmm. Nem akarsz irni C++ tutorialt? :) Amiket en probaltam megerteni, abban pl ez is olyan homalyos volt, hogy azt elmagyarazni is nehez lenne. Ez igy teljesen ertheto volt, koszi :)
Title: Re: EP128emu
Post by: IstvanV on 2015.June.20. 12:39:54
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

Talán említést érdemel még az itt (https://enterpriseforever.com/emulatorok/xep128/msg47938/#msg47938) található optimalizált quality 3 módú gldisp.cpp (de ezt még tesztelni kell), illetve az SConstruct-ban találtam egy hibát a 227. sorban. Ez azonban csak win32CrossCompile módban eredményez problémát FLTK 1.3.x verzióval (ami például ebben (https://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713) a MinGW csomagban is található - ezzel Linuxon is egyszerűen fordítható Windowsos emulátor, ha a Wine telepítve van), és így talán nem sokan fordítják az emulátort. Ezen kívül a 294. sort módosítottam, hogy win32CrossCompile esetén a Windowsos FLUID-ot használja.

Előfordulhatnak még problémák újabb Linux disztribúciókon, amik SConstruct és egyéb módosításokat igényelhetnek, bár én most le tudtam fordítani az eredeti 2.0.9.1 verziót, és csak a Lua 5.2 okozott hibát, ami miatt 5.1-es devel csomagot kellett telepíteni.
Title: Re: EP128emu
Post by: Attus on 2015.June.20. 22:22:28
Legyártottam a gldisp foltot, lefordítottam vele az emut. :)  UHU-3
Különösebbet nem észleltem eddig a feltelepített emuval.

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.
Hiába, nem értek a fluid -hoz.
Sem. :oops:
Megköszönném, ha megadnád a módosításokat. Monjduk engem a windózos rész nem igazán érdekel, de a többieket, a többséget biztosan az is. Ekkor le lehetne fordítani majd windóz alá is az összegyűjtött változtatásokkal.
Title: Re: EP128emu
Post by: IstvanV on 2015.June.21. 10:19:21
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.

Ha csak annyi a változás, hogy a sávok maximális száma 240 helyett 254 lett, akkor a disk_cfg.fl-ben (ami egyszerű szöveges file) elég 254-re cserélni a 240 minden olyan előfordulását, ami 'Fl_Value_Input floppyATracksValuator' vagy hasonló nevű widgetnél van. Ez összesen 4 módosítás.

Vagy grafikus felületen: a FLUID 1.3-al megnyitni a disk_cfg.fl-t, és az összes "Tracks" widget tulajdonságainál (dupla kattintással jeleníthető meg) a "Maximum"-ot 240-ről 254-re növelni, majd menteni a módosított file-t. De a szöveges keresés/csere itt talán egyszerűbb.

A diff ugyanis a sorvégek miatt mind változásnak jelölte.

Ez elkerülhető a diff -b használatával, ami egyébként a space/tab változásokat is figyelmen kívül hagyja.
Title: Re: EP128emu
Post by: Attus on 2015.June.21. 13:35:23
Köszönöm.
:)

Végülis a fluid1 -el csináltam meg a track növelést, most már napra késznek mondható az ep128emu csomag UHU-3 -hoz. UHU-2.2 is!
A gomb színei változatlanok...
Title: Re: EP128emu
Post by: IstvanV on 2015.June.21. 14:17:55
Kisebb probléma, hogy így a szektorok száma is 254 lehet (Zozosoft verziója csak a sávokat növelte), az emulátor többi részében azonban továbbra is 240-re korlátozott. De ennek a gyakorlatban kevés jelentősége van, különösen mivel a kézi sáv/szektor/fej szám megadás ritkán használt funkció.
Title: Re: EP128emu
Post by: Attus on 2015.June.21. 14:58:34
Azért kijavítom,csak a sávok lesznek növelve.
Köszönöm az észrevételt.

Rend a lelke mindennek.
Title: Re: EP128emu
Post by: Attus on 2015.June.24. 09:10:20
Mi lehet a hiba, miért nem leli a basic a fájlt?
Az 5-ös fejlécek mennek.
Title: Re: EP128emu
Post by: Zozosoft on 2015.June.24. 09:13:43
Nem értem ami a képen van.
Basic LOAD után idézőjelbe kell a fájlnév. EXDOS LOAD-hoz meg kettőspont kéne az elejére. Viszont az BASIC-et nem tölt.
Title: Re: EP128emu
Post by: Attus on 2015.June.24. 09:26:15
Bocs, az idézőjel...
:oops:
Hú, de régen töltöttem be basic programot! :)
Title: Re: EP128emu
Post by: szipucsu on 2015.July.11. 13:33:08
Win7 alatt hogyan lehet megoldani, hogy dupla kattintással a snapshot file software módban induljon el?
Title: Re: EP128emu
Post by: ergoGnomik on 2015.July.11. 14:32:39
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.

Hát, ez az ötlet nem jött be. Nem baj, van másik! A Registry-ben kell egy kicsit matatni hozzá. a HKEY_CLASSES_ROOT\Ep128Emu.SnapshotFile\shell\open\command kulcsnak kell a (Default) REG_SZ értékét módosítani úgy, hogy az alapértelmezett (nálad nem tudom hogyan van pontosan és ezt csak XP-n nézem) "C:\Program Files\ep128emu2\ep128emu.exe" -snapshot "%1" szövegbe beszúrod a -no-opengl parancssori kapcsolót például a - snapshot elé. Vigyázni kell, hogy a módosítással ne íródjon semmi egybe!
Title: Re: EP128emu
Post by: endi on 2015.September.01. 19:12:17
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ént
Title: Re: EP128emu
Post by: szipucsu on 2015.September.01. 19:55:53
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ént
Azt a hex editorban is ki lehet lőni.
Te akarsz lenni az EP-s DJ? :D
Title: Re: EP128emu
Post by: endi on 2015.September.01. 20:11:59
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éje, amiben nagyon durva, hogy ha a szólamokat külön hallgatjuk, van 2 szólam ami önállóan totálisan furcsa zenét ad ki, együtt meg brutál zseniális és nagyon együtt van. még a c64 emulátorban próbáltam régen, ki akarom ep-n is próbálni :)
Title: Re: EP128emu
Post by: szipucsu on 2015.September.01. 21:45:37
van az abyss c. játék zseniális zenéje
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.
Title: Re: EP128emu
Post by: endi on 2015.September.01. 21:47:55
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.

azért más zenék, hangok kielemzéséhez is hasznos lehet.
persze értem én, 1-2 ember fogja csak használni :)
Title: Re: EP128emu
Post by: szipucsu on 2015.September.01. 21:58:37
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.
Title: Re: EP128emu
Post by: szipucsu on 2016.April.17. 10:56:43
Azt hogy lehetne megcsinálni, hogy a snapshot az emulátor software mode-jában nyíljon meg dupla kattintással?
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...
Title: Re: EP128emu
Post by: IstvanV on 2016.April.17. 12:39:16
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 egyszerű beállítani, hogy mi legyen az alapértelmezett program (egy tetszőleges snapshot file tulajdonságainál, vagy a start menüben a "Default Programs"), de így nem tudom, hogyan lehet a teljes parancssort megadni. :oops: Egy lehetséges megoldás egy rövid .bat file-t létrehozni, amely elindítja az emulátort szoftveres módban, és aztán azt társítani az .ep128s és .ep128d file-okkal:

ep128emu.exe -no-opengl -snapshot "%1"

Vagy a regedit segítségével átírni a parancssort, amely a registry-ben ezeknél található:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Ep128Emu.DemoFile\shell\open\command
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Ep128Emu.SnapshotFile\shell\open\command


Itt -no-opengl-t kell hozzáadni a parancssorhoz, például így (eredeti és módosított változat):

"C:\Program Files (x86)\ep128emu2\ep128emu.exe" -snapshot "%1"

"C:\Program Files (x86)\ep128emu2\ep128emu.exe" -no-opengl -snapshot "%1"
Title: Re: EP128emu
Post by: ergoGnomik on 2016.April.17. 12:48:53
Azt hogy lehetne megcsinálni, hogy a snapshot az emulátor software mode-jában nyíljon meg dupla kattintással?
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...
Ahogyan IstvanV írja, és ahogy azt már tavaly júliusban én is említettem.
Title: Re: EP128emu
Post by: szipucsu on 2016.April.17. 14:11:50
Nagynehezen rávettem, hogy elindítsa ezzel a bat file-os módszerrel, de csak akkor megy, ha a snapshot file nem tartalmaz szóközt, és az elérési útvonala sem.

De végül sikerült a Registry-t is átírnom. Hihetetlen, de most már megvan.
Title: Re: EP128emu
Post by: endi on 2016.April.17. 14:29:02
miért kell ehhez registry-ben turkálni?
a file association nem műxik?
nálam szerintem installkor beállította
Title: Re: EP128emu
Post by: szipucsu on 2016.April.17. 14:47:22
miért kell ehhez registry-ben turkálni?
a file association nem műxik?
nálam szerintem installkor beállította
Működne az is, ha alapból vinné a gép az opengl módot, ami az emunál az alap.
Viszont snapshot duplakattintós megnyitásakor alapból az opengl módban akarja az emut megnyitni, ami itt nem működik. Tehát alapból nem lehet megnyitni így duplakattintással a snaphotot.
Így rá kell venni előbb a gépet, hogy software módban nyissa meg az emut snapshot megnyitásakor. Ez volt, ami nem ment nekem, csak többszöri szájbarágós elmondásra.
De majd jön a Windows 11, ott megint minden máshogy lesz, mint ahogy az XP-nél és a Win7-nél megszoktuk. :D
Title: Re: EP128emu
Post by: endi on 2016.April.17. 14:51:04
ja értem
Title: Re: EP128emu
Post by: Zozosoft on 2016.April.17. 14:56:32
Nekem a laptop nem támogatja az opengl-t
Milyen laptop, milyen VGA-val?
Nekem Lenovo X60, valami Intel 945G VGA-val csinált ilyet, az volt a megoldás, hogy nem a Lenovos drivert tettem fel, hanem az Intel oldaláról szedtem le, és lett OpenGL.
Title: Re: EP128emu
Post by: szipucsu on 2016.April.17. 16:03:16
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ő.
Title: Re: EP128emu
Post by: Zozosoft on 2016.April.17. 19:05:03
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.
Title: Re: EP128emu
Post by: szipucsu on 2016.April.17. 19:29:48
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?
Még ami fura, hogy Skype-on nem jelennek meg a profilképek, aminek nem jöttem rá az okára. Az is emiatt lehet?
Title: Re: EP128emu
Post by: endi on 2016.May.27. 10:35:14
ez vajon mi lehet?
Title: Re: EP128emu
Post by: Zozosoft on 2016.May.27. 10:51:25
ez vajon mi lehet?
Quote
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.

Egy üres vinyó image persze, hogy sokkal kisebb tömörítve.
Title: Re: EP128emu
Post by: endi on 2016.May.27. 11:38:41
aha köszi
Title: Re: EP128emu
Post by: lgb on 2016.May.27. 22:53:21
Esetleg torold le az ArchiveBomb-ot az image-rol :-D
Title: Re: EP128emu
Post by: lgb on 2016.July.28. 16:30:24
Mivel erdekel am az ep128emu is (csak nem ertek hozza ...), nem csak a Xep128, csinaltam egy ilyet:

https://github.com/lgblgblgb/ep128emu

Ebbe szepen belepassziroztam a Sourceforge CSV-t, csak most git-ben van. Aztan nekialltam egyenkent commit-olgatni itt mindenfele hozzaszolasokban emlitett fixeket/trukkoket stb.

https://github.com/lgblgblgb/ep128emu/commits/master

Itt latszanak, meg meg lehet nezni forras szinten mi volt a diff, stb. Van valakinek vmi eszrevetele? :)

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. Mert ahogy nezem kb minden *_fl.cpp es *_fl.hpp az generalt, a repository-ban nincs is benne.
Title: Re: EP128emu
Post by: Zozosoft on 2016.July.28. 16:34:58
Az jó lenne, ha el tudnál jutni legalább egy utolsó verziós telepítőig :oops:
Title: Re: EP128emu
Post by: IstvanV on 2016.July.28. 18:10:13
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.

A disk_cfg.fl-t kell módosítani, itt (https://enterpriseforever.com/ep128emu/ep128emu/msg47971/#msg47971) található egy patch ami a sávok maximális számát 254-re növeli.

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.
Title: Re: EP128emu
Post by: lgb on 2016.July.29. 08:58:18
Ez sikerult (marmint ez elvileg installer lenne ...):  http://xep128.lgb.hu/files/ep128emu-2.0.9.1.exe

Istvan, neked van errol otleted? Marmint:

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:

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

Szoval nem igazan ertem en, miert akarna GUI-s dolgot hasznalni a gcc?!?! Masreszt meg DISPLAY tuti oke ... Hmmm, max az az otletem van, hogy scons nem adja at a DISPLAY kornyezet valtozot? Na ez lehet :D Csak ezzel meg az a gond, hogy mivel en tavoli gepen forditok, amugy se mukodne ez tul jol, es forditas miatt most legyen neki X? Nem lehet errol lebeszelni valahogy? :)
Title: Re: EP128emu
Post by: IstvanV on 2016.July.29. 13:08:56
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.
Title: Re: EP128emu
Post by: lgb on 2016.July.29. 13:55:23
Nekem nem volt ilyen probléma, bár én X alatt fordítottam, és nem távoli gépen.

Most neztem, local-ban is ez van ... Fura. Foleg, mert ha copy&paste amit scons csinal a parancssorba, akkor poccre megy, gcc, stb. Viszont az scons-al "csinaltatva" kinszenvedoen lassu es panaszkodik a DISPLAY-re. Pedig mar beleirtom SConstruct-ba is hasonlokat, hogy DISPLAY valtozot adja hozza, de igy is. Hmmm. Majd megprobalom strace-elni vagy nem tudom, hogy mi az ordogot csinalhat ... Meg amugy is fura, hogy a gcc ablakot nyitna :D
Title: Re: EP128emu
Post by: IstvanV on 2016.July.29. 17:44:08
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.
Title: Re: EP128emu
Post by: lgb on 2016.July.29. 18:02:13
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.

A Makefile hozzatetelem a szokas hatalma, scons-ot hiv amugy :) Viszont pl a make installer-re elvileg megcsinal mindent, az installer-t is. Igaz, hogy szerintem bele van drotozva a sajat eleresi utam a cuccra, szoval sok mindenre nem jo igy :D A MingW amugy az, amit meg te prezentaltal a 7z file-ban. Az scons az viszont nem, az, ami az Ubuntu 16.04-ben van. 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. Xep128-nal is igy csinalom. Persze attol meg fl/stb dolgokat ala kene pakolni ahhoz meg lusta voltam, kenyelmes volt a 7z-ed, ahogy van :)

Arra is gondoltam, hogy irok az egeszhez sajat Makefile-t inkabb scons helyett, mert ez utobbihoz kevesbe ertek. Na, de nem akarom en mindenaron megvaltani a vilagot persze ...

Masreszt, ha minden fix benne van (lasd commit log) akkor arra is gondoltam, hogy lassan lehetne egy verzioszamot novelni, mert igy eleg keverdesre adhat okot, hogy ez most melyik cuccos is konkretan ...
Title: Re: EP128emu
Post by: Zozosoft on 2016.July.29. 18:11:49
Szerintem is lehetne vegre 2.1 :-)
Title: Re: EP128emu
Post by: lgb on 2016.July.29. 18:27:14
Szerintem is lehetne vegre 2.1 :-)

Ja, hat annyi modositas nincs benne :-/  2.0.9.2 -re gondoltam volna :D Na majd IstvanV eldonti :D Vegulis 2.1 egyszerubben megjegyezheto :D
Title: Re: EP128emu
Post by: IstvanV on 2016.July.29. 18:35:43
Esetleg 2.0.10 ? 2.1-hez kellene valamilyen új feature is. :)

A Wine 1.9.15 verzióra frissítése után a fordítás elején megjelent néhány DISPLAY hibaüzenet, de úgy látszik, ezt csak a winecfg automatikus futása okozta, mert második fordításnál már nincsenek ilyen üzenetek, és lassabb sem lett. Talán az scons okozhatja a problémát ? Azonban nekem X nélkül sincs hiba az SConstruct kisebb módosítása (az 52. sor törlése) után.

Valamilyen más környezeti változó hiánya is okozhatja a hibaüzeneteket és a lassúságot, talán a Wine nem ismeri fel az scons alatti környezetben, hogy már telepítve van, és minden g++ parancsnál újra próbálja installálni és konfigurálni az emulált Windows rendszert ?
Title: Re: EP128emu
Post by: IstvanV on 2016.July.29. 19:49:44
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.

Ez működhetne, csak át kell írni az SConstruct-ban a 'wine C:/MinGW/bin/g++.exe' és hasonló parancsokat. Természetesen kellenek hozzá a különböző függőségek is (PortAudio stb.), de ezeket talán fel lehetne használni a .7z csomagból, bár abban meglehetősen elavult verziók találhatók. De az FLTK-t valószínűleg újra kell fordítani, mert a C++ ABI változhatott néhány év alatt. :)

Lehetne még próbálkozni Win64 emulátor verzió fordításával is, ez valamivel gyorsabb lenne.
Title: Re: EP128emu
Post by: Attus on 2016.July.29. 23:04:28
Végre a githubra raktátok!
:)
A sourceforge mintha amúgyis döglődne...

Manapság rengetegen nyergelnek át  a gittre, én nagyon örülök ennek, hogy végre nem kell majd összevadászni az ep128emu újabban alkotott javításait, módosításait, foltozgatásokkal (https://github.com/uhulinux/ub-3/tree/master/ep128emu/patches).
LGB! Gondolom, hogy a foltozgatásaim értelmesebbjeit már belevetted a gitt repódba. Bár biztosan van a foltjaimban, ami felesleges, vagy eldobandó, vagy disztró specifikus, már nem is tudom, mert elég régen vadásztam össze őket.
Ha Istvánnak kedve szottyanna, majd committolhat bele, mert gondolom, hogy LGB biztosan megengedi neki.

Ha lesz új verziószám, akkor innen fogom elkészíteni az UHU csomagjaimat.
Arch-Linux alá is lehet PKGBUILD-ot kreálni, ahhoz is értek valamicskét, habár én megútáltam mostanában ezeket a rolling tamakocsi disztrókat. Ha nem frissítgetem őket legalább havonta, akkor megdöglenek és frissíthetetlenné válnak fél év múltán.

Még lehet, hogy a végén pr -eket is fogok küldözgetni.
:twisted:
Title: Re: EP128emu
Post by: Attus on 2016.July.29. 23:19:14
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.
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.
Title: Re: EP128emu
Post by: lgb on 2016.July.29. 23:27:09
É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.

Nem tudom, nekem 1.3-as fltk-val megy ubuntu alatt sajat forditasbol (marmint linux ala build-elve) ... Bar nem jatszottam vele igazan, hogy debugger stb, nem latok feltuno gondot, max scons tenyleg irja, hogy "warning" forditas kozben a verzio miatt, de mas nem tunt fel ... Vagy van mas ismert problema ezzel?
Title: Re: EP128emu
Post by: IstvanV on 2016.July.30. 09:34:17
Az emulátor támogatja az FLTK 1.3-at, az itt (https://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713) található régi Windowsos fordító csomagban is már 1.3.2 verzió van. :) Az UHU-n valószínűleg más okozhatja a problémát.

Megpróbáltam lefordítani FLTK 1.3.3-al is, ami szintén működik néhány LIBS módosítás után, de ezekre nem lenne szükség fltk-config használatakor (azaz ha az FLTK telepítve lenne, és nem csak lefordítva és az emulátor forrásához másolva).
Title: Re: EP128emu
Post by: Attus on 2016.July.30. 16:01:45
A csomagészítés UHU alatt szeparált chroot környezetben megy, melybe a fordító rendszer feltelepít minden a fordításhoz felétlen szükséges csomagot és persze azok ffüggőségeit is, hogy működjenek a chroot alatt. Az fltk-dev csomagunk tartalmazza többek közt a /usr/bin/fltk-config fájlt is az fltk fejlécei, ha előírom, hogy a chrootba legyen benne az fltk-dev csomag, akkor az is feltelepül a fordításhoz, valamint a dev csomag felhúzza oda az fltk alapcsomagot is.

Megpróbálom újra, hisz elég régen volt a próbálkozásom.
Ha ubi alatt megy, itt is menni fog.
Title: Re: EP128emu
Post by: Attus on 2016.July.31. 22:25:33
Valami gáz lehet az fltk csomagunkkal, mert az fltk-1.3.2, vagy az fltk-1.3.3 csomagunk használatával is szinte azonnal leáll a fordítás.
:(
compile...
+ scons
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
Error: HIBA a(z) compile fazisban.


 Az fltk csomagok ezekkel a fordítási opciókkal készültek:
 --enable-threads \
 --enable-xft \
 --enable-shared \
 --enable-cairo \
 --enable-gl

Az fltk1 meg ezzel:

 --enable-threads \
 --enable-xinerama \
 --enable-xft \
 --enable-xdbe \
 --enable-largefile \
 --enable-localpng

Minden fltk verziónál fel vannak telepítve a jpeg, png, zlib cuccok, az fltk1 -el megleli, az fltk csomagokkal meg nem.

A sconstruct fájlban az fltk1 esetén az fltkconfig = 'fltk1-config, mert az van a /usr/bin alatt, a többi esetben persze marad az fltk-config.
Azért lett átnevezve, hogy ne legyen fájlütközés az fltk1 és fltk csomagok közt. Az fltk1 -nél külön fltk1 mappába lettek telepítve a libek és fejlécek, szintén a fájlütközéseket elkerülendő. Érdekes, hogy a nem szabványos elhelyezésűnél semmi gond nincs, és a nem megerőszakolt magasabb verziójúaknál meg nem akarja az igazságot az ep128emu, míg más fltk-t használó programoklhoz meg jó az fltk csomag.

Szóval lesz itt gondom, kár, hogy a pythonhoz (scons) tök vagyok a C-hez hasonlóan, csak a Z80 assembler megyeget, meg a bash.

Átnéztem az fltk csomagunk fájljait, szinte tök azonos az ARCH-Linuxéval, a helyei is azonosak.
https://www.archlinux.org/packages/extra/i686/fltk/

Szóval egyelőre nem értem a helyzetet.
:cry:
Title: Re: EP128emu
Post by: IstvanV on 2016.July.31. 22:38:40
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

A config.log file talán segítene a hiba okát megtalálni, ezekből az üzenetekből csak az derül ki, hogy az imageLibTest() függvénynél van a hiba. De lehetne próbálkozni az imageLibTest() hívásainak a törlésével is.
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 08:10:20
Köszönöm István, belekukkantottam a logba, segített is!
:)
Ez volt a logban:

/usr/bin/ld: cannot find -lXft
/usr/bin/ld: cannot find -lfontconfig
/usr/bin/ld: cannot find -lXinerama
collect2: error: ld returned 1 exit status

Megadtam neki a chrootba telepítendő csomagok listájába a hiányoltakat (fontconfig-dev, libxft-dev, libxinerama-dev), és most már gond nélkül lefordult és elkészült a csomag a leendő disztrónkoz. fltk-1.3.3. Egyébként Itt vannak (http://ftp://ftp.ubk.hu/) az általunk (általam is) ápolt tárolóink, most a dev tárolóhoz csináltam meg épp, mely ugyi még csak virtuális, gyakorlatban nem kipróbálható,  de megcsinálom már a létező UHU-3 alá is, majd beszámolok.
Ha jó, akkor száműzhetők az fltk1 csomagok az UHU változatokból.
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?


De jól félrevezetett az előző hibaüzenet.
Miért is nem a logban levőket közölte?

:roll:
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 08:40:19
És működik az ep128emu csomagom az fltk-1.3.2 -vel.
:)

http://ubk.hu/forum/showthread.php?tid=8&pid=3212#pid3212
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 09:07:07
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?

Hat, hacsak IstvanV nem akar SF-en barkacsolni, az gondolom marad olyan, mint eddig. Github-on meg kene nezni, hogy most minden benne van-e kb, amit eddig szeretett volna a "nep". Aztan elnevezni Istvan utmutatasi :) alapjan 2.0.10-nek. Onnantol kezdve lehet ra csinalni pl egy release tag-et, es azt lekerni, mint "stable" verzio, ha esetleg ahhoz kepest lenne valtozas benne, akkor is az marad az, mint "stable".
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 09:35:21
Egyelőre forkoltalak (rettenetes szókreálmány), hogy meglegyen legalább újabb példányban.
Title: Re: EP128emu
Post by: Zozosoft on 2016.August.01. 10:03:25
Esetleg 2.0.10 ? 2.1-hez kellene valamilyen új feature is. :)
Új feature mehet 2.2-be :-)
2.1 az olyan szépen rímelne a gyári EXOS és BASIC verziókra :ds_icon_cheesygrin:
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 10:14:00
Sorolom is rögtön, a szembeszökő hiányokról az észrevételeimet.

Semmi linux installálási rész nincs most még a forrástömegben. Ez bizony hiányosság egy új release előtt és szerintem pótolandó.
Jó, hogy a scons -al fordít, ezt értem, hisz windózra is könnyű vele.

Én a sima configure/make párosokhoz vagyok szokva (meg újabban a cmake és qmake cuccokhoz), csak 6 csomagunk van, ami scons -t használ a fordításhoz az eddig mindegy 4500 UHU csomagból.

Én is "kézzel-lábbal" vagyok kénytelen installálni az ep128emu cuccait a fordítás után, nem a make install -al. Az installáló szkript most ilyen: Az (UB_INSTALLDIR a chroot installálási célmappája)

Code: [Select]
#!/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"

Továbbá a programindító desktop fájlokat is magam készítettem az egyes funkciókhóz, melyeket a csomaghoz a fordítás után és az összerámolás előtt külön csatolok, hogy a menüből akár a cpc, akár a spectrum rész is indítható legyen.
https://github.com/uhulinux/ub-3/tree/master/ep128emu/addons/usr/share/applications.
Ha ezek is benne lennének a forrásban, akkor onnan lehetne lekapni őket és belerámolni a csomagba. És nem csak UHU csomagba, hanem akár UBUNTU deb csomagba is!
Ezek valamennyien hiányoznak, és szerintem bármely linux disztrónál hasznosíthatók lehetnének.


A rettenes windózos ico fájlokat is átkonvertáltam a linuxban szokott png formátumra és szintén utólag csapom bele a csomagba őket, hogy ikonosak legyen a menüpontjaim bármely DE alatt.
https://github.com/uhulinux/ub-3/tree/master/ep128emu/addons/usr/share/pixmaps

Ezt persze installálásnál is megtehetném az imagemagick convert parancsát használva, de nem lenne egyszerűbb, ha ezek is elérhetők lennének a forrásból?

Az már a non plus ultra ketegória lenne, ha ezeket a forrásba majd belekerülő linuxos installáló tenné meg helyettem, melynek a DESTDIR változóval megadhatnák egy tetszőleges célterületet.

Egyelőre nnyi.

Ja, a d718984 committal leszedett githubos forrás is szépen lefordul nálam.
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 10:50:47
LGB!
Kaptál egy PR-t!
;-)
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 11:08:59
LGB!
Kaptál egy PR-t!
;-)

Nocsak, egy pull request-re gondolsz? PR alapjan legalabbis feltetelezem, hogy ennek a roviditese. Olyat sem kaptam meg soha :D

UPDATE: comment-altam a pull request-et. Ugysem hasznaltam meg ilyen funkciot github-on, eddig legalabbis :-P
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 14:54:57
Csináltam egy issues -t is, hogy legyen min elmélkedni!
https://github.com/lgblgblgb/ep128emu/issues/3
:razz:

Továbbá valaha csináltam a lemezkezeléshez egy kis segítséget linux alá magyar nyelven, melyet a csomagjainkoz csatoltam.
Talán ezt is be lehetne emelni az ep128emu github forrásába, hogy veszendőbe ne menjen, vagy másutt is használható legyen.
De gőzöm sincs, hogy hol lehetne a célszerű helye a forrástömegben.
https://raw.githubusercontent.com/uhulinux/ub-3/master/ep128emu/addons/usr/share/doc/Packages/ep128emu/lemezek.hlp
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 17:50:32
Hat. Oszinten, ertem en, hogy jo az SConstruct. Meg latom, hogy python, meg stb, en eleg sokat Python-oztam. De valahogy megis ugy erzem, hogy egy tisztan Makefile-os dologra gyorsabb lenn lecserelni :D Mert hat lusta vagyok megtanulni megint egy uj dolgot :) Aztan szoba kerult meg a Cmake, hat meg egy uj dolog ... Jelenleg is beleganyoltam ugye egy Makefile-t ami csak "hivja" az scons-t kb. Kerdes, hogy abba keruljon-e bele install akarmi, vagy inkabb legyen tisztan nullarol sima Makefile. *Szamomra* ez utobi azert celravezetobb, mert lehetne normalis cross compile win-re, mindenfele wine es egyeb trukk nelkul. Bar ez scons-al is lehetne persze, sot abba lehetne akar install is, mint mondtam, ebben nincs tapasztalatom. Ettol persze, ha valaki megcsinalja, legyen, vegulis nem az en project-em, nem akarom en "kisajatitani" vagy barmi, mielott barki rosszra gondolna :)
Title: Re: EP128emu
Post by: IstvanV on 2016.August.01. 17:56:49
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.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.01. 18:03:45
*Szamomra* ez utobi azert celravezetobb, mert lehetne normalis cross compile win-re, mindenfele wine es egyeb trukk nelkul.

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

Code: [Select]
    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'
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 18:35:49
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):

Igen, ez tiszta, csak az elmelet es a gyakorlat elmeletben ugyanaz, de gyakorlatban nem, attol felek mar elore :D

Amugy az se total tiszta pl, hogy lehet normalisan atadni parametereket az SConstruct-nak. Amit en kitalaltam azt lathatod, pl ezt:

Code: [Select]
win32CrossCompile = ARGUMENTS.get('win32', 0)
Ez azert kellett, hogy scons paranccsorral lehesen valtoztatni, hogy most mire build-elunk. Persze lehet, hogy van erre szebb megoldas is :) A masik dolog ami jo lenne, de nem tudom hogy megy SConstruct-tal:

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. Xep128-ban igy van, hogy arch fuggo object file-ok vannak, igy barmikor ossze-vissza lehet valtogatni es nem kell mindent ujrabuildelni. Igaz, ott magamtol oldottam meg Makefile-bol (de ez igaz a dependency-re is). Gondolom, ez alapvetoen SConstruct-ban kb meg egyszerubb is lehetne, mivel Makefile-ban ehhez azert trukkozni kell idonkent, a dependency filter awk dolgomrol nem is szolva :-P
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 18:38:10
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.

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.
De mint említém, én a scons -hoz tök vagyok, és szerencsémre eddig csak ritkán fordult elő, hohg python szkriptet kelljen módosítanom, hisz ahhoz sem értek.
Szerintem egyszerűbb lenne, ha István ezt megejtené a linuxosok kedvéért.

A bombono-dvd csomagunkban ennyi az egész install szkriptünk:
scons DESTDIR=${UB_INSTALLDIR}  install

A dangeerdeep csomagunkban:
scons installbindir=$UB_INSTALLDIR/usr/bin datadir='/usr/share/games/dangerdeep' install

Amit még egy csomó kézzel-lábbal elkövetett cp követ

A gpsd csomagunkban van még:

export DESTDIR="$UB_INSTALLDIR"
scons install

Más csomagunkban nincs scons installálás.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.01. 19:30:35
Igen, ez tiszta, csak az elmelet es a gyakorlat elmeletben ugyanaz, de gyakorlatban nem, attol felek mar elore

A legegyszerűbb lenne kipróbálni, ha nem működik, akkor egyelőre marad a Wine. :)

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

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.
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 19:36:36
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? Mert ugye mas az egesz kornyezet. Na jo, majd kiprobalom :D
Title: Re: EP128emu
Post by: IstvanV on 2016.August.01. 19:48:53
Oke, de ettol fuggetlenul az scons nem fogja elolrol kezdeni?

Csak a konfigurálást, az .o file-okat nem fordítja újra scons -c nélkül.

Egy másik lehetőség a CacheDir használata, például CacheDir("./build_cache") valahol az SConstruct elején. Ez minden a fordítás során generált file-t tárol a megadott könyvtárban (md5sum alapján), majd ha később azonos feltételek mellett ugyanazt a file-t kellene fordítani, akkor egyszerűen onnan másolja.

A CacheDir tartalma scons -c után sem veszik el.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.01. 20:11:52
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?

Környezeti változó lekérdezésére már van példa a fenti néhány sorban, ahol az instDir $HOME/bin (instDir = os.environ["HOME"] + "/bin").

Quote
Azt is fel kellne sorolni valahol, hogy milyen fájlokat és hova telepítsen az insDirbe, ahhoz relatívan persze.

A példában ez az [ep128emu, makecfg, tapeedit] tömb. Idézőjelekben file nevek is megadhatók forrásként, ha ezeket nem az SConstruct generálja (pl. ikonok).

Több instDir is lehetséges, ilyenkor ezeket az Alias-nál tömbként kell megadni (pl. Alias("install", [instDir, instDir2])).
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 20:37:41
Nekem semmi kedvem belerondítani a szépen megírt Sconstruct fájlba, biztosan elrontanám.
Eddig is meg tudtam csinálni az installállást is bash szkripttel, csak szebb és elegánsabb lenne, ha erre redukálható lemme:

export DESTDIR=${UB_INSTALLDIR}
scons   install

És ezzel egycsapásra minden cucc, ikonokkal, desktopokkal, binárisokkal, adatokkal együtt a helyére röppenne.
Title: Re: EP128emu
Post by: Attus on 2016.August.01. 22:22:01
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.

Ez az install rész megcsinálná a kívánt könyvtárakat és odaröppentené a kívánt fájlokat.

Utána ezzel lehetne hívni minden disztrónál:

make DESTDIR="akármilyenhely" install
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 22:35:02
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.

Meg tudnam :) scons barmilyen jo, valahogy nem all a kezemre, de nyilvan szokas kerdese, meg hat nem is ertek hozza, lassuk be. Hiaba python, meg hiaba ilyenre vagytam mindig, hogy ne kelljen Makefile-ba script-eket eroszakolni neha :D meg hasonlok.

Valahogy kisse tulbonyolitott a dolog. Pl ez masik vesszoparipam, az arch. fuggo object file-ok. Probraltam a cache-dir-t de nem az igazi. -c -re nem torlodik, ugyanugy ganyolhatok kore script-et. Mert "make clean" hasonlo esetben viszont torolje ... Szerintem igy logikus. Raadasul egy csomo zavaro es fura uzenet jon, hogy visszaszedi cache-bol ... Es a cache-ben nem is normal file-kent van tarolva, nem tudok csak ugy belenezni, object file-t objdump-olni stb ... Szoval ez valahogy nem jon be. Marad az object file pre/postfix, de ott meg mindig nem tul szep, hogy az elejen a config-ot akkor is ujra csinalja, es nem tudja per arch letarolni. Szoval barhogy is nezem, nekem ez tul darabos. Pedig gondolom, hogy az en hozzaallasommal van baj, es lehet az nem termeszetes, amit en akarok :D

Lehet siman tul oreg vagyok en mar az ilyen ujhullamos tool-okhoz :D 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 :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.August.01. 22:49:08
Én meg csak a kötőszavakat értem abból amit beszéltek :oops:
Title: Re: EP128emu
Post by: lgb on 2016.August.01. 23:03:55
Én meg csak a kötőszavakat értem abból amit beszéltek :oops:

:)

A C++ -os "szokasos kiborulasom" stilszeruen Enterprise-os (igaz, az urhajo) peldaval:

Scotty: The Enterprise. Show me the bridge of the Enterprise, you chatterin' piece of...
Computer Voice: There have been five Federation ships with that name. Please specify by registry number.
Scotty: N-C-C-1-7-0-1. No bloody A - B - C - or D!

:) En is igy vagyok vele. Sima, mezei, eredeti C, semmi ++ moge :) Bar a peldat nemikepp zavarja, hogy a fenti idezetben pont a C nem kell neki :D tobbek kozott ...
Title: Re: EP128emu
Post by: ergoGnomik on 2016.August.02. 08:10:11
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

Azért jó túlbonyolítani, mert utoljára akkor van a program az ellenőrzésed alatt, amikor elindítod a buildelést. A C++ filozófiájának egy része, hogy a programot úgy írd meg, hogy elkerülöd a típuskényszerítéseket. Ha ilyen van a programban, akkor ott valamilyen elvi hiba húzódik meg vagy a program szerkezetében, vagy az adatstruktúrák absztrakciójában. A C++ erősebben típusos nyelv, mint a C. És persze hordozza az összes eszközt is amivel pusztító erővel lehet ágyékon rúgni az erős típusosságot, de ez más tészta.

Persze itt gondolom megjegyzed, hogy neked ne ugasson bele a nyelv, mert te úgyis jobban tudod, csak ez körülményektől függően elég sokszor nem így van. Azután meg ott van az is, hogy senki sem nélkülözhetetlen, vagy legalább is az alkalmazók – érthető módon – baromira nem szeretik a helyettesíthetetlenséget. Ha nincsenek garanciák arra, hogy a következő jézuska képes lesz hatékonyan folytatni az eltávozott munkaerő feladatait, akkor az jelentős veszteséget is okozhat, amitől a tulajdonosok és/vagy befektetők nagyon nem szoktak boldogok lenni. Ennek – mármint a hatékony fejlesztő csere lehetősége megvalósításának – egy része lehet a fenti alapelv.

Igen, minden magára valamit is adó cégnél létezik specifikáció, ami meghatározza hogyan kell programozni, de nem jobb ha ennek egy részét maga az alkalmazott programozási nyelv követeli meg/kényszeríti ki? Egyszerűbb lehet a kézikönyv, így nagyobb valószínűséggel fogja az alkalmazott a lefektetett irányelveket követni. Sőt, rendes helyeken van folyamatosan frissített projekt specifikáció is, de ugye azt is csak egy fejű, két kezű emberek csinálják. Nem sokkal hatékonyabb a munka, ha valamilyen változtatást nem sikerült rendesen végiggörgetni a teljes specifikáción, akkor egy belső teszt fordításnál ez rögtön kiugrik, nem kell nekihajtani a szoftvert a tényleges futtatási teszteknek?

ON
Title: Re: EP128emu
Post by: Attus on 2016.August.02. 08:23:38

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.
Magát a fordítást elvégzeztethető István jól megírt, habár öreg agyamat elborzasztó ( mivel nem értek hozzá) Sconsscriptje, az installálási fázist meg LGB leendő ragyogóan megírt Makefile install része.

Vagy esetleg CmakeFiles.txt ? :idea:

Én arra hajlanék, hogy a cmake-val lenne jó elvégeztetni minden Makefile generáltatást, ehhez csak jól megírt CmakeFiles.txt kellne, melyhez sajnos szintén nem értek, csak tudom, hogy az a menő manapság, főleg a keresztfordításokhoz, mindenféle operációs rendszerhez.
Title: Re: EP128emu
Post by: lgb on 2016.August.02. 08:59:24
Nem hiszem, hogy egy Makefile install rész-nek sok köze lenne a C++-hoz.

Nincs is. Csak a szokasos hulyesegem, hogy elkalandoztam :)
Title: Re: EP128emu
Post by: Attus on 2016.August.02. 09:39:45
Ja, közben a romhalmazt elhelyeztem a gitt forkomba, talán a megfelő helyre és küldem Pull request -et a fő gittbe.
Ez is nélkülözhetetlen a működéshez. Mármint a romhalmaz, amik remélem, hogy már nem jogvédettek.
Title: Re: EP128emu
Post by: lgb on 2016.August.02. 12:40:36
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.

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&
   ^
Title: Re: EP128emu
Post by: ergoGnomik on 2016.August.02. 13:09:01
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&
   ^
Megné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?
Title: Re: EP128emu
Post by: IstvanV on 2016.August.02. 13:29:56
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&
   ^

Ez egy egyszerűen javítható hiba, a Compressor_M0::CompressionParameters::CompressionParameters& helyett Compressor_M0::CompressionParameters& kell. Ha máshol is előfordul ez a hiba, akkor ugyanígy javítható. Meglepő, hogy a GCC régi verziói ezt elfogadták. :oops: Egyébként az epcompress forráskódja is tartalmaz(t)a ezt a hibát.

Ha már epcompress, akkor a teljesség kedvéért még ez és az egyéb segédprogramok (epimgconv, dtf, stb.) is a GitHub-ra kerülhetnének, talán egy "ep-utils" vagy hasonló csomag részeként. :)
Title: Re: EP128emu
Post by: Attus on 2016.August.02. 14:20:29
Ja, közben a romhalmazt elhelyeztem a gitt forkomba, talán a megfelő helyre és küldem Pull request -et a fő gittbe.
Ez is nélkülözhetetlen a működéshez. Mármint a romhalmaz, amik remélem, hogy már nem jogvédettek.
A békesség és jogviták elkerülése végett inkább visszacsináltam.
Majd a júzer fogja magának letöltögetni őket, vagy egy, a githubba rakott wrapper segítségével, vagy anélkül a kívánatos helyre, ha használni is akarja az emulátort .
Í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.
Title: Re: EP128emu
Post by: szipucsu on 2016.August.03. 17:37:15
Í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
Title: Re: EP128emu
Post by: ergoGnomik on 2016.August.03. 18:11:44
Í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.
Title: Re: EP128emu
Post by: Attus on 2016.August.03. 22:43:25
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ó.
Ezt azért legalább nekünk illene tudni, hogy áll most, 2016-ban az EXOS ROM jogi védettség terén.
A cég megszűnt, de ki a cég jogutódja és mikhez ragaszkodik az EXOS -al kapcsolatban?
Szabad az eredeti EPROMBA égetettet használni a gép megvásárása nélkül? Vagy a bináris halmazt fájl formában?
Másolható? Terjeszthetők a másolatok? Módosítható?

A visszafejtése megtörtént és nyilvánosságot is kapott, mint tudjuk, nyomtatott formájában is elérhető, nekem is magvan, hisz megvettem.
Title: Re: EP128emu
Post by: szipucsu on 2016.August.03. 23:14:36
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.
Title: Re: EP128emu
Post by: ergoGnomik on 2016.August.04. 07:02:24
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.
Title: Re: EP128emu
Post by: lgb on 2016.August.04. 08:06:24
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.

Na igen. Ha tovabbfejesztes, akkor elvileg az eredetinek is a tiednek kell lenni, hacsak nem olyan a licenc ami engedi ezt. Amugy sok emulatornal eleve egyaltalan nem adnak ROM-ot, vagy kulon csomagolva (kb a usert "kenyszeritve" ezzel, hogy szerezze be maganak, ha kell") ... mas emulatoroknal meg irnak nullarol (!) valami helyettesito rom-ot, ami eleg alap dolgora stb, de hozzateszik, hogy szerezd be magadnak, ha kell az "igazi" mert azzal fog menni csak a legtobb dolog. Amiga emulatoroknal kulonosen erdekes, ahol ugye azert eleg aktiv bizniszt keritenek moge most is ... Ott aztan kickstart ROM-ot nem is olyan egyszeru szerezni, elvileg azt mondjak, hogy legyen egy valodi Amiga-t, aztan dump-old ki, vagy vedd meg az Amiga forever CD-t penzert, amin rajta van (es a jelenlegi jogtulajdonos persze hozzajarult igy). 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 :)
Title: Re: EP128emu
Post by: Attus on 2016.August.04. 09:58:37
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.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.04. 11:01:10
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:
[attachurl=1]
Title: Re: EP128emu
Post by: lgb on 2016.August.04. 12:00:08
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)

Thx, beletettem ... Amugy ugyanaz a gond mint ep128emu-val, GL hianya miatt:

Code: [Select]
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 ...
Title: Re: EP128emu
Post by: IstvanV on 2016.August.04. 12:56:02
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).
Title: Re: EP128emu
Post by: lgb on 2016.August.04. 13:12:58
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).

Oke, koszi!

Nincs benne a -lGL

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

Viszont, ilyet ir:

Code: [Select]
lgb@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 lib

stb ... Es ha odateszem az --use-gl opciot is, akkor az --ldstaticflags -nal odarakja mar a GL-t. Erdekes modon amugy ugy se, es latom az SConstruct-ban is hasznalva van pedig az --use-gl is. Szoval akkor nem ertem ...

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

Hulyeseget nagyot nem akarok irni, de nekem ugy remlik, hogy ez a DSO izebize ez nem egyertelmuen az, hogy hianyzik, hiszen az uzenetben is szerepel:

Code: [Select]
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line
tehat mar a GL-el csinal valamit eleve ... Meg irnak pl ilyesmiket (bar nem pont ide illik):

http://stackoverflow.com/questions/19901934/strange-linking-error-dso-missing-from-command-line

Hogy szamit a sorrend, stb is. Mondjuk, oszinten szolva, nekem csak remlik, hogy egyszer ebbe en is belefutottam sajat project-nel, sajnos mar nem remlik az mar viszont, hogy konkretan mi volt a megoldas, de ott is valami atrendezese a dolognak, es sorrendi kerdes ...
Title: Re: EP128emu
Post by: Attus on 2016.August.04. 13:29:00
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$

Kipróbáltam a linux installert.
Nincs ikonja a cpc64emu menüpontnak.
A cpc64emu.desktop fájljába becsúszott egy hiba, vagy a png fájl neve lett más.
Icon=cpc464em a helyes, ha cpc64em.png van a resources mappában.
PR.
Title: Re: EP128emu
Post by: lgb on 2016.August.04. 18:06:39
Az ubival való összevetésképp felraktam az fltk-dev csomit, ami amúgy nem kell az ep128emu működéshez...

Nyilvan, de a forditasahoz igen, nem?

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

Hmmm. Nalam ugyanez (Ubuntu 16.04 64 bit):

Quote
lgb@vega:~$ fltk-config --use-gl --ldflags
-Wl,-Bsymbolic-functions -lfltk_gl -lfltk -lX11
lgb@vega:~$ fltk-config --version
1.3.3

Erdekes modon, ez viszont ertelmesebbnek tunik (csak hat ez static linkinghez valo, ugye - elevileg):

Code: [Select]
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
Title: Re: EP128emu
Post by: Attus on 2016.August.04. 21:09:52
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.
Title: Re: EP128emu
Post by: lgb on 2016.August.04. 21:11:50
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.

Igen, de pont ez az ami igy nem teljesul ugye, legalabbis nekem igy nem fordul :D
Title: Re: EP128emu
Post by: IstvanV on 2016.August.05. 19:44:08
A legegyszerűbb lenne a LIBS-hez hozzáadni a "GL"-t, nekem ugyan működik ilyen módosítás nélkül is, de az fltk-config kimenetének egyébként is tartalmaznia kellene.
Title: Re: EP128emu
Post by: Attus on 2016.August.06. 14:59:17
Nekem lefordult az UHU 3 alá, csak nincs installálója ennek sem.

Ezek a fordítási csomag függőségei nálam:

dotconf-dev
fltk-dev
fontconfig-dev
glu-dev
jack-dev
libjpeg-dev
libsndfile-dev
libxft-dev
libxinerama-dev
lua-dev
portaudio-dev
scons
sdl-dev

Ez viszont érekes:

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

Ez biztosan legalább 10 éves, szerintem nincs is olyan disztró manapság, mely 1.2.9 -et használhatna az sdl1 sorozatból.

UHU ubk1 -- sdl_1.2.15 (2016)
UHU 3 -- sdl_1.2.15 (2014)
UHU 2.2  -- sdl_1.2.14 (2010)
UHU 2.1 -- sdl_1.2.10 (2008)
UHU 2.0 -- sdl_1.2.10 (2006)
UHU 1.2 -- sdl_1.2.7 (2005)
Title: Re: EP128emu
Post by: IstvanV on 2016.August.06. 15:43:49
Az 1.2.15 nekem működik, ez valószínűleg csak átmeneti probléma volt az 1.2.10 verzióval.
Title: Re: EP128emu
Post by: Attus on 2016.August.06. 16:11:16
Megcsináltam a plus4emu csomagomat is, kipróbáltam, működik.
A windóz installálást nem értem igazán. Mindent a leírás alapján kopíroz a csomagkészítőm a megfelelő helyekre, és nem a júzer. Ő majd a csomagtelepítőjével csinálja majd meg, UHU esetén jelesül az apt -al.
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?
Továbbá csináltam egy wrappert, ami megnézi, hogy van e ~/.plus4emu könyvtár, ha nincs csinál egyet és belerámolja a romokat és lefuttatja a plus4emumkconfig-ra átnevezett makeconfig cuccost.
Azért, hogy ez ne ütközzön az ep128emu makecfg fájljával.
Ehhez is elkélne egy linux installáló Makefile.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.06. 18:31:20
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?

Különböző ikonok vannak az egyes ablakok számára, a Cbm4.ico az "alapértelmezett" ikon:

1551.ico: floppy konfiguráció
Plus4i.ico: billentyűzet konfiguráció
Plus4Mon4.ico: video konfiguráció
CbmFile.ico: a társított típusokhoz a Windows file kezelőjében

Az alábbi patch a következő kisebb módosításokat tartalmazza:
- verzió frissítése (1.2.9.2 -> 1.2.9.3 beta)
- az SConstruct-ban a régi MinGW csomag használata (gcc-sjlj.exe stb.) javítva
- a plus4emuGLGUIEnvironment["LIBS"]-hez hozzáadja a "GL"-t, ha az fltk-config ezt nem tette meg
- a comctl32.dll hiánya hibát okozott újabb FLTK verzióval
- a README-ben az ajánlott SDL verzió javítva

[attachurl=1]
Title: Re: EP128emu
Post by: lgb on 2016.August.06. 19:42:31
Az alábbi patch a következő kisebb módosításokat tartalmazza ...

https://github.com/lgblgblgb/plus4emu

Beletoltam mar az elozo patch-edet is, meg ezt is.

Ja, es igen, koszi, most igy nekem is lefordul mar :-P
Title: Re: EP128emu
Post by: Attus on 2016.August.06. 21:26:14
Különböző ikonok vannak az egyes ablakok számára, a Cbm4.ico az "alapértelmezett" ikon
Jó 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?
Nem értem, hogy milyen ablakok számára készültek.
Az egyes felbukkanó ablakoknak? És a linux esetén is hogyan érvényesülhetnek, hol jelennek/jelenhetnek meg?
A menünek a Cbm4.ico -t átkonvertáltam az imagemagick convert parancsával plus4emu.png -ra, amit beleveszek a programindító plus4emu.desktop fájljába, tehát ez rendben lenne, így gányoltan.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.06. 21:52:36
Linux installáláskor hova kerüljenek, ha kell őket egyáltalán rakni valahova?

Ezeket nem kell installálni, a .desktop file céljára elég csak a Cbm4.ico PNG formátumra konvertálva.

A Windows verzióban az összes .ico file beépül a programba a fordításkor. Az FLTK 1.3.2 és régebbi verzióiban nem lehet az ablakokhoz hordozható módon ikont rendelni, az ikonok jelenleg csak Windowson láthatók. 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.
Title: Re: EP128emu
Post by: Attus on 2016.August.06. 22:23:36
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)
;-)
Amúgy biztosan meg tudnád csinálni, egy feltéltel rendszerrel, hogy ez az ikonbeépítés csak FLTK 1.3.3 észlelése esetén történjék, korábbiaknál meg ne.

Köszi a választ!
Title: Re: EP128emu
Post by: Attus on 2016.August.07. 09:24:52
A plus4emu csomagom installálási része. a scons fordítás után.

Ebben az összes ico fájl átkonvertálása egyelőre feleslegesnek tűnik, de hát miért ne?

Code: [Select]
#!/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"/

A debian csomaggá összerámolás előtt még ezeket a saját gyártású fájlokat adom hozzá addonsból.
Egy wrapper az emu indításhoz, mely a júzer $HOME könyvtárába rakja a romokat és lefuttattja a plus4emumakecfg névre átkeresztelt makecfg ELF binárist, ha még ez nem történt volna meg.

Code: [Select]
#!/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

Egy programindító desktop fájl a /usr/share/applications mappába plus4emu.desktop néven a menü részére.

Code: [Select]
[Desktop Entry]
Type=Application
Name=plus4emu
Comment=CBM+4 emulator
Comment[hu]=Commodore+4 emulátor
Exec=plus4emu
Icon=Cbm4
Categories=Game;Emulator;

Ezekkel már szépen indul az emu menüből.

Nem tudom kell még valami?

Esetleg egy Makefile ennek az emunak a forrásába is elkélne az installáláshoz.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.07. 14:37:50
[attachurl=1]

- verzió frissítése (2.0.9.2 beta)
- a Windows installerben a forrás file-ok listájához hozzáadtam a resource/ alatti új file-okat
- a README-ben az ajánlott SDL verzió javítva
- FLTK 1.3.3 és újabb verzió esetén nem csak Windowson jelenik meg az emulátor ablak ikonja

[attachurl=2]
[attachurl=3]    (resource/Cbm4.png, a Cbm4.ico konvertálva)

- a makecfg, tapconv, és compress programok átnevezve (p4makecfg stb.) nem Windows rendszereken
- Linux .desktop és ikon file
- scons install funkció Linuxon, valószínűleg még fejleszteni kell rajta (jelenleg a HOME alatt installál mindent, ez az SConstruct szerkesztésével módosítható) :oops:
- FLTK 1.3.x támogatása az SConstruct-ban
- FLTK 1.3.3 és újabb verzió esetén nem csak Windowson jelennek meg az emulátor ablakok ikonjai

Csak nekem van olyan probléma, hogy a floppy LED-ek mellett a "Disk: " helyére néha szemét kerül ? Lehet, hogy ez csak driver hiba, de emulátor bug is lehet. :oops:
Title: Re: EP128emu
Post by: Attus on 2016.August.07. 22:23:48
Csináltam fltk-1.3.3 -at a próba kedvéért, ezzel legyártattam az ep128emu csomagot  lgb gittjéből és István újabb foltját alkalmazva.
Feltelepítettem, természetesen a synaptic telepítő felfrissítette az fltk-1.3.2 -t is.
Elindítottam a régi ~/.ep128emu dolgaival, elindult, a fő ep ablakban már volt felül baloldalt EP ikonka. A keyboard-map ablaknak nincs ikonja, a disk-confignak viszont van.
Kiléptem az emulátorból, átneveztem a ~/.ep128emu mappámat és elindítattam a makecfg-ep128emu wrappert, letöltötte a romokat, majd villant egyet és kilépett.
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.
Az fltk-1.3.3 épp úgy készült mint egykoron az fltk-1.3.2.
Erre újra csináltam egy csomagot, most az fltk-1.3.2 -vel, visszafejlesztettem a feltelepített rendszeren z fltk-t és felraktam az újra elkészült csomagot.

Ekkor a makecfg-ep128emu.bin már nem szállt el, szépen konfiguráltam.
Az emulátor fő ablakjának keretében most nincs EP ikon.

Lehet kotorászni, hogy miért száll el és csak a makecfg az fltk-1.3.3 -al?
Title: Re: EP128emu
Post by: IstvanV on 2016.August.07. 23:02:35
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.

Az 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.
Title: Re: EP128emu
Post by: lgb on 2016.August.08. 00:43:48
No, nekem az lenne a kerdesem, hogy mikepp lesz Linuxos ep128emu Lua-val :) mert nekem sehogy ... Mindig azt irja ki, scons hogy nem talal lua-t, pedig mar tobbfele lua dev csomag fel van pakolva :) Ugye SConstruct-hoz nem ertek, de azt latom, hogy lua.h -t akarja include-olni, csak ugye az nem fog menni, mert /usr/include/lua53/ alatt lenne pl, nem csak sima /usr/include/ amit amugy megtalal. Amugy igy is jo:

Code: [Select]
lgb@vega:~$ pkg-config --cflags lua53
-I/usr/include/lua5.3
lgb@vega:~$ pkg-config --cflags lua52
-I/usr/include/lua5.2

Sot, meg ilyenem is van:

Code: [Select]
lgb@vega:~$ lua-config --include
-I/usr/include/lua50

Csak akkor meg hasznalnia kene az SConstruct-nak a pkg-config-ot, hogy megkerdezze, milyen cflags kell. Stb. config.log-ban is azt latom, hogy az scons megprobalja tesztkent include-olni a "lua.hu"-t, de ugye nem ad meg -I kapcsolot normalisan, hogy tudja szegeny gcc, honnan vegye ...
Title: Re: EP128emu
Post by: IstvanV on 2016.August.08. 06:48:29
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.
Title: Re: EP128emu
Post by: Attus on 2016.August.08. 07:23:49
Az 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.

Köszi.

Már keztem ideg lenni, hogy az fltk-1.3.3 csomagomat nem jól csináltam, ezen a téren megnyugtattál. UHU-3 alá nem frissítem fel addig az fltk -t, míg ez a a probléma meg nem oldódik, marad a régi ep128emu csomag ott.
A leendő UHU ubk1 RIA alatt sem lesz jó, mert ott is töröltem az fltk1 csomagot, ott csak flk-1.3.3 van már azzal készült el minden csomag és semmi kedvem azt visszafejleszteni, mert akkor ezeket a csomagokat újra kellene építenem majd az fltk régebbi verzióval:
dillo, edelib, ede, jwm-settings-manager, lmms, mathgl, teapot, tigervnc, ep128emu
Tervbe vettem a leendő UHU kiadásunk csomagkészletünk bővítését a plus4emu -val is, ez utóbbit a most életképes UHU-3 alá már bele is nyomtam pár napja. (ftp://ftp.ubk.hu/pkg/3/main/plus4emu_1.2.9.2-1.1_i386.ubk.uhu).

Ha valóban fltk-1.3.3 rendszerszintű Linuxon a hiba, akkor lgb az UBUNTU -n megnézhetné, hogy neki működik e a mkconfig...
Lehet, hogy UBI alatt már megpatkolták az fltk-t erre a hibára, akkor átveszem tőlük az fltk hibajavító foltot.
szerk:
Az fltk1.3_1.3.3-8.debian.tar.xz -ben nincsenek debian foltok, tehát, ha LGB-nek működik, akkor az fltk patkóval nem gyógyítandó.
Tényleg! UBI alá nem lehet telepíteni kész ep128emu csomagot valamelyik ppa tárolóból?
Title: Re: EP128emu
Post by: Attus on 2016.August.08. 07:47:43
István!

:idea:
Nem lenne egyszerűbb  ezt a nyamvadt makecfg -t magából az emulátorból, annak menüpontjából indítani?
Akkor  a fájlválasztó ablak már biztosan megjelenne.
Title: Re: EP128emu
Post by: Attus on 2016.August.08. 09:05:48
UHU-3 alá én célszerűnek láttam lecserélni a /usr/bin/ep128emu binárist egy ep128emu szkriptre, persze az ep128emu bináris átneveztem ep128emu.bin -re.
Így ugyanis az ep128emu hívása esetén a szkript letölti a romokat, ha kell, és futtatja az ep128emu.bin ELF binárist a megkapott paraméterekkel.
Ha meg létezik $HOME/.ep128emu mappa, akkor nem tölt le semmit, hanem egyből futtatja az emu -t. :cool:
A makecfg-ep128emu.bin exec hívással nem jó, mert azzal a szkript már elfelejtődik! :(
Ettől még a makecfg-ep128emu wrapper nyugodtan lefuttatható külön is. :)

Az ep128emu /usr/bin alatti ep128emu nevű indító wrapperem: https://github.com/uhulinux/ub-3/blob/55c629c626ccd6da7b86e3c928b2d187937237c2/ep128emu/addons/usr/bin/ep128emu
A  csomag chrootba installáló szkriptje: https://github.com/uhulinux/ub-3/blob/55c629c626ccd6da7b86e3c928b2d187937237c2/ep128emu/install
Title: Re: EP128emu
Post by: Attus on 2016.August.08. 10:02:37
Kipróbáltam az fltk-1.3.3 -al készült csomagomat az UHU-3 alatt.
Az ablakkeretben az ikonok nem jelnnek meg GNOME, MATE, ICEWM, LXQT alatt, ellenben fluxbox, kwin (KDE4), openbox ablakkezelőknél igen.
Hiába, ez nem oly sima ügy, mint windows esetén, ahol nincs ilyen ablakkezelő választék, mely az ablakkereteket építi fel.
:twisted:

A gdb kimenet ez:
Code: [Select]
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)

Csatolok pár képernyőképet a fluxbox alól, amelyekben változást tapasztaltam a menüben megjelenő ikonokat illetőleg.
Title: Re: EP128emu
Post by: lgb on 2016.August.08. 10:39:02
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.

Ja, hogy azt nezne? No, ezt nem talaltam, en az SConstruct-ban kerestem, de akkor lehet, hogy az scons "beepitve" tartalmazza a tesztet, es az SConstruct csak utasitja ra, hogy csinalja meg.

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

:) Viszont:

Code: [Select]
lgb@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
Title: Re: EP128emu
Post by: IstvanV on 2016.August.08. 11:11:25
Ja, hogy azt nezne?

Nem, jelenleg nem használja a pkg-config-ot, de elvileg könnyen be lehetne építeni. Probléma azonban, hogy nem tűnik hordozhatónak a disztribúciók között, lehet, hogy több csomagnévvel is kellene próbálkozni (lua, lua51, lua-5.1, stb.).
Title: Re: EP128emu
Post by: Attus on 2016.August.08. 20:51:50
Megcsináltam az fltk teszt tárolójából a legfrisebb forrásból az fltk csomagot (1.3.4) és azzal az ep128emu csomagot.
https://github.com/fltk/test-only
Feltelepítettem őket.
Ezzel már nem száll el a makecfg, feldob egy gtk ablakot az fltk helyett a célmappa választáshoz, amlelybe nincs beírva előre a ./ep128emu mappa, nekem kell beírni, de ekkor kilép, hogy a mappa már létezik, igaza van, mert a wrapper hozta létre. Ha közben letörlöm a létrehozott .ep128emu mappát, akkor már továbblép a makecfg, feldobja az fltk ablakot a keyboard konfigurálásához és rendben befejezi a működést. Azaz mégse, mert a romhalmazt nem bontja ki!

Szumma.
Az fltk-1.3.3 -al a makecfg puritán módon összeomlik, az fltk-1.3.4 teszt változattal meg nem bontja ki a romhalmazt a felhasználó bosszantása után sem.

Tehát Linux alatt úgy néz ki, hogy csak az fltk-1.3.2 az utolsó használható eddig az ep128emu -hoz.

Visszafejlesztettem UHU-3 telepítményemen az eredeti fltk-1.3.2 -t és a vele gyártott ep128emu változatot.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.09. 07:45:23
Az ablakkeretben az ikonok nem jelnnek meg GNOME, MATE, ICEWM, LXQT alatt, ellenben fluxbox, kwin (KDE4), openbox ablakkezelőknél igen.

Ezt az emulátorban valószínűleg nem lehet javítani, az ikonok megjelenítése az FLTK feladata. :)

Quote
Csatolok pár képernyőképet a fluxbox alól, amelyekben változást tapasztaltam a menüben megjelenő ikonokat illetőleg.

Ha a Spectrum és CPC ikonok EP módban jelennek meg, az bug, amit hamarosan javítok. :oops:

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.
Title: Re: EP128emu
Post by: Attus on 2016.August.09. 08:06:00
Nos, gányoltam!
:)
Belekukkantottam az fltk-1.3.3 forrásába (http://fltk.org/pub/fltk/1.3.3/fltk-1.3.3-source.tar.gz).
Újra legyártattam a csomagkészítő rendszeremmel az fltk-1.3.3 csomagot a mellékelt foltot alkalmazva, melyet én kreáltam arra, hogy lebeszélje a native-file-chooser -t a gtk változatról.
Ezután ezzel az fltk csomaggal ismét az ep128emu csomit gyártottam újra.
Feltelepítettem az UHU-3 rendszeremre az imígyen legyártott ep128emu csomagot, melyhez az apt csomagkezelőm természetesen hozzátelepítette az imént elkészült foltozott fltk csomagomat is.

És az ep128emu működik, a makecfg is, ami nem omlik immár össze, hanem a hagyományos fájlválasztó ablakkal indít, majd a keyboard ablakkal folytatja és ki is bontogatja a romhalmazt a megfelelő helyre, és utána indul is rendben az ep128emu.
Ez siker az ep128emu -t tekintve, de ez azért mégis gány, mert ezzel kiheréltem az fltk gtk újítását, melyet más programok esetleg használhatnak. Ez nem épp illő dolog, de most itt célravezető.
A legjobb lenne, ha az ep128emu forrását próbálná meg István hozzápasszítani a foltozatlan fltk-hoz.

István!
Megkérhetlek erre?
Persze, ha lehetséges az ep128emu forrás értelmes és célravezető módosítása.

Az mégsem várható el, hogy valamennyi linux disztró, melyek a stabilnak kiadott fltk-1.3.3 -at használják, az ep128emu kedvéért az én foltommal megpatkolják az fltk-1.3.3 csomagjaikat.

Egyelőre én sem veszem bele a patkómat a leendő új UHU kiadásunkba (Szeptemberre várható), lehet, hogy inkább újra belerakom a már kidobott fltk1 csomagot és azzal fog ott majd működni, a most egyelőre így az ottani fltk-1.3.3 -al legyártott ep128emu csomag.
Title: Re: EP128emu
Post by: Attus on 2016.August.09. 08:10:05
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.

Bízom benned!
;-)
Közben írtam valamit én is, ezután olvastam ezt a hozzászólásodat, melyre így elkésve reagálok.
De legalább látod, hogy ügyködtem én is  a magam módján...
Title: Re: EP128emu
Post by: IstvanV on 2016.August.09. 19:06:27
[attachurl=1]
[attachurl=2]

- az emulált gép típusának nem megfelelő ep128emu ikonok javítva
- a makecfg az FLTK file választó ablakot használja Linuxon az 1.3.3 verziónál előforduló hibák elkerülésére
- pkg-config használata a Lua konfigurálására ha egyébként nem sikerül megtalálni (ezt nem teszteltem)
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 07:25:48
Szuper!
:)

Most tűnt fel, hogy a régebbi fltk -val a minimalizált ep128emu ablakok a paneltálcákon az ablakkezelőfől függetlenül (MATE, stb.) eddig ikontalanok voltak, most meg szép zöld ikonnal rendelkeznek.
Nem, mintha az emu működését ez befolyásolná, csupán esztétikailag szebb.

Ellenben újabb "hibát" fedeztem fel az ep128emu -ban.

A plus4emu ablakok  tálcára minimalizált ablakjainak ikonjai:

emulátor: Cbm4
keyboard map: mini billentyű
gép beállítás: mini billentyű
display: mini monitor
floppy: mini floppy
hang: semmi extra, a gép alapértelmezetté
:cool:

Ellenben az ep128emunál nem így van, ott mindig a zöld E betűs ikon van minden ablaknál.
:(
Title: Re: EP128emu
Post by: IstvanV on 2016.August.11. 13:12:40
Ellenben az ep128emunál nem így van, ott mindig a zöld E betűs ikon van minden ablaknál.

Ez nem hiba, EP-hez, Spectrumhoz, és CPC-hez jelenleg nincsenek külön floppy, billentyűzet, stb. ikonok. :oops: A Plus/4-es ikonok eredetileg nem saját készítésűek (amint az a Read_me.txt-ben olvasható), elvileg lehetne ezeket használni az ep128emu-ban is, de jobb lenne újakat készíteni, amelyeken nem Commodore hardver látható. :)

Egy újabb patch néhány kisebb debugger fejlesztéssel, amelyeket az ep128emu újabb verzióiból másoltam:
[attachurl=1]
- a debugger ablak villogása a Step gombok használata közben javítva
- 160 soros monitor puffer 120 helyett
- szöveges formátumú memória kiírás
- a monitor támogatja a 2-es, 8-as, és 10-es számrendszert, az ep128emu-hoz hasonlóan
Title: Re: EP128emu
Post by: Zozosoft on 2016.August.11. 13:31:39
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
Title: Re: EP128emu
Post by: lgb on 2016.August.11. 13:40:43
Nekem az utolso SConstruct path ota a plus4emu:

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

Pedig meg sem talalta:

Code: [Select]
Checking for C header file lua.h... (cached) no
Title: Re: EP128emu
Post by: IstvanV on 2016.August.11. 14:00:27
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

Ez megoldható, bár nem tudom, melyik megoldást lenne érdemesebb választani.

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.
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 14:28:09
Nekem semmi gondom a plus4emu csomagom elkészítésénél, megtalál mindent.

A Sconstruct fájlt megpatkoltam, hogy a scons install jól végezze a dolgát, kibővítettem a config és rom cuccok installálásával is.
A p4makecfg parancsrészt kitöröltem az installálási részből, mivel a chroot környezetben interaktivitás nem lehetséges.
Lehet, hogy István találna benne még ésszerűsíteni valót.

Az installálás végeztével az plus4emu binárist árneveztem plus4emu.bin -re, amit az installálási rész után a dpkg csomagolóm által hozzáadott és a /usr/bin alá elhelyezett plus4emu wrapper hív majd fel az emu futtatásakor, amennyiben a júzer ~ könyvtárában nincs .plus4emu mappa.

Mellékelem a csomagom elkészülési logját, lehet, hogy LGB is talál benne valami megoldást a lua problémájára.

Az installálási SConstruct foltom (https://github.com/uhulinux/ub-3/blob/72d3c2526684b61a22a204ec740f388ee415c75b/plus4emu/patches/sconstruct.patch)

Az installálási rész (https://github.com/uhulinux/ub-3/blob/72d3c2526684b61a22a204ec740f388ee415c75b/plus4emu/install)

A pluszban szállított wrapper (https://github.com/uhulinux/ub-3/blob/70e583d08a10fc98d7b132db4279986f0feb48cb/plus4emu/addons/usr/bin/plus4emu)

Próbáltam átadni egy $DESTDIR környezeti változót a SConscript fájlban a HOME helyébe illesztett DESTDIR -el, de nem volt hajlandó átvenni a $DESTDIR értékét.

Ez nem működött:
export DESTDIR=${UB_INSTALLDIR}/usr
scons install
Title: Re: EP128emu
Post by: lgb on 2016.August.11. 14:56:57
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.

Nemi clean utan:

Code: [Select]
Checking for C header file lua.h... no
Ennek ellenere tovabbra is leakad, hogy nincs lua.h, pedig igy tenyleg probalnia sem kene ...

Code: [Select]
scons: 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
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 15:01:03
Hol van a rendszereden a lua.h nevű fájl?
Talána szájába kéne rágni ennek a SConstructnak.
UHU 3 alatt csak lua-5.1 van, ahol a lua_dev csomag ide rakja:  /usr/include/lua.h

A fejlesztő rendszeren van lua-5.1, ami szintén ugyanoda rakja.
Afelesztői rendszer van lua52 csomag is, amiből a lua52_dev csomag ide teszi:
 /usr/include/lua5.2/lua.h

Én most UHU-3 alá csináltam az ott lévő lua-dev csomaggal.
Megkísérlem a fejlesztői rendszerre is a lua52 -vel, de kérdem én! Minek a lua52, ha elég a régi lua?
Title: Re: EP128emu
Post by: lgb on 2016.August.11. 15:15:15
lgb@vega:~$ pkg-config lua-5.3 --cflags
-I/usr/include/lua5.3
lgb@vega:~$ pkg-config lua-5.2 --cflags
-I/usr/include/lua5.2
lgb@vega:~$ pkg-config lua-5.1 --cflags
-I/usr/include/lua5.1

En ebben kicsit tanacstalan vagyok, mar gondoltam ra, hogy elegge el nem itelheto modon atirom Makefile-ra :D Ez nem az SConstruct-ot minositi persze, hanem engem :)
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 15:27:08
Csak a lua csomaggal fordul most le, a lua52 -vel bajok vannak.
Nyilván, mert a lua.h nem a /usr/include alatt van, hanem nem szabvány helyen.
Megpatkolás nélkül egyszerűen átlépi és lua támogatás nélkül fordul le.
Megpatkoltam a SConstruct fájlt, hogy a lua52 -t is keresse, ekkor már megakadt, hogy nem találja a lua.h fájlt.
Code: [Select]
for pkgName in ['lua-5.1', 'lua51', 'lua', 'lua52']:
A config.log része:
Code: [Select]
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.
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 15:30:53
lgb@vega:~$ pkg-config lua-5.1 --cflags
-I/usr/include/lua5.1

Ezé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.
Nyilván a SConstruct által generált cucc nem ott keresi és nem találja.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.11. 15:37:02
Ennek ellenere tovabbra is leakad, hogy nincs lua.h, pedig igy tenyleg probalnia sem kene ...

A probléma nem ott van, ha a lua.h-t nem találja a "szabványos" helyeken, akkor ezzel próbálkozik:
Code: [Select]
   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
            break
Tehát arról kellene többet tudni, hogy itt pontosan mi történik.

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']
Title: Re: EP128emu
Post by: Attus on 2016.August.11. 19:36:35

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']
Na, ez a rész nekem szinte kínai.
:oops:
Title: Re: EP128emu
Post by: lgb on 2016.August.11. 20:37:11
Ezek utan jonak tunik (bar oszinten, hiaba ertek a Python-hoz, valtozatlanul nem latom at, mit csinal ez az SConstruct valahogy ...):

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

Szerintem ep128emu-nal is megnezem, ugy remlik ott sem fordult nekem Lua-val ...

UPDATE: most mindket git repo-ba betoltam, mivel ugy tunik igy fordul rendben. Meg elvileg osszes "Istvan Patch" :) is bekerult mindkettobe, vagy hat remelem legalabbis, hogy most ep128emu es plus4emu github cuccom is up-to-date szerunek mondhato. Bar neha elvesztettem a fonalat, hogy akkor most hol is tart a patch aradat :D :D
Title: Re: EP128emu
Post by: IstvanV on 2016.August.11. 21:54:40
Időközben újabb patch készült, de ha csak a CPPPATH változott a GitHub-on, akkor talán nem probléma, hogy figyelmen kívül hagyja a változást, mert ugyanazt a hibát szintén javítja.

[attachurl=1]
[attachurl=2]

- a snapshot töltés az ep128emu indításakor automatikusan beállítja a gép típusát, ha ezt a parancssor nem tartalmazza
- 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
- Attus installer módosításait beépítettem, ha az UB_INSTALLDIR környezeti változó definiált, akkor az SConstruct feltételezi, hogy csomag készül chroot környezetben
- a bináris értékek most már valóban működnek a plus4emu monitorában, az előző patch hibás volt

Az installer/plus4emu file-nak futtathatónak kell lennie (chmod 755), ez a script indítja az emulátort a Linux csomagban.
Title: Re: EP128emu
Post by: lgb on 2016.August.12. 00:00:41
Bedolgoztam :) Amugy Istvan, nem akarsz vmi iras jogot a github-os cuccokra? A Te projecteid, igazan megerdemelned :) Finoman szolva is ... Nem mintha lusta lennek patch-elgetni, szoval nyilvan nem kotelezo, csak gondoltam megkerdezlek azert, remelem nem gond.
Title: Re: EP128emu
Post by: Attus on 2016.August.12. 08:45:07
István!
Ez a legutóbbi plus4emu változat már szinte túlkényezetet engem.
:bow:
Nem kell semmi foltozás, extra plusz fájl, wrapper hozzáadás.
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ó?

A csomagom készítésénél a compile rész ennyi:
scons

Az install része meg:
scons install.

Ha letörlöm a feltelepített elkészült csomagom első futtatása előt a ~/.plus4emu mappát, akkor a menüpont plus4emu részére kattintva csak egy billentyűzet beállítő ablakocskát kapok és utána máris teljes pompájában működik az emu.
A következő indításoknál azonnal indul. A p4makecfg -t külön terminálból felhívva újra konfigurálható minden.

Más disztrók meg beállítják majd maguknak az UB_INSTALLDIR változót arra, ami nekik megfelel.
Title: Re: EP128emu
Post by: Attus on 2016.August.12. 09:21:50

- 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

Kipróbáltam lua52 -vel.

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

Megtalálja rendben a lua52 fejléceket, vígan fordít, csak a végén akad el, gondolom a lua52 változás miatt.
Ez már a forrásba való belenyúlást igényli, hogy lua52 -vel is fordítható legyen.
A hiba üzi:
Code: [Select]
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.

]
Itt találtam (http://stackoverflow.com/questions/9057943/porting-to-lua-5-2-lua-globalsindex-trouble) egy portolási ajánlást, mellyel a kód mind lua51, mind lua52 esetén működik majd.
Title: Re: EP128emu
Post by: Attus on 2016.August.12. 11:24:04
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?
;-)
Title: Re: EP128emu
Post by: IstvanV on 2016.August.12. 11:44:41
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.
Title: Re: EP128emu
Post by: Attus on 2016.August.12. 12:45:38
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.
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.
Title: Re: EP128emu
Post by: lgb on 2016.August.12. 13:06:20
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.

Most felreertes ne essek, megsertodni ne tessek :D cimu versezet utan szabadon: persze, nyilvan orommel adok :) De azt sem akarom, hogy valaki azt higyje, hogy nem akarok vele foglalkozni, akkor nem toltam volna oda fel. Viszont az teny, hogy sokat nem tudok hozzaszolni erdemben, se SConstruct wizard nem vagyok, se C++ guru, ahogy gondolom ez mar reg kiderult mindenki szamara :) Csak szerettem volna, ha valami normalisabb helyen van. A sourceforge nem tul hasznalhato, anno regen egesz jo volt, mplayer fejlesztesben amikor aktiv voltam, volt ott is a cucc, es jonak is tunt, meg hat alternative sem nagyon volt, de manapsag szerintem egy katasztrofa a cucc. :( Ami az MS-nek van ilyen open source hostingja (bar sajnos a neve nem ugrik be) az meg szinten egy remalom, nem jelenik meg az oldal fele, csak ha gorgetem, a kinezete kb olyan, mint 20 evvel ezelott az "elso weboldalam" cimu konyv peldaja stb ... Biztos van a github mellett ertelmes alternativa meg, amirol nem tudok (gitbucket vegulis nem tunik rossznak - az mar tenyleg szubjektiv es egyeni preferenciam, hogy nekem valahogy kevesbe jon be).

Meg ugye ez a kozossegi fejlesztes feeling, "fork me!" stb ez nekem tetszik :) Epp tegnap tunt fel, hogy a Mega65 csapat forkolta az "xemu" projectemet, gondolom amiatt, hogy Commodore 65 emulator is van benne (amugy, hogy ne legyen teljesen off-topic: gondolkodok azon, hogy a Xep128 hosszabb tavon megszunik letezni mint onnallo project, de az Xemu-n belul megmarad, es tovabb lesz fejlesztve, csak hat az emulator "framework" lenne a lenyeg, ami a kettoben hasonlo, es duplan karban tartani kicsit luxus).

A masik, hogy az en Makefile hackelesem lehet tok felesleges, nyilvan meg lehetne szepen csinalni SConstruct-bol is :)

Quote
É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.

Grats! :)
Title: Re: EP128emu
Post by: IstvanV on 2016.August.12. 20:46:27
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.

[attachurl=1]

Kisebb javítás az installerben:

[attachurl=2]
Title: Re: EP128emu
Post by: lgb on 2016.August.12. 22:00:28
Ok, betoltam. Lehet, nemsokara nem is kell az en Makefile meg installer cuccom es majd torlom.

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.
Title: Re: EP128emu
Post by: szipucsu on 2016.August.12. 22:07:13
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.
Title: Re: EP128emu
Post by: Attus on 2016.August.12. 22:33:38
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.

Már megint a romhalmaz problematika...

Sajna a curl parancs chroot környezetben használhatatlan. :(
Ott ugyanis csak a fordításhoz felétlen szükséges cuccok vannak, nincs grafika, internet, tehát szerencsétlen, csak a csomagkészítéshez definiált  és életre keltett és oda beléptetett korlátozott írási jogokkal rendelkező (hogy semmit ne tehessen tönkre ott) build felhasználó nem tud letölteni semmit, csak a neki odakészített dolgokkal, kész fájlokkal és feltelepített programokkal tud valamit kezdeni.
Ezért én kifoltoztam a SConstruct fájlból a curl részt.
Code: [Select]
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",


A csomagkészíítéshez tehát a githubról származó forráson kívül letöltetem az ep128emu_roms.bin fájlt is, megfoltozza a build rendszerem a foltommal a forrást, majd felépíti a minimális szükséges chroot környezetet és belépteti oda a build felhasználót és vele elvégezteti a fordítást és installálást, aki ugyanis lefuttatja a rendelkezésére bocsájtott compile és az install szkripteket is, majd munkájának eredményét összerámolja csomaggá. Ezután a build rendszer kilépteti őt a chroot alól, az ott elkészült cuccot meg kimásolja nekem a chroot alól az általam kívánt mappába.
A csomagot feltelepíthetem a teljes rendszeremre és kipróbálhatom, akkor már használhatja a csomagom a curl, vagy wget parancsot.

Most a fentebb vázolt probléma miatt az installáló szkriptem erre változott:
Code: [Select]
#!/bin/sh -eux

scons install
cp ep128emu_roms.bin ${UB_INSTALLDIR}/usr/share/ep128emu/roms/

Így viszont a csomagban benne van újból a romhalmaz is, habár a curl-val installáló részed működése esetén is benne lenne.
Internet kapcsolat nélkül is használható egyből az emu.
Az ep128emu wrapperben a csomagot feltelepítő és használó júzer már használhat természetesen minden olyan parancsot, amelyet a csomag futási függőségeként előirok a csomagban a depends fájlban. Tehát akár wget, vagy curl parancsot is, de ekkor a csomag feltelepülésekor az előírt cuccoknak is fenn kell lennie nyilván a rendszeren, hogy júzerkám használhassa, ha azok nem lennék a rendszerén, akkor okos csomagtelepítőm az apt felteszi majd neki.
Tehát, ha a wrapperben lenne a curl, akkor az töltené le a romhalmazt, ha júzerkám rajta lóg a neten, különben nem történik semmi, csak létrejön neki a ~/ep128emu mappa romhalmaz nélkül és az UHU rendszert hibáztatja, hogy nem műkszik neki az emu.

Ezután le is vakarja az UHU rendszert és felrak egy felkapottabbat, mondjuk valamely BUNTU származékot, és azon fog kinlódni vele, mert normális, forrásból felépített deb csomagot ott sem talál, vagy letölti a sourceforge-ról a kész, jól felhizlalt, mindent statikusan tartalmazó, vagy 10 éves binárisodat. Végül beleun és újra rátér a windóz örömeinek élvezetére.
Title: Re: EP128emu
Post by: Attus on 2016.August.13. 08:57:35
A SConscript nyilván jól végzi majd a dolgát mindem más, olyan Unix rendszeren, melyen a csomagkészítés során a curl parancs használható. E tekintetben az UHU talán az egyedüli kivétel. Egykoron pont azért találta K. Egmond, meg P. Balázs ezt az egész szerintem zseniális chroot alatti csomagkészítési technológiát, hogy pontosan meghatározható legyen az elkészítendő csomag környezete, ami teljesen független a csomagkészítő rendszeren lévő cuccoktól. Tehát még nem létező UHU verziókhoz is lehessen csomagokat készíteni. Én határozhatom meg, hogy milyen kernel legyen a chrootban, milyen UHU disztribúció alá készüljön a csomag, a chroot mikből épüljön fel. Például UHU 2.2 alatt, mely még a régi init rendszert használja, nyigodtan tudok csomagot készíteni az UHU 3 alá, mely UHU 3 már systemd -t használ. Mostanság meg a leendő, szinte legfrisebb verzió állapotú csomagokból álló újabb, tervezett kiadásunkhoz készítjük őket. Természetesen ezeket gyakorlatban kipróbálni csakis már olyan feltelepített rendszeren lehetséges.
Ezért tudom viharos gyorsasággal megcsinálni különféle lua verziókkal az ep128emu csomagot, hisz én írom elő a csomagkészítéshez használatos (természetesen a chroot számára elérhetővé téva a már meglévő csomagválasztékot) lua, vagy lua52 csomagot. Ekkor a csomagkészítő CSAK a lua52 -t tudja majd használni. Ha egy csomag elkészül, nagy valószínűséggel jól fog majd működni a gyakorlatban is.

Ezt azért írtam, mert én túl egyedinek találom ezt UHU curl esetet, amit nyilván csomagom számára én leküzdök, már le is küzdöttem.

Ezt az egész romhalmaz licensz problematika azért érdekes.

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.

Ha valaki elkészíti most nem UHU alá a SConscript segítségével más rendszer alá az rpm, vagy deb, vagy akármilyen csomagot, a csomagjában benne lesz a romhalmaz.
Igaz, hogy ez az ep128emu esetében nem az ep128emu githubos forrásából származik.
Áthidaló megoldásként jó lenne valamilyen COPYRIGHT, vagy LICENSE fájl a romhalmazok számára, melyet a csomaghoz hozzá lehetne csapni. A júzer azt a csomag feltelepítése után elolvashatja.
Ha egyetért vele és tudomásul veszi, akkor nyilván használhatja majd az emut, ha nem, akkor uninstallálhatja az emu csomagot a romhalmazzal egyetemben. Innentől kezdve nem a csomag készítőé és a GPL -es emu forrásának készítőé a felelősség a nem GPL romhalmaz használatáért.

Amúgy az a megoldás, hogy az ep128emu első futtatásakor a wrapper töltse le a romhalmazt, majd futtassa azepmakecfg -t azért nem tetszik, mert hibalehetőségeket tartalmaz.
Nincs internetkapcsolat, vagy az enterpriseforever.com a futtatás pillanatában mondjuk szerverkiesés miatt elérhetetlen, satöbbi.
Ráadásul lassú letöltési sebesség esetén ez még időigényes is, mely a mai rohanó világban egyeseket idedesít és eltanácstalanít.

A cp parancs viszont mindig elérhető.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.13. 09:29:43
Már megint a romhalmaz problematika...

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.

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.

Mivel ugyanazokat a Commodore ROM-okat más, ismertebb emulátorok (pl. a VICE) forrása is tartalmazza a SourceForge-on, feltételeztem, hogy a beépítésük nem probléma. :oops: Az EP-s ROM-ok esetében bonyolultabb lehet a licensz kérdés, mert nem csak az eredeti Intelligent Software ROM-ok kerültek a csomagba, hanem több más szerző programjai is, mint például az ASMON.

De megoldható lenne, hogy plus4emu csomag készítésekor az SConstruct ne installálja a ROM-okat, és a wrapper töltse le ezeket is.

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.

Van (istvan-v), bár eddig nem igazán használtam.
Title: Re: EP128emu
Post by: Attus on 2016.August.13. 09:42:14
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.
Ha mégsem, majd utánanéz a júzer a rom hiánynak és pótolja, ahogy tudja.
Title: Re: EP128emu
Post by: IstvanV on 2016.August.13. 12:26:32
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.

Az emulátorok most már itt is megtalálhatók:

https://github.com/istvan-v/ep128emu
https://github.com/istvan-v/plus4emu

Szerk.: a Lua 5.2 hibát már javítottam az ep128emu-ban
Szerk. 2: a curl problémát is javítottam (remélhetőleg)
Title: Re: EP128emu
Post by: Attus on 2016.August.13. 16:22:47
Köszönöm István!
:)
Hamarjában javítottam is az ep128emu  wrapperen a github tárolódban, mivel hibát véltem felfedezni benne.
A gyakorlatban szépen működik az elkészült és feltelepített új ep128emu csomag, a wrapper szépen leszedi a romhalmazt, elindítja az emut.
Minden rendben lévőnek tűnik.
;-)

A lua52 -vel is szépen lefordul.
Title: Re: EP128emu
Post by: lgb on 2016.August.13. 16:28:13
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 ...
Title: Re: EP128emu
Post by: Attus on 2016.August.13. 17:07:15
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.
A dosemu is használható valódi DOS -al, de eleve freedos -al szállítják csomagszinten. Kiváncsi lennék, hogy mi lenne vele ha nem lenne freedos?

Amúgy én meg egyáltalán nem törekszem UHU-only stílusra, sőt! De arra igen hogy például Debian is csinálhasson a forrásából könnyen deb csomagot a csomagkészítő mechanizmusával, vagy Arch Linux is egy PKGBUILD -ot. Ez utóbbit már akár én is meg tudnám írni, mivel konyítok hozzá valamit, a forrás mostani állapotában.
Az UB_INSTALLDIR elnevezés az egyetlen, mely szerintem az UHU -ra utal, de azt is csak az UHU csomagkészítását ismerők tudják.
Valahogy így nézne ki most egy PKGBUILD durván:

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

Egyébkén Arch-Linuxhoz nincs ep128emu most még az AUR szekciójában sem.

Egy ep128emu.spec is könnyedén írható most már valamilyen RedHat rendszer rpm-jéhez.
Title: Re: EP128emu
Post by: lgb on 2016.August.13. 18:09:25
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.

Nem, mert ket csomag ket kulonbozo licenccel ... Attol meg hogy dependal ra, az nem sert semmi licencet, nem egyutt van disztributalva ugye. Illetve depends helyett lehet "suggests" stb is.

Ennek ellenere, nem kotekedni akartam ... Hogy mi a *jo* megoldas erre, az erdekes kerdes. Lehet, teljesen jo nincs is :) Csak szubjektive jobb es nem jobb ...
Title: Re: EP128emu
Post by: Attus on 2016.August.13. 18:42:46
Most az ep128emu bináris csomag GPL.
Nincs benne nonfree rom, csupán a wrapper letölti, ha tudja a licensz nélküli romhalmazt.

Tényleg. Lehet, hogy jobb lenne a külön romhalmaz csomag, mint így csak mint írtam, kellene abba egy licensz leírás is, anélkül semmi értelme.

Ekkor a wrapper visszatérhetne a curl letöltés helyett a kopírozásra, amennyiben az ep128emu főcsomag telepítési függésének megadja a csomag készítője a romhalmazt. A romhalmaz csomag meg a /usr/share/ep128emu/roms alá  szállítja a romhalmazt, ahonnan már az ep128emu wrapper át tudja másolni a júzer ~/.ep128emu/roms mappájába.

Kérek egy licensz fájlt a leendő romhalmaz csomaghoz!
Title: Re: EP128emu
Post by: Attus on 2016.August.14. 16:00:55
Romhalmaz...
:idea:
Az igazi az lenne, ha az epmakecfg maga ellenőrizné a romhalmaz meglétét, ha nem leli, akkor egy táncra invitáló ablakot dobna csak fel, hogy kedves júzerkám légy oly kedves és kerítsd elő romokat!
Ezután nyugtázásra várás után szépen kilépne.
Nem is értem, hogyan is van képe az ep128emu -nak elindulnia rom nélkül?
Ha nincs neki romja, akkor egy hasonló táncrakérő ablakot kellene csak produkálnia, és nyugta után elhagynia a terepet.

Ha ezt megtennék, akkor a júzer a nonfree rom csomagot felrakhatná a maga szakállára, amely csomag oda rakná a romhalmazt, ahová az emu és a makecfg kéri.
Title: Re: EP128emu
Post by: szipucsu on 2016.August.14. 18:29:03
nyugta után elhagynia a terepet.
Nyugtával kell dicsérni a napot! :D
Title: Re: EP128emu
Post by: lgb on 2016.August.17. 23:14:48
Toroltem a sajat github repo-kat mert sok ertelme nincs, hogy rolam forkolta Istvan, amikor az ove :)

A plus4emu eseten nem is volt gond, Istvane lett igy az upstream kb a github szerint is. Az ep128emu eseten kicsit vicces, mert engem forkolt Attus es Istvan is, az enyem torlesevel viszont most Attus repojarol mondja a github, hogy o az upstream. Mondjuk nem tudom mennyi jelentosege van ennek (szerintem nem sok, max esztetikai).
Title: Re: EP128emu
Post by: Attus on 2016.August.18. 13:32:59
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.
Title: Re: EP128emu
Post by: lgb on 2016.August.18. 18:46:50
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 ...
Title: Re: EP128emu
Post by: Attus on 2016.August.18. 19:40:47
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:
Legfeljebb vissza lehet majd tenni, ha mégis kell, hisz a github minden commit állapotot megőriz.

Az lenne jó, ha Isván beletenné a forrásba a rom ellenőrzést, én nem tudom, mert a C-hez hülye vagyok, sok mással egyetemben.
Meg nem is az én projectem, nem venném magamnak a bátorságot hozzá. A bash wrapper-be még bele tudok kontárkodni, ezt meg is tettem, de tőlem csak ennyire futja. :oops:
Title: Re: EP128emu
Post by: lgb on 2016.August.28. 22:47:03
Mivel mas miatt kellett, kiprobaltam erre is:

https://travis-ci.org/lgblgblgb/ep128emu
https://bintray.com/lgblgblgb/generic/ep128emu

Az elso ezek kozul egy build test cuccos vegulis, amit osszekot az ember github-bal, es magatol esetleg minden commit-nal teszteli, hogy build-elheto maradt-e, stb. itt beleeroszakoltam szegenybe a wine-os trukkoket, meg ilyesmi. A masodik a bintray, az meg vegulis aztan a travis es kozte ad deployment szolgaltatast, tehat az eredmeny le is toltheto onnan (mivel a travis altal hasznalt docker stuff csak ideiglenes, a build utan magatol megszunik).

Nem tudom jo-e valamire (marmint ertsd: hogy igy esetleg le is toltheto allapotban van, forditas nelkul is az "egyszeru felhasznalok" szamara - nem, ebben nem volt kritika am, mielott valaki belem akarna kotni :) ), csak megprobaltam erre is.

Amugy MacOSX-et is tudna, probaltam is, csak epp nem jottem ra, hogyan lehet homebrew-val feltenni ami kell aztan a forditashoz, de az elso linken lathato az output az OSX build-re is persze. Illetve hat annak kb hianyara, mivel az scons elegge az elejen megakad, hogy nem talal ezt-azt :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.August.31. 18:38:00
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:
Title: Re: EP128emu
Post by: Attus on 2016.August.31. 20:01:40
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.
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.
Title: Re: EP128emu
Post by: Zozosoft on 2016.August.31. 20:22:23
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...
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...
Title: Re: EP128emu
Post by: Attus on 2016.September.02. 07:55:22
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...
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.

LGB eléggé előrelátón csak windózos binárisokat csináltatott a travis -al, linuxosakat nem, hisz a linux család nem oly egységes, mint a windóz, minden linux disztróhoz, ráadásul annak minden verziójához kellene egy pásszos bináris. Viszont most, hogy a githubos forrás késznek mondható, minden linux disztró csomagápolója könnyedén csinálhat a disztrója és annak verziói számára telepíthető csomagot a forrásból, ezzel megkímélve a júzereit a barkácsolástól.
LGB-től maximum az lehetne elvárható, hogy az általa használt UBUNTU verzióhoz csináljon mások számára is elérhetőn deb csomagokat, amiket én természetesen nem tudnék használni egyik telepített Linux rendszeremen sem.

Minden linuxnál viszont használható a windózos exe is a wine emulátorral, mely wine emulátor minden normálisabb linux disztróban működik.
:)
Title: Re: EP128emu
Post by: lgb on 2016.September.03. 23:53:31
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.

:) :) Igen, mivel aki Linuxozik, ugyis fordit ilyesmit, legalabbis en mindig. Oke, tudom, altalanositok :)

Amugy ez travis-szal van, azt is jelenti, hogy most ha ez repo-mban valamit modositanek es github-ra eljut a commit, akkor anelkul hogy _barmit_ csinalnek, a github elkuldi a travis-nak a jelzest, ami aztan elindit ideiglenesen egy virtualis gepet abban Linux-szal, lehuzza a git repo-t es a specifikalt parametereim alapjan elkezdi a script-jeimet futtatni, ami elokesziti a forditast, leforditja. Ezek utan az meg szol a bintray-nek, hogy deploy-olja az eredmenyt oda  :-P Eljen a cloud computing meg mindenfele hasonlo nyekere :) Meg annyi kiegeszites, hogy valojaban csak a "deploy" nevu branch-ra teszi ezt szandekosan, hatha nem akarom publikalni mert pl "kiserleti" build ...

Szoval, ami a bintray-es linken van, az az allapot, amit az en github-os repo-mban jelenleg latni. Ami, ha jol latom, uaz, mint Istvane jelenleg.

Persze, Linux ala is siman mehetne, minden gond nelkul, csak ugye hogy lesz belole csomag, az egy dolog. En ubuntu allatt build-eltetem Travis-on, gyanus, ugy UHU-juk nincs nekik :) Elvileg persze biztos megoldhato lenne vmi chroot-ban akarmiben UHU compatible cuccot rakni. Fedora, akarmi meg van is nekik talan. 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 :)

Ha valakit erdekel, itt latszik is, mit kop ki magabol a Travis ilyen alkalomkor (nem tudom masnak elerheto-e igy ez):

https://travis-ci.org/lgblgblgb/ep128emu/jobs/155779550
Title: Re: EP128emu
Post by: lgb on 2016.September.04. 00:22:37
Ja, azt nem emeltem ki, hogy itt sem artana teszt :) Nekem ugye nincs windows-om, nem tudom, hogy amit eloallitottam installer-t a Travis-os linux-os docker-en futo wine-al :-D az egyaltalan jo-e, mukodik-e ... stb.
Title: Re: EP128emu
Post by: Attus on 2016.September.04. 09:43:33
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.
Én az UHU verziókhoz mindig is megcsináltam és amíg tudom meg is fogom csinálni.

Arch-Linuxhoz nem fogom, de épp most találtam egy régebbit: https://github.com/aur-archive/ep128emu/blob/master/PKGBUILD
Ez is jó pár éves.

Vajon ki lehetnek ezek, akik alkották a tudtunk nélkül?

# Maintainer: Laurent Carlier <lordheavym@gmail.com>
# Contributor: Anton Bazhenov <anton.bazhenov at gmail>
# Contributor: Christoph Zeiler <archNOSPAM_at_moonblade.dot.org>


UBUNTU alá nem leltem deb csomagot belőle egyik tárolójukban sem: http://archive.ubuntu.com/ubuntu/pool/
Személyszerint én tűrhetetlennek találom azt az UBUNTU csomagkészítőitől, hogy a legszámosabban használt UBUNTU -hoz nincs deb csomag az ep128emu -ból.
Itt sincs ep128emu project: https://launchpad.net/

Sőt DEBIAN alá sincs.

A legkevésbbé használt UHU alá meg általam van.

RedHat rpm meg csak PcLOs alá létezik és csak 32 bites és szintén öregecske.

http://rpm.pbone.net/index.php3/stat/4/idpl/25923981/dir/pclinuxos/com/ep128emu-2.0.9-1pclos2010.i586.rpm.html

Nem értem az általam nagyrabecsült nagytömegben használt disztrók csomagjainak karbantartóit.

LGB?
Title: Re: EP128emu
Post by: lgb on 2016.September.04. 16:52:26
Egyáltalán nem éri meg, mert nem 10, hanem nagyságrendileg több Linux megvalósítás is létezik.

En ne tudnam :) Ez csak amolyan koltoi szam volt oda. Akkor mondjuk ugy, hogy meg a legelterjedtebb disztrokhoz csinalni kulon-kulon is gond lenne, ha mindet "neked" kell.

Quote
LGB?

En bevallom oszinten, nem igazan ertek a deb csomagok keszitesehez sem :) Olyat mar csinaltam (xep128-hoz van is), hogy csinal egyet kozvetlenul binarisbol, de ugye - ha jol tudom - ez debian policy alapjan nem elfogadhato mar eleve, ez max ilyen "sajat hasznalatra" dolog akkor. Egyszer elkezdtem olvasni a dolgokat errol, hogy hogy kene, de oszinten kicsit megrettentem az informaciomennyisegtol, es "nekem ennyi idom erre nincs" felkialtassal hagytam a fenebe :) Ez az en hibam, tudom.
Title: Re: EP128emu
Post by: endi on 2016.September.05. 08:20:58
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
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 09:01:34
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 ...
Title: Re: EP128emu
Post by: endi on 2016.September.05. 09:02:48
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 :)
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 09:09:25
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).
Title: Re: EP128emu
Post by: endi on 2016.September.05. 09:21:10
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
Title: Re: EP128emu
Post by: endi on 2016.September.05. 09:25:30
itt van több jó kép meg forrás
http://www.scale2x.it
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 09:29:41
gpu-n is mehet ez gondolom, és szerintem nem túl bonyolult filterek ezek

Ep128emu-ban lehet - passzolom - mivel OpenGL ha hasznalva van ... Xep128 ebbol a szempontbol egyszerubb szerkezet, az sima textura mint kb egy ket dimenzios tomb, aztan az SDL dolga, hogy mit csinal vele, ha eppen win-en, linux-on, OSX-en, raspberry pi-n vagy barmin mas fut, lehet tok mas backend-eket hasznal, abba nagyon nincs beleszolasom, hogy filter-t tegyen ra, ilyet nem lehet, mert pont az a lenyege, hogy egy ilyen egyfajta absztrakcio (mondjuk scaling quaility-t lehet allitani, de a backend-tol fugg, hogy figyelembe veszi-e ...). Istvan nyilatkozhat esetleg extra OpenGL addon-ok viszonylataban ep128emu-ra :)
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 09:32:07
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
Title: Re: EP128emu
Post by: endi on 2016.September.05. 09:37:16
"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
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 09:40:09
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

Jo, hat ha ennyire jobban tudod, akkor csinald meg :) Szerintem semmi ertelme (ami nem azt jelenti, hogy nincs ertelme, csak en nem latom, max azt). Az oldalon is irjak hogy az algoritmus celja a KIS bitmap-eknel jelentos. Egy GBA-je piszok kicsi egy EP-hez kepest.
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 10:13:35
De nehogy felreertsd, amugy lehet ennek letjogosultsaga esetleg (pl neked ezek szerint), csak en igazabol azt latom, hogy az algoritmus celja a "nagy gyenge" felbontasok elvezhetove tetele, mint amilyen a GBA is akar. EP-n ez azert nehez kerdes, mert annak alapbol is eleg jo felbontasa van, meg egy mai monitorra is eppen kb hogy rafer a dupla textura meret, szoval ezert nem latom ertelmet. Nyilvan, az igaz, hogy az EP max felbontasat 2 szinu modban tudja hozni, mondhatnad hogy akkor kisebb felbontasokra. De ugye itt jon kepbe az LPT/LPB hogy akar minden sor lehet mas felbontasban, ezt igy eleg nehez adaptalni, max tenyleg azt tudod, hogy az egesz texturara ranyomod amit az "emu lerenderel" de akkor az a fenti brutal meret lesz. Es itt nem is a "PC teljesitmenye" a legfobb gond, en az ertelmet nem latom, hogy pl az en notebook-om mar nem is tud olyan fenbontast (1472 pixel horizontalisan akkor). Akkor meg utana downscale kene, ami kicsit vicces, hogy elobb scale2x (ami egyfajta upscale) aztan meg downscale ... A masik, hogy a Xep128 valoban nem tul szep egy teremtmeny, belsoleg azonnal texturaba renderel, 32 bit / pixel RGBA. Erre nehez alkalmazi az algoritmust, vagy legalabbis nem pontosan latom, hogy az RGB komponenseket itt kulon el kell jatszani az algoritmussal vagy mi a fenet akarnak tulkeppen :)
Title: Re: EP128emu
Post by: endi on 2016.September.05. 10:21:22
hát nyilván nem hires 2 módra nyomja rá az ember ezt az effektet :)
de azon kívül mindenre :D
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 10:26:32
hát nyilván nem hires 2 módra nyomja rá az ember ezt az effektet :)
de azon kívül mindenre :D

De ez az amit meseltem. Hogy EP-n nincs globalis felbontas ... Most akkor scanline-onkent csinalod mert LPT eseteleg innentol-ideaig mast ir le mint mashol. Akkor viszont a "talalkozasi" eleknel ket fonbontas hataran lehet fura lesz es az algoritmus is problemas (lasd a leirasban a kep szelere vonatkozo megjegyzesek, itt meg kvazi a szele az is, hogy talalkozik egy tok mas felbontassal). Masreszt, az algoritmus szinekre gyakorolt hatasa is erdekes, foleg, hogy tok kulonbozo felbontasok/ szinszamok vannak, szerintem erre nem is egyszeru ezt alkalmazni. Azert mondom, hogy mar max az emulator texturajara kene, tehat min mar le van "renderelve" minden a megfelelo "kesz" allapotra, de az ugye meg mindenhol a max, hires-nek megfelelo felbontas ... Az EP ehhez "tul jo" gep :) hogy ilyen egyszeru algoritmust ra lehessen nyomni, marmint, gondolom legtobb helyen egy globalis felbontas van oszt' csokolom.
Title: Re: EP128emu
Post by: endi on 2016.September.05. 10:30:44
szerintem te nem érted ezt a filtert...
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 10:33:00
szerintem te nem érted ezt a filtert...

Akkor magyarazd el kerlek :) En a forraskodot is megneztem stb. Ez persze nem jelenti azt, hogy meg is ertettem, es helyesen, az is igaz :)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.05. 19:10:48
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...

A GitHub emulátor verziók az itt (https://enterpriseforever.com/ep128emu/ep128emu/msg31713/#msg31713) leírt módon fordítva:
[attachurl=1]
[attachurl=2]
Ez azonban meglehetősen elavult MinGW csomaggal készült. :oops:
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ő?

Ep128emu-ban lehet - passzolom - mivel OpenGL ha hasznalva van ...

Ilyen filtert ugyan az emulátor nem tartalmaz, van azonban TV emuláció, bár a shaderen lehetne javítani, mivel régi GPU-khoz készült.
Title: Re: EP128emu
Post by: lgb on 2016.September.05. 19:24:29
Akkor magyarazd el kerlek :) En a forraskodot is megneztem stb. Ez persze nem jelenti azt, hogy meg is ertettem, es helyesen, az is igaz :)

Mondjuk amit az RGB komponensekrol irtam az tenyleg baromsag, azt nem tudom hogy sikerult oda kevernem, bocs. De a tobbi igaz, az algoritmus alapvetoen egy matrix szeru valamit csinal, ahol minden 1x1 (azaz 1) pixelbol csinal 2x2-ot (azaz 4-et) a kornyezo pixelek figyelembevetelevel, ha jol ertem. A gond ott van, hogy EP-n lehetseges, hogy nem egyseges a pixelsurruseg, ugymond, pl a kepernyo fele ilyen felbontasu, a masik olyan. Oke, mondhatod, hogy ez nem gond, mivel azert persze egesz szamu tobbszoros, es az emu altal "lerenderelve" oda jutna, hogy vegulis lehet, egy 4 colour pixel dupla szeles (tehat 'valojaban' 2 pixelnek fele meg), stb. A gond az, hogy hacsak nem akarod az egesz max felbontasra a scale2x-et (amikor viszont az eredmeny kisse nagy lenne, az en monitoromra ra sem ferne pl ... ezert mondtam hogy utana meg az egeszet downscale-elni kene pl linearis interpolacioval vagy barmi massal), akkor tegyuk ra csak oda, ahol a kepernyo adott reszen az LPB szerint az adott scanline-okra alacsonyabb a felbontas. Itt viszont elojon az a gond, amirol irnak, hogy a kep szelet maskepp kell kezelni. Es ugye az algoritmus szempontjabol, ha csak egy "csirka" alkalmazod (ahol pl az LPB szerint alacsonyabb a felbontas) akkor annak "felso" es "also" hataran az neki a "kep szele" lene voltakeppen, ezert itt erdekes effekt lephetne fel _VAGY_ ott a kornyezo pixelnel figyelmbe kene venni a max (hires) felbontasut atmappelve kozeletiessel valahogy. Lehet, nem epp erthetoen tudom kifejezni magam ... Szoval, amikor azt irtad, hogy hires-re nem kell alkalmazni, minden masra viszont miert ne, erre celoztam, hogy EP-n nincs globalis videomod, mi van, ha a kepernyo egy resze van mas felbontasban?
Title: Re: EP128emu
Post by: szipucsu on 2016.September.06. 00:03:11
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ú.
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?
Title: Re: EP128emu
Post by: lgb on 2016.September.06. 00:33:32
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.

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.

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

Quote
UI.: Miért jó, hogy van külön EP128emu és külön EP128emu 2.0.9 topik?

Passz :)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 10:25:15
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ő?

Wine alatt viszont nincs ilyen hiba, legalábbis az alapértelmezett MME kimenetet használva (a WASAPI elszáll, de ez lehet Wine bug is). Talán azért, mert a Wine nem támogat minden audio API-t (pl. nincs WDM-KS), és a PortAudio hiba a hiányzók közül érinti valamelyiket. A legjobb lenne új PortAudio DLL-t fordítani az aktuális forrásból, illetve ideális esetben a teljes MinGW csomagot frissíteni. :oops:

További probléma Windows 7 alatti tesztelésnél, hogy az installert csak adminisztrátorként lehet futtatni, azonban utána normál felhasználóként nincsenek ikonok a start menüben, és az emulátor indításakor a hiányzó konfiguráció miatt a (hibásan konzol módúra fordított :oops:) makecfg jelenik meg, ahol az adat file-ok helyét a "Program Files (x86)" alatt manuálisan kell megadni.

Szerk.: az itt található PortAudio csomagból (https://github.com/adfernandes/precompiled-portaudio-windows) (portaudio-r1891-build.zip) a portaudio-r1891-build/lib/Win32/ReleaseMinDependency/portaudio_x86.dll file működik, átnevezve portaudio.dll.0.0.19-re. Egyelőre csak Wine alatt teszteltem, de ott javítja a WASAPI hibát.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 12:48:42
Néhány további lehetséges ötlet a fejlesztésre:

* 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):
- epimgconv
- epcompress
- dtf
- epsndconv
- epvideoconv
- cpccolor

* Win64 verzió fordítása

* 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ámogatja
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 13:15:14
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 :-)
Title: Re: EP128emu
Post by: ergoGnomik on 2016.September.06. 13:19:01
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.

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
Title: Re: EP128emu
Post by: lgb on 2016.September.06. 13:27:06
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

:) :) Jo, mondjuk ebben az esetben mar tenyleg lehet benne racio :)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 16:35:14
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. 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ó.
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 16:42:15
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.

Quote
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.
Title: Re: EP128emu
Post by: szipucsu on 2016.September.06. 17:42:00
* a különböző segédprogramok hozzáadása a csomaghoz
Ez 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.
A cpccolor micsoda? Lehet, arról lemaradtam.

:) :) 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.)
Title: Re: EP128emu
Post by: lgb on 2016.September.06. 18:25:25
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.)

Ja, az talan meg JSep-nel volt, hogy browser alapbol vmi simitast csinalt a canvas-oknal. Aztan Zozo mondta - ha nem o volt bocs - hogy neki inkabb legyen pixeles es latszodjon h mi hogy merre. Mas meg ugye inkabb azt szeretne, hogy menjenek a pixelek a fenebe :) Szoval nehez igazsagot tenni ...
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 19:07:01
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:
- 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 is
- loadROMSegment(segment, fname, offset) - ROM file betöltése a megadott szegmensre, ha a név üres, akkor törli a szegmenst

A Shift+F11 hasznos lehet az eredeti konfiguráció újratöltésére az emulált rendszer esetleges elrontása után. :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 19:21:49
Mindkét megoldás már megtalálható a GitHub verzióban:
Jól hangzik!
EXE-t merre találok? :oops:
Title: Re: EP128emu
Post by: Attus on 2016.September.06. 19:55:22
Néhány további lehetséges ötlet a fejlesztésre:

* 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
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.
Jó, hogy el van hagyatva már évek óta a dotconf, ezzel nincs is egyedül a választékban.
A dotconf -ot, mint külső cuccot az ep128emu -n kívül az UHU csomagkészletéből csak a speechd csoda (Arch-nál a speech-dispatcher (https://www.archlinux.org/packages/extra/i686/speech-dispatcher/)) használja még. Ezt a sopeechhd -t meg az orca gnómos felolvasó progi, meg még pár használja.
Engem nem zavar, ha nincs beleépítve, a most karnbantartandó mintegy 5000 darab UHU-ubk1 csomagok számosságát ez nem is csökkentené, hisz még van olyan, ami használja.
* 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):
- epimgconv
- epcompress
- dtf
- epsndconv
- epvideoconv
- cpccolor
Nem tudom, de szerintem ezek küzül be lehetne építeni egy párat, legalább egybe lenne az egész cucc.

* Win64 verzió fordítása
Ez 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ámogatja
Megfontolandó, 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?
Én arra hajlok, hogy használhatóvá kellne tenni mindegyikkel, legalább részben kompatibilissá, hogy legfeljebb azok, akik lua 5.1 -el tudják csak használni ,a lua 5.3 előnyeiről le kell, hogy mondjanak.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 20:02:43
Jól hangzik!
EXE-t merre találok? :oops:

[attachurl=1]

Ez már remélhetőleg javított PortAudio verziót tartalmaz, illetve próbaként Lua 5.3-at is.
Title: Re: EP128emu
Post by: lgb on 2016.September.06. 20:04:27
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:

https://bintray.com/lgblgblgb/generic/ep128emu
Title: Re: EP128emu
Post by: Attus on 2016.September.06. 20:24:48
Mindig csak ezek az EXE-k :D Hozzavagtam a travis/bintray duohoz, hogy jo-e ... passz:

https://bintray.com/lgblgblgb/generic/ep128emu
Majd Zozo megmondja, hogy milyen!
;-)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 20:24:59
Ez már remélhetőleg javított PortAudio verziót tartalmaz

Ezzel is lefagy, de csak Windowson, csak nekem van ilyen probléma (lehet, hogy driver bug) ?
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 20:35:11
Nálam is, pontosabb nem fagyott, hanem bezáródott.
Title: Re: EP128emu
Post by: DrPrery on 2016.September.06. 20:41:32
Dettó ugyanaz, mint Zozo-nál... (Win7)
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 20:45:56
Mindig csak ezek az EXE-k :D Hozzavagtam a travis/bintray duohoz, hogy jo-e ... passz:

https://bintray.com/lgblgblgb/generic/ep128emu
Viszont ez működik! :-) Érdekes, hogy más is az EXE mérete, mint az István féle verzióban.
Title: Re: EP128emu
Post by: DrPrery on 2016.September.06. 20:52:05
Quote
Viszont ez működik! :-)

Hoppá, nálam is...
Title: Re: EP128emu
Post by: IstvanV on 2016.September.06. 20:58:44
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:
Title: Re: EP128emu
Post by: lgb on 2016.September.06. 21:02:45
Akkor ez a MinGW csomagommal lehet valamilyen probléma, talán ideje lenne az egészet újabbra cserélni. :oops:

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
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.06. 21:08:07
- 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 is
writeROM(0,0) után INTERNAL CHECKSUM ERROR lesz resetnél :-) szóval működik.
Title: Re: EP128emu
Post by: Attus on 2016.September.06. 22:26:03
Nem értem.
:oops:
Ezt a foltot (https://github.com/istvan-v/ep128emu/commit/6277d32dc1e9c621632af38744c2d53964438f34) hol és miképp kell alkalmazni az emulátorhoz?
Meg kellene foltozni vele az fltk -t az emulátor kedvéért?
Vagy csak windózhoz való?
Ha kész flk-1.3.3 bináris libekkel készül az emulátor binárisa, akkor ez utólag szerintem kivitelezhetetlen, hacsak bele nem rakjuk statikusként az egész fltk-t újraforgatva az emulátorba.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.07. 13:55:51
Szerintem en is azzal nyomtam travis-on :-P https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/mingw-win.7z

Akkor talán az eltérő optimalizálás okozhatta (a CPU típusát pentium2-ről pentium3-ra módosítottam) ? Ha igen, akkor az GCC bug is lehet, de az emulátort Wine alatt futtatva nincs hiba. :eek:

Nem értem.
:oops:
Ezt a foltot (https://github.com/istvan-v/ep128emu/commit/6277d32dc1e9c621632af38744c2d53964438f34) hol és miképp kell alkalmazni az emulátorhoz?

Ez csak a képkonvertáló programoknál (epimgconv, p4fliconv) hasznos, és ott is csak GIF formátumú képek konverziójánál bizonyos esetekben. Tehát a patch hiánya nem jelent különösebb problémát.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.09. 22:34:59
Új MinGW (mingw-w64 (https://mingw-w64.org/)) csomagok:

mingw_w64-x86.7z (https://www.dropbox.com/s/a336x3bs1p0gv3t/mingw_w64-x86.7z?dl=0)  (32 bites)
mingw_w64-x64.7z (https://www.dropbox.com/s/ex0zxz7e6bmcb9r/mingw_w64-x64.7z?dl=0)  (64 bites)

GCC/G++ 6.2.0
FLTK 1.3.3
SDL 1.2.15
SDL2 2.0.4
Lua 5.3.3
LuaJIT 2.1.0 beta2
PortAudio r1891 (innen (https://github.com/adfernandes/precompiled-portaudio-windows))
libsndfile 1.0.27

Ez használható már az emulátor GitHub verziójának a fordítására, azonban Linuxon kell még hozzá ez a wrapper is:
[attachurl=1]
illetve erre linkek a többi programhoz (ar, as, c++, cpp, dlltool, g++, ld, nm, objcopy, opjdump, ranlib, strip, windres). Win64-re fordításhoz pedig az "i686" helyett "x86_64".

Installer készítésére továbbra is az NSIS 2.x (https://sourceforge.net/projects/nsis/files/NSIS%202/) használható, azonban a makensis futtatásakor /DWIN64 kell a 64 bites csomaghoz.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.10. 13:54:59
[attachurl=1]
[attachurl=2]
Title: Re: EP128emu
Post by: endi on 2016.September.10. 13:57:22
ezek amúgy most mik? új verzió, amiben van valami új?
Title: Re: EP128emu
Post by: IstvanV on 2016.September.10. 14:27:51
ezek amúgy most mik? új verzió, amiben van valami új?

Különösebb újdonságok nincsenek, csak a 2.0.9.1 verzió óta talált hibák javítása, néhány kisebb debugger (Lua) fejlesztés, és a csomag tartalmaz egy pár segédprogramot is (epimgconv, epcompress, dtf). Ezeken kívül még javítottam a Windows installer több felhasználós rendszer támogatásán, azaz az installert adminisztrátorként futtatva a start menü ikonok most már láthatóak a többi felhasználó számára is, az uninstall pedig eltávolítja az ikonokat. Normál felhasználóként először futtatva az emulátort a makecfg indul el, és remélhetőleg megtalálja a telepítési helyet, így csak két OK kell az indításhoz (továbbra is megjelenik néhány file írási hiba, amiket még javítani kell, de ezektől függetlenül az emulátor működik).

Az újabb fordító kisebb gyorsulást is eredményezhetett, bár ez CPU függő:
2.0.9.1 (pentium3)      850%    2585%
2.0.9.2 (régebbi beta) (https://enterpriseforever.com/ep128emu/ep128emu/msg58008/#msg58008)  960%    2590%
2.0.9.2 x86 (https://enterpriseforever.com/ep128emu/ep128emu/msg58129/#msg58129)             940%    2775%
2.0.9.2 x64 (https://enterpriseforever.com/ep128emu/ep128emu/msg58129/#msg58129)             890%    3010%

Az első oszlopban egy meglehetősen lassú AMD laptop CPU-n mért sebesség látható (Alt+W az IS-BASIC indítása után, szoftveres video módban), a második pedig egy Intel Sandy Bridge CPU.
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.10. 14:34:52
A segédprogramoknál is van újabb CPU-kra optimalizálás?
Title: Re: EP128emu
Post by: IstvanV on 2016.September.10. 14:38:21
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.
Title: Re: EP128emu
Post by: Attus on 2016.September.10. 16:27:16
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 ki lehetne nyugodtan irtani az leendő újabb release -nál a Pentium2 kompatibilitást.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.16. 17:17:20
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

Az újabb GitHub forráskódok már nem biztos, hogy módosítás nélkül működnek a régi MinGW csomaggal, mert az itt (https://enterpriseforever.com/ep128emu/ep128emu/msg58125/#msg58125) található GCC 6.2.0-s csomagot használom a teszteléshez. :oops: Ezzel azonban már 64 bites verzió is fordítható.

32 bites Windows fordítás Linux rendszeren:

Az alábbi wrapper linkek létrehozása (az SConstruct jelenleg csak néhányat használ ezek közül, amelyeket kiemeltem):
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-ar
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-as
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-c++
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-cpp
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-dlltool
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-g++
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-ld
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-nm
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-objcopy
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-objdump
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-ranlib
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-strip
ln -s i686-w64-mingw32-gcc i686-w64-mingw32-windres


PATH beállítása Wine alatt (régi Wine verziókkal ez nem biztos, hogy működik):
wine reg.exe ADD "HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\Environment" /v "PATH" /f /t "REG_EXPAND_SZ" /d "C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\mingw32\\bin"

Fordítás és installer készítése (az NSIS telepítési helye természetesen változhat):
scons win32=1 -j 4
cd installer
wine "C:/Program Files (x86)/nsis-2.51/makensis.exe ep128emu.nsi


64 bites verzióhoz:
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-ar
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-as
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-c++
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-cpp
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-dlltool
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-g++
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-gcc
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-ld
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-nm
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-objcopy
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-objdump
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-ranlib
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-strip
ln -s i686-w64-mingw32-gcc x86_64-w64-mingw32-windres


wine reg.exe ADD "HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\Environment" /v "PATH" /f /t "REG_EXPAND_SZ" /d "C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\mingw64\\bin"

scons win64=1 -j 4
cd installer
wine "C:/Program Files (x86)/nsis-2.51/makensis.exe /DWIN64 ep128emu.nsi


A fent leírt módon fordítható a plus4emu is.

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.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.16. 18:33:52
Beta verziók a GitHub-on:

https://github.com/istvan-v/ep128emu/releases
https://github.com/istvan-v/plus4emu/releases
Title: Re: EP128emu
Post by: Attus on 2016.September.16. 20:08:18
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.

Persze Linuxhoz úgyis majd az illető disztróhoz lett fordítva, ha az 32 bites, akkor az, ha 64 bites, akkor az.

A mi UHU -nk esetében nincs is valódi 64 bites rendszer, azaz csak 64 bites ELF binárisok, csak 64 bites kernel használata lehet a 32 bites binárisokkal.
Más Linuxoknél léteznek tisztán 64 bites megvalósítások, melyek szerintem csak divatból és eladhatóság miatt léteznek.
Lehet, hogy ezen utóbbi meggyőződésem miatt sokan felhorkannak, de én a gyakorlatban semmi különbséget nem látok a 64 bites Arch, Gentoo és Ubuntu telepítményeim gyorsaságát nézve a 32 bites UHU rendszereimhez képest.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.17. 10:55:53
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.

A 64 bites verzió 10-20%-al gyorsabb (ez függ a CPU-tól, fordítási paraméterektől, stb.), Linuxon valójában nagyobbnak tűnik a különbség, mint Windowson. Az x64 utasításkészlet több regiszter használatát teszi lehetővé, így a függvények paraméterei is általában regiszterekben adhatók át, és Linuxon jobb a PIC támogatása (mivel lehetséges az utasításmutatóhoz képest relatív címzés):
Code: [Select]
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                    ret
A 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).
Title: Re: EP128emu
Post by: Attus on 2016.September.17. 16:12:07
Köszönöm a felhomályosítést, ezek szerint tévedtem. :oops:
[offtopic]
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?
Lehet, hogy egyszerűbb lenne a vasat 5-10 -% -al gyorsabbra cserélni.
Most állunk át libjpeg -ről libjpeg-turbo -ra, ami máris sokkal nagyobb nyereség.[/offtopic]
Title: Re: EP128emu
Post by: IstvanV on 2016.September.19. 10:49:29
Néhány EnterMice (http://wiki.enterpriseforever.com/index.php/EnterMice) kérdés: :oops:

- az adatátvitel működése: ha a B7h port 1. bitje változik, akkor az EXT1 joystick bemeneten megjelenik a következő 4 bit (egy byte-on belül a felső 4 bit az első), és ha hosszú ideig (> 1500 us ?) nincs adat kérés, akkor az megszakítja az adatátvitelt ?
- a puffer végén túli olvasásnál minden byte 0 ?
- az adatbitek hozzárendelése a joystick irányokhoz: tűz = bal gomb (1 = lenyomva ?), fel = b0/b4, le = b1/b5, bal = b2/b6, jobb = b3/b7 ?
- a "J" (olvasás a B6h port 0. bitjén) és "K" (B6h port 1. bit) oszlop módok közötti különbség fontos, vagy a gyakorlatban elég lehet csak az egyiket emulálni ? 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 ?
- a BoxSoft és egyéb régebbi protokollok emulációjának van-e különösebb gyakorlati haszna, vagy elég csak az EnterMice, ami a korábbi protokollok által visszaadott információt bővíti, de elvileg kompatibilis ? Bár úgy látom, az EnterMice módban az extra 4 byte nem tartalmaz igazán hasznos információt az "Extended MSX"-hez (4 byte-os puffer) képest, csak hardver verziót és eszköz azonosítót, tehát talán az utóbbit lenne a legcélszerűbb emulálni. De az EnterMice is egyszerű lenne, ha pontosan tudnám, hogy mit kell visszaadni a 4 byte bővítésben.
- 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 wiki szerinti Btn3, Btn4, Btn5 melyik PC-s egér gomboknak felel meg ?

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?

Az UHU esetében talán nem, de ha valaki már 64 bites disztribúciót használ, akkor nincs különösebb hátránya a 64 bites emulátornak, és ha nem is nagy a gyorsulás, a támogatását viszonylag könnyű volt megvalósítani (Linuxon már az első pre-2.0.0 "beta" verziók is 64 bit kompatibilisek voltak 2006-ban, csak Windowson újdonság az ilyen csomag). :)
Title: Re: EP128emu
Post by: lgb on 2016.September.19. 11:20:59
Néhány EnterMice (http://wiki.enterpriseforever.com/index.php/EnterMice) kérdés: :oops:

Jajj :) Mennyit szivtam en ezzel (de a letobb problema az volt, hogy felfogjam, mert nagyon nem ertettem az elejen ...), de sajnos a reszletek mar nem remlenek, max a forraskod talan hasznos lehet:

https://github.com/lgblgblgb/xep128/blob/master/input.c

Amugy talan angol Xep128 forumban volt sok okitas Gflorez mouse wizard baratunktol :) Amugy nem mondom, hogy az en implementaciom fuuuu de jo, vagy barmi, igazabol Gflorez szeretett volna ilyen dolgokat, en meg nem nagyon tiltakoztam :) es alapvetoen az o instrukcioi alapjan irogattam (illetve neha a hw szerzoje is hozzaszolt a kerdesekhez).

Latom, kedvet kaptal az ep128emu projecthez ujra :) :)

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

Szerintem ennek a kerdesnek nincs ertelme ... Vagy en nem ertem a kerdest :) Az eger mozog, o nem tud semmit semmifele kepernyorol vagy kepernyo felbontasrol ... azt, hogy a kepernyon ez minek felel meg, az a software-en mulik csak (ami a kapott elmozdulas alapjan kirak pl egy mouse pointer-t, azt hogy hogy csinalja, az az o maganugye, hasznalhatja kozvetlenul az elmozdulas erteket persze, de akar skalazhatja is, vagy megvalosithat intelligens modot, amikor pl nem linearis kapcsolat van kozottuk, azaz: finoman huzva az egeret "pontosabb" de "lassabb", gyorsabban meg hat gyorsabb), semmi mason. Amugy, volt kollega aki nagyon azt szerette volna, hogy legyen a PC-s egerkurzor Xep128-ban "az" egerkurzor, es igen nehez volt elmagyarazni, hogy ez elvi lehetetlenseg, mivel nincs kapcsolat az eger elmozdulas es a kepernyo koordinatak kozott. Szoval nyilvan ez Xep128-ban is ugy van, hogy mouse grab mod, eltunik a PC-s egerkurzor, aztan SDL-ben mouse movement esemenyeket figyelek csak (koordinatak nem erdekelnek mert azt nem lehetseges kozvetlenul lekepezni), es abbol emulalom le. Ez kb olyan mint a joystick. Abbol, hogy jobbra, balra, stb huzod szegenyt, meg nem kovetkezik, hogy az EP kepernyojen hol van a mozgatando "alakzat", ahogy az sem, hogy pontosan mennyinek felel meg valami a kepernyon (max azert mas a pelda, mert joy eseten egy irany az kb digitalis, mig eger eseten "gyujti" az elmozdulast, es utana egyben kiolvasod mint delta, a legutobbi olvasas ota). Bocs, ha ennyit irok, vagy keptelen vagyok kifejezni magam normalisan, hogy mit is akarok mondani :D :D

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 (viszont nem ertem ez egy emulatornak miert fontos, szerintem semennyire ... o ugyis a hw-t emulalja csak). De ez persze minden sw-nel mas es mas, pl SymbOS nyilvan sajat mouse rutint hasznal, ott megint mas lesz ...

Sot - imho+afaik - az eger altal atadott elmozdulas (delta X, Y) ertekek meg egerrol egerre sem ugyanazok, es aztan vegkepp nincs koze semmifele kepernyo koordinata X es Y-hoz.

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

Ez jo kerdes, szerintem nem art, mert ha tulcsordul, az fura lenne, foleg ha elojelet valt.

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

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.
Title: Re: EP128emu
Post by: gflorez on 2016.September.19. 12:03:21
Persze Én szívesen a választ, de angolul kérem.

--------------

Of course I am eager of answer, but in English please.
Title: Re: EP128emu
Post by: lgb on 2016.September.19. 12:18:29
Of course I am eager of answer, but in English please.

I've just mentioned that you gave me several useful tips in the English Xep128 topic in a quite patient way, even if I were quite dumb at the beginning to realize the "big picture" :) Maybe that can be useful for others too, who wants to understand the details and not bothered by reading my "sometimes hard way to realize things"-style posts as well :)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.19. 12:58:42
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

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?

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

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.
Title: Re: EP128emu
Post by: gflorez on 2016.September.19. 13:35:35
Ok, I am very happy that he is interested on mouse controller to implement on his EP128emu.

The hardest part is to understand how and when the data is put on the joystick ports by the interfaces(Neos-Boxsoft, MSX, EnterMice). It took me two years, you only a week. Maybe IstvanV will understand it in only days or hours....

Resolution is not important on the MSX approach, the mouse only returns a delta of the position, the increments-decrements on 8 bit signed, so the min movement is a pixel, and the max 128, probably not reachable in a 1/50 of second.

The Ps/2 mouse works the same, with deltas, but on 9 bit signed. The eight bit is discarded.

Then, the better sensitivity of modern mouses(or the host OS mouse) benefit directly the PS/2->MSX approach of the EnterMice.

The wheel is only a pulse counter.

You have two "hard wired" buttons and three "software" buttons, five in total.

-----
Zozo proposed to better use K, because until now that line has been unused. Boxsoft uses J and it conflicts with Joy1 on games and apps that read all controls at the same time. This is because the MSX protocol puts "imposible" movements on the direction switches. It is not armful, but freezes the app, for example EPDOS or the ManicMiner Spectrum conversion.

 
Title: Re: EP128emu
Post by: lgb on 2016.September.19. 14:00:09
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.

I think, it's more a "try it" thing :) At least I've done that, implementing and trying the result how it "feels". I cannot say there is an 'exact' value. However what I found, that using Xep128 in window and full screen mode, the "scaling" between the mouse-proto-level dx dy should be modified somewhat compared to the situation when it's fullscreen, since in window mode mouse "feels" too sensitive, for obvious reason. Maybe it's of course not the window/full screen topic at all, but on the fact, how big the emulated screen is (I mean on the PC monitor, that is), currently.

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

I don't think it would work in general ... Maybe, but for example EP software may be "lazy" to do the check for a while (disk I/O for longer, no mouse check meanwhile) so there will be a difference already. Also, I don't think there is a "standard" of mapping mouse dx/dy values to screen dx/dy, but who knows ... And for me, I would even annoying to see the mouse PC pointer and the EP "drawn" mouse pointer at the same time, to be honest :) That's true, that you can disable (PC) mouse pointer just for the emulator window, and you can try "not to grab it", ie you can "pull out" mouse from the emulator window, and you can use it normally in other windows on your host OS, maybe, that would be a benefit ...

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

Though, I have code for mouse wheel, honestly, I haven't even tried that ever :)

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

Honestly, I am even lazy to understand my own code in Xep128 emu :) But my approach was something like checking "mouse pulses" (what is sent over the serial port) and if there is not so much, I treat the read as "joystick scan" otherwise "mouse scan". On joy-1 conflicting I simply use a "veto" variable that "joy is OK". So maybe, it's OK, that you replicate for both of J and K column, and you just need to take care this "veto" stuff in case of a conflict between joy and mouse.

My work was also some kind of try&error process, for example SymbOS didn't worked without some added work-around, what I can't remember too much in details :) I mean, if you do this "heuristic" logic, as SymbOS try to "detect" mouse and maybe too "short" period it was for Xep128 to "judge" it as a mouse scan. And if SymbOS fails to "find mouse" it won't use it then, even if it would work on the next msec, for example ...
Title: Re: EP128emu
Post by: pear on 2016.September.19. 14:41:38
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.
In other words, is issued a 9-bit value divided by two.
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.19. 16:17:57
I think current days enough emulate EnterMice mode only. All old programs use the MOUSE.XR extension which is already updated for EM. Then no conflict with Ext 1 joy.
Pear can write the exact timing of EM.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.20. 20:01:40
There is some mouse emulation code in ep128emu on GitHub now, but it still needs more work. :oops:
Title: Re: EP128emu
Post by: gflorez on 2016.September.20. 21:38:22
Is there a Win executable to try?
Title: Re: EP128emu
Post by: IstvanV on 2016.September.21. 09:38:38
Is there a Win executable to try?

I will create one soon once the mouse emulation is in a more usable state, but I still have a few questions:
- when the mouse I/O is not active (not within 1500 us of the last change of the RTS bit), should the mouse buttons still appear on port B6h? Currently, I make all mouse input to port B6h disabled (data bits = 1) when no data is requested, but maybe some software simply checks the state of the fire button outside the mouse I/O routine?
- is it safe to use the full range (-128 to 127) for the X/Y movement values? I am getting erratic movement in EP software if I move the pointer too fast, as if there was an overflow somewhere, not sure if this is in the emulator or the emulated software
- are the second fire buttons of the external joysticks useful in practice? I have added these in the DAVE input code, but they are not available yet in the configuration
- for bytes 4 to 7 in the data buffer, I currently return 0x44, 0x14, 0x19, 0x5D, these values are from xep128. Are the values correct (maybe the PS/2 ID could be changed to be different from xep128), and would it make a difference in practice if the emulator did not send them?
- the mouse wheel byte also includes the horizontal wheel in the upper nibble, which is not implemented in hardware yet according to the documentation. Does that break any software?
Title: Re: EP128emu
Post by: pear on 2016.September.21. 11:03:50
In EnterMice:
First: No. After this time buttons bits are set to 1.
Second: Yes, it's safe. If overflow appeared, movements are set the max or min value.
Third: I have no idea ;)
Fourth: Not very important.
Fifth: In any case, you can clear the unused half byte.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.21. 11:10:28
Fifth: In any case, you can clear the unused half byte.

It seems that MOUSE.XR (the version linked from the wiki) tests the 7th bit of the mouse wheel byte to determine the direction of scrolling, so the implementation that includes the horizontal wheel does break the driver. I removed support for the horizontal wheel, and the data byte is now sign extended from the lower 4 bits.
Title: Re: EP128emu
Post by: gflorez on 2016.September.21. 11:22:38
1- EnterMice enters to a wait state if there is no request on the RTS line, and then it doesn't sends information to the direction bits of the B6h port nor to the Fire bits.  But it activates itself very fast if a change in RTS is detected. This is because EnterMice is a PS/2 to MSX software converter(on a chip), and then the hardware buttons are emulated. This was not the case of the Neos-Boxsoft approach, that wired directly the buttons of the mouse to the EP.

2- Yes, some software produce jumps in the movement, other run smoothly, but I think that it is not produced by the range, as the mouse routine is read every 1/50 sec. It is improbable to reach -128 or 127 even moving very fast the mouse, I think, but I can be wrong, of course.

3- Secondary wired was already possible with the Boxsoft approach, but the Neos mouse lacked the wire as it was used for synchronism(RTS). On the EnterMice approach the secondary mouse button has been put even if no program still uses it.

Especial case are the three software buttons and wheel. To make the interface's software, Pear has followed the extended MSX protocol from Prodatron(SymbOS developer) and NYYRIKKI(MSX developer), that add that new information. This not harm the old software, as the buttons an wheel information go on other lecture cycles. Later, Pear has extended more the protocol to put EnterMice information.

SymbOs still doesn't uses more than the main button, but soon it will do, like other ports of the OS. Is for it that all that buttons are implemented. Of course they are accessible on Exos by the Mouse driver(a new system var has been created) or in the hardware if a developer wants to implement them on new software.

4- These are the extra cycles added by Pear to the MSX protocol, and still there are space to put more information... Basically, what they add is information for the user-developer, not important for its operation. That bytes return type of mouse as detected by the interface, version of hardware and version of software. The last is Pear sign.

As you only have to emulate the complete mouse(5 buttons and wheel), leave that bytes untouched.

5- As I said, still there isn't software that use the wheel. Horizontal wheel is an idea of Pear, not present on Prodatron extended MSX protocol. Actually the upper nibble is not used, but  I must follow Prodatrons's protocol, so I take the two nibbles as a whole byte. I later can change that behaviour easily.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.21. 11:26:58
This program works now with the GitHub version after loading MOUSE.XR:
[attachurl=1]

Converting the coordinates of the pointer still needs to be improved, since FLTK does not provide relative movement information, only the position of the pointer within the emulator window, so it can reach the edges of the window and then in the emulated machine it stops moving. :oops: The 4th and 5th buttons do not seem to work, but that might be because on the mice I have they send keyboard macros, rather than actual mouse button events.
Title: Re: EP128emu
Post by: pear on 2016.September.21. 11:28:49
4- {...} The last is Pear sign.
Exactly there are the EnterMice serial number.
Title: Re: EP128emu
Post by: gflorez on 2016.September.21. 14:56:51
It seems to work with the EGI, not with SymbOS as it is a hack that needs the secondary button to work as the main one.


I can say now that on EP128emu the CM2000 game works perfect....
Title: Re: EP128emu
Post by: IstvanV on 2016.September.21. 15:26:49
Win32 test version (now with fixed mouse wheel :oops:):
[attachurl=1]

Recording mouse events to demo files is also supported, but it may not be entirely reliable yet:
[attachurl=2]
Title: Re: EP128emu
Post by: gflorez on 2016.September.21. 18:18:28
IstvanV, I am very grateful to you to emulate the EnterMice. Also to LGB for give you the Xep code.

EnterMice is a great piece of hardware that cannot be evaluated without seeing it working.
Title: Re: EP128emu
Post by: gflorez on 2016.September.21. 18:51:51
Here you have, KM mouse emulated with EnterMice. SPE128emu running as a Rom inside EP128emu.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.22. 10:46:34
I tested a few more programs from the EnterMice wiki (http://wiki.enterpriseforever.com/index.php/EnterMice#List_of_mouse_compatible_programs_up_to_date):

CM2000, PASZIANS.COM, SPEmu128 - these work fine in ep128emu with mouse input
PaintBox - works after loading MOUSE.XR and setting EnterMice mode with SET 189,4
SWAP - moving the pointer works, but the button does not because the game tests the state of the EXT1 fire buttons outside the 1500 us time the emulator allows for mouse I/O after the RTS bit changes. Pressing the actual EXT1 fire button does work, however :)
SymbOS - does not work, it expects mouse input on column J, which is not supported by ep128emu. Perhaps it can be configured somehow to use native EnterMice mode?
EGI - works after replacing the :VAR 189 0 with :VAR 189 4 in EXDOS.INI
EDC Windows - it works, but because of the low horizontal sensitivity, the pointer will frequently hit the left/right edges of the emulator screen

While FLTK does not support mouse grabbing and relative motion, I may try using native APIs (XWarpPointer() on Linux and SetCursorPos() on Windows) in the "fullscreen with no menu bar" mode to center the pointer whenever it gets too close to the edges.
Title: Re: EP128emu
Post by: gflorez on 2016.September.22. 10:54:37
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?.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.22. 11:33:21
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?.

With the modified version, moving the pointer works for me, but maybe the detection is not always reliable. The buttons do not work for the same reason as in SWAP, they are tested outside the 1500 us timeout. A simple hack to work around that is to swap the two calls at 0598h and 059Bh:
Code: ZiLOG Z80 Assembler
  1. .   0598  CD DC 27     CALL  27DC
  2. .   059B  CD D6 2A     CALL  2AD6
replaced with:
Code: ZiLOG Z80 Assembler
  1. .   0598  CD D6 2A     CALL  2AD6
  2. .   059B  CD DC 27     CALL  27DC
so that the fire buttons are tested after receiving the mouse data, while the 1500 us timer is still active. To fix the left/right button issue, this code needs to be changed:
Code: ZiLOG Z80 Assembler
  1. .   283A  F6 EF        OR    EF
  2. .   283C  21 B4 27     LD    HL, 27B4
  3. .   283F  77           LD    (HL), A
  4. .   2840  3A B1 27     LD    A, (27B1)
  5. .   2843  CB 47        BIT   0, A
  6. .   2845  20 02        JR    NZ, 2849
the modified version that tests the left button instead:
Code: ZiLOG Z80 Assembler
  1. .   283A  17           RLA
  2. .   283B  F6 EF        OR    EF
  3. .   283D  21 B4 27     LD    HL, 27B4
  4. .   2840  77           LD    (HL), A
  5. .   2841  3A B1 27     LD    A, (27B1)
  6. .   2844  1F           RRA
  7. .   2845  38 02        JR    C, 2849
Title: Re: EP128emu
Post by: gflorez on 2016.September.22. 12:33:01
I did my hack with an Hex editor on the executable, I don't have the  disassembled code.

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.

Prodatron has promised a complete rework of the application with all buttons and wheel, so no problem.
Title: Re: EP128emu
Post by: gflorez on 2016.September.22. 13:16:49
Here is the fixed SymbOS, now it reacts to right button as main.

Title: Re: EP128emu
Post by: IstvanV on 2016.September.22. 15:23:21
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.

Actually, my second hack does not change the size of the code: while it does add one more RLA instruction, it also optimizes a test of the lowest bit of A by replacing a BIT 0, A and JR NZ with RRA and JR C. So, with that optimization it is the same size and even the same number of Z80 cycles as before.
Title: Re: EP128emu
Post by: gflorez on 2016.September.22. 15:42:10
Thank you very much. I'm not a programmer and so I didn't count the bytes but the instructions.....

You did the complete work for me.

Title: Re: EP128emu
Post by: IstvanV on 2016.September.23. 14:25:16
I found a possible bug in MOUSE.XR, although it may also be considered a feature. :) In the following routine, the movement values received from the mouse are multiplied by 2 using 8 bit arithmetic, but this overflows if the original value is outside the range -64 to 63. This can be reproduced in the emulator, if the pointer is moved very fast, then it "bounces" back from the edge of the screen when the overflow occurs.
Code: ZiLOG Z80 Assembler
  1. .   C646  2A 36 C9     LD    HL, (C936)
  2. .   C649  3A 41 C9     LD    A, (C941)
  3. .   C64C  FE 02        CP    02
  4. .   C64E  38 05        JR    C, C655
  5. .   C650  FE FF        CP    FF
  6. .   C652  30 01        JR    NC, C655
  7. .   C654  87           ADD   A, A
  8. .   C655  B7           OR    A
  9. .   C656  F2 72 C6     JP    P, C672
  10. .   C659  ED 44        NEG
  11. .   C65B  5F           LD    E, A
  12. .   C65C  16 00        LD    D, 00
  13. .   C65E  19           ADD   HL, DE
  14. .   C65F  22 36 C9     LD    (C936), HL
  15. .   C662  ED 5B D4 C7  LD    DE, (C7D4)
  16. .   C666  1B           DEC   DE
  17. .   C667  B7           OR    A
  18. .   C668  ED 52        SBC   HL, DE
  19. .   C66A  38 14        JR    C, C680
  20. .   C66C  ED 53 36 C9  LD    (C936), DE
  21. .   C670  18 0E        JR    C680
  22. .   C672  16 00        LD    D, 00
  23. .   C674  5F           LD    E, A
  24. .   C675  B7           OR    A
  25. .   C676  ED 52        SBC   HL, DE
  26. .   C678  30 03        JR    NC, C67D
  27. .   C67A  21 00 00     LD    HL, 0000
  28. .   C67D  22 36 C9     LD    (C936), HL
  29. .   C680  2A 38 C9     LD    HL, (C938)
  30. .   C683  3A 42 C9     LD    A, (C942)
  31. .   C686  FE 02        CP    02
  32. .   C688  38 05        JR    C, C68F
  33. .   C68A  FE FF        CP    FF
  34. .   C68C  30 01        JR    NC, C68F
  35. .   C68E  87           ADD   A, A
  36. .   C68F  B7           OR    A
  37. .   C690  F2 AE C6     JP    P, C6AE
  38. .   C693  ED 44        NEG
  39. .   C695  5F           LD    E, A
  40. .   C696  16 00        LD    D, 00
  41. .   C698  19           ADD   HL, DE
  42. .   C699  22 38 C9     LD    (C938), HL
  43. .   C69C  ED 5B 11 C0  LD    DE, (C011)
  44. .   C6A0  CB 23        SLA   E
  45. .   C6A2  CB 12        RL    D
  46. .   C6A4  1B           DEC   DE
  47. .   C6A5  B7           OR    A
  48. .   C6A6  ED 52        SBC   HL, DE
  49. .   C6A8  D8           RET   C
  50. .   C6A9  ED 53 38 C9  LD    (C938), DE
  51. .   C6AD  C9           RET
  52. .   C6AE  16 00        LD    D, 00
  53. .   C6B0  5F           LD    E, A
  54. .   C6B1  B7           OR    A
  55. .   C6B2  ED 52        SBC   HL, DE
  56. .   C6B4  30 03        JR    NC, C6B9
  57. .   C6B6  21 00 00     LD    HL, 0000
  58. .   C6B9  22 38 C9     LD    (C938), HL
  59. .   C6BC  C9           RET
Title: Re: EP128emu
Post by: gflorez on 2016.September.23. 15:02:56
You are right! I have not though about it....

That modification of the mouse driver, version 1.1, was found on the EGI disks. It is not present on the former versions known until that moment.

In fact this modification was promised in the review about Paintbox in the only known issue of the ECI magazine (http://url=http://enterprise.iko.hu/magazines/ECI_No1.pdf), page 17.

I will try to fix it soon.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.23. 19:01:14
Here is my attempt at a fixed version of the above routine, it is shorter than the original, but it may be possible to write it better, and I did not test it extensively yet: :oops:
Code: ZiLOG Z80 Assembler
  1.         org     0c646h
  2.  
  3.         ld      hl, (0c936h)            ; HL = X coordinate
  4.         ld      a, (0c941h)             ; A = X motion
  5.         ld      e, a
  6.         rla
  7.         sbc     a, a
  8.         ld      d, a                    ; sign extend to 16 bits
  9.         ld      a, e
  10.         inc     a
  11.         cp      3
  12.         jr      c, l1                   ; -1 to +1?
  13.         sbc     hl, de
  14. l1:     or      a
  15.         sbc     hl, de
  16.         ld      de, (0c7d4h)            ; DE = width
  17.         ld      a, l
  18.         cp      e
  19.         ld      a, h
  20.         sbc     a, d
  21.         jr      c, l2                   ; X not out of range?
  22.         cp      80h
  23.         sbc     hl, hl                  ; X < 0: X = 0, X >= W: X = -1
  24.         jr      nc, l2
  25.         add     hl, de                  ; X = W - 1
  26. l2:     ld      (0c936h), hl
  27.         ld      hl, (0c938h)            ; HL = Y coordinate
  28.         ld      a, (0c942h)             ; A = Y motion
  29.         ld      e, a
  30.         rla
  31.         sbc     a, a
  32.         ld      d, a                    ; sign extend to 16 bits
  33.         ld      a, e
  34.         inc     a
  35.         cp      3
  36.         jr      c, l3                   ; -1 to +1?
  37.         sbc     hl, de
  38. l3:     or      a
  39.         sbc     hl, de
  40.         ex      de, hl
  41.         ld      hl, (0c011h)            ; height / 2
  42.         add     hl, hl
  43.         ex      de, hl                  ; DE = height
  44.         ld      a, l
  45.         cp      e
  46.         ld      a, h
  47.         sbc     a, d
  48.         jr      c, l4                   ; Y not out of range?
  49.         cp      80h
  50.         sbc     hl, hl                  ; Y < 0: Y = 0, Y >= H: Y = -1
  51.         jr      nc, l4
  52.         add     hl, de                  ; Y = H - 1
  53. l4:     ld      (0c938h), hl
  54.         ret
Title: Re: EP128emu
Post by: gflorez on 2016.September.23. 19:13:45
Ok thanks. I will test it later at home.

I work with a disassembly of the driver, so better if shorter the code.

Surely your fix is much better than what I could do...

Title: Re: EP128emu
Post by: IstvanV on 2016.September.23. 21:05:48
Another new beta version / újabb beta verzió: :)
[attachurl=1]
[attachurl=2]

- the second and third joystick fire buttons are now configurable via the GUI, and also work in CPC emulation mode
- new configuration options for the mouse sensitivity, separately for X and Y in the range 0.5 to 2.0
- in fullscreen mode with no menu bar, mouse grabbing is simulated using native X11 or Win32 API functions

- a második és harmadik EXT1/EXT2 tűz gombok a grafikus felületen konfigurálhatók, és működnek CPC módban is
- állítható egér érzékenység, külön a vízszintes és a függőleges irányban 0.5 és 2.0 között
- teljes képernyős menü nélküli módban az X11 vagy Win32 API közvetlen használatával javítja az egér emulációt, kevesebb problémát okoz ha a mutató eléri az emulátor ablak szélét (ilyenkor automatikusan visszaugrik középre)
Title: Re: EP128emu
Post by: Ep128 on 2016.September.23. 22:34:12
... de mind ez miért nem 2.1 most már? :-)
Title: Re: EP128emu
Post by: gflorez on 2016.September.24. 08:08:38
Good job. You have have though in all.

I will fix soon EDC Windows horizontal sensitivity.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.25. 09:51:16
A ROM csomagot valószínűleg ideje lenne frissíteni :oops:, de ehhez össze kellene gyűjteni az aktuális verziókat. Jelenleg ezek a file-ok találhatók a csomagban:

   32768  Defl:N    19981  39% 2010-05-11 22:15 0c4526fc  asmon15.rom
   16384  Defl:N    12322  25% 2008-12-03 21:46 1228de34  basic20.rom
   16384  Defl:N    12444  24% 2008-12-03 21:46 55f96251  basic21.rom
   16384  Defl:N    10964  33% 2008-12-03 21:46 6999d6a3  brd.rom
   32768  Defl:N    25531  22% 2010-01-23 15:46 40852f25  cpc464.rom
   32768  Defl:N    26122  20% 2010-01-23 15:46 9e827fe1  cpc6128.rom
   32768  Defl:N    26095  20% 2010-01-23 15:46 9ab5a036  cpc664.rom
   16384  Defl:N    10659  35% 1995-11-15 07:22 1fe22ecd  cpc_amsdos.rom
   16384  Defl:N    13055  20% 2008-12-03 21:46 2a4a2dd4  cyrus.rom
   16384  Defl:N    10623  35% 2008-12-03 21:46 67ed9956  ep-plus.rom
   32768  Defl:N    23402  29% 2009-07-09 20:35 bd503eeb  epd19hft.rom
   32768  Defl:N    23297  29% 2009-07-09 20:36 9a0bd9b2  epd19uk.rom
   32768  Defl:N    23286  29% 2009-06-29 19:56 7eb63e25  epdos_z.rom
   16384  Defl:N      677  96% 2009-12-22 14:37 4b31ed3a  epfileio.rom
   16384  Defl:N    11152  32% 2008-12-03 21:46 e1af230c  esp.rom
   16384  Defl:N    13328  19% 2009-05-07 22:29 e1e4a2ef  exdos10.rom
   32768  Defl:N    14079  57% 2009-12-25 12:33 e0135929  exdos13.rom
   32768  Defl:N    24067  27% 2009-12-25 12:25 95c5a5e7  exdos13isdos10esp.rom
   32768  Defl:N    24126  26% 2009-12-25 11:53 ac6f2072  exdos13isdos10hun.rom
   32768  Defl:N    26627  19% 2010-05-08 20:43 b3d4d8d3  exos20.rom
   32768  Defl:N    26823  18% 2010-05-08 20:45 34284877  exos21.rom
   65536  Defl:N    42754  35% 2008-12-03 21:46 c82e699f  exos22.rom
   65536  Defl:N    43290  34% 2008-12-03 21:46 24838410  exos23.rom
   65536  Defl:N    43902  33% 2010-05-08 21:32 9525a251  exos232esp.rom
   65536  Defl:N    43722  33% 2010-05-08 21:32 0e8ac476  exos232hun.rom
   65536  Defl:N    43701  33% 2010-05-08 21:32 f99fc840  exos232uk.rom
   32768  Defl:N    18333  44% 2008-12-03 21:46 1753d49a  fenas12.rom
   16384  Defl:N    11978  27% 2008-12-03 21:46 18b8f121  forth.rom
   32768  Defl:N    18226  44% 2008-12-03 21:46 3c405abc  genmon.rom
   32768  Defl:N    17270  47% 2008-12-03 21:46 3cd4b5cb  heass10hfont.rom
   32768  Defl:N    17076  48% 2008-12-03 21:46 dea94a5c  heass10uk.rom
   32768  Defl:N    17198  48% 2008-12-03 21:46 c96ea13a  heassekn.rom
   16384  Defl:N    11246  31% 2008-12-03 21:46 596ab6d6  hun.rom
   16384  Defl:N     3465  79% 2010-01-23 15:46 a62c75d6  ide.rom
   32768  Defl:N    18469  44% 2010-10-17 15:22 ab810f33  iview.rom
   16384  Defl:N    11098  32% 2008-12-03 21:46 1d75ab53  lisp.rom
   32768  Defl:N    14383  56% 2008-12-03 21:46 eba6027c  pascal11.rom
   65536  Defl:N    33246  49% 2008-12-03 21:46 c8fcf3ae  pasians.rom
   16384  Defl:N    11684  29% 2010-12-20 23:40 9813835d  tpt.rom
   32768  Defl:N    18184  45% 2009-07-10 22:41 d75ece67  zt18ekn.rom
   32768  Defl:N    18334  44% 2009-07-10 22:41 76c9dbf6  zt18hfnt.rom
   32768  Defl:N    18275  44% 2009-07-10 22:42 4f386fc8  zt18hun.rom
   32768  Defl:N    18038  45% 2009-07-10 22:41 5378d312  zt18uk.rom
   32768  Defl:N    24147  26% 2010-01-23 15:46 2cbe8995  zx128.rom
   32768  Defl:N    18296  44% 2005-12-24 11:12 99a8ec89  zx41.rom
   16384  Defl:N    12204  26% 2010-01-23 15:46 ddee531f  zx48.rom
Title: Re: EP128emu
Post by: Lacika on 2016.September.25. 10:10:02
A pascal11.rom szerintem már felesleges. pasians.rom-ból van új, egeres.
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.25. 15:09:15
Ha hazaertem a hegymaszasbol, akkor osszeszedem.
Title: Re: EP128emu
Post by: geco on 2016.September.25. 17:24:33
:smt041
Hamarosan én is használom az egeres EP128emut. :)
Title: Re: EP128emu
Post by: geco on 2016.September.26. 18:51:37
Kúúúl, megy az egér, és a zajcsatornás szűrős cucc is fasza.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.27. 18:23:53
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?
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.27. 18:38:48
Szerintem én voltam, azon az alapon, hogy egyébként meg CMOS-ként müködik (nem bugos).
A konfigurálhato lenne legjobb.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.27. 18:49:48
Szerintem én voltam, azon az alapon, hogy egyébként meg CMOS-ként müködik (nem bugos).

Valóban, bár a nem bugos Z80 miatt nem valószínű, hogy hibásan működnének programok, az OUT (C), 0 helyett OUT (C), 255 viszont könnyen okozhat problémát, mivel a gépeket eredetileg NMOS CPU-val gyártották.
Title: Re: EP128emu
Post by: lgb on 2016.September.28. 01:22:31
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.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.28. 10:21:06
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. :)
Title: Re: EP128emu
Post by: lgb on 2016.September.28. 14:07:16
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. :)

Lehet, nem a te otleted volt, de magam vedelmeben, en ezt tuti nem irtam volna at csak ugy magamtol :) :)
Title: Re: EP128emu
Post by: IstvanV on 2016.September.29. 11:40:35
Néhány újabb javítás a GitHub forráskódban:
- az egér és joystick gombok emulációja módosítva, most már működik a SWAP
- a debuggerben az R regiszter kezelése hibás volt, nem vette figyelembe, hogy a 7. bit külön változó
- az "érvénytelen" DD/FD prefixek (ezek gyakorlatilag NOP utasítások amelyek után nem történhet megszakítás) időzítése javítva, eddig ezek 2 M1 ciklust használtak. Bár nem valószínű, hogy ennek sok jelentősége volt

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. Más ROM-ok nem frissültek 2011 óta, például EXOS, EXDOS, EPDOS, ZozoTools, vagy IDE? Az ep128.hu-n remélhetőleg az aktuális verziók találhatók, így ott megnézhetem, miből van újabb. Találtam is például EXOS 2.4-et és EXDOS 1.4-et, ezeknek van valamilyen előnye emulátoron a korábbi verziókhoz (2.32 és 1.3) képest?
Title: Re: EP128emu
Post by: IstvanV on 2016.September.29. 20:05:46
[attachurl=1]
[attachurl=2]

A fentieken kívül a FILE: most már támogatja az EXOS 10 hívásokat, és a :DEF_DEV_FILE file kezelő eszköznek állítja be. Azonban a megfelelő működéséhez az epfileio.rom-ot is frissíteni kell, az új verzió (https://github.com/istvan-v/ep128emu/raw/master/roms/epfileio.rom) ugyan megtalálható az installerben, de telepítés közben a letölthető ROM csomagban található régi file felülírhatja.
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.29. 20:53:19
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:

Quote
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.
Erről van szó. (https://enterpriseforever.com/programozas/exdos-283/msg38049/#msg38049)

START parancs is javítva lett EP64-en. (https://enterpriseforever.com/programozas/exdos-283/msg38517/#msg38517) (A konkrét javítás) (https://enterpriseforever.com/programozas/exdos-283/msg38537/#msg38537)

További változások. (https://enterpriseforever.com/programozas/exdos-283/msg38606/#msg38606)

EXDOS.INI kezelés (https://enterpriseforever.com/programozas/exdos-283/msg41674/#msg41674) is fejlesztve lett, tekintettel a fix háttér tárak terjedésére.

IDE-s konfigba mindenképpen 1.4 kell, egyébként meg ajánlott :-)
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.29. 20:58:54
EPDOS 1.7 2012 (https://enterpriseforever.com/programozas/epdos-fejlesztese/msg27078/#msg27078)
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.29. 21:04:41
Aktuális ZT csomag.
Title: Re: EP128emu
Post by: IstvanV on 2016.September.30. 13:10:48
Köszönöm, az új ROM-okat beépítem a csomagba, bár a feltöltéssel még lehetnek problémák (https://enterpriseforever.com/hibabejelento/ep128emu-enterpriseforever-com-login/). :oops: 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)?

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? A régi (1.3) EXDOS ROM-ok ezek:
- exdos13.rom: angol és német hibaüzenetek, nincs IS-DOS: csak német konfigurációkhoz?
- exdos13isdos10esp.rom: angol és spanyol, tartalmaz IS-DOS-t: spanyol konfigurációkhoz?
- exdos13isdos10hun.rom: angol + magyar + IS-DOS: elavult file, az EXDOS14ISDOS10UK-HFONT.ROM helyettesíti

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?).
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.30. 14:11:09
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.

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

Quote
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.
1.9 az IDE-s konfigba kell, az tudja kezelni a nagy meghajtókat (csak még kicsit béta :oops: ).
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.30. 14:32:20
IDE 1.2
Title: Re: EP128emu
Post by: Zozosoft on 2016.September.30. 14:47:34
Spectrum ROM-okhoz: Gosh Wonderful ZX Spectrum ROM
Hiba javított, kapott pár plusz utasítást, és a legfontosabb: normálisan lehet begépelni az utasításokat, nem kell azzal vergődni, hogy a shiftek, kurzorok mely kombinációja mellett, melyik gombon van az adott utasítás.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.01. 09:58:50
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.

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.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.01. 11:32:11
A GitHub-on itt (https://github.com/istvan-v/ep128emu/commit/2fee38635cd398d0c09d6ee2425ba6a29fe93fbd) láthatók az új ROM csomaghoz végzett módosítások, elsősorban a makecfg.cpp-nél érdemes megnézni, hogy jó konfigurációkat generál-e (a machineConfigs[] alatt).
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.01. 12:06:39
Ez a zx48.rom-ot helyettesítheti? Akkor talán célszerű lesz átnevezni "zx48gw03.rom"-ra.
Igen.

Quote
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.
Title: Re: EP128emu
Post by: gflorez on 2016.October.01. 12:39:00
Már eltávolítottam az önmódosító kódot a soros (Hsoft) részből.

Ahogy Zozo mondja, ez kezeli a Ram-ot kódon belül, ezért szüksége van egy nagy újraírása, hogy a ram kívül legyen.

Lehet, hogy ez működhet a jelenlegi formájában, betölteni a kiterjesztést minden hideg reset, mint a EDCW.Rom-nál is. Meg lehet csinálni áthelyezhetővé, mint az eredeti meghajtó.

---------------------

I have already removed the self modifying code from the serial(Hsoft) part.

As Zozo says, it manages the Ram inside the code, so it needs a great rewriting to put the ram outside.

May be it can work in its actual form, loading the extension every hard reset, just like the EDCW.Rom does. It can be made relocatable as the original driver.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.02. 20:50:51
Új IVIEW.ROM csomag:
[attachurl=1]

Ebben egyelőre nem található .com formátumú CVIEW (azt még nem frissítettem), és előfordulhatnak új hibák, tehát még tesztelni kell. :oops: Az újdonságok:
- UNCOMPRESS 1.03 (https://enterpriseforever.com/programming/unzip-deflate-tool-for-z80-machines-any-interests/msg50949/#msg50949), ez a verzió valamivel gyorsabb az 1.02-nél
- az IVIEW és CVIEW hibásan kezelte a -palres 0 módú interlace képeket, ezt a hibát javítottam
- szintén IVIEW és CVIEW: ha a file megnyitásakor A6h a hibakód, akkor kilépnek. Ez a FILE: eszköz használatakor hasznos, mert üres file névnél a Cancel gombra kilép, és nem kér végtelen ciklusban új file nevet
- csak IVIEW: az F1-F8 billentyűk kezelésében egy kisebb hibát javítottam
- csak CVIEW: az F1-F8 billentyűkkel beállítható időtartam nem változik turbós gépeken, és az IVIEW-hez hasonlóan tárolja a következő képekhez, nem kell mindig újra beállítani
- az új UNCOMPRESS kódot a CVIEW is használja, tehát az is gyorsabb lett az adatterület kb. 50 byte-os növekedése árán

A FILE bővítő is elavult lehet azokban a .ext változatokban, amelyek tartalmazzák.
Title: Re: EP128emu
Post by: endi on 2016.October.02. 20:57:55
ha már újra elővetted, nincs kedved a graf-karakteres módot is beépíteni?
tudom, elég komoly programozás kéne hozzá, de nagyon érdekes lehetne, főleg ha basic-ből is felhasználható lenne az eredmény :)
a lényeg itt az lenne hogy kis memóriaigényű képeket lehetne vele tárolni, az ismétlődő karakterek felhasználásával.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.02. 21:30:23
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.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.03. 14:42:43
Abból itt az aktuális (https://enterpriseforever.com/programozas/file-bovites/msg55291/#msg55291) amit bele lehetne rakni.

Módosított file.s a fenti csomag fordításához (csak akkor használja, ha a BUILD_FILE_EXTENSION engedélyezett a main.s-ben):
[attachurl=1]
Csak érdekességként egeret támogató - valódi gépen még nem tesztelt - változat:
[attachurl=2]
Title: Re: EP128emu
Post by: lgb on 2016.October.03. 17:33:26
Milyen "jo", hogy mindig kell 1-2 masodperc mire radobbenek a FILE: es a :FILE kozotti kulonbsegre :D Amugy az egereszos verzional az lesz, mint most, hogy minden program kulon "egereszik", vagy a mouse driver project befigyel majd? :)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.06. 18:21:00
Az IDE emuláció nem működik snapshot töltés után. :oops: Egyelőre még nem találtam meg a hiba pontos okát, de az emulátor nem menti az IDE vezérlő állapotát, snapshot töltéskor csak IDE reset történik, ami viszont okozhat problémát.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.09. 10:28:49
Az itt (https://enterpriseforever.com/egyeb-temak/pc-gt-ep-kepkonverzio/msg58740/#msg58740) található új IVIEW.ROM talán már nem tartalmaz jelentősebb hibát, és bekerülhet a csomagba. :) A FILE 1.4 (https://enterpriseforever.com/programozas/file-bovites/msg58733/#msg58733) verzió miatt még frissülhet a ZozoTools, illetve az EXDOS 1.4-ből még nincs nem magyar nyelvű változat. 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? A PASIANS.ROM-ból van még egeresített verzió (http://wiki.enterpriseforever.com/index.php/EnterMice#Games_list), más ROM nem frissült az előző néhány oldalon már megtalálhatóakon kívül?
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.09. 18:03:47
illetve az EXDOS 1.4-ből még nincs nem magyar nyelvű változat.
Lesz, angol, magyar, német,spanyol.
Quote
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

Csak találtam egy bugot, amit még ki kell írtani :oops:

Quote
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ó.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.10. 15:24:58
Lesz, angol, magyar, német,spanyol.

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

Quote
Az EDCW (https://enterpriseforever.com/programming/entermice-option-on-edcw/msg58753/#msg58753)-ből is készült EnterMice-s verzió.

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? Az EP_640k_EXOS232_EXDOS_utils.cfg és EP_640k_EXOS232_IDE_utils.cfg még bővíthető lenne a 22-23h és 33h szegmenseken, illetve az előbbinél szabad még a 42-43h is. Jelenleg a már nem aktuális PASCAL11.ROM-ot sem használja konfiguráció.

A ROM csomag jelenlegi állapota:
[attachurl=1]
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.10. 15:52:34
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
EXDOS14ISDOS10UK-1772.ROM
EXDOS14ISDOS10UK-BRD-1770.ROM
EXDOS14ISDOS10UK-BRD-1772.ROM
EXDOS14ISDOS10UK-ESP-1770.ROM
EXDOS14ISDOS10UK-ESP-1772.ROM
EXDOS14ISDOS10UK-HFONT-1770.ROM
EXDOS14ISDOS10UK-HFONT-1772.ROM

1770/72 között a különbség a 73-as (STEP RATE) változó alapértéke, ennek emulátoron nincs jelentősége, így ez akár el is hagyható.


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

Quote
A ROM csomag jelenlegi állapota:
A config lista is elérhető valahol?
Title: Re: EP128emu
Post by: Attus on 2016.October.10. 17:32:05
István!

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.

:oops:

Ugyanebben (is) segédkezett (nem kicsit) LGB, ő talán jobban megérdemelné a nevének megemlítését.
A PCLinuxOS spec file frissítése is már biztosan nagyon időszerű lenne, habár lehet, hogy akár nélkülözhető is.
Quote
Thanks to:

Zozosoft      - hardware testing and information
MrPrise       - ep128emu.enterpriseforever.com web site
Attus         - Linux binary packages
Martin Bantz  - PCLinuxOS RPM spec file
Title: Re: EP128emu
Post by: IstvanV on 2016.October.10. 19:38:41
A config lista is elérhető valahol?

Ezzel az aktuális GitHub forrásból készült verzióval tesztelhető:
[attachurl=1]
[attachurl=2]
[attachurl=3]
A 32 bites "CMOS" változat CMOS Z80-at emulál, és Lua 5.3 helyett LuaJIT-et használ, ami elvileg gyorsabb, bár nem támogatja a Lua 5.3 újdonságait (pl. &, |, ~ műveletek). Érdemes összehasonlítani a két Lua verzió sebességét olyan - nagy CPU igényű - scriptekben, ahol a breakPointCallback() minden utasításnál vagy memória hozzáférésnél lefut.

A ROM csomag:
[attachurl=4]
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. Az EXDOS13.ROM-ot most nem használja semmi, és az 1.0-t is csak az EP64 konfigurációk. A 640K utils és IDE konfigurációkba bekerült a PASZIANS.ROM (22..23h) és az EDCW.ROM (33h).

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.

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
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.10. 19:46:13
Találtam egy hiányosságot a WD emulációban :oops:
Track/Sector/Data register tartalma nem olvasható vissza. Itt alapból az utoljára beírt érték olvasható, amíg kiadott parancs nem módosítja.
Reset a Sector registert 1-be állítja, a Track, Data nem változik (Status 0 lesz). Bekapcsoláskor a Track, Data 255 lesz.

Ez azért érdekes, mert pont register írás/visszaolvasással akarom tesztelni, hogy van-e WD :oops: (Ne legyen külön floppys/nem floppys EXDOS)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.10. 20:22:55
A regiszterek elvileg eddig is írhatók és (vissza)olvashatók voltak, a probléma az, hogy az emulátor valójában külön WD-t emulál minden meghajtóhoz. :oops: Ez természetesen eltér a valódi géptől, azonban a javításhoz külön kellene választani a WD és a meghajtók emulációját. A WD regiszterekhez csak akkor lehet hozzáférni, ha a 18h porton ki van választva egy meghajtó.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.10. 20:48:39
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 :-)

Bár sok gyakorlai jelentősége nincs, de a nagyobb pontosság kedvéért esetleg nem nagy módosítás: "Reset a Sector registert 1-be állítja, a Track, Data nem változik (Status 0 lesz). Bekapcsoláskor a Track, Data 255 lesz."
Title: Re: EP128emu
Post by: Attus on 2016.October.10. 21:32:01
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


Köszönet!
;-)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.10. 21:32:51
A 4 WD-s emulációt megpróbálom javítani, és a regiszterek alapértékeit is, bár jelenleg nincs külön reset és bekapcsolás utáni állapot.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.10. 21:40:10
Gyors javitásként esetleg: a nincs meghajto és az A: WD-je lehetne közös?
Title: Re: EP128emu
Post by: IstvanV on 2016.October.10. 21:43:27
Gyors javitásként esetleg: a nincs meghajto és az A: WD-je lehetne közös?

Tehát az out (18h),0 is az A:-t válassza? Vagy esetleg a 0 maradjon továbbra is érvénytelen, de bekapcsolás vagy reset után az alapállapot 01h (A:) legyen 0 helyett?
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.10. 22:05:16
Ugy gondoltam, hogy 0 esetén is az A: WD regiszterei lennének elérhetök, de nyilván ilyenkor nem hajtodnának végre a parancsok.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.11. 21:59:30
Módosított floppy emuláció, csak egy WD177x és 4 meghajtó:
[attachurl=1]

Valószínűleg vannak hamarosan javítandó új hibák (szerk.: már találtam is, hiányzó lemez esetén nem megfelelő a hiba emulációja :oops:), ezért csak egy változatot fordítottam (64 bites és LuaJIT-et használ). :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.11. 22:50:40
Valószínűleg vannak hamarosan javítandó új hibák
Ezt játszom éppen az EXDOS 1.4-el is :oops:
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.11. 23:17:18
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

Hátra van még a WD ellenőrzés, itt kell majd még egy új hibaüzenet is (Controller not ready vagy ilyesmi). Ill. kell egy a Lost Data-hoz is, ez gyárilag data error-nak van jelezve.

Title: Re: EP128emu
Post by: IstvanV on 2016.October.12. 11:04:16
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.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.12. 19:31:51
A WD hiba javítva:
[attachurl=1]
[attachurl=2]
[attachurl=3]

ROM csomag az aktuális EXDOS 1.4 verzióval és a ZozoTools (https://enterpriseforever.com/programozas/file-bovites/msg58790/#msg58790) is frissítve:
[attachurl=4]
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 03:01:54
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.

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 ...
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 10:32:26
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:

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?
Title: Re: EP128emu
Post by: IstvanV on 2016.October.13. 10:39:20
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").

Elvileg a floppy is lehet legfeljebb kb. 60 MB méretű (254 * 2 * 240 szektor), amiből négy még mindig meglehetősen nagy lenne. :) Ettől eltekintve nem tudom biztosan, hogyan lenne célszerű kezelni a betöltött image-t, mivel így az eredeti lemez (amit a felhasználó Alt+D-vel választott) már nem látható, viszont ahhoz valamikor vissza kell térni, és akkor a snapshotból töltött image (esetleg már módosult) tartalma elveszik.

Azonban a snapshotban mentett lemezre már most is van megoldás, a RAMDISK használata. Ez ugyan nem a legkényelmesebb, mert a felhasználónak létre kell hoznia, de elkerüli az image mentéssel kapcsolatos problémákat.

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

Erre már gondoltam, bár a megvalósításához még meg kellene írni a snapshot támogatást a floppy és IDE emulációban. :oops: Talán egy későbbi verzióban. Azonban a jelenlegi megoldás floppy esetén általában nem okoz problémát, mivel ez egyébként is cserélhető lemezes eszköz, és az EXDOS megfelelően kezeli a lemezcserét. Hiba csak akkor van, ha lemezművelet közben (amit a floppy LED-ek jeleznek) készül snapshot.

A lemezcsere az IDE.ROM-nál okoz hibát, de ugyanitt problémás lenne a snapshot mentés is, a nagy image méretek miatt a checksum is észrevehetően lassíthatná a snapshot műveleteket, mivel a teljes (legfeljebb 4) file-t be kell olvasni a számításához.

Quote
Ja, spec vmi egyszeru tomorites pl memorianal sem rossz otlet talan ... Nem kell vmi extra, talan valami RLE is jo ilyesmikre ...

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.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.13. 11:30:56
Nincs, a vinyók alapból nem cserélhető lemezek :oops:

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.

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

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. 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)?
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 11:32:27
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.

En is erre gondoltam: nyilvan a mai tarkapacitasok viszonylataban nem gond, csak azert forumokra tenni ide/oda mail-ben kuldeni stb akar, ott azert meg mindig szamithat!
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 11:51:00
Quote
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. :)

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). Meg size korrekcio, mivel elvileg SD image meret nem lehet akarmi, meg akkor sem, h 512-vel oszthato, tehat ott jatszok vele egy kicsit es bovitem az image-et ha kell, kulonben a SD id-et hasznalo cuccok (pl Zozo fdisk) helytelenul fognak mukodni.

Quote
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)?

Ja, valami olyasmi, lasd Xep128 forrasaban :) Amugy en ep128emu-ba ugye egyszer "belehackeltem" :) ha emlekszel, igen randa modon, mukodott is (sot meg az SD audio player-emmel is... ha jol remlik te is nezted pont anno). Az hogy mennyire "szep", hat biztos nem az :) ide pakoltam anno ki (az oldal vege fel van link forrast tartalmazo zip-re is!): http://ep.lgb.hu/ep128emu-sdext/

Ezzel mondjuk az a baj, hogy az en SD-card implementaciom eleg ronda. Nekem is ujra kene irni, meg amugy a hibakezeles rossz benne, pl ha valami SD-controller szintu hiba van (marmint a kartyan levo controller maga ... mert ugye vmi mcu szeruseg van mindegyikben ami illeszti a flash cuccosokat az SPI/vagy mas hozzaferesi dolgokhoz) azt en mas szinten adom vissza (nem mint data packet szintu hiba), ez okozza, hogy a Xep128-ban ha pl read-only sd img-t irsz, akkor exdos error lesz es utana olvasni sem hajlando mar az exdos (ez mondjuk lehet az exdos/sd diskio/akarmi hibaja is, mert ettol meg kene neki tovabb hasznalni csak szerintem ilyen hibakra lehet, hogy nincs felkeszitve ...). A Xep128 beli implementacio amugy emulalja a flash-eleset is a "ROM-nak", amit meg Zozo kert. A cuccos itt van:

https://github.com/lgblgblgb/xep128/blob/master/sdext.c

Velemenyem szerint, amugy par embernek hasznos az IDE is, sot lehet a ketto keverese is (ha jol remlik Zozo irta, hogy ez regen nem ment, de most mar igen ...). Szoval azt is lehetne akar mondjuk csak a GUI szempontjabol, hogy ami az "IDE" volt oda rakni egy fulre az SD-t is. Bar tudom, itt nem a GUI atalakitasa fo problema ;) En mar egyszer majdnem ravettem magam :) hogy ha mar ugyis beleganyoltam az ep128emu-ba (lasd fentebb) akkor az IDE emus GUI reszt "elteriteni" h SD-t lehessen (is?) vele allitani. De ugye mivel a C++ nekem kinai, es szerintem csak az ember nyugalmanak megzavarasara jo, ezert feladtam :) En mar annak is orultem, hogy sikerult belegyanolnom ep128emu-ba valahogy, meg ha borzalmas modon is :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 12:05:42
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.)

Quote
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
Ismerek 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.
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: )

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.

Quote
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.
A 07h az SD, ahol ROM,SRAM és I/O regiszterek találhatóak. Ebből az első 8K ROM, ami valójában 64K, és 8K lapokban lapozható (az így elérhető plusz terület jelenleg még nincs kihasználva). Ezután 7K RAM, majd 1K az I/O terület. Az I/O az 4 bájt, ami alapból ismétlődik az egész területen:
-SD adat regiszter (R/W)
-SD vezérlés (W)/állapot (R)
-ROM lapregiszter (W)
-nagysebességű olvasás vezérlő bit (W)
Nagysebességű módban a teljese területen az adat regiszter olvasható, ilyenkor lehet LDIR-rel másolni
Title: Re: EP128emu
Post by: IstvanV on 2016.October.13. 12:25:21
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).

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.

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.

Ha ez az IDE szektor olvasó rutin, akkor talán lehetne gyorsítani rajta:
Code: ZiLOG Z80 Assembler
  1. .   D066  06 00        LD    B, 00
  2. .   D068  3E 20        LD    A, 20
  3. .   D06A  DD 4E 02     LD    C, (IX+02)
  4. .   D06D  ED 79        OUT   (C), A
  5. .   D06F  F6 30        OR    30
  6. .   D071  ED 79        OUT   (C), A
  7. .   D073  DD 4E 00     LD    C, (IX)
  8. .   D076  ED 78        IN    A, (C)
  9. .   D078  77           LD    (HL), A
  10. .   D079  23           INC   HL
  11. .   D07A  DD 4E 01     LD    C, (IX+01)
  12. .   D07D  ED 78        IN    A, (C)
  13. .   D07F  77           LD    (HL), A
  14. .   D080  23           INC   HL
  15. .   D081  10 E5        DJNZ  D068
  16. .   D083  AF           XOR   A
  17. .   D084  FB           EI
  18. .   D085  C9           RET
Helyette (nem tudom, itt fontos-e a DE, BC', DE', és az F visszatéréskor, ha igen, akkor kell még néhány utasítás, de az IDE.ROM-ban még sok a szabad hely, ezért lehetne még hosszabb és valamivel gyorsabb kód is):
Code: ZiLOG Z80 Assembler
  1. .   D066  DD 5E 00     LD    E, (IX)
  2. .   D069  DD 56 01     LD    D, (IX+01)
  3. .   D06C  AF           XOR   A
  4. .   D06D  D9           EXX
  5. .   D06E  DD 4E 02     LD    C, (IX+02)
  6. .   D071  47           LD    B, A
  7. .   D072  11 20 30     LD    DE, 3020
  8. .   D075  ED 59        OUT   (C), E
  9. .   D077  ED 51        OUT   (C), D
  10. .   D079  D9           EXX
  11. .   D07A  4B           LD    C, E
  12. .   D07B  ED A2        INI
  13. .   D07D  4A           LD    C, D
  14. .   D07E  ED A2        INI
  15. .   D080  D9           EXX
  16. .   D081  10 F2        DJNZ  D075
  17. .   D083  D9           EXX
  18. .   D084  FB           EI  
  19. .   D085  C9           RET

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

Ennek a hackelt verziónak a forráskódja megtalálható valahol?
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 13:01:03
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.

Na, ezt nem tudtam, jo tudni :)

Quote
Ennek a hackelt verziónak a forráskódja megtalálható valahol?

Fentebb irtam pont egy elozo hozzaszolasomban am (a "Licenc kerdesek resznel az oldalon) :D

http://ep.lgb.hu/ep128emu-sdext/

Oldal alja fele van link. Mondjuk _tenyleg_ ronda hack, es az SD "tamogatas" benne is kisse hmm ganyolt :)
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 13:05:05
Ja meg annyi, hogy ahhoz kepest ami abban a "patkolt" ep128emu-ban volt SD-hez azert ujabb a mostani Xep128-ban levo SD cuccos, foleg, mivel pl ebben iras is van azota ......... Meg pl flash-eles az sd card cartridge flash-ehez. Meg meg par dolog, amit szerintem nem is commit-oltam meg github-ra sem :(
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 13:37:03
Egy apróság: az EP64 TASMON configokban mehet már 4-5-re a TASMON, módosítva lett a gyorstesztje, hogy EXOS 2.0-val is menjen.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 14:45:24
A WD hiba javítva:
Működik is a WD vizsgálat, régi emuval not ready lesz, az újjal működik :-)
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 16:12:35
Bocsi, flood-olom itt a temat a hulysegeimmel :) Csak meg annyit, hogy az ep128emu "ganyolasom" SD temaban, es az Xep128-ban levo kod is _nagyon_ ronda, biztos jobb lenne inkabb ujrairni :) Marmint nekem is, csak mindig lusta voltam belefogni :-/ Ettol persze, folelem bele lehet tennie ep128emu-ba, GPL mindket project, szoval nem gaz, csak epp nem szep, nem is C++ meg stb :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 19:21:18
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:
Title: Re: EP128emu
Post by: IstvanV on 2016.October.13. 21:11:29
SD kártya hack az itt található forráskód (http://ep.lgb.hu/ep128emu-sdext/src.tgz) alapján:
[attachurl=1]

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.

Egyéb változások:
- az IDE emuláció a VHD formátumú image-t akkor is elfogadja, ha nem .vhd a kiterjesztése
- az asmon15.rom minden konfigurációban a 4-5 szegmensekre kerül
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.13. 21:17:17
Itt (https://enterpriseforever.com/hardver/sd-kartya-interface-cartridge-ben/msg58104/#msg58104) a legutolsó SD ROM csomag, a 0.4 már működik IDE-vel együtt is.
De hamarosan készül újabb is, friss EXDOS 1.4-el ill. FILE 1.4-el (ahol ilyen is van a konfigban).
Title: Re: EP128emu
Post by: lgb on 2016.October.13. 23:54:35
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.

:) Jo, azert megjegyzem am, hogy amit es ahogy betettem az ep128emu-ba (fix nevu file meg minden egyeb galadsagok) az egy gyors "szorakozas" akart lenni a reszemrol, hogy meg tudnam-e csinalni, szoval elnezest a ganyolasaimert, utolag is :)
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 08:12:22
Amugy itt a viszonylag friss sdext.c verzio a Xep128-bol ez github-on sincs meg kint. Egyreszt ez tud irni is, masreszt van benne VHD detect (en amugy nem is tudtam, hogy ilyen formatum kulon van a vegen azzal az info blokkal, csak akkor derult ki, amikor Zozo tesztelte, es sehogy nem jott ki a meret ...), illetve SD kartya "meretezes" ervenyes meretre (ha MS VHD forumatum, akkor ezzel viszont elrontja ...), meg pl ures image letrehozas is, egy RLE tomoritett "beepitett" image-rol (ez mondjuk nincs benne, include-olja), no meg flash-eles support. Ami van (es volt az elozoben is) fopen/fileno kerveredes az azert van, mert az Xemu specifikus open_emu_file() van hasznalva az image megnyitasara (ez megnezi pl az exe-vel kozos konyvtarban, aztan az SDL altal visszaadott "preferences directory"-ban, stb, legtobb dolog Xep128-ban ezen 'at" van megnyitva, am ez FILE *-t ad vissza file handler-nek (tehat fopen-t hasznal). 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. Az nagyon valoszinu, hogy ep128emu-ban messze nem ez lenne az idealis eljaras, lehet xep128-ban sem :-P

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 ... A normalis megoldas az lenne, hogy adott ideig busy statuszt visszzadni, igy "belassitani" kicsit a dolgot, hogy valosagosabb legyen. Ehhez viszont normalisabban kene megirni :D Igy mos az a nagyon ronda trukk van benne, hogy:

z80ex_w_states(40);

Ezzel a CPU emulatorral elhitetem, hogy X orajelciklusikg tartott, igy "belassitom" normalis(-abb) szinte igy. Persze ez total hulye megoldas (mivel a valosagban persze nem a Z80 "all" ilyenkor amikor az SD dolgozna ...), a normalis a fenti lenne: beolvasni, de nem visszaadni az eredmeny, hanem egy ideig busy-t "szimulalni", aztan csak utana "kiszolgalni". Stb.

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. Gondolom a problema az, hogy amugy nem a parancsot kene "vissza-error-zni" ilyen esetben, mert van SD-nel (bocsanat, fejbol mar nem remlik pontosan) as mas jellegu hiba is, amikor a parancsot elfogadod, csak annak eredmenye az error. Azt viszont nehezebb a jelenlegi kisse szedett-vetett megoldassal megcsinalni, azt azert nem tettem eddig :) Mindig csak a lustasag, ehmm :)
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.14. 09:25:55
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.
Egy bad sectoros kártyát is már begyűjtöttem a teszthez.

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.
(Viszont a SymbOS már most is kezeli a kártyacserét, igaz neki egyszerűbb dolga van, mert csak primary partíciókat kezel.)
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 09:28:07
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.

Ja, csak _szerintem_ (nem teszteltem) egy valodi SD katya bad sector/akarmi eseten a data valaszban ad error-t. En meg egyszeruseg kedveert a command-ra mondom hogy error, szerintem ez zavarja, azaz a parancsot sem fogadom el hibaval ... Valoszinu, hogy valodi kartya a parancsot elfogadja, csak utana ad error-t, ami egy mas "hiba szint" az SD kommunikacioban teljesen.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.14. 10:42:40
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.

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.

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

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 Plus/4-nél (1541) és korlátozottan a CPC-nél valósítottam meg. :oops:

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.

Ez hasznos lenne az IDE.ROM-nál is (ha megoldható), mert most bármilyen image file csere vagy új megnyitása, illetve snapshot töltés után hidegindításra van szükség ahhoz, hogy az IDE meghajtókat lássa az EXDOS.
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 10:56:21
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.

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.

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

Varni annyit kell, amig busy :) Marmint a command kiadasa utan a kartya (ha byte szinten nezzuk, mert SPI soros, dehat ugye az SD cartridge mar byte-ban adja neked ...) 0xFF erkezik addig, amig nem tudja adni a kartya az adatot. Utana jon egy 0xFE, ez a data token, jelzi vele, hogy most akkor adna az adatokat, amit kertel. Szerintem meg egy Z80 szempontjabol sem igaz, hogy "nulla ido alatt" kepes vegrehajtani egy read parancsot egy kartya ... Mivel en ennyire nem akartam tulszofisztikalni, ezert adok egyetlen egy 0xFF-et (a biztonsag kedveert, hatha vmi program nezki ki tudja), de utana mindig 0xFE jon (data token) majd mar az adat. Viszont tartok tole, hogy egy valodi gepen (ezt le kene amugy tesztelni!!!!!) azert tobb ideig lesz 0xFF, bar ez nyilvan kartyatol is fugg ... De mondjuk az az extrem eset is elkepzelheto (oke, ennek erteme nem sok!) hogy valami EP-s program kuld egy read parancsot a kartyanak, majd az eredmeny nem igazan erdekli, es kuld megint egyet stb. Ebben az esetben ugye egy valodi EP/kartya eseten az SD-n levu pici kis MCU csinalgatja a dolgat, no problem. Emulatornal viszont gond, mert mindegyik ilyennel lesz belole egy lseek() meg read(), ami mivel egyszalu az emulator, addig feltartja a gep emulalasat ... 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, de sajnos ez sem tul nyero otlet, mivel egy mai modern multitask OS-nel eleg sok minden fut, lehet lesz "egesz sok ido" mire a masik thread eszreveszi h uj read request van, osszessegeben meg lassabb lenne mint egy valodi EP/SD kombo ... Amire meg gondoltam: non-blocking I/O hasznalata. Akkor ugye, ha a host OS nem tudja adni az adatokat visszkapom h meg varjak ... Raadasul ezt valami emulator idoziteshez hasonlitva (tudomisen osszes eddig felhasznalt cpu ido, vagy pl a Nick slot-ok szama, szoval vmi olyan ami amug is konyvelve van es miatta nem vezetek be uj idozitot/szamalalot, azt nem szeretem), mondjuk limitalom, hogy azert egy szuk ciklus ami nezi csak h jon-e a data token ne okozzon minden egyes opcode-nal majdnem egy host OS syscall-t, hogy megvan-e mar az adat, mert azert az megiscsak X szazezer-millio kozotti rendszerhivas masodpercenkent. Persze, lehet, csak en vagyok ennyire aggodos tipus, es nem kene ennyire feltenem egy modern PC-t, csak elbirja azt :-P
Title: Re: EP128emu
Post by: IstvanV on 2016.October.14. 11:20:27
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.

Itt szerintem valami más probléma lehetett, vagy ez valamilyen nagyon lassú fread() implementáció (Windows vagy OS X?). Ami biztosan gyorsított, az a sok debug printf() letiltása. :)

Quote
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

Egy 4 MHz-es Z80 CPU-n egy NOP utasítás is 1 us, értelmes programnak nem kellene 100% alá lassítani az emulációt egy mai PC-n, még akkor sem, ha az csak stdio-t használ egy szálon.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.14. 11:35:34
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.
(A WD-nél egyébként van, most a WD vizsgálatnál elő is jött, be kellett rakni PUSH/POP várakozásokat a regiszter írás/olvasások közé, hogy valódi gépen is megbízhatóan működjön. Az EXDOS is inkább ezért nézi a 18h porton a WD DRQ lábát a status register helyett.)

Quote
É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 :-)

Quote
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.
Viszont ha a fejléptetést a megfelelő ütemben kiadott hanghatással meg lehetne oldani, az tetszene :-) (Mint pl a Saint féle Atari ST emulátorban, vagy a közelmúltban készült magyar TAP34 emulátorban.)
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 11:49:52
Most vagy en nem ertem, vagy te - de inkabb en nem :) Mindenesetre nekem ez igy sehogy sem all ossze. Pont az a baj (nem csak Xep128-nal, pl Xemu-ban a C65 meg az M65 emulatorommal is) hogy barmi disk emunal nagyon durvan elszall a CPU hasznalat. Az oka az, hogy bar az emulalt CPU szempontjabol eltelt annyi orajelciklus amit igenybe vesz a kerdeses muvelet elkuldese a hw fele (ami ha opcode szintjen nezzuk, akkor maga az opcode vegrehajtasi ideje, ha viszont "sub opcode szinten" akkor kvazi nulla, mert ha a kerdeses opcode pl memoriat irna akkor is ugyanannyi lenne), ugyanakkor jelentos overhead van ehhez kepest, mivel van egy-ket libc/syscall is kozben. Viszont ugye az emulator idozitese azt szamolja, hogy hany emulalt orajelciklus telt el. Ha most mondjuk egy viszonylag szuk ciklusban csinalgat ilyeneket, akkor akar minden X.-edik opcode-nal is a PC jelentos hatranyban van az EP-hez kepest, mert ugye ott a szokasos hw emulaciohoz kepest meg ott az is, hogy file I/O-t is kell csinalnia. Na, a lenyeg az, hogy Xep128-ba es Xemu-ban tobb kulonbozo emulatoromban is ez komoly gond. Pl M65 emulator ezert nem is mukodik, mert az I/O total lefogja (3.5Mhz emulalt 65CE02 eseten ugy 30-40% SD-vel valo bizeralas, 10% ha nem, marmint a CPU hasznalat a futtato Linux-on - ha szendekosan lentebb viszem az emulalt CPU orajelet akkor kvazi alig lesz kulonbseg, mert tobb iro marad mindenre). Ha kikapcsolom akkor jo :) Ott valoszinu megis tobbszalas lesz, vagy valami emulalt busy-val lesz megoldva, hogy ne flood-olja ugymond az emulatort (igaz, az M65 gyorsabb mint az EP, szoval ez azert nem teljesen ugyanaz a tema).

Xep128/EP eseten amugy a dolog nem annyira veszes, de pl pont ep128emu kapcsan, amikor csinaltam a ganyolast, ott nagyon lefogta, amig fread()-et hasznaltam, toredekere esett a cpu fogyasztas, ahogy attertem a read()re ... Ha jol remlik windows verzio alatt (IGAZ, a windows verziot wine-al tudtam csak kiprobalni). Azert erdemes lenne megnezni, hogy valtozik az emulator CPU fogyasztasa intenziv image emulalt I/O eseten, ep128emu-t (a fenti halvany emleken kivul) nem neztem, Xep128 es Xemu eseten is eleg jelentos elteres van/volt.

A debug printf :) az nem emlekszem hol/mikor volt, es mikor nem :) de alapbol mintha nem lenne engedelyezve, de lehet, hogy tevedek (ha ugy felejtettem a DEBUG_SDEXT-et akkor tenyleg volt, de amikor neztem en, akkor persze kikapcsoltam, mert az tenyleg zavaro, foleg, ha kozben ugye szegeny gep CPU ideje arra megy el, hogy a kismillio printf output-jat a terminal ablakba szeeeeep fontokkal lerenderelje ...).
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.14. 12:17:51
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 :-)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.14. 13:06:46
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 :-)

A magas CPU fogyasztásnak nem is nagyon lenne értelme, a korábban említett tesztben egy 900 MB-os file olvasása kb. 1.8 millió puffereletlen 512 byte-os fread() hívással 2 másodperc volt, és ez egy 1.65 GHz-es AMD E450 laptop CPU-n. :) Tehát egy egész szektor beolvasása (a tényleges lemezműveletet nem számítva, mert a file-t már cache-elte a rendszer, de itt egyébként is csak a read()/fread() különbség a lényeges) átlagosan alig több mint 1 us, és erre természetesen csak minden 512. byte (512 * 16 / 10 = 819.2 us 10 MHz-es Z80 CPU-n 512 LDI utasítás) után van szükség.

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).
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 14:15:51
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).

Akkor passz, nekem akkor sem jon ossze, es ep128emu-val _SE_ mint jeleztem :) megjegyzem. debug dolgok persze, mint mondtam, ki voltak akkor kapcsolva.

Bar nem az alapproblema resze, de amugy van meg egy helyzet, amikor ez viszont tenyleg gond: nem feltelen igaz, hogy cache-elve van, es a rendszer nem vegez I/O muveletet amugy,a mikor akar emeberi idoben merve is eltarthato valameddig a muvelet, na ez viszont meg gazabb. Nekem a fenti anomaliakon kivul ez akkor gond, amikor pl sshfs-en at mount-olok egy filerendszert, es ugy lassu, de az amugy is lassu, ha csak siman shell-bol probalod machinalni. Normalisabb megoldasnal ilyenkor pl SD kartya emulacio siman busy-t ad vissza mint normalisan is, egeszen addig amig nem sikerul az I/O. Am mivel itt blocking I/O van, addig all az egesz emulator (ezt meg ugy ertem, hogy ugye akkor tenyleg az egesz, meg szabalyosan kilepni sem tudsz, meg semmi nem mukodik, ha pl behal eppen a halozat). Oke, lehet en vagyok tul paranoid, de ez velem neha megesik, mert altalaban sshfs-en at tolok dolgokat :)
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 15:43:00
De amugy megnyugtattal, hogy te sem szofisztikaltad agyon ep128emu-ban ezek szerint az image kezelest, hanem ott is "inline" (vagy hogy mondjam) blocking I/O van szepen, semmi egyeb. Ha jol ertem. Azert en pl SD kartya sebesseget csak megneznem egyszer, hogy valojaban milyen gyors :) Az biztos, hogy az SPI busz sebessege az SD cartridge-n ugy van megvalasztva, hogy elvileg Z80-al nem tudod "megelozni" (azt hiszem ezt egyszer szamoltam/neztem, talan meg turbo-s gepen sincs gond, bar 12MHz kornyeken ilyen POP/PUSH jellegu trukkel mar lehet gond, de ez nem is a fenti problema ugye, hanem mas jellegu). A masik resze, hogy milyen gyorsan valaszol adattal pl egy block read-re, azert lenne lenyeges, mert van ahol ez fontos, pl az SD audio playeremnel ez nagyon nem mindegy, igy lehet mas eredmeny egy valodi gepen es egy emulatorban ... Xep128-ban mindig egy $FF jon az $FE data token elott mint mondtam, ezt mondjuk le lehetne tesztelni, hogy a valosagban mennyi (bar ez nyilvan fugg kartya tipustol, sot meg lehet az adott block helyzetetol is, hogy flash-en hol van, mittomen' nem igazan ertek a flash technikahoz melyebben, hogy uniform-e az access time). Linear olvasasnal biztos nem lesz lassu foleg egy EP-nek :) de random hozzaferesnel erdekes lehet.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.14. 21:27:12
Írható SD kártya:
[attachurl=1]
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 21:38:52
Írható SD kártya:
(Attachment Link)

Ebben mennyire tertel el az en kodomtol? Neztem, elsore most tul faradt vagyok hogy a melyere nezzek, de erdekel amugy :)
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 21:44:48
Kozben a Xep128 github-os repo-ba felnyomtam ezeket, amit itt is kuldtem C forras, mert eddig csak local-ban volt meg ...................
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.14. 22:09:29
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?
Szerintem végleges verzióba kéne a Machine configuration-ba egy opció, hogy Enable SD interface emulation, amihez tartozna konfig fájl bejegyzés, ahogy a virtual fileIO-hoz is. A lemez kiválasztón meg vagy lenne külön fülecske az SD-hez, vagy a secondary két vinyó válthatna át két SD-vé.

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.
Title: Re: EP128emu
Post by: lgb on 2016.October.14. 22:16:17
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?

Ez Xep128-ban ugy van, hogy megnezi milyen rom van ott, ha EXOS_ROM es SDEXT kifejezest megtalalja a szegmensen akkor "feltetelezi" hogy SDEXT ROM van ott es engedelyezi. Ez nem tudom mennyire jo megoldas mondjuk :)

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

Ami elvileg mar xep128 github-on is van amugy. Max ott tele van pakolva figyelemezteto ablakokkal ugye az image meret "noveles" miatt ha nem jonne ki "SD-compatible" meretre.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.15. 19:00:02
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?

Ezt a GitHub-on már módosítottam, most egyelőre nem konfigurálható a grafikus felületen, ezért szöveges formátumú konfigurációs file-t kell betölteni (Alt+Q), illetve ugyanezek megadhatók a parancssorban is:
Code: [Select]
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 49152
Ezen 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.
[attachurl=1]
[attachurl=2]

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

A VHD támogatás és az image méret számítása/ellenőrzése már a forráskódban van, a tegnap fordított verizóban is megtalálható (ha nem hibás).

Újdonság lesz még a tömörített formátumú snapshotok (illetve demo és egyéb ep128emu fejlécű bináris file) támogatása, ilyenek egyelőre csak az epcompress segítségével készíthetők, az emulátor csak tölteni tudja ezeket:
epcompress -1 snapshot.ep128s snapshot.ep128s                       (lassú)
epcompress -raw -9 -maxoffs 262144 snapshot.ep128s snapshot.ep128s  (max. tömörítés, nagyon lassú)

Ha később beépítem a mentést is, akkor az valószínűleg egyszerűbb, kevésbé hatékonyan tömörítő, és lényegesen gyorsabb kódot használna.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.15. 20:02:55
A fent említett változtatásokon kívül a debuggerben az SD kártya I/O területének az olvasása nem zavarja az adatátvitelt (azaz egy memory dump nem számít LDI utasításoknak :)), és az egyébként csak írható regiszterek is olvashatók.
[attachurl=1]

Tömörített snapshot/demo file-ra példa, az eredeti itt (https://enterpriseforever.com/letoltesek-downloads/ep128emu-demok/) található:
[attachurl=2]

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:
Title: Re: EP128emu
Post by: lgb on 2016.October.15. 23:49:02
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 ...
Title: Re: EP128emu
Post by: lgb on 2016.October.16. 00:38:05
Nem tartozik szorosan a temahoz, de:

http://c65.lgb.hu/web-xemu/xc65.html

Ez az Xemu project-embol a Commodore 65 emulator, "webes" verzioja. Ellentetben az jsep-vel, ez nativ C kod, csak az emscripten nevu forditoval kvazi le van forditva javascript-re (az jsep az "kezzel" irt javascript kod volt). Ezt elvileg meg lehetne tenni persze az Xep128-al is (es akkor kvazi jsep-szeruseg lesz belole ...). Sot, elvileg az ep128emu-val is, azert irtam ebbe a topic-ba :) Csak ugye a gond azzal az, hogy az emscripten kepes SDL2-t "emulalni", de az ep128emu nem igazan azt hasznal (bar amugy emscripten GL-t is tud valahogy a SDL2-n at, ahogy nativan is tud ilyet az SDL2, amikoris WebGL lesz belole valahogy a forditas soran).
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.16. 12:56:14
:) 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? :-)
Title: Re: EP128emu
Post by: szalai56 on 2016.October.16. 16:08:34
Bocsánat, ezt a rom.bin -t mivel tudom kicsomagolni?

Köszi
Title: Re: EP128emu
Post by: IstvanV on 2016.October.16. 18:05:42
A makecfg automatikusan kicsomagolja, ha ilyen nevű file-t talál a "roms" alatt, illetve kész verzióknál az installer letölti. Ugyanez a csomag .zip formátumban:
[attachurl=1]
Title: Re: EP128emu
Post by: IstvanV on 2016.October.16. 23:06:28
[attachurl=1]

Most már grafikus felületen konfigurálható az SD kártya emuláció, és lehetőség van tömörített formátumú snapshot és demo file-ok mentésére (ez a "Machine configuration" ablakban engedélyezhető, de a Ctrl+F9-el készített "quick snapshot"-ra nincs hatása). A tömörítő sebességét sikerült többé-kevésbé elfogadhatóra javítani, összehasonlításképpen a Total Eclipse demo elejéről készült snapshot mérete:
  166082 byte - az emulátorral mentve (Alt+S)
  525131 byte - ugyanez kicsomagolva
  166023 byte - újra tömörítve a parancssoros epcompress-el, hasonló paraméterekkel (-blocksize 65536 -maxoffs 65536)
  163585 byte - parancssoros epcompress, maximális tömörítés (-raw -9 -maxoffs 262144)
  167285 byte - gzip formátum 7za-val (parancssoros 7-Zip) létrehozva, ez kisebb file-t készít mint az eredeti gzip és zip programok
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.16. 23:34:43
Most már grafikus felületen konfigurálható az SD kártya emuláció
:smt038

Kipróbáláshoz 64-ksra növelt SDEXT.

Azt esetleg lehetne, úgy általában is, hogy rövidebb ROM fájlt FF-ekkel felkerekítsen a szükséges méretre?
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.16. 23:42:42
Kártya (azaz jelenesetben VHD) cseréhez, ezeket az infókat kaptam a hardver tervezőjétől:
Quote
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.

A jelenlegi SDEXT verzió még nem foglalkozik vele :oops: Így kártya csere után Not ready lesz, mivel nem lett inicializálva a kártya.
Ennek az emulációja még hiányzik. (Azaz, hogy csere után várjon az inicializálásra.)
Ha ez is meglesz, akkor már az új ep128emu segítségével készülhet a következő SDEXT :smt038
Title: Re: EP128emu
Post by: IstvanV on 2016.October.17. 11:44:14
Azt esetleg lehetne, úgy általában is, hogy rövidebb ROM fájlt FF-ekkel felkerekítsen a szükséges méretre?

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. :) Azonban a 64K-s ROM a 04-07h szegmensekre már nem elég, kell még egy külön file a lapozható flash ROM céljára. Ilyen ROM-okra itt (https://enterpriseforever.com/ep128emu/ep128emu/msg58858/#msg58858) található példa. A 7-es szegmens valójában nem is használt ha engedélyezett az SD kártya. De nem tudom, a külön programozható 64K ROM mennyire hasznos az emulátorban, és snapshot kezelésnél problémás is (mert így a ROM image már tulajdonképpen írható "lemez"; szerk.: esetleg a tartalmát menteni lehetne, és töltés után Shift+F11-ig írásvédett ROM lenne), 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ó?

Ennek az emulációja még hiányzik. (Azaz, hogy csere után várjon az inicializálásra.)

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:
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.17. 12:42:09
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 :-)
Alapvetően régen EP-n úgy tároltam a ROM fájlokat, hogy olyan hosszú amennyi kód van benne. Most is pl az SDEXT04 az csak 5289 bájt :-) amit fel kellett kerekíteni 64K-ra, hogy elfogadja.

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

Quote
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).
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.17. 15:19:25
Angol Spectrum emulátor ROM (https://enterpriseforever.com/hardware/zx-spectrum-emulator-card/?action=dlattach;attach=16421), ez is mehet a ROM csomagba.
Title: Re: EP128emu
Post by: lgb on 2016.October.17. 19:54:13
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)


Nos, a Xep128-ban valojaban tenyleg nincs olyan, hogy "nem inicializalt a kartya". Elfogadja azokat a parancsokat, amit ilyenkor szokas csinalni, de ezek hianyaban is mukodne, ami mondjuk persze sajna nem egyezik a valosaggal, de "fix" SD image eseten ez elvileg tul sok vizet nem zavar, ha az SDEXT amugy is tutira megcsinalja, akkor valodi gepen is megy. Az mas kerdes, hogy "hot swap" eseten persze jo, ha ez is tesztelheto ...

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

Marmint ez Xep128-ban - elvileg - benne van. Vagy ugy ertetted, hogy ep128emu-ban nincs? _size_calc() fuggveny modositja a _read_csd_answer tombot, amit a 9-es parancs visszaad aztan. A fenti fuggveny a sdext_check_and_set_size()-bol van hivva. Hmm ... ha minden igaz :D Arra persze nem eskudnek meg, hogy ez igy tuti jo most, ahogy van. Ha jol remlik Zozo tesztelte (meg o is kerte ezt), es par probalkozas utan jonak tunt szerinte. *Ha* jol emlekszem :) Ami megmaradt az az, hogy nagyokat karomkodtam magamban, hogy milyen pepecs munka a CSD valaszt atirni, meg az egesz meret dolgot csinalni :)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.17. 22:54:08
Vagy ugy ertetted, hogy ep128emu-ban nincs?

Eddig nem volt, de már van:
[attachurl=1]
Szintén támogatottak a fent említett állapot bitek (írásvédelem, nincs kártya, kártya csere; ez a byte a debuggerben olvasva az alsó két biten a cs0 és cs1 állapotát adja vissza), bár az image file nélküli E0h/C0h érték nem biztos, hogy helyes. Kártya csere után inicializálásra van szükség, erre a célra csak a CMD1 megvalósított, ha nincs kártya, akkor az inicializálás sikertelen.

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. Jelenleg a használhatóságát rontja, hogy töltéskor kártya cserét állít be. :) A demo felvétel és lejátszás pedig kártya nélküli állapotot, ami nem igazán felhasználóbarát, mert a demo után az image-t újra meg kell nyitni.
Title: Re: EP128emu
Post by: lgb on 2016.October.17. 23:05:25
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.

Az jo :) Xep128-ba beletettem *nemi* igazan nem tul pontos ep128emu snapshot loading-ot meg anno, de a fo problemam mindig az volt, hogy WD/disk support-ot lusta voltam csinalni, SD-t meg az ep128emu nem tudott, ez nemikepp rontott a hasznalhatosagon :)

Amugy szerintem a Xep128-al nem is nagyon fogok tobbet foglalkozni, nincs ertelme, az ep128emu kvazi mindenben jobb, most meg mar biztosan, mert ugye eddig volt par elonye azert a Xep128-nak (SD kartya, eger ...). Igazabol a letrejottet is az az igeny szulte, hogy kellett nekem par dolog, de az ep128emu es foleg a C++ dolgokhoz kozom nincs (marmint, hogy abba irtam volna bele, sajat emulator helyett).
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.18. 07:28:03
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ó.
Nincs bent kártya: DFh
Kártya bekerül: 3Fh, majd a change bit törlése után 1Fh
Kártya kivétele: FFh, majd a change törlése után DFh
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.18. 07:33:00
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:

Quote
eddig volt par elonye azert a Xep128-nak (SD kartya, eger ...).
Z180? :-) Elöbb-utóbb aktuális lesz :-)
Title: Re: EP128emu
Post by: lgb on 2016.October.18. 08:02:24
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 :-)

:) Amugy a tervem nem az, hogy Xep128 tobbe egyaltalan ne legyen, de nem biztos, hogy ebben a formaban. Van az Xemu nevu projectem, ami tobb gepet is emulal (pl a mar emlitett Commodore 65 meg Commodore LCD, illetve a Mega-65 is, de abban pl Primo kezdemeny is van mar). Ez igy ilyen generic emulator framework-nek csufolhato valami. Belepakolom abba majd elobb-utobb, igy nem kell ket kulon project-kent kezelni. Nameg benne van meg az emscripten irany, JSep "kivaltasra" is jo lehet, ami hasznos lehet ahhoz a tervhez, hogy weben prezentalni egy-egy EP programot "gyorsan". Az JSep kisse "bena" volt :)
Title: Re: EP128emu
Post by: IstvanV on 2016.October.18. 21:48:59
A nem használt bitek 1-esek

Ez biztosan így van? Az eddigi & 0xE0-al működik, viszont | 0x1F-re módosítva a ROM nem találja az F: után a többi logikai meghajtót. :oops: De máshol is lehet a hiba.

Szerk.: a ROM csomag már nem aktuális, mivel az EXDOS frissült, ezért egyelőre töröltem, hamarosan újat készítek.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.18. 22:06:28
Ez biztosan így van?
Ezt láttam, amikor ASMON-ban nézegettem a regisztereket :oops:
Title: Re: EP128emu
Post by: IstvanV on 2016.October.18. 22:41:38
Valóban, ez véletlenszerűen előforduló hibának tűnik, és nem függ a regiszter nem használt bitjeinek az értékétől.

Szerk.: lehet, hogy ez ROM bug, itt egy puffer címe változik attól függően, hogy történik-e megszakítás egy bizonyos időpontban (a - karakterrel kezdődő sorok a hibás futásból vannak):
Code: Diff
  1. @@ -69771,22 +69771,43 @@
  2.  AF=0140 BC=0000 DE=003F HL=003F 07:CE2B  LD    E, L
  3.  AF=0140 BC=0000 DE=003F HL=003F 07:CE2C  POP   HL
  4.  AF=0140 BC=0000 DE=003F HL=0000 07:CE2D  ADC   HL, BC
  5.  AF=0140 BC=0000 DE=003F HL=0000 07:CE2F  LD    B, H
  6. -AF=0140 BC=0000 DE=003F HL=0000 D8:0038  PUSH  AF
  7. -AF=0140 BC=0000 DE=003F HL=0000 D8:0039  SCF
  8. -AF=0141 BC=0000 DE=003F HL=0000 D8:003A  JR    0045
  9. -AF=0141 BC=0000 DE=003F HL=0000 D8:0045  IN    A, (B3)
  10. -AF=0741 BC=0000 DE=003F HL=0000 D8:0047  LD    (0055), A
  11. -AF=0741 BC=0000 DE=003F HL=0000 D8:004A  LD    A, 00
  12. -AF=0041 BC=0000 DE=003F HL=0000 D8:004C  OUT   (B3), A
  13. -AF=0041 BC=0000 DE=003F HL=0000 D8:004E  JP    C410
  14. -AF=0041 BC=0000 DE=003F HL=0000 00:C410  IN    A, (B2)
  15. -AF=FF41 BC=0000 DE=003F HL=0000 00:C412  LD    (0054), A
  16. -AF=FF41 BC=0000 DE=003F HL=0000 00:C415  LD    A, FF
  17. -AF=FF41 BC=0000 DE=003F HL=0000 00:C417  OUT   (B2), A
  18. -AF=FF41 BC=0000 DE=003F HL=0000 00:C419  LD    (BF7C), HL
  19. -AF=FF41 BC=0000 DE=003F HL=0000 00:C41C  LD    HL, BF79
  20. +AF=0140 BC=0000 DE=003F HL=0000 07:CE30  LD    C, L
  21. +AF=0140 BC=0000 DE=003F HL=0000 07:CE31  DEC   SP
  22. +AF=0140 BC=0000 DE=003F HL=0000 07:CE32  DEC   SP
  23. +AF=0140 BC=0000 DE=003F HL=0000 07:CE33  DEC   SP
  24. +AF=0140 BC=0000 DE=003F HL=0000 07:CE34  DEC   SP
  25. +AF=0140 BC=0000 DE=003F HL=0000 07:CE35  DEC   SP
  26. +AF=0140 BC=0000 DE=003F HL=0000 07:CE36  DEC   SP
  27. +AF=0140 BC=0000 DE=003F HL=0000 07:CE37  DEC   SP
  28. +AF=0140 BC=0000 DE=003F HL=0000 07:CE38  DEC   SP
  29. +AF=0140 BC=0000 DE=003F HL=0000 07:CE39  DEC   SP
  30. +AF=0140 BC=0000 DE=003F HL=0000 07:CE3A  DEC   SP
  31. +AF=0140 BC=0000 DE=003F HL=0000 07:CE3B  POP   HL
  32. +AF=0140 BC=0000 DE=003F HL=4000 07:CE3C  PUSH  HL
  33. +AF=0140 BC=0000 DE=003F HL=4000 07:CE3D  DEC   SP
  34. +AF=0140 BC=0000 DE=003F HL=4000 07:CE3E  DEC   SP
  35. +AF=0140 BC=0000 DE=003F HL=4000 07:CE3F  PUSH  DE
  36. +AF=0140 BC=0000 DE=003F HL=4000 07:CE40  LD    DE, 0200
  37. +AF=0140 BC=0000 DE=0200 HL=4000 07:CE43  ADD   HL, DE
  38. +AF=0140 BC=0000 DE=0200 HL=4200 07:CE44  POP   DE
  39. +AF=0140 BC=0000 DE=003F HL=4200 07:CE45  LD    A, (E010)
  40. +AF=0440 BC=0000 DE=003F HL=4200 07:CE48  PUSH  AF
  41. +AF=0440 BC=0000 DE=003F HL=4200 D8:0038  PUSH  AF
  42. +AF=0440 BC=0000 DE=003F HL=4200 D8:0039  SCF
  43. +AF=0441 BC=0000 DE=003F HL=4200 D8:003A  JR    0045
  44. +AF=0441 BC=0000 DE=003F HL=4200 D8:0045  IN    A, (B3)
  45. +AF=0741 BC=0000 DE=003F HL=4200 D8:0047  LD    (0055), A
  46. +AF=0741 BC=0000 DE=003F HL=4200 D8:004A  LD    A, 00
  47. +AF=0041 BC=0000 DE=003F HL=4200 D8:004C  OUT   (B3), A
  48. +AF=0041 BC=0000 DE=003F HL=4200 D8:004E  JP    C410
  49. +AF=0041 BC=0000 DE=003F HL=4200 00:C410  IN    A, (B2)
  50. +AF=FF41 BC=0000 DE=003F HL=4200 00:C412  LD    (0054), A
  51. +AF=FF41 BC=0000 DE=003F HL=4200 00:C415  LD    A, FF
  52. +AF=FF41 BC=0000 DE=003F HL=4200 00:C417  OUT   (B2), A
  53. +AF=FF41 BC=0000 DE=003F HL=4200 00:C419  LD    (BF7C), HL
  54. +AF=FF41 BC=0000 DE=003F HL=4200 00:C41C  LD    HL, BF79
  55.  AF=FF41 BC=0000 DE=003F HL=BF79 00:C41F  LD    A, (HL)
  56.  AF=8041 BC=0000 DE=003F HL=BF79 00:C420  BIT   7, A
  57.  AF=8091 BC=0000 DE=003F HL=BF79 00:C422  SET   7, (HL)
  58.  AF=8091 BC=0000 DE=003F HL=BF79 00:C424  JR    NZ, C42D
  59. @@ -69805,14 +69826,14 @@
  60.  AF=FF44 BC=0000 DE=003F HL=BFFD 00:C441  PUSH  AF
  61.  AF=FF44 BC=0000 DE=003F HL=BFFD 00:C442  IN    A, (B1)
  62.  AF=D944 BC=0000 DE=003F HL=BFFD 00:C444  LD    (HL), A
  63.  AF=D944 BC=0000 DE=003F HL=BFFD 00:C445  LD    HL, (BF7C)
  64. -AF=D944 BC=0000 DE=003F HL=0000 00:C448  PUSH  HL
  65. -AF=D944 BC=0000 DE=003F HL=0000 00:C449  PUSH  IY
  66. -AF=D944 BC=0000 DE=003F HL=0000 00:C44B  PUSH  IX
  67. -AF=D944 BC=0000 DE=003F HL=0000 00:C44D  LD    A, C9
  68. -AF=C944 BC=0000 DE=003F HL=0000 00:C44F  LD    (0057), A
  69. -AF=C944 BC=0000 DE=003F HL=0000 00:C452  LD    H, A
  70. +AF=D944 BC=0000 DE=003F HL=4200 00:C448  PUSH  HL
  71. +AF=D944 BC=0000 DE=003F HL=4200 00:C449  PUSH  IY
  72. +AF=D944 BC=0000 DE=003F HL=4200 00:C44B  PUSH  IX
  73. +AF=D944 BC=0000 DE=003F HL=4200 00:C44D  LD    A, C9
  74. +AF=C944 BC=0000 DE=003F HL=4200 00:C44F  LD    (0057), A
  75. +AF=C944 BC=0000 DE=003F HL=4200 00:C452  LD    H, A
  76.  AF=C944 BC=0000 DE=003F HL=C900 00:C453  EX    AF, AF'
  77.  AF=0001 BC=0000 DE=003F HL=C900 00:C454  JR    C, C4B2
  78.  AF=0001 BC=0000 DE=003F HL=C900 00:C4B2  PUSH  BC
  79.  AF=0001 BC=0000 DE=003F HL=C900 00:C4B3  PUSH  DE
  80. @@ -70085,10 +70106,10 @@
  81.  AF=FA44 BC=53E5 DE=20FF HL=662A 00:C546  RET   NZ
  82.  AF=FA44 BC=53E5 DE=20FF HL=662A 00:C547  PUSH  BC
  83.  AF=FA44 BC=53E5 DE=20FF HL=662A 00:C548  EX    (SP), HL
  84.  AF=FA44 BC=53E5 DE=20FF HL=53E5 00:C549  ADD   HL, SP
  85. -AF=FA45 BC=53E5 DE=20FF HL=0579 00:C54A  LD    A, FC
  86. -AF=FC45 BC=53E5 DE=20FF HL=0579 00:C54C  POP   HL
  87. +AF=FA45 BC=53E5 DE=20FF HL=056B 00:C54A  LD    A, FC
  88. +AF=FC45 BC=53E5 DE=20FF HL=056B 00:C54C  POP   HL
  89.  AF=FC45 BC=53E5 DE=20FF HL=662A 00:C54D  RET   NC
  90.  AF=FC45 BC=53E5 DE=20FF HL=662A 00:C54E  LD    B, H
  91.  AF=FC45 BC=66E5 DE=20FF HL=662A 00:C54F  LD    C, L
  92.  AF=FC45 BC=662A DE=20FF HL=662A 00:C550  LD    IY, 4000
  93. @@ -70501,10 +70522,10 @@
  94.  AF=FA44 BC=53E5 DE=20FF HL=61FC 00:C546  RET   NZ
  95.  AF=FA44 BC=53E5 DE=20FF HL=61FC 00:C547  PUSH  BC
  96.  AF=FA44 BC=53E5 DE=20FF HL=61FC 00:C548  EX    (SP), HL
  97.  AF=FA44 BC=53E5 DE=20FF HL=53E5 00:C549  ADD   HL, SP
  98. -AF=FA45 BC=53E5 DE=20FF HL=0579 00:C54A  LD    A, FC
  99. -AF=FC45 BC=53E5 DE=20FF HL=0579 00:C54C  POP   HL
  100. +AF=FA45 BC=53E5 DE=20FF HL=056B 00:C54A  LD    A, FC
  101. +AF=FC45 BC=53E5 DE=20FF HL=056B 00:C54C  POP   HL
  102.  AF=FC45 BC=53E5 DE=20FF HL=61FC 00:C54D  RET   NC
  103.  AF=FC45 BC=53E5 DE=20FF HL=61FC 00:C54E  LD    B, H
  104.  AF=FC45 BC=61E5 DE=20FF HL=61FC 00:C54F  LD    C, L
  105.  AF=FC45 BC=61FC DE=20FF HL=61FC 00:C550  LD    IY, 4000
  106. @@ -70777,10 +70798,10 @@
  107.  AF=FA44 BC=53E5 DE=20FF HL=625D 00:C546  RET   NZ
  108.  AF=FA44 BC=53E5 DE=20FF HL=625D 00:C547  PUSH  BC
  109.  AF=FA44 BC=53E5 DE=20FF HL=625D 00:C548  EX    (SP), HL
  110.  AF=FA44 BC=53E5 DE=20FF HL=53E5 00:C549  ADD   HL, SP
  111. -AF=FA45 BC=53E5 DE=20FF HL=0579 00:C54A  LD    A, FC
  112. -AF=FC45 BC=53E5 DE=20FF HL=0579 00:C54C  POP   HL
  113. +AF=FA45 BC=53E5 DE=20FF HL=056B 00:C54A  LD    A, FC
  114. +AF=FC45 BC=53E5 DE=20FF HL=056B 00:C54C  POP   HL
  115.  AF=FC45 BC=53E5 DE=20FF HL=625D 00:C54D  RET   NC
  116.  AF=FC45 BC=53E5 DE=20FF HL=625D 00:C54E  LD    B, H
  117.  AF=FC45 BC=62E5 DE=20FF HL=625D 00:C54F  LD    C, L
  118.  AF=FC45 BC=625D DE=20FF HL=625D 00:C550  LD    IY, 4000
  119. @@ -71183,10 +71204,10 @@
  120.  AF=FA44 BC=53E5 DE=20FF HL=6270 00:C546  RET   NZ
  121.  AF=FA44 BC=53E5 DE=20FF HL=6270 00:C547  PUSH  BC
  122.  AF=FA44 BC=53E5 DE=20FF HL=6270 00:C548  EX    (SP), HL
  123.  AF=FA44 BC=53E5 DE=20FF HL=53E5 00:C549  ADD   HL, SP
  124. -AF=FA45 BC=53E5 DE=20FF HL=0579 00:C54A  LD    A, FC
  125. -AF=FC45 BC=53E5 DE=20FF HL=0579 00:C54C  POP   HL
  126. +AF=FA45 BC=53E5 DE=20FF HL=056B 00:C54A  LD    A, FC
  127. +AF=FC45 BC=53E5 DE=20FF HL=056B 00:C54C  POP   HL
  128.  AF=FC45 BC=53E5 DE=20FF HL=6270 00:C54D  RET   NC
  129.  AF=FC45 BC=53E5 DE=20FF HL=6270 00:C54E  LD    B, H
  130.  AF=FC45 BC=62E5 DE=20FF HL=6270 00:C54F  LD    C, L
  131.  AF=FC45 BC=6270 DE=20FF HL=6270 00:C550  LD    IY, 4000
  132. @@ -71385,10 +71406,10 @@
  133.  AF=FA44 BC=53E5 DE=20FF HL=6280 00:C546  RET   NZ
  134.  AF=FA44 BC=53E5 DE=20FF HL=6280 00:C547  PUSH  BC
  135.  AF=FA44 BC=53E5 DE=20FF HL=6280 00:C548  EX    (SP), HL
  136.  AF=FA44 BC=53E5 DE=20FF HL=53E5 00:C549  ADD   HL, SP
  137. -AF=FA45 BC=53E5 DE=20FF HL=0579 00:C54A  LD    A, FC
  138. -AF=FC45 BC=53E5 DE=20FF HL=0579 00:C54C  POP   HL
  139. +AF=FA45 BC=53E5 DE=20FF HL=056B 00:C54A  LD    A, FC
  140. +AF=FC45 BC=53E5 DE=20FF HL=056B 00:C54C  POP   HL
  141.  AF=FC45 BC=53E5 DE=20FF HL=6280 00:C54D  RET   NC
  142.  AF=FC45 BC=53E5 DE=20FF HL=6280 00:C54E  LD    B, H
  143.  AF=FC45 BC=62E5 DE=20FF HL=6280 00:C54F  LD    C, L
  144.  AF=FC45 BC=6280 DE=20FF HL=6280 00:C550  LD    IY, 4000
  145. @@ -71478,10 +71499,10 @@
  146.  AF=FB20 BC=0000 DE=003F HL=F13D 00:C46D  LD    (0054), HL
  147.  AF=FB20 BC=0000 DE=003F HL=F13D 00:C470  POP   IX
  148.  AF=FB20 BC=0000 DE=003F HL=F13D 00:C472  POP   IY
  149.  AF=FB20 BC=0000 DE=003F HL=F13D 00:C474  POP   HL
  150. -AF=FB20 BC=0000 DE=003F HL=0000 00:C475  LD    (BF7C), HL
  151. -AF=FB20 BC=0000 DE=003F HL=0000 00:C478  LD    HL, BFFD
  152. +AF=FB20 BC=0000 DE=003F HL=4200 00:C475  LD    (BF7C), HL
  153. +AF=FB20 BC=0000 DE=003F HL=4200 00:C478  LD    HL, BFFD
  154.  AF=FB20 BC=0000 DE=003F HL=BFFD 00:C47B  LD    A, (HL)
  155.  AF=D920 BC=0000 DE=003F HL=BFFD 00:C47C  OUT   (B1), A
  156.  AF=D920 BC=0000 DE=003F HL=BFFD 00:C47E  POP   AF
  157.  AF=FF44 BC=0000 DE=003F HL=BFFD 00:C47F  LD    (HL), A
  158. @@ -71497,95 +71518,74 @@
  159.  AF=8091 BC=0000 DE=003F HL=07FF FF:B226  LD    A, H
  160.  AF=0791 BC=0000 DE=003F HL=07FF FF:B227  OUT   (B3), A
  161.  AF=0791 BC=0000 DE=003F HL=07FF FF:B229  LD    A, L
  162.  AF=FF91 BC=0000 DE=003F HL=07FF FF:B22A  LD    HL, (BF7C)
  163. -AF=FF91 BC=0000 DE=003F HL=0000 FF:B22D  JP    0051
  164. -AF=FF91 BC=0000 DE=003F HL=0000 D8:0051  OUT   (B2), A
  165. -AF=FF91 BC=0000 DE=003F HL=0000 D8:0053  LD    A, 3D
  166. -AF=3D91 BC=0000 DE=003F HL=0000 D8:0055  POP   AF
  167. -AF=0140 BC=0000 DE=003F HL=0000 D8:0056  EI  
  168. -AF=0140 BC=0000 DE=003F HL=0000 D8:0057  RET
  169. -AF=0140 BC=0000 DE=003F HL=0000 07:CE30  LD    C, L
  170. -AF=0140 BC=0000 DE=003F HL=0000 07:CE31  DEC   SP
  171. -AF=0140 BC=0000 DE=003F HL=0000 07:CE32  DEC   SP
  172. -AF=0140 BC=0000 DE=003F HL=0000 07:CE33  DEC   SP
  173. -AF=0140 BC=0000 DE=003F HL=0000 07:CE34  DEC   SP
  174. -AF=0140 BC=0000 DE=003F HL=0000 07:CE35  DEC   SP
  175. -AF=0140 BC=0000 DE=003F HL=0000 07:CE36  DEC   SP
  176. -AF=0140 BC=0000 DE=003F HL=0000 07:CE37  DEC   SP
  177. -AF=0140 BC=0000 DE=003F HL=0000 07:CE38  DEC   SP
  178. -AF=0140 BC=0000 DE=003F HL=0000 07:CE39  DEC   SP
  179. -AF=0140 BC=0000 DE=003F HL=0000 07:CE3A  DEC   SP
  180. -AF=0140 BC=0000 DE=003F HL=0000 07:CE3B  POP   HL
  181. -AF=0140 BC=0000 DE=003F HL=07FF 07:CE3C  PUSH  HL
  182. -AF=0140 BC=0000 DE=003F HL=07FF 07:CE3D  DEC   SP
  183. -AF=0140 BC=0000 DE=003F HL=07FF 07:CE3E  DEC   SP
  184. -AF=0140 BC=0000 DE=003F HL=07FF 07:CE3F  PUSH  DE
  185. -AF=0140 BC=0000 DE=003F HL=07FF 07:CE40  LD    DE, 0200
  186. -AF=0140 BC=0000 DE=0200 HL=07FF 07:CE43  ADD   HL, DE
  187. -AF=0148 BC=0000 DE=0200 HL=09FF 07:CE44  POP   DE
  188. -AF=0148 BC=0000 DE=003F HL=09FF 07:CE45  LD    A, (E010)
  189. -AF=0448 BC=0000 DE=003F HL=09FF 07:CE48  PUSH  AF
  190. -AF=0448 BC=0000 DE=003F HL=09FF 07:CE49  LD    A, (E011)
  191. -AF=0048 BC=0000 DE=003F HL=09FF 07:CE4C  INC   A
  192. -AF=0100 BC=0000 DE=003F HL=09FF 07:CE4D  LD    (E011), A
  193. -AF=0100 BC=0000 DE=003F HL=09FF 07:CE50  LD    A, (E016)
  194. -AF=0100 BC=0000 DE=003F HL=09FF 07:CE53  CALL  CC83
  195. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC83  PUSH  BC
  196. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC84  PUSH  DE
  197. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC85  PUSH  IX
  198. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC87  PUSH  IY
  199. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC89  PUSH  HL
  200. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC8A  LD    (IY+0A), A
  201. -AF=0100 BC=0000 DE=003F HL=09FF 07:CC8D  CP    05
  202. -AF=0193 BC=0000 DE=003F HL=09FF 07:CC8F  JR    NZ, CCA0
  203. -AF=0193 BC=0000 DE=003F HL=09FF 07:CCA0  PUSH  HL
  204. -AF=0193 BC=0000 DE=003F HL=09FF 07:CCA1  PUSH  IX
  205. -AF=0193 BC=0000 DE=003F HL=09FF 07:CCA3  POP   HL
  206. +AF=FF91 BC=0000 DE=003F HL=4200 FF:B22D  JP    0051
  207. +AF=FF91 BC=0000 DE=003F HL=4200 D8:0051  OUT   (B2), A
  208. +AF=FF91 BC=0000 DE=003F HL=4200 D8:0053  LD    A, 3D
  209. +AF=3D91 BC=0000 DE=003F HL=4200 D8:0055  POP   AF
  210. +AF=0440 BC=0000 DE=003F HL=4200 D8:0056  EI  
  211. +AF=0440 BC=0000 DE=003F HL=4200 D8:0057  RET
  212. +AF=0440 BC=0000 DE=003F HL=4200 07:CE49  LD    A, (E011)
  213. +AF=0040 BC=0000 DE=003F HL=4200 07:CE4C  INC   A
  214. +AF=0100 BC=0000 DE=003F HL=4200 07:CE4D  LD    (E011), A
  215. +AF=0100 BC=0000 DE=003F HL=4200 07:CE50  LD    A, (E016)
  216. +AF=0100 BC=0000 DE=003F HL=4200 07:CE53  CALL  CC83
  217. +AF=0100 BC=0000 DE=003F HL=4200 07:CC83  PUSH  BC
  218. +AF=0100 BC=0000 DE=003F HL=4200 07:CC84  PUSH  DE
  219. +AF=0100 BC=0000 DE=003F HL=4200 07:CC85  PUSH  IX
  220. +AF=0100 BC=0000 DE=003F HL=4200 07:CC87  PUSH  IY
  221. +AF=0100 BC=0000 DE=003F HL=4200 07:CC89  PUSH  HL
  222. +AF=0100 BC=0000 DE=003F HL=4200 07:CC8A  LD    (IY+0A), A
  223. +AF=0100 BC=0000 DE=003F HL=4200 07:CC8D  CP    05
  224. +AF=0193 BC=0000 DE=003F HL=4200 07:CC8F  JR    NZ, CCA0
  225. +AF=0193 BC=0000 DE=003F HL=4200 07:CCA0  PUSH  HL
  226. +AF=0193 BC=0000 DE=003F HL=4200 07:CCA1  PUSH  IX
  227. +AF=0193 BC=0000 DE=003F HL=4200 07:CCA3  POP   HL
  228.  AF=0193 BC=0000 DE=003F HL=E020 07:CCA4  LD    A, L
  229.  AF=2093 BC=0000 DE=003F HL=E020 07:CCA5  LD    (IY), A
  230.  AF=2093 BC=0000 DE=003F HL=E020 07:CCA8  LD    A, H
  231.  AF=E093 BC=0000 DE=003F HL=E020 07:CCA9  POP   HL
  232. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCAA  LD    (IY+01), A
  233. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCAD  LD    (IY+02), E
  234. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCB0  LD    (IY+03), D
  235. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCB3  LD    (IY+04), C
  236. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCB6  LD    (IY+05), B
  237. -AF=E093 BC=0000 DE=003F HL=09FF 07:CCB9  EXX
  238. +AF=E093 BC=0000 DE=003F HL=4200 07:CCAA  LD    (IY+01), A
  239. +AF=E093 BC=0000 DE=003F HL=4200 07:CCAD  LD    (IY+02), E
  240. +AF=E093 BC=0000 DE=003F HL=4200 07:CCB0  LD    (IY+03), D
  241. +AF=E093 BC=0000 DE=003F HL=4200 07:CCB3  LD    (IY+04), C
  242. +AF=E093 BC=0000 DE=003F HL=4200 07:CCB6  LD    (IY+05), B
  243. +AF=E093 BC=0000 DE=003F HL=4200 07:CCB9  EXX
  244.  AF=E093 BC=0000 DE=FAC5 HL=AB7E 07:CCBA  LD    (IY+06), E
  245.  AF=E093 BC=0000 DE=FAC5 HL=AB7E 07:CCBD  LD    (IY+07), D
  246.  AF=E093 BC=0000 DE=FAC5 HL=AB7E 07:CCC0  LD    (IY+08), C
  247.  AF=E093 BC=0000 DE=FAC5 HL=AB7E 07:CCC3  LD    (IY+09), B
  248. ...
  249. @@ -71733,15 +71733,15 @@
  250.  AF=FFAC BC=0A00 DE=7E00 HL=FC00 07:D16F  RET
  251.  AF=FFAC BC=0A00 DE=7E00 HL=FC00 07:D29C  XOR   A
  252.  AF=0044 BC=0A00 DE=7E00 HL=FC00 07:D29D  CP    E
  253.  AF=0042 BC=0A00 DE=7E00 HL=FC00 07:D29E  POP   HL
  254. -AF=0042 BC=0A00 DE=7E00 HL=09FF 07:D29F  JR    NZ, D2AC
  255. -AF=0042 BC=0A00 DE=7E00 HL=09FF 07:D2A1  LD    BC, 0200
  256. -AF=0042 BC=0200 DE=7E00 HL=09FF 07:D2A4  LD    E, FF
  257. -AF=0042 BC=0200 DE=7EFF HL=09FF 07:D2A6  CALL  D0C8
  258. -AF=0042 BC=0200 DE=7EFF HL=09FF 07:D0C8  PUSH  BC
  259. -AF=0042 BC=0200 DE=7EFF HL=09FF 07:D0C9  PUSH  HL
  260. -AF=0042 BC=0200 DE=7EFF HL=09FF 07:D0CA  LD    HL, FC00
  261. +AF=0042 BC=0A00 DE=7E00 HL=4200 07:D29F  JR    NZ, D2AC
  262. +AF=0042 BC=0A00 DE=7E00 HL=4200 07:D2A1  LD    BC, 0200
  263. +AF=0042 BC=0200 DE=7E00 HL=4200 07:D2A4  LD    E, FF
  264. +AF=0042 BC=0200 DE=7EFF HL=4200 07:D2A6  CALL  D0C8
  265. +AF=0042 BC=0200 DE=7EFF HL=4200 07:D0C8  PUSH  BC
  266. +AF=0042 BC=0200 DE=7EFF HL=4200 07:D0C9  PUSH  HL
  267. +AF=0042 BC=0200 DE=7EFF HL=4200 07:D0CA  LD    HL, FC00
  268.  AF=0042 BC=0200 DE=7EFF HL=FC00 07:D0CD  LD    A, FF
  269.  AF=FF42 BC=0200 DE=7EFF HL=FC00 07:D0CF  LD    C, 20
  270.  AF=FF42 BC=0220 DE=7EFF HL=FC00 07:D0D1  LD    B, 00
  271.  AF=FF42 BC=0020 DE=7EFF HL=FC00 07:D0D3  LD    (HL), A
  272. @@ -71755,34143 +71755,18295 @@
  273.  AF=FF2A BC=FF20 DE=7EFF HL=FC00 07:D0D6  JR    NZ, D0DD
  274.  AF=FF2A BC=FF20 DE=7EFF HL=FC00 07:D0DD  DEC   A
  275.  AF=FEAA BC=FF20 DE=7EFF HL=FC00 07:D0DE  CP    (HL)
  276.  AF=FE6A BC=FF20 DE=7EFF HL=FC00 07:D0DF  POP   HL
  277. -AF=FE6A BC=FF20 DE=7EFF HL=09FF 07:D0E0  POP   BC
  278. -AF=FE6A BC=0200 DE=7EFF HL=09FF 07:D0E1  RET   NZ
  279. -AF=FE6A BC=0200 DE=7EFF HL=09FF 07:D0E2  LD    A, (E002)
  280. -AF=006A BC=0200 DE=7EFF HL=09FF 07:D0E5  AND   02
  281. -AF=0054 BC=0200 DE=7EFF HL=09FF 07:D0E7  LD    A, 80
  282. -AF=8054 BC=0200 DE=7EFF HL=09FF 07:D0E9  LD    (FC03), A
  283. -AF=8054 BC=0200 DE=7EFF HL=09FF 07:D0EC  LD    A, (FC00)
  284. -AF=FE54 BC=0200 DE=7EFF HL=09FF 07:D0EF  JR    NZ, D0FF
  285. -AF=FE54 BC=0200 DE=7EFF HL=09FF 07:D0F1  EX    DE, HL
  286. -AF=FE54 BC=0200 DE=09FF HL=7EFF 07:D0F2  LD    HL, FC00
  287. -AF=FE54 BC=0200 DE=09FF HL=FC00 07:D0F5  LDIR
  288. -AF=FE4C BC=01FF DE=0A00 HL=FC01 07:D0F5  LDIR
  289. -AF=FE6C BC=01FE DE=0A01 HL=FC02 07:D0F5  LDIR
  290. -AF=FE6C BC=01FD DE=0A02 HL=FC03 07:D0F5  LDIR
  291. -AF=FE64 BC=01FC DE=0A03 HL=FC04 07:D0F5  LDIR
  292. -AF=FE6C BC=01FB DE=0A04 HL=FC05 07:D0F5  LDIR
  293. ...
Title: Re: EP128emu
Post by: IstvanV on 2016.October.19. 10:07:23
A hibát valószínűleg ez okozza:
Code: ZiLOG Z80 Assembler
  1. .   CC83  C5           PUSH  BC
  2. .   CC84  D5           PUSH  DE
  3. .   CC85  DD E5        PUSH  IX
  4. .   CC87  FD E5        PUSH  IY
  5. .   CC89  E5           PUSH  HL
A PUSH HL által mentett címet (sokkal) később itt olvassa egy POP HL:
Code: ZiLOG Z80 Assembler
  1. .   CE31  3B           DEC   SP
  2. .   CE32  3B           DEC   SP
  3. .   CE33  3B           DEC   SP
  4. .   CE34  3B           DEC   SP
  5. .   CE35  3B           DEC   SP
  6. .   CE36  3B           DEC   SP
  7. .   CE37  3B           DEC   SP
  8. .   CE38  3B           DEC   SP
  9. .   CE39  3B           DEC   SP
  10. .   CE3A  3B           DEC   SP
  11. .   CE3B  E1           POP   HL
Amint az a sok DEC SP utasításból látható, ezt a címet valójában már leemelte a veremről a kód valahol, ezért kell visszaléptetni a veremmutatót. Probléma azonban, hogy itt engedélyezettek a megszakítások, tehát a mentett címet az EXOS bármikor felülírhatja. A CC83h-s rutin elején viszonylag könnyen be lehetett építeni egy DI-t:
Code: ZiLOG Z80 Assembler
  1. .   CC83  F3           DI  
  2. .   CC84  C5           PUSH  BC
  3. .   CC85  D5           PUSH  DE
  4. .   CC86  DD E5        PUSH  IX
  5. .   CC88  FD E5        PUSH  IY
  6. .   CC8A  E5           PUSH  HL
  7. .   CC8B  FD 77 0A     LD    (IY+0A), A
  8. .   CC8E  FE 05        CP    05
  9. .   CC90  20 0F        JR    NZ, CCA1
  10. .   CC92  3A 11 E0     LD    A, (E011)
  11. .   CC95  FE 01        CP    01
  12. .   CC97  20 08        JR    NZ, CCA1
  13. .   CC99  ED 53 12 E0  LD    (E012), DE
  14. .   CC9D  ED 43 14 E0  LD    (E014), BC
  15. .   CCA1  DD E5        PUSH  IX
  16. .   CCA3  E3           EX    (SP), HL
De ez még nem elég, mert az itt található EI továbbra is hibát okozhat:
Code: ZiLOG Z80 Assembler
  1. .   CEDB  F3           DI  
  2. .   CEDC  CD 61 CC     CALL  CC61
  3. .   CEDF  E5           PUSH  HL
  4. .   CEE0  DD 5E 01     LD    E, (IX+01)
  5. .   CEE3  DD 56 02     LD    D, (IX+02)
  6. .   CEE6  DD 4E 03     LD    C, (IX+03)
  7. .   CEE9  DD 46 04     LD    B, (IX+04)
  8. .   CEEC  DD 6E 05     LD    L, (IX+05)
  9. .   CEEF  DD E1        POP   IX
  10. .   CEF1  CD 66 D4     CALL  D466
  11. .   CEF4  FB           EI  
  12. .   CEF5  C8           RET   Z
Itt az EI törlése miatt lenne valamilyen probléma?

Szerk.: módosított ROM, ez javítja a véletlenszerűen hiányzó meghajtókat, de azt nem teszteltem, hogy az EI törlésének van-e hátránya: :oops:
[attachurl=1]
Code: Diff
  1. @@ -2029,28 +2029,28 @@
  2.  .   CC7B  E1           POP   HL
  3.  .   CC7C  E5           PUSH  HL
  4.  .   CC7D  CD 1D CF     CALL  CF1D
  5.  .   CC80  D1           POP   DE
  6.  .   CC81  C1           POP   BC
  7.  .   CC82  C9           RET
  8. -.   CC83  C5           PUSH  BC
  9. -.   CC84  D5           PUSH  DE
  10. -.   CC85  DD E5        PUSH  IX
  11. -.   CC87  FD E5        PUSH  IY
  12. -.   CC89  E5           PUSH  HL
  13. -.   CC8A  FD 77 0A     LD    (IY+0A), A
  14. -.   CC8D  FE 05        CP    05
  15. -.   CC8F  20 0F        JR    NZ, CCA0
  16. -.   CC91  3A 11 E0     LD    A, (E011)
  17. -.   CC94  FE 01        CP    01
  18. -.   CC96  20 08        JR    NZ, CCA0
  19. -.   CC98  ED 53 12 E0  LD    (E012), DE
  20. -.   CC9C  ED 43 14 E0  LD    (E014), BC
  21. -.   CCA0  E5           PUSH  HL
  22. +.   CC83  F3           DI  
  23. +.   CC84  C5           PUSH  BC
  24. +.   CC85  D5           PUSH  DE
  25. +.   CC86  DD E5        PUSH  IX
  26. +.   CC88  FD E5        PUSH  IY
  27. +.   CC8A  E5           PUSH  HL
  28. +.   CC8B  FD 77 0A     LD    (IY+0A), A
  29. +.   CC8E  FE 05        CP    05
  30. +.   CC90  20 0F        JR    NZ, CCA1
  31. +.   CC92  3A 11 E0     LD    A, (E011)
  32. +.   CC95  FE 01        CP    01
  33. +.   CC97  20 08        JR    NZ, CCA1
  34. +.   CC99  ED 53 12 E0  LD    (E012), DE
  35. +.   CC9D  ED 43 14 E0  LD    (E014), BC
  36.  .   CCA1  DD E5        PUSH  IX
  37. -.   CCA3  E1           POP   HL
  38. +.   CCA3  E3           EX    (SP), HL
  39.  .   CCA4  7D           LD    A, L
  40.  .   CCA5  FD 77 00     LD    (IY), A
  41.  .   CCA8  7C           LD    A, H
  42.  .   CCA9  E1           POP   HL
  43.  .   CCAA  FD 77 01     LD    (IY+01), A
  44.  .   CCAD  FD 73 02     LD    (IY+02), E
  45. @@ -2345,13 +2345,13 @@
  46.  .   CEE3  DD 56 02     LD    D, (IX+02)
  47.  .   CEE6  DD 4E 03     LD    C, (IX+03)
  48.  .   CEE9  DD 46 04     LD    B, (IX+04)
  49.  .   CEEC  DD 6E 05     LD    L, (IX+05)
  50.  .   CEEF  DD E1        POP   IX
  51.  .   CEF1  CD 66 D4     CALL  D466
  52. -.   CEF4  FB           EI  
  53. +.   CEF4  F3           DI  
  54.  .   CEF5  C8           RET   Z
  55.  .   CEF6  E5           PUSH  HL
  56.  .   CEF7  21 01 CF     LD    HL, CF01
  57.  .   CEFA  23           INC   HL
  58.  .   CEFB  0F           RRCA
  59.  .   CEFC  30 FC        JR    NC, CEFA
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.19. 10:53:13
Beépítve, ha nincs más bug :oops: :oops: :oops: akkor frissítem a SD ROM csomagot is.
Title: Re: EP128emu
Post by: IstvanV on 2016.October.19. 19:47:57
A ROM csomagot (https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/30/) frissítettem:
- zx41uk.rom
- sdext05.rom
- EXDOS 1.4 (csak a WD1770/IS-DOS-os változatokat tartalmazza, talán a már nem használt exdos13.rom helyére kerülhetne az IS-DOS nélküli EXDOS 1.4?)

"EP kompatibilis" csomag, nem tudom, hasznos-e, de ezen működik az :UNCOMPRESS: :)
[attachurl=1]
Title: Re: EP128emu
Post by: Attus on 2016.October.19. 21:00:40
A linuxos wrapper még a régi romhalmazt tölti le. ( https://github.com/istvan-v/ep128emu/blob/master/resource/makecfg-wrapper)
Nem lehetne átírni az új romhalmazra?
Title: Re: EP128emu
Post by: IstvanV on 2016.October.19. 21:02:00
Új beta verzió a GitHub-on (https://github.com/istvan-v/ep128emu/releases/tag/2.0.10-beta_20161020):
* az installer az aktuális ROM csomagot letölti a fórumról (így azonban INetC (http://nsis.sourceforge.net/Inetc_plug-in) plugin kellett az installer készítéséhez, mert a régi NSISdl csak HTTP-t támogat)
* SD kártya emuláció:
- az image méret ellenőrzésében egy hiba javítva
- az állapotregiszter nem használt bitjei olvasáskor 1 értékűek
- debuggerben a 2. biten az idle állapot olvasható, a 0-1. biteken a CS0 és CS1
- a LED kijelző mutatja az SD I/O-t is, bár ez a műveletek rövid időtartama miatt néha nehezen látható
- a "reset machine configuration" (Shift+F11) törli az SRAM tartalmát
* CMOS Z80-at emuláló verzióban a disassembler az OUT (C),0 utasítás helyett OUT (C),FF-et ír ki
* az assembler elfogadja a nem dokumentált IN (C) és a CPU típusának megfelelő OUT (C),0/FF utasításokat
* a snapshot tömörítés valamivel gyorsabb és (ez a file tartalmától függhet) hatékonyabb lett, a tömörítést az emulátor ablak címe ("Compressing file...") és a "várakozás" egér kurzor jelzi, bár gyors gépeken ezek általában csak rövid ideig láthatók (az emulátorba épített epcompress ki tudja használni a több magos CPU-k lehetőségeit)
* a makecfg frissítve az új ROM csomaghoz, új SD kártyás konfigurációk, a zx41.rom zx41uk.rom-ra cserélve minden nem magyar konfigurációnál, Spectrumon új 48K-s "GW03" konfiguráció
Title: Re: EP128emu
Post by: IstvanV on 2016.October.19. 21:07:31
Nem lehetne átírni az új romhalmazra?

Át lehetne írni, bár a fórumos cím csak átmeneti megoldás, a kész verzióban valószínűleg már nem ez lesz a letöltési cím, illetve a fórumon a csomag minden frissítésekor is változik a cím, mert a file-t nem a neve hanem a feltöltés száma (most éppen 16433) alapján lehet elérni, ami természetesen minden új feltöltésnél más lenne.
Title: Re: EP128emu
Post by: Attus on 2016.October.19. 21:08:56
A wget https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/?action=dlattach;attach=16433 most csak egy html -t szed le.

Így nem is lehet tehát átírni.
Title: Re: EP128emu
Post by: Attus on 2016.October.19. 21:29:49
KItaláltam, működik. Kellett egy  \ escape jel a ;attach elé
:)
Majd megfoltozom a csomagomban, a githubra nem emelem be, oda majd a véglegeset majd te úgyis berakod.

wget -O ep128emu_roms-2.0.10.bin https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/?action=dlattach\;attach=16433

Csupán figyelnem kell a letöltési cím változására és követni a folttal.
Amúgy én a letöltő wrapperrel nem vagyok elégedett, mert a mostani csak akkor tölti le a romhalmazt, ha nincs "$HOME/.ep128emu/roms/ep128emu_roms-2.0.10.bin"
Ha majd frissül a romhalmaz, vagy maga az emu, akkor mindaddig ott fog csúnyálkodni a régi, míg az egészet a júzer le nem törli és le nem futtatja a makecfg -t.
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.19. 21:34:11
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.
Illetve ennek egy speciális esete az SD cartridge-re kerülő EXDOS, ahol az SDEXT a társbérlő, valamint a ROM vége még 2000H-val lejebb van, mivel ott kezdődik az SRAM a 7-es szegmensen. (Itt majd az ISDOS a lapozható részbe fog bekerülni.)
Title: Re: EP128emu
Post by: Zozosoft on 2016.October.19. 21:42:17
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