Programmer sur DS avec la libnds

[Noda]

Envoyé par Pitt

Cet exemple utilise le canal 3, et copie des octets (même si on utilise une taille en mots, puisqu'on divise cette taille par 2 ). Vous pouvez bien entendu utiliser un autre canal, ou encore transférer des mots (DMA_COPY_WORDS) plutôt que des octets (DMA_COPY_HALFWORDS).

Si je ne m'abuse un mot (word) c'est 32 bits donc 4 octets, et un halfword 16 bits soit 2 octets

[Pitt]

Envoyé par Noda

Si je ne m'abuse un mot (word) c'est 32 bits donc 4 octets, et un halfword 16 bits soit 2 octets

Très juste, merci pour la correction de coquilles.

[Dr.Vince]

Envoyé par Pitt

* Serait il possible d'utiliser des '|' dans les tableaux ?

C'est fait, il suffit juste de doubler le caractère |

[Pitt]

T'es génial !

[Foxy]

Envoyé par Noda

Si je ne m'abuse un mot (word) c'est 32 bits donc 4 octets, et un halfword 16 bits soit 2 octets

Hmm.. Normalement un WORD c'est 16 bits et un DWORD c'est 32 bits.

[Brunni]

En C sous Windows (et probablement ailleurs) c'est comme ça, mais dans le jeu d'instructions d'ARM c'est word = 32 et halfword = 16, je n'ai d'ailleurs jamais vraiment compris, il ne doit pas y avoir de standard

[Foxy]

Merci pour l'info Brunni, au moins c'est plus clair là

[Arialia]

tiré de wikipedia :

En plus du système de représentation des nombres, il faut s'intéresser à la taille et la précision des nombres qu'un processeur peut manipuler. Dans le cas d'un processeur binaire, un "bit" correspond à une position particulière dans les nombres que le processeur peut gérer. Le nombre de bits (chiffres) qu'un processeur utilise pour représenter un nombre est souvent appelé "taille du mot" (word size, bit width, data path width) ou "précision entière" lorsqu'il s'agit de nombres entiers (à l'opposé des nombres flottants). Ce nombre diffère suivant les architectures, et souvent, suivant les différents modules d'un même processeur. Par exemple, un CPU 8-bit gère des nombres qui peuvent être représentés par 8 chiffres binaires (chaque chiffre pouvant prendre 2 valeurs), soit 28 ou 256 valeurs discrètes. En conséquence, la taille du nombre entier défini une limite à la plage des nombres entiers que le logiciel exécuté par le processeur pourra utiliser.

Donc comme l'arm est 32 bits la taille du mot est donc 32 bits, c'est pour ça que pour le compilateur un word est sur 32 bits...

Sur PC, il faut tenir compte de l'historique : le 8086 est un processeur 16 bits ainsi que le 80286 les premiers compilateurs pc sont nés à cette époque et donc un "word" était sur 16 bits, apparemment certains compilateurs sur Pc ont donc gardé cette taille pour la compatibilité du code ...

donc attention à la taille du "word" tout dépend du processeur ciblé et du compilateur ....

[Pitt]

Oui, effectivement, c'est très aléatoire, d'où la confusion que j'avais faite dans le tuto ...
En tout cas, update demain, avec restructuration totale du tuto ...

[Aigle d'or]

Si dans le langage courant, on parle de mot machine, c'est pour bien sous entendre que la taille du mot est lié au processeur qui le manipule.

[Pitt]

Finalement, pas de nouvelle version aujourd'hui, mais je suis en train de refaire complètement le tuto, tout en l'améliorant ...

[simonomis]

Envoyé par Pitt

On va maintenant désactiver l'écran tactile, qui ne nous sert à rien, en ne lui affectant aucun mode graphique.
Par contre, on initialise l'écran du haut, sur lequel on va écrire notre texte, au mode graphique nécessaire, c'est-à-dire le mode 0 2D. On va également activer un des fonds, le fond 0.
Les fonds sont des couches superposées, qui gèrent la transparence, et qui permettent d'utiliser plusieurs "niveaux" d'affichage.

Code PHP:

 videoSetMode(0);
 videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE); 


ce n'est pas l'inverse qui est fait avec ce code ?!
chez moi, quand je tape ca, l'ecran du haut est desactivé et le texte est en bas...

[pmcc]

Envoyé par simonomis

ce n'est pas l'inverse qui est fait avec ce code ?!
chez moi, quand je tape ca, l'ecran du haut est desactivé et le texte est en bas...

Il a peut-être inversé les 2 écrans (de tête SwapLcd()).

[Pitt]

arf, oui, j'avais inversé mes écrans dans mon code de test, et j'avais pas vérifié cette partie du code ...
bon, je corrigerai, mais de toute façon, le tuto revient dans pas longtemps, sous une tout autre forme, et en beaucoup mieux !

[mastertop101]

Salut, j'ai essayé de compiler et je me retrouve avec plusieurs problèmes (et je ne suis pas le seul à en avoir)

C:\devkitPro\ESSAIS_LIBNDS\arm9>make
main.c
arm-eabi-gcc -MMD -MP -MF /c/devkitPro/ESSAIS_LIBNDS/arm9/build/main.d -g -Wall -O2 -march=armv5te -mtune=arm946e-s -fomit-frame-pointer -ffast-math -mthumb -mthumb-interwork -I/c/devkitPro/ESSAIS_LIB
NDS/arm9/include -I/c/devkitPro/libnds/include -I/c/devkitPro/ESSAIS_LIBNDS/arm9/build -DARM9 -c /c/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c -o main.o
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c: In function 'main':
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c:10: warning: implicit declaration of function 'BG_MAP_BG'
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c:11: warning: implicit declaration of function 'RGB'
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c:15:3: warning: no newline at end of file
linking arm9.elf
main.o: In function `main':
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c:10: undefined reference to `BG_MAP_BG'
c:/devkitPro/ESSAIS_LIBNDS/arm9/source/main.c:11: undefined reference to `RGB'
collect2: ld returned 1 exit status
make[1]: *** [/c/devkitPro/ESSAIS_LIBNDS/arm9/arm9.elf] Error 1
make: *** [build] Error 2

C:\devkitPro\ESSAIS_LIBNDS\arm9>pause
Press any key to continue . . .

Et mon code :

#include <nds.h>
#include <stdio.h>
int main (void){
	irqInit();
	irqSet(IRQ_VBLANK,0);
	videoSetMode(0);
	videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE);
	vramSetBankC(VRAM_C_SUB_BG);
	SUB_BG0_CR=BG_MAP_BG(31);
	BG_PALETTE_SUB[255] = RGB(31, 31, 31); 
	consoleInitDefault((u16*)SCREEN_BASE_BLOCK_SUB(31),(u16*)CHAR_BASE_BLOCK_SUB(0),16);
	iprintf("Hello world !\n");
	return 0;
	}

Utilisant le template :
C:\devkitPro\examples\nds\templates\arm9

Merci de votre aide

[pmcc]

Envoyé par mastertop101

Salut, j'ai essayé de compiler et je me retrouve avec plusieurs problèmes (et je ne suis pas le seul à en avoir)




Et mon code :

#include <nds.h>
#include <stdio.h>
int main (void){
	irqInit();
	irqSet(IRQ_VBLANK,0);
	videoSetMode(0);
	videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE);
	vramSetBankC(VRAM_C_SUB_BG);
	SUB_BG0_CR=BG_MAP_BG(31);
	BG_PALETTE_SUB[255] = RGB(31, 31, 31); 
	consoleInitDefault((u16*)SCREEN_BASE_BLOCK_SUB(31),(u16*)CHAR_BASE_BLOCK_SUB(0),16);
	iprintf("Hello world !\n");
	return 0;
	}

Utilisant le template :
C:\devkitPro\examples\nds\templates\arm9

Merci de votre aide

RGB15 à la place de RGB, et BG_MAP_BASE pour BG_MAP_BG.

[Pitt]

arf oui, j'étais pas inspiré le soir où j'ai écrit ça ?!
Bon, bientôt une nouvelle version, et sans les bugs ...
Personne ne l'avait remarqué avant ?

[Arialia]

Oh ! je l'avais pas remarqué j'ai du faire une correction automatique sans faire gaffe ! Le cerveau nous joue des tours des fois ....

[Dr.Vince]

le truc que tu devrais faire Pitt c'est tester les bouts de code avant de poster pour être sur qu'il n'y a pas de coquilles

[Pitt]

C'est ce que j'avais fait, mais comme j'avais utilisé plusieurs codes de test, j'ai juste du me tromper de fenêtre XD ...

P.S.: Regarde ta messagerie !

[Pitt]

Grosse update, pas énormément de nouveautés, mais c'est 3x plus précis, 3x plus structuré, et 3x plus long aussi ...
Les commentaires/remarques/suggestions sont les bienvenus ...

Enjoy !

[Arialia]

très bien Pitt

du coup je viens de voir cette fonction :
swiDecompressHuffman

est-ce qu'en utilisant cette fonction je gagnerai du temps par rapport à la fonction équivalente de la jpeglib ou seulement de la mémoire( se serait déjà pas mal ...) ?

[Foxy]

Envoyé par Pitt

De plus, la DS est Little Endian, donc les octets qui composent chaque mot ne sont pas inversés. Par exemple le double-mot 0xBADC0FEE sera stocké comme suit, c'est-à-dire exactement comme on l'écrit en hexadécimal :

[TABLE 1 3 0]
2^Octet|0|1|2|3
Valeur|BA|DC|OF|EE
[/table]

C'est le contraire
C'est en Big Endian que les octets ne sont pas inversés, en Little Endian les octets se lisent de droite à gauche (comme sur PC).

[Dr.Vince]

effectivement Pitt,, faut que tu inverse l'entête du tableau 0123 -> 3210

[Pitt]

Arf tiens, j'ai appris un truc, je pensais sincèrement que c'était l'inverse !
Je corrige !

Pour la fonction swiDecompressHuffman, je l'ai pas encore testée, donc je ne sais pas ce qu'elle vaut, mais ça doit pouvoir optimiser un peu, en effet.

Merci pour vos remarques !

EDIT : c'est fait !
@Dr.Vince >> je vais bientôt rajouter la 2ème "partie", enfin tu vois ce que je veux dire quoi ...