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

[Invité]

Bonjour à tous,


Je l'avais promis il y a quelques mois ... Je voulais mettre le pied à l'étrier et me lancer dans cette magnifique aventure qu'est l'assembleur ou comment dialoguer avec la machine "en douceur" !

Depuis mes débuts en programmation sur Megadrive, j'ai d'abord abordé la chose par le biais de BasiegaXorz en "tout basic", et petit à petit, j'ai commencé à faire connaissance avec les "tripes" de la Megadrive.
Travaillant dans l'électronique, il y a pas mal de choses qui m'étaient familière concernant des notions de HARD, ainsi qu'une initiation à l'assembleur du temps de mon CPC avec son merveilleux Zylog 280A.

BasiEgaXorz ou "BEX" avec mes projets, m'ont ensuite donné l'opportunité de toucher aux nombreux OPCODES du 68000 ainsi que les Adresses spécifiques aux différents composants de la console ( VDP, PSG, Puce FM, etc ... )

Pour Rappel :
CPU: Motorola 68000 at 7.61 mhz
Slave CPU: Zilog z80
Main memory: 64kb
Video: Yamaha YM7101 VDP (Video Display Processor)
Video memory: 64kb
Audio: Yamaha YM2612 FM chip, Texas Instruments SN76489 chip

64 Ko de RAM & 64Ko de VRAM !!!!
Ayant commencé avec un jeu plutôt complexe pour une première expérience, j'ai vite découvert que la RAM était vraiment géniale mais par contre, la VRAM me demanderait pas mal de manipulation dans le sens ou je ne pourrais pas TOUT charger en mémoire et qu'il faudrait faire des chargements dynamiques en fonction des demandes des scènes du jeu ...
Une joyeuse nouveauté quand tu viens du monde du PC !

Maintenant, il me fallait le bon "Kit" pour bien commencer ainsi que divers tutoriels, cours et livre sur ce bon vieux 68000.
Voici ce que j'utilise :


- BasiEgaXorZ !! En effet, ce génial programme assemble le code Basic en code Assembleur par le biais de la librairie de Jospeh Norman. Trés pratique pour comprendre l'architecture des boucles de conditions, boucles, etc ...
- Editeur NotePAD++ avec un plug-IN 68K ASM & Z80 ASM pour avoir les bonnes couleurs / OPCODES.
- Compilateur en ligne de commande : ASM68K. Trés pratique et trés simple ! Pour compiler un projet TATA.S et créer un .BIN : ASM68K TATA.S,TATA.Bin ... Rien de plus simple !
- Mes outils de créations graphiques, sons & Musiques à savoir les même que j'utilise pour BEX.
- Les différents tutoriels indispensables pour bien débuter :
1/ https://bigevilcorporation.co.uk/2012/02/28/sega-megadrive-1-getting-started/ !! Magnifique tutoriel en anglais ou pratiquement toutes les bases sont écrites.
2/ http://www.gamefaqs.com/genesis/916377-genesis/faqs/9755 !! Un autre site avec des bases indispensables !
3/ http://www.hacking-cult.org/ !! Un INDISPENSABLE qui m'a énormément aidé pour le débuggage de mes projets sur le HARD.
4/ Un vieux bouquin sur le 68000 vraiment génial : ASSEMBLY LANGUAGE PROGRAMMING for the 68000 Family par Thomas P.Skinner ! Trés pratique pour apprendre la théorie & pratique sur le fonctionnement du 68000. Il y a pas mal d'exercices à faire avec les solutions ... Un Must.
- Mon cerveau ! Il est trés créatif, imaginatif mais a une facheuse habitude de souvent bugguer !

Bon, et maintenant ... Que vais je faire ... de tout cela ?

Et bien, j'ai pris exemple sur le site de BigEvil et j'ai repris point/Point les différents tuto sur les points suivants :
- Le Header
- L'initialisation de la console.
- Les différents autres pages & fonctions de mon futur code.

Avec BEX et tous mes autres projets basic, j'ai toujours eu l'habitude de tout intégrer sur la même feuille de code ... Créeant des projets avec plus de 50 000 lignes, tout en arrivant à m'y retrouver .. La magie des programmeurs Basic !
Ici, j'ai opté pour une autre méthode, un peu comme le C, intégrer différentes parties et ensuite les intégrer au code principal.

Voici comment ça se présente sur l'image :





4 onglets ont été définis :
1/ HEADER.S --> Le Header
2/ MAIN.S --> Le corps principal
3/ INIT.S --> Les routines d'initialisation de la console
4/ DATAGRAPHIQUES.S --> Toutes les Data graphiques.

Concernant 1 & 3, il s'agit de codes génériques utilisés et donnés sur pas mal de Tuto ... Personnellement, je les laisse tel quel. Il n'y a que le HEADER qui peut être modifié sans risque !

Le 4 contiendra mes données graphiques .. Ici j'ai intégré ma Font d'origine de Papi Commando & Bomb on Basic City.
Ex :
Font:
    dc.l    $00011F00    ;  Tile: 0
    dc.l    $00011F00
    dc.l    $00011F00
    dc.l    $00011F00
    dc.l    $00011F00
    dc.l    $000FFF00
    dc.l    $00011F00
    dc.l    $000FFF00

( Ici c'est le symbole d'exclamation "!" )

Le 3 sera le corps principal de mon projet !!
Pour le moment, il ne contient pas grand chose, si ce n'est :

;***********************
;*** Corps Principal ***
;***********************

;***** On initialise le HEADER *****
 include Header.S
;***** On initialise la Console *****
 include Init.S
;***** On charge les données Graphiques *****
 include DATAGraphique.S

;***** Programme Principal *****
Main:

 jmp Main
 
;***** Définition des Palettes *****
;Palette No0
PaletteBase:
 dc.w 0x0000
 dc.w 0x00EE
 dc.w 0x0224
 dc.w 0x004E
 dc.w 0x000E
 dc.w 0x00E0
 dc.w 0x0800
 dc.w 0x008E
 dc.w 0x0EEE
 dc.w 0x0E80
 dc.w 0x0642
 dc.w 0x0EA0
 dc.w 0x0E20
 dc.w 0x0E40
 dc.w 0x0E60
 dc.w 0x0000

J'y ai défini ma palette 0 d'origine avec ses couleurs !
Bientôt viendra le feuillet VARIABLE.S ou je définirai toutes mes variables globales.

J'ai donc compilé tout ce joyeux bazard !





Et j'ai obtenu mon premier Main.BIN que l'émulateur execute sans problème .. Avec un joli écran noir !





Vous noterez le nom de la ROM : PAPI ASM !

Pour le moment, je m'en suis arrété là.
Sans vous mentir, j'avais déjà travaillé sur ce sujet il y a pas mal de mois ... Sans trop me lancer, mais en bidouillant avec BEX, car il permet d'intégrer du code ASM.
Maintenant, il me faut comprendre la manière dont on dialogue avec le VDP et son Control Port ... C'est assez tordu, mais pas insurmontable.
Une fois cette partie intégrer, je pourrais ensuite afficher mes premiers caractères graphiques ( ou texte ) ainsi que TILE & Sprite.
Et par la suite, la gestion des Plans A & B.

Voila donc mes débuts en Assembleur que je voulais vous faire partager.
Je ne laisse pas du tout tomber mon projet actuel, mais je voulais vraiment sauter le pas.
On va y aller en douceur ... Tranquille Emile, Cool Raoul, A l'aise Blaise ... Relax Max !!

Merci d'avoir lu ce long pavé.
A bientôt !

[drfloyd]

mais tu es totalement dingue

Donc ayant galéré en C, tu passes donc directement en assembleur ?

[Invité]

Sympa, surtout si tu continues à l'alimenter 

[Invité]

Yesss je suis dingue, un suppo 500mg et ça repart !!
Je trouve l'ASM plus abordable que le C en fait .. Et puis avec tous les outils et tutos modernes, il y a de quoi faire des trucs.

J'alimenterai le topic au grès de mes travaux.

[drfloyd]

question d'un newbie en assembleur : ce n'est pas plus compliqué de debuter sur un 68000 que sur une machine 8bit ? Ne serait que pour la taille des jeux....

[pckid]

Sympa ce post ! hâte d'en apprendre plus sur tes avancements.

[Invité]

@Pckid : Merci ! Je tâcherai d'être clair .. Enfin j'essaierai !!
@Doc : J'en sais absolument rien ... Je suis Newbie XXL.

Je planche actuellement sur la manière dont on dialogue avec le VDP.
C'est totalement tordu ... :p
On écrit un ordre au Control port et apres on effectue nos opérations.
J'écrirai un bout de code et exemple quand j'aurai tout pigé car les sites tutos regorgent d'erreurs et les sites techniques ne sont pas forcément clairs.
Une fois cette partie assimilé, tu peux déjà t'amuser a afficher et gérer plein de trucs a l'écran.
++

[vincent2105]

Comme les copains, je vais suivre ton topic avec intérêt

Et j'ai obtenu mon premier Main.BIN que l'émulateur execute sans problème .. Avec un joli écran noir !

Pour ma part, le moindre truc qui fonctionne comme prévu m'apporte satisfaction... et des fois ca ressemble vraiment à rien. Fallait voir l'incompréhension de ma femme quand elle m'a vu heureux d'avoir réussi à déclencher 4 interruptions dans une frame... :p

Spoiler:

Bonne continuation Vetea

[drfloyd]

On va suivre les folles aventures de Vetea dans le monde de la programmation de bas niveau.... (qui porte mal son nom !)

[Ninja_SCX]

question d'un newbie en assembleur : ce n'est pas plus compliqué de debuter sur un 68000 que sur une machine 8bit ? Ne serait que pour la taille des jeux....

Au contraire, je pense que c'est plus simple de débuter sur 68000 que sur un processeur 8bits.
La syntaxe est plus claire et il y a plus de possibilités (plus de registres de données et d'adresse, opérateurs de multiplication et division).

[tfdi]

Vetea:ton image pique les yeux (et je l'adore ton image!!...) ...

Code:

Move.l 0,d0
jmp loop
rts

Pour que tu commences bien:

move.l 0,d0  -> Te donnera un crash system suite à une erreur de bus, c'est move.l #0,d0.

Tu ne verras jamais, jamais, jamais, jamaiiiiisssssss ...  un RTS après un jmp, jmp c'est comme goto en basic, c'est un saut inconditionnel, donc le rts ne sert absolument à rien. Si tu mets un rts (ReTurn from Subroutine, retour de sous programme) c'est que tu es dans un sous-programme, logique, ton RTS doit être dans les lignes de code qui se situe après ton label "loop", sinon t'auras là aussi une erreur de bus ..

style:

Code:

move.l #0,d0
jmp loop
move.l #$12345678,d0   ; Jamais exécuté

loop:
 move.l #$23456789,d6
 rts


Garde ton image en souvenir de tes débuts en asm68k, dans quelques mois quand tu maitriseras mieux le sujet, elle te fera sourire ...

Je suis d'accord avec Ninja_SCX, c'est plus facile de débuter en asm68k qu'en asm sur un processeur 8 bits. Le code est plus facilement "lisible" et compréhensible pour démarrer l'assembleur.

[F.L]

vétéa se lance dans l'assembleur...
c'est quand meme fou que tu n'arrives pas à configurer codeblocks mais que tu arrive à comprendre ce langage de jedi....
si jamais tu n'as pas laissé tomber le C, demande à c6502, il n'avais bien aidé à lancer codeblocks sans erreur

[drfloyd]

quand on aime pas le C, on aime pas

[Invité]

Putain c'est midi et je me lève juste la ...
Merci pour vos messages.
@Tfdi : ouiiiiii elle est nawak l'image, c'est fait exprès !! Papi il code qu'en Basic et encore ... Il passe son temps a graisser ses armes ( et sa raquette en bois Noah ) en attendant de futures aventures ...

J'aime beaucoup le 68k car ça grouille d'opcode de registres divers ... Y en a même trop !!
Le Z80, y a pas grand chose de mémoire ... Et le 6502 encore moins !!
Donc tu as les Jedis, les padawans et les supers Yodas !!

@FL : c'est pas si compliqué .. Bex te donne le change en assemblant ton code basic !! C'est vraiment génial et ça permet de commencer a prendre l'habitude ..
Le plus difficile, c'est la partie dialogue avec le hard car il faut suivre certaine règle plutôt tordus.
Quand j'arriverai a afficher mes premiers caractères je ferai un post.

[drfloyd]

Hello world sur megadrive tu peux le faire j'y crois 

[TotOOntHeMooN]

La mécanique mentale pour apréhender le C et l'ASM c'est pas la même.
Beaucoup de pro ASM ne sont pas foutu de programmer en C.

[65c02]

La mécanique mentale pour apréhender le C et l'ASM c'est pas la même.
Beaucoup de pro ASM ne sont pas foutu de programmer en C.

mouai... là je ne suis vraiment pas convaincu....
C'est tellement simple l'asm et tellement bidon le C...
En 1990 peut être, et encore, pour la tradition. 
mais aujourd'hui...

[Invité]

C'est tellement simple l'asm et tellement bidon le C...

Le gros Troll

L'asm ne sert de nos jours strictement a rien , a la limite pour programmer sur nos vielles machines.
Par contre le C est toujours utilisé (principalement dans l'embarquée ) , dans le jeux vidéo le C c'est fait remplacé par le C++.

Enfaite je rejoins TotOOntHeMooN , le C est l'asm c'est très différent.

Pour ma part je me sens pas concerné je programme aussi bien en asm que en C donc bon

[Invité]

Messieurs les spécialistes, merci de poursuivre vos débats sur un post dédié à cela, je suis persuadé que cela pourra donner des joutes mémorables et aussi sans intérêts.

Il s'agit juste d'un défi personnel qui fera rire les spécialistes mais qui pourrait intéresser les autres, alors merci de respecter cela.

Bon, je retourne à ce foutu VDP ...

[TotOOntHeMooN]

OK, donc je t'encourage dans ton choix de l'ASM et tu me dis d'aller voir ailleurs... 

[Invité]

le C est l'asm c'est très différent.

Oui, ça n'a pas le même nom 

de toutes façons, il n'y a pas de meilleurs langage, juste des langages plus adaptés que d'autres à ce que l'on veut faire .

[65c02]

le C est l'asm c'est très différent.

Oui, ça n'a pas le même nom 

de toutes façons, il n'y a pas de meilleurs langage, juste des langages plus adaptés que d'autres à ce que l'on veut faire .

[tetsuro]

Passionnant, je vais te suivre, d'autant plus que j'avais commencé un topic aussi sur le 68000, d'ailleurs je t'invite à y jeter un œil œil, il y a de supers conseils de tout nos potes du forum, une mine d'or d'informations ! Je n'ai pas fini mon apprentissage se ce langage mais j'y compte bien y revenir et ton topic vas peut-être m'y aider ! Courage !

[vingazole]

Passionnant, je vais te suivre, d'autant plus que j'avais commencé un topic aussi sur le 68000, d'ailleurs je t'invite à y jeter un œil œil, il y a de supers conseils de tout nos potes du forum, une mine d'or d'informations ! Je n'ai pas fini mon apprentissage se ce langage mais j'y compte bien y revenir et ton topic vas peut-être m'y aider ! Courage !

Celui-là : https://www.gamopat-forum.com/t84489-asm-68000-z80-megadrive ?

[Invité]

Merci Tetsuro !!
Oui en effet, c'est passionnant !!
Désolé si j'ai été sec, mais les débats de spécialistes me gavent profondément ... Créez un topic dédié et lâchez vous !!

Sinon, j'ai codé une bonne partie de l'après midi pour arriver a pas grand chose .. En fait, je ne sais pas si les commandes que je réalise se passe normalement avec la console .. La compilation est OK ( d'ailleurs j'ai créé un Batch.bat pour compiler, créer une ROM et exécuter l'émulation !! Merci Dub, c'est grâce a toi. )
J'utilise Gens qui possède un mode Debug très pratique.
J'en suis a charger ma palette de base, mais aucune idée si elle est bien chargée. Je verrai ça demain.
Sinon j'ai bien pigé la méthode de dialogue avec le VDP, c'est pas compliqué, j'expliquerai tout en même temps.
A bientôt.

[Invité]

tu vois finalement qu'il est pas si mal np++ 

[Invité]

Projet No1

Bonsoir à tous,

Je peux enfin vous proposer un premier projet qui m'a valu bien des efforts pour un résultat ... euh .. très simpliste : Afficher un fond bleu !



Au commencement, l'eau, l'air, le feu, la terre ... et le VDP !

Ahh ... Ce foutu VDP .. Il m'a valu quelques heures de galère pour comprendre comment ça marche !
Tout d'abord, il faut définir ce que l'on veut faire :

1 - Définir une Palette principale de 16 couleurs.
2 - Il s'agira de la No 0.
3 - Charger la Palette en VRAM.
4 - Changer la couleur de fond de l'écran en choisissant une couleur de notre Palette.

- Tout d'abord, on définit notre Palette
Je créer donc un nouveau feuillet : Palettes.asm
Son code :

Code:

PaletteBase:
 dc.w $0000
 dc.w $00EE
 dc.w $0224
 dc.w $004E
 dc.w $000E
 dc.w $00E0
 dc.w $0800
 dc.w $008E
 dc.w $0EEE
 dc.w $0E80
 dc.w $0642
 dc.w $0EA0
 dc.w $0E20
 dc.w $0E40
 dc.w $0E60
 dc.w $0000


Rien de plus simple, le nom de la Palette suivie des couleurs à charger.
Chaque élément est de type Word, on utilise l'OP DataContainer donc : dc.w $xxxx

On va définir nos variables :
Même chose, je créer un feuillet Variables.ASM

Code:

VDPControlPort: equ $C00004
VDPData: equ $C00000


Qu'est ce donc ??
Et bien, pour plus de commodité, j'ai directement définie les adresses du Control Port (C00004) & du Data Port (C00000) du VDP.
EQU permet de donner une adresse au Label ( Equate Directive ).

- Le VDP, comment lui causer ??
Pour causer avec pépére, il faut lui parler avec un mot de 32 bits via le Control Port donc la structure est :
BBAA AAAA AAAA AAAA 0000 0000 BBBB 00AA

B : Ordre à donner au VDP
A : Adresse principale
0 : Laisser toujours 0 ! ^^

Les ordres du VDP :
000000 – Lecture VRAM
100000 – Ecriture VRAM
000100 – Lecture CRAM (Palette)
110000 – Ecriture CRAM (Palette)
001000 – Lecture VSRAM
101000 – Ecriture VSRAM

On veut charger, donc écrire une Palette dans la CRAM : B=110000
L'adresse de notre Palette est : 0 !

Donc on peut en déduire notre "mot" VDP :
11000000000000000000000000000000 ( en binaire ici )
On le convertir en Hexa : C00000

On a donc notre adresse du control Port : VDPControlPort & C00000

Tout est prêt pour charger notre Palette ... Ou pas encore !

- Le VDP ou les 23 Registres du bonheur !
Le VDP possède 23 registres programmables ... Je ne vais pas tous les décrire, il suffit de les découvrir ici : http://www.hacking-cult.org/?r/18/24
Après pas mal de galère et de réflexion, je ne comprenais pas pourquoi je n'arrivai pas à avoir la totalité des couleurs en mémoire .. Je n'avais juste que la première ...

EUREKA ! Il fallait activer l'auto incrémentation ! Une fonction du VDP qui va incrémenter automatiquement la mémoire à chaque chargement de données.

Le Registre en question est le No15. ( soit $F )
Comme nous avons des couleurs en Word, on va paramétrer l'incrémentation à 2 bits ( soit $02 )

Qu'est ce que ça donne tout ce bordel en code ??

Nous voila donc à notre code principal ...

On déclare nos principaux feuillet:

Code:

 include Init.asm
 include Variables.asm
 include Palettes.asm


Ensuite, on va programmer notre VDP aux valeurs précédemment expliquées :

Code:

;On va définir l'autoincrémentation : Registre 15 et incrémentation de 2 bits.
 move.w #$8F02,VDPControlPort


Ici nous allons définir le mode d'auto incrémentation 8F suivi des 2 bits.
L'instruction est de type 16 bits, en Word.
( Le 8 est le chiffre par défaut avant la déclaration du registre VDP ... Ne me demandez pas pourquoi, c'est comme ça ! )


Après cela, on va paramétrer le VDP pour le chargement de notre Palette :

Code:

;Ecriture de notre Palette 0
 move.l #$C0000000,VDPControlPort


On retrouve notre mot d'adressage VDP calculé précédemment, c'est un mode de type Long.

On va ensuite charger en mémoire notre Palette 0 !

Code:

;Chargement des données Palettes dans la VRAM.
 lea PaletteBase,a0 ; On charge notre palette dans le registre d'adresse a0  
 clr.l d0 ;On efface d0 par sécurité.
 move.b #7,d0 ;On va intialiser notre compteur. Notre palette possède 16 couleurs, on incrémente de 2 bits à la fois : 16/2 = 8-1 (a cause du compteur)
 @Loop:
 move.l (a0)+,VDPData ;On charge notre Palette dans la mémoire de la VRAM via le DataPort.
 dbra d0,@Loop ;On décrémente jusqu'à D0=0


Les commentaires parlent d'eux même. :)
Avec l'OPCode LEA, on charge le label de notre Palette dans le registre d'adresse a0.
Ensuite, j'efface le contenu de D0 par sécurité ... Je sais c'est sans doute inutile ! Pour cela, on a l'OPcode CLR.
J'efface l'intégralité de D0 sur 32 bits ( tout à 0 ), donc CLR.L
Ensuite, on définit la valeur de notre compteur, un nombre décimal 7 par le biais d'un petit Move.b .. On pourrait aussi remplacer Move.b par MoveQ qui est spécifique aux données de type Byte.
Pourquoi 7 alors que l'on a 16 couleurs à charger ?
Et bien vu que nous allons incrémenter de 2 bits pour chaque valeur, on a donc 16/2 = 8.
Le compteur va commencer à 0, on va donc décrémenter 8 de 1. D'où 7. ( 0 à 7 = 8 )
Par la suite, DBRA va décrémenter D0 jusqu'à ce qu'il soit égal à 0.

En basic, cela pourrait être équivalent à :
For i=0 to 7
 ...
next

Simple non ?

Maintenant que tout est chargé, et bien on va définir la couleur de fond de notre écran !
Le registre VDP pour cela est le No7.
Il faut ensuite définir la Palette à utiliser et la couleur de celle ci.
Palette 0 - Couleur 12 ( $C ) d'où : 0C
Donc : $870C

Code:

move.w #$870C,VDPControlPort


Et voila, c'est terminé !!

Nous compilons donc notre projet et au travers de notre émulateur GENS, obtenons un magnifique écran bleu !!


Par curiosité, nous pouvons constater notre Palette 0 au travers du Debug VDP :


Nous retrouvons bien notre Palette 0 avec les bonnes couleurs d'origine ! Dingue non ?!

Build du projet :
https://dl.dropboxusercontent.com/u/108143465/Projet1.zip

Bon c'est sur, ça casse pas trois pattes à un Canard ... Certain vont bien se marrer devant ce premier défi bien pourri ... Mais qu'importe, ça me rend heureux d'avoir déjà compris la méthode et obtenu ce premier résultat.

Bien à vous.

[tetsuro]

Oui c'est bien celui-là vingazole, je ne t'avais pas reconnu avec cet avatar, je t'ai connu avec celui d'une jolie maman Noël
C'est génial Vetea, je trouve que cet apprentissage va dans le sens de ce que tu maitrisais déjà un peu, car si j'ai bien compris tu codais en Basic mais tu faisais aussi quelques appels en ASM avec BEX ?

[Invité]

Merci Tetsuro.
Oui avec bex on peut intégrer du code Asm très facilement.
Mais la, c'est un véritable projet en asm, apprendre comment ça se structure, etc ... C'est ça qui est bon !!

[tfdi]

Vetea:

Moveq #0,d0  ->4 Cycles
clr.l d0 -> 8 Cycles
move.l #0,d0 -> 12 Cycles

Un moveQ #0 est bien plus rapide qu'un clr.l ...  ....

Un petite explication concernant moveQ, la valeur que tu affectes au registre de donnée de destination est sur 8 bits, mais elle est étendue sur 32 bits lors du transfert.

En clair, parce que ce sont ces petites différences qui changent le monde en assembleur  :

Code:

move.l #$12345678,d0    ; d0=12345678
move.b #$FF,d0  ; d0=123456FF
move.w #$FF,d0  ; d0=123400FF
move.l #$FF,d0  ; d0=000000FF
moveq #$FF,d0 ; ATTENTION d0=FFFFFFFF
moveq #$7F,d0 ; AUTRE PIEGE d0=0000007F


Comme tu peux le voir, il y a des grosses différences en fonction du fait que tu utilises en destination .b, .w, .l ou moveq. Ce sont ces petites "astuces" qui sont longues à maitriser ..

Mais en persévérant, on y arrive toujours, et je sais que tu y arriveras