Re: Papi Commando fait de ... L'assembleur 68000 !

[Hpman]

move.w d1, VDPData => 16 cycles
move.w d1, (a0) => 8 cycles

C'est tout :o

[Invité]

Merci.

[Invité]

Voilà j'ai modifié mon code et j'ai dédié 2 registres d'adresse ( a5 & a6 ) au VdpData & VdpCtrl.
C'est vrai que c'est placé dans des zones de boucles, ça optimise !
Merci de vos conseils ... Bon, place au foot, on laisse le cerveau au vestiaire.

[Invité]

move.w d1, VDPData => 16 cycles
move.w d1, (a0) => 8 cycles

C'est tout :o

C'est marant qu'un transfert dans un pointeur soit plus rapide qu'un transfert direct à l'adresse .

[Hpman]

4 cycles de plus par mot à aller chercher sur le bus mémoire, c'est le tarif 

Voir plus si il y a des wait state sur le bus concerné, je sais pas comment c'est gaulé sur MD.

[Invité]

Oui mais le (A0) pointe aussi sur une adresse sur le bus .

[Hpman]

Bah justement la différence c'est que l'adresse est connue puisque dans a0. Avec l'autre instruction le 68k doit aller lire l'adresse de destination avant d'y aller.

L'instruction move.w d1, (a0) fait 1 mot, spécifier l'adresse donne une instruction de 3 mots. Faut bien aller fetch tout ça...

[Invité]

C'est ce qui est génial avec ce topic, ce sont les conseils et informations avisées des experts.
@ Hpman : tu m'as l'air de t'y connaitre. As tu réalisé des jeux ? Démos ? Autres .. ? Et sur quel matos ?

[Hpman]

Je fais une lib pour simplifier le dev sur neogeo, même cpu que la MD donc. Ecrite principalement en asm.

Rien de palpitant, quelques demos techniques pour voir si tout tourne bien comme prévu , ex https://www.youtube.com/watch?v=TGE213yo6F8

[Stef]

@touko> C'est la syntaxe de l'assembleur qui te fait dire ça car en l'occurrence tu écris au même endroit dans les 2 cas, juste que l'adresse est dans un registre dans un cas, et en mémoire de l'autre. Et aller lire l'adresse en memoire ça coûte quelque chose (surtout quand il s'agit d'une adresse 32 bits comme ici).

@Hpman> Y'a pas de wait state sur MD, tu es toujours à 4 cycles par accès mémoire (bon en réalité y'a le z80 qui fonctionne en bus steal sur le bus du 68000 mais ça reste assez négligeable meme quand le z80 fait beaucoup d'accès).

@vetea> oui c'est exactement ça, 8 cycles de gagné dans une boucle ça compte, imagine une boucle que tu fais 100 fois par frame, hop 800 cycles de gagner par frame, c'est déjà ça ;-)

[tfdi]

Vetea : ca va rentrer ... ... et tu finiras par comprendre qu'en fait, l'asm c'est simple malgré les apparences

[Invité]

Bah justement la différence c'est que l'adresse est connue puisque dans a0. Avec l'autre instruction le 68k doit aller lire l'adresse de destination avant d'y aller.

L'instruction move.w d1, (a0) fait 1 mot, spécifier l'adresse donne une instruction de 3 mots. Faut bien aller fetch tout ça...

Ah ok, donc tu n'as plus le calcul de l'adresse,je pensais que ça se faisait à chaque accès, même en indirect .

[tfdi]

Touko:Non, le calcul de l'adresse ne se fait pas si t'utilises un registre d'adresse, c'est l'avantage, ca permet de gagner quelques cycles.

[Hpman]

Ça serait pas franchement le CPU de l'année si utiliser les registres n'allait pas plus vite qu'une mémoire externe 

[Invité]

Non mais j'entends par registres quand tu les utilises comme variables,et que tu travailles directement dedans, mais là pour moi tu pointes sur une adresse hors CPU, même si tu passes par un registre,d'où ma confusion .
Je voyais pas ça comme ça en fait  

@tfdi:

move.w d1, VDPData => 16 cycles
move.w d1, (a0) => 8 cycles

C'est pas quelques cycles là, ça divise carrément /2 (à moins que ce soit plus 12 cycles sur Md et non 16(atari ST ??))

[Stef]

Non c'est bien 16 vs 8, mais c'est logique, le récupération de l'adresse en immédiate demande 2 accès mémoire (2x16 bits), donc 2x4 cycles en plus... la logique 6502 ou tu fonctionnes souvent en immédiate pour aller plus vite est aberrante sur 68000 ou tu 'caches' les valeurs en registre.

[Invité]

Ok, merci pour l'explication, c'est clair maintenant 

[Invité]

Franchement ce topic, c'est de l'or ... Une petite mine d'informations qui rendent mes petits projets presque anecdotiques !
J'ai fait pas mal de lecture et de théorie ce week-end, a potasser un peu le VDP.
Je pense être en mesure a gérer le positionnement des Tiles texte, gérer le Joypad, le scrolling ... Viendra ensuite un point très important : gestion du Vblank & Hblank via un registre spécifique du VDP qui va permettre de tout comptabiliser et de réaliser bon nombres de choses sympathiques.
Bref j'ai de quoi m'amuser pour un bon moment !!

Et quand tout sera rodé, je pars sur une conversion full Asm de Papi Commando Tennis !!

A bientôt.

[65c02]

 
Merci pour ce topic Vetea
Tu montres bien combien, passé un certain cap, c'est simple et fun de coder en assembleur.
On ne pouvait rever d'un meilleur ambassadeur

[Invité]

Bonjour à tous,

Cet après midi, j'ai codé une petite heure en assembleur pour parfaire mes routines de Texte, et aussi, ajouter la possibilité d'afficher mes Pattern la ou je le désire sur un Plan (A/B) choisi.

Voici le résultat :


Dingue non !!

Pour en arriver là, j'ai refondu une bonne partie de ma routine principale de texte .. Mais aussi, avec l'aide de vos conseils, pointer mes 2 adresses VDPDATA & VDPControl Port sur 2 registres d'adresses :

Code:

;///// On stocke nos adresses principales dans les 2 derniers registres d'adresses a5 & a6
 lea VDPControlPort,a5
 lea VDPData,a6
 


Ensuite, rien n'a changé concernant le chargement des Palettes & des Tiles Textes ...

Par contre, voici les nouveautés ( certainement à optimiser, les Cadors de l'assembleur vont se précipiter ... ) que j'ai apporté depuis mon dernier projet !

J'ai d'abord défini mes variables de départ :

Code:

;***** Variables Texte & Gobales *****
Text: dc.b 'PAPI  COMMANDO',0
Text1: dc.b ' AIME GAMOPAT',0
Text2: dc.b ' ET CA, C EST BIEN.'
PrioriteText: ds.b 1         ;Variable de priorité ! 1 Octet réservé.


On va pas se gêner pour dédier un registre d'adresse pour notre variable de priorité texte ...

Code:

lea prioriteText,a2


Ensuite la manière dont je vais déclarer tout le merdier ...

Code:

 ;Routines principales pour afficher mes textes.
 lea text,a0
 ;Init de mes registres de Données principales.
 moveq #0,d1
 moveq #0,d0
 moveq #0,d3

 moveq #10,d1                ;Position Y Tile ( ici Y=13)
 moveq #12,d3                ;Position X Tile ( Ici X=20)
 ;Instruction de Commande ( Priorité, Palette, Tile Mirror Vertical, Tile Mirror Horizontal)
 move.b #0,(a2)              ;Priorité Tile à 0
 moveq #1,d4                 ;Effet texte / Palette ( 0 : ON, 1 : OFF)
 move.w #$0,d2               ;Ici Priorité 0,Palette 2,M.V. non,M.H. non
 bsr WriteText               ;Appel du sous programme d'affichage des Tiles


( Il s'agit du mot : Papi Commando )

Le mot suivant :

Code:

 ;Texte Suivant !
 lea text1,a0
 moveq #0,d1
 moveq #0,d0
 moveq #0,d3
 moveq #13,d1               
 moveq #12,d3 
 move.b #0,(a2)         
 moveq #0,d4                 
 move.w #$2000,d2           
 bsr WriteText


Ici, l'effet Couleur est activé ...

Et le mot final ...

Code:

 ;Texte Suivant !
 lea text2,a0
 moveq #0,d1
 moveq #0,d0
 moveq #0,d3
 moveq #16,d1               
 moveq #10,d3 
 move.b #1,(a2)          
 moveq #1,d4             
 move.w #$8000,d2        
 bsr WriteText


Ici, la priorité Tile est à 1 !

Vous remarquerez qu'à chaque fois j'initialise mes registres de données ... Je ne sais pas si c'est utile dans le cas présent, mais j'imagine dans un projet plus complexe, on peut vite se mélanger les pinceaux en oubliant d'initialiser des registres de données qui sont utilisés de manière différentes à la suite de plusieurs routines ...
Alors je ne sais pas si c'est un bon réflexe, mais je préfère tout initialiser à chaque appel ... A moins qu'il existe un OPCODe permettant de tout faire en une seule ligne ... ( Je crois que MOVEM joue ce rôle .. Il faudra que j'essais. )

Et la, le cœur même de ma routine de gestion de texte :

Code:

;///// Routine d'écriture de Texte /////
WriteText:
 move.l  #WritePlaneA,d0       
 lsl.w #6,d1             ;On multiplie par 64 ( 64 Cells )
 add.w  d3, d1         ;On additionne par Y     
 lsl.w #1,d1             ;On Multiplie par 2
 swap    d1              ;On effectue un swap ...
 add.l d1,d0             ;On l'ajoute à l'adresse du VDP ! 
 move.l d0,(a5)
 moveq #0,d0             ;Init d0
 moveq #0,d1             ;Init d1
 
 CharCopy:
 move.b (a0)+,d0
 Beq.b Fin                   ;Si 0 soit fin de la chaine, alors goto fin !
 move.b d0,d1                ;On copie les 2 premiers bits de d0 dans d1
 subi.b #$20,d1              ;On associe d0 avec le Mapping VRAM ( Soit Contenu d0 - $20)
 add.w d2,d1                 ;On additionne son contenu avec d2, notre Mot de commande VDP.
 move.w d1,(a6)              ;On envoie le bazard au VDP
 moveq #0,d1                 ;Init de d1
 cmp.b #0,d4                 ;On va voir si notre option d'incrémentation de Palette est valide ? 0-O, 1-N
 Beq.b IncPal                ;Si oui, alors allons y !! :)
 bra CharCopy                ;Caractère suivant
 IncPal:                     ;Routine d'incrémentation de Palette pour un effet texte rigolo.
 moveq #0,d3                 ;Init de d3
 add.w #$2000,d2             ;On additionne de $2000 pour passer à la palette suivant.
 swap d2                     ;On permute le contenu de d3 afin de pouvoir lire les 2 premiers Bits.
 cmp.b #0,(a2)               ;On va comparer si la priorté Tile a été activé on non ?
 bne.b ModeP_Pal1
 cmp.b #6,d2                 ;Si c'est égal à 6 (Palette 3) ?
 ModeP_Pal1:
 cmp.b #$0E,d2               ;Si c'est égal à 0E (Palette 3 en priorité 1) ?
 swap d2                     ;On retrouve notre Mot de commande VDP !
 Beq.s DecPal                ;On va aller à la routine d'initialisation de Palette
 bra  CharCopy               ;Caractère suivant
 DecPal:                     ;Routine d'initialisation de Palette.
 cmp.b #0,(a2)               ;On va comparer si la priorté Tile a été activé on non ?
 bne.b DecPal1
 move.b #0,d2                ;On initialise nos 2 premiers Bits ( No Palette)
 DecPal1:
 move.b #80,d2                ;On initialise nos 2 premiers Bits ( No Palette)
 swap d2                     ;On retrouve notre Mot de Commande VDP.
 bra CharCopy
 fin:
 rts


Ma GRANDE fierté personnelle car, tout comme la dernière fois, je t'ai codé ça les doigts dans le nez de manière naturelle ... J'ai bandé comme un âne après la compilation quand tout c'est bien compilé et fonctionné.
Je fais donc la différence entre le Mot du VDP en priorité haute & Basse, pour éviter tout problème ...
Tout est géré dans la même routine de manière à l'utiliser à la volée quand je le désire.

Un truc de fou encore une fois ... J'en reviens pas d'en être arriver là.

Prochaine étape, afficher un Sprite et apprendre comment le VDP gère le truc.
Peut être aussi, comment gérer les interruptions VBLANK, HBLANK dans une boucle fermée ...
La, ça sera le stade supérieur ...

A bientôt et merci d'avoir lu ce pavé ( pas trop indigeste j'espère ... )

[Invité]

Perso, mettre tes registres à 0 avant d'y charger une valeur est inutile,mais sinon je suis content d'avoir eu raison en disant que tu aimerais ça 

[Invité]

Oui merci !!
Ça commence a devenir naturel et c'est ça qui est bon !

[Hpman]

C'est toujours incorrect après IncPal, le swap ne fonctionne pas comme ça et la routine part dans tout les sens.

[Invité]

Bon ... Et bien que proposes tu ??
Si je partage mon code de N00b V1.0 c'est pour le soumettre a d'éventuel correction. Merci d'avance

[Hpman]

Si j'ai bien compris le schmilblick ça devrais faire le taf:

Code:

;///// Routine d'écriture de Texte /////
WriteText:
   move.l  #WritePlaneA,d0       
   lsl.w #6,d1            ;On multiplie par 64 ( 64 Cells )
   add.w  d3, d1        ;On additionne par Y     
   lsl.w #1,d1            ;On Multiplie par 2
   swap    d1              ;On effectue un swap ...
   add.l d1,d0            ;On l'ajoute à l'adresse du VDP ! 
   move.l d0,(a5)
   moveq #0,d0            ;Init d0
 
CharCopy:
   move.b (a0)+,d0
   beq.s Fin                  ;Si 0 soit fin de la chaine, alors goto fin !
   subi.b #$20, d0
   move.w d2, d1
   add.w d0, d1
   move.w d1,(a6)              ;On envoie le bazard au VDP
   
   cmp.b #0,d4                ;On va voir si notre option d'incrémentation de Palette est valide ? 0-O, 1-N
   bne.s CharCopy              ;
   
   ;inc palette
   add.w #$2000, d2
   andi.w #$7fff, d2
   bra.s CharCopy
Fin:

Tu peux aussi virer 0x20 de d2 avant d'appeler la routine, et éviter la soustraction à chaque caractère dans la routine.

[Invité]

Merci beaucoup, je vais étudier ça.

Question : Pourquoi mettre un .S pour les OPcodes Beq, Bra et Bne ? Un .b n'est pas correct ou c'est juste un format générique à respecter.

[Hpman]

Euh .b et .s c'est idem, j'ai l'habitude avec .s (short) donc voila...
Y'en a certainement un officiel et un toléré la dedans.

Je vois que j'ai zappé l'option priorité, on a qu'a dire que ça fait un exercice 

[Invité]

Oui merci .. J'ai vu que .s c'est Short, on peut même mettre .w avec Bra pour des sauts un peu plus "long" .. Pour les sauts en hyper espace, c'est Jmp.


J'ai corrigé mon ancien code avec le tien, ça marche mais je sais pas pourquoi .. A vrai dire, je n'y comprends rien.
On fait un ET logique avec 7fff ( 32767 ) et aprés on le stocke dans d2 ... Même sans ce Andi.w, ça fonctionne aussi, avec mon ancien code, ça fonctionne aussi.


Bref, mon cerveau a buggé.
Rendez vous plus tard ...

[Hpman]

Bah add.w #$2000, d2 pour incrémenter la palette, andi.w #$7fff, d2 pour clear la priorité (bit15), éventuellement mis à 1 par l'opération précédente.

Vaut mieux être à l'aise avec les manips binaires pour l'asm.

[Invité]

Élémentaire en effet.
C'est bon, j'ai pigé la combine du and. :)

[Invité]

Vetea n'essayes pas de courir avant de savoir marcher, c'est normal de pas connaitre toutes les astuces de la prog en ASM d'un CPU après 20 lignes de code .
Ca vient avec l'habitude, et surtout après avoir touché à tous les opcodes et connaitre leurs cycles .
Déjà arriver à faire ce que tu veux sans erreurs en si peu de temps est déjà excellent .