Voglio capirci qualcosa di più...

[Gemini]

Più che altro devi imparare a ragionare come un programma. Il linguaggio non credo conti più di tanto, anche se partire dal c potrebbe darti una spinta in più, ma non è detto. In fondo c'è tanta gente che inizia direttamente dall'asm senza nemmeno essere passato per un qualsiasi linguaggio ad alto livello.

[Clomax]

Più che altro devi imparare a ragionare come un programma.

più che altro come un programmatore... non importa da dove inizi, non c'è un'unica strada per imparare a programmare. cosa devi fare? perfetto, rimboccati le maniche, studia e prova, prova e riprova. che sia assembler, che sia c, che sia java se un linguaggio corrisponde alle tue esigenze lo usi.

una delle risposte più apprezzate nei colloqui è: "il linguaggio di programmazione è solo un mezzo".

[Gemini]

più che altro come un programmatore...

Non esattamente, o almeno la risposta cambia a seconda delle esigenze. Per capire il codice di un gioco si deve capire esattamente cosa fa una routine e anche conoscendo come si comporterebbe un programmatore non è detto che si arrivi a capire cosa fa il programma, soprattutto se c'è un compilatore di linguaggio ad alto livello dietro. La domanda "e questo come potrebbe funzionare o come si attiva?" ti dice nulla?

[Jegriva]

Già che ci siamo: libri sull'ASM da reperire?

[bell1-1010]

Jeg ma non ti è sufficente la guida sul sito?
l'ho trovata relativamente (sottolineo relativamente)semplice....    

[darkdream]

qualcuno ha parlato di gameboy e vwf? :brucelee:

http://www.romhacking.it/downloads/guide/e...ida_gbasmhk.doc

per i puntatori dai una occhiata qui
http://www.zuminator.altervista.org/guide/...hackvol1ZTG.rar

(io ho cominciato a programmare direttamente su gb-z80...
http://www.romhacking.net/forum/index.php?...msg7583#msg7583 )

[Syxtem]

Per quanto mi riguarda l'asm dello Z80 è uno dei più facili in assoluto. Innanzitutto è di tipo CISC (e questo non può che farmi molto piacere) e poi segue molto da vicino quello per architetture x86 (pur in maniera MOLTO più semplificata), che io tratto con maggiore frequenza.
Poi, ovviamente, non è necessario sapere il c per sapere l'assembly (altrimenti il primo compilatore c come avrebbero fatto a scriverlo?). Invece, è abbastanza utile avere qualche nozione di assembly quando si programma con linguaggi di un certo livello. Questo per motivi di ottimizzazione, di stesura del codice etc.
C'è da dire cmq che in genere il c ha diverse analogie rispetto al corrispettivo codice assembly (per lo meno con l'asm di tipo CISC) per cui io spesso e volentieri cerco di convertire mentalmente il codice da asm a c (dato che che in quest'ultimo linguaggio tutto diventa molto più "accessibile"). Tempo fa avevo pure scritto una specie di pseudo-guida che trattava in maniera relativamente approfondita l'assembly x86 e quello per lo Z80 (con elencate le differenze tra quel tipo di asm e quello nei processori del gameboy). Alla fine era una specie di traduzione/rielaborazione di alcuni documenti che avevo trovato in giro sulle varie architetture però c'era anche un esempio (secondo me carino) su una rom GB per imparare un po' a capire quel tipo di asm (si trattava proprio di un esercizio di reversing). Purtroppo con lo spostamento del sito ad un nuovo dominio ancora non ho avuto la voglia di spostare tutto il materiale e rimetterlo online.

Per capire i puntatori, il C non serve... o almeno... non serve per capire come modificare i puntatori in una rom. Questo per un semplice motivo.
Fai conto di considerare un puntatore come una specie di freccia. Le informazioni interessanti di questo pseudo-vettore sono il punto di applicazione (il punto di partenza), la lunghezza di questo vettore e la fine di questa freccia (ossia il punto di arrivo).

Codice Seleziona Espandi


  Partenza                 (Lunghezza)                  Arrivo
        -------------------------------------------------->

In un linguaggio di programmazione viene considerato esclusivamente il punto d'arrivo (perchè è l'unica cosa che serve per far andare il programma), per altro in maniera piuttosto implicita. Alla fine poi il punto di arrivo è calcolato come la somma dell'indirizzo di partenza con la lunghezza, ma tutto ciò viene fatto in maniera completamente trasparente. Tieni conto che poi in altri linguaggi, tipo Java, i puntatori manco esistono come tipo di dato e sono totalmente impliciti nel linguaggio.
Quello che invece più probabilmente interessa a te è conoscere gli altri due parametri. Il punto di partenza non ha un vincolo preciso. Può essere determinato dalle specifiche della rom o può essere stabilito all'interno del codice stesso. La lunghezza in genere invece è sempre espressa da qualche parte all'interno della rom. È ovvio poi che, sapendo il punto di arrivo e la lunghezza è possibile risalire al punto di partenza e non ho intenzione di scrivere come "modificare" i puntatori anche perchè il tuo problema hai detto che è "capirli". Una volta capiti avrai tutto il tempo per fare le dovute prove e sbatterci la testa sopra.
Quello che ho scritto sopra è in pratica l'implementazione pratica di un puntatore (astraendo tutto ad offset e byte).
Se ti può essere più semplice capirlo come concetto puoi pensare ai puntatori come un array informatico (spero tu sappia cos'è... in caso contrario leggilo sulla guida che ti sei stampato). [Infatti in c è possibile anche dichiarare dei puntatori e poi utilizzarli direttamente e nello stesso modo degli array, tanto per far capire che i due concetti non sono poi così distanti.]
Ecco, fai conto la tua variabile array si chiami "memoria" e la variabile "index" sia appunto l'indice di questo array. Si ha una cosa di questo tipo: memoria[index]
Beh, questo index è in pratica un puntatore a tutti gli effetti. Se ci rifletti un po' su riuscirai a cogliere l'analogia.
È ovvio che tutto quello che ho scritto è un po' sintesi di tutto il concetto e vengono fatte anche alcune approssimazioni che nemmeno ho esplicitato (ma mica volevo scrivere una guida... volevo solo rispondere ad un post), ma in linea di massima tutto dovrebbe essere corretto. Poi magari in alcune guide si adottano ulteriori semplificazioni (con esempi) ed è ancora più chiaro, ma qua io ho cercato di mantenere un certo rigore tra concetto in sè ed implementazione dello stesso (in maniera volendo un po' alternativa, così da vedere se in questo modo è più chiaro).

Per i font a larghezza variabile è inutile scrivere qualcosa in un topic. Ti rimando alle guide specifiche e ti consiglio di appoggiarti a qualche tutorial e a 2-3 esempi pratici.

Per quanto riguarda le compressioni invece... non c'è una regola per "capirle". Sono algoritmi. Li leggi e cerchi di capire perchè funzionano (magari facendoti un debug mentale o su un foglio di carta con qualche esempio). Ad esempio la compressione huffman mi pare piuttosto semplice da capire perchè riesce a comprimere. L'unica difficoltà lì è capire i concetti fondamentali dell'informatica, come gli alberi e com'è sfruttato l'albero in quel particolare algoritmo.

Infine, per rispondere a "Già che ci siamo: libri sull'ASM da reperire?", se sei abbastanza pazzo puoi cercare "The Art of Assembly" che è un tomo gigante da centinaia di pagine, rigorosamente in inglese e rigorosamente su asm x86. Ma in quella bibbia viene sviscerato quasi tutto quello che può essere interessante riguardo all'assembly x86 e all'asm in generale, con consigli, riflessioni ed osservazioni, esempi a palate ed anche una guida che ti insegna ad usare il compilatore MASM, che rimane forse il miglior compilatore assembly x86 sulla piazza. È uscita anche la versione per compilare asm x64, ma quello ancora non l'ho provato.

[Phoenix]

Per le compressioni (o almeno la base) c'è la mia guida  :w00t: