Welcome, Guest. Please login or register.


Author Topic: EP128emu (Read 402180 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #570 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.

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #571 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 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.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #572 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 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! :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #573 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.

[ Guests cannot view attachments ]

Kisebb javítás az installerben:

[ Guests cannot view attachments ]

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #574 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.

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 9954
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: EP128emu
« Reply #575 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.
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #576 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.
« Last Edit: 2016.August.12. 23:03:17 by Attus »

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #577 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ő.
« Last Edit: 2016.August.13. 09:37:34 by Attus »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #578 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.
« Last Edit: 2016.August.13. 09:45:55 by IstvanV »

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #579 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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #580 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)
« Last Edit: 2016.August.13. 13:02:50 by IstvanV »

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #581 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.
« Last Edit: 2016.August.13. 16:37:18 by Attus »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #582 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 ...

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EP128emu
« Reply #583 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.
« Last Edit: 2016.August.13. 17:10:28 by Attus »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #584 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 ...