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

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.

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.

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

Ezt valóban terveztem, az ep128emu-ban már most is van ilyen.

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

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.

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

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.