di  -  mercoledì 6 aprile 2011

Pubblichiamo un contributo di Antonio Barba, sviluppatore software specializzato nel ramo videogiochi.

Tutti noi conosciamo, almeno di fama, il Nintendo DS. Lanciato verso la fine del 2004 in Giappone e Nord America (marzo 2005 in Europa), il Nintendo DS è, ad oggi, la console portatile più venduta al mondo – 144 milioni di unità a Dicembre 2010.

Per la sua progettazione, Nintendo riprende la piattaforma hardware del precendente Nintendo GameBoy Advance, il form factor dei Game&Watch anni ’80 ed aggiunge alcune importanti innovazioni, come il touchscreen, il microfono, la connessione WiFi e l’accelerazione hardware 3D.

Nitro Processor
Tutte le funzioni principali del Nintendo DS sono gestite da un System on Chip custom, chiamato Nitro Processor.
Al suo interno sono presenti ben 2 CPU con architettura di tipo ARM: un core ARM946E-S, che funge da CPU principale (Main processor) e opera alla frequenza di 67,028 MHz ed un secondo core (subprocessor) ARM7TDMI, che lavora a 33,514 MHz.

Le funzioni assegnate alle due CPU sono ben distinte e pertanto possiamo parlare di sistema AMP (Asymmetric Multi Processor).
 Nel SoC trova inoltre posto il settore grafico, costituito da 2 coprocessori quasi gemelli, chiamati rispettivamente 2D Graphics Engine A e B, ed il coprocessore denominato 3D Graphics Engine che opera in maniera particolare, appoggiandosi in parte alle funzioni del 2D Graphics Engine A.

Troviamo poi due coprocessori matematici, connessi all’ARM9 Bus, quindi utilizzabili solamente dal Main processor. Questi coprocessori matematici implementano le funzioni di divisione e di radice quadrata per numeri interi a 16 e 32 bit. Non vi è alcun supporto hardware per i calcoli in floating point, cosa abbastanza comune sulle console di vecchio tipo.

Completano il quadro un coprocessore sonoro dotato di mixer, alcuni Timer, vari banchi di memoria Ram ed un paio di controller DMA, uno per ciascun processore, dotati di 4 canali programmabili ciascuno.

Struttura della memoria

Nel DS la struttura della memoria è sorprendentemente complessa. Il Nitro Processor incorpora al suo interno 12KB di cache L1 per il Main processor, suddivisi in 8KB per le istruzioni e 4KB per i dati. A questa cache L1 si affianca un secondo livello di cache, che va gestito “manualmente” dal programmatore, quindi non è trasparente come la L1.

Questa particolare memoria si chiama TCM (Tightly Coupled Memory). Come la cache di primo livello, anche la TCM può essere letta e scritta senza interferire con il bus di sistema. Questo consente, ad esempio, di pianificare dei trasferimenti DMA e nel frattempo lavorare con codice e dati precedentemente caricati su TCM.

In realtà le TCM sono due: 32KB per le istruzioni e 16KB per i dati. Questo ricalca ovviamente il modello Harvard della CPU ARM9. La separazione tra dati e istruzioni consente di effettuare il fetch di una istruzione contemporaneamente ad una operazione di Load/Store dei dati, massimizzando l’efficienza della pipeline a 5 stadi dell’ARM9.

Questo vantaggio si perde ovviamente quando le istruzioni e i dati si trovano sulla Main Ram, che è situata esternamente al Nitro Processor. La Main Ram ammonta a 4 MB, ed è molto più lenta della TCM per vari motivi: è dotata di bus a 16bit anziché 32 bit, opera ad una frequenza di clock di 33,5 Mhz anziché 67, condivide in un unico spazio di indirizzi sia i dati che le istruzioni (conformandosi quindi all’architettura Von Neumann), negando quindi l’accesso parallelo a dati e istruzioni, e inoltre presenta dei tempi di accesso che variano da 2 a 5 cicli di clock, in base a vari fattori che vedremo in seguito.

A causa di questi problemi di accesso alla memoria, quando il Nintendo DS lavora sui dati presenti nei 4MB di Main Ram risulta mediamente più lento del GameBoy Advance. Il trucco per sfruttarne pienamente la potenza risiede in alcune tecniche importantissime, che mostrerò in seguito.

Il subprocessor non possiede né la cache di primo livello, né la TCM. Inoltre non è connesso fisicamente con la Main Ram. L’unica memoria RAM accessibile dall’ARM7 è costituita da un totale di 96 KB di memoria molto veloce, chiamata Working RAM.

La Working RAM è suddivisa a sua volta in 3 banchi, uno da 64 KB ad uso esclusivo dell’ARM7 e 2 banchi da 16KB che possono essere letti/scritti alternativamente dall’ARM7 e dall’ARM9, costituendo di fatto un meccanismo molto veloce di scambio dati tra i due processori. L’assegnazione dei due banchi da 16KB deve essere fatta manualmente dal programmatore, agendo su particolari registri del Nitro Processor.

La dotazione di memoria inoltre comprende 656 KB di memoria video, suddivisa in 4 banchi da 128 KB, 1 banco da 64KB, 1 banco da 32KB e 3 banchi da 16 KB. La gestione della memoria video è uno dei compiti più complessi che deve affrontare il programmatore durante la creazione di un videogame. I singoli banchi di VRAM possono, e devono, essere opportunamente configurati per ospitare immagini bitmap, texture, sprite, palette, ecc…, agendo su speciali registri di configurazione.

A complicare le cose contribuisce il fatto che ogni singolo banco può coprire una o più funzioni, ma non contemporaneamente, e inoltre bisogna decidere quali banchi assegnare al 2D Engine A, quali al 2D Engine B e quali al 3D Engine.
 Il 3D Engine dispone poi di 4 banchi speciali, non mappabili direttamente dalla CPU, che contengono rispettivamente i vertici (72KB x 2) ed i poligoni (52KB x 2) della scena 3D da renderizzare. Ulteriori 4 banchi speciali da 1KB ciascuno sono assegnati ai 2D Engine A e B, e contengono le descrizioni degli sprite OAM (coordinate, attributi, ecc..) e la cosiddetta Standard Palette (per compatibilità con il GameBoy Advance).

Per sfruttare correttamente e proficuamente una console del genere si presuppone, come si evince, una profonda conoscenza dell’hardware e soprattutto dei 3 Graphics Engine e dei modi con cui questi interagiscono con i banchi di memoria.

Sul fronte software è d’obbligo poi sapere che il DS non ospita un vero e proprio Sistema Operativo, ma la libreria Nintendo utilizzata per sviluppare i giochi contiene una serie di utilità, tra cui anche un minimo supporto a thread, mutex e semafori. La gestione del multitasking avviene comunque in manuale, tramite un meccanismo di multitasking cooperativo molto elementare.

Prossimamente parlerò dei coprocessori grafici, mostrando come questi contengano sostanzialmente tutte le funzioni “classiche” dei chip grafici prodotti a partire dai primi sistemi Atari fino al sopravvento dell’hardware 3D-only, basato cioè esclusivamente sull’uso di poligoni.

In particolare parlerò di come sia possibile realizzare complesse scene 2D con 4 background sovrapposti, dotati di parallax scrolling, 128 sprite a schermo, antialiasing e alpha blending, tutti dotati di effetti di rotazione e scala, senza intaccare minimamente la capacità di calcolo della CPU che resta libera al 99% di effettuare altri calcoli.

Parlerò inoltre dei dettagli delle due CPU e della sofisticata struttura a coprocessori del Nitro Processor, che in qualche modo rende il Nintendo DS molto simile sia all’architettura delle gloriose console casalinghe (ad esempio Super Nintendo e Nintendo 64), sia a famosi computer anni ’80-’90 come il Commodore Amiga.

40 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Massimo M
     scrive: 

    Carino coe articolo – pensavo. Mi stava riaccendendo qualcosa nella mia testa .. ma era trppo in profondità per riconoscerlo.
    E’ bastata l’ultima riga per farmi trasalire!

    Aspetto con ansia la prossima puntata!

  • # 2
    Uebmaestro
     scrive: 

    Concordo con Massimo, stessa lampadina :-)

    In particolare i due subprocessor cloccati esattamente alla metà della CPU sospetto possa avere a che fare con l’accesso a cicli alternati al 68000 da parte del copper dell’Amiga (spero di non averla sparata troppo grossa).

    E complimenti anche da parte mia, le dissezioni tecniche sulle architetture hardware in questo blog non sono mai troppo complesse da capire eppure sempre complete!

  • # 3
    Marco
     scrive: 

    “Il subprocessor […] non è connesso fisicamente con la Main Ram.”

    Dallo schema parrebbe di si però…

  • # 4
    Cesare Di Mauro
     scrive: 

    Mi lasciano perplesse certe scelte tecniche (in primis il bus a 16 bit per l’interfacciamento con la memoria).

    Comunque in un sistema di questo tipo non mi affiderei alle librerie per gestire task & thread: preferirei avere l’assoluto controllo di tutto (Amiga docet).

    Una domanda: i 128 sprite contemporaneamente si riferisco alla totalità, o c’è un massimo per riga di raster (come l’SNES, che ne ha 32 max, se non ricordo male).

  • # 5
    Antonio Barba (TheKaneB)
     scrive: 

    @Marco: per questioni di NDA non potevo pubblicare la mappa reale del Nitro Programming Manual. Accontentiamoci di questa mappa di pubblico dominio, creata da sviluppatori homebrew e che, purtroppo, non è perfetta :-)

    Confermo quanto detto nell’articolo riguardo al fatto che l’ARM7 (Subprocessor) non ha accesso diretto alla Main Ram, prendete lo schema come valido “in linea di massima”.

  • # 6
    Cesare Di Mauro
     scrive: 

    @Uebmaestro: il subprocessor è uno solo, e ha una frequenza dimezzata rispetto alla CPU.

    Poi non credo che sia possibile accedere a una locazione di memoria in un solo ciclo di clock: ce ne vorranno di più, perché quella non sarà memoria SRAM, ma DRAM.

    @Marco: vero.

  • # 7
    Antonio Barba (TheKaneB)
     scrive: 

    @Cesare: sono 128 per riga di raster :-) potenzialmente puoi riprogrammare l’OAM buffer durante l’Horizontal Blank e avere 128 sprite nella metà superiore e altri 128 nella metà inferiore o anche di più… ma con uno schermo da 256×192 dubito che ciò sia utile :-)

  • # 8
    Cesare Di Mauro
     scrive: 

    OK. Allora aggiungo un’altra domanda sull’argomento: gli sprite sono 128 totali, o di più?

    Visto quello che hai detto sul subprocessor, mi chiedo come faccia a girare un gioco GBA nel DS, visto che in questi casi è lui a fungere da CPU (se non ricordo male). La lentezza sarebbe notevole, visto che il clock viene ulteriormente dimezzato (16,6Mhz anziché 33) per rispecchiare esattamente il funzionamento del GBA.

  • # 9
    Antonio Barba (TheKaneB)
     scrive: 

    @Cesare e @Uebmaestro:
    La Main Ram è di tipo dinamico e i cicli di accesso sono 2 per il setup + 2 per ogni coppia di byte (bus da 16bit) in accesso sequenziale. L’accesso casuale invece va da 3 a 5 cicli per lettura, in base all’indirizzo (se cade dentro la stessa colonna dell’accesso precedente oppure no).

    Per questo motivo non è possibile implementare un accesso a clock alterni come avveniva sull’Amiga. Però è possibile programmare il DMA per effettuare i trasferimenti da Main Ram a VRAM (o da cartuccia a Main Ram), e nel frattempo far lavorare la CPU sui dati e sul codice presenti in TCM.

    Una tipica applicazione è quella dello streaming video:
    – Trasferisco tramite DMA un blocco di dati dalla cartuccia alla Ram
    – Trasporto il blocco dalla Ram alla DTCM
    – Tramite la routine di decompressione presente nella ITCM decomprimo il blocco
    – Tramite DMA trasferisco il blocco decompresso alla VRAM
    – Ripeto finchè non finisce il filmato

    In questo modo, una volta innescato il meccanismo, il DMA si occuperà di caricare i dati del prossimo blocco, e contemporaneamente la CPU decodifica il blocco corrente.

    Usando la libreria di sviluppo Homebrew, che da molta più libertà allo sviluppatore, è anche possibile utilizzare l’ARM7 in parallelo all’ARM9 per smistare le operazioni di decodifica. La libreria Nintendo vincola l’ARM7 a delle funzioni predefinite (gestione Wifi, Audio, TouchScreen e poca altra roba).

  • # 10
    Antonio Barba (TheKaneB)
     scrive: 

    quando il DS effettua il boot in modalità GBA, il nitro processor si riconfigura in modo perfettamente identico al GBA, ripristinando clock (e bug, anche!) originali, e disattivando l’hardware aggiuntivo.

    L’OAM buffer contiene esattamente 128 entries per gli sprite, e tutti e 128 possono stare sulla stessa riga di raster.

  • # 11
    Unrealizer
     scrive: 

    sbaglio o nella mappa postata non è riportata la cartuccia NDS (o almeno, io non la vedo)? O_O

    Inoltre, mi interesserebbe sapere come funzionano le flash per il salvataggio… smontando una cartuccia commerciale (pokemon diamante) ho trovato una flash SPI da 512KB, e utilizzando un PIC sono riuscito a leggerla (anche se far funzionare il tutto a 3,3V non è stato semplice, almeno per me che sono alle prime armi :D) ma quando ho provato il tutto su una cartuccia con led IR incorporati (pokemon oro), ho trovato solo una flash da 8KB, e non 512KB @_@

  • # 12
    iva
     scrive: 

    Dallo schema non sembra un puro modello Harvard (ma modified), il bus verso la memoria e’ uno solo, la separazione avviene tramite la cache dati e istruzioni (come avviene pure in un qualsiasi x86).

  • # 13
    Antonio Barba (TheKaneB)
     scrive: 

    @iva e @Unrealizer: vi rimando al mio commento #5

    @Unrealizer: la Cartuccia NDS non è mappata in memoria, quindi non è presente in questo schema. Vi si accede tramite un controller seriale. La memoria di salvataggio è diversa nei vari giochi, quelle più grosse costano di più quindi si sceglie la cartuccia appropriata in base al budget del gioco :-)

  • # 14
    Antonio Barba (TheKaneB)
     scrive: 

    @iva: i manuali ARM parlano nel dettaglio della struttura Harvard del core ARM9 e di come questa sia in realtà Von Neumann soltanto “dal memory controller in giù”. Per approfondire ti rimando al sito arm.com, ai fini dell’articolo mi sembrava un po’ troppo approfondito come discorso e ho preferito non appesantirlo più di così :-)

  • # 15
    [D]
     scrive: 

    Che bordello sto DS… ma in fase di progettazione e costruzione, tutto sto casino tra subprocessori e graphics engine non dovrebbe risultare più costoso dell’implementazione diretta di un solo componente ma più potente ?

  • # 16
    Mirco Tracolli
     scrive: 

    Non vedo l’ora di leggere i prossimi articoli, sono troppo curioso :D.

    @ Antonio

    Volevo chiederti una cosa: questa architettura ha risentito molto della retrocompatibilità?

    Mi sembra di aver capito infatti che alcune scelte, sopratutto per quanto riguarda la parte grafica, sono state fatte per non perdere compatibilità con prodotti già usciti. Naturalmente è solo una mia impressione, forse anche un pò troppo azzardata :P.

  • # 17
    Unrealizer
     scrive: 

    @Antonio Barba
    tutto chiaro sul fatto che la cartuccia non è mappata in memoria ;)

    il problema del save è diverso… un gioco così non può avere un salvataggio di soli 8KB (almeno non quando la versione precedente usava flash 128 volte più grandi!), e poi tra cassette diverse, i dati così ottenuti sono sempre molto simili (variano al massimo un paio di byte), anche se il progresso all’interno del gioco varia molto tra le due cassette… il mio sospetto è che si tratti di un qualche buffer di controllo per gli infrarossi incorporati, ma visto che c’è una sola linea CS sulla cartuccia, non capisco come si possa scegliere tra IR e save!

  • # 18
    Antonio Barba (TheKaneB)
     scrive: 

    @D: considera che Nintendo generalmente mantiene la compatibilità \hardware\ con la console precedente. Questo complica il progetto ma aiuta le vendite nei primi mesi.

    Quasi tutte le console costruite in questo modo hanno 2 processori. In questo caso invece di tenerlo spento (come lo Z80 del GameBoy Advance), hanno ben pensato di farlo funzionare anche in modalità Nitro (cioè in modalità Nintendo DS).

    La presenza dei due Graphics Engine è dovuta alla scelta di usare 2 schermi.
    Il resto è perfettamente allineato con l’architettura, e l’apparente complessità logica è nascosta dentro una sorprendente semplicità fisica (quasi tutto quello che ho citato è implementato dentro un singolo chip, il Nitro Processor appunto).

    Quello che costa è l’elettronica, l’interno del chip è quasi irrilevante nel bilancio complessivo dei costi di produzione, soprattutto quando si tirano fuori 150 milioni di pezzi venduti :-D

  • # 19
    Antonio Barba (TheKaneB)
     scrive: 

    @Mirko: esatto, il DS è sostanzialmente un GBA “on steroids” :-D
    @Unrealizer: non ho idea di come siano costruite le varie cartucce dei pokemon. In quanto progetto interno, la Nintendo potrebbe anche decidere di progettare una cartuccia ad hoc, diversa da quella che “vende” ai publishers esterni. In genere comunque la memoria del gioco è una ROM, mentre il salvataggio è su SRAM non volatile (con batteria), su SPI Flash, o su EEPROM. In base al tipo di memoria di salvataggio cambia la dimensione, il costo e le modalità di programmazione (le EEPROM si “consumano” più delle Flash ROM, quindi devi salvare meno spesso… ecc…).

  • # 20
    [D]
     scrive: 

    “Il resto è perfettamente allineato con l’architettura, e l’apparente complessità logica è nascosta dentro una sorprendente semplicità fisica (quasi tutto quello che ho citato è implementato dentro un singolo chip, il Nitro Processor appunto).”

    Quando parlerai del SDK offerto da nintendo voglio proprio vedere quanto sarà semplice la cosa perchè tenere dietro tutte ste cose non sembra per niente facile

  • # 21
    Unrealizer
     scrive: 

    @Antonio Barba

    Grazie comunque, mi sa che mi metterò a cercare di tirare fuori qualcosa da quei dump ;) ho come l’impressione che basti scrivere il byte giusto all’indirizzo giusto per “sbloccare” la flash xD oppure potrei mettermi a reversare la cassetta xD

  • # 22
    iva
     scrive: 

    Visto cosa distingue un’architettura Harvard pura da una modificata – separazione netta dell’address space tra dati e istruzioni – “dal memory controller in giu'” non e’ un dettaglio irrilevante.
    In un’architettura Harvard pura non potrei “fondere” i due address space nemmeno se volessi.
    In quella modificata che hai citato la separazione avviene tramite le due cache.
    Se scrivo dei dati in memoria, faccio il flush della cache, cambio il program counter e lo faccio puntare alla memoria che ho scritto quel codice viene eseguito senza problemi, o no? (sempre memory map permettendo).
    Questo non puo’ avvenire in un’architettura pura.

    Ho scritto il commento vedendo che hai postato il link dell’articolo su wikipedia dell’architettura harvad pura quando e’ disponibile anche quello della modificata (che pero’ e’ disponibile in inglese ma non in italiano), che sarebbe quello corretto in questo caso.

    Tutto qui, comunque articolo molto interessante!

    /pedantic mode off :)

  • # 23
    Antonio Barba (TheKaneB)
     scrive: 

    Non parlerò dell’SDK di Nintendo (per validi ed intuibili motivi), ma di devkitPro e libNDS, che sono l’equivalente open source e free software.
    I concetti sono gli stessi comunque, cambiano i nomi delle funzioni ma il modo di programmare è analogo.

    Comunque si, il programmatore mediamente deve fare i salti mortali per programmare sul DS, e questo può avere effetti collaterali di assuefazione e dipendenza. Un po’ come una droga, ti uccide i neuroni ma non puoi farne a meno! ;-D

    Chiaramente a Nintendo questo non interessa molto, perchè gli utenti del suo SDK sono software house qualificate (accettano solo le richieste di software house con un certo background). La complessità di questi sistemi tipicamente spaventa a morte l’hobbista che potrebbe improvvisamente decidere di dedicarsi alla raccolta di francobolli, ma per un professionista si tratta soltanto di studiarsi bene qualche centinaio di pagine di manuali tecnici. Non è un caso, infatti, che molti programmatori che lavorano su Nintendo DS siano gli stessi che hanno lavorato anche sulle precedenti console Nintendo, che condividono la stessa filosofia architetturale, e generalmente la maggior parte di loro si trova a proprio agio sia con il C che con l’Assembly.

    Insomma, non è roba per mangiatori di quiche :-D

  • # 24
    Cristian
     scrive: 

    Bello questo articolo!
    Scommetto che ti sei divertito a sezionare la DS :-)

  • # 25
    Antonio Barba (TheKaneB)
     scrive: 

    @iva: tecnicamente hai ragione :-)
    L’esecuzione di codice in-place però deve sottostare alle impostazioni della MPU, che decide i parametri di accesso delle varie regioni di memoria. Tra i bit di protezione c’è anche il bit Execute, che decide se tale zona di memoria può essere eseguita o no.

    Comunque si, a causa di questo mix si tratta di un’architettura mista, o Harvard modificata (termine che non amo, ma questa è una mia opinione personale).

  • # 26
    [D]
     scrive: 

    “Chiaramente a Nintendo questo non interessa molto”

    Ah bhe grazie. Vuoi accodarti al carrozzone dove trovi ancora un idraulico così duro di comprendonio da non aver capito che la principessa, piuttosto che darla a lui, si farà la lucertola in tutte le posizioni del kamasutra tanto da far intervenire wwf e greenpeace ? Sei innamorato di un ratto, caduto da piccolo nel barattolo della senape, con la fissa di infilare la coda nel 220 ?
    Ami alla follia un folletto verde caratterizzato da manie sociopatiche nei confronti dei maiali ?

    Per loro, per le loro “incredibili” avventure e soprattutto per la barca di soldi che ci girano attorno, ti studi anche 3000 pagine di manuali su come mappare la memoria con i fiammiferi e non fiati :)

  • # 27
    Antonio Barba (TheKaneB)
     scrive: 

    bravissimo, vedo che hai espresso bene il concetto :D

  • # 28
    Antonio Barba (TheKaneB)
     scrive: 

    ERRATA CORRIGE:
    Dopo alcune verifiche, risulta che la mappa di memoria sia corretta. La Main Ram è accessibile sia da parte dell’ARM9 sia da parte dell’ARM7. A causa di vari problemi tecnici (dovuti alla mancanza di meccanismi di cache coerency e alla penalità nelle performances) l’ARM7 viene fatto lavorare (di default) esclusivamente con la propria Working Ram, ma volendo (e assumendosi le dovute responsabilità) può anche andare a ramazzare nella Main Ram.

    Grazie ai lettori che mi hanno messo la pulce nell’orecchio :-)

  • # 29
    Cesare Di Mauro
     scrive: 

    Mi pareva troppo strano. :D

    Grazie per le altre informazioni. Aspetto impazientemente gli altri articoli (perché ne farai tanti, vero? :D) per togliermi alcuni dubbi che mi sono affiorati nel frattempo.

    Comunque, sì, programmare il DS sarà un casino, ma l’hardware è relativamente semplice (con tutta quella roba dedicata non sarà uno spasso, ma per tante cose fa tutto lui) e penso sia abbastanza “godereccio” (assembly ARM escluso. 68000 rulez. :D).

  • # 30
    flameman
     scrive: 

    @ Unrealizer

    \il problema del save è diverso… un gioco così non può avere un salvataggio di soli 8KB (almeno non quando la versione precedente usava flash 128 volte più grandi!), e poi tra cassette diverse, i dati così ottenuti sono sempre molto simili (variano al massimo un paio di byte), anche se il progresso all’interno del gioco varia molto tra le due cassette… il mio sospetto è che si tratti di un qualche buffer di controllo per gli infrarossi incorporati, ma visto che c’è una sola linea CS sulla cartuccia, non capisco come si possa scegliere tra IR e save!\

    ciao
    il tuo sospetto e’ fondato, una cartuccia per GB/GBA/DS non si compone di sola ram e flash, ma spesso ha anche un MBC (memory bank controller).

    Il caso da te citato ne e’ un esempio (l’IRDA, con tutta la sua codifica.m e’ implementata e mappada dall’MBC), come ne e’ un sempio la gb_camera, o altre cartucce particolari che frappongono fra il nudo bus dati di interfaccia verso la console e i dispositivi di memoria (ram e flash) anche un chip di controllo + intelligente di un semplice address decoder.

    Ovviamente non c’e’ doc ufficiale, tutto quanto esiste (o potrebbe esistere underground, incluso il … cosa mappa/come e’ mappato/come si configura) e’ frutto di reverse enge di appassionati.

    … ore ed ore ed ore di hacking.

    per GB esistono almeno 5 tipo di MBC. Ci feci un po’ di hack tanti anni fa.

    Per gb sfruttai l’MBC di una cartuccia, e dissaldai il chip per confezionare una cartuccia con nvram (al posto della rom). Disegnato (Orcad) e fatto realizzare il PCB (4 strati, fori metallizati, profilo di una cartuccia GB), ci saldi i componenti in smd (la mia brava nvram, ram, e l’MBC), ci giocai un po’, ma poi in sostanza non ho mai fatto nulla.

    Per gba mi risparmiai la fatica del dissaldare l’MBC da una cratuccia-game per risaldarlo su una cartuccia-prototipo, semplicemente facendo fare ad un cpld xilinx quello che fa l’MBC. Bella esperienza, ci aggiunsi anche un paio di seriali, e un modulo di rete con tanto di protocollo udp/ip (microchip), ma ancora una volta, poi, in sostanza, non ci ho mai fatto nulla.

    Per DS (che ha hw ancora + ghiotto) men che meno: zero.

    Certo: scrivere sw, o in particolare giochi per dispositivi del genere e’, francamente, bello, come una forma artistica… ma alla fine, scontrandosi col pragmatismo imposto dalla realta’, e allora questi giocattoli altro non sono che strumenti didattici in tempo di uni.

    Hobby. Mere curiosita’.

  • # 31
    flameman
     scrive: 

    qualcuno ha sviluppato per gb o per gba o ha intenzione di farlo ?

    eventualmente per ds ?

    che reali possibilita’ ci sono di trasformare questa passione in opportunita’ lavorative ?

  • # 32
    Antonio Barba (TheKaneB)
     scrive: 

    @Flameman: il lavoro nell’ambiente si trova, ma ormai il DS non viene piú considerato perché é uscito il nuovo Nintendo 3DS.
    Con le nuove console l’approccio é diverso, più simile alla programmazione per pc.
    Se vuoi intraprendere la strada dei video giochi a livello professionale devi puntare su tecnologie più moderne.

  • # 33
    flameman
     scrive: 

    si, ma in concreto che possibilita’ ci sono ?
    mando un C.V. a chi ?
    come mi preparo, ecc ecc

  • # 34
    Antonio Barba (TheKaneB)
     scrive: 

    @flameman: puoi farti un giro su gameprog.it, vedere quali sono le aziende i VG attualmente operative in Italia, visitare i relativi siti internet, verificare le posizioni aperte e inviare di conseguenza il tuo CV.
    In Italia ci sono poche aziende di questo tipo, cioè che sviluppano giochi di grosso calibro su console da gioco e PC. Se vuoi qualche possibilità in più buttati sugli smartphone attuali, impara a programmare da zero alcuni giochi semplici (tipo Tetris, R-Type, Sokoban, cose classiche insomma) e portali con te durante il colloquio.
    Comunque qui la discussione mi sembra un pochino OT, ci sono diversi siti che trattano in modo estensivo l’argomento, con guide e consigli per iniziare a lavorare nell’industria dei VG.

  • # 35
    flameman
     scrive: 

    Grazie delle info, ma a mio avviso e’ + interessante parlare di reali possibilita’, in concreto, che farsi le pippe su mere curiosita.

    Avete scritto molte cose interessanti, belle, ma voglio dire: presenti DS, presenti (o presenterai) DS-SDK, bene, bello, ma cosa me ne faccio io in concreto?

    Ci confeziono qualcosa come ho fatto io per GB e GBA, bello, ma poi cosa me ne faccio ? Me li porto ai colloqui o li allego (.rom x email) assieme al CV.pdf

    ahahaha

    Esempio di sito/siti che tratta, invece, opportunita’ lavorative ?

  • # 36
    Antonio Barba (TheKaneB)
     scrive: 

    @flameman: i miei articoli sono in linea con quelli relativi al chipset di Amiga. Che ci fai in concreto? Nulla.
    Di siti che trattano opportunità lavorative ce ne sono a tonnellate. ad esempio: http://lmgtfy.com/?q=job+game+programmer+

  • # 37
    flameman
     scrive: 

    in effetti anche tutta sta manfrina di amiga e’ tanto bella quanto nostalgica quando inutile

    dovessi esprimermi come Steve Jobs direi che “il passato non e’ vendibile”

    ma e’ davvero cosi’ ?

    leggere “se amiga avesse avuto un hppa come cpu”, e’ tipo chiedersi se super mario bross ce la possa mai fare (o ce l’abbia segretamente mai fatta) in una qualche fantomatica edizione ultra speciale di portarsi a letto finalmente la principessa tanto bramata

    di questi tempi serve doparsi di pragmatismo!

    detto questo, e sono il primo che predica bene e poi fa il contrario, se ti chiedo di siti che parlando in concreto di reali possibilita’ lavorative e’ perche’ mi piacerebbe anche sapere se tra i lettori c’e’ qualcuno che in effetti le ha realizzate

    oppure si tratta di sogni, come avere ancora un amiga-2012 sulla scrivania ?

    ditemi se ha senso con il mondo che non lascia affatto fiato per parlare in modo estroverso

    il verbo di oggi e': e a fine mese come ci arrivo ?

    e per questo si fanno lavori frustranti ma che a fine mese ti ci fanno arrivare

    io per esempio faccio un lavoro che non mi piace per niente: sviluppo firmware avionico per aeromobili con un approccio di processo degli anni ’60

    nettamente castrante!

    ma e’ il primo impiego, e ci sono arrivato mettendo assieme parte dell’esperienza amatoriale degli ultimi 10 anni: cio’ mi ha permesso di essere abbastanza skillato per inserirmi direttamente nel ramo di sviluppo (e non nel testing, dove per il mio estro creativo, nel fare cose ripetitive, e ricontrollare 1001 volte il lavoro degli altri, mi sarei suicidato dopo 3 giorni)

    proprio sulla scia delle diverse architetture, del concetto di “do not think different, be different” (di Be.inc) mi sono ritagliato una piccola nicchia creativa

    almeno respiro, ma ancora non mi basta, vorrei fare nettamente altro, qualcosa di molto + creativo: ho dei limiti molto marcati in quello che faccio, e c’e’ poco da fare

    quando leggo questo blog, nel leggere l’approccio “come si sarebbe voluto che fosse”, io spero di leggere anche esperienze lavorative che hanno portato il bagaglio e l’interesse hobbistico personale a concretitzzare lavori che diano soddisfazione reale

    in poche parole, ma chi parla tanto di amiga, nintendo e vari, chi ci ha mai smanettato o se ne e’ intrigato fino nei + intimi dettagli viscerali (fino a dentro il design, o dentro alle schede madri, sui chip)

    oggi, con tutto quel know/how, cosa fa ?

  • # 38
    Cesare Di Mauro
     scrive: 

    Personalmente: http://www.youtube.com/watch?v=Bx8WMlkkC2I

  • # 39
    Antonio Barba (TheKaneB)
     scrive: 

    @flameman: personalmente ho imparato a scrivere giochi su Nintendo DS, e per lavoro ne ho sviluppati 2 che puoi comprare sugli scaffali di qualsiasi negozio di giochi. Grazie a quell’esperienza ho continuato e ho lavorato su altri 4 titoli commerciali sempre più importanti. Quindi si, le skill che si acquisiscono anche con i semplici “smanettamenti” possono essere riciclate ai fini della propria professione. Un po’ come quando a scuola studi materie che non ti piacciono però, a distanza di decenni, senti quanto quelle materie “inutili” siano state in realtà determinanti per la tua formazione culturale complessiva.

    In sostanza, finchè tieni in moto il cervello, niente di quello che impari è inutile :-)

  • # 40
    Luca_
     scrive: 

    Buongiorno volevo se esite in qualche forma un timer in modo che per esempio si posso giocare per un’ora al massimo al giorno, da inserire sulla R4 del nintendo DS

    saluti a tutti

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.