Rippiamo e Ricostruiamo Spy Vs Spy dal TAP originale, passo dopo passo
Articolo di iAN CooG, pubblicato il 04-08-2007.
Categoria: Programmazione.

028_spy_vs_spy_cover.jpg 028_spy_vs_spy.png
La scheda di Spy vs Spy su Ready64.it


Questo articolo si prefigge lo scopo di spiegare come ricostruire un programma C64 rippando (estraendo) gli spezzoni dal TAP originale, lavorando solo ed esclusivamente dal lato PC, con vari crosstools.

I tools necessari sono:

  • FinalTAP o TapClean [http] a scelta (FinalTAP 2.5 e' stato usato in questo esempio);
  • Exomizer 2.0b6 [http];
  • Multipack [http];
  • Dasm [http].

Opzionali:

  • 65xxdis o altri disassembler 6502 [http], indispensabile una buona preparazione in ASM 6502 e conoscenza del C64;
  • Hiew o altri hexeditors (e' sempre bene esaminare i files per sapere come sono fatti).

La base per il nostro esempio sara' il gioco Spy vs Spy (download), nella versione prelevata dal sito: http://tapes.c64.no. Mentre per seguire passo passo il procedimento, e' possibile scaricare il package completo con gli esempi.

Con FinalTap iniziamo ad estrarre i vari spezzoni, io ho chiamato i files con un progressivo e l'indirizzo di partenza e stanno nella dir "SPLITTED\". I nomi dei files li ho rinominati per poterli raggruppare.

Questi servono per l'immagine di caricamento:

  • 1-2000-pic.prg
  • 2-0400-scr.prg
  • 3-d800-col.prg

sono riconoscibili per la lunghezza, 1000 bytes ognuno per memoria video e colore, 8000 bytes per la memoria bitmap, gli indirizzi (0400 e d800) parlano da soli.

Questi servono per ricostruire in memoria il gioco:

01-4000.prg
02-f700.prg
03-6600+c000.prg (*2)
04-0900.prg

(*2) sono 2 files gia' uniti assieme perche' contigui, lasciare attiva la voce in FinalTAP "join neighbour". Questi invece non ci servono: (SPLITTED\NOT USED\)

0000-02a7.prg
0000-0300.prg
0000-033c.prg
4d000.prg
d000
00-0400(empty).prg
05-starter.prg

I 3 files 0000-* sono il loader vero e proprio, normalmente andrebbe disassemblato per capire come vengono caricati in sequenza i files e dove eventualmente vengono rilocati - non sempre infatti i files vengono lasciati nella zona di memoria dove vengono caricati. Ma questa volta siamo fortunati, e vedremo il perche'.

I files 4d000 e d000 servono per settare i registri VIC mentre vengono caricati, il primo per settare il modo grafico per far vedere l'immagine, il secondo per spegnere lo schermo prima di finire il caricamento, perche' uno dei prossimi files(*) sovrascriverebbe l'immagine e la si vedrebbe "rovinarsi" man mano che vengono letti i bytes dalla loc. $2000 in poi.

(*) 04-0900.prg

il file 00-0400 e' semplicemente pieno di spazi, per pulire lo schermo. Inutile.

05-starter.prg, l'ultimo file presente sul TAP, e' utile solo per sapere la sys di partenza, l'indirizzo di partenza di questo file e 02a7 e viene quindi eseguito automaticamente. Dissasemblandolo otteniamo:

02A7  A9 7F     LDA #$7F
02A9 8D 0D DC STA $DC0D
02AC 8D 0D DD STA $DD0D
02AF AD 0D DC LDA $DC0D
02B2 AD 0C DD LDA $DD0C
02B5 4C 00 66 JMP $660
che serve in pratica per fermare le interrupt ed eseguire il gioco (JMP$6600).
A noi interessa solo l'inidirzzo di partenza. Non dobbiamo nemmeno disassemblare il loader.

Ora possiamo incominciare.

Passo 1

Abbiamo i files spezzati, dobbiamo farne un file unico.
Per fare questo possiamo usare un linker su C64 (sledgehammer, PSQlink e altri) ma visto che stiamo operando da PC e per risparmiare tempo usiamo CBMCOMBINE.
Il file STEP1.BAT e' gia' pronto per fare il tutto. in STEP1\ troviamo il file gia' linkato. Possiamo provare a vedere se il tutto e' ok usando un cruncher o un packer. PuCrunch e Exomizer vanno meglio di qualunque altro compressore nativo.

Quando comprimiamo il file ricordiamoci di dare come indirizzo di partenza $6600, che abbiamo trovato prima. Lanciando, in STEP1\, try_it_now.bat otteniamo una preview del gioco. A chi non interessa la loading picture il discorso potrebbe finire qua, ma dato che ci siamo, facciamo le cose per bene.

Passo 2

Il file ottenuto dallo step2 occupa praticamente tutta la ram. Come facciamo ad infilare la loading picture? Proviamo a comprimere il file con un charpacker (serve per eliminare le sequenze di carateri ripetuti, praticamente un compressore RLE).

Io uso NoStackUsing packer degli Active, si possono usare tantissimi altri come BYG compactor, Zipper, frontpacker, ma l'importante e' che il risultato sia di aver dimezzato il file come STEP2\svs_0900-fbff.charpacked.prg Ora abbiamo liberato la memoria da $B000 a $FFFF, possiamo farcela.

Passo 3

Le immagini non appaiono da sole, dobbiamo fare un prg di visualizzazione o utilizzare un pic linker, anche se questi funzionanao se si ha l'immagine in formato Koala/Art studio... dobbiamo arrangiarci, picview.asm e' quello che ho fatto per le mie releases e torna utile. Visualizza l'immagine situata a $E000, prende la memoria colore da $B800 e la sposta a $D800, la memoria video da $B400 a $C400, poi aspetta lo spazio/fire del joy, dissolve i colori dell'immagine e fa partire il programma linkato.

Dobbiamo unire gli spezzoni dell'immagine, il visualizzatore e il gioco precedentemente charpaccato, usando cbmcombine (o step3.bat)

Il file in memoria risultera' cosi' composto:

$0801       $A398  $b400         $bbff  $c000/$c10f  $e000          $ff40
+------------+.....+---------------+....+----+.......+---------------+
| gioco | | | |pic | | |
|charpaccato | |memvideo+colore| |view| | bitmap |
+------------+.....+---------------+....+----+.......+---------------+

Step 4)

Ora possiamo comprimere il file dando come indirizzo di partenza $C000, la routine di visualizzazione dell'immagine; step4.bat per vedere come fare.

Fine. Abbiamo il nostro SPYVSSPY +PIC pronto.

Il procedimento viene eseguito interamente con un PC. E' molto piu' facile e immediato rispetto alle evoluzioni necessarie su un C64 vero, dove il solo tempo di compressione del file richiede mediamente delle ore... per non parlare della sola estrazione dei files dai tape. Esistono utility native che fanno quello che fa FinalTap ma oltre ad essere tenute gelosamente dai gruppi "elite" non sempre funzionano, e bisogna comunque fare tutto a mano, salvando la memoria su disco e compiendo una lunga e tediosa serie di operazioni manuali.


Note
Questo articolo e' stato rilasciato il 13 Marzo 2004.
Revisionato e pubblicato su Ready64 in data 4 Agosto 2007.

| | Share
Commenti
Commenta gioco Ci sono 0 commenti per questo articolo. Registrati se vuoi lasciarne uno.
Commodore 64
Utenti Online
Ciao, ospite!
(Login | Registrati)

user.png57 utenti online:
(1 registrati, 56 ospiti, 0 anonimi)
flowers
user_red.png 1 Utente in chat
Cerca un gioco
Random Game
Ultimo Commento
Clicca per leggere tutti i commenti
Pitfall II: Lost Caverns
"Intanto bisogna fare un po' di chiarezza. Pitfall I e II nascono entrambi su Atari VCS2600, una console NOTEVOLMENTE inferiore al C64 in termini di risorse hardware. Il programmatore, David Crane, ex dipendente Atari e fondatore dell'Activision, addirittura, utilizzò dei trucchi speciali per riuscire a far stare tutto il secondo capitolo nella cartuccia su Atari. David Crane è un'autentica superstar degli anni '80, dato che successivamente programmò capolavori quali Decathlon (lo sfascia joystick rivale di Summer Games), Ghostbusters e Little Computer People (il papà di The Sims). Per inciso, la saga di Pitfall è stata propedeutica per l'arrivo dei giochi platform come Super Mario e gli elementi ci sono tutti, sebbene Pitfall I e II siano molto più ampi rispetto ai classici platform. La mappa di Pitfall II è enorme, la musica cambia dinamicamente a seconda di quanto succede nel gioco, praticamente non si muore mai ma si torna indieto al checkpoint più vicino (in pratica è un sistema per azzerare la frustrazione tipica dei giochi superdifficili degli anni '80), la giocabilità è molto elevata (più giochi più diventi capace, un po' come capita in H.E.R.O., platform contemporaneo di Pitfall II sempre dell'Activision) e la grafica, tutto sommato, deriva pur sempre da una conversione Atari VCS. Pitfall II è un caposaldo, uno di quei giochi che, rivisti anche a distanza di 30 anni, produrrà sempre divertimento (un po' come Bruce Lee, H.E.R.O. e pochi altri) e va sicuramente annoverato fra quegli evergreen che nessun fan del C64 potrà mai dimenticare. PS: La conversione in sala giochi in realtà era semplicemente un adattamento che ne richiamava la modalità di gioco e la colonna sonora, ma per il resto escludendo nome, musica e stile di gioco era un titolo quasi completamente diverso (personalmente preferisco di gran lunga il gioco da casa). "
- Scritto da ecstaticax
Ult. Commento Art.
Intervista a Danilo Toma
"Che nostalgia...i giorni passati a studiare(sic!) il disassemblato commentato(!) delle famigerate routine grafiche...bei ricordi. Da qualche parte, ingiallito dal tempo, ho ancora quella fantastica monografia sul L.M. (e ricordo pure l'errata ..."
- Scritto da jkt124