RetroASD = JammASD (versione usb) + Mini PC!

[picerno]

Per un errore attualmente va solo il comando -d, che dovrebbe inizializzare la scheda.... ad esempio toglie lo shift dal button 1 e 2 (so già che qualcuno non è d'accordo, lol! ma pazientate e ogni cosa avrà il suo perchè)...
edit: https://github.com/zanac/RetroASD/relea ... 0.1-fix.7z qui ho messo il fix per usare la sintassi per cambiare la regola 8, sorry per il casino che sto combinando

confermo che lo script funziona anche in windows e riesco a cambiare le regole
ho notato un paio di cose a volo. non riesco a settare la regola 100. l'opzione -d fa qualcosa ma non toglie lo button 1 e 2

[zanac]

Per un errore attualmente va solo il comando -d, che dovrebbe inizializzare la scheda.... ad esempio toglie lo shift dal button 1 e 2 (so già che qualcuno non è d'accordo, lol! ma pazientate e ogni cosa avrà il suo perchè)...
edit: https://github.com/zanac/RetroASD/relea ... 0.1-fix.7z qui ho messo il fix per usare la sintassi per cambiare la regola 8, sorry per il casino che sto combinando

confermo che lo script funziona anche in windows e riesco a cambiare le regole
ho notato un paio di cose a volo. non riesco a settare la regola 100. l'opzione -d fa qualcosa ma non toglie lo button 1 e 2

Si hai ragione, non tolgo lo shift dal button 1 e 2, per ora toglievo alcuni shift (tipo quelli della leva joystick a dx e sx)....
Hai ragoine la regola 100 c'è un errore, ho messo un range(1, 100) e invece va 101 come discutevamo in privato.... ops il python è un po' confusionario in queste cose devo darne atto!
Direi che l'obiettivo di testare la fattibilità di uno script per Windows è andato a buon fine, prossimi giorni "cristallizzo" una prima release usabile davvero.

[picerno]

Direi che l'obiettivo di testare la fattibilità di uno script per Windows è andato a buon fine, prossimi giorni "cristallizzo" una prima release usabile davvero.

Esperimento pienamente riuscito

[zanac]

pubblicato: pyJammASD-build-win32-v_0.0.2-fix come release

changelog:
- rimossa opzione -d
- aggiunta opzione -c (--config) con la quale si può specificare un dizionario di regole, nel pacchetto è fornito il file default.ini
sintassi: pyJammASD -c default.ini
- aggiunta opzione --flag (facoltativa) per specificare un elenco di bit 0/1 dei flag nell'ordine flagEnable, flagShifted, flagInverse, flagToggle, flagRepeat, flagPulse
sintassi: pyJammASD -s -r 7 -p P1_BUTTON_1 -k L_CTRL -f 100010
con questo esempio facciamo un override della regola 7 abilitando il repeat del pulsante 1, utile per i giochi di astronavi... a fine partita va ripristinato il flag standard lanciando:
pyJammASD -s -r 7 -p P1_BUTTON_1 -k L_CTRL -f 100000
(o semplicemente pyJammASD -s -r 7 -p P1_BUTTON_1 -k L_CTRL dato che 100000 è il default)
- inserito il source di pyJammASD come file interpretato a runtime, utile per chi vuole fare divertirsi ad evolvere il progetto su Windows!


Nota: ad oggi funziona solo il set delle regole, la lettura non è ancora operativa a causa di un bug nella libreria usata, in verità la libreria era bacata anche lato set delle regole ho dato priorità nel debug ovviamente al setting...

[picerno]

pubblicato: pyJammASD-build-win32-v_0.0.2-fix come release

pyJammASD -s -r 7 -p P1_BUTTON_1 -k L_CTRL -f 100000
(o semplicemente pyJammASD -s -r 7 -p P1_BUTTON_1 -k L_CTRL dato che 100000 è il default)

per settare tutte le regole superflue in modo che siano disabilitate devo quindi eseguire questo?
pyJammASD -s -r[1-100] -p TEST -k NONE -f 000000

Nota: ad oggi funziona solo il set delle regole, la lettura non è ancora operativa a causa di un bug nella libreria usata, in verità la libreria era bacata anche lato set delle regole ho dato priorità nel debug ovviamente al setting...

che bug?

[zanac]

Si ma le regole non inserite nel dizionario le inizializza da solo se non ho fatto cavolate.
Il bug è nella libreria python perché era nata per python 2, ho fatto già alcune patch per farla andare su python 3 nel giro del set, ma non ho terminato per leggere

[picerno]

Si ma le regole non inserite nel dizionario le inizializza da solo se non ho fatto cavolate.

ah! ok

Il bug è nella libreria python perché era nata per python 2, ho fatto già alcune patch per farla andare su python 3 nel giro del set, ma non ho terminato per leggere

pensavo intendessi la libreria HID. a proposito, ma poi nel tuo sistema hai usato quella libreria basata su signal11/hidapi? dalla versione per windows sembrerebbe di si visto che c'è la dll che ho compilato io

[zanac]

Si esatto è proprio quella libreria, solo che il wrapper python ha alcuni problemi con Python 3.7, niente che non si può risolvere con un po' di debugging cmq

[zanac]

Nuovi problemi.... e nuove soluzioni.

L'utilizzo di xrandr "scaled" (--scale-from) ci permette di usare emulation station con una risoluzione superwide senza grossi problemi.
Lo scaling tuttavia genera un fastidioso effetto tearing all'interno dei giochi. La soluzione è chiaramente rimuover lo scaling prima del lancio di un gioco e riabilitarlo in uscita...

Dopo aver giocato un po' con xrandr ho finalmente troato la sintassi per togliere lo scaling:
xrandr --output $(xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") --mode "MODE_1920_240" --transform none

Si rende ora necessario lanciare questo comando prima del lancio di un gioco, qui ci viene in aiuto la guida di retropie:
https://github.com/RetroPie/RetroPie-Se ... Runcommand

La documentazione riporta delle info interessanti, è nativamente possibile integrarsi tramite due script:
runcommand-onstart e runcommand-onend

Prossimi step: creare una sorta di wrapper che, in questo momento, disabilita e riabilita lo scaler... a regime in base all'emulatore scelto e/o il gioco dopo aver disabilitato lo scaler dovrebbe cambiare modeline con quella più corretta. Il posto corretto per fare il tutto è sicuramente all'interno di questi script.

[zanac]

Aggiungo una riflessione: ovviamente questi script sono il posto corretto per cambiare anche i tasti usando lo script pyJammASD.py infatti runcommand-onstart riceve questi parametri:
$1 - the system (eg: atari2600, nes, snes, megadrive, fba, etc).
$2 - the emulator (eg: lr-stella, lr-fceumm, lr-picodrive, pifba, etc).
$3 - the full path to the rom file.
$4 - the full command line used to launch the emulator.

Questo significa che in base al parametro $1, $2 e $3 è possibile sia riprogrammare i tasti della JammASD che togliere lo scaler ed eventualmente cambiare modeline. Ho una mezza idea su come rendere il tutto più pulito ed elegante per eventuali configurazioni future... devo però lavorarci su. Stay Tuned!

[antoniomauro]

Fantastico!
Non voglio farti perdere tempo in post troppo tecnici ma trovo veramente brillante la soluzione delle risoluzioni "ultrawide" per riuscire ad ottenere risoluzioni e refresh rate (modeline) arbitrari anche con schede grafiche integrate.
Se ho ben capito hai surclassato i famosi CRT Emudrivers che soffrono invece di molte limitazioni relativamente all'hardware utilizzabile.

Con questi script (pre/post) poi si apre di fatto la possibilità di realizzare un sistema pixel-perfect per ogni piattaforma/gioco

[Tox Nox Fox]

la teoria sotto è la stessa dei crtemudriver, ma rielaborata sotto Linux e con qualche "colpo di genio" di zanac che li rendono utilizzabili un po' ovunque.
Come dicevo anche con zanac, al tempo del dos puro (anni fa ) usando Linux o Dos si usciva a 15khz su ogni scheda video in circolazione. In Dos, con ArcadeOs bastava una riga in un file di testo per uscire a 15khz.
Poi con Windows iniziarono i problemi per la forzatura.

[picerno]

, al tempo del dos puro (anni fa ) usando Linux o Dos si usciva a 15khz su ogni scheda video in circolazione. In Dos, con ArcadeOs bastava una riga in un file di testo per uscire a 15khz..

Io sono rimasto a quei tempi. Dos e advmame

[zanac]

, al tempo del dos puro (anni fa ) usando Linux o Dos si usciva a 15khz su ogni scheda video in circolazione. In Dos, con ArcadeOs bastava una riga in un file di testo per uscire a 15khz..

Io sono rimasto a quei tempi. Dos e advmame

Male male, ma a fine progetto conto di farti "evolvere"

[zanac]

Continua la sperimentazione.
Dopo un po' di giorni che giravo alla risoluzione descritta mi sono spinto a spingere, perdonate il gioco di parole, il mio buon vecchio Mivar alla massima risoluzione che supportava e sopportava.
Il Mivar reggeva tranquillamente una risoluzione di 300p a 15khz, tuttavia ho deciso di scendere a 274p per mantenere la compatibilità con magari altri monitor arcade meno di manica larga.

Con questa risoluzione i giochi che usano 224p (la maggior parte) possono essere visualizzati aggiungendo 25 pixel sopra e sotto lo schermo (25+225+25=274), la risoluzione orizzontale invece è ora ad una fiammante 2560 pixel, con questo compremesso possiamo ora far girare i Sega Model 3 (che ricordo essere 496x384) a 2480x274 con una perdita di qualità video di "appena" il 29% dei pixel contro il 35% di una risoluzione 15khz standard (non sto qui a riportarvi il dettaglio dei calcoli per non annoiare troppo).

Veniamo ora ad alcuni giochi con risoluzioni bastarde.
Mortal Kombat: 400x256... risoluzione orizzontale 80+400*5+80, risoluzione verticale 9+256+9! Ci siamo.

Popeye, interlacciata a 512x448. No, non ci siamo.
Per le interflacciate serve una super risoluzione che copra più casistiche... dopo diversi tentativi ho tirato fuori una 1024x600 interlacciata! Popeye quindi diventa 512*2,76+448+76

Tutto bene? Si, quasi. Come fare a gestire due modeline così esotiche con xrandr? Ecco il trucchetto....

/usr/bin/xrandr --newmode "MODE_2560x274p" 52.42 2560 2664 2912 3328 274 275 277 300 -hsync -vsync
/usr/bin/xrandr --newmode "MODE_1024x600i" 20.161 1024 1032 1127 1264 600 601 607 638 interlace -hsync -vsync
/usr/bin/xrandr --addmode $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") "MODE_2560x274p"
/usr/bin/xrandr --addmode $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") "MODE_1024x600i"
/usr/bin/xrandr --output $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") --mode "MODE_2560x274p" --scale-from 384x274


Fatto questo possiamo cambiare da una risoluzione all'altra con questi tre comandi:

Super risoluzione progressiva:
/usr/bin/xrandr --output $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") --mode "MODE_2560x274p" --transform none

Super risoluzione progressiva scalata (per emulation):
/usr/bin/xrandr --output $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") --mode "MODE_2560x274p" --scale-from 384x274

Super risoluzione interlacciata:
/usr/bin/xrandr --output $(/usr/bin/xrandr | grep ' connected ' | sed "s/^\(.*\) connected.*/\1/") --mode "MODE_1024x600i"



Per finire ecco un altro tema che mi sta a cuore: l'uso di emulatori a schermo intero ma che in realtà faremo girare su una finestra grande quanto il desktop!
In questo caso tutto funziona bene tranne che il cursore del mouse va oscurato. Come fare?

Semplice, definiamo un file ad hoc cursor_hidden.xbm con all'interno queste righe:

cursor_hidden.xbm:
#define blnk_ptr_width 1
#define blnk_ptr_height 1
#define blnk_ptr_x_hot 0
#define blnk_ptr_y_hot 0
static unsigned char blnk_ptr_bits[] = { 0x00 };

Ora il comando:
/usr/bin/xsetroot -cursor /opt/retropie/retroasd/cursor_hidden.xbm /opt/retropie/retroasd/cursor_hidden.xbm

Ora ci siamo davvero!
E se il cursorse serve nuovamente?

Detto fatto:
xsetroot -cursor_name left_ptr

[antoniomauro]

Grande!
Come gestirà l'emulatore (mame ad esempio) la scelta della risoluzione adatta tra quelle installate?
Prevedi un'impostazione manuale degli "ini" oppure qualche altro meccanismo?
Immagino che conosci già perfettamente "groovymame" che dovrebbe supportare l'utilizzo e la selezione delle "super resolution" molto simili al metodo che stai implementando!

[zanac]

Grande!
Come gestirà l'emulatore (mame ad esempio) la scelta della risoluzione adatta tra quelle installate?
Prevedi un'impostazione manuale degli "ini" oppure qualche altro meccanismo?
Immagino che conosci già perfettamente "groovymame" che dovrebbe supportare l'utilizzo e la selezione delle "super resolution" molto simili al metodo che stai implementando!

In realtà non ho mai usato groovymame, chi mi conosce sa che provengo da Pandora Tieni conto che non sono un maniaco del pixel perfect, anzi... in verità mi piace quasi di più giocare con qualche filtro che faccia un upscaling della risoluzione del gioco

Tuttavia voglio tenermi aperto e permettere a chi invece piaccioni i pixel di avvicinarsi ad un'esperienza arcade originale... detto questo in prima fase appunto non ho intenzione di usare alcun stratagemma per cambiare la risoluzione, ma mi interessa capirne la fattibilità.
Come ho in mente di farlo? Facile, mame tramite la sua api a command line permette di estrarre le info di ogni gioco, nel tag <display> ci sono le info della risoluzione desiderata dal gioco, in base a quella non farò altro che settare al volo retroarch

[antoniomauro]

Capisco!

[zanac]

pyJammASD v 0.0.3

Versione Windows: https://github.com/zanac/RetroASD/relea ... v_0.0.3.7z
su Git c'è il source per Linux.



Rimosso parametro -d e aggiunto -c

Ora tramite -c si può caricare un dizionario di regole...

Ho predisposto due dizionari di esempio: default.ini e libretro.ini

Il default.ini imposta le regole di base che RetroASD caricherà all'avvio... libretro.ini invece contiene una configurazione che ho pensato studiata per l'uso di retroarch.
In questa configurazione i tasti shiftati hanno il "repeat" settato, ovvero tenendo premuto il tasto start del player 1 i tasti avranno il repeat settato... questo è comodo per gli shot m up o tipo nei picchiaduro dove si deve premere velocemente un pulsante (tipo le 100 mani di Honda).

[zanac]

Finalmente è tempo di romset!
RetroASD inizia a funzionare... Ed è tempo di romset! Lato mame sono coperto, lato Naomi e atomiswave sto cercando rom+chd testati con core flycast. Se qualcuno ha voglia di darmi una mano fatemi pure un fischio su fb o via PM.
Attenzione, solo a chi ha rom testate con questo core! Astenersi perdi tempo e/o rom testate con altri emulatori!
..