Inside Ps1 Parte 3: il sistema grafico

Un’analisi abbastanza completa del sistema grafico della Ps1 non è di facilissima comprensione, in virtù del fatto che essa si suddivide in 4 aree primarie con competenze specifiche. Mi spiego meglio: il sistema si compone di quattro “meccanismi” che operano coordinatamente per la rappresentazione di elementi 2d/3d e la riproduzione di filmati. Il primo “meccanismo” è rappresentato dai co-processori di controllo che abbiamo introdotto nella scorsa parte dell’analisi. Il loro compito è in realtà ridotto  ma, nello specifico, è significativo perchè coordinano il passaggio dei dati elaborati dalla Gpu (che ora vedremo) alla CPU e viceversa, passaggio necessario per alcune operazioni di sincronizzazione video.

Il secondo pezzo del sistema, molto più importante, risiede anch’esso nella CPU e corrisponde al nome di Geometry Transformation Engine. Questo sistema, che potremmo definire un modulo operativo insito alla Cpu stessa, è il cuore di tutti i calcoli relativi alla grafica 3d della Ps1. Il GTE può operare calcoli vettoriali e matriciali, rotazioni, prospettive, equazioni per la gestione dei colori. E’ progettata per essere molto più veloce della Cpu in queste operazioni. Non è realmente indirizzata dalla CPU in memoria tramite un indirizzo, per richiamarla in fase di programmazione è necessario usare istruzioni speciali, uniche solo e soltanto del GTE. Come una vera e propria “singola” CPU, il GTE ha 32 registri di sistema sui quali operare, suddivisi in registri per i dati di elaborazione e registri di controllo. Dovete sapere che la maggior parte dei calcoli su elementi tridimensionali viene fatta (sia in C che in linguaggio Assembly specifico per la Cpu) utilizzando calcoli di natura geometrica/matriciale, in virtù della relativa semplicità di programmazione in questa modalità e con l’enorme vantaggio di poter operare singolarmente su elementi delle matrici e sui vettori per variare facilmente le caratteristiche di ciò che andrà a video.

Un’analisi completa dei comandi del GTE risulterebbe noiosa ed eccessivamente tecnica, quindi passiamo al terzo pezzo del puzzle, il MDEC (Motion DeCoder Engine) un chip a parte demandato alla decompressione di file video letti dal CD. I formati video di base della Ps1 sono molteplici, molti di più dei soliti XA e Mpeg-1 che si crede propri del sistema Sony. Il chip è capace di decomprimere video a grande velocità, e per gestire lo stream (flusso) di dati continuo che giunge alla Cpu entrano in gioco i co-processori di cui abbiamo parlato all’inizio, il cui compito diventa allora quello di schedulare ossia mettere in ordine di esecuzione i frammenti di byte video decodificati per poter essere letti in serie. E’ compatibile anche il formato video H.261, ormai certamente desueto ma che rappresenta la base per tutti i successivi formati odierni, MPEG in primis.

L’ultimo e fondamentale elemento del complesso grafico è la vera GPU, una piccola perla di chip datata 1995. E’ principalmente demandata all’elaborazione della grafica bidimensionale, ma si occupa anche di coordinare l’output a video dei risultati del GTE. E’ capace di gestire fino a 16.7 milioni di colori, una risoluzione massima di 640×480, elabora un massimo di 4000 8×8 pixel con dimensionamento e rotazione individuali. Può gestire più sfondi contemporaneamente ed effetti di parallasse/scaling. Gestisce luci, ombre e texture risultati dai calcoli del GTE e dei coprocessori. Ha 1 Mb di Video Ram. Sebbene possa sostenere al massimo una risoluzione molto più bassa del concorrente Sega Saturn, la Gpu della Ps è capace di un notevole potenziale nel campo dell’elaborazione tridimensionale, con risultati mai reggiunti dalla sua avversaria, specie nella modellazione tridimensionale e nella raffinata gestione degli effetti lighting. Pensate a Vagrant Story e alla straordinaria capacità di illuminazione degli elementi a schermo, impressionante considerato tutto il sistema, non certo complesso nè rivoluzionario. Dove perdeva tutto questo sistema grafico era l’elaborazione 2d, inferiore al Saturn e capace di una limita nonchè eccessivamente complessa gestione di sprite e parallassi. E’ altresì vero che le intenzioni di Sony per la console erano chiare: stupire con la nuova era del 3d e quello era il riferimento. Il 2d fu una conseguenza, al contrario del Saturn dove il 2d raffinato fu la base di partenza (anche a livello di programmazione) della console a discapito del reparto 3d.

Ci si rivede per la prossima parte di Inside Ps1, stay tuned!!

Annunci

Inside Ps1 Parte 2: la Cpu R3000

Proseguiamo la nostra analisi dell’insieme hardware della nostra amata scatoletta grigia cercando di spiegare dettagliatamente (ed al tempo stesso il più semplicemente possibile) le caratteristiche salienti del suo “cuore”, ossia la cpu R3000. Codesto circuito integrato è stato prodotto dalla MIPS Computer Systems nel lontanto’88 ed stato proposto in molteplici forme e caratteristiche sui più svariati sistemi, compresi alcuni satelliti in orbita, fino almeno al ’98. E’ basato sull’architettura MIPS, elaborata già nel 1983 se non vado errato. Rispetto alle architetture classiche di tipo x86 o PowerPC essa si basa su un concetto base abbastanza semplice ma geniale: tutte le istruzioni da eseguire devono essere eseguite in un solo ciclo di clock (“elaborazione”) della Cpu (detto in termini semplici per i non addetti ai lavori. Ora, ciò porta il grande vantaggio in termini di prestazioni (velocità) ma anche lo svantaggio di dover operare su un set di istruzioni più semplici e meno flessibile rispetto ad altre architetture. Ovviamente, negli anni questa filosofia di lavoro si è evoluta e ha permesso di avere un set di istruzioni ridotto (RISC è la sigla) di ottima flessibilità non sacrificando troppo le prestazioni in temini di velocità e capacità di calcolo. Qui si dovrebbe parlare anche della capacità delle cpu MIPS di utilizzare la potentissima tecnica di pipeling a stalli ma tralascio questi dettagli tecnici, se volete approfondire Wikipedia è ben documentata (soprattutto in inglese).

La nostra Ps monta una versione custom della R3000, appositamente studiata per la console Sony. La frequenza di lavoro è stata portata a 33.8688 Mhz. Contiene 115000 transistor. Il set di istruzioni (ovviamente RISC) è a 32 bit. Può computare fino a 30 milioni di operazioni al secondo. Ha una memoria cache per le istruzioni di ben 4 KB (organizzata in linee da 16 bit), una cache per i dati di 1 KB (organizzata in linee da 1 byte, cioè 8 bit) ed una velocità di trasferimento sul bus dati e sul bus istruzioni di 132 MB/sec. All’interno è composta da un’ALU (Unità aritmetico logica, per i calcoli matematici) abbastanza avanzata ed è pensata per memorizzare dati (appunto in memoria dati) in modalità little-endian. Il nome simpatico di little endian non deve far pensare a qualche pittoresco nativo americano, quanto piuttosto ad un particolare formato di codifica dei dati di dimensione maggiore di 1 byte. In effetti è una modalità classica del mondo Intel (soprattutto negli anni ’90). A supportare la cpu ci sono 2 co-processori di supporto, più il geometry engine, che tratteremo nelle successive puntate dell’articolo.

Andando ad analizzare nel dettaglio l’architettura a 32 bit notiamo che i registri per la cpu sono 32 da R0 a R31 (classica architettura MIPS/RISC) e lo stack pointer (ossia la struttura dati in memoria atta a memorizzare istruzioni e byte, detto molto semplicemente) è gestito dal registro R29, cosa che lo differenzia abbastanza rispetto ad altri modelli sia RISC sia della serie R3000. Difatti, un bel numero di istruzioni è particolare propria della serie 3000 e propria di questo modello. La Sony ha voluto una cpu non estremamente potente ma abbastanza funzionale nella programmazione e customizzata ai propri scopi. Da considerare è un’ulteriore caratteristica: la presenza dei co-processori aggiunge un bel gruppetto di istruzioni in più che normalemente non ci si aspetterebbe davanti ad una cpu classe R pre serie 4000.

Per farvi un semplice esempio (dedicato ai meno esperti) di un’istruzione assembly RISC, supponiamo di voler caricare in un registro (ad esempio R20) un valore numerico, magari esadecimale come 0x60. Useremo l’istruzione LUI   R20, 0x60 , dove LUI sta per Load Upper Immediate (caricare il dato direttamente). Tutto banale, ma immaginate una serie di 30000 istruzioni per creare un semplice giochino tipo Asteroids. La Sony decise, come ho già accennato nella puntata precedente, di utilizzare un ambiente di sviluppo in C, molto più semplice da gestire. Dovete sapere che il mondo della programmazione dei microprocessori/microcontrollori ha 2 grandi scuole di pensiero: chi ama programmare in Assembly (linguaggio macchina) e chi ama programmare in C. Il primo ha il vantaggio di essere potentissimo, perchè come abbiamo visto dall’esempio del registro possiamo controllare direttamente ogni componente fisico/logico della Cpu nei minimi particolari, ma dobbiamo conoscere alla perfezione un oceano di istruzioni e operandi, cosa complessa davvero. Programmare in C rende tutto più semplice ma non permette spesso un controllo diretto della macchina a livello dei singoli bit (bisogna usare strategie diverse, diciamo). Insomma, la R3000 è un componente senza dubbio di qualità, che però alcune volte va in stallo per colpa dello scarso firmware nativo della Ps. Ricordo che capitavano spesso errori di sincronizzazione tra la Cpu e le periferiche esterne come la Memory Card, e ciò è dovuto alla non perfetta programmazione da parte di Sony, ma di questi casi rari (ma veri, io ne sono stato vittima :)) ne parleremo un’altra volta. Completo enunciano l’impresa di un gruppetto di folli facente parte della community di Assembler Games che ha portato la Cpu a 66 Mhz e passa cambiando il quarzo di oscillazione (clock) collegato all’intrgrato. Ottimo lavoro, una Ps overcloccata… Ma che senso ha? Suppongo l’integrato sarà già passato a miglior vita bruciando per la troppa potenza da dissipare. Oppure ogni gioco che provano va ad 80 FPS (fuori scala) ed è ingestibile. Bravi… mah.

Spero di aver esposto nella maniera più chiara e completa possibile l’argomento, tenendo conto che non potevo scrivere un trattato di architettura delle CPU 😀 vi aspetto per la prossima parte dedicata alla Gpu della Ps1, se avete dubbi chiedete e vi sarà risposto 🙂

Inside the Master Sytem: Intro

Ispirato dal buon Sergio, mi sono messo anche io ad analizzare e a proporre a voi la board del famosissimo Master System model 1 versione PAL, console che posseggo e che tengo con grande cura nella mia collezione. A differenza del mio collega ispiratore, non sono un grande esperto di elettronica, ma la mia recensione sarà basata su grandi ricerche fatte su internet, filtrando informazioni utili ed interessanti al fine di farmi/farvi conoscere meglio la composizione di questa magnifica console spesso sottovalutata per diverse ragioni che avrò modo di spiegare più avanti. Per questa ragione se notate delle incongruenze o degli errori microscopici o macroscopici fatemi sapere che correggo prima di essere giustamente frustato per la mia ignoranza!

Detto questo passiamo subito a dare una prima occhiata alla board, descrivendo successivamente alcuni componenti:

La seguente board è la versione VA/PAL 837 -6097 come si può notare dal numero scritto a macchina con inchiostro nero. Da ciò che so è la seconda board PAL uscita per l’ SMS.

Il processore, che possiamo notare affianco al piccolo contenitore metallico sulla macchina (usato come raffreddamento) è possibile vedere il processore “Zilog Z0840004PSC” a 8-16 bit. Processore prodotto dal 1976  apparso su una moltitudine di console e computer degli anni 70-80. Poco sotto troviamo il chip grafico “Sega 315-5124” derivato  Texas Instruments TMS9918A, molto potente di cui parleremo in seguito. Dopo questa breve introduzione anche io propongo una scaletta di tutto ciò che approfondirò riguardo l’hardware dell’SMS in questi giorni… sarà una cosa abbastanza lunga ma spero possa soddisfarvi (NB: il mio studio e la mia ricerca sull’argomento sarà molto più semplicistica rispetto a quella proposta da Sergio e siete liberi, previo avviso, di modificarla):

– La CPU: Zilog Z0840004PSC; caratteristiche generali e prestazioni

– Il VDP: Sega 315-5124; caratteristiche generali e prestazioni

– La RAM e la VRAM: NEC D4168C-20/15; caratteristiche generali e prestazioni

– Sonoro (PSG) ed (FM):  Texas Instruments SN76489 / Yamaha YM2413; caratteristiche generali e prestazioni

– Le periferiche I/O; caratteristiche generali e prestazioni

Questa è l’impresa in cui tenterò di cimentarmi sperando di essere il più corretto e chiaro possibile! a presto!

Inside PS1 Parte 1: Introduzione

Un’analisi approfondita e coerente del sistema Sony a 32 bit è abbastanza complessa. La storia delle vicessitudini con Nintendo per lo sviluppo del lettore CD, delle numerose versioni della sua scheda madre e delle progressive semplificazioni degli hardware la lascio a Wikipedia, proprio qui. La storia esula dal mio compito di analisi rigorosa del macchina nel qui presente articolo; l’unica precisazione che faccio è che la mia analisi si basa sul modello SCPH-7002 (che possedevo prima che purtroppo mi abbandonasse per guasto costringendomi all’inizio del 2001 all’acquisto di una PsOne). Questo significa la presenza della porta parallela ed una parte di software del S.O. nella Rom che lo gestisce. Molto importante per applicazioni di testing e programmazione, come vedremo. Tutto ciò che ho imparato è frutto della mia passione per l’elettronica (ed un pò per l’informatica) nonchè la frequentazione assidua di gruppo amatoriali di studio e hacking dei sistemi hardware più disparati. Ciò non significa che vi spiegherò come fare una modifica o altre cavolate, scordatevelo e compratevi una Ps1 usata in condizioni decenti invece 🙂

Uno sguardo alla scheda madre della Ps1 è il primo passo di questo tributo alla tecnica “sonara” (nota che la foto sotto è di una SCPH-5001 ma non vi sono differenze hardware con la 7002, solo l’introduzione nella serie 700x del Sound Scope).


Motherboard semplice ed ordinata, molto “semplice” da realizzare rispetto a quella del Saturn ed ovviamente più economica. In alto a sinistra la porta parallela. Il chip con la grossa scritta Sony in grassetto in basso a sinistra è la cpu, la R3000 che andremo ad analizzare con calma nella seconda parte di questa guida (che pubblicherò a puntate 🙂 ). L’integrato immediatamente sopra è la Gpu e preciso fin da adesso che non è la sola a gestire il comparto grafico, anzi inaspettamente ha meno compiti di quanto si creda. La Spu (Sound Process Unit, per i meno avvezzi) è qualla poco spostata a destra dal centro della console con la sigla CXD29… . Si può notare un gran numero di compomenti Nec di supporto ai Bus nonchè un chip Motorola ed un chip Mitsubishi (memoria RAM CMOS statica).

Per chi avesse mai studiato Calcolatori all’univerisità, la sigla MIPS non è certo nuova. Un’architettura per la CPU molto efficiente valorizzata dal set di istruzioni RISC, davvero alla portata di tutti (almeno nelle istruzioni base): è lo stesso usato per i microcontrollori AVR stile Arduino. Ma una cosa sono programmi di lettura porte/registri, ben altro è la creazione di un videogame. Naturalemente la Sony pensò bene di non suicidarsi realizzando un ambiente di sviluppo in Assembly stile Saturn, ma di fornire un accessibile IDE in C-like customizzato da complesse librerie per la gestione di hw/sw. Parte di queste librerie ed i documenti a loro collegati si trovano ancora in rete, cercando con cura. Programmare la Ps1 significava connetterla al PC tramite porta seriale o quella parallela (archeologia informatica), sfruttando una scheda di espansione PCI studiata per interfacciare i 2 sistemi. Oggi numerosi gruppi di sviluppatori indipendenti hanno realizzato compilatori e librerie “rozzi” ma open-source per l’interconnessione delle 2 macchine senza hw esterno. Comunque, se mai vorrete provare questa strana “ebbrezza” digitale di far comunicare la scatoletta grigia con un computer, dimenticatevi SO che siano superiori a Win 98 Seconda Edizione. Non chiediamo troppo, per favore 🙂 …

La mia guida si dividerà in queste parti principali:

  • Analisi della CPU R3000: struttura, istruzioni base e prestazioni
  • Studio della GPU ed interazione con il Geometry Engine
  • Memorie (RAM, ROM, ecc..) e DMA
  • Coprocessori di controllo
  • SPU e CD-Rom più analisi dei metodi di protezione adottati da Sony
  • Memory Card, Porta Seriale e Parallela

Nelle prossime settimane cercherò di iniziare l’analisi della CPU. STAY TUNED 🙂