Blog italiano su Dingoo A320

Posted on 13/9/2009, 10:35 by: zaxxon

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!

Comments: 0 | Views: 203

Last Post by: zaxxon (13/9/2009, 10:35)

SDK e minilib insieme

Posted on 19/8/2009, 15:20 by: zaxxon

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 caricate 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

Edited by zaxxon - 9/1/2011, 09:02

Comments: 0 | Views: 196

Last Post by: zaxxon (19/8/2009, 15:20)

Embedding Resources

Posted on 18/8/2009, 09:16 by: zaxxon

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!

Comments: 0 | Views: 193

Last Post by: zaxxon (18/8/2009, 09:16)

MySDK aggiornamento

Posted on 17/8/2009, 18:48 by: zaxxon

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

Comments: 0 | Views: 196

Last Post by: zaxxon (17/8/2009, 18:48)

minilib

Posted on 2/8/2009, 17:36 by: zaxxon

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:

CODICE

/*****************************************************************************
minilib.h - Minimal library for Dingoo A320 game programming.

History:
01/08/2009 - Start Project by zaxxon
*****************************************************************************/

#ifndef _MINILIB_H_
#define _MINILIB_H_

struct _BlitArea
{ unsigned short Width;
unsigned short Height;
unsigned short *Pixels;
};

typedef struct _BlitArea BlitArea;

struct _Screen
{ BlitArea *Buffer1, *Buffer2;
BlitArea *View, *Draw;
unsigned short *OldBuffer;
unsigned short **Video;
};

typedef struct _Screen Screen;

BlitArea *ML_CreateBlitArea(int width, int height);
void ML_FreeBlitArea(BlitArea *B);
int ML_BlitClone(BlitArea *src, BlitArea *dst);
int ML_BlitCopy(BlitArea *src, int srcX, int srcY, BlitArea *dst, int dstX, int dstY, int width, int height);
int ML_BlitCopyCK(BlitArea *src, int srcX, int srcY, BlitArea *dst, int dstX, int dstY, int width, int height, unsigned short ColorKey);
Screen *ML_InitScreen(void);
void ML_CloseScreen(Screen *S);
void ML_ScreenFlip(Screen *S);

#endif

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

Comments: 0 | Views: 231

Last Post by: zaxxon (2/8/2009, 17:36)

SDK per Linux

Posted on 28/7/2009, 10:42 by: zaxxon

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

Comments: 0 | Views: 205

Last Post by: zaxxon (28/7/2009, 10:42)

Double Buffer indipendente dalla versione firmware

Posted on 30/6/2009, 15:33 by: zaxxon

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:

CODICE

lcd_get_frame:
0x0000000080004d78 3c028024 lui v0,0x8024
0x0000000080004d7c 8c42e078 lw v0,-8072(v0)
0x0000000080004d80 27bdffe8 addiu sp,sp,-24
0x0000000080004d84 14400006 bnez v0,0x0000000080004da0
0x0000000080004d88 afbf0010 sw ra,16(sp)
0x0000000080004d8c 0c0019e3 jal 0x000000008000678c
0x0000000080004d90 00000000 nop
0x0000000080004d94 8fbf0010 lw ra,16(sp)
0x0000000080004d98 03e00008 jr ra
0x0000000080004d9c 27bd0018 addiu sp,sp,24
0x0000000080004da0 0c001639 jal 0x00000000800058e4
0x0000000080004da4 00000000 nop
0x0000000080004da8 08001366 j 0x0000000080004d98
0x0000000080004dac 8fbf0010 lw ra,16(sp)

0x00000000800058e4 3c028024 lui v0,0x8024
0x00000000800058e8 03e00008 jr ra
0x00000000800058ec 8c42e07c lw v0,-8068(v0)

0x000000008000678c 27bdffe8 addiu sp,sp,-24
0x0000000080006790 afbf0010 sw ra,16(sp)
0x0000000080006794 0c001639 jal 0x00000000800058e4
0x0000000080006798 00000000 nop
0x000000008000679c 8fbf0010 lw ra,16(sp)
0x00000000800067a0 03e00008 jr ra
0x00000000800067a4 27bd0018 addiu sp,sp,24

_lcd_get_frame:
0x000000008000d550 27bdffe8 addiu sp,sp,-24
0x000000008000d554 afbf0010 &...

Read the whole post...

Comments: 0 | Views: 284

Last Post by: zaxxon (30/6/2009, 15:33)

Double Buffering

Posted on 21/6/2009, 10:40 by: zaxxon

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...

Comments: 1 | Views: 1830

Last Post by: VaksblaltettY (10/9/2010, 10:39)

I controller LCD

Posted on 21/6/2009, 10:36 by: zaxxon

Stranamente la console non utilizza il controller LCD integrato nel SoC, ma ne utilizza uno esterno, pilotato dal SoC attraverso l'interfaccia SLCD (Smart LCD). La prima versione della console montava il controller ILI9325 mentre quelle più recenti montano il ILI9331. Si pensava che quelli più vecchi fossero solo sulle console bianche, ma io ne ho una nera che monta il 9325, quindi il colore non è determinante.
Entrambi questi controller dichiarano una risoluzione di 240x320 pixel, mentre la console monta un display da 320x240 pixel. Il fatto di pilotare il display ruotato di 90 gradi rispetto alle specifiche del controller, causa il cosidetto effetto tearing, cioè la comparsa di linee diagonali lampeggianti in concomitanza con repentini cambiamenti dell'immagine visualizzata.
L'effetto tearing dovrebbe scomparire configurando il controller in modalità nativa 240x320, anche se questo potrebbe portare ad un degrado delle prestazioni per le applicazioni che prevedono l'uso del display in orizzontale. Vedremo in futuro cosa fare.

Comments: 0 | Views: 145

Last Post by: zaxxon (21/6/2009, 10:36)

Il SoC Ingenic Jz4740

Posted on 21/6/2009, 10:32 by: zaxxon

Lo studio dell'hardware sarà concentrato sul utilizzo delle periferiche incluse nel SoC. Questo porterà via parecchio tempo, però penso sia utile pubblicare i datasheet che ho trovato, in modo da facilitare altri curiosi dediti allo studio...

Comments: 0 | Views: 160

Last Post by: zaxxon (21/6/2009, 10:32)