Akkor viszont merge-olni kene a plus4 es az ep128emu project-et :D
Az alapvető probléma az, hogy az ep128emu a többi gépet gyakorlatilag az EP lebutított változataként kezeli, ez viszont nem igazán jó megoldás a Plus/4 esetében, különösen mivel az a legbonyolultabb és legjobb minőségű emulátorom, ha rajtam kívül nem is használja senki.Ebben biztos vagy, a múltkor valami +4-es cuccot néztem meg, és ha jól emlékszem Ergognomik és Zozo le is tolt, hogy a Vice-on próbáltam (és nem a Plus4emun), és nem igazán működött, volt még 1-2 emu amit ajánlottak, hát láss csodát, amit néztem annál a Plus4emu volt épp a legjobb, úgyhogy gopndolom plus4-es körökben is használhatják jópáran, pláne aki programot is ír, mint említettük Zozóval ha bármely más emulátoron kell debuggerhez nyúlni, előtte 1-2 pszichiátriai kezelésre van szükség, utána meg fél évre :D
Ebben biztos vagy, a múltkor valami +4-es cuccot néztem meg, és ha jól emlékszem Ergognomik és Zozo le is tolt, hogy a Vice-on próbáltam (és nem a Plus4emun), és nem igazán működött, volt még 1-2 emu amit ajánlottak, hát láss csodát, amit néztem annál a Plus4emu volt épp a legjobb, úgyhogy gopndolom plus4-es körökben is használhatják jópáran, pláne aki programot is ír, mint említettük Zozóval ha bármely más emulátoron kell debuggerhez nyúlni, előtte 1-2 pszichiátriai kezelésre van szükség, utána meg fél évre :D+~1
Az alapvető probléma az, hogy az ep128emu a többi gépet gyakorlatilag az EP lebutított változataként kezeli, ez viszont nem igazán jó megoldás a Plus/4 esetében, különösen mivel az a legbonyolultabb és legjobb minőségű emulátorom, ha rajtam kívül nem is használja senki.
Sőt, korábban már volt is panasz, hogy István elhanyagolta a plus4emut, és újabb Linux disztribúciókon nem, vagy csak nagyon rosszul futott.
hirtelen nem emlékeztem rá lehet-e venni, hogy a SID emulációt a natív C64-es címen keresztül futtassa.
nem emlékeztem rá lehet-e venni, hogy a SID emulációt a natív C64-es címen keresztül futtassa.
A Git forráskódban már van ilyen:
(Attachment Link)
Lehetne a bétából kérni linuxos x86-64-es fordítást is? Olyan "mindent bele" verziót, mint ami a régi SF-os oldalról is letölthető? (Saját forgatáshoz kellene egy csomó devel cucc. :( )
Lehetne a bétából kérni linuxos x86-64-es fordítást is? Olyan "mindent bele" verziót, mint ami a régi SF-os oldalról is letölthető? (Saját forgatáshoz kellene egy csomó devel cucc. :( )És mi az akadálya annak, hogy ezeket a devel cuccokat felrakd ideiglenesen a disztród központi tárójából? Helyszűke a mai tárbő világban? A fordítás végeztével aztán már le is gyalulhatod őket, hisz az emu futásához azok már feleslegesek.
Ha nem talál valami, úgyis kukorékol, akkor megtömöd azzal amit kér, amit kér azt feljegyzed, mert arra a fordítás végén már úgysem lesz szükséged többé.
A végén meg futtathatod is helyben, vagy akár rendszergazdaként mehet a scons install, majd a takarítás, oszt jóccakát.
Nem is tudom, hogy csinált vajon István a scons -hoz uninstall részt is?
De az univerzális "mindent bele" hízott linux binárishalmazt sem.
Ennél egyszerűbb letölteni a bináris verziót. :)
Ennek ilyen kis méretű programnál nincs különösebb jelentősége.Ezt is tudom, de én akkor sem tudok kibújni a bőrömből. Sok kicsi sokra megy.
A frissített bináris csomagok már letölthetők innen (https://github.com/istvan-v/plus4emu/releases).
És mi az akadálya annak, hogy ezeket a devel cuccokat felrakd ideiglenesen a disztród központi tárójából?
Sokkal jobb minden disztróhoz a disztró karbantarói által elkészített feltelepíthető , a disztró igényeihez jól pásszított kész és karcsú és bármikor fájdalom nélkül könnyedén levakarható csomag.
Egyébként milyen disztród van?
A frissített bináris csomagok már letölthetők innen (https://github.com/istvan-v/plus4emu/releases).
Kipróbáltam mindkét x86-64-es verziót, látszólag semmi különbség. Ebbe bele van fordítva a lua interpreter is? Még sosem használtam lua-t, fogalmam sincs hogyan lehet kipróbálni.
Valami egyszerű teszt-szkript nincs kéznél? :)
Report: a debuggerben a stack dump nem görgethető,
illetve a meghajtó CPU-ja esetén mintha nem is jól működne...
Fedora (https://getfedora.org/)-t, ott már nagyobb a gyári csomag esélye.Hajrá!
A két x86_64 változat között csak a Lua verzió a különbség, az egyik a Lua 5.3.3-at használja, a másik pedig a LuaJIT 2.1.0 beta2-t. Az utóbbi gyorsabb, mivel interpreter helyett JIT fordító, de a nyelv régebbi verziójára épül, így nem támogatja például az &, |, ~, << és >> műveleteket.
A debugger Lua programozása hasonló az ep128emu-hoz
Valóban, ez az ep128emu esetében is így van, csak a "Memory dump" és a disassembler görgethető. De ha hasznos lenne a veremnél (eredetileg csak a veremmutató körüli néhányszor 10 byte-os terület megjelenítése volt a célja), akkor ott is meg lehetne oldani.
A debugger természetesen csak létező hardverről tud használható információt adni, ezért előbb a meghajtót engedélyezni kell D64 file megnyitásával.
A Fedora rpm csináló rendszere is királyi! Kreálj egy plus4emu.spec -t!
Más úgysem fog csinálni hivatalból, arra szerintem hiába vársz.
Hmmm... Van itt egy kis furcsaság. :) Vagyis: sejtem hogy mi van. A jelenség akkor jön elő, ha 1551-es meghajtó emuláció van bekapcsolva. A STACK ablakban a "*" gondolom azt jelzi, hogy hova került be az utolsó adat, tehát az SP+1 pozíció van jelölve.
A következőek nem Plus/4 emulátor specifikusak, és legfeljebb csak hangos gondolkodásnak nevezném, de semmiképpen sem igénynek. Lehetséges lenne a debugger ablakot részekre szétszedni, és nem egyetlen füles felületbe sűríteni? Egynél több memória megjelenítő ablakot használni, hogy például a forrás1-művelet-forrás2=cél, illetve más hasonló típusú felhasználásokat könnyebb legyen nyomonkövetni?
Végrehajtás (x) típusú töréspontot bevezetni?
Te is így érzed? :-D Valójában kellene egy olyan csomag, ami scons-t használ, annak a .spec fájljából talán ki tudnék okoskodni valamit. Egyelőre már annak is tudok örülni, ha egy sima "configure, make, make install" típusú stuffhoz sikerül a csomag. :)Hármat már találtam is hirtelenjében.
Valóban így működik, de egyszerűen módosítható lenne, hogy ilyenkor $0200-nál mutassa látható megjelölt pozíció nélkül, ha az javítaná a használhatóságot.
Hármat már találtam is hirtelenjében.
;-)
Jut eszembe: a memóriakonfigurációnál meg lehet adni 1581 ROM tartalmat is. Ilyen meghajtót is tud emulálni? Ha igen, hogyan? :)
Végrehajtás (x) típusú töréspontot bevezetni?
Nekem úgy tűnik, hogy az eredeti reSID fejlesztése kb. tényleg a 0.16-os verzióval ért véget, után már a csak reSID-fp nevű forkját vitték tovább. Ez most – ha minden igaz – a libsidplayfp (https://sourceforge.net/projects/sidplay-residfp/?source=typ_redirect) projekt részeként érhető el.
A libsidplayfp-t is megnéztem, de itt nagyon eltérőnek tűnik a kód az eredeti reSID-hez képest, és egyelőre még nem tudom, pontosan melyik részeit kellene felhasználni csak a SID emulációhoz. :oops:Felületesen belepillantva talán a builders könyvtárban levő dolgok amik fontosak, ha más projektben akarnák használni őket.
(a Plus/4-es SID kártyák általában 8580-at használnak?)
Ha a "*" az utoljára betett adatot jelöli, akkor talán érdemes lenne SP=$FF esetén a $0200 körüli tartalmat mutatni jelölés nélkül.
Ez a változtatás már megtalálható (egyebek mellett) a Git forráskódban.
Az időzítő probléma egyébként a CIA emulációját is érintheti, bár csak az 1581-es floppy meghajtó használ ilyet, így talán kevésbé jelent problémát.
Hacsak az ep128emu mintájára nem csinálsz ebből is C64 meg VIC20 emulátort is...Nem rossz ötlet! :ds_icon_cheesygrin:
A GitHub-on egy ideje már van 1.2.10 (https://github.com/istvan-v/plus4emu/releases) verzió. :)
Az időzítő probléma egyébként a CIA emulációját is érintheti, bár csak az 1581-es floppy meghajtó használ ilyet, így talán kevésbé jelent problémát. Az itt (http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/cia6526.zip) található részletes leírás szerint 2 időtartam beállítása esetén például a számláló értéke 2,1,2,2,1,2,2,1,... lesz, azaz 3 ciklusonként generál megszakítást 2 helyett. Nem tudom, a 6526 és a 8520 között van-e különbség.
Az 1551-ben, pont mint az 1541-ben is, "kézzel" kell törölni a Byte-Ready-t, nem történik meg automatikusan. A törlő jel viszont maga a TIA _CS-je, tehát bármilyen TIA elérés történik, az törli a Byte-Ready-t. Normál lemezolvasásnál a Byte-Ready jel után a bejött adat kiolvasása történik, ami a TIA egyik regiszterének az olvasását jelenti, ott az a lépés egyben a törlés is. (Írásnál ugyanez a logika.) A Byte-Ready (a beolvasott adattal egyetemben) a következő adat teljes beeséséig "él", tehát ezidő alatt bármikor kiolvasható az adat is meg a (még nem törölt) Byte-Ready is.
Módosítottam, most csak TIA hozzáférésre törlődik.
A GitHub-on jeleztek még egy lehetséges hibát (https://github.com/istvan-v/plus4emu/issues/2), ezt egyelőre nem sikerült javítani.
De az is jó lenne, ha ez kombinálható lenne, egy "1234xi"-t is elfogadna, természetesen "ignorálva", nem lenne tőle "syntax error". (Ha végre sikerült találni egy megfelelő breakpointot, akkor átmenetileg anélkül ki lehetne kapcsolni, hogy "meg kellene jegyezni", hogy milyen is volt.)
A másik: van-e arra valami egyszerű mód, hogy meg lehessen tudni az utoljára generált kép rasztersorainak a számát? Debug esetén ez is azért jól jönne. Hagyományos CRT-n ez nem volt annyira kritikus, de manapság elég finnyásak a tv-k / egyéb eszközök. Ha ezt esetleg (igény szerint) ki tudná rakni valahova (Ablaknév, mint ahogy a % van?), fullextrának esetleg a képszinkronsorok számával, :) az segíthetne "kompatibilis" stuffot faragni.
Ugyanitt lehetne olyat is csinálni, hogy "create disk image", vagy valami hasonló, tehát ezen az oldalon jó lenne tudni egy "üres lemez"-t csinálni az adott típusú meghajtóval.
Az egyik: a debug / breakpoint ablakban most fedeztem fel, hogy van az "r"/"w"/"x" mellett "i" mint "ignore" lehetőség is. Ez tök jó! :) De az is jó lenne, ha ez kombinálható lenne, egy "1234xi"-t is elfogadna, természetesen "ignorálva", nem lenne tőle "syntax error". (Ha végre sikerült találni egy megfelelő breakpointot, akkor átmenetileg anélkül ki lehetne kapcsolni, hogy "meg kellene jegyezni", hogy milyen is volt.)
Az hasznos funkció lenne, ha .d64 kiterjesztésű nem létező file megadása esetén automatikusan létrehozna egy üres lemezt?
Erre a célra is használható újdonság a Git forrásban a megjegyzések támogatása, ; vagy # karakter után a sor további részét figyelmen kívül hagyja.
Az ID random gondolom egyszerű, a lemeznévnek meg jó a "NEW DISK". ("DAEMON-FORMAT"? :ds_icon_cheesygrin: )
Az üres D64/D81 lemez készítése már működik, és többé-kevésbé a .zip file támogatás is (csomagolt .d64, .d81 és .tap nyitható meg ilyen módon, de csak az első file az archívumban, és nem írható).
A felhasználó által módosíthatóvá téve tetszőleges effektusok valósíthatók meg, vagy javítható a meglevő (régi GPU-hoz készült) szűrők minősége. Bár előfordulhat, hogy rajtam kívül nem érdekelne senkit ez a lehetőség, ezért nem biztos hogy érdemes beépíteni.
Szerk.: frissítettem a Git forrást, ennek a hibának (https://github.com/istvan-v/plus4emu/issues/2) a javításával is próbálkoztam, de még nem biztos, hogy nem sikerült mást elrontani. :oops:
Amúgy lassan majd lehetne ebből forgatott binárist (részemről Linux/x86_64) kérni? :oops: Köszönet!
Ezzel amúgy lehet valamit kezdeni? Én - a tesztek alapján - inkább azt mondanám, hogy ezt a "ficsőrt" jobb ha a kedves programozó urak nem forszírozzák, mivel nem minden megjelenítő reagál ugyanúgy erre.
(A jó öreg CVBS jel szépségei... Még jó, hogy ez az EP-t, meg az ep128emu-t nem érinti. :-D )
A hiba valójában nem ezzel a - már régebbi verziókban is emulált - effektussal kapcsolatos, hanem a "bad line" engedélyezését/tiltását megvalósító logika tűnik bugosnak.
EP-re is van kompozit és S-video kimenet, az emulátor "quality=4" módja valójában az utóbbi alapján készült.
Fedora alatt a bináris elindul, bár tesztelni egyelőre nem volt időm. De ahogy olvasom, rá is ér még... :) (Ez a lib-hiány mitől lehet? A régebbi verziók régebbi környezetben fordultak, vagy ott statikusan van ez linkelve? Csak azér' érdeklődök, hogy ha lesz belőle rendes rilíz, akkor mire számítsak. :oops: )
Fura, mert az sok helyen okozna gondot, nem?
Szerk: Kipróbáltam a két tesztprogramot. Az első lefut, a megnézendő memóriákra a vízszintes / függőleges pozícióregiszter van kimásolva. Mivel a teszt nem órajelre pontosan indítja a kiolvasást, így több végeredmény is lehet:
A második tesztprogramot is elindítottam mindhárom gépen. Tulajdonképpen ezért a tesztért próbáltam ki több gépen, mivel mindháromnál elborult a tesztprogram! Ráadásul olyan memóriacímeken, ahova a CPU-nak oda se szabadna keveredni... :\ De az is változik. Szép kis bugot sikerült triggerelni a hardverben! :) (Vagy mi. :oops: )
Újabb a disztribúció. A glibc, libstdc++ és egyéb "rendszer" libek nem statikusak, csak az FLTK, PortAudio, libsndfile, SDL, Lua és cURL.
Ez viszont meglepő, a program látszólag nem tartalmaz "veszélyes" műveletet:
(Attachment Link)
Szerk.: az történhet, hogy a CPU és a TED egyszerre próbál hozzáférni a memóriához.
Hát ez az, én se láttam benne semmi veszélyeset.
Illetve ugyanitt jó lenne, ha kiválasztható lenne a "disabled" is, tehát lehetne innen is tiltani az egyes egységeket. (Most ezt egy kissé körülményesnek érzem: ki kell törölni az "image file"-t, majd kérni egy "Disable unused drives"-t.)
Ehm... Akkor az előre fordított binárist itt, CentOS alatt nem fogom tudni használni. :-| Mindegy, Fedora alatt megy! :)
A "disable" gombok törlik az image file-t és utána letiltják a nem használt meghajtókat.
A libmvec.so használatát le lehet tiltani. Nem tudom, ennek van-e valami hátránya, de így elvileg glibc 2.15 is elég lenne a bináris futtatásához.
István, nem gondoltál még arra, hogy a midiplay-t, midiconv-ot, stb.-t Plus4-hez is megcsináld? Talán egyszerűbb is lenne, mert csak 2 csatorna van, nincsenek effektek csak egy torzítás (tudtommal), és sztereó hang sincs. Talán envelope-ok vannak.Nem nagyon van értelme. Elb*szott egy konstrukció az. A frekvencia kezelés botrányos, 10 bites regiszter, nincsenek rendes mélyek (~110 Hz a minimum), normál A hang felett alig van regiszter érték különbség a meglehetősen pontatlanul kiválasztható zenei hangok között (nem tudsz rendes hajlításokat csinálni). Nincs torzítás, csak az egyik csatornát át tudod kapcsolni négyszögjel és egy béna zaj között. A hangerőt 9 szinten tudod szabályozni (beleértve a némítást is), és csak egyetlen közös hangerő van, burkológörbe meg nincs. És természetesen monó.
Pár pontosítás..Első reakcióként az akart kijönni belőlem, hogy "Nekem is Plussy-m van haver, nem kéne!", de azután sikerült időben meggondolni magamat, így csak annyit mondok a TED-re vonatkozó részekre, hogy nem. Részletesebben:
Na de nem sokban különbözik ettől a Dave, egy-két lépéssel előbbre van, ahol meg más limitációk vannak.Szubjektív, mennyire sokban/kevésben különbözik a Dave a TED-től. Ha azt vesszük, jóformán a Dave is csak négyszögjelet tud megszólaltatni, de azt elég sokféleképpen lehet variálni.
hm nézegettem ezt a plus4 grafikát, hát ezt jól kitalálták ezzel a luminance dologgal, azazhogy a 15 színnek van egy 7 értékű fényessége, és ezzel marha sok színt tud megjeleníteni egy sorban is. most hirtelen nem találtam túl jó leírást, szóval nem értem teljesen, de tök jónak tűnikÉn úgy értem, hogy maradtak a C64-es színmemória megoldásnál, azt bővítették ki, 4 bit helyett 8 bitre, tehát minden karakterre külön színt állíthatsz be, tehát egy karakter sorba 40 különböző színt is akár, és trükközéssel, mint speccyn gondolom minden pixel sorra állíthatod a színmemóriát, de gondolom itt azért már a 40 színnél kevesebbet.
- bővített háttérszín mód: hasonló az előbbihez, de csak 64 a karakterkészlet mérete, viszont 4 háttér szín közül lehet választani karakterenkéntEz egy picit hasonlít az EP 4 színpár közül választható módhoz, nem, a legfelső 2 bit állítja melyik háttérszín alkalmazandó az adott karakterre, csak itt a tintaszín szabadon választható a 127-ből.
-
- többszínű karakteres mód: kis felbontású, 3 "háttér" színt szabadon használhat bármelyik pixel, 1 szín karakterenként állítható, de csak 57 szín használható (fekete + 7 szín 8 árnyalata), mert a szín egyik bitje itt a nagy felbontású és a többszínű mód között tud választaniItt van az, hogy a C64-től öröklődött a beállítás, így a 4. bit szabályozza a nagy felbontás/több szín, ha a 7. bitre tették volna, akkor szabadon választható lenne a 121 szín itt is, nem ? Bár a leírásból úgy jön ki inkább, hogy a 3. bit szabályozza, nem a 4.
-
ha a 7. bitre tették volna, akkor szabadon választható lenne a 121 szín itt is, nem ?