Un paio di lettori (non speravo di averne tanti) mi ha chiesto dove reperire la toolchain usata per compilare il demo del SDK.
La toolchain in questione (mipsel-dingoo-elf) è stata creata con crosstool-ng versione 1.4.1.

Potete scaricare i sorgenti da qui: crosstool-ng-1.4.1.tar.bz2

Installatelo e poi prendete il file di configurazione della toolchain da qui: mipsel-dingoo-elf.config

Usate il file di configurazione, se volete modificando il path di installazione, per creare la toolchain.
Assicuratevi poi di mettere la nuova toolchain nel path.

Alla prossima!

I due progetti SDK e minilib si sono fusi insieme, perché, come anticipato, ora lo script elf2app.py è in grado di appendere un file di risorse in coda al eseguibile, mentre la minilib mette a disposizione le funzioni per accedere a tali risorse e contiene il tool resource_compiler.py per creare il file di risorse da passare a elf2app.py.

Al momento vengono gestite solo 2 tipi di risorse: IMG e RAW.
La prima gestisce qualsiasi immagine supportata dalla libreria PIL come una BlitArea, quindi direttamente utilizzabile dalle altre funzioni della minilib.
La seconda accetta qualsiasi tipo di file e lo considera un blocco di dati, poi sarà compito del programma gestire i dati caricati in memoria.

L'SDK ora si considera installato in /opt/dingoo_sdk se si cambia percorso bisogna modificare alcuni file per farlo funzionare.

Allego anche un programmino demo con la classica pallina che rimbalza sopra uno sfondo: sia l'immagine della pallina che quella dello sfondo sono caricare nel eseguibile come risorse di tipo IMG.

Appena ho tempo/voglia scriverò qualche riga di documentazione sulle funzioni della minilib, ma sono abbastanza intuitive.

Alla prossima!

Download SDK: dingoo_sdk.tgz
Download demo: demo.zip

Sto facendo qualche prova per capire come appendere alla fine del eseguibile dei file di risorse grafiche o audio.
Dai test risulta che è possibile farlo ma nel file .app non deve essere presente il chunk ERPT.
Guardando gli eseguibili dei giochi forniti con la console, in effetti usano le risorse appese alla fine del file e non è presente il chunk ERPT.

L'ipotesi che tale chunk serva per indicare i dati BSS (non inizializzati) è dunque da scartare, in effetti tale informazione il sistema può ricavarla anche dai dati presenti nel chunk RAWD.

Visto che gli eseguibili funzionano anche senza l'ERPT, l'ho rimosso dallo script del SDK, quindi dalla prossima versione non verrà generato, lo script darà invece la possibilità di appendere un file in coda al eseguibile: scriverò un tool per inglobare tutti i file di risorsa in un unico file (una specie di tar) da appendere poi al eseguibile. Nella minilib saranno presenti le funzioni per estrarre tali file e caricarli in memoria.

Alla prossima!

Piccolo aggiornamento per l'SDK scritto in Python.
Ho modificato la struttura di base, ora non uso più un unico file (dingoo.o) bensì una libreria statica (libdingoo.a) contenente un file oggetto per ogni simbolo: in questo modo se l'applicazione usa solo poche funzioni non è costretta a linkare anche tutte le altre.

Per far questo ho dovuto riscrivere quasi completamente lo script elf2app.py per poter importare solo i simboli realmente utilizzati.

Nelle prossime versioni inserirò anche la minilib nel SDK aggiungendo la possibilità di inserire in coda al eseguibile delle risorse (grafica, audio, ecc), la cosa dovrebbe già essere fattibile, in quanto il sistema esporta delle funzioni apposite (dl_res_*) ma non ho ancora capito come usarle, per cui farò qualcosa di mio.

Il nuovo SDK è scaricabile qui: MySDK 0.0.2

Ho iniziato a scrivere una libreria di funzioni utili per lo sviluppo di giochi.
Il file include di ciò che ho implementato finora è il seguente:


Appena ho qualcosa di più completo lo rendo pubblico, nel frattempo allego una piccola demo fatta per testare le funzioni: test.app

L'SDK per Dingoo che si trova in rete è pensato per essere usato con Windows, infatti il programma per generare il file .app è un eseguibile Windows e, per usarlo sotto Linux, bisogna ricorrere al wine.

L'analisi del firmware mi ha permesso di estrarre l'elenco di tutti i simboli esportati dal kernel e risulta che non tutti sono visibili attraverso la libreria entry.a fornita con l'SDK.

Ho quindi deciso di creare una serie di script in python per poter generare file .app anche in Linux senza dover usare il wine, avendo nel contempo accesso a tutti i simboli esportati dal kernel.

Il file dingoo.h al momento è molto scarno, con il tempo, studiando le funzioni del kernel, verrà rimpolpato con i prototipi delle funzioni trovate.

Allego un archivio contenente questo SDK minimale ed ovviamente il classico Hello, World! per vedere come usarlo.

Da notare che io lo uso con una toolchain che non prevede l'uso di un sistema unix e relativa libc, ma penso possa funzionare con qualunque altra toolchain.

Download: Dingoo MySDK

Analizzando il codice delle versioni 1.01, 1.02, 1.03 e 1.1 mi sono accorto che la funzione _lcd_get_frame() e le funzioni da lei chiamate mantengono lo stesso codice, variando solo l'indirizzo e/o le costanti.
Questo ad esempio è il dump della funzione nella versione 1.03 del firmware:

La memoria video della console non rientra nella RAM di sistema, bensì è integrata nel controller LCD. Il Sistema Operativo della console mantiene una copia dell'immagine video in RAM e la invia al controller LCD dopo aver effettuato le modifiche.
Quindi, per far apparire qualcosa a video, bisogna chiedere al sistema l'indirizzo del buffer in RAM, andare a modificare il contenuto del buffer e poi chiedere al sistema di aggiornare il controller LCD.

La richiesta del indirizzo del buffer video in RAM avviene con la chiamata della funzione _lcd_get_frame().

Il buffer ottenuto rappresenta i pixel dell'immagine che apparirà a video, i pixel sono memorizzati da sinistra a destra e dall'alto al basso, per cui i primi byte del buffer codificheranno il pixel in alto a sinistra dello schermo.
Ogni pixel occupa 2 byte (16 bit) ed è codificaro in RGB:565, cioè ci sono 5 bit per la componente rossa, 6 bit per quella verde ed altri 5 bit per quella blu.

Una volta modificato il contenuto del buffer, per far apparire a video le modifiche bisogna chiamare la funzione _lcd_set_frame(), la quale invierà al controller LCD il contenuto del buffer in RAM.
ATTENZIONE: La funzione svolge il suo compito impostando uno dei canali DMA, per cui ritornerà il controllo al chiamante prima che tutto il buffer sia copiato nel controller LCD. Se il nostro programma non tiene conto di questo fatto e comincia a disegnare il nuovo frame appena torna la chiamata da _lcd_set_frame(), si corre il rischio di modificare la RAM che non è ancora stata inviata al controller, ottenendo a video fastidiosi artefatti o sfarfallii.

Per ovviare a questo problema bisogna ricorrere alla tecnica del double buffering, cioè avere in RAM due buffer distinti e, mentre la _lcd_set_frame() invia uno dei buffer al LCD controller, noi usiamo l'altro buffer per disegnare il nuovo frame, al termine li scambiamo.
Nei siti che si occupano di programmazione per il dingoo si trovano esempi di double buffering poco performanti: utilizzano sì un doppio buffer in RAM, ma per fare lo scambio lasciano che sia il processore a copiare il buffer allocato dal programma nel buffer di sistema per poi chiamare la _lcd_set_frame().
Analizzando il dump delle funzioni _lcd_get_frame() e _lcd_set_frame() contenute nel firmware, ho scoperto l'indirizzo della variabile che contiene il buffer video del sistema. Andando a modificare il contenuto di questa variabile decidiamo noi dove si trova il buffer video prima di chiamare la _lcd_set_frame(), così non serve fare copie da RAM a RAM, ma basta settare un unico valore a 32 bit.
Il problema è che da una versione all'altra del firmware l'indirizzo della variabile cambia, quindi il nostro programma, per usare questa tecnica, deve prima determinare la versione del firmware installato e poi usare il corrispondente valore.
Per la versione 1.03 il puntatore al buffer si trova...

Read the whole post...