Author Topic: EP128emu (Read 400807 times)

IstvanV · « **Reply #645 on:** 2016.September.09. 22:34:59 »

Új MinGW (mingw-w64) csomagok:

mingw_w64-x86.7z (32 bites)
mingw_w64-x64.7z (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)
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:
[ Guests cannot view attachments ]
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 használható, azonban a makensis futtatásakor /DWIN64 kell a 64 bites csomaghoz.

IstvanV · « **Reply #646 on:** 2016.September.10. 13:54:59 »

[ Guests cannot view attachments ]
[ Guests cannot view attachments ]

endi · « **Reply #647 on:** 2016.September.10. 13:57:22 »

ezek amúgy most mik? új verzió, amiben van valami új?

IstvanV · « **Reply #648 on:** 2016.September.10. 14:27:51 »

Quote from: endi on 2016.September.10. 13:57:22

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) 960% 2590% 2.0.9.2 x86 940% 2775% 2.0.9.2 x64 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.

Zozosoft · « **Reply #649 on:** 2016.September.10. 14:34:52 »

A segédprogramoknál is van újabb CPU-kra optimalizálás?

IstvanV · « **Reply #650 on:** 2016.September.10. 14:38:21 »

Quote from: Zozosoft on 2016.September.10. 14:34:52

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.

Attus · « **Reply #651 on:** 2016.September.10. 16:27:16 »

Quote from: IstvanV on 2016.September.10. 14:38:21

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.

IstvanV · « **Reply #652 on:** 2016.September.16. 17:17:20 »

Quote from: lgb on 2016.September.06. 21:02:45

Szerintem en is azzal nyomtam travis-on 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 található GCC 6.2.0-s csomagot használom a teszteléshez.

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.

Quote from: Attus on 2016.September.10. 16:27:16

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.

IstvanV · « **Reply #653 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

Attus · « **Reply #654 on:** 2016.September.16. 20:08:18 »

Quote from: IstvanV on 2016.September.16. 17:17:20

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.

IstvanV · « **Reply #655 on:** 2016.September.17. 10:55:53 »

Quote from: Attus on 2016.September.16. 20:08:18

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

Attus · « **Reply #656 on:** 2016.September.17. 16:12:07 »

Köszönöm a felhomályosítést, ezek szerint tévedtem.

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

IstvanV · « **Reply #657 on:** 2016.September.19. 10:49:29 »

Néhány EnterMice kérdés:

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

Quote from: Attus on 2016.September.17. 16:12:07

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

lgb · « **Reply #658 on:** 2016.September.19. 11:20:59 »

Quote from: IstvanV on 2016.September.19. 10:49:29

Néhány EnterMice kérdés:

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

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.

gflorez · « **Reply #659 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.

Author Topic: EP128emu (Read 400807 times)

IstvanV

Re: EP128emu

IstvanV

Re: EP128emu

endi

Re: EP128emu

IstvanV

Re: EP128emu

Zozosoft

Re: EP128emu

IstvanV

Re: EP128emu

Attus

Re: EP128emu

IstvanV

Re: EP128emu

IstvanV

Re: EP128emu

Attus

Re: EP128emu

IstvanV

Re: EP128emu

Attus

Re: EP128emu

IstvanV

Re: EP128emu

lgb

Re: EP128emu

gflorez

Re: EP128emu