Autori: D-Chan, mickey, Fraka, Duke, BGies, MJL, _Ombra_, Sephiroth 1311, Phoenix
Versione: 4.0 (v. 3.0)
Ultimo aggiornamento: 19/09/2010

- Indice-

Dannazione, non esiste nessun fottuto manuale per le traduzioni! Nessun nome, nessuna tecnica! Soltanto un ammasso uniforme di valori esadecimali legati da regole decise da quei pazzi dei programmatori, e la vostra intelligenza!!

Intendete tradurre un videogioco, o semplicemente volete modificarne il contenuto, ma non avete la più pallida idea di come si faccia, non siete pratici di editor esadecimali o cose del genere e soprattutto non sapete come è fatto l'interno di una ROM o di un file immagine ISO?
Allora iniziamo dalle basi. Tratteremo per prima cosa due concetti fondamentali: cos'è un file (e come lo si modifica) e cos'è una codifica del testo.

Sistemi numerici

Da sempre gli esseri umani hanno utilizzato il cosiddetto sistema numerico decimale per contare, che si poggia su di un alfabeto di dieci simboli che oggi noi chiamiamo numeri. Tutto dipende dal fatto che il primo modo che abbiamo sviluppato per contare è quello di usare le nostre dita, che sono in tutto dieci. Allo stesso modo, i computer, per via della loro struttura elettrica ed elettronica, si trovano a loro agio a contare con solo due simboli (0 e 1). Ogni cosa, ogni informazione all?interno dei calcolatori elettronici viene memorizzata con solo questi due simboli.
Immaginiamo di voler contare dodici oggetti: sappiamo che basterà iniziare a contare dal numero 0, aumentando di volta in volta la cifra. In questo modo arriveremo ad ottenere 9. Terminate le cifre a disposizione, non facciamo altro che aggiungere una decina a sinistra e ricominciando a contare da capo, ottenendo 10. Infine si arriverà a 12. Questo sistema di rappresentare i numeri viene detto posizionale, dando a ogni numero un "peso" in base alla posizione che esso assume. Per questo distinguiamo unità, decine (dieci volte le unità), centinaia (cento volte le unità) ecc. Anche il sistema binario, come quello in base sedici è posizionale e funziona nel medesimo modo, abbiamo solo meno simboli a disposizione.
Volendo contare dodici oggetti in binario basterà iniziare a contare da 0. Contando avremo di volta in volta:

0 1 10 11 100 101 110 111 1000 1001 1010 1011 1100

Ogni volta che finiamo i simboli su una colonna ne aggiungiamo una nuova e ricominciamo da capo con le altre. Quindi il numero 1100 in binario è equivalente al numero 12 in decimale. Potete fare delle prove con la calcolatrice di Windows per esercitarvi. La differenza sta semplicemente nel fatto che in base dieci il numero presente su una colonna "pesa" dieci volte di più di quello nella colonna subito a destra, mentre in base due, ogni numero "pesa" il doppio di quello subito a destra.
Oltre al binario e al decimale, esiste un altro sistema numerico molto usato che è detto esadecimale. Esso sfrutta un alfabeto di sedici simboli che sono i seguenti: 0123456789ABCDEF. È facilmente intuibile che le lettere dalla A alla F siano equivalenti ai numeri 10 11 12 13 14 e 15 nel sistema decimale. L'utilità di questo sistema numerico per i nostri scopi sarà più chiara nel paragrafo successivo.
N.B. Solitamente, vista la presenza di molti simboli in comune tra i vari sistemi numerici, si preferisce indicare i numeri binari in questo modo: 10011b, cioè posponendo la lettera "b" al numero. I numeri in esadecimale vengono invece scritti così: 0x3FE2 oppure $3FE2, facendo precedere cioè al numero "0x" oppure "$". I numeri in decimale invece vengono scritti senza simboli aggiuntivi.

Il compito del game hacker è quello di agire su un file pur non possedendo alcun programma creato per la sua modifica. Nel caso delle traduzioni amatoriali, bisogna sostituire tutti quei dati inerenti al testo (o alla grafica dei testi), per sostituire al testo originale quello tradotto.

Concetti di file, dato e informazione

Dopo aver capito come il computer gestisca i numeri, possiamo iniziare a comprendere come esso possa usarli per immagazzinare informazioni. Iniziamo dai file.
Un file non è altro che una lunga sequenza di bit (potremmo anche vederlo come gigantesco numero :P) immagazzinata in memoria. Il semplice insieme di questi bit messi in sequenza viene definito dato e da solo può non avere alcun significato. Infatti, se vi dessi la sequenza di bit "10101101100011101100000111101111", voi non sapreste cosa essa possa rappresentare. Se invece vi dicessi che essa rappresenta un numero in notazione binaria, allora otterreste da questo dato un'informazione, cioè un numero. Quindi è chiaro che i dati in sé per essere utili devono poter essere interpretati. Questo è ciò che il software, e a volte anche la macchina, fa: un programma riceve in ingresso una sequenza di bit (il nostro file) e la interpreta per generare informazioni. Ad esempio mostrare a schermo un'immagine. Tutto sta nel saper interpretare la sequenza di bit.
Avrete intuito però che cercare di interpretare una lunghissima sequenza di soli 0 e 1 è qualcosa di improponibile. È per questo che solitamente (anzi sempre) questa sequenza di bit venga scomposta in blocchi da 8 bit alla volta chiamati byte, ad esempio: 10001111 01101110 e ogni byte viene riscritto nel suo equivalente in notazione esadecimale, ottenendo quindi 8F 6E (fate una prova con la calcolatrice di Windows). Avrete capito che in questo modo si ha una rappresentazione più compatta e comprensibile del nostro file. Quindi il contenuto di un ipotetico file potrebbe essere A4F6EE3567EA e così via.
N.B. Con 8 bit è possibile contare da 0 a 255. I numeri da 0 a 255 in esadecimale sono quelli che vanno da 00 a FF. Esistono dei programmi, chiamati Editor Esadecimali, che permettono di visualizzare il contenuto di un file in esadecimale. Un esempio è Hex Workshop, che visualizza un file nel seguente modo (come praticamente tutti gli altri editor):

89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 04 F4 00 00 02
3D 08 02 00 00 00 32 EC B1 7E 00 00 00 01 73 52 47 42 00 AE CE 1C E9
00 00 00 04 67 41 4D 41 00 00 B1 8F 0B FC 61 05 00 00 00 09 70 48 59
73 00 00 0E C3 00 00 0E C3 01 C7 6F A8 64 00 00 52 CA 49 44 41 54 78
5E ED DD BF EB 34 D7 7D 2F 70 FF 19 29 6E C0 E0 1B B8 C8 95 D5 3D DD

Cioè disponendo la sequenza per righe. Altro concetto fondamentale per l'aspirante romhacker è quello di offset (o indirizzo). Ogni byte, all'interno di un file, ha una sua posizione: primo, secondo ecc.. La posizione associata ad un byte dentro un file è appunto chiamato offset. Esso non è altro che un numero rappresentante la posizione del byte. Il primo byte ha offset 0, il secondo 1, il terzo 2, e così via. Essendo gli offset dei numeri, anch?essi possono essere rappresentati sia in decimali che in esadecimale. Solitamente viene utilizzata la notazione esadecimale per gli offset.
Il problema che da adesso in poi ci porremo sarà: "Come faccio a sapere come interpretare i byte di un particolare file"?

La codifica del testo

Abbiamo detto che ogni file (o meglio, il suo contenuto), per essere utile deve essere interpretato in qualche modo. Ipotizziamo che vi sia data la sequenza di byte 63 69 61 6F 20 6D 6F 6E 64 6F.
Se vi dicessi che i byte che vanno da 0x61 a 0x7A rappresentano rispettivamente le lettere dell'alfabeto americano abcdefghijk... allora sareste in grado di interpretare i byte di questo file, concludendo che esso rappresenta il testo "ciao mondo". Ciò che abbiamo usato è detta codifica del testo, cioè si associa ad ogni byte (a volta anche a più di uno) una lettera, un simbolo di punteggiatura ecc.
Di codifiche per il testo ne esistono tante, ma la più diffusa è la codifica ASCII (American Standard Code for Information Interchange). Essa permette di rappresentare tutto l'alfabeto americano maiuscolo e minuscolo, segni di punteggiatura, numeri e codici di controllo particolari come il ritorno a capo. Questo standard viene utilizzato da tutti i sistemi operativi moderni, anche se si sta cercando di sostituirlo con uno più attuale detto UNICODE.
La codifica ASCII associa a un singolo byte un simbolo. Anche se non vengono sfruttate tutte le 256 combinazioni ma solo 128. Di seguito viene riportata la tabella del codice ASCII:

Tutti gli editor esadecimali esistenti permettono di visualizzare un file in due modalità contemporaneamente: come sequenza di byte grezza e interpretando i byte in ASCII. I byte non presenti nella codifica ASCII vengono solitamente mostrati con un "#" oppure un ".". Hex Workshop ad esempio li mostra così:

44 61 20 73 65 6D 70 72 65 20 67 6C 69 20 65 73 | Da sempre gli es
73 65 72 69 20 75 6D 61 6E 69 20 68 61 6E 6E 6F | seri umani hanno
20 75 74 69 6C 69 7A 7A 61 74 6F FF FF FF FF FF | utilizzato.....

Purtroppo, molti videogiochi, soprattutto quelli molto vecchi, non utilizzano lo standard ASCII per memorizzare il testo, ma usano una codifica personalizzata. Spesso ciò avviene perché il gioco in sé non necessità di tutti i simboli del codice ASCII risparmiando spazio per memorizzare il font (argomento di cui parleremo più avanti) oppure per introdurre codici di controllo particolari, come il colore oppure la velocità di scorrimento del testo. Non esistendo editor esadecimali che permettono di visualizzare e di modificare file interpretandoli con codifiche diverse da quella ASCII, alcuni programmatori hanno sviluppato degli editor che possono visualizzare un file secondo una codifica da noi assegnata. Vedremo adesso come utilizzare questi programmi per modificare il testo di un gioco.

Ultima premessa: ricordate che in questa guida l'insieme delle lettere con cui il gioco scrive i testi verranno definite "font".

Detto questo... buona lettura! :)

Un tempo era necessario procurarsi un Hex Editor, cioè un editor esadecimale, ed imparare a memoria il codice della ROM che si traduceva. Quindi per tradurre la parola "Arma" in FF3 USA era necessario cercare i numeri 00 2B 26 1A e sostituirli con quelli equivalenti alla parola desiderata. Fortunatamente, da ormai una decade esistono delle utility che visualizzano e permettono di modificare il testo come se fosse in ASCII (o quasi), e rendono molto più semplice la modifica della ROM/ISO, anche se non riducono certo i problemi di spazio che si incontrano al livello di conoscenza base.

Già, per chi non lo sapesse in una ROM (o nei file di una ISO) non si può superare il numero di caratteri in una riga presenti nella versione originale, a meno che non si vadano a modificare i famigerati puntatori. Questo rappresenta il più grosso problema di traduzione per i neofiti. Lo accenneremo più in là in questo documento, ma verrà trattato più approfonditamente nelle guide successive. Dovete pensare ai puntatori come a dei byte che "indicano" al gioco dove comincia quel preciso dialogo. Modificandoli, è possibile spostare l'inizio di ogni frase.
Comunque, nell'incauto caso voleste tentare una traduzione senza la modifica dei puntatori, ricordatevi che è meglio reinterpretare il testo, anziché renderlo molto letterale ma facendolo diventare difficilmente comprensibile. Ad ogni modo, qualsiasi traduzione creata senza l'hacking dei puntatori viene ormai considerata di bassa qualità. Questo perché, nella stragrande maggioranza delle volte, la lingua italiana è assai più verbosa dell'inglese. Dunque, una traduzione che non modifichi i puntatori castrerà le possibilità espressive del traduttore. L'unica eccezione può accadere se si traduce da lingue neolatine simili all'italiano, come il francese o lo spagnolo. Molti giochi moderni contemplano la presenza di più lingue nello stesso gioco, e questo potrebbe permettervi di tradurre sì il testo inglese, ma reinserendolo al posto dello spagnolo, ad esempio.

Per iniziare a tradurre un qualsiasi videogioco per qualsiasi piattaforma è necessario conoscere la sua tabella (o table), ovvero le corrispondenze valore esadecimale -> carattere.
Questo è un esempio di tabella:

  0 1 2 3 4 5 6 7 8 9 A B C D E F
0
1   A B C D E F G H I J K L M N O
2 P Q R S T U V W X Y Z a b c d e
3 f g h i j k l m n o p q r s t u
4 v w x y z 1 2 3 4 5 6 7 8 9 0 .
5 , : ; - ! ? =
6
7
8
9
A
B
C
D
E
F > <

La tabella si legge come un piano cartesiano: prendendo prima il numero della riga, poi quello della colonna troverete a che codice esadecimale corrispondono le varie lettere (in questo caso: A=11, B=12, 9=4D, >=F0).
Così, se vogliamo trovare nella ROM la parola "Arma" basta cercare "11 3C 37 2B" e il gioco è fatto.
Questo metodo si usava prima che esistessero editor come il Cartographer, il Thingy, il Translhextion e molti altri, bene o male tutti disponibili su Romhacking.NET.
La particolarità di questi editor infatti è che vi permettono di modificare il testo direttamente da tastiera, come se fosse scritto in ASCII, basta che voi passiate loro come parametro la tabella del font, cosi che possano attuare la conversione.
Qualora qualcuno volesse utilizzare il vetusto Thingy, esso ha molte altre features utili, per cui vi consiglio di leggere la sezione della guida all'uso del Thingy per approfondimenti.
Altri editor recenti e molto validi sono Atlas e Cartographer, entrambi reperibili nella nostra sezione "Utilità".

Come trovare la giusta tabella

Prima di cominciare a spiegare il primo passo per cominciare una traduzione, ovvero come trovare una tabella, abbiamo un consiglio da darvi: a meno che non siate già un minimo esperti, NON tentate di cominciare con le traduzioni giochi per console avanzate (dalla PSX in su), che solitamente richiedono altre conoscenze rispetto alle traduzioni di semplici ROM per NES o SNES. Il nostro consiglio è di cominciare a tradurre, anche solo per prova, qualche gioco NES/SNES dal poco testo, in modo da afferrare per prima i concetti base.
Detto questo, cominciamo la lezione!

1) Primo metodo: con il programma SearchR X creato dal nostro Chop o con Monkey Moore

Innanzitutto procuratevi nella pagina Utilità o l'utility chiamata SearchR X, oppure il MonkeyMoore. Ambedue permettono di cercare stringhe di testo all'interno di una ROM o di singoli files.

A questo punto, tratteremo di come cercare il testo all'interno di una ROM. Il procedimento per i giochi Playstation e/o successivi è simile nella teoria, ma differente nella pratica. Controllate le guide successive per capire come conviene comportarsi con giochi di centinaia di MB!
Questa guida procederà utilizzando come esempio il SearchR X di Chop. Una recente e validissima alternativa al nostro programma (dopo circa 8 anni di dominio del SearchR X) è il Monkey Moore di Darkl0rd, anch'esso reperibile nella pagina delle Utilità. Rispetto al SearchR X, ha il grosso privilegio di funzionare anche con i caratteri giapponesi, e quello di riuscire a lavorare su file molto grossi (il SearchR X nacque esplicitamente per le ROM, invece).

Come primo esempio utilizziamo la ROM di Final Fantasy III USA. Proviamo a cercare il nome della protagonista Terra. Nella stessa directory mettiamo la ROM ed il SearchR X. Lanciamo il SearchR X, apriamo la ROM, e scriviamo "terra" nel campo "Cerca:" nella finestra di "Ricerca relativa". Come risultato otterremo dati simili a quelli qui riportati:

Offset: 293568 (0x0047C0 in esadecimale)
Valori: a=80 A=?? 1=??
Anteprima: terra.locke.cyan

Se avete giocato a FFIII, saprete che quando ti viene chiesto di inserire il nome di un personaggio, il nome di default è proposto tutto in lettere maiuscole. Così i numeri trovati in precedenza corrispondono tutti a lettere maiuscole: 93 = T, 84 = E, 91 = R, 80 = A.

Se nella colonna con la scritta "Valori" comparirà A=41, significa che il testo nella ROM è in ASCII, e pertanto è facilmente modificabile con un qualsiasi editor esadecimale.

Se invece non trovate niente, tenete in considerazione che il testo potrebbe essere nascosto, o codificato in una maniera non standard, ad esempio con una codifica a 16 bit.
In quest'ultimo caso, quando fate le ricerche, semplicemente scrivete le parole con un punto interrogativo fra le lettere, il ? corrisponde ad un carattere jolly che può essere qualsiasi byte hex. Per esempio la parola "Yes" la cercherete come "Y?e?s" ed il gioco è fatto. Il SearchR X permette inoltre di effettuare la ricerca a 16 bit senza l'uso dei caratteri jolly, basta solo utilizzare l'apposita opzione.

Un'attenzione particolare va riservata ai caratteri che non compongono il normale alfabeto A..Z/a..z; come numeri, segni di punteggiatura o altri simboli particolari (ad esempio i disegnini vicino ai nomi degli oggetti in Final Fantasy e altri RPG). Per conoscerne il valore nella text table il più delle volte basta:

• Se si lavora su una ROM, aprirla con un editor grafico come Tile Layer Pro o Tile Molester
• Se si lavora su un ISO, localizzare il font (vedere guide successive)
• Trovare le tiles (o i pixel) che compongono la text table A..Z/a..z
• Scovare i simboli e osservarne la posizione

Naturalmente se il simbolo che stiamo cercando, mettiamo sia il disegno di una faccina, si trova 2 tiles prima della A e il codice della A è A0, il codice per faccina è A0 - 2 = 9E.

Un altro sistema è invece quello di sostituire alla prima frase del gioco dei numeri esadecimali a caso, per vedere quali simboli escono fuori. Il più delle volte sarete costretti a fare così per scoprire tiles che non sono numeri o lettere, e quindi difficilmente rintracciabili in altro modo.
Se avete completato tutto l'alfabeto ma appunto vi mancano tiles come la punteggiatura o delle icone, potete trovarli ad intuito, studiandone la posizione. Giocate fino ad incontrarli. Ad esempio, trovate la frase:

Vero, oggi e' una bella giornata! :)

Aprendo la ROM col Thingy e cercando questa frase, vi si presenterebbe una situazione del genere:

Vero<0B> oggi e<0C> una bella giornata<0E> <0F><10>

Ovviamente i bytes 0B, 0C, 0E, 0F e 10 sono rispettivamente virgola, apostrofo/accento, punto esclamativo, due punti e parentesi. ;)

Per quanto riguarda le compressioni come il DTE/MTE (vedere sotto), invece, l'unico metodo efficace per scovarle è cercare per esempio una decina di parole, così da riuscire a costruire una tabella. Aprite la ROM in un editor come il Thingy e leggere il testo che avete trovato con le tabelle che avete creato. A questo punto cercate di "intuire" quali sillabe/parole mancano e far corrispondere queste supposizioni ad 1 byte.

Per esempio, se nel Thingy vedete le parole "Mario#out", può voler dire che il byte # corrisponde alla MTE " is ", quindi nella vostra tabella non fate altro che aggiungere "#= is " dove # corrisponde al byte hex (naturalmente il tutto senza le virgolette).

Una volta scovati i primi valori, non vi resterà che creare il file .tbl, vale a dire un txt contenente tutti i valori della tabella da voi scoperta. Vi sono due modi per farlo: usare il programma TaBuLar, oppure creare manualmente la tabella creando un txt e rinominandolo successivamente in ".tbl" (assicuratevi che il vostro Windows visualizzi le estensioni per i tipi di file conosciuti, trovate l'opzione in "Opzioni cartella"). Il modo in cui "scrivere" i valori della tabella è il seguente:

10=A
11=B
12=C
...
40=a
41=b
42=c
...
*FE
/FF

2) Metodo del confronto

Questo metodo è poco utilizzato, ma è estremamente utile nel caso di giochi che avessero una tabella del font "sparsa", vale a dire con le lettere che si susseguono in ordine non alfabetico. Se il gioco che volete tradurre permette di cambiare il nome al proprio personaggio (es: Chrono Trigger), potete procedere in questo modo:
Chiamate Crono con il nome "Crono", giocate e salvate. A questo punto rinominate il file del salvataggio chrono.srm in chrono.1. Ora iniziate un'altra partita e chiamate Crono "AAAAA", giocate e salvate. Rinominate chrono.srm in chrono.2 e fate un bel confronto tra i file chrono.1 e chrono.2. È possibile utilizzare Hex Workshop per comparare i due files, oppure usare il comando dos "fc", in questa maniera:

fc /b chrono.1 chrono.2 > cfr.txt

Adesso lanciate edit cfr.txt e andate ad esaminare il file.

file: cfr.txt Confronto dei file chrono.1 e chrono.2 in corso...
0000059C: 01 02
000005B0: A2 A0
000005B1: CB A0
000005B2: C8 A0
000005B3: C7 A0
000005B4: C8 A0
000005E3: 0E 16
000005E4: 12 18
000005FA: 0A 0B
00001FF0: 73 29
00001FF1: 8C 42

Nel file chrono.2 si notano 5 caratteri uguali uno di seguito all'altro che corrispondono al nome "AAAAA", quindi la A = A0 e di conseguenza la C = A2, r = CB, o = C8, n = C7. Ora si può costruire la table seguendo, in questo caso, l'ordine alfabetico (se A = A0 allora B = A1, C = A2 e così via...).
Trucchetto: se A = 41, allora la ROM è in ASCII e si può modificare con un editor esadecimale qualsiasi senza bisogno di una table.

Il metodo con cui è sistemato il testo cambia da gioco a gioco. La stragrandissima maggioranza dei giochi si basa sul metodo "1 byte=1 lettera/simbolo", ma con delle varianti. Vediamo alcune delle principali:

1) DTE/MTE

Lo spazio che una cartuccia metteva a disposizione era sempre molto poco, e questo gli sviluppatori lo sapevano molto bene. Una cartuccia per SNES arriva a non più di 4 Megabytes e, considerando che erano decisamente costose, meno spazio occupava un gioco meglio era. Per questo i programmatori delle varie software house sviluppavano potenti routine di compressione dei dati, cosi da risparmiare quanto più spazio possibile. E mettere in crisi i ROM hackers, anche. :)

La grafica è la parte più consistente, ma esistono metodi di compressione anche per il testo, e la maggior parte si basa sull'assegnazione di più lettere a un solo valore esadecimale.
Il più famoso è il DTE della Squaresoft, in cui a un valore esadecimale corrispondono due lettere (l'acronimo significa infatti Dual Tile Encoding). Le sillabe scelte sono quelle che compaiono con maggior frequenza nel gioco.
Quando a un solo valore esadecimale corrispondono più di 2 lettere, ci troviamo di fronte al cosiddetto MTE, che sta per Multiple Tile Encoding.
Un esempio di ROM che fa uso di MTE è Chrono Trigger, dove la scritta "the" corrisponde al byte $21, "her" al byte $30 e così via. La maggior parte di queste sillabe sono state sostituite dal traduttore, poiché in italiano non sono di nessuna utilità. Così, il byte 27 che in origine era "you" ora è "gli".
Questo però può causare dei problemi nel testo ancora in inglese, perché ora ogni volta che ci dovrebbe essere scritto "you" adesso c'è scritto "gli", per cui anche una parola come "yourself" diventa "glirself". ^__^
Questo è il motivo per cui, in caso di pubblicazioni di patch beta, è meglio scrivere nel "readme.txt" che il rimanente testo in inglese NON sarà più leggibile con la patch in italiano.

Per sostituire le sillabe, bisogna trovarle all'interno della ROM (o nel file dell'ISO che le contiene, nel caso di Chrono Cross era l'eseguibile principale). Generalmente utilizzano la stessa table dei dialoghi, per trovarle potete cercarle col SearchR X. Spesso sono separate da un altro byte, ad esempio in Chrono Trigger sono separate da un valore che rappresenta il numero di lettere che compone la sillaba: 02 se la sillaba è di due lettere). In Final Fantasy III USA invece è il valore esadecimale 7F, e tutte le sillabe sono composte da due lettere. Quindi, ponendo il caso in cui le tre sillabe consecutive fossero "he", "it" e "is", bisognerà scrivere he?it?is nella schermata principale del SearchR.
Al fine di scoprire quali coppie di lettere/simboli sono più comuni nel vostro dump tradotto, consigliamo caldamente il "DTE Tool" di Geo, che trovate nella sezione utilità. Ricordate che l'italiano ha quattro DTE che vi verranno sempre utilissime: "a ", "e ", "i " ed "o ". ;)

L'MTE può presentarsi in diverse forme:

1. Semplicemente, a un byte corrispondono 3 o più lettere

2. Dizionari: questa tecnica di compressione è analoga alla precedente, assegna più lettere a uno stesso valore esadecimale. La differenza sostanziale è un byte "trigger" (grilletto, diverso da ROM a ROM) prima di ogni tile doppia, con lo scopo di segnalare che appunto ciò che segue non è una normale tile. Inoltre, questa routine viene utilizzata quasi sempre per parole intere (e non sillabe).
   I dizionari funzionano più o meno così: in un punto della ROM c'è un "dizionario" con le parole più usate, scritte di seguito e di solito separate da un byte, a cui si può accedere mettendo nel testo del gioco il byte trigger e di seguito il byte indice del dizionario.
   Ad esempio:

   Ciao come <00><A3>

   00 è il byte trigger, A3 indica la parola da usare. In un altro punto della ROM avremo:

   parola<byte fine>parola 2<byte fine>stai<byte fine>parola 3 etc

   È possibile editare i dizionari, ma non si può superare il numero di byte originali, salvo difficili hacking a livello di assembler.
   Alcune ROM utilizzano i dizionari per cose particolari come i nomi dei personaggi o frasi che scompaiono dopo che il giocatore preme un tasto.
   Per esempio in Secret of Mana il nome dei vari personaggi è formato da due bytes: il byte n.57 e un byte che può essere 00, 01 o 02 a seconda di quale dei tre personaggi vi era scritto. Questo metodo è comunissimi in tutti i giochi di ruolo dove è possibile rinominare i personaggi.

3. Substring: questo sistema si discosta un po' da quelli precedenti. Infatti, le substring sono dei puntatori! (ancora non sapete cosa sono, continuate a leggere questa guida, e poi date un'occhiata alla nostra guida ai puntatori SNES).
   Anche in questo caso c'è un byte trigger, però vengono letti i 2 (o 3, dipende dalla ROM) bytes successivi, che sono appunto un puntatore. Questo significa che le substring permettono di puntare in un qualunque punto del banco, così da utilizzare eventuale spazio inutilizzato.
   Un esempio di ROM che usa le substrings (e anche i dizionari) è Terranigma della Enix, in cui il byte trigger per le substrings è CB.

NB: sebbene queste siano le tre varianti con cui più spesso si presenta il MTE, ogni gioco è diverso dagli altri e potrebbe usare tecniche di compressione diverse, quindi non prendete per oro colato tutto quello che leggete. Usate la vostra intelligenza e fate esperimenti. :)

Può capitare che le varie sillabe non abbiano la stessa tabella del testo (ovvero che questi byte speciali non siano una specie di comando per concatenare più lettere), ma che in ogni tile doppia siano effettivamente disegnati più caratteri. Questo genere di tile è generalmente chiamato "dte grafico" (o "squished tiles", se ci riferiamo alle sole ROM), e l'unica soluzione per utilizzarle è fare un hacking della grafica. Se non avete esperienza di programmazione ma intendete crearvi delle DTE per comprimere un testo, il metodo del DTE grafico potrebbe fare al caso vostro. Una sola annotazione: è sconveniente utilizzare il DTE grafico su testi che compaiono gradualmente (una lettera alla volta). Questo perché il giocatore avvertirebbe un effetto di comparsa simultanea di due lettere, che causerebbe un'impressione sgradevole. Utilizzatele invece con testi a comparsa immediata, come solitamente sono i menu dei giochi di ruolo. In quel caso, le sillabe grafiche sono assolutamente indistinguibili dalle lettere singole (noi stessi ne abbiamo fatto ampiamente uso per i menu di Final Fantasy Tactics e Final Fantasy VII).
Sconsigliamo ai principianti di iniziare a tradurre una ROM che sfrutti tile multiple, per fare pratica è meglio iniziare con una più semplice.

2) La codifica a 16 bit

Molto in breve, con questa tra una parola e l'altra viene interposto un altro byte. Per esempio, al posto di "YES" ci sarà scritto "YxExSx" dove "x" può essere un byte qualunque. Anche gli eseguibili per Windows sfruttano questo sistema, nei quali di frequente si può trovare le lettere separate da un punto (c.o.s.ì. .a.d. .e.s.e.m.p.i.o).
Pochi giochi, come per esempio Harvest Moon, utilizzano questo sistema, tenetelo però in considerazione quando con la ricerca relativa non avete nessun risultato, perché il testo cercato (specialmente quello dei menù) potrebbe essere codificato in questo modo.
Solitamente questo metodo è un rimasuglio della versione giapponese di un gioco. Per scrivere i testi di un gioco in giapponese sono infatti necessari migliaia di ideogrammi. Una codifica a 8 bit (1 byte) permette di utilizzare 255 caratteri diversi. Mentre a noi occidentali questa cifra può sembrare un'enormità, è decisamente insufficiente per la lingua giapponese, che utilizza migliaia di ideogrammi, oltre all'alfabeto fonetico dei katakana. Da qui la necessità di una codifica a 16 bit, che permette 255^2 valori diversi, vale a dire ben 65025 caratteri possibili!

Se volete lavorare su un gioco recente, tenete conto che molti giochi moderni utilizzano la codifica UNICODE. Dunque potrebbe non essere più tanto strano trovare del testo codificato a 16 bit. Esistono anche codifiche a 32 bit, ma sono rarissime poiché occupano una marea di bytes (4 bytes per una sola lettera!). In oltre 10 anni di traduzioni, abbiamo incontrato questa codifica in due giochi: nell'hacking di Super Mario World e nella traduzione di Xenogears, dove per altro era utilizzata per scrivere le sole parole "Next Level" nel menu principale. Ma questi sono decisamente casi limite! :D

3) Interleaved Genesis ROM

Le ROM per Megadrive in formato SMD hanno una strana disposizione dei bytes nella ROM e di conseguenza anche delle lettere. Per questo motivo, non sono traducibili senza essere prima convertite in formato BIN. Diverse utility (uCON, GenConv, SegaTool) sono capaci di farlo.

4) Byteswap

Le ROM per Nintendo64 dumpate con il Doctor64 (formato V64) sfruttano questo sistema. Praticamente i byte nella ROM sono invertiti a due a due (byteswapping), perciò la parola "MARIO " diventa "AMIR O". Procuratevi un'utility per convertire la ROM su Romhacking.NET.

5) Testo compresso

In realtà non si tratta di una codifica del testo, ma per comodità lo inseriremo in questa categoria.
Nonostante l'avvento di giochi memorizzati su supporti ottici sempre più capienti, le Software House non hanno mai smesso di utilizzare qualche algoritmo di compressione sui testi dei giochi. L'utilità è doppia: proteggere il testo dai romhacker e rendere lievemente più veloci i caricamenti da disco. Inutile dire che la grandissima maggioranza dei giochi compressi utilizza un formato proprietario, cioè creato ad hoc per quel titolo. In poche parole, dovrete cavarvela da soli, a meno che non abbiate qualche hacker/programmatore al vostro fianco. Se lavorate su qualche gioco molto recente, però, provate prima a cercare qualche utilità di de/compressione già pronta su Google, non è detto che non sia stata sviluppata (un esempio famoso è la saga di Winning Eleven/Pro Evolution Soccer, per i quali sono disponibili decine di tools).
Se l'argomento compressioni vi interessa, date un'occhiata alla guida di Phoenix alla decompressione della LZSS, una delle compressioni più comuni, anche se utilizzata in un'infinità di varianti.

Sui puntatori si sono scritte decine di guide in tutte le lingue. Essi, per i neofiti, sono un po' come il sacro Graal: introvabili ma sempre anelati, la beatitudine celata. Scherzi a parte, è proprio vero che il diavolo è meno brutto di quanto lo si dipinge. Una volta appreso il meccanismo sfruttato dai puntatori, diventa improvvisamente molto facile rintracciarli e modificarli... o almeno quelli in formato standard. ;)
Cominciamo a definire il concetto di puntatore, in maniera assolutamente semplicistica: un puntatore è un insieme di byte che indicano l'offset iniziale di una serie di dati. Questi dati possono essere interi file o semplicemente testo. Vien da sé che, al momento, ci interessano questi ultimi. Di puntatori esistono molte tipologie (alcune le tratteremo nelle guide successive), ma i più comuni sono i puntatori a 16 bit. Un puntatore a 16 bit è formato da una coppia di byte che indica l'offset da cui comincia una stringa di testo. Importante: questo indirizzo risulterà sempre invertito, a meno che non lavoriate con una console con processore Big Endian.

1) Esempio di puntatore standard

Poniamo di stare lavorando non su una ROM ma su un singolo file (di un gioco PSX, ad esempio). La frase che dobbiamo spostare comincia all'offset 0x2A50. Vi aspettereste di dover cercare in hex la coppia di byte 2A 50... e invece no! Dovrete cercare nel file i byte 50 2A, ovvero la coppia di byte con i valori invertiti! Questa apparente stranezza è facilmente spiegabile con il concetto di ordine dei byte. La maggior parte delle console utilizza il Little Endian, dove il byte meno significativo sta a sinistra di quello più significativo, al contrario della nostra numerazione "umana". Qualora lavoraste su una console Big Endian, come ad esempio il Mega Drive/Genesis, non dovete invertire la coppia di byte.
Un concetto importante da tenere a mente è i che i puntatori hanno bisogno dei byte 00, se il valore non è abbastanza grande da coprire tutti i byte del puntatore. Dunque, se il vostro offset è 0xC0, nel file troverete C0 00. La cosa si applica anche in caso di puntatori composti da 4 o più bytes (puntatori a 32 bit); esempio 50 2A 00 00 per indicare l'offset 0x2A50.

2) I puntatori nelle ROM SNES

Tutto qui, dite? No, non è proprio tutto qui. Questo semplice sistema solitamente va benissimo per chi lavora su singoli file molto piccoli, mentre è assolutamente inadatto per chi vuole tradurre una ROM, in quanto nelle ROM sono spesso presenti degli header, cioè una serie di byte iniziali che non fanno parte della ROM ma sono aggiunti dal software di dumping della cartuccia. La presenza di questi byte in eccesso "sposta in avanti" tutti i valori successivi, causando un'apparente discordanza tra il puntatore e l'offset. Mettiamo ad esempio che il vostro file/ROM abbia un header di $10 bytes: la frase che a voi interessa sarà localizzata all'offset 0x2A60, non più 0x2A50! Ciò però non vuol dire che il puntatore sia cambiato: per lui quei $10 di header semplicemente non esistono. :)
Ogni volta che dovete cercare un puntatore in una ROM, dunque, ricordavi di sottrarre dall'indirizzo della frase il valore dell'header. Nelle ROM NES l'header consta di soli 10$, in quelle SNES gli header sono solitamente $200. Esempio: il vostro offset in una ROM SNES con header è sempre 0x2A50? Dovrete prima sottrarre 0x200, ottenendo 0x2850, e poi invertire la coppia (0x5028)
Un'altra particolarità delle ROM è quella di lavorare "a banchi". Senza spiegarlo approfonditamente, diciamo che il testo in una ROM può trovarsi ad un offset molto elevato, ad esempio 0x0281CC0. In questo caso, dopo aver sottratto l'eventuale header, dovrete "staccare" gli ultimi due bytes ed invertirli. Lo 02 non andrà calcolato, poiché i puntatori SNES sono a 16 bit, non a 32. Per approfondire il discorso di puntatori per ROM SNES vi rimando alla guida sui puntatori hirom.
Concetto molto importante: solitamente è facile individuare un banco di puntatori. Un banco è un insieme di puntatori che puntano a frasi (o file) in sequenza. Mettiamo di avere questa situazione:

Frase 1, offset 0x2A00
Frase 2, offset 0x2A20
Frase 3, offset 0x2A30
Frase 4, offset 0x2A3F

3) Tipologie meno comuni di puntatori

Tra gli altri tipi di puntatori troviamo quelli a 32 bit, utilizzati soprattutto per puntare ai sottofile di un archivio, ed in alcuni casi applicati ai testi. Sempre riprendendo l'offset 0x2A50, un puntatore a 32 bit lo indicherebbe come 0x502A0000.
Un tipo particolare di puntatori a 32 byte sono quelli usati dal Game Boy Advance. Essi utilizzano 3 bytes su 4 per l'offset, mentre l'ultimo è sempre un byte con valore 08. L'offset 0xE4756D sarà indicato da un puntatore 6D 75 E4 08.
Una tipologia poco comune sono i "puntatori dimezzati" (non hanno un nome effettivo, a quanto ne sappiamo), che noi abbiamo incontrato in Vagrant Story. Essi hanno la particolarità di segnare la metà dell'offset reale, è il gioco a moltiplicare per 2 il valore riportato nel file. Per ovvi motivi matematici (qualsiasi cifra moltiplicata per 2 è sempre pari), questo metodo non può puntare ad offset dispari, e ciò richiede di inserire un byte di padding, se il testo risultasse composto da una quantità di byte dispari.
Una tipologia molto particolare di puntatori sono quelli all'offset in RAM, che tratteremo nella terza parte della guida all'hacking, che riguarderà la Playstation (et similia).
Ovviamente esistono molti altri tipi di puntatori particolari, in quanto ogni gioco è un "universo tecnico" a sé stante. Cercate dunque di sfruttare il vostro intuito se aveste problemi, e fate quante più prove possibili. In ogni caso, il modo migliore e più rapido per scoprire il formato dei puntatori è ricorrere ad una lettura del codice ASM del gioco tramite un debugger.

Fino ad ora abbiamo parlato di come trovare il testo e come editarlo "al volo", cioè agendo direttamente sulla ROM, cambiando byte per byte. Questo metodo ha però dei grossissimi svantaggi, tra cui la facilità con cui potreste corrompere i dati del gioco, la difficoltà di inserimento del testo, l'impossibilità di ricercare una data parola all'interno del testo, la lungaggine del metodo e tanto altro. Il metodo dell'editing al volo può andare bene solo per modificare file dal pochissimo testo e dove non vi fosse necessità di espansioni o modifiche ai puntatori. Se intendete invece effettuare traduzioni di testi molto corposi, sarà d'obbligo estrarre il testo dall'interno del gioco.

La procedura di estrazione del testo è tecnicamente chiamata dumping (scaricamento). Si utilizza un programma per analizzare le porzioni di dati testuali e convertirli in un semplice e comodissimo txt (oppure in qualche altro formato più complesso, ma solitamente si dumpa in txt, a meno che non vi programmiate dei tools appositi per il vostro progetto).

1) Dump di base con ThingyV, Translhextion, ecc.

Questi due storici programmi hanno delle comodissime funzioni di dumping, molto semplici da utilizzare. Con il Thingy, posizionatevi all'inizio del testo che desiderate dumpare e premete il tasto D. Il programma vi chiederà se desiderate dumpare manualmente o automaticamente. Nel primo caso, posto che il dump partirà dal byte su cui avete premuto il tasto D, dovrete solo scendere fino a selezionare l'ultimo byte che vi interessa. Il programma vi chiederà il nome con cui volete salvare il vostro dump, che verrà creato nella stessa cartella del Thingy. Conviene utilizzare il dumping manuale solo per blocchi molti piccoli, visto che dovrete scorrere manualmente il file per arrivare al byte finale.
Il dumping automatico (chiamato "Aggiungi Posizione") vi chiederà invece l'offset iniziale del testo e quello finale, dumpando automaticamente tutto ciò che è contenuto tra i due offset. Ovviamente, vi sarà poi chiesto con che nome salvare il file Questo metodo è ottimale se bisogna dumpare un blocco di testo molto ampio.

Il procedimento con il Translhextion è molto simile, anche se c'è la leggera differenza di trovarsi in ambiente Windows 32. Per l'estrazione manuale, bisogna solo utilizzare il mouse per selezionare il testo da estrarre, per poi fare un click destro sul testo selezionato (evidenziato in giallo). Una volta cliccato su "Hexdump" vi si aprirà una finestra dove appaiono l'offset iniziale e quello finale del blocco selezionato. Selezionando l'opzione "Export to file" sarà infine possibile creare un txt con il dump del testo che avete scelto.
L'operazione automatica è simile a questa appena descritta. Cliccate su "Selection" nel menu contestuale, per poi selezionare "Export as hexdump". Inserite l'offset iniziale e quello finale per salvare il vostro txt.

Le operazioni di reinserimento sono speculari all'estrazione e non dovrebbero destare alcun problema. Se intendete ricalcolare i puntatori, dovrete pero utilizzare un ulteriore software a vostra scelta. Su Romhackig.NET sono disponibili numerosi programmi per il ricalcolo dei puntatori.

2) Dump avanzato con Atlas & Cartographer

L'apparente semplicità nel dumpare i testi con il Thingy ed il Translhextion nasconde una grossissima magagna: l'impossibilità di espandere le frasi e di ricalcolare i puntatori. Proprio per questo, nel corso degli anni, si sono sviluppate utility sempre più raffinate per la gestione di testo e puntatori. Certo, nulla batte la possibilità di avere un programma tarato su misura per il gioco su cui state lavorando, ma se ciò fosse impossibile, questi due programmi potranno venirvi in aiuto!

Cartographer è un programma che, tramite la creazione di uno script, permette di estrarre facilmente il testo di un file e di gestire la tabella dei puntatori. Questo script dovrà contenere informazioni quali la tabella da utilizzare, il formato dei puntatori e tanto altro. Nel pacchetto del programma è compreso lo script per l'estrazione del testo dalla ROM di Final Fantasy I inglese per NES. Il file in sé è piuttosto lungo e pieno di dettagli, ma il programma è fornito di un readme molto dettagliato.
In soldoni, vi servirà sapere inizio e fine della tabella dei puntatori e del blocco di testo. Potrete poi impostare eventuali parametri come stringhe a lunghezza fissa e la tipologia di puntatori (16 o 32 bit). Sono disponibili due modalità di dumping: una nella quale non vengono riportati i puntatori ed una in cui invece ad ogni blocco di testo è associato l'offset del puntatore ed il suo valore. Questa seconda modalità è particolarmente utile se si lavora con testi dai puntatori sparsi e non "storati" in una semplice tabella. Fate riferimento al dettagliatissimo readme per maggiori informazioni.
Vi sconsigliamo di utilizzare questo programma finché non avrete molto chiaro il concetto di puntatore, di tabella di puntatori e di banco di testo.

Lo scopo principale di Cartographer è quello di preparare un txt compatibile con il programma Atlas. Benché sia teoricamente possibile fare tutto manualmente, Cartographer potrà darvi una grossissima mano. Tuttavia, non potrete "dare in pasto" ad Atlas il vostro textdump finché non avrete inserito all'interno le informazioni per la table da usare e che tipo di puntatori il gioco utilizza. Per maggiori informazioni, trovare allegato ad Atlas un completissimo manuale.

Se avete afferrato (bene o male :D ) tutto ciò che è stato spiegato in questa prima parte della guida, e se avete effettuato i vostri esperimenti con successo, siete pronti a passare al livello successivo, dove tratteremo di casi particolari di puntatori, di grafica, di (eventuale) inserimento di files e di come creare una patch.
A questo punto incontrate un bivio. Scegliete se leggere la guida all'hacking per giochi senza file system (ROM dal NES al GBA) o con file system (file ISO, più le ROM del NDS). Benché sia un bene fare esperienza prima sulle ROM, è anche vero che non è per nulla necessario essere esperti di hacking per SNES al fine di lavorare egregiamente su PSX e affini.
Trovate le altre parti di questa guida nell'indice della sezione "Guide".

Q: Ho rinominato la ROM/il file XYZ in formato TXT, perché non vedo il testo? (domanda realmente posta)
A: È necessario leggere il resto della guida per tradurre una ROM. Perciò se pensavi che le sole FAQ bastassero, lascia perdere. :P

Q: Ora ho trovato la tabella del font, ma cosa me ne faccio?!?
A: Ti scarichi un editor e ti leggi le istruzioni su come utilizzarlo. Poi utilizzi la table.
Non chiedete di spiegare come funziona ogni singolo editor di testo! Il readme è sempre molto completo.
(Per il Thingy, se dopo aver letto il readme avete ancora problemi, potete leggere la nostra guida all'uso del Thingy).
Generalmente è necessario inserire in un file di testo la tabella che avete trovato, ma il sistema cambia da editor a editor.

Q: Perché non riesco a trovare certe parole col SearchR X, o le parole compaiono "troncate"?
A: Probabilmente il gioco utilizza un sistema come il DTE e gli altri elencati qui sopra. Se siete particolarmente sfigati è possibile che lo script sia compresso con qualche algoritmo "tradizionale", come ad esempio Huffman (avete presente il winzip?). In tal caso o siete bravi a programmare o non c'è niente da fare. Se ve la sentite, fate riferimento alla guida di Phoenix alla decompressione della LZSS.

Q: Il SearchR X non trova alcuna parola! Perché?
A: Assumendo che tu abbia tenuto in considerazione tutti i sistemi di codifica precedentemente elencati nella guida, è possibile che il testo sia compresso in una maniera particolare (provate a comprimere un file di testo con il WinZip, per intenderci). Vi sono poi alcuni rarissimi giochi quali col SearchR non si trova nulla perché essi utilizzano una codifica inferiore al singolo byte per carattere. Un esempio è Bart Simpson VS the World per NES, dove ogni nibble (mezzo byte) rappresenta un carattere o un byte trigger.

Q: Perché il SearchR X trova corrispondenze diverse cercando la stessa parola (nel senso che, cercando una parola e trovandone varie corrispondenze nella ROM/nel file, trova che la lettera A risulta associata a diversi numeri esadecimali)?
A: Il SearchR X prova tutte le combinazioni secondo cui una successione di numeri può formare la parola cercata. È possibile che, per puro caso, tra i dati analizzati vi fossero dei numeri che, messi in un certo modo, formassero la parola cercata (questo capita in particolar modo con le parole più piccole). Può anche darsi che la ROM abbia più di una tabella (Final Fantasy III USA ne ha una per l'inventario e una per il resto del gioco).

Q: Come mai cercando la stessa parola con le maiuscole e con le minuscole ottengo gli stessi risultati? Significa che quel gioco utilizza allo stesso modo maiuscole e minuscole?
A: No, semplicemente, come detto sopra, il SearchR X trova le stesse corrispondenze se la sequenza delle lettere è la stessa. Infatti, per esempio, il rapporto fra la lettera A e la lettera C, in numeri, è sempre C=A+2 sia che le lettere siano maiuscole, sia che siano minuscole... speriamo di essere stati chiari in questo caso. ^__^

Q: Posso modificare le ROM/i file in ASCII direttamente con un editor di testo come il WordPad?
A: No, la ROM/il file si rovinerebbe. I byte non testuali vengono riprodotti come specie di "quadratini", che vengono considerati tutti uguali, e di conseguenza vengono salvati tutti con lo stesso numero. Ovviamente dopo la il gioco (in special modo la ROM) non funziona più.
Qualche eccezione potrebbe esservi però su console recenti. Xenosaga Episode I per Playstation, ad esempio, ha tutte le email presenti nel gioco salvate come txt "nudi e crudi". Ma sono casi di per sé rari, e presenti praticamente solo nelle console di nuova generazione, che spesso condividono il formato dei propri files con i computer.

Q: Voglio ottenere più spazio nella ROM/nel file! Come devo fare?
A: È necessario fare un hacking dei puntatori in modo da dirottarli in una zona libera che aggiungete in fondo alla ROM/al file. Il procedimento è spiegato dettagliatamente nel documento sull'hacking dei puntatori scritto da mickey. A seconda del tipo di puntatori, vi potrebbe venire più o meno facile espandere il testo. Vi consigliamo anche di leggere le guide all'hacking delle ROM e dei giochi con filesystem.

Q: Ho tradotto una ROM del Gameboy, ma quando faccio partire l'emulatore dà un errore di "checksum". Che fare?
Le ROM del Gameboy hanno un particolare sistema secondo cui, qualunque cosa venga modificata nella ROM, bisogna cambiare dei byte anche nell'header (la parte iniziale della ROM che la fa identificare dalla console). Pare che non tutti gli emulatori siano in grado di far funzionare ROM con il checksum incorretto (cioè una ROM tradotta), di conseguenza vi conviene usare un programma come l'HebeGB per modificare il checksum e farlo risultare corretto all'emulatore.

Q: Le patch di traduzione sono legali?
A: Fintanto che la patch viene distribuita senza la ROM o il file ISO, risulta legale. È invece illegale distribuire una ROM o in file ISO ai quali sia già applicata la patch. Questo perché per scaricare una ROM o un file immagine è necessario possedere il gioco su supporto originale (per le console fino a 16-bit, generalmente la cartuccia), e nessuno può avere su cartuccia (o sul disco originale) una ROM tradotta.

Q: Dove posso trovare altre guide?
A: Se ti riferisci a guide in italiano, ti consigliamo di cercarle su Romhacking.IT o su ZTG. I also suggest to read some English guides, the best place to find them is Romhacking.NET. After all, since you want to translate games from English to Italian, you are supposed to speak at least a decent English... so you should have no problem understanding them. ;)

Bene, se ci sono domande che riteniate vadano aggiunte a queste FAQ o se semplicemente avete ulteriori problemi, scrivete sul nostro forum specificando di aver letto la presente guida e dando informazioni precise su cosa non riuscite a fare.