Newsgroup: it.comp.software.emulatori
Titolo: MuEL 0.10b

Lo scopo del programma, nato inizialmente come esigenza personale, è
quello di fornire una interfaccia grafica a vari emulatori, che
permetta di poter associare delle immagini e delle note alle varie
rom. (Niente di nuovo insomma, tranne che per SNES io non ne ho mai
visti).
Allo stato attuale, è presente solo la parte relativa al SuperNintendo
e gli emulatori supportati sono lo ZSNes e lo SNes9x (DOS). E' al
momento perfettamente funzionante e grazie alla collaborazione di
JanAxHell, è stato introdotto il supporto ad i file .DAT attualmente
utilizzati dal ROM Center di Eric Bole-Feysot. Grazie a questo
prezioso file, attualmente compilato e mantenuto da JanAxHell e
comprendente circa 3700 voci, è possibile individuare, tramite il CRC
delle Rom, il loro nome originale e l'eventuale correttezza dei 
dump.
MuEL lo potete scaricare qui: 
http://digilander.iol.it/fedpaol1/
Il file SNES.DAT (100Kb) è reperibile presso il sito di ROM Center
http://emuhq.com/romcenter/
Per installare il programma è sufficiente scompattarlo in una
directory qualsiasi e lanciarlo. Alla prima esecuzione verrà creato il
file MuEL.ini che dovrete provvedere a modificare manualmente, almeno
fino a quando non mi deciderò a costruire l'interfaccia di
configurazione. Il file INI si documenta da solo, quindi non
dovrebbero esserci problemi.
Al momento sto controllando il funzionamento dei vari emulatori per
PCEngine, dopodichè partirò con la scrittura del codice per questi.
Salvo imprevisti tra una settimana dovrei avere qualcosa di
funzionante.
-- 
Night Ranger
fedpaol.WH...@libero.it
 
Togli .WHAT.IS.SPAM per rispondere
ICQ# 63076483

funzionante.
Hehe, lo sapevo che non ti saresti fermato allo SNES :)
Jan AxHell

Hehe, lo sapevo che non ti saresti fermato allo SNES :)
Ho fatto in tempo a metterlo sul sito che mi sono accorto di un bug :(
Lo ZSNes se usato con modi video a 8 bit salva l'immagine in formato
pcx invece che bmp (a 16bit fa così) e non me ne ero accorto.
In compenso ho gia finito la sezione relativa a Hu-Go!, almeno la
parte dei .pce, per le immagini iso non so che fare, dato che non so
come si comporta non avendone nessuna sotto mano. Se qualcuno ha
informazioni da darmi sarò mooolto contento di citarlo da qualche
parte.
Il Magic Engine invece, oltre ad avere la sua GUI, non accetta input
da linea di comando, quindi mi vedo costretto a scartarlo.
A questo punto credo che dovrei come minimo contattare Eric per
chiedere se ha nulla in contrario all'utilizzo dei suoi .DAT, anche se
in fondo chi ha più merito è chi li ha compilati, dato che l'algoritmo
è un semplice CRC. A lui il merito dell'idea.


Ho fatto in tempo a metterlo sul sito che mi sono accorto di un bug :(
Ce n'è anche un'altro (e ma che casino che ho fatto). Se una rom è
ReadOnly il programma va in crash quando controlla il CRC. Comunque è
stato fixato tutto e probabilmente domani rifaccio l'upload.


č un semplice CRC. A lui il merito dell'idea.
Uhm, perche' invece dei datfile di ROMCenter (validissimo per carita', ma
orientato soprattutto alle ROM arcade), non trovi il modo di usare quelli
del Cartlist? che riconosce un sacco di formati oltre lo SNES... poi metti
una funzione di rename al tuo frontend e voila', ecco il rom renamer
definitivo... :)

definitivo... :)
Perchè a quel che so è da una vita che non viene aggiornato (anche se
a dir la verità fino a ieri non sapevo nemmeno che esistesse).
Comunque anche per il Rom Center sono disponibili i file per SNES,
NES, GAMEBOY, NEO GEO POCKET, SMS anche se a parte quello per SNES gli
altri non sono molto nutriti.
Datemi un link per il CartList, vedrò che fare.Al limite si possono
sempre tenere entrambi i sistemi ed utilizzare l'uno o l'altro a
seconda del file indicato (o entrambi, perchè no). 
Per il Rename effettivamente hai ragione, ci avevo già pensato, ma
prima che mi contattasse Jan, il tutto era limitato più che altro ad
un programmino ad uso personale, senza pretesa alcuna. Del resto non
so come faccia a funzionare, dato che proprio per quel motivo ho
scritto tutto di getto, senza pianificare nulla su carta. Comunque
ormai ci sono, si tratta solo di qualche altra linea di codice.


ormai ci sono, si tratta solo di qualche altra linea di codice.
Con Maiorana (eheh) abbiamo (piu' che altro ha) fatto un programmino che
calcola i CRC dei file e crea dei database da utilizzare poi per successivi
rename. Ma non skippa una mazza, non riconosce gli zip etc quindi direi che
tu stai messo meglio... :)

 [...]
Bruno, il Cartlist32 ha due gravi bug nel calcolo del CRC.
Inoltre è ormai obsoleto. Cowering sta sfornando una serie di tools
(i vari GoodXXX), che, associati al GoodCompare, permettono di
rinominare le rom e sapere quali ti mancano e quali hanno le persone
che contatti rispetto alla tua mancolista in un baleno.
Inoltre le rom Genesis hanno una particolarissima caratteristica: un X
quantitativo di rom per questa console _deve_ avere il BAD checksum.
E' per ora ignoto il motivo di questa cosa e in fase di costoso studio
da parte di #rareroms.
Jan AxHell

da parte di #rareroms.
Si', sapevo di qualcosa del genere, mi pare che lessi che era una forma di
protezione dai vari copiatori.

se qui le varianti sono un'infinita'...).
Sei pazzoooooooooo!!! :)) Come fai a catalogare in quel modo le image dei
giochi per C64? Tralasciando il discorso dei diversi formati e riunendo
tutto al .d64 e .tap (gli altri si possono importare, con max due passaggi,
in un .d64), e` semplicemente IMPOSSIBILE...
L'unica e` basare sull'occupazione in memoria dei singoli .prg (aka:
percentuale intorno al 97% = probabilmente e` la stessa cosa), ma anche
cosi` e` un casino, specie coi giochi crunched.
-- 
Massi "No, cadenti non e` il cognome, si scrive minuscolo" cadenti.
Vivi la nostalgia: 
http://www.c64audio.com/
Canzone preferita in questo momento: Galway is good 2000
(Back In Time vol.2 - track 2)

>da parte di #rareroms.
Qui forse avrei bisogno di alcune delucidazioni, se mi potete
contattare in mail o darmi qualche url mi fate un favore.


Uhm, si' ma che io sappia solo con lo SNES viene skippato l'header.
Confermo, infatti sul PCE l'header non viene tolto, ho appena
implementato il controllo.
Ora, oltre ai dati del Cartlist (se riesco a decrittare il formato del
file) sto inserendo anche la parte per associare ad ogni ROM il
proprio emulatore, vedremo che viene fuori.


che contatti rispetto alla tua mancolista in un baleno.
URL?


funzionante.
Beeeeelooo... Mi offro come betatester! ;)
Scherzi a parte, che vuol dire il nome?
-- 

Quali? parla parla... :)
Il primo è generico: il CL32 non si preoccupa della dimensione delle
rom, quindi, sia che abbiano header/intro aggiunte, sia che siano
pure, il CRC è calcolato sulla totalità dei dati. Ovvero, se hai due
dump dello stesso gioco, uno pulito e uno con header da 512 byte, per
il CL32 sono due rom diverse con CRC diverso.
Il secondo riguarda solo le rom con header interno. Il CL32 lo ignora.
Così, se hai due rom dello stesso gioco, ma per esempio di paese
diverso, il CRC risulta identico.
Come puoi vedere, anche solo facendo la lista delle proprie rom (senza
quindi compararle con altre), non si è mai sicuri di quali siano i
doppioni.
Jan AxHell

contattare in mail o darmi qualche url mi fate un favore.
Vedi sopra.
Jan AxHell

proprio emulatore, vedremo che viene fuori.
Come minimo, una vera ficata!  :))
Jan AxHell

doppioni.
Io per andare sul sicuro quando devo fare qualche aggiunta, prendo il mio
database, ci aggiungo tutte le "novita'" e poi mi esamino tutti i file che
vengono segnalati come doppioni uno ad uno, per verificare che lo siano
veramente.
Boh, cmq il CL per me rimane un ottimo prg nonche' uno strumento
insostituibile (per ora?).

Scherzi a parte, che vuol dire il nome?
Se andavi sul sito lo capivi :Pù
Comunque dovrebbe stare per Multi Emulators Loader, ma diciamo che:
1) L'inglese non è il mio forte, se qualcuno ha scaricato il programma
se ne è accorto leggendo il file ini
2) Non ho molta fantasia, essendo una persona pratica.
Quindi se avete dei suggerimenti anche per il nome ....



Invece sì, perchè se non ce ne accorgevamo, il ROM Center avrebbe
avuto un dat da 6-7000 CRC totalmente inutili, creando confusione su
ciò che veramente uno possiede o no. Già c'è un discreto quantitativo
di persone che va a caccia dei BAD dump segnalati dai GoodXXX,
figurati se ci lasciavamo i CRC delle versioni con e senza 512 byte...
Un programma che automatizza dei procedimenti deve essere il più
pulito possibile, se no non serve a niente perchè non ti puoi fidare
al 100%. Io per i doppioni mi fido solo del CloneMaster che compara i
file byte-per-byte, ed è proprio grazie a questo che ho notato i 512
byte.
Jan AxHell

byte.
??? scusa se li compara byte per byte non ti segnala come differenti, le
versioni con header aggiunto e quelle senza (versioni che invece il
ROMCenter segnala identiche, per come l'ho capita)?

proprio identici per tutto il resto.
Infatti di solito sono uguali tranne che per il byte in questione o cmq
nell'header.


ROMCenter segnala identiche, per come l'ho capita)?
Se per header intendi i 1024 byte iniziali (che poi alla fine sono i 512
che dite voi, visto che gli altri 512 sono vuoti), la presenza o meno
indica solo alcuni fattori non essenziali all'emulatore o all'emulazione
per girare. Servono solo ai copiatori, per motivi che non sto a rispiegare
(lo feci gia` quando Jan mi chiese come erano strutturate le rom snes) e
basta. In pratica, l'emulatore se ne strafrega. Se poi vogliamo parlare di
rom "pura", questa, almeno nel caso dello snes, e` pura utopia visto che
esistono decine di modi differenti in cui puo` essere registrato un header,
e sono tutti virtualmente corretti (aka vanno tutti bene per i copiatori e
il contenuto dei dati della rom vera e propria e` identico). Se compari
byte per byte ti ritroverai, molto spesso, con tante rom identiche che
cambiano solo per quanto riguarda l'header (grandezza o mancanza dello
stesso, e piu` spesso ancora differenze tra uno e l'altro). E` anche per
questo che dicevo, tempo fa, che aggiungere il supporto anche per le rom
splitted non sarebbe una cattiva idea (ma Jan mi rispose picche :P,
immagino che dipenda dal fatto che andrebbe rivisto tutto il motore
principale del romcenter, e non se ne occupa lui).
Probabilmente io sto pieno di rom diverse dalle tue proprio perche` gran
parte delle rom in mio possesso sono miei dump, questo pero` non vuol dire
che siano corrotte. Possono essere buone entrambe, anche se diverse.
In pratica, quello che voglio dire e`: non fatevi troppe seghe mentali
sugli header, altrimenti non ne uscirete fuori. Io stesso conosco bene 7 o
8 formati,ma sono sicuro che ce ne sono di piu` (per non parlare di quelli
splitted, li` e` piu` complicato ancora visto che l'header cambia anche
all'interno dei vari file componenti un singolo gioco). Poi ognuno
ovviamente faccia come vuole. Ma personalmente credo che il discorso degli
header uguali/diversi non sia applicabile nel caso di una vastita` di
formati qual e` il caso dello snes.


altra "originale" certo preferisco distinguerle...
No, per header si intende quello aggiunto dal tool utilizzato per fare
il dump.


che siano corrotte. Possono essere buone entrambe, anche se diverse.
Quindi, almeno in teoria, l'unica cosa a differire dovrebbe essere
appunto l'header. Ma se così fosse, il sistema del ROM Center dovrebbe
essere più affidabile. BTW, dato che la parte SNES (a parte il ROM
Rename) è già pronta dovresti provare a dare un'occhiata al front-end,
dato che legge anche le rom non compresse (a differenza del ROM
Center). Unica nota dolente: non funziona se le rom sono su CD-ROM,
dato che mi crea problemi l'attributo di sola lettura. E' probabile
che dovrò prevedere tale caso ed eventualmente spostarle in una dir
temporanea, ma il processo verrebbe rallentato parecchio. 
Per le ROM splitted vedrò cosa fare, in teoria dovrebbe essere
possibile calcolarlo anche lì.
Tra l'altro mi servirebbe qualcuno con la voglia di testarlo un po'.


principale del romcenter, e non se ne occupa lui).
Nella prossima versione ci sarà il supporto di split e merge, me lo ha
detto l'autore in mail una decina di giorni fa.
-- 
mo...@yacc.it
ICQ # 30316291
www.geocities.com/hollywood/location/1937/index.htm
Sito ufficiale G.D.V.C. fan club - In the name of FANTALONE


Intendo in generale (molti tipi di rom non hanno questo problema). Se
comparo i file SNES con CL32 non sono sicuro che mi becchi tutti i
doppi, mentre con il CloneMaster sě. Quelli che restano con i 512byte
li spurgo con il Datama (di ROM Center), anche se cmq
si tratta poi di un lavoro manuale, basato sul log ottenuto.
Certo, in questi termini non esiste ancora un tool che fa tutto;
bisogna arrangiarsi un po'. Il ROM Center legge la "fotografia" (il
DAT) creata con Datama, di per sč non calcola niente eccetto il CRC,
a prescindere dalla dimensione del file.
Jan AxHell

detto l'autore in mail una decina di giorni fa.
Infatti io non ho mai risposto picche :P
Jan AxHell

Infatti io non ho mai risposto picche :P
Pero` mi dicesti che non avevi intenzione al momento di fare immettere il
supporto in questione :) Nulla di male se poi hai cambiato idea, anzi :)
La cosa principale, per quanto mi riguarda, e` proprio quella: supporto rom
non zippate e supporto rom splittate. In questo modo potro` finalmente dare
un'occhiata anche alla mia collezione di rom :)


Tra l'altro mi servirebbe qualcuno con la voglia di testarlo un po'.
Appena ho un po' di tempo lo scarico.


Appena ho un po' di tempo lo scarico.
Aspetta, è pronta la nuova versione. Senza Splitted però.
* Possibilità di associare ad ogni ROM l'emulatore più adatto (che
funziona o preferito)
* Funzione di Rename (non come vi avevo promesso, non efettuerà anche
lo zip, magari in futuro)
SNES:
* Supporto per ZSNes (al momento solo la ver. c, dato che la ver. a
non supporta gli zip e presenta alcuni problemi con la linea di
comando) e SNes9x (solo la ver. Dos, dato che la versione per Windows
non accetta nulla da linea di comando)
* Integrazione con il programma SMC (abbandonato, forse solo per il
momento, il CartList), che permette di estrapolare le info
direttamente dalla ROM (il DAT del RomCenter lo sapevate già che
c'era)
PCE:
* Supporto per HuGo e Hu6280 (vers. DOS, la vers. Win non accetta
input su linea di comando)
* Supporto per gli screenshot limitato a HuGo, dato che Hu6280 salva
in formato iff/ilbm e io non so come convertirlo.
* Integrazione con PCEID come alternativa al file DAT.
Ad ogni modo, per ora, la routine di comparazione del CRC rallenta il
browsing tra i file, probabilmente quindi aggiungerò anche un delay,
in modo che l'identificazione del file avvenga solo dopo che il
cursore si ferma sul file per un po' (0.5 o 1 secondo, magari
configurabile). Tutto questo fino a che non riusciro ad ottimizzare la
routine (se mai ci riuscirò).
A questo punto considererò questa versione chiusa, fatta eccezione per
gli eventuali bugfix, e mi metto a riscrivere tutto daccapo, magari in
C++, razionalizzando finalmente il lavoro e cercando di ottenere i
sorgenti di SMC e PCEID in modo da integrare le routine direttamente
all'interno del programma.
Per la cronaca, Eric Bole-Feysot, il papa' di ROMCenter ha dato il suo
consenso all'utilizzo dei file DAT. (Tanto per fare le cose in regola)


consenso all'utilizzo dei file DAT. (Tanto per fare le cose in regola)
Ma il file .dat dello snes e` stato fatto da Jan AxHell...:)


Ma il file .dat dello snes e` stato fatto da Jan AxHell...:)
Si, infatti devo ringraziare anche lui, ma ad ogni modo dato che lo
stesso sistema viene usato anche per il PCE e che l'idea è stata sua
mi è sembrato logico chiedere il permesso ;)
