ForumFree

zaxxon

Group:
Administrator
Posts:
19
PM  Email 

Friends
Add Friend

Tag Board

    Smilies

    Name:

     

    2 user(s) online
    F_ACTIVE
    2 guests
    0 members
    0 Anonymous Members
    [ View Complete List ]


    Last comments
    10/9 10:39: VaksblaltettY in Double Buffering

    Statistics
    F_STATS
    Blog italiano su Dingoo A320 have:
    12 articles, 1 comments, 55 members,
    3.249 total visits, 11 visits this month,
    324º in Top Blog

    The newest member is erundaeteva

    Most users ever online was 16 on 28/7/2009, 14:04


    Calendar



    B_NORM    
    view post Posted on 13/9/2009, 10:35 by: zaxxonQuote
    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: 203Last Post by: zaxxon (13/9/2009, 10:35)
     

    B_NORM    
    view post Posted on 19/8/2009, 15:20 by: zaxxonQuote
    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: 196Last Post by: zaxxon (19/8/2009, 15:20)
     

    B_NORM    
    view post Posted on 18/8/2009, 09:16 by: zaxxonQuote
    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: 193Last Post by: zaxxon (18/8/2009, 09:16)
     

    B_NORM    
    view post Posted on 17/8/2009, 18:48 by: zaxxonQuote
    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: 196Last Post by: zaxxon (17/8/2009, 18:48)
     

    B_NORM    
    view post Posted on 2/8/2009, 17:36 by: zaxxonQuote
    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: 231Last Post by: zaxxon (2/8/2009, 17:36)
     

    B_NORM    
    view post Posted on 28/7/2009, 10:42 by: zaxxonQuote
    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: 205Last Post by: zaxxon (28/7/2009, 10:42)
     

    B_NORM    
    view post Posted on 30/6/2009, 15:33 by: zaxxonQuote
    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: 284Last Post by: zaxxon (30/6/2009, 15:33)
     

    B_NORM    
    view post Posted on 21/6/2009, 10:40 by: zaxxonQuote
    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: 1830Last Post by: VaksblaltettY (10/9/2010, 10:39)
     

    B_NORM    
    view post Posted on 21/6/2009, 10:36 by: zaxxonQuote
    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: 145Last Post by: zaxxon (21/6/2009, 10:36)
     

    B_NORM    
    view post Posted on 21/6/2009, 10:32 by: zaxxonQuote
    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: 160Last Post by: zaxxon (21/6/2009, 10:32)
     

    Search: