source assembleur nostub pour apprendre - Page 5

Quel est le pb ?

En fait çà trace une ligne incomplète tout en haut de l'écran, puis çà me met adress error.
Tu veux la source complete ?

Non.
Essaie de comprendre ce que tu fais sans brûler d'étapes. Tout se passera pour le mieux.
Je n'ai pas l'impression que tu aies compris comment fonctionne l'affichage sur l'écran LCD.

Tu crois, bon alors j'reprends tout depuis le début !

Comprends-tu cette source que tu étudies ?
Pourquoi tu multiplies le contenu de d1 par 30 ?
Pourquoi tu divises d0 par 8 ?
Dans la boucle d'affichage, comprends-tu ce qui est fait ?

Bonne chance

Sasume>oui je ne comprends ce que la boucle fait !

Tu comprends ou tu ne comprends pas ?

Je ne comprends pas ce que la boucle fait.

Et le reste, tu comprends ?

Pour la boucle, voici les commentaires :

 clr.w d0 ; efface le contenu de d0 (pour plus tard)
 move.b (a0)+,d0 ; copie une ligne du sprite (a0 contient l'adresse du sprite)
 lsl.w d3,d0 ; décale cette ligne de quelques pixels (en fonction de la coordonnée x d'affichage)
 move.w d0,(a1) ; copie le sprite en mémoire vidéo (comme on copie un word, il fallait que d0.w soit "vierge")
 add #30,a1 ; on pointe sur la ligne suivante de l'écran

Mais as-tu lu le tutoriel qui allait avec ce code ? Il explique sûrement un tas de choses.

Justement il explique tout le début mais pas la boucle. Mais pourquoi cela ne fonctionnet-t-il pas alors ?

En fait, en relisant le code il y a quelques petits pb...
La taille des opérandes sur lesquels tu travailles n'est pas toujours explicitée (par défaut c'est un word), donc tu mélanges parfois des bytes avec des words.
Et surtout, la façon dont l'adresse de destination est calculée est fausse, elle a une chance sur deux de provoquer un défaut d'adresse (adress error). D'ailleurs, sais-tu ce que c'est un "Adress Error" ?
Si tu cherches des routines d'affichage de sprite, il y en a un tas dans ExtGraph (cela dit, je crois que le code est incompréhensible car Lionel a supprimé tous les noms de label explicites).
Sinon, tu dois bien pouvoir en trouver ailleurs...
Ou alors le mieux c'est tout simplement que tu réécrives une routine toi-même. C'est un excellent exercice d'apprentissage de l'ASM.

Adress error, ben justement, c'est l'erreur que j'ai ! Le sprite s'affiche, le prog se relance tout seul !!! le sprite se réaffiche puis retour à home et adress error !

Tu peux poster tout ton code stp ? Parce que si tu n'as rien entre le dbra et les dc.b correspondant au sprite, le processeur va essayer d'exécuter le sprite, donc il va faire n'importe quoi...

voici donc le code:

 
                include "OS.h" 
	xdef _nostub 
	xdef _ti89 
	xdef _ti92plus 
 
 
	movem.l	d0-d4/a0-a5,-(a7) 		; Sauvegarde des registres d0,d4 et a5 
 
	move.l	$C8,a5 			; on place la table des rom_call dans le registre a5
 
	pea.l	3840 			;taille à allouer 
					;(même chose que move.l #3840,-(a7), mais plus optimisé) 
	move.l	HeapAllocPtr*4(a5),a0 
	jsr	(a0) 			;alloue les 3840 octets 
	move.l	a0,d4 			;sauvegarde l'adresse du bloc alloué en d4 
	 
	beq	nomem			;si le pointeur est nul, quitte le programme 
	 
	pea.l	$4c00			;source: adresse de l'écran 
	move.l	d4,-(a7)		;destination: adresse du bloc alloué 
	move.l	memcpy*4(a5),a0 
	jsr	(a0)			;sauvegarde l'écran 

 
	move.l	ScreenClear*4(a5),a0 	; on efface l'écran
	jsr	(a0)
	
	
	move.l	ngetchx*4(a5),a0 	; on attend l'appui sur une touche
	jsr	(a0)
	
	
	lea           croix,a0                    ; Il semblerait que le compilateur rajoute le (PC) automatiquement... 
    	move.l     #LCD_MEM,a1    ; Mémoire de la vidéo 

    	move.l    d1,d2         ; d1 et d2 contiennent la même valeur 
    	lsl.l         #5,d1         ; On multiplie d1 par 2^5, soit 32 
    	lsl.l         #1,d2         ; On multiplie d2 par 2^1, soit 2 
    	sub        d2,d1         ; On soustrait d1*32 et d2*2, en factorisant on a d1*(32-2) d'ou d1*30 ! 

    	move.l    d0,d2         ; On copie d0 dans d2 
    	lsr           #3,d0         ; On divise d0 par 2^3 soit 8 
    	and         #7,d2         ; l'instruction AND permet grâce à un miracle de la nature d'obtenir le reste de d2/8 

    	add        d0,d1          ; Ajout du reste à d1 
    	add         #1,d1 
    	add         d1,a1          ; Ajout du total à a1 

    	move.b   #8,d3 
    	sub         d2,d3 
    	move.w  #7,d1 

boucle: 
    clr.w d0 ; efface le contenu de d0 (pour plus tard) 
    move.b (a0)+,d0 ; copie une ligne du sprite (a0 contient l'adresse du sprite) 
    lsl.w d3,d0 ; décale cette ligne de quelques pixels (en fonction de la coordonnée x d'affichage) 
    move.w d0,(a1) ; copie le sprite en mémoire vidéo (comme on copie un word, il fallait que d0.w soit "vierge") 
    add #30,a1 ; on pointe sur la ligne suivante de l'écran
    dbra        d1,boucle 




	
                move.l	ngetchx*4(a5),a0 	; on attend l'appui sur une touche
	jsr	(a0)
	
	
	pea.l	3840
	move.l	d4,-(a7)		 ;source: adresse du bloc alloué 
	pea.l	$4c00 			;destination: adresse de l'écran 
	move.l	memcpy*4(a5),a0 
	jsr	(a0)			;restaure l'écran 
	addq.l	#8,a7 
	move.l	d4,(a7) 
	move.l	HeapFreePtr*4(a5),a0 
	jsr	(a0)			;libère le bloc alloué 
 
 
nomem: 
	addq.l	#4,a7 			;nettoie la pile 
	movem.l	(a7)+,d0-d4/a0-a5		;restaure d0-d4 et a5 
	rts
	
	
	
croix:                         ; Placer les données en fin de programme avec les autres variables. 
    dc.b %00000000 
    dc.b %00000000 
    dc.b %00000000 
    dc.b %00011000 
    dc.b %10011001 
    dc.b %10100101 
    dc.b %11111111 
    dc.b %11000011

Tu n'initialises pas d0 et d1 ?
Mais je te répète que la calcul de l'adresse de destination (a1) est incorrect et a une chance sur deux de produire un défaut d'adresse.

lea croix,a0 ; Il semblerait que le compilateur rajoute le (PC) automatiquement...
Ca me parait bizarre. Mes souvenirs sur ce genre de détails sont vieux, mais je pense pas que le code généré soit le même avec et sans (pc).
Dans un cas il doit générer un adressage relatif, dans l'autre un adressage absolu avec un relogement.

Reste à savoir si l'assembleur fait une optimisation là dessus ou pas. En principe il ne devrait pas (c'est pas son rôle), mais on sait jamais, il se passe de drôle de choses dans la toolchain ces temps ci.

j'vais abandonner je crois, j'y arrive pas !

bah relis le post de Sasume, il a parfaitement raison... enfin dans un premier temps tu peux initialiser d0 et d1 à 10, a priori ça ne devrait pas planter pour ces valeurs précises ^^

et avant l'appel de ScreenClear, il manque un lea 12(a7),a7 pour réajuster la pile



spectras> a priori si... si tu veux absolument un adressage absolu, il faut rajouter un .l ^^

zegoo :
j'vais abandonner je crois, j'y arrive pas !

au début, c'est très lent pour apprendre, mais une fois que tu as les bases, ça va beaucoup plus vite

Merci M.Flanker de m'avoir remotivé, merci M.Pollux pour lea 12(a7),a7 (j'avais pas compris mais c'est quand meme bizarre...) et merci M;Sasume, en effet le bout code que j'ai fait ne fonctionnait que pour x et y codés sur un byte !!!
En tout cas j'ai fait çà car çà me semblait logique, peut etre n'est-ce pas encore correct mais çà a l'air de marcher:

[pre] include "OS.h" xdef _nostub xdef _ti89 xdef _ti92plus movem.l d0-d4/a0-a5,-(a7) ; Sauvegarde des registres d0,d4 et a5 move.l $C8,a5 ; on place la table des rom_call dans le registre a5 pea.l 3840 ;taille à allouer ;(même chose que move.l #3840,-(a7), mais plus optimisé) move.l HeapAllocPtr*4(a5),a0 jsr (a0) ;alloue les 3840 octets move.l a0,d4 ;sauvegarde l'adresse du bloc alloué en d4 beq nomem ;si le pointeur est nul, quitte le programme pea.l $4c00 ;source: adresse de l'écran move.l d4,-(a7) ;destination: adresse du bloc alloué move.l memcpy*4(a5),a0 jsr (a0) ;sauvegarde l'écran lea 12(a7),a7 ;nettoyage de la pile move.l ScreenClear*4(a5),a0 ; on efface l'écran jsr (a0) move.l #25,d0 move.l #35,d1 lea croix,a0 ; Il semblerait que le compilateur rajoute le (PC) automatiquement... move.l #LCD_MEM,a1 ; Mémoire de la vidéo move.l d1,d2 ; d1 et d2 contiennent la même valeur lsl.l #5,d1 ; On multiplie d1 par 2^5, soit 32 lsl.l #1,d2 ; On multiplie d2 par 2^1, soit 2 sub d2,d1 ; On soustrait d1*32 et d2*2, en factorisant on a d1*(32-2) d'ou d1*30 ! move.l d0,d2 ; On copie d0 dans d2 lsr #3,d0 ; On divise d0 par 2^3 soit 8 and #7,d2 ; l'instruction AND permet grâce à un miracle de la nature d'obtenir le reste de d2/8 add d0,d1 ; Ajout du reste à d1 add #1,d1 add d1,a1 ; Ajout du total à a1 move.b #8,d3 sub d2,d3 move.w #7,d1 boucle: clr.l d0 ;clr.w d0 ; efface le contenu de d0 (pour plus tard) move.b (a0)+,d0 ; copie une ligne du sprite (a0 contient l'adresse du sprite) lsl.l d3,d0 ;lsl.w d3,d0 ; décale cette ligne de quelques pixels (en fonction de la coordonnée x d'affichage) move.l d0,(a1) ;move.w d0,(a1) ; copie le sprite en mémoire vidéo (comme on copie un word, il fallait que d0.w soit "vierge") add #30,a1 ; on pointe sur la ligne suivante de l'écran dbra d1,boucle move.l ngetchx*4(a5),a0 ; on attend l'appui sur une touche jsr (a0) pea.l 3840 move.l d4,-(a7) ;source: adresse du bloc alloué pea.l $4c00 ;destination: adresse de l'écran move.l memcpy*4(a5),a0 jsr (a0) ;restaure l'écran addq.l #8,a7 move.l d4,(a7) move.l HeapFreePtr*4(a5),a0 jsr (a0) ;libère le bloc alloué nomem: addq.l #4,a7 ;nettoie la pile movem.l (a7)+,d0-d4/a0-a5 ;restaure d0-d4 et a5 rts croix: ; Placer les données en fin de programme avec les autres variables. dc.b %00000000 dc.b %00000000 dc.b %00011000 dc.b %00011000 dc.b %10011001 dc.b %10100101 dc.b %11111111 dc.b %11011011 /[pre

j'ai du me gourer pour les balises, dsl !!

(ça me fait toujours rire les M. )

Il est bon là ce bout d'code ?

move.l d1,d2 ; d1 et d2 contiennent la même valeur
lsl.l #5,d1 ; On multiplie d1 par 2^5, soit 32
lsl.l #1,d2 ; On multiplie d2 par 2^1, soit 2
sub d2,d1 ; On soustrait d1*32 et d2*2, en factorisant on a d1*(32-2) d'ou d1*30 ! 

c'est juste évidemment, mais un mulu #30,d1 aurait été plus clair (un poil plus lent, mais ici c'est pas très important, il vaut mieux avoir une source plus lisible)

tu as un bouton Editer quand tu te plantes dans un post ^^

add d0,d1 ; Ajout du reste à d1
add #1,d1
add d1,a1 ; Ajout du total à a1 

j'ai un peu du mal à comprendre ces lignes

est-ce que tu as fait un schéma ? j'avais fait mes propres routines d'affichage de caractères, et j'avais pas mal lutté pour plein de petits problèmes de ce genre

plutôt qu'une division par 8, j'aurai plutôt fait une division de x par 16 puis multiplier par 2, histoire d'être sûr d'avoir une adresse paire (et joué avec un AND #%1111,d2 au lieu de AND #%111,d2)

Tu devrait le mettre le "croix(pc)" on sait jamais...et evite de compter sur le compilateur pour te "corriger" les fautes eventuelles de ton code ^^
Pour ca refere toi au A68kGuide pour connaitre la synthaxe exacte des instructions.
C'est toujours mieux que de laisser le compilo faire un choix arbitraire
Et perd pas courage, ca vaut le coup, crois moi

je crois que c'est pas la peine d'embêter zegoo avec les machin(pc) vs machin.l pour l'instant :/

zegoo :
Il est bon là ce bout d'code ?

Il commence à devenir gros là, c'est minutieux pour nous de vérifier...
Il y a toujours le pb du calcul de l'offset de l'adresse de destination, comme te l'a fait remarquer Flanker (M. Flanker, pardon).
Essaie-toi à d'autres routines maintenant, pour approfondir tes connaissances et t'amuser un peu plus. Tu verras, au final c'est assez rigolo l'ASM quand tu commences à connaître bien. Tu maîtriseras les limites de la machine, tu trouveras 50 façons de faire la même chose mais différemment, avec chacune ayant ses avantages inconvénients...
Surtout, ne néglige pas le temps de lire les tutos ou documentations. C'est pas le plus marrant, mais t'es obligé de passer par là.

Pollux> nan faut pas l'embeter, faut juste lui dire de l'écrire correctement. On lui demande pas de comprendre la différence.

spectras :
On lui demande pas de comprendre la différence.

ben moi je dirais que si, au contraire