Émulateur de GameBoy pour TI - Page 11

santi
a écrit : je sais pas duquel parle orion, mais moi j'ai testé avec le mario que j'ai trouvé sur le site de redangel17 (page 6 de ce topic).

J'ai téléchargé mario sur le site de Redangel17, et ça plante à cause d'un DAA (faitez-en un breakpoint à l'addresse 5861 pour le verifier: ça tombe sur un DAA et lorsque vous appuyez 'i' ça plante). Z'estez sûrs qu'il plantait pas avant (si vous regardez dans le source DAA est un ibad qui fait un setdeinit, et cela depuis la première version de l'émulateur)?

En tout cas, z'en faitez pas de problème car je suis déjà en train de m'occuper du DAA. Au lieu d'émuler le flag H, lorsque je retrouve un DAA je regarde quelle a été la dernière opération et je la refais en tennant compte du flag H.

À +

Thibaut a écrit :
Je ne sais pas si A68k optimise tout seul, mais j'écrirais plutôt move.l ($c8).w,a0 : on gagne 2 octets et de la vitesse.

A68k et GNU as ne sont pas bêtes, donc il optimisent ça.

guigui17 a écrit :
Pour te répondre Thibaut, OUI, A68k optimise ceci contrairement à AS

Ne t'attends pas trop d'un assembleur on-calc, d'autant plus qu'il est en version 0.xx.

boogerman
a écrit : En plus, les données d'origine ne sont pas forcément alignées à mot (ce qui nous force à copier octet à octet)

Utilise le ROM_CALL memcpy. Il s'occupe automatiquement de recopier les données en des boucles rapides même si elles ne sont pas alignés (il copie le premier octet à part si l'adresse est impaire, puis fait une copie long par long - avec une boucle bien déroulée en plus).

Kevin Kofler a écrit :
Utilise le ROM_CALL memcpy. Il s'occupe automatiquement de recopier les données en des boucles rapides même si elles ne sont pas alignés (il copie le premier octet à part si l'adresse est impaire, puis fait une copie long par long - avec une boucle bien déroulée en plus).

De toutes façons c'est déjà fixé. J'ai fait des fichiers de 56ko et je copie avec des movems.l comme dans gray.s. Vu que la copie est de 16ko on gagne beacoup beacoup de cycles (je pense pas que memcpy pourrait faire mieux :^)

Quelqu'un sait quelle est la méthode la plus rapide pour copier d'un buffer à un autre en faisant un asl/asr du contenu?

> Ne t'attends pas trop d'un assembleur on-calc, d'autant plus qu'il est en version 0.xx.
GTC le fait

> J'ai fait des fichiers de 56ko et je copie avec des movems.l comme dans gray.s.
C pas compatible HW1 ça
En plus le gain est de moins de 20%...

> Quelqu'un sait quelle est la méthode la plus rapide pour copier d'un buffer à un autre en faisant un asl/asr du contenu?
tu veux faire quoi précisément? un scroll d'écran?

Pollux a écrit :
C pas compatible HW1 ça En plus le gain est de moins de 20%...

Ah bon? Mais l'instruction movem existe dans HW1 aussi... pourquoi c'est pas compatible? (en tout cas, 20% c'est 20% quand un jeu échange les rom banks plus de 25 fois par seconde ça se voit la différence).

tu veux faire quoi précisément? un scroll d'écran?

Ouai je veux faire un scroll d'écran. Je le fais déjà mais je trouve que c lent...

> Ah bon? Mais l'instruction movem existe dans HW1 aussi... pourquoi c'est pas compatible? (en tout cas, 20% c'est 20% quand un jeu échange les rom banks plus de 25 fois par seconde ça se voit la différence).

La mém archive des HW1 a une protection anti-exécution qui fait planter la caltos s'il y a 3 lectures consécutives dans l'archive, ce qui n'arrive donc qu'avec movem...

> Ouai je veux faire un scroll d'écran. Je le fais déjà mais je trouve que c lent...
T'es sûr qu'il vaut mieux pas tout redessiner à chaque fois?
Sinon si tu tiens à ton scroll regarde GX_HorizontalScroll dans GraphX (cf signature de thibaut)

Pollux
a écrit : La mém archive des HW1 a une protection anti-exécution qui fait planter la caltos s'il y a 3 lectures consécutives dans l'archive, ce qui n'arrive donc qu'avec movem...

mais ils font chier avec leurs protections
bon je vais mettre cela come compile time option pour ceux qui ont une HW2
merci du renseignement

> Ouai je veux faire un scroll d'écran. Je le fais déjà mais je trouve que c lent...
T'es sûr qu'il vaut mieux pas tout redessiner à chaque fois?
Sinon si tu tiens à ton scroll regarde GX_HorizontalScroll dans GraphX (cf signature de thibaut)[/cite]

eh ben c'est pour redessiner. sur le GB le background consiste en 32x32 sprites de 8x8, mais comme l'écran est + petit que cela (160x144) il utilise scx et scy (scroll x et scroll y) pour dire quelle partie du background est visible. Selon la valeur du scx, il faut faire un asl/asr. Je vais jetter un coup d'oeil sur GraphX.

Eh ben, la fonction GX_HorizontalScroll telle quelle ne me sert pas à grand chose vu qu'elle travaille sur des structures de GraphX.

Le source m'arrangerait bien pour voir si c'est plus rapide que le mien, mais j pas trouvé...

ah oui c chiant les sprites de 8x8

Pollux a écrit :
ah oui c chiant les sprites de 8x8

Mais non mais non ça passe pas par la taille de sprits vu qu'en fin de comptes le tout finit dans un buffer de 256*256 pixels. Le problème c'est de scroller ce buffer vite fait...

oui, avec ta méthode... mais avec des 16x16 on peut utiliser des méthodes plus rapides que la tienne...

Pollux
a écrit : oui, avec ta méthode... mais avec des 16x16 on peut utiliser des méthodes plus rapides que la tienne...

Peux tu expliquer cela avec plus de détail?

boogerman : je garde mes sources, sinon TiMad pourrait les copier !!! oh làlà

Poste ta routine de scroll, je te dirai comment elle se situe par rapport à la mienne

Thibaut a écrit :
boogerman : je garde mes sources, sinon TiMad pourrait les copier !!! oh làlà

Poste ta routine de scroll, je te dirai comment elle se situe par rapport à la mienne

	;copy the visible portion of the background to the lcd

	clr.w	tmp1
	move.b	scy(aio),tmp1
	lsl.w	#5,tmp1

	clr.w	tmp2
	move.l	agblcd0(PC),atmp2
	move.l	agblcd1(PC),atmp3

	clr.l	opc
	move.w	#144-1,cc

cyc	move.l	abuffs(PC),apc
	lea	buffs_bgbuff0(apc),atmp1
	lea	buffs_bgbuff1(apc),apc
	adda.w	tmp1,atmp1
	adda.w	tmp1,apc

	move.b	scx(aio),tmp2
	lsr.b	#3,tmp2
	andi.b	#$fe,tmp2

	move.b	scx(aio),opc
	andi.b	#$0f,opc

	move.w	0(atmp1,tmp2.w),tmpf	;this block repeats itself 10 times
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2
	swap	tmpf
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf
	asl.l	opc,flags
	swap	tmpf
	swap	flags
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

	add.w	#32,tmp1
	andi.w	#$1FFF,tmp1

	dbra.w	cc,cyc

	rts

les

	addq.b	#2,tmp2
	andi.b	#$1f,tmp2

c'est parce que le background "wraps around" (on dit comment?) l'écran

boogerman a écrit :
les

	addq.b	#2,tmp2
	andi.b	#$1f,tmp2

c'est parce que le background "wraps around" (on dit comment?) l'écran

c.à.d. lorsqu'une partie de l'écran sort du background elle apparait de l'autre coté

Encore une remarque: chaque cycle est une ligne que l'on copie du background buffer (buffs_bgbuff) au LCD (agblcd). Le background buffer fait 256*256 pixels et le GB LCD fait 160x144 pixels. SCX et SCY donnent la position du background

Wouaaa c'est chaud comme code

Dis, il est sensé scoller de how may many pixel your code ?

Thibaut a écrit :
Wouaaa c'est chaud comme code
Dis, il est sensé scoller de how may many pixel your code ?

Tant que ca ?

Eh ben ça scrolle verticalement de scy(aio) et horizontalement de scx(aio)

Et ça modifie l'image DANS le buffer ou alors ça copie l'image du buffer vers l'écran, en décallant ?

Thibaut
a écrit : Et ça modifie l'image DANS le buffer ou alors ça copie l'image du buffer vers l'écran, en décallant ?

Ça copie vers l'écran en décallant

Thibaut
a écrit : Et ça modifie l'image DANS le buffer ou alors ça copie l'image du buffer vers l'écran, en décallant ?

Je l'ai un peu commenté pour que ça soit plus clair

	;this repeats 10 times (=20 bytes=160 pixels)

	move.w	0(atmp1,tmp2.w),tmpf	;get from 1st buffer (light buffer)
	move.w	0(apc,tmp2.w),flags	;get from 2nd buffer (dark buffer)
	addq.b	#2,tmp2			;increase buffer index but modulo 32
	andi.b	#$1f,tmp2		;  to wrap around the screen
	swap	tmpf			;get next word from 1st and 2nd buffer
	swap	flags
	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	asl.l	opc,tmpf		;shift
	asl.l	opc,flags
	swap	tmpf			;store in 1st and 2nd LCD (light and
	swap	flags			;  dark LCD)
	move.w	tmpf,(atmp2)+
	move.w	flags,(atmp3)+

Arf j'ai du mal à comprendre ton code.

Ta routine réalise-t-elle le scrolling DANS le buffer, c'est à dire que le contenu du buffer est modifié (scrollé) ?

Thibaut a écrit :
Arf j'ai du mal à comprendre ton code.
Ta routine réalise-t-elle le scrolling DANS le buffer, c'est à dire que le contenu du buffer est modifié (scrollé) ?

Mais non elle lit le buffer, fais le scroll dans les régristres et écrit dans l'écran. Elle ne modifie pas le contenu du buffer vu que ce serait ridicule pour deux motifs:
- le buffer est plus grand que l'écran (l'écran n'en montre qu'une partie), donc on travaillerait en trop
- lorsque SCY/SCX sont modifiées elles sont tj relatives à la position initiale du buffer

OK. Et tu scrolles de 16 en 16, c'est ça ?

Ha non on dirait pas.

Il doit être possible d'optimiser, mais tu as mis des constantes à la place des registres, j'arrive pas à réfléchir.

Thibaut a écrit :
Ha non on dirait pas.
Il doit être possible d'optimiser, mais tu as mis des constantes à la place des registres, j'arrive pas à réfléchir.

Whooops. Bon voilà

	;copy the visible portion of the background to the lcd

	;params: a4=pointeur vers i/o régisters du gameboy (dont scy et scx)

	clr.w	d5
	move.b	scy(a4),d5
	lsl.w	#5,d5

	clr.w	d6
	move.l	agblcd0(PC),a3
	move.l	agblcd1(PC),a6

	clr.l	d0
	move.w	#144-1,d1

cyc	move.l	abuffs(PC),a5
	lea	buffs_bgbuff0(a5),a2
	lea	buffs_bgbuff1(a5),a5
	adda.w	d5,a2
	adda.w	d5,a5

	move.b	scx(a4),d6
	lsr.b	#3,d6
	andi.b	#$fe,d6

	move.b	scx(a4),d0
	andi.b	#$0f,d0

	move.w	0(a2,d6.w),d7	;this block repeats itself 10 times
	move.w	0(a5,d6.w),d2	;
	addq.b	#2,d6		;
	andi.b	#$1f,d6		;
	swap	d7		;
	swap	d2		;
	move.w	0(a2,d6.w),d7	;
	move.w	0(a5,d6.w),d2	;
	asl.l	d0,d7		;
	asl.l	d0,d2		;
	swap	d7		;
	swap	d2		;
	move.w	d7,(a3)+	;
	move.w	d2,(a6)+	;

	;...
	;...	(9 fois la même chose)
	;...

	add.w	#32,d5
	andi.w	#$1FFF,d5

	dbra.w	d1,cyc

	rts

	move.l	agblcd0(PC),a3
	move.l	agblcd1(PC),a6

agblcx sont les addresses des deux (light et dark) gameboy lcds qui font 160*144/8 bytes

cyc	move.l	abuffs(PC),a5
	lea	buffs_bgbuff0(a5),a2
	lea	buffs_bgbuff1(a5),a5

buffs_bgbuffx sont les addresses relatives des background buffers (light et dark) par rapport à abuffs(PC)

C'est plus clair maintennant?