Merci Vincent pour ces vidéos très éducatives. Mon premier contact avec l'assembleur sur ST (en 1991!) avait été un peu froid: quand j'ai réalisé comment était arrangé le mode 16 couleurs de l'Atari, avec les bit-planes, j'ai vite laisser tomber. Je m'y suis mis de nouveau en 1993 sur Falcon avec mode Hi-Color facile à adresser. Là j'ai pu beaucoup progresser. Mais depuis tout ce temps, je n'ai jamais touché aux bit-planes. Avec tes vidéos je vais enfin m'y mettre. Tu amènes la chose de façon bien progressive et intéressante. J'ai assemblé ton dernier exemple avec Assemble sous SteemSSE. Ca fonctionne bien mais j'y du mettre l'appel ligne A $A009 à la fin avant le pterm pour retrouver la souris. En tout cas, continue et bon courage pour les vidéos sur l'accès aux bit-planes qui risquent d'être un peu velues!
Merci Thibault pour ce retour chaleureux 🙂 En effet, les bitplanes ce n'est ni intuitif, ni facile à manipuler. Je compte y venir tout en douceur, avec probablement quelques détours. Je suis content que tu utilises Assemble : moi j'utilise Devpac 2 car j'y suis habitué. Mais l'objectif n'est pas de promouvoir Devpac 2 : c'est d'expliquer la théorie et de montrer des exemples concrets, pour que chacun puisse les adapter et en tirer parti dans son environnement favori. Ce que tu as fait. En revanche, je suis assez étonné de la nécessité d'utiliser $A009 pour réafficher la souris. Ou plutôt, c'est le contraire : j'ai été étonné que, dans mon cas, je n'en aie pas eu besoin. Peut-être que ça dépend des versions du TOS ? Je re referai des tests. Merci pour cette information.
Très bien expliqué, tu as un réel esprit didactique ! Mais je pars de tellement loin en ASM (noob) que je reste perdu. Mais, en m'y penchant plus sérieusement, avec tes vidéos, je pense que je finirai par y arriver !
Merci 😊 Eh oui, apprendre l'assembleur c'est délicat, car ça demande une somme de connaissances assez difficiles d'accès. D'abord, le langage lui-même. Il est conçu pour pouvoir être facilement exécuté par le processeur. Donc l'être humain doit s'adapter pour parler la même langue, et ce n'est pas du tout naturel. De plus, le 68000 a de nombreuses instructions et beaucoup de modes d'adressages. Ca apporte une grande flexibilité, mais en revanche ça fait beaucoup de choses à apprendre. Et parfois on peut faire la même chose avec plusieurs instructions, c'est troublant. L'idéal serait de prendre une documentation de référence du 68000 et de commencer par apprendre toutes les instructions. Le problème, c'est que si on commençait comme ça, on se demanderait vite : mais à quoi ça sert tous ces trucs compliqués ? Ensuite, il faut quelques notions de mathématiques. Heureusement, ce n'est pas compliqué, ça reste au niveau école primaire : additions, soustractions, multiplications, divisons. Mais on a souvent besoin d'utiliser des nombres écrits en binaire et en hexadécimal. Et ça aussi, ce n'est pas naturel. Rien de très compliqué, mais il faut se familiariser avec. Ensuite, il y a l'interface avec le système d'exploitation, au début et à la fin du programme. Je l'ai expliqué dans les premières vidéos, on n'a plus besoin d'y revenir. Mais le plus obscur, ce sont les structures de données, et notamment la manière dont les pixels sont codés dans la mémoire vidéo. C'est ce que présente petit à petit, avec des exemples. C'est très important, car peu importe le langage, ces structures restent toujours les mêmes. En revanche, la manière dont les pixels sont codés change un peu selon les modes vidéo et les machines. Quand on aura bien compris la base, on pourra faire le parallèle avec d'autres systèmes, et grâce à notre nouveau bagage ce sera facile de comprendre. Et j'oubliais encore un élément : le logiciel assembleur. J'utilise Devpac 2 car il est simple et agréable, mais bien sûr on peut utiliser un autre assembleur. Donc tout ça, eh bien ça fait une belle somme de connaissances à acquérir. Un mur infranchissable, si on ne s'y prend pas avec méthode. En fait, c'est un peu comme l'apprentissage d'une langue étrangère. Il faut commencer à pratiquer tout de suite. Apprendre quelques mots. Faire des phrases, même si au début on ne comprend pas tout. Apprendre quelques règles de grammaire. Et avancer petit à petit dans tous ces domaines. Et surtout, ne pas se décourager. C'est pour ça que je cherche des exemples variés. En illustrant avec des jeux connus, ça permet de prouver que tout ça n'est pas du vent, et c'est ludique. Donc en résumé, je sais bien que tout le monde ne pourra pas comprendre tout ce que j'explique dans ces tutos assembleur. Du moins pas dans l'immédiat. Mais ceux qui sont intéressés pourront tout de même apprendre quelques trucs, dans l'un des domaines cités. Et au bout d'un moment, tout ça deviendra familier. On pourra alors regarder à nouveau ces vidéos, plus tard, et comprendre ce qui nous avait échappé. En tout cas, c'est une belle aventure.
Je viens du C/C++ que je ne maîtrisait pas trop mal dans les années 90. J'avais développé un clone de Civilisation mais en post apocalyptique. L'ASM m'a toujours paru comme un mur infranchissable à côté du C. Mais je regarde tes vidéos, je me dit que je récupère déjà quelques bribes. Et si un jour, je veux m'y mettre, je sais que tes vidéos me seront précieuses 😁.
Vivement la suite sur les 4 bits plans, sur les chunks, le page flipping et la synchro VBL ... comment ça je réclame ? Oui bon d'accord je réclame un peu. Super vidéo ! Un petit scrolling vertical du bloc ça aurait mis appétit aussi :-)
Salut Vincent, j'y retrouve quelques similitude entre assembleur Atari et celui du 6809E Thomson. Mais le 6309, qui est le successeur du 6809 possède quelques fonctions particulièrement puissante, comme la copie de blocs de RAM (en une seule instruction), des instruction de DIV et MUL sur 16 et 32 bits.
Oui, on s'aperçoit que même si tous les processeurs sont différents, il y a des principes de base qui reviennent toujours. Donc quand on connaît bien l'assembleur d'un processeur, on a des facilités pour apprendre celui d'une autre machine.
Je compte faire des cours en Langage Pascal sur Atari ST (il y a le HS Pascal et le Pure Pascal), c'est un langage vraiment très intéressant, qui a les avantages du C, Basic, C++ (Parce qu'il est aussi objet), et Java (Le Pascal peut être compilé en pseudo code). Je ne sais pas si je vais utiliser majoritairement HS Pascal ou Pure Pascal. Les 2 ont l'air bien, même si Pure Pascal est plus récent de 1 ou 2 ans. Du coup, j'y balancerait tous mes contenus de cours du CNAM (tris Quick Sort, Inversion de matrice, opérations sur polynomes, recherche opérationnelle etc etc)
Merci, c'est toujours super clair et super bien fait. Sans transition : ferez vous une vidéo sur le GFA Basic Atari ? J'ai pas mal de vieux code dans ce langage, et je me demandais comment le traduire plus ou moins automatiquement dans un langage actuel (java, python, ou autre) pour l'exploiter, l'améliorer, dans un environnement moderne.
Bonjour, je suis content que ça vous plaise 😊 Non, je n'ai pas l'intention de faire de vidéo sur le GFA Basic, tout simplement car je le connais mal. En fait, les premiers ST étaient livrés avec le ST Basic, qui n'était vraiment pas terrible. Du coup, les utilisateurs se sont tournés vers le GFA Basic, qui lui était très bon. Mais pour ma part, j'ai acheté mon Atari STE très tard, en 1992. Et à cette époque il était livré avec l'Omikron Basic, qui était lui aussi très bon. Donc en pratique, j'ai beaucoup programmé en Omikron Basic avant de passer à l'assembleur et au C. Et je n'ai jamais eu besoin du GFA. Mais en effet, ce serait intéressant de faire le parallèle entre le GFA et les autres langages. Les similitudes et les différences.
Sur Thomson, on a 16 kO de RAM vidéo, on n'a pas ces bloc de 16 pxl, mais en mode bm 16, qui fait 160 pxl de large, on a le même principe de 4 bits par pixel, sauf que sur Thomson ya cette foutue compatibilité avec les TO7 qui fait que c'est splitté entre RAMA et RAMB. En gros quand tu démarres à l'adresse RAM écran 0, tu es en RAM A et balance 2 pixels (2x4 bits d'un octet de RAM A pour la couleur), donc ceci pour les pxl 0 et 1, pour les 2 suivant, c'est en RAMB (tu es obligé de faire la bascule), donc 2 autres pxl dans le même emplacement "logique" de RAM... La RAM vidéo est splitté en 2x8kO. Mais heureusement, avec le Gate Array Mode Page, il est possible de travailler dans la zone de RAM $A000-$DFFF, et là, on a les 8kO de RAM B qui sont dans les adresses basses et lles 8kO de RAMA sont dans la zone haute.
Eh oui, sur certaines machines même l'accès à la RAM vidéo peut être compliqué. Heureusement, avec le 68000 c'est juste une zone de ram contiguë, comme une autre. Ensuite, ce qui est compliqué avec les vielles machines, c'est que vu le faible nombre de couleurs, un octet sert à coder plusieurs pixels. Ca peut se faire de différentes manières. Mais surtout, pour modifier un seul pixel, il faut modifier seulement une partie d'un octet. Ca devient vite un casse-tête.
Hello, tu ne dis pas pourquoi on pourrait remplacer avantageusement ADD.L par LEA à 15:20 ? Le truc que je devinerai être vraiment avantageux serait de mettre un repeat 16 sur le move.l (a0)+,(a1)+ si toutefois devpac connait ce genre de directive!
Bonne remarque ! En effet, j'ai éludé la question. J'avais prévu de parler plus en détail de LEA, mais j'ai laissé tomber car ça compliquait les choses, et je ne voulais pas égarer inutilement les spectateurs. Il y a deux avantages à utiliser LEA plutôt que ADD.L : la place et la vitesse. - La place : l'opérande de ADD.L est codée sur 32 bits. Alors que celle de LEA l'est sur 16 bits. Donc au total, ADD.L est codé sur 6 octets, alors que LEA prend seulement 4 octets. - La vitesse : dans ce cas, ADD.L prend 16 cycles, alors que LEA n'en prend que 8. Ces deux questions relèvent de l'optimisation, alors pour cette fois-ci j'ai laissé tomber pour ne pas perdre de vue l'objectif : expliquer simplement l'algorithme. La syntaxe de LEA étant plus compliquée, ça rend le code moins compréhensible. J'expliquerai tout ça dans de futures vidéos où la performance aura vraiment de l'importance, par exemple pour faire des animations. Concernant ta deuxième remarque, c'est tout à fait pertinent : Devpac supporte les directives REPT/ENDR pour dupliquer du code plusieurs fois. Ainsi, quand on connaît à l'avance le nombre de tours de boucles, on évite de perdre du temps sur l'instruction DBRA. Au prix d'un code un peu plus gros, mais qui reste raisonnable sur de petites boucles. Mais l'optimisation idéale sur 68000, c'est d'utiliser l'instruction MOVEM qui permet de copier le contenu de plusieurs registres à la fois. C'est ce qu'il y a de plus performant pour copier de grandes zones de mémoire.
@@Vretrocomputing Merci pour ta réponse détaillée, je connais mal le 68000, j'arrive à le lire (j'ai beaucoup de mal avec les branchements) mais pondre de l'optimisé j'suis pas prêt donc je me renseigne doucement. Tu as des ouvrages (disponibles en ligne) à conseiller?
Salut Vincent, toujours un plaisir de regarder tes vidéos ! Petite question j'ai pris l'habitude d'écrire plutôt mes coordonnées sous la forme 160*y+8*x, où x est le numéro du groupe de pixels horizontalement. Je suppose que c'est équivalent, ou bien cela risque-t-il de me compliquer la tâche à l'avenir dans certains cas que je n'aurais pas encore rencontrés ? Et merci encore pour ces vidéos :) Vivement la prochaine !
Merci, je suis content que ça continue à te plaire 😊 Ta formule est parfaitement valide. Elle utilise le principe de base "offset = taille de l'objet * numéro de l'objet". J'ai choisi d'insister plutôt sur x/2, car il m'a semblé que c'était plus facile de se repérer avec des pixels. Mais les deux sont totalement équivalents, pas de souci.
Bon j'éprouve le besoin d'écrire mon raisonnement ici afin que l'on me dise si j'ai bien comprit : admettons que je veuille connaitre l'adresse d'une coordonnée x et y : x=64 et y=39 (ligne n°40-1) Je cherche d'abord l'adresse de début de la ligne 39, qui débute à : adresse écran + 39 fois 160 octets. Puis sachant que x=64 est le 1er pixel situé à 8+8+8+8 octets du début de la ligne, ont l’additionne à l'adresse du début de ligne trouvé juste avant ? et comme 8+8+8+8 çà fait 32, çà revient à fait 64/2, ce qui permet de mettre X dans le calcule, est ce que j'ai bon ?
Oui, c'est ça. C'est la formule que j'ai indiquée à 4:29. Quant à la manière dont sont codés les 16 pixels dans les 8 octets, je l'expliquerai dans une prochaine vidéo.
Ah, c'est dommage. A essayer. Mais attention c'est un peu spécial, à cause de la nécessité de jongler entre les modes tank et avion. Et surtout, le boss du niveau 1 est très dur, je l'ai rarement battu.
Merci Vincent pour ces vidéos très éducatives. Mon premier contact avec l'assembleur sur ST (en 1991!) avait été un peu froid: quand j'ai réalisé comment était arrangé le mode 16 couleurs de l'Atari, avec les bit-planes, j'ai vite laisser tomber. Je m'y suis mis de nouveau en 1993 sur Falcon avec mode Hi-Color facile à adresser. Là j'ai pu beaucoup progresser. Mais depuis tout ce temps, je n'ai jamais touché aux bit-planes. Avec tes vidéos je vais enfin m'y mettre. Tu amènes la chose de façon bien progressive et intéressante. J'ai assemblé ton dernier exemple avec Assemble sous SteemSSE. Ca fonctionne bien mais j'y du mettre l'appel ligne A $A009 à la fin avant le pterm pour retrouver la souris. En tout cas, continue et bon courage pour les vidéos sur l'accès aux bit-planes qui risquent d'être un peu velues!
Merci Thibault pour ce retour chaleureux 🙂 En effet, les bitplanes ce n'est ni intuitif, ni facile à manipuler. Je compte y venir tout en douceur, avec probablement quelques détours. Je suis content que tu utilises Assemble : moi j'utilise Devpac 2 car j'y suis habitué. Mais l'objectif n'est pas de promouvoir Devpac 2 : c'est d'expliquer la théorie et de montrer des exemples concrets, pour que chacun puisse les adapter et en tirer parti dans son environnement favori. Ce que tu as fait.
En revanche, je suis assez étonné de la nécessité d'utiliser $A009 pour réafficher la souris. Ou plutôt, c'est le contraire : j'ai été étonné que, dans mon cas, je n'en aie pas eu besoin. Peut-être que ça dépend des versions du TOS ? Je re referai des tests. Merci pour cette information.
Wow ça me rappelle vague souvenirs ... Je suis sacrément rouillé
Xenon et Xénon II par les Bitmap Brothers, que de bons souvenirs
Très bien expliqué, tu as un réel esprit didactique !
Mais je pars de tellement loin en ASM (noob) que je reste perdu.
Mais, en m'y penchant plus sérieusement, avec tes vidéos, je pense que je finirai par y arriver !
Merci 😊 Eh oui, apprendre l'assembleur c'est délicat, car ça demande une somme de connaissances assez difficiles d'accès. D'abord, le langage lui-même. Il est conçu pour pouvoir être facilement exécuté par le processeur. Donc l'être humain doit s'adapter pour parler la même langue, et ce n'est pas du tout naturel. De plus, le 68000 a de nombreuses instructions et beaucoup de modes d'adressages. Ca apporte une grande flexibilité, mais en revanche ça fait beaucoup de choses à apprendre. Et parfois on peut faire la même chose avec plusieurs instructions, c'est troublant. L'idéal serait de prendre une documentation de référence du 68000 et de commencer par apprendre toutes les instructions. Le problème, c'est que si on commençait comme ça, on se demanderait vite : mais à quoi ça sert tous ces trucs compliqués ? Ensuite, il faut quelques notions de mathématiques. Heureusement, ce n'est pas compliqué, ça reste au niveau école primaire : additions, soustractions, multiplications, divisons. Mais on a souvent besoin d'utiliser des nombres écrits en binaire et en hexadécimal. Et ça aussi, ce n'est pas naturel. Rien de très compliqué, mais il faut se familiariser avec. Ensuite, il y a l'interface avec le système d'exploitation, au début et à la fin du programme. Je l'ai expliqué dans les premières vidéos, on n'a plus besoin d'y revenir. Mais le plus obscur, ce sont les structures de données, et notamment la manière dont les pixels sont codés dans la mémoire vidéo. C'est ce que présente petit à petit, avec des exemples. C'est très important, car peu importe le langage, ces structures restent toujours les mêmes. En revanche, la manière dont les pixels sont codés change un peu selon les modes vidéo et les machines. Quand on aura bien compris la base, on pourra faire le parallèle avec d'autres systèmes, et grâce à notre nouveau bagage ce sera facile de comprendre. Et j'oubliais encore un élément : le logiciel assembleur. J'utilise Devpac 2 car il est simple et agréable, mais bien sûr on peut utiliser un autre assembleur. Donc tout ça, eh bien ça fait une belle somme de connaissances à acquérir. Un mur infranchissable, si on ne s'y prend pas avec méthode. En fait, c'est un peu comme l'apprentissage d'une langue étrangère. Il faut commencer à pratiquer tout de suite. Apprendre quelques mots. Faire des phrases, même si au début on ne comprend pas tout. Apprendre quelques règles de grammaire. Et avancer petit à petit dans tous ces domaines. Et surtout, ne pas se décourager. C'est pour ça que je cherche des exemples variés. En illustrant avec des jeux connus, ça permet de prouver que tout ça n'est pas du vent, et c'est ludique. Donc en résumé, je sais bien que tout le monde ne pourra pas comprendre tout ce que j'explique dans ces tutos assembleur. Du moins pas dans l'immédiat. Mais ceux qui sont intéressés pourront tout de même apprendre quelques trucs, dans l'un des domaines cités. Et au bout d'un moment, tout ça deviendra familier. On pourra alors regarder à nouveau ces vidéos, plus tard, et comprendre ce qui nous avait échappé. En tout cas, c'est une belle aventure.
Je viens du C/C++ que je ne maîtrisait pas trop mal dans les années 90. J'avais développé un clone de Civilisation mais en post apocalyptique.
L'ASM m'a toujours paru comme un mur infranchissable à côté du C.
Mais je regarde tes vidéos, je me dit que je récupère déjà quelques bribes. Et si un jour, je veux m'y mettre, je sais que tes vidéos me seront précieuses 😁.
Tres bien expliqué, ça y'est ça revient ! Je pense déjà aux manips de bitplans et construction de sprites, LOL
Aha ! Ça sera l'objet de futures vidéos, bien sûr.
Vivement la suite sur les 4 bits plans, sur les chunks, le page flipping et la synchro VBL ... comment ça je réclame ? Oui bon d'accord je réclame un peu. Super vidéo !
Un petit scrolling vertical du bloc ça aurait mis appétit aussi :-)
Que des bonnes idées pour la suite 😊 Mais une chose à la fois.
Salut Vincent, j'y retrouve quelques similitude entre assembleur Atari et celui du 6809E Thomson.
Mais le 6309, qui est le successeur du 6809 possède quelques fonctions particulièrement puissante, comme la copie de blocs de RAM (en une seule instruction), des instruction de DIV et MUL sur 16 et 32 bits.
Oui, on s'aperçoit que même si tous les processeurs sont différents, il y a des principes de base qui reviennent toujours. Donc quand on connaît bien l'assembleur d'un processeur, on a des facilités pour apprendre celui d'une autre machine.
Je compte faire des cours en Langage Pascal sur Atari ST (il y a le HS Pascal et le Pure Pascal), c'est un langage vraiment très intéressant, qui a les avantages du C, Basic, C++ (Parce qu'il est aussi objet), et Java (Le Pascal peut être compilé en pseudo code).
Je ne sais pas si je vais utiliser majoritairement HS Pascal ou Pure Pascal. Les 2 ont l'air bien, même si Pure Pascal est plus récent de 1 ou 2 ans.
Du coup, j'y balancerait tous mes contenus de cours du CNAM (tris Quick Sort, Inversion de matrice, opérations sur polynomes, recherche opérationnelle etc etc)
Bonne initiative ! Plus il y a de cours, plus on peut apprendre.
Merci, c'est toujours super clair et super bien fait.
Sans transition : ferez vous une vidéo sur le GFA Basic Atari ? J'ai pas mal de vieux code dans ce langage, et je me demandais comment le traduire plus ou moins automatiquement dans un langage actuel (java, python, ou autre) pour l'exploiter, l'améliorer, dans un environnement moderne.
Bonjour, je suis content que ça vous plaise 😊 Non, je n'ai pas l'intention de faire de vidéo sur le GFA Basic, tout simplement car je le connais mal. En fait, les premiers ST étaient livrés avec le ST Basic, qui n'était vraiment pas terrible. Du coup, les utilisateurs se sont tournés vers le GFA Basic, qui lui était très bon. Mais pour ma part, j'ai acheté mon Atari STE très tard, en 1992. Et à cette époque il était livré avec l'Omikron Basic, qui était lui aussi très bon. Donc en pratique, j'ai beaucoup programmé en Omikron Basic avant de passer à l'assembleur et au C. Et je n'ai jamais eu besoin du GFA. Mais en effet, ce serait intéressant de faire le parallèle entre le GFA et les autres langages. Les similitudes et les différences.
@@Vretrocomputing Merci ! En effet, en 1992 je commençais à trahir Atari pour le PC ... ;)
@@RadurLeGenial Moi j'ai tenu jusqu'en 1997 😊 Mais ensuite c'était plus possible, je suis passé sur PC.
@@Vretrocomputing Belle fidélité, respect ! ;)
Nice stuff as usual!
Ah ! souvenirs... J'adorais mon ST et l'assembleur 68000...
Rien ne t'empêche de continuer aujourd'hui 😊
@@Vretrocomputing si, le temps à y consacrer au milieu du reste 😂
Sur Thomson, on a 16 kO de RAM vidéo, on n'a pas ces bloc de 16 pxl, mais en mode bm 16, qui fait 160 pxl de large, on a le même principe de 4 bits par pixel, sauf que sur Thomson ya cette foutue compatibilité avec les TO7 qui fait que c'est splitté entre RAMA et RAMB.
En gros quand tu démarres à l'adresse RAM écran 0, tu es en RAM A et balance 2 pixels (2x4 bits d'un octet de RAM A pour la couleur), donc ceci pour les pxl 0 et 1, pour les 2 suivant, c'est en RAMB (tu es obligé de faire la bascule), donc 2 autres pxl dans le même emplacement "logique" de RAM... La RAM vidéo est splitté en 2x8kO. Mais heureusement, avec le Gate Array Mode Page, il est possible de travailler dans la zone de RAM $A000-$DFFF, et là, on a les 8kO de RAM B qui sont dans les adresses basses et lles 8kO de RAMA sont dans la zone haute.
Eh oui, sur certaines machines même l'accès à la RAM vidéo peut être compliqué. Heureusement, avec le 68000 c'est juste une zone de ram contiguë, comme une autre. Ensuite, ce qui est compliqué avec les vielles machines, c'est que vu le faible nombre de couleurs, un octet sert à coder plusieurs pixels. Ca peut se faire de différentes manières. Mais surtout, pour modifier un seul pixel, il faut modifier seulement une partie d'un octet. Ca devient vite un casse-tête.
Hello, tu ne dis pas pourquoi on pourrait remplacer avantageusement ADD.L par LEA à 15:20 ? Le truc que je devinerai être vraiment avantageux serait de mettre un repeat 16 sur le move.l (a0)+,(a1)+ si toutefois devpac connait ce genre de directive!
Bonne remarque ! En effet, j'ai éludé la question. J'avais prévu de parler plus en détail de LEA, mais j'ai laissé tomber car ça compliquait les choses, et je ne voulais pas égarer inutilement les spectateurs. Il y a deux avantages à utiliser LEA plutôt que ADD.L : la place et la vitesse.
- La place : l'opérande de ADD.L est codée sur 32 bits. Alors que celle de LEA l'est sur 16 bits. Donc au total, ADD.L est codé sur 6 octets, alors que LEA prend seulement 4 octets.
- La vitesse : dans ce cas, ADD.L prend 16 cycles, alors que LEA n'en prend que 8.
Ces deux questions relèvent de l'optimisation, alors pour cette fois-ci j'ai laissé tomber pour ne pas perdre de vue l'objectif : expliquer simplement l'algorithme. La syntaxe de LEA étant plus compliquée, ça rend le code moins compréhensible. J'expliquerai tout ça dans de futures vidéos où la performance aura vraiment de l'importance, par exemple pour faire des animations.
Concernant ta deuxième remarque, c'est tout à fait pertinent : Devpac supporte les directives REPT/ENDR pour dupliquer du code plusieurs fois. Ainsi, quand on connaît à l'avance le nombre de tours de boucles, on évite de perdre du temps sur l'instruction DBRA. Au prix d'un code un peu plus gros, mais qui reste raisonnable sur de petites boucles. Mais l'optimisation idéale sur 68000, c'est d'utiliser l'instruction MOVEM qui permet de copier le contenu de plusieurs registres à la fois. C'est ce qu'il y a de plus performant pour copier de grandes zones de mémoire.
@@Vretrocomputing Merci pour ta réponse détaillée, je connais mal le 68000, j'arrive à le lire (j'ai beaucoup de mal avec les branchements) mais pondre de l'optimisé j'suis pas prêt donc je me renseigne doucement. Tu as des ouvrages (disponibles en ligne) à conseiller?
Les cours d'assembleur de Féroce Lapin sont parfaits pour débuter sur Atari.
atariste.free.fr/asm/assembleur.html
Salut Vincent, toujours un plaisir de regarder tes vidéos ! Petite question j'ai pris l'habitude d'écrire plutôt mes coordonnées sous la forme 160*y+8*x, où x est le numéro du groupe de pixels horizontalement. Je suppose que c'est équivalent, ou bien cela risque-t-il de me compliquer la tâche à l'avenir dans certains cas que je n'aurais pas encore rencontrés ? Et merci encore pour ces vidéos :) Vivement la prochaine !
Merci, je suis content que ça continue à te plaire 😊 Ta formule est parfaitement valide. Elle utilise le principe de base "offset = taille de l'objet * numéro de l'objet". J'ai choisi d'insister plutôt sur x/2, car il m'a semblé que c'était plus facile de se repérer avec des pixels. Mais les deux sont totalement équivalents, pas de souci.
Bon j'éprouve le besoin d'écrire mon raisonnement ici afin que l'on me dise si j'ai bien comprit :
admettons que je veuille connaitre l'adresse d'une coordonnée x et y : x=64 et y=39 (ligne n°40-1)
Je cherche d'abord l'adresse de début de la ligne 39, qui débute à : adresse écran + 39 fois 160 octets.
Puis sachant que x=64 est le 1er pixel situé à 8+8+8+8 octets du début de la ligne, ont l’additionne à l'adresse du début de ligne trouvé juste avant ? et comme 8+8+8+8 çà fait 32, çà revient à fait 64/2, ce qui permet de mettre X dans le calcule, est ce que j'ai bon ?
Oui, c'est ça. C'est la formule que j'ai indiquée à 4:29. Quant à la manière dont sont codés les 16 pixels dans les 8 octets, je l'expliquerai dans une prochaine vidéo.
Hellow from Russia
Hi, Alex. I hope that you enjoy Russian subtitles 🙂
Dès que j’aurai le temps, je ressors mon STF, mes 2 STE et mon Mega STE.
à l'époque programmé c'etait biezn casse couille. En tous cas, je faisais des jeu en Turbo Basic, et j'enmerdé moins à faire des sprites animés!
Suis-je le seul à n'avoir jamais jouer à Xenon ?
Ah, c'est dommage. A essayer. Mais attention c'est un peu spécial, à cause de la nécessité de jongler entre les modes tank et avion. Et surtout, le boss du niveau 1 est très dur, je l'ai rarement battu.