Categoria: Interviste
Roberto Preatoni ha iniziato a collaborare nel 1983 come Freelance per l'editore Logica 2000 di Milano.
La sua attività consisteva nel modificare il gioco originale e girarlo all'editore per la riproduzione e distribuzione.
Notoriamente infatti, i titoli immessi sul mercato dall'editore milanese, erano in realtà giochi realizzati all'estero e privati di alcuni tratti distintivi (titolo, crediti, eccetera). Questa pratica, estremamente diffusa all'epoca (anche tra altri editori) ha influenzato in maniera prominente la storia italiana del Commodore 64 e di conseguenza anche un'intera generazione di videogiocatori.
Con questa intervista a Roberto Preatoni cercheremo di capire e conoscere meglio quali erano i retroscena relativi a questo fenomeno.
Arrugginito è un eufemismo. È semplicemente marcio.
Qual'era il tuo "nome di battaglia" all'epoca? (io ricordo il famoso "roby one kenobi", sei tu?)
Nel 1989, quando mi portai il C64 al servizio militare. Non potendolo far funzionare con la corrente (il maresciallo mi disse che mi avrebbero punito per "furto d'uso") lo facevo funzionare con una batteria esterna, che avevo messo nell' armadietto. Mi rubarono tutto e io smisi per quello.
Puoi svelarci qualche dettaglio in più sulle modalità con cui avvenne il tuo "reclutamento"?
Un ragazzo che aveva il padre che lavorava per la CBS (Coleco, ricordate?) pur potendo avere tutto il materiale Coleco gratis a casa, sorprendentemente (o no?) era un fan sfegatato del C64. A tal punto che aveva scritto una specie di framework per le avventure testuali e stava cercando di piazzare i suoi prodotti alla Logica 2000. Fu lui a metterci in contatto.
Ci fornivano o ci procuravamo gli originali, quasi sempre americani (Activision rulez). Il gioco era bypassare le routine di protezione, eliminare tutte le forme di copyright e sostituirle con il nome della casa editrice. Eravamo in due, io ed un mio amico (Marco, dal quale ho imparato tutto ciò che sapevo all' epoca). Cominciammo con un VIC 20 per poi passare al C64. Era più che altro un lavoro che implicava l'utilizzo di cassette esterne contenenti un disassemblatore (Hesmon se la memoria non mi tradisce), qualche switch per il warm reset, e una buona dose di faccia da schiaffi quando dovevi firmare il foglio che ti presentavano alla casa editrice per assicurarsi che il software da te craccato fosse "originale" (anche se in realtà lo sapevano benissimo che fosse craccato).
Si lavorava a casa del mio amico, lui aveva più hardware di me.
Quindi se ho ben capito dovevi dichiarare che il software l'avevi realizzato tu. Se così fosse, era un evidente modo per scaricare eventuali ripercussioni legali. Esisteva all'epoca la responsabilità oggettiva dell'editore? In che maniera la legislazione vigente all'epoca tutelava il software?
La legislazione non poteva tutelare con leggi specifiche sul software, ma ricordiamoci che la legge sulla protezione delle opere d'ingegno è sempre esistita (quella che all'epoca tutelava i libri, per esempio) quindi anche se non c'era un codicillo specifico per inchiodare la pirateria informatica si era sempre soggetti all' interpretazione di un eventuale giudice della legge generica.
È mai capitato di dover rinunciare a qualche elemento di un gioco (musica o altro) per fare in mondo che una compilation stesse perfettamente sul lato di una cassetta?
Uhm... a dire il vero non mi è mai capitato, anche perché la compilation la creava la casa editrice, quindi non mi sono mai posto il problema.
Nel caso di giochi multiload ti è mai capitato di dover presentare ogni caricamento come un gioco a sé stante?
Chi sceglieva i nuovi nomi da mettere ai giochi?
Per molte persone oggi sono più famosi i videogiochi con il nome italiano invece dei loro rispettivi originali. Quale riflessione ti suscita questo fatto?
Siamo abituati al concetto di cracker che lavora nell'ombra e diffonde i suoi crack in maniera clandestina e in un circolo ristretto. Viceversa in Italia i "pirati" agivano alla luce del sole ed erano dotati di mezzi di distribuzione che sono appannaggio delle grandi catene distributive. Come giudichi quest'anomalia?
La giudico facendo la considerazione che tale anomalia rappresenta purtroppo la normalità di tutti gli aspetti italiani...
Non pensi che una localizzazione privata dei riferimenti all'opera originale possa avere creato disinformazione, un po' come leggere un libro senza sapere chi l'ha scritto?
Sei mai stato testimone o ti è giunta voce di dispute legali per pirateria?
All'epoca no, ma ora come consulente informatico è materia di tutti i giorni.
Hai fatto riferimento al tuo amico, solo due persone si sobbarcavano l'intera mole di uscite della casa editrice?
No, c'era un gruppo di una decina di freelance. Tutti molto, molto bravi, probabilmente il più scarso ero io.
Sei ancora in contatto con il tuo collega, ti capita di rivangare i vecchi tempi?
Ah certo. Solo che però ora i ruoli si sono invertiti. È lui a chiedere a me :-)
Ad oggi, hai conservato qualche interesse per il C64, per esempio visitando i siti ad esso dedicati o utilizzando gli emulatori?
Conservi ancora il tuo Commodore 64, i giochi e la tua attrezzatura che usavi all'epoca?
Hai detto che hai l'emulatore sul cellulare, parliamo un po' dei tuoi gusti personali: quali sono i tuoi giochi e programmatori preferiti?
E nell'ambito della cracking scene italiana?
Oltre ai crack hai realizzato qualche altro progetto per Commodore 64?
Una dichiarazione libera per concludere l'intervista?
- fare risiedere un programma di 3k in soli 1,5 k (e via di overloading);
- fare eseguire degli sprite a una macchina (vic 20) che non poteva gestirli nativamente;
- far eseguire al processore lavori di multi-tasking quando nessuno aveva previsto che si potesse fare (e via di interrupt requests).
Insomma, mi sembra di vedere mia nonna che, arrivando dalla guerra mi diceva che "non si deve buttare via nulla". Oggi sprechiamo gigaherz e gigabyte, è per quello che rispetto molto di più il coder di un Ghostbusters (C64) piuttosto che quello di un Quake 3.
Aggiornamento del 21 Aprile 2020
A distanza di ben 14 anni dalla pubblicazione di quest'intervista, apportiamo un aggiornamento interessante e dalle spiccate note didattiche. Roberto ci ha fornito una versione digitalizzata della tesina che elaborò per l'esame di maturità nel corso dell'anno scolastico 1985 - 1986.
L'elaborato ha titolo:
"DIGITALIZZAZIONE, MEMORIZZAZIONE, ELABORAZIONE, RIPRODUZIONE DI SEGNALI SONORI CON L'AUSILIO DI ELABORATORI ELETTRONICI CON ESEMPIO PRATICO DI RIPRODUZIONE SERVIZIO ORA ESATTA SIP BASATO SU ARCHITETTURA CBM COMMODORE 64"
- Qui è possibile scarica il file zip contenente il documento in versione pdf -
Si tratta di un progetto per la realizzazione di un campionatore/riproduttore vocale elettronico e digitale basato sul Commodore 64, parallelamente a un'applicazione scritta in BASIC e Assembly, per riprodurre il servizio telefonico "Ora esatta" offerto dalla società telefonica SIP (ora Telecom).
L'applicazione software scritta in BASIC riproduce l'ora esatta partendo dal vocale campionato attraverso l'apposito programma in Assembly. Una volta campionato il suono/vocale, è possibile utilizzarlo per costruire qualsiasi servizio o inserirlo in giochi come "Ghostbusters".
Trattandosi di una tesi che doveva soddisfare alcuni specifici requisiti di studi di elettronica industriale, microprocessori e informatica, la parte relativa alla riproduzione vocale è stata sviluppata con un hardware in grado di far fluire il bitstream del vocale digitalizzato attraverso la user port e pilotando un amplificatore operazionale con funzione di convertitore digitale/analogico collegato a un altoparlante.
Roberto lancia la sfida per chi volesse cimentarsi, affermando che è possibile apportare una modifica al progetto, dirottando il bitstream del vocale digitalizzato andando a pilotare direttamente l'onda quadra del SID, uscendo quindi direttamente sull'altoparlante della televisione. In questo modo il vocale campionato può essere integrato anche nei videogames o in applicazioni stand alone. Osservando attentamente il sorgente del programma in Assembly che riproduce il bitstream, la modifica è veramente irrisoria... sempre a detta di Roberto.
La soluzione non la vogliamo svelare per intero, ma un piccolo aiuto ve lo forniamo: occorre modificare il blocco di istruzioni del programma riproduttore scritto in Assembly, dalla riga 15 alla 20, che ora si presenta così:
ROL 142
ROL A
STA 56577 (questa è la user port del C64)
INC 141
BEQ INCREMENTA
Al posto di scaricare l'accumulatore nella locazione della user port, si può utilizzare come trigger per far generare un'onda sonora al SID.
Ovviamente per pilotare il SID al posto dell'amplificatore audio come indicato nel progetto è necessario utilizzare ogni singolo bit del bitstream audio digitale per far generare al SID un singolo impulso d'onda (potete sbizzarrirvi provando a pilotare onde quadre, sinusoidali o triangolari).
Inoltre occorre fare attenzione ai valori delle variabili utilizzate per le routine di delay. Esse governano la velocità con la quale la memoria viene riempita o scaricata di dati.
In pratica meno delay e più fedeltà avrete nel campionamento digitale ma meno secondi di parlato potrà essere contenuto in memoria. Al contrario, più delay significa che la memoria viene riempita con più parlato ma di minore fedeltà. Il trucco utilizzato nel programma di Roberto è di utilizzare i singoli bit che arrivano attraverso la user port dal circuito campionatore come se fossero pallottole infilate una a una dentro il tamburo di un revolver a 8 colpi (il byte). Man mano che il tamburo gira, la pallottola che deve essere sparata (ovvero il bit che deve essere campionato o riprodotto, ovvero il LSB - Least Significant Bit) viene di volta in volta inserita nella canna (la locazione 56577 della user port) e viene sparato (scritto o letto) attraverso essa azionando il cane (il registro Accumulatore).
Una volta fatto ruotare il tamburo del revolver per 8 volte, si passa a riempire (o svuotare a seconda che si scriva o si legga il dato) il tamburo con nuove cartucce (andando al byte di memoria successivo).
Speriamo che l'analogia abbia reso chiaro il concetto alla base del funzionamento.
Questo accorgimento permette di utilizzare l'intera memoria del C64 (tranne quella che contiene i programmi, ovviamente) moltiplicando di fatto le locazioni disponibili per 8.
Se proprio non sapete come reperire la componentistica per la costruzione del convertitore analogico/digitale per campionare il suono... ebbene probabilmente lo avete già! Fa parte della circuiteria del registratore Datassette 1530 (o compatibili), basta solo applicare il segnale proveniente dal vocale al posto della testina del registratore, e all'interno c'è già tutta la circuiteria che trasforma l'onda analogica in onda digitale. Includiamo un'immagine dello schema elettronico del datassette che realizza questa funzione, con la descrizione su come utilizzarlo.
Per evitare di dover smontare completamente il datassette, è possibile anadare a leggere i dati direttamente dallo spinotto del tape utilizzando la cassette port e andando a leggere il dato sul pin d-4. Ovviamente sarà necessario modificare il programma adeguatamente. Tuttavia, sarebbe preferibile mantenere il progetto originale che vede lo scambio dati sulla user port così sarà necessario stravolgere troppo il programma in linguaggio macchina.
Buon divertimento!