Enterprise Forever

:HUN => Emulátorok => EP128Emu => Topic started by: IstvanV on 2016.December.16. 11:28:54

Title: Plus4emu
Post by: IstvanV on 2016.December.16. 11:28:54
Akkor viszont merge-olni kene a plus4 es az ep128emu project-et :D

Ilyen terveim már voltak korábban, illetve a Plus/4 emuláció valójában az ep128emu része volt a 2.0 kiadása előtt (itt (https://sourceforge.net/projects/ep128emu/files/ep128emu_v2_multimachine/ep128emu-2.0.0-beta1/) még található olyan verzió amely tartalmazza, bár ez már meglehetősen elavult), csak később lett külön projekt. Azonban a beépítése több okból is nehéz lenne:
- a debugger már most sem igazán jól támogatja a különböző gépeket, egy 6502 alapú és több CPU-s rendszer (mivel a floppy meghajtók és a nyomtató gyakorlatilag külön számítógépek saját 6502 kompatibilis CPU-val) hozzáadása nem egyszerűsítené a helyzetet :)
- a GUI is meglehetősen rugalmatlan a több gépes emuláció tekintetében, nem EP módban sok része használhatatlan (pl. a ROM szegmensek hosszú listája, TVC-n nem létező IDE lemezek, billentyűzet konfiguráláskor mindig az EP billentyűzete látható, stb.), a Plus/4 emulátor pedig több "egzotikus" hardvert is támogat amik tovább bonyolítanák a gép specifikus felhasználói felületet
- a video kimenet kezelése teljesen más, a plus4emu lényegesen bonyolultabb és nagyobb CPU igényű TV emulációt tartalmaz

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. Tehát valószínűbbnek tűnik, hogy csak kiadok egy új plus4emu verziót, mert az 1.2.9.2 már több okból is elavult (pl. TGA formátumú screenshotok, az ep128emu-ban már évekkel ezelőtt javított problémák, mint például a debugger ablak zavaró villogása a Step gombok használata közben, néhány alapvető debugger funkció hiánya, a képernyő elsötétül az emuláció szüneteltetése közben, stb.), de nem érné meg annyi időt fordítani rá, amennyit a két projekt egybeépítése igényelne.
Title: Re:Plus4emu
Post by: geco on 2016.December.16. 13:33:20
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
Title: Re:Plus4emu
Post by: ergoGnomik on 2016.December.16. 14:52:53
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
Amennyire tudom elég bevett gyakorlat, hogy akik csak emulátoron fejlesztenek +4-re, azok mindkettőben tesztelik. 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. Ha emlékezetem nem csal, valakinek volt olyan ötlete is, hogy portolja Androidra, így pl. utazások üres óráiban lenne min fejlesztenie-tesztelnie. Bár arra nem emlékszem, hogy ez utóbbiról később bármit is olvastam volna. Noha nem mindent elsöprő, de érzékelhető igény van a plus4emu karbantartására, ha fejlesztésére nem is. (És én magam is használom. A múltkor ssr86-nak csak azért nem abban mutattam a példát a DAVE zenei képességek témában, mert hirtelen nem emlékeztem rá lehet-e venni, hogy a SID emulációt a natív C64-es címen keresztül futtassa.)
Title: Re:Plus4emu
Post by: balagesz on 2016.December.17. 01:04:39
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.

Ezen utolsó megjegyzésre reagálnék tisztelttel: dehogy nem használják mások! :) Ezúton is szeretném megköszönni, hogy foglalkoztál / foglalkozol vele. Persze ugyanez vonatkozik a többi stuffra is, köszönjük! (Az emberek általában ilyenek; ha valami nem megy, akkor nyüszítenek. Amikor minden rendben, akkor csönd van... :) )
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.17. 15:19:45
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.

Itt (https://github.com/istvan-v/plus4emu/releases) található újabb verzió, ami az ep128emu változtatásainak a többségét - így a Linux javításokat is - tartalmazza, illetve Linuxon érdemes az aktuális forráskódból fordítani.

Quote
hirtelen nem emlékeztem rá lehet-e venni, hogy a SID emulációt a natív C64-es címen keresztül futtassa.

Jelenleg csak $FD40 és $FE80 címeknél érhető el a SID, de hamarosan használható lesz a C64-es cím is.
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.19. 22:28:03
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:

[attachthumb=1]
Title: Re:Plus4emu
Post by: ergoGnomik on 2016.December.19. 23:18:56
:smt041
Title: Re:Plus4emu
Post by: balagesz on 2016.December.20. 21:53:57
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. :( )
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.21. 12:58:48
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. :( )

Hamarosan fordítok azt is, az 1.2.10-beta_20160925 már egyébként is kezd elavulttá válni a forráskódhoz képest.
Title: Re:Plus4emu
Post by: Attus on 2016.December.21. 14:21:15
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.
A github tárolót is nyugodtan letöltheted, kibontod, ott belelépsz a kibontott mappába és a scons paranccsal le is fordíthatod nyugodtan.
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?
Ha igen akkor a forrásmappát meg kell tartani, hogy lepucolható legyen egy scons install után is, ha mégsem tetszik az emu.
Install nélkül meg egyszerűen legyalulható az egész mappa.

No, én ezek miatt nem kedvelem a helyben, gépre fordítást.
De az univerzális "mindent bele" hízott linux binárishalmazt sem.

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?
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.21. 21:50:53
A frissített bináris csomagok már letölthetők innen (https://github.com/istvan-v/plus4emu/releases).

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

Ennél egyszerűbb letölteni a bináris verziót. :)

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

Az scons install rendszergazdaként nem ajánlott, mert jelenleg (az ep128emu-hoz hasonlóan) ~/bin és ~/.local/share/plus4emu alatt telepít mindent. De normál felhasználóként egy parancs (scons -j 4 install) lefordít és telepít is mindent. Az scons-nál nem kell külön uninstallert írni, egyszerűen az scons -c install paranccsal törölhető minden amit az install telepítene, legalábbis ha az scons tud az adott file létezéséről. Éppen most került ugyanis a Git forráskódba egy javítás, hogy az összes makecfg által generált konfigurációs file-t is törölje a ~/.local/share/plus4emu/config alatt (a listájukat a makecfg forráskódjából olvasva), ez a kiadott beta csomagban még nincsen.

Quote
De az univerzális "mindent bele" hízott linux binárishalmazt sem.

Ennek ilyen kis méretű programnál nincs különösebb jelentősége.
Title: Re:Plus4emu
Post by: Attus on 2016.December.21. 22:34:16

Ennél egyszerűbb letölteni a bináris verziót. :)

Ezt én is jól tudom.
:)

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.

Linux alatt még mindig alapelv, hogy amennyiben lehetséges minden libből dinamikus cuccokat használunk és nem a programba beledrótozott statikusakat. Az meg pláne egy szürnyűség a szememben, ami windózéknál dívik hogy egy és ugyanazon dll temérdek helyen van szétszórva a masinán mindegyekik programhoz mellékelve és ahhoz drótozva, ami azt használja.

Sajna már linuxra is szánt programokon is látszik újabban ez a tendencia.

A scons install részében nem mélyültem bele, nem tudtam, hogy rootként nem ajánlott az install futtatása.
:oops:
Újabban soha nem fordítok és telepítek a gépembe közvetlen forrásból programokat, nálam a /usr/local alatti rész tök üres. a ~ mappám alatt sincsenek futtatható ELF binárisok, csak saját kreálmányú bash szkriptek. Vagy tíz éve volt utoljára, hogy forrásból fordítottam és telepítettem a gépemre valamit.
Title: Re:Plus4emu
Post by: balagesz on 2016.December.21. 22:47:44
Kaptunk külön témát? Király! :ds_icon_cheesygrin:

A frissített bináris csomagok már letölthetők innen (https://github.com/istvan-v/plus4emu/releases).

Köszönet, máris ránézek!

És mi az akadálya annak, hogy ezeket a devel cuccokat felrakd ideiglenesen a disztród központi tárójából?

Leginkább az, hogy a devel cuccok zömét is jó eséllyel nekem kéne fordítani. :oops:

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.

Valóban... Itt viszont - sejtésem szerint - akkor lesz csomag, ha csinálok magam. (Csináltam már ilyet, de készségszinten azért nem megy... Szerintem az UHU build rendszerével el vagytok kényeztetve! :) )

Egyébként milyen disztród van?

A fő rendszerem a CentOS (https://www.centos.org/), nem éppen ilyen területen erős... Emellett néha előszedem az aktuális (körüli) Fedora (https://getfedora.org/)-t, ott már nagyobb a gyári csomag esélye.
Title: Re:Plus4emu
Post by: balagesz on 2016.December.21. 23:45:47
A frissített bináris csomagok már letölthetők innen (https://github.com/istvan-v/plus4emu/releases).

Működik:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161221_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161221_001.png)

És van "normális" fájlválasztó ablak! :)
És "nem nyúlja le" kompletten a hangeszközt, megy a PA-val is! :)
És nem tűnik el a kép Pause alatt! :)
És van ASCII megjelenítés a debugger Memory Dump-nál! :)
És a többi... :)

És még nincs is itt a Karácsony! :) Köszönet!

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... A többi rendben levőnek tűnik.
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.22. 10:48:01
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.

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.

Quote
Valami egyszerű teszt-szkript nincs kéznél? :)

A README-ben a 640. sortól található leírás a Lua használatáról, és egy egyszerű példa is. A Lua nyelv dokumentációja itt olvasható (https://www.lua.org/manual/5.3/) (5.3 verzió), a LuaJIT által támogatott régebbi 5.1 pedig itt (https://www.lua.org/manual/5.1/). A debugger Lua programozása hasonló az ep128emu-hoz, a lényege röviden, hogy Run-ra lefut a script, és utána minden esetben amikor a debugger ablak megjelenne (az Alt+M-es kézi megnyitás kivételével), az emulátor meghívja a breakPointCallback függvényt, ennek a visszatérési értéke (true vagy false) dönti el, hogy az ablak ténylegesen megjelenik-e. A Stop gomb leállítja a breakPointCallback további hívását. A Lua programból elérhető a debugger funkcióinak a többsége, így írható és olvasható a memória és a CPU regiszterei, töréspontok definiálhatók, a memória PRG formátumban menthető és tölthető, írni lehet a monitor ablakba, stb.

Ez például a 260. sor elején növeli a keret színét:
Code: Lua
  1. setDebugContext(0)
  2. clearBreakPoints()
  3. setBreakPoint(4, 260 * 128, 3)
  4. function breakPointCallback(d, t, a, v)
  5.   if t == 4 then
  6.     writeMemory(0xFF19, readMemory(0xFF19) + 1)
  7.     return false
  8.   end
  9.   return true
  10. end

Quote
Report: a debuggerben a stack dump nem görgethető,

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.

Quote
illetve a meghajtó CPU-ja esetén mintha nem is jól működne...

Alapértelmezés szerint a meghajtók nem emuláltak, mivel sokat lassítanak az emulátoron (kb. 9/16 sebességre az 1541 nagy pontosságú módban, és 10/16-ra a pontos időzítést kikapcsolva). 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.
Title: Re:Plus4emu
Post by: Attus on 2016.December.22. 13:16:44
Fedora (https://getfedora.org/)-t, ott már nagyobb a gyári csomag esélye.
Hajrá!
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. Ha meg beválik, akkor oda is lesz letölthető rpm másoknak is.
Title: Re:Plus4emu
Post by: balagesz on 2016.December.22. 18:14:13
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.

Á, így már világos. A lefordított cuccban benne van a Lua interpreter is, csak a két (Lua) verzió nem teljesen kompatibilis egymással, ezért van létjogosultsága a nem JIT-es verziónak. (Tehát nem ilyen verziójú Lua-nak kell lennie telepítve a gépen, hogy használni lehessen.)

A debugger Lua programozása hasonló az ep128emu-hoz

Nekem magával a Lua nyelvvel nincs (Egyelőre? :) ) semmi tapasztalatom, de azt hiszem időszerű lesz bepótolni. (Már megint a tanulás... :evil: :razz: ) A példát köszi, működik. ;)

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.

Valójában túl nagy jelentősége nincs, mivel a rendes memória-dump részen úgyis meg lehet nézni a teljes tartalmat.

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.

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. (Ami a memóriában a $0100+SP+1 cím.) Viszont az 1551 DOS $FF értékkel inicializálja az SP-t. (A CPU regiszter ablakba látszik is ez az érték általában, a főprogram futása alatt sokat ilyen.) Itt a "megjelölni kívánt pozíció" a memóriában $0200 lenne, de ilyen verem-pozíció ugye nincs. A "*" meg szépen a $0100 címet jelöli, ahonnan nem látszik a STACK vége, ezért is próbáltam meg görgetni. :-D
Title: Re:Plus4emu
Post by: balagesz on 2016.December.22. 18:17:24
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.

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. :)
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.22. 18:48:20
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.

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. Az mindenesetre hiba volt, hogy a Return gomb SP=$FE esetén $01FF-$0200 címekről olvasta a visszatérési címet, így azt már javítottam.
Title: Re: Plus4emu
Post by: ergoGnomik on 2016.December.22. 19:19:55
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? (Bár hogy ez utóbbi tényleg nem lenne, abban nagyon bizonytalan vagyok.)
Title: Re: Plus4emu
Post by: IstvanV on 2016.December.22. 19:38:25
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?

A szétszedhető debugger ablak nem tűnik egyszerűen megoldhatónak, több memória megjelenítő viszont lehetne az ep128emu-hoz hasonlóan, a jelenlegi méretének (17 * 8 byte) a csökkentése árán. Esetleg még két kisebb, 3-4 soros megjelenítő, amelyek akár indirekt címzést is használhatnának. Nem tudom, a file műveletekkel kapcsolatos funkciók (End address, ASCII format, Load from file, Save to file) mennyire hasznosak, ugyanerre a célra használhatók az L és S monitor parancsok is, a törlésükkel pedig több hely lenne az új megjelenítők számára.

Quote
Végrehajtás (x) típusú töréspontot bevezetni?

Ezt valóban terveztem, az ep128emu-ban már most is van ilyen.
Title: Re:Plus4emu
Post by: Attus on 2016.December.22. 20:17:06
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.
;-)
https://src.fedoraproject.org/cgit/rpms/gpsd.git/tree/gpsd.spec
https://src.fedoraproject.org/cgit/rpms/pingus.git/tree/pingus.spec
https://src.fedoraproject.org/cgit/rpms/libserf.git/tree/libserf.spec
Title: Re:Plus4emu
Post by: balagesz on 2016.December.23. 01:39:16
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.

Jó kérdés... 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. De ha a "*" a következő kiveendő adatot jelöli, akkor pont az a jó, ahogy most van. :-D Mondjuk nekem inkább az lenne a logikus, hogy az a memóriacím van jelölve, ahova az SP éppen mutat. A debuggerelő júzer meg úgyis tudja (kéne neki... :) ), hogy a PHA arra a címre rak, a PLA meg a következőről vesz ki. Bár ez egy olyan kardinális kérdés, hogy eddig fel se merült. :oops: Persze az is igaz, hogy ritka a jelenség, az alapgép illetve az 1541 se $FF-fel inicializálja az SP-t. (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? :) (Meg akartam nézni, hogy ott mi lesz az SP-vel... :) ))

Hármat már találtam is hirtelenjében.
;-)

Francba, kezd elfogyni a kifogásom. :mrgreen:
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.23. 13:07:50
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? :)

.D81 formátumú image megnyitása esetén automatikusan azt emulálja.

Szerk.:
Végrehajtás (x) típusú töréspontot bevezetni?

Ez most már van a Git forráskódban.
Title: Re: Plus4emu
Post by: IstvanV on 2016.December.24. 11:29:04
SID témában még egy lehetséges változtatás a reSID frissítése, a 0.16 már nem tűnik aktuálisnak, ha nem is találok "hivatalos" letöltési címet ahol a legújabb verzió megtalálható lenne. De a VICE forráskódja szerint van (2010-ben kiadott) 1.0 verzió, és ott azóta is több változtatás történt, amelyeket érdemes lehetne beépíteni. Bár előfordulhat, hogy ezek növelnék az emuláció CPU igényét, és valószínűleg elsősorban a 6581 pontosságát javítják.
Title: Re: Plus4emu
Post by: ergoGnomik on 2016.December.24. 20:41:24
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.
Title: Re: Plus4emu
Post by: IstvanV on 2016.December.25. 10:38:12
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.

Elvileg van 1.0 verziója is amit még Dag Lem fejlesztett, a változások listája itt (https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/resid/ChangeLog) olvasható, de az "eredeti" (nem VICE emulátorba épített) kiadást nem találom sehol. Mindenesetre ezt a verziót nagyobb probléma nélkül be tudtam építeni, bár még javítani kellene néhány hibát és frissíteni a snapshot formátumot. Hátránya azonban hogy valóban lassabb mint a 0.16, és az emuláció pontosságát elsősorban a 6581-nél javítja (a Plus/4-es SID kártyák általában 8580-at használnak?), de ez a többi SID emulátornál is így van, a 6581 kevésbé "ideális" tulajdonságokkal rendelkezik (magas a torzítása, pontatlan, stb.), ezért bonyolultabb a modellezése.

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:
Title: Re: Plus4emu
Post by: ergoGnomik on 2016.December.25. 12:29:16
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.
Title: Re: Plus4emu
Post by: IstvanV on 2016.December.25. 12:46:03
Valóban, és az ott található resid-builder azonosnak tűnik a VICE változattal. Nem tudom, érdemes lenne-e helyette az "fp"-t használni, talán a legjobb lenne azt is tesztelni.
Title: Re: Plus4emu
Post by: balagesz on 2016.December.27. 22:48:56
(a Plus/4-es SID kártyák általában 8580-at használnak?)

(Igen, a plus/4-es kártyák jellemzően 8580-nal készültek. Tudok pár 6581-es verzióról is, de meglehetősen kevés a darabszám. Amúgy annak idején hasonlítgattam (füllel... :) ) a 8580-6581 hangjait. És megértem, hogy egyesek miért is ragaszkodnak a 6581-hez... :razz: )
Title: Re:Plus4emu
Post by: IstvanV on 2016.December.27. 22:52:58
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.
Title: Re:Plus4emu
Post by: balagesz on 2016.December.29. 23:27:08
Ez a változtatás már megtalálható (egyebek mellett) a Git forráskódban.

Szuper! Így talán kevésbé zavaró ez a rendkívül ritka jelenség... :)

Amúgy ha már béta; mintha lenne egy apró pontatlanság az 1541 VIA Timer1 emulálásában. Nézegetem a forráskódot, de (én se) nem értek C++-szul. :| A kód elvileg azt csinálja, (?) hogy csökkenti megfelelő ütemben a Timer1 számlálóját, majd ha 0 lesz, akkor meghívja a Timer1Underflow() függvényt, ami Free Run esetén újratölti a számlálót a beállított értékkel. Ezzel a számláló pont annyi órajelenként "akciózik", mint amennyi a tárolóban be van állítva. Nemrégiben teszteltem "rendes" VIA-t (egy eredeti MOS-t, meg egy - talán - UMC-t próbáltam), és azok úgy működnek, mint ahogy a MOS-os dokumentációban van. Ott az történik, hogy a $0000 utáni órajelre $FFFF lesz az érték, a következő impulzusra töltődik csak újra a számláló a tárolókból. Ennek az a végeredménye, hogy Free Run esetén a beírt értékhez képest 2 lépéssel több a számláló ciklusideje.

Hogy ennek van-e bármilyen jelentősége? :-D Gondoltam azért elmondom. ;) (A közelmúltban még a régi plus4emu segítségével debugoltam az 1541 DOS-t, ott jött ki némi számolgatás után ez az érdekesség. Most belenézve a forráskódba, ezt olvasom ki belőle...)
Title: Re: Plus4emu
Post by: IstvanV on 2016.December.30. 00:21:29
Nem tudom, jó-e ez a megoldás, de módosítottam a Git-ben hogy ne a nullára való lefutást hanem a 0000 -> FFFF átmenetet figyelje mindkét számláló, és az első újratöltése még további egy ciklus késleltetés után történjen.
Title: Re: Plus4emu
Post by: balagesz on 2016.December.30. 01:45:21
Jónak kell annak lennie, mivel - mint látszik - nem annyira kritikus itt a történet. Az 1541 DOS meg nem túl rugalmas (hogy finoman fogalmazzak... :) ), saját IRQ-t készíteni nem enged, ezzel maximum méricskélni lehet, de tulajdonképpen mit is? :) A DOS egyébként Format alatt ezzel mér ki 100 µS-nyi időt. Így nyer értelmet az, hogy $0062-vel "húzza fel" a timert, nem $0064-gyel.

Azért szerintem az jelent valamit, hogy ilyen "hibákon" rágódunk az emuval kapcsolatban. :) Elég jó ez a stuff, na! Köszönet!
Title: Re: Plus4emu
Post by: IstvanV on 2017.February.09. 19:05:31
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.
Title: Re: Plus4emu
Post by: geco on 2017.February.09. 19:16:53
Ezt találtam:
The Amiga home computers employed two and Commodore 1581 floppy disk drive one 8520 chip, which is functionally equivalent to 6526/8521 except the simplified TOD circuitry.
The 8520 revision of the CIA, as used in the Amiga and the Commodore 1581 disk drive, modified the time-of-day clock to be a 24-bit binary counter, replacing the BCD format of the 6526. Other behavior was similar, however.
Title: Re: Plus4emu
Post by: balagesz on 2017.February.17. 00:00:32
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.

Erről konkrét infóm nincs, de mintha valaki azt említette volna, hogy a CIA-kból Timer működés szempontjából két fajta is van. Itt egészen biztosan nem lesz ezzel probléma. (Hacsak az ep128emu mintájára nem csinálsz ebből is C64 meg VIC20 emulátort is... :ds_icon_cheesygrin: )

Az új verziót köszi, csekkolom!
Title: Re: Plus4emu
Post by: Zozosoft on 2017.February.17. 08:44:23
Hacsak az ep128emu mintájára nem csinálsz ebből is C64 meg VIC20 emulátort is...
Nem rossz ötlet! :ds_icon_cheesygrin:
Title: Re: Plus4emu
Post by: IstvanV on 2017.February.22. 11:42:56
A p4fliconv előnézet funkciója nem működött (csak fekete képernyő jelent meg), javítottam a Git forráskódban. Valójában már az előző beta verzióban is rossz volt. :oops: Hamarosan frissítem a letölthető csomagokat.
Title: Re: Plus4emu
Post by: lgb on 2017.May.08. 00:41:08
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.

Hmmm. Mondjuk nem eppen a tekintetben, es lehet nem is ez a lenyeg, de amennyre utdom, a 8520 abban kulonbozik fokeppen a 6526/8521-tol, hogy leegyszerusitetted a TOD-ot, nem a BCD-s van, hanem egyszeruen egy 24 bites (???) szamlalo, vagy ilyesmi?

8520 talan tenyleg 1581-esben volt (meg mintha Amiga kornyeken is lenne ilyesmi?), de ha altalaban a "CIA-ra" vonatkozik (es nem kulon a 8520-ra csak), akkor az szerintem 1570/1571-ben is volt mar pl. 1541-ben volt talan VIA, es ott kezdodtek a gondok is (illetve meg VIC20-nal ahol a gepben is VIA volt) hogy a szepen megalmodott IEC serial busz hw-esen bugzott egy VIA bug miatt, ezert atvaltottak "software-es" megoldasra, ennek is koszonheto, hogy olyan szep lassu lett :( Mondjuk C128-nal van mar fast serial cuccos, ami talan pont ugy muxik, ahogy terveztek volna, de elmeletileg C64-nel is menne (CIA van benne), ha a drive is tudja (tehat 1541 kilove).

Ez szigoruan IMHO es AFAIK jellegu hozzaszolas volt :-P
Title: Re: Plus4emu
Post by: balagesz on 2017.June.04. 19:31:00
A jelenlegi "kiadott" verzió az az 1.2.10.1? Azt hiszem fogtam egy "hibát". Vagyis nem is hiba, csak - a forráskódot nézve - nincs teljesen kész ez a rész. :) (Mivel nincs gh accom, (meg a fogalmazás se lenne egyszerű,) inkább ide írnám...)

A probléma az 1551 emulációban van, mégpedig a Byte-Ready kezelésében. A most letöltött forrásban (1.2.10.2-nek mondja magát) a vc1551.cpp fájl 268. sorában van a Byte Ready Flag beállítása, ez rendben van. (Gondolom... :) ) A 396-os sorban van ugyanezen Flag törlése, ami akkor következik be, ha a bitszámláló 2. Na, ezen törlés előtt van egy FIXME megjegyzés, hogy ez a hack egy workaround. Tisztelettel FIXálnék... :oops:

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.

Ha már lemezkezelés; van még pár ötlet, amit nem tudom mennyire lenne bonyolult megcsinálni:

Van ugye a lemez-konfiguráló ablak. Ebben az U8/U9-hez ki lehet választani a meghajtó típust... Egyrészt érdeme lenne beállíthatóvá tenni az 1581-et is, ne csak "indirekt módon", olyan lemez behelyezésével lehessen kiválasztani. (Ha már tudja... De ez mehetne az U10/U11-hez is.) 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.)

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.

Illetve még egy ötlet: ha változik a lemez tartalma, esetleg jó lenne megkérdezni a júzert, hogy mi legyen vele. A jelenlegi automatikus felülírás helyett megkérdezhetné, hogy felülírja, mentse más néven, vagy dobja el a változásokat. :) Nyilván az emu bezárásakor is rá kellene erre kérdezni... Ha esetleg ez valakinek nagyon nem esik kézre, az automatikus mentés esetleg konfigurálható is lehetne.
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.05. 11:17:45
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 többi ötletnél nagyobb átalakításra lenne szükség (például a teljes D64 file memóriába töltésére, jelenleg csak az aktuális sávot tárolja, és a változtatásokat azonnal kiírja ha nem írásvédett a file), de a "disable unused drives" használata könnyen egyszerűbbé tehető lenne. Bár ezt a műveletet a Ctrl+F11 vagy Shift+F11 reset is automatikusan elvégzi.

Szerk.: 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. Újra működőképessé kellene tenni a gépemet teszteléshez, bár a billentyűzete már gyakorlatilag használhatatlan. :(
Title: Re: Plus4emu
Post by: balagesz on 2017.June.05. 22:49:51
Módosítottam, most csak TIA hozzáférésre törlődik.

Köszönet! A lemezkezelést nem is gondoltam, hogy ennyire "real-time" módon van megoldva... :) Ez már régebben is eszembe jutott: mi van akkor, ha egy "jófej" program olyan stream-et ír ki egy sávra, amit nem lehet .d64-be alakítani? :)

Két dolog jutott még az eszembe, bár ezek egyike se plus4emu specifikus, jól jönne az ep128emu-ban is. 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.) 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.

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.

A p4w-n láttam az "igényt"... Ha kell még valami, szívesen tesztelek, bár az is igaz, hogy az ember jobban szereti egyből kipróbálni, ha valami az eszébe jut. :oops: Mondanám, hogy megnézem a géped, csak mostanában mintha egy kissé túlvállalnám magam. :-D
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.06. 11:48:26
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.)

Ez megoldható, bár jelenleg is van lehetőség az 1234i-t külön sorban megadni (ilyenkor a sorrendtől függetlenül tiltja az 1234x-et), illetve az átmenetileg letiltható breakpoint célját szolgálja a "prioritás" paraméter: például 1234xp1 csak akkor aktív, ha a "threshold" nem nagyobb 1-nél. A 'p' után 0 és 3 közötti érték használható, az alapértelmezés 2.

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

Az alábbi Lua script kiírja a kép időtartamát sorokban és egyszeres sebességű ciklusokban (feltételezi, hogy a program nem írja az FF04/05 időzítőt):
[attachurl=1]
EP változat amely az LPT hosszát írja ki:
[attachurl=2]

Találtam egy plus4emu hibát is, a p4lines.lua (és általában minden video breakpoint) csak akkor működött, ha 0 volt a "Priority threshold", ezt a Git forráskódban már javítottam.
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.06. 18:42:11
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 hasznos funkció lenne, ha .d64 kiterjesztésű nem létező file megadása esetén automatikusan létrehozna egy üres lemezt? Az alábbi tömörített image egyszerűen beépíthető lenne, csak 100 byte. Bár a lemez neve és azonosítója így mindig "NEW DISK" és 00 2A. Az utóbbit véletlenszerűen is lehetne generálni, ha az előnyösebb.
[attachurl=1]

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

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. Egy sorban több breakpoint is lehet, így ilyen módon mind egyszerre tiltható.
Title: Re: Plus4emu
Post by: balagesz on 2017.June.06. 22:50:42
A lua-s sorszámlálót köszönöm, még nem próbáltam, de szerintem ki fogja elégíteni az igényem! :)

Az hasznos funkció lenne, ha .d64 kiterjesztésű nem létező file megadása esetén automatikusan létrehozna egy üres lemezt?

Eddig én ezt úgy csináltam, hogy - nem röhögni! - fogtam egy használatban levő .d64 fájt, lemásoltam más néven, majd a másolatot megformáztam az emulátorral! :cool: Ehhez képest minden segítség hasznosabb, de úgy érzem, ez erősen rétegigény. Az ötlet amúgy jó, de mehetne akkor a .d81 is ugyanígy. ;) Az ID random gondolom egyszerű, a lemeznévnek meg jó a "NEW DISK". ("DAEMON-FORMAT"? :ds_icon_cheesygrin: )

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.

Ez a megoldás így a "non-plusz-ultra", jobb is mint az én verzióm. Köszönet!
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.07. 14:35:14
Az ID random gondolom egyszerű, a lemeznévnek meg jó a "NEW DISK". ("DAEMON-FORMAT"? :ds_icon_cheesygrin: )

Úgy oldottam meg, hogy a lemez nevét és az azonosítót is a file neve alapján generálja.

Még egy lehetséges ötlet a .zip formátumú (például P4W-ről letöltött) file-ok megnyitása, ilyenkor az emulátor automatikusan kicsomagolná az első megfelelő kiterjesztésű file-t egy átmeneti file létrehozásával, amely kilépéskor törlődik. Nem tudom, ez hasznos-e, bár régebben említette valaki.
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.08. 11:49:10
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ó).

Még egy korábbi ötlet a monitor emuláció fejlesztése (több effektus (https://enterpriseforever.com/ep128emu/ep128emu/msg61749/#msg61749), stb.), ezzel kapcsolatban talán hasznos lenne a külső file-ból betölthető shader, jelenleg például ezeket használja (a forráskódba építve) az emulátor:
[attachurl=1]
[attachurl=2]
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:
Title: Re: Plus4emu
Post by: balagesz on 2017.June.09. 22:32:35
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ó).

Remek, köszi! :)

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.

Az ilyen feature mindig jó, nem gondolnám hogy csak téged érdekel... ;) Én mondjuk kifejezetten élvezem, hogy végre négyzet az a pixel, nem egy elmosódott paca, de ha nem szöveget néz direkt az ember, azért az eredeti CRT-k "pöttyei" tényleg inkább hozzáadnak, mint elvesznek az élményből.

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:

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. Az ősrégi monitoroknál valószínűleg nincs nagyobb különbség, de a kicsit is modernebbek (még sima CRT-k) is reagálhatnak már máshogy. Persze IMHO. :-D (A jó öreg CVBS jel szépségei... Még jó, hogy ez az EP-t, meg az ep128emu-t nem érinti. :-D )

Amúgy lassan majd lehetne ebből forgatott binárist (részemről Linux/x86_64) kérni? :oops: Köszönet!
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.09. 22:58:55
Amúgy lassan majd lehetne ebből forgatott binárist (részemről Linux/x86_64) kérni? :oops: Köszönet!

Linux bináris csomag az aktuális forráskódból:
[attachurl=1]
Title: Re: Plus4emu
Post by: balagesz on 2017.June.10. 00:36:53
Köszi! Most csak CentOS7-en volt időm kipróbálni, de itt hiányolja a "libmvec.so.1"-et. (2.17-es a glibc.) Az eddigi verzióknak nem kellett. :\ Holnap ránézek az aktuális Fedora alatt is.
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.10. 10:47:42
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 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. Ezzel az egyszerű programmal tesztelhető a probléma:

[attachurl=1]
G 2000
M 2100 2157
M 2200 2257

Szerk.: még egy teszt:
[attachurl=2]

De a fenti bináris verzió sem jó, már módosítottam a forráskódot.

Quote
(A jó öreg CVBS jel szépségei... Még jó, hogy ez az EP-t, meg az ep128emu-t nem érinti. :-D )

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. Tehát itt is van külön szűrő a világosság- és színjelhez, illetve emulált a soronként váltakozó fázishiba. A NICK működése miatt azonban nem lehet "inverz" színeket előállítani.
Title: Re: Plus4emu
Post by: balagesz on 2017.June.11. 18:36:45
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: )

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.

Fura, mert az sok helyen okozna gondot, nem? A tesztet megnézem mindjárt.

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.

Nyilvánvalóan van, mivel az RF jel is ebből áll elő, csak nem fejtettem ki bővebben. A kompozit videó enkóder csip ezt a fázist talán pont a NICK H/2 kimenetéről veszi, de "furcsa is lenne", ha ennek bármi összefüggése is lenne az éppen aktuálisan a képernyőre pakolt sor számával. Mivel - ha jól sejtem - a NICK-en belül direkt rasztersorszámláló, mint olyan, (ami azt számolja, hogy a képszinkron óta hányadik rasztersor rakódik ki éppen,) nincs is. :mrgreen:

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:

#1 (http://bsz.amigaspirit.hu/pics/plus4-tedtest1_1.png)
#2 (http://bsz.amigaspirit.hu/pics/plus4-tedtest1_2.png)
#3 (http://bsz.amigaspirit.hu/pics/plus4-tedtest1_3.png)

Ez a 3 kép 3 különböző gépen is készült! :) 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: )
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.11. 20:42:28
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: )

Újabb a disztribúció. A glibc, libstdc++ és egyéb "rendszer" libek nem statikusak, csak az FLTK, PortAudio, libsndfile, SDL, Lua és cURL.

Quote
Fura, mert az sok helyen okozna gondot, nem?

Ez csak az alsó kereten, a képernyő "szabálytalan" lezárásakor (azaz ha a $CB és $CC sorok nem futnak le rendesen) előforduló időzítési probléma.

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

Köszönöm a teszteredményeket, az valójában előny, hogy több különböző időzítéssel is futott a program. A Git verzió majdnem jó, de a $CC sorban van egy ciklus eltérés:
[attachthumb=1]

[attachthumb=2]

[attachthumb=3]

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

Ez viszont meglepő, a program látszólag nem tartalmaz "veszélyes" műveletet:
[attachthumb=4]
Szerk.: az történhet, hogy a CPU és a TED egyszerre próbál hozzáférni a memóriához.
Title: Re: Plus4emu
Post by: balagesz on 2017.June.11. 22:03:12
Újabb a disztribúció. A glibc, libstdc++ és egyéb "rendszer" libek nem statikusak, csak az FLTK, PortAudio, libsndfile, SDL, Lua és cURL.

Ehm... Akkor az előre fordított binárist itt, CentOS alatt nem fogom tudni használni. :-| Mindegy, Fedora alatt megy! :)

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. Én is ilyenre tippelek; a TED "elveszi" a CPU buszát akkor, amikor az feccselné a következő utasítást? A memóriatartalom (így első ránézésre) nem sérült, legalábbis a futó kód jó maradt. Ezért is pislogtam a fura BREAK címek miatt, (nem is mindig úgy / ugyanott száll el, ) illetve néztem meg 3 gépen. Láttam már furákat, de ilyennel eddig még nem futottam össze...
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.11. 23:24:26
A második teszt képen is gyanús, hogy a $2200 címre 0 került $CC helyett, tehát már itt is valamilyen szabálytalan busz hozzáférés történhetett. Ezért is lehet egy ciklus eltérés az emulátorhoz képest, például mert a CPU kétszeres sebességű módban marad amikor nem kellene.

Hát ez az, én se láttam benne semmi veszélyeset.

Az $FF1D-re $CB írás okozhatja, amit a flickrxo.prg is használ, $CA-val lehet megbízhatóan az alsó keret elé ugrani.
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.13. 15:39:59
[attachthumb=1]

[attachthumb=2]
Title: Re: Plus4emu
Post by: ergoGnomik on 2017.June.13. 20:50:43
:ds_icon_cheesygrin: :smt023 :smt041
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.13. 22:36:59
Már a Git verzió is lehetővé teszi ezeket az effektusokat, bár jelenleg nincs GUI a shader file választásához, csak a display.shaderSourcePAL és display.shaderSourceNTSC paraméterekkel állítható. Az eredeti (emulátorba épített) PAL shader és a módosított változatok:
[attachurl=1]
[attachurl=2]
[attachurl=3]
Title: Re: Plus4emu
Post by: geco on 2017.June.14. 08:33:25
Fasza ez a tv effekt :smt023
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.14. 13:17:09
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.)

A "disable" gombok törlik az image file-t és utána letiltják a nem használt meghajtókat.
[attachthumb=1]

Szerk.: a továbbfejlesztett video konfiguráló ablak:
[attachthumb=2]

Ez csak érdekesség (a GPU számára egyébként minimális terhelést jelent 50 Hz-en): :)
[attachthumb=3]
[attachurl=4]

Szerk. 2:
Ehm... Akkor az előre fordított binárist itt, CentOS alatt nem fogom tudni használni. :-| Mindegy, Fedora alatt megy! :)

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.
Title: Re: Plus4emu
Post by: balagesz on 2017.June.14. 20:20:26
Ez a tv-emuláló effekt egész baráti! ;) Anno nagyon örültem, amikor végre tudtam szerezni egy olyan monitort, amin normális volt a geometria. Csak kár, hogy később meghalt benne a cső... :\

A "disable" gombok törlik az image file-t és utána letiltják a nem használt meghajtókat.

Köszönet! :)

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.

Talán egy próbát megérhet, hogy igazából számít-e valamit. (Gondolom a működésben nem lesz változás, esetleg lassabb lesz. Ha elhanyagolható a különbség, akkor én nagyon örülnék neki... :oops: Persze ha szignifikáns, akkor értem ne tolj ki másokkal. Mindenesetre köszönöm előre is a megfontolás tárgyát. :-D )
Title: Re: Plus4emu
Post by: IstvanV on 2017.June.14. 21:21:38
Feltöltöttem az új bináris csomagokat a GitHub (https://github.com/istvan-v/plus4emu/releases)-ra. A 64 bites Linux verziókat -fno-unsafe-math-optimizations használatával fordítottam, így nincs libmvec.so (glibc 2.22) függőség. Ettől ugyan a lebegőpontos műveletek valamivel lassabbak lehetnek, de ennek az emulátornál nem sok jelentősége van.
Title: Re: Plus4emu
Post by: szipucsu on 2018.August.23. 13:15:26
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.
Title: Re: Plus4emu
Post by: ergoGnomik on 2018.August.23. 14:52:07
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ó.

De ha már itt járunk, geco a minap talált egy kis hibát a plus4emu-ban. Nem tudjuk, hogy ismert-e a jelenség, de azokban a verziókban, amiben megnéztük (én az 1.2.10-ben, geconak nem tudom melyik van fent) nem lehet a SID-emulációt kikapcsolni.
Title: Re: Plus4emu
Post by: IstvanV on 2018.August.23. 15:45:49
Ez tulajdonképpen nem bug, hanem korlátozás :oops:, a SID emulációt nem lehet teljesen letiltani, ha SID regiszter írás történik, az jelenleg mindig bekapcsolja a következő hidegindításig (Shift+F11 vagy Ctrl+F11, vagy snapshot töltés). A Machine|SID emulation|Enable/Disable hatása csak átmeneti, az előbbi használatának akkor van értelme, ha egy program csak olvasással próbálja tesztelni a SID kártya jelenlétét, az utóbbival pedig a CPU fogyasztás csökkenthető reset nélkül.

Az 1.2.10-nél egyébként van kevésbé régi verzió itt (https://github.com/istvan-v/plus4emu/releases), illetve ehhez képest is történt néhány kisebb módosítás, ami egyelőre csak a forráskódban található: a Plus/4 World fórumon jelzett vízszintes scroll bug javítása, és jobb copy/paste támogatás (pl. Unicode PETSCII karakterek, de ez még nem tökéletes).
Title: Re: Plus4emu
Post by: leexus on 2018.August.29. 07:57:28
Pár pontosítás..
A Plus4 TED (MOS7360) hang chip 10 bites adatmélységgel dolgozik Basic utasításokkal, de további 4-5 regiszter áll rendelkezésre a voice 1 és 2 esetében ha gépi kódban használod.
Lsd. 8. oldal.
https://www.pagetable.com/docs/ted/TED%207360R0%20Preliminary%20Data%20Sheet.pdf
A frekvencia táblázat alapján az A hang 110 Hz, de ez nem jelenti azt, hogy nem tud mélyebbet. Magyarul ez csak a SOUND utasítással kiadott hangra érvényes, de az értéke gépi kódban átállítható. 100Hz és 23kHz között tudja állítani a generátor. Igaz 10 Hz nem a világ, és nem egy SID chip (ami látszólag 0-4kHz, de a valóságban 30Hz a legmélyebb hang ami kijön a csövön). Tehát nem "elbaszott", hanem az akusztikai sajátosságok miatt más kicsit, na és a 0.894Hz ütemezés miatt is, ami a két C64 (C64 és C64C) esetében szintén más és más. Erre szoktak készíteni egy freki táblázat konverziót, ha konkrét hangjegyekről beszélünk.
No, de nem is erre a célra született, ahogy a Dave sem. A TED elsősorban 4-biten digitálizált hangok visszajátszására és effektek-zajok alkotására-generálására, és formáns beszédszintetizátor létrehozására (lsd. C= 364) alkalmas a TED chip hang része, ellentétben a SID-el ami valóban alkalmasabb hang szintézisre.
ADSR valóban nincs, azonban könnyedén leprogramozható, sőt akár effektek is mint fade-elés. Ilyen a sok program közül pl. a TED Zakker ahol az ADSR kérdést és sok más látszólag hiányzó hatást is megoldották: http://plus4world.powweb.com/software/TEDzakker
Én inkább úgy fogalmaznék, Basicből nem elérhető sok funkció, de alapos programozással elég sok mindent meg lehet valósítani a TED-en is, a sajnos létező korlátok ellenére.
A többi amit írtál igaz, valóban a SID-hez hasonlítva töredékét tudja produkálni a TED chip, hiszen a költségcsökkentés és akkori játékkonzol világ AY-kultuszára épülve jött létre, hogy azzal kvázi "kompatibilis" hangot tudjon generálni. Ez pedig a csipogás és a digit. hang visszajátszás volt. (Lsd. korabeli Yamaha YM hangchipek.)
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. Én mindegyik chipet szeretem használni, programozni, mindegyiknek megvan a varázsa. Egy viszont nem segít, a hasonlítgatás. Almát körtével nem lehet. Nem véletlen lett olyan a TED mint amilyen, ahogy a SID is. Egyébként a konzolokat és home computereket tekintve a SID éppúgy kilóg a sorból. Csak ott az a döntés számunkra jól sült el, a játék portolók meg megőrültek emiatt, sokszor külön zenészeket kellett megfizetni emiatt, ami más gépeken csak programozás volt.
Title: Re: Plus4emu
Post by: ergoGnomik on 2018.August.29. 10:44:03
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:
Title: Re: Plus4emu
Post by: szipucsu on 2018.August.29. 19:12:54
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.
Title: Re: Plus4emu
Post by: endi on 2018.August.29. 20:16:48
na kíváncsi lettem erre a TED-re, rá is keresek yutubon :)
Title: Re: Plus4emu
Post by: endi on 2018.August.29. 20:40:27
találtam is egy nem semmi demót
https://youtu.be/BvxXKbdxfDk
Title: Re: Plus4emu
Post by: leexus on 2018.August.29. 23:14:36
akkor mondjuk ezt a demót, a zene miatt.
https://youtu.be/c_6a6K2HtXU?t=135

vagy ezt
https://youtu.be/hNXhNe3sXQo?t=348
Title: Re: Plus4emu
Post by: leexus on 2018.August.29. 23:19:43
meg ezt: :)
https://www.youtube.com/watch?v=Ru6fX71Cdbg

és egy játékból pár rész.
https://youtu.be/hCQmad6EqwA?t=80
https://youtu.be/hCQmad6EqwA?t=198
https://youtu.be/hCQmad6EqwA?t=349
Title: Re: Plus4emu
Post by: endi on 2018.August.29. 23:38:49
ööö... hát, ahhoz képest, hogy a plus4-et mondják a legbénább commodore-nak, ezek simán jobbak mint bármi amit c64-en láttam. hangzásban is simán hozta amit a c64... ami durva...
Title: Re: Plus4emu
Post by: ergoGnomik on 2018.August.30. 06:19:11
Mondjuk pont SID-es zenéjű cuccokat nem éppen optimális ajánlgatni. Így a Promised Land (SID-kártya) vagy az Amiga Mania (Wavekonverter) nem igazán jó példák. Szerintem. De a CD5-ben elég sok TED zene volt.

Ajánlani lehet még játékból a Pets Rescue-t, Lands of Zadort, Adventures in Time-ot, Majesty of Spritesot, Pac-Pacet, Xplode Mant, Memento-t.
Demók közül a tévedés (mégse TED-es a zene legalább a felében) jogát fenntartva legyen mondjuk a Crackers Demo 4, Rocket Science, endi már megtalálta a Metamerism-et, States United, Questionmark, Notizen Aus Der Provinz, Threeve, LOD Is Back, 8 Shades of Black, Ikaruga, TED Storm.

Szerk.: Stílus javítás (szóismétlés kiküszöbölése). Az Amiga Mania-ra pedig rosszul emlékeztem. Végigpörgettem, és van benn néhány frekvencia konverteres SID, meg két rövid loop, felteszem valamilyen Amigás zenéből digitalizálva.
Title: Re: Plus4emu
Post by: endi on 2018.August.30. 11:36:28
ja hogy sid kártya? az csalás :)
Title: Re: Plus4emu
Post by: endi on 2018.August.31. 10:14:22
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
Title: Re: Plus4emu
Post by: geco on 2018.August.31. 10:41:51
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.
Title: Re: Plus4emu
Post by: IstvanV on 2018.August.31. 12:18:56
Karakterenként választható szín a 121 közül, a módtól függően:
- nagy felbontású karakteres módban 1 "fix" (regiszter, tehát megszakításban módosítható) háttér szín + 1 szín karakterenként állítható
- 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ént
- 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álasztani
- nagy felbontású grafikus mód: 2 szín szabadon válaszható karakterenként, hasonló a Spectrumos attribútum módhoz, csak 16 helyett 121 színt támogat a hardver
- többszínű grafikus mód: felezett vízszintes felbontás, 2 háttér szín + 2 karakterenként állítható

Trükközéssel (FLI) az attribútum cellák mérete 2 sor magasságúra csökkenthető, bár ez sok memóriát és CPU-t fogyaszt, elsősorban konvertált képek megjelenítésénél hasznos. 1 soros attribútum felbontás is elérhető, de korlátozásokkal, ilyenkor nem lehet a színeket teljesen szabadon választani, hanem csak a fényesség állítható (fekete-fehér kép), vagy a szomszédos soroknál az egyiknek a fényessége a másiknak a színe lesz.

Konvertált képek tovább javíthatók a vízszintes scroll soronkénti módosításával, így az attribútum cellák a kép részleteihez igazíthatók.

A normál 25 karakteres kép magasság viszonylag könnyen növelhető. A 40 karakter szélesség növelése sem lehetetlen, de csak nagyon korlátozottan oldható meg, általában nem sok értelme van.

Az emulátor csomagjában található p4fliconv programmal a fentiek kipróbálhatók, kivéve a karakteres módokat, soronként változó attribútumokat, és 40 karakternél szélesebb képernyőt.
Title: Re: Plus4emu
Post by: geco on 2018.August.31. 13:49:50
- 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ént
-
Ez 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álasztani
-
Itt 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.
Title: Re: Plus4emu
Post by: IstvanV on 2018.August.31. 14:00:44
ha a 7. bitre tették volna, akkor szabadon választható lenne a 121 szín itt is, nem ?

Igen. Ez a megoldás jobb lett volna, mert a 7. bit eredetileg a villogást engedélyezi, ami többszínű módban egyébként sem működik.
Title: Re: Plus4emu
Post by: endi on 2018.August.31. 21:35:47
érdekes ötlet hogy a háttér kevésbé állítható mint a tinta szín. de cserébe nagyon sok tinta szín van...