Émulateur de GameBoy pour TI - Page 12

1000000 fois plus clair !

Bon déjà à 1è vue, indépendamment du reste :

	move.w	0(atmp1,tmp2.w),tmpf
	move.w	0(apc,tmp2.w),flags
	addq.b	#2,tmp2
	andi.b	#$1f,tmp2

=>

	move.w	(atmp1)+,tmpf
	move.w	(atmp2)+,flags

et tu déroules ta boucle 32 fois... si ça te fais peur, tu peux la dérouler 8 ou 16 fois en incluant un test au début de la boucle pour voir si tmp2%32=0

Ensuite je viens de regarder le fonctionnement ; 1è version optimisée (j'abandonne tes noms horribles) :

 move.l (a0)+,d0
 move.l (a1)+,d1
 lsr.l count,d0       ; on n'utilise jamais asl mais lsl, surtout quand on ne fait pas d'arithmétique
 lsr.l count,d1
 move.w d0,(a2)+
 move.w d0,(a3)+
 move.l -2(a0)d0
 move.l -2(a1),d1
 lsr.l count,d0
 lsr.l count,d1
 move.w d0,(a2)+
 move.w d0,(a3)+

Et on peut encore faire la chasse aux valeurs immédiates :

 move.l (a0)+,d0
 move.l (a1)+,d1
 lsr.l count,d0
 lsr.l count,d1
 move.w d0,(a2)+
 move.w d0,(a3)+
 move.l (a4)+,d0
 move.l (a5)+,d1
 lsr.l count,d0
 lsr.l count,d1
 move.w d0,(a2)+
 move.w d0,(a3)+

avec a4=a0+2, a5=a1+2

boogerman : je suis en train de bosser ta routine, et à moins que je me trompe elle est très optimisable !!

regarde quand même mon post Thibaut

Non j'ai pas trop regardé. J'optimise de mon côté. Après on fera une mise en commun

>Pollux: Ca me rappelle vaguement un truc.

En gros ce qu'il me faut c'est la facon la plus rapide pour copier un buffer dans un autre en faissant un decallage. Cette routine est tres importante car il y a pas mal de jeux qui changent SCY plusieures fois par frame (par ex, pour creer l'effet d'un background multi layer ou chaque layer se deplace a une vitesse differente). A chaque fois que le jeu modifie SCY, il me faut refaire le decallage et a partir de cette ligne montrer le background decalle avec la nouvelle valeur. Donc vaut mieux faire vite...

Bon j'ai en principe remplacé par celle-ci...
Elle ressemble très peu à l'originale. Quant aux optimizations:
- la mémoire se copie par longwords (au lieu de words), ce qui réduit le nombre d'access
- si le décallage est > 16, on fait décallage vers la droite
- au lieu de faire de faire des tests de wraparound dans le main loop, on les fait avant et on modifie le code

Pour les cycles, le main loop (celui qui se repète 144 fois, donc le plus important), avant faisait:
[116,176]*10=[1160,1760] (selon le nombre de décallages éffectués)
maintenant, il fait:
[114,174]*5=[456,870] (selon le nombre de décallages effectués vers la droite)
[130,190]*5=[650,950] (selon le nombre de décallages effectués vers la gauche)

Ce qui fait carrément la moitié. Quelqu'un peut mieux faire?

Et pas moins important, on dirait que ça marche .

	movem.l	d0-d7/a0-a6,-(a7)

	;copy the visible portion of the background to the lcd

	lea	bg_draw(PC),a1		;used to self-modify the code

	move.l	agblcd0(PC),a6		;(a6)=gblcd0
	move.l	agblcd1(PC),a5			;(a5)=gblcd1

	move.l	abuffs(PC),a3
	lea	buffs_bgbuff0(a3),a2	;(a2)=bgbuff0
	lea	buffs_bgbuff1(a3),a3	;(a3)=bgbuff1

	clr.w	d5			;d7=number to shift left
	move.b	scx(a4),d5
	move.w	d5,d7
	andi.b	#$1f,d7
	cmp.b	#16,d7		;if(d7>=16) faster to rotate right
	bpl	r

;scx		c1nc	c2nc	scx/32	scx/32*4
;-----------------------------------------------
;[224,256)	-1	4	7	28
;[192,224)	0	3	6	24
;[160,192)	1	2	5	20
;[128,160)	2	1	4	16
;[96,128)	3	0	3	12
;[64,96)	4	-1	2	8
;[32,64)	4	-1	1	4
;[0,32)		4	-1	0	0

	lsr.b	#5,d5			;add to a2 and a3 the offset of
	move.w	d5,d0		;the 1st column to copy
	lsl.b	#2,d5
	add.w	d5,a2
	add.w	d5,a3

	subq.w	#2,d0			;patch ncycles after X wraparound
	bpl	lpl
	clr.w	d0
lpl	subq.w	#1,d0
	move.b	d0,lc2nc+1-bg_draw(a1)

	subq.w	#3,d0			;patch ncycles before X wraparound
	neg.w	d0
	move.b	d0,lc1nc+1-bg_draw(a1)

	move.w	#$ffff,d2		;d2=mask and d3=~mask
	lsl.w	d7,d2
	move.w	d2,d3
	not.w	d3

	clr.w	d5			;add to a2 and a3 the offset of
	move.b	scy(a4),d5		;the 1st line to copy
	move.w	d5,d6
	asl.w	#5,d5
	add.w	d5,a2
	add.w	d5,a3

	move.w	#144-1,d1		;d1=nlines before Y wraparound
	cmpi.w	#112,d6		;  =min(scy+144,256)-scy
	bmi	lally
	move.w	#256-1,d1
	sub.w	d6,d1
lally
	move.w	#144-2,d0		;patch nlines after Y wraparound
	sub.w	d1,d0
	move.w	d0,llnc+2-bg_draw(a1)

llc	move.l	(a2)+,d5
	move.l	(a3)+,d6
	lsl.l	d7,d5
	lsl.l	d7,d6

lc1nc	moveq	#-1,d0			;this number gets patched
	bmi	lc1e

lc1c	move.l	(a2)+,d4		;12		-> [52,82]
	rol.l	d7,d4		;8+[2*0,2*15]
	move.l	d4,a0		;4
	and.w	d3,d4		;4
	or.w	d4,d5		;4
	move.l	d5,(a6)+		;12
	move.l	a0,d5		;4
	and.w	d2,d5		;4
	move.l	(a3)+,d4
	rol.l	d7,d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d6
	move.l	d6,(a5)+
	move.l	a0,d6
	and.w	d2,d6

	dbra.w	d0,lc1c

lc1e	lea	-32(a2),a2
	lea	-32(a3),a3

lc2nc	moveq	#-1,d0			;this number gets patched
	bmi	lc2e

lc2c	move.l	(a2)+,d4
	rol.l	d7,d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d5
	move.l	d5,(a6)+
	move.l	a0,d5
	and.w	d2,d5

	move.l	(a3)+,d4
	rol.l	d7,d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d6
	move.l	d6,(a5)+
	move.l	a0,d6
	and.w	d2,d6

	dbra.w	d0,lc2c

lc2e	lea	40(a2),a2
	lea	40(a3),a3

	dbra.w	d1,llc

	lea	-32*256(a2),a2	;wraparound and continue
	lea	-32*256(a3),a3

llnc	move.w	#-1,d1			;this number gets patched
	bmi	lle

	move.w	#-1,llnc+2-bg_draw(a1)	;prevent any further loops
	bra	llc

lle
lret	movem.l	(a7)+,d0-d7/a0-a6
	rts

;scx		c1nc	c2nc	(scx+160)/32+1	(scx+160)/32*4
;-------------------------------------------------------------
;[224,256)	3	0	5			20
;[192,224)	2	1	4			16
;[160,192)	1	2	3			12
;[128,160)	0	3	2			8
;[96,128)	-1	4	1			4
;[64,96)	4	-1	8			32
;[32,64)	4	-1	7			28
;[0,32)		4	-1	6			24
;
;c1nc=max(6,(scx+160)/32+1)-2
;c2nc=3-c1nc

r	lea	160*144/8(a6),a6
	lea	160*144/8(a5),a5

	sub.b	#32,d7		;d7=number to shift right
	neg.b	d7

	add.b	#160,d5		;add to a2 and a3 the offset of
	lsr.b	#5,d5			;the last column to copy + 1
	addq.b	#1,d5
	move.w	d5,d0
	lsl.b	#2,d5
	add.w	d5,a2
	add.w	d5,a3

	cmp.w	#6,d0			;patch ncycles before X wraparound
	bmi	rmi
	moveq	#6,d0
rmi	subq.w	#2,d0
	move.b	d0,rc1nc+1-bg_draw(a1)

	subq.w	#3,d0			;patch ncycles after X wraparound
	neg.w	d0
	move.b	d0,rc2nc+1-bg_draw(a1)

	move.w	#$ffffffff,d2	;d2=mask and d3=~mask
	lsr.w	d7,d2
	move.w	d2,d3
	not.w	d3

	clr.w	d5			;add to a2 and a3 the offset of
	move.b	scy(a4),d5		;the last line to copy
	add.b	#144-1,d5
	move.w	d5,d1
	asl.w	#5,d5
	add.w	d5,a2
	add.w	d5,a3

	cmpi.w	#144-1,d1		;d1=nlines before Y wraparound
	bmi	rally			;  =min(scy+144-1,144-1)
	move.w	#144-1,d1
rally
	move.w	#144-2,d0		;patch nlines after Y wraparound
	sub.w	d1,d0
	move.w	d0,rlnc+2-bg_draw(a1)

rlc	move.l	-(a2),d5
	move.l	-(a3),d6
	lsr.l	d7,d5
	lsr.l	d7,d6
	swap	d5
	swap	d6

rc1nc	moveq	#-1,d0			;this number gets patched
	bmi	rc1e

rc1c	move.l	-(a2),d4		;12		-> [60,90]
	ror.l	d7,d4		;8+[2*0,2*15]
	swap	d4			;4
	move.l	d4,a0		;4
	and.w	d3,d4		;4
	or.w	d4,d5		;4
	swap	d5			;4
	move.l	d5,-(a6)		;12
	move.l	a0,d5		;4
	and.w	d2,d5		;4
	move.l	-(a3),d4
	ror.l	d7,d4
	swap	d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d6
	swap	d6
	move.l	d6,-(a5)
	move.l	a0,d6
	and.w	d2,d6

	dbra.w	d0,rc1c

rc1e	lea	32(a2),a2
	lea	32(a3),a3

rc2nc	moveq	#-1,d0			;this number gets patched
	bmi	rc2e

rc2c	move.l	-(a2),d4
	ror.l	d7,d4
	swap	d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d5
	swap	d5
	move.l	d5,-(a6)
	move.l	a0,d5
	and.w	d2,d5
	move.l	-(a3),d4
	ror.l	d7,d4
	swap	d4
	move.l	d4,a0
	and.w	d3,d4
	or.w	d4,d6
	swap	d6
	move.l	d6,-(a5)
	move.l	a0,d6
	and.w	d2,d6

	dbra.w	d0,rc2c

rc2e	lea	-40(a2),a2
	lea	-40(a3),a3

	dbra.w	d1,rlc

	lea	32*256(a2),a2	;wraparound and continue
	lea	32*256(a3),a3

rlnc	move.w	#-1,d1			;this number gets patched
	bmi	rle

	move.w	#-1,rlnc+2-bg_draw(a1)	;prevent any further loops
	bra	rlc

rle
rret	movem.l	(a7)+,d0-d7/a0-a6
	rts

Ah, ce que je donnerais pour un MMU...

Serait-ce possible d'acheter un M68xxx qui ait un MMU et l'insérer dans la TI?

Si c'est possible je t'envoie ma TI et tu me prépares ça

Malheureusement c possible.... mais uniquement dans nos reves...

godzil a écrit :
Malheureusement c possible.... mais uniquement dans nos reves...

Au niveau SW, les nouvelles versions du 68K devraient rester compatibles (je pense).
Niveau HW, c'est plus si evident que ça...

Éh ben va falloir chercher autre chose. Je suis en train de lire des papers sur dynamic recompilation. C'est vraiment trop trop fort. Je conseille fortement à ceux qui sont intéresés de lire le pdf qui se trouve sur http://www.davidsharp.com/tarmac/index.html.

boogerman
a écrit : Au niveau SW, les nouvelles versions du 68K devraient rester compatibles (je pense).

Non. TI utilise les vecteurs d'émulation des lignes 1010 (A) et 1111 (F) pour autre chose que ce que font les instructions en 1010 et 1111 intégrés dans les 68K supérieurs.

09/01/2002 - v0.4.1

Partial support for the DAA inst (should get a bunch of games on the move) and
some fixes/optimizations.

- Optimizations in lcd.asm:
- palcv: 'move.l #0,ea' -> 'clr.l ea'.
- bg_rld: -147500 cycles per background reload (35% faster).
- bg_draw: -109000 cycles per background draw (100% faster).
- Fixed non local label in macro fC2X in tigb.asm.
- Added support for the DAA inst when it is preceeded by 'adc (HL)', 'adc r8',
'adc v8', 'add (HL)', 'add r8', 'add v8', 'cp (HL)', 'cp r8', 'cp v8',
'dec a', 'inc a', 'sbc (hl)', 'sbc r8', 'sbc v8', 'sub (hl)', 'sub r8',
'sub v8'. As a consequence, the mentioned insts have a 20 cycle slowdown
(24 for 'add v8', cp 'v8' and 'sub v8') when not followed by DAA.
- Reduced by 8 cycles writes to the internal RAM and to it's ghost.
- *Hopefully* fixed a HW1 incompatibility created by last version's faster ROM
bank switching (now when HW1 is detected the memcpy is made via move.l's
instead of movem.l's).
- Removed the unused HFLAG compile time option from defs.h.

Bon je pense qu'a partir de maintenant (si j'ai assez de temps, bien sûr) je vais essayer de faire une implementation de dynamic recompilation. Cette méthode bouffe beacoup de RAM, donc il va faloir libérer autant que possible. À la base, on a ~180k. Le binaire de TIGB fait ~50k, et lorsqu'il démarre il bouffe 100k. En gros, il restent 30k libres et je pense que ce ne sera pas assez (la performance gagné est directement proportionelle à la quantité de RAM utilisée).

Donc en gros, j'aimerais savoir si c'est possible d'éxecuter du code directement depuis la ROM. Si oui, est-ce que ça va aussi vite que la RAM?

boogerman a écrit :
- *Hopefully* fixed a HW1 incompatibility created by last version's faster ROM
bank switching (now when HW1 is detected the memcpy is made via move.l's instead of movem.l's).

Je n'ai pas testé, mais je me permets de dire que oui, éliminer les movem résout les problèmes. Reste à savoir pourquoi tu n'utilises pas le ROM_CALL... Contrairement à la plupart des ROM_CALLs, memcpy est rapide! Et il n'utilise pas de movem, juste des boucles déroulées de move.l, donc il marche correctement sur HW1.

boogerman
a écrit : Donc en gros, j'aimerais savoir si c'est possible d'éxecuter du code directement depuis la ROM.

Non, à moins de la déprotéger contre l'exécution (ce qui est très compliqué et relativement dangereux: c'est protégé par la même protection que l'écriture en FlashROM).
D'ailleurs, le problème des movem sur HW1 est dû au fait que leur protection anti-exécution stupide ne sait pas faire la différence entre l'exécution en FlashROM et la lecture en FlashROM par movem.

Si oui, est-ce que ça va aussi vite que la RAM?

Non.

Kevin Kofler a écrit :
memcpy est rapide! Et il n'utilise pas de movem, juste des boucles déroulées de move.l, donc il marche correctement sur HW1.

Certes, mais lorsque je detecte HW2 je fais movem.l et je gagne en vitesse, voilà pourquoi je n'utilise pas memcpy.

Non, à moins de la déprotéger contre l'exécution (ce qui est très compliqué et relativement dangereux: c'est protégé par la même protection que l'écriture en FlashROM).

Donc 'va falloir s'arranger avec peu de RAM...
Vraiment 180k c'est pas beacoup...

Que c'est beau la recompilation dynamique. Reste à savoir si le gain de vitesse sera suffisant....

Je pense que j'aurai une version préliminaire d'ici peu (si la fac me laisse assez de temps)...

En tout cas, avez vous gouté à la dernière version? Cette histoire du DAA devrait faire marcher pas mal de jeux (par ex, mario land 1 et 2)...
Et puis j'ai pas mal accéléré lcd.asm, donc ça devrait aller un peu plus vite.

Qu'en pensez vous?

on peut downloader où??

là : http://www.boogersoft.com/projects/tigb

et le lien pour les roms pré-compilés pour TI ?

C'est dans le zip.

Mais non mais non. Pas de roms précompilés pour TI ni de lien dans mon ZIP.

En gros, pour convertir les ROMs il vous faut:

- télecharger tt (http://www.ticalc.org/pub/win/tt.zip)
- copier ttbin2oth.exe dans le classeur /bin du ZIP de TIGB
- ouvrir une fenêtre MS-DOS
- se placer sur bin (ex: cd ti92tigbbin)
- taper 'rom2ti d:gbromsmario.gb 92' (ou 89 si c'est une TI-89)

Voilà cela crée les fichiers romx.9xz/89z que vous pouves uploader dans la calc

C clair?

j'ai testémario1, il amrche maintenant
par contre par rapport à la vitesse des anciennes versions jepeux pas te dire, c'est la première fosi que je le fais tourner pour de vrai
en tout cas bravo

boogerman a écrit :
En gros, pour convertir les ROMs il vous faut:

- télecharger tt (http://www.ticalc.org/pub/win/tt.zip)
- copier ttbin2oth.exe dans le classeur /bin du ZIP de TIGB
- ouvrir une fenêtre MS-DOS
- se placer sur bin (ex: cd ti92tigbbin)
- taper 'rom2ti d:gbromsmario.gb 92' (ou 89 si c'est une TI-89)

Voilà cela crée les fichiers romx.9xz/89z que vous pouves uploader dans la calc
C clair?

OK, j'avais fait tout ce que tu as dit, mis à part rajouter 92 ou 89 pour compiler pour 92 ou 89. Merci.

Que se passe-t-il exactement, lors de la conversion gb->TI ? Tu ne changes rien ou bien tu changes quand même qq trucs ?

jackiechan a écrit :
OK, j'avais fait tout ce que tu as dit, mis à part rajouter 92 ou 89 pour compiler pour 92 ou 89. Merci.
Que se passe-t-il exactement, lors de la conversion gb->TI ? Tu ne changes rien ou bien tu changes quand même qq trucs ?

Je coupe le rom en plusieurs fichiers (parce que la TI n'admet pas des fichiers >65ko) et puis je fais ttbin2oth qui met un .bin en format TI.

alors, j'ai testé:
sur VTI ça marche mais c'est vrai que c'est leenntt
sur ma HW 2 AMS 2.08 PeOS 0.54b
ça foire:
ça cleane l'ecran, ça remet l'écran home avec busy allumé,ça cleane l'ecran, ça remet l'écran home avec busy allumé,ça cleane l'ecran, ça remet l'écran home avec busy allumé,...

boogerman
a écrit : Je coupe le rom en plusieurs fichiers (parce que la TI n'admet pas des fichiers >65ko) et puis je fais ttbin2oth qui met un .bin en format TI.

Et tu ne pourrais pas "tricher" un peu, pour accélerer l'émulation. c-a-d modifier le fichier quand tu le convertis en fichier TI de façon à ce que ça te simplifie l'émulation (je m'y connais pas du tout, si ça trouve, c'est impossible....) ??

jackiechan
a écrit : Et tu ne pourrais pas "tricher" un peu, pour accélerer l'émulation. c-a-d modifier le fichier quand tu le convertis en fichier TI de façon à ce que ça te simplifie l'émulation (je m'y connais pas du tout, si ça trouve, c'est impossible....) ??

Ce dont tu parles s'appelle recompilation, et consiste à analyser le code, l'optimiser et le recompiler. Mais la recompilation statique (c.à.d., avant d'éxecuter le ROM) est pour le moins impratiquable dans le GameBoy (car c'est pas possible de séparer statiquement le code des données, ni de recompiler le self-modifying code).

Je suis en train de travailler dans un moteur de récompilation dynamique, qui fait la récompilation en temps d'éxécution et s'il trouve des problèmes ou des évenements telles les interruptions, il retombe sur l'interpreteur. Je pense que d'ici peu j'aurai une version préliminaire, mais j'ai pas mal d'examens ce mois-ci, donc je peux rien garantir.

Bon, je viens de tester sur vti (avec Kirby), et j'ai l'impression que lorsqu'on laisse une touche longtemps appuyée, ça bloque l'écran (il se fige, mais le jeu continue de tourner), il suffit qu'on la relache pour que l'écran s'affiche à nouveau..
Enfin, si ça se trouve tu le précise dans ton readme, mais j'avoue que je ne l'ai pas lu en entier...

Je viens de réessayer avec é autres jeux (motocross et castlevania2), mais ça ne marche pas... quand je lance tigb, l'écran s'efface, mais il n'affiche rien et plus rien de répond).