Nei post precedenti di questa serie abbiamo smontato il C64 pezzo per pezzo. Registri, memoria, istruzioni, controllo di flusso e i chip hardware. Ora rimettiamo tutto insieme in qualcosa che funziona.
Il progetto è un mini piano a cinque note. I tasti Z X C V B suonano Do Re Mi Fa Sol. Ogni nota cambia il colore del bordo dello schermo, riproduce un suono nel SID e visualizza la lettera della nota al centro dello schermo. Abbastanza semplice da stare in un unico post, abbastanza complesso da usare tutti e tre i chip insieme.
Nei post precedenti di questa serie abbiamo costruito il modello completo. Registri, memoria, istruzioni, decisioni e cicli. Sai già come un programma si muove attraverso la memoria e come il processore esegue ogni byte che incontra. Quello che manca è la parte più sorprendente della storia del C64, e probabilmente l’idea più elegante dell’intera serie.
Scrivere in memoria era attivare hardware
Nel post sulla mappa di memoria abbiamo visto che certe regioni non erano RAM normale. Il range da $D000 a $DFFF apparteneva ai chip hardware. Il VIC-II, il SID e il CIA. Ma cosa significa in pratica lo si capisce solo quando si vede il codice.
Nel post precedente abbiamo visto come il processore sposta dati e fa aritmetica. Ma un programma che esegue solo istruzioni in linea retta non fa molto di utile. A un certo punto deve prendere una decisione. Andare in un modo o nell’altro, a seconda di un risultato. Ha bisogno di cicli, condizionali, della capacità di comportarsi diversamente a seconda dello stato delle cose.
Nell’assembly del 6510, tutto questo si costruisce su un unico meccanismo. I flag.
Nel post precedente abbiamo costruito la mappa. Sappiamo dove vivono i dati, come la memoria è organizzata in indirizzi e perché certe regioni valevano più di altre. Ora manca il pezzo centrale. Cosa fa davvero il processore mentre esegue un programma.
Il programma è anche byte
Nel post sul ciclo di esecuzione abbiamo visto che il processore legge un byte, lo interpreta come istruzione, lo esegue e avanza al successivo. Ma non abbiamo mai parlato di come un byte diventa un’istruzione.
Nel post precedente abbiamo visto che il processore ha tre registri di uso generale e un ciclo di esecuzione semplice e ininterrotto. Il problema è che tre registri non sono sufficienti per nessun programma reale. Hai bisogno di un posto dove conservare i dati mentre non li stai usando, conservare il programma stesso, conservare variabili e risultati intermedi. Quel posto è la RAM.
La RAM è un array gigante
Se hai mai usato un array in qualsiasi linguaggio, hai già capito la RAM. La memoria del C64 era esattamente questo:
Nella Parte I abbiamo coperto il panorama: l’epoca, la macchina, il contesto. Ora è il momento di scendere di un livello e capire come funziona davvero il processore. Dove vivono i dati, come vengono lette le istruzioni e cosa accade ogni frazione di secondo mentre un programma è in esecuzione.
Registri: lo spazio di lavoro del processore
Quando scrivi qualcosa come x = 5 + 3 in qualsiasi linguaggio moderno, il processore deve prendere il 5 da qualche parte, prendere il 3 da qualche parte, sommarli e salvare il risultato. Quel “qualche parte” sono i registri.
Quando sono entrato nel settore tecnologico, nella seconda metà degli anni 2010, i linguaggi ad alto livello erano già lo standard. Quando ho studiato Ingegneria Informatica, persino i sistemi embedded si scrivevano in C++, e quello veniva considerato il livello più basso. Nel mondo del software e dei giochi, l’astrazione andava ancora più in profondità. Java dominava l’industria, e Unity era nel pieno del processo di democratizzare lo sviluppo di giochi al punto che chiunque con un weekend libero poteva pubblicare qualcosa di giocabile.
