install df0:
copy sources:sinescroll.exe df0:
makedir df0:s
echo "sinescroll.exe" > df0:s/Startup-Sequence

	lea sinus,a6
	move.w (a6,d0.w),d1
	muls #(SCROLL_AMPLITUDE>>1),d1
	swap d1
	rol.l #2,d1
	add.w #SCROLL_Y+(SCROLL_AMPLITUDE>>1),d1
	move.w d1,d2
	lsl.w #5,d1
	lsl.w #3,d2
	add.w d2,d1
	add.w d6,d1
	lea (a2,d1.w),a4

	move.w (a2,d0.w),d4
	add.w d2,d4
	lea (a0,d4.w),a4

	cmp.l a1,a3
	bne _nextColumnNoLoop
	movea.l textColumns,a1
_nextColumnNoLoop:

_waitBlitter0\@
	btst #14,DMACONR(a5)
	bne _waitBlitter0\@
_waitBlitter1\@
	btst #14,DMACONR(a5)
	bne _waitBlitter1\@

_waitBlitter0\@
	btst #14,DMACONR(a5)
	bne _waitBlitter0\@

	move.w d3,d7
	ror.w #4,d7
	or.w #$0B4A,d7
	move.w d2,BLTCON0(a5)

	move.w d3,BLTCON0(a5)

Un lamer pourrait ripper notre beau sine scroll ! En particulier, il pourrait utiliser un éditeur hexadécimal pour modifier le texte qui défile. Pour se protéger de ce lamer, adoptons une protection de base dont il fera les frais s'il entreprend de s'y attaquer.

Pour que le texte ne soit pas apparent, nous devons l'encoder. Contentons-nous de combiner les octets de ses caractères par XOR avec TEXT_XOR, un octet de valeur quelconque. Ainsi, les caractères n'apparaissent pas comme des caractères dans un éditeur hexadécimal.

Et si tout de même le lamer devait deviner l'opération - ce dont nous lui laissons délibérément la possibilité en exposant le texte encodé à une attaque fondée sur l'analyse de récurrences -, calculons TEXT_CHECKSUM, un checksum du texte encodé, et rajoutons ici et là des appels à un code qui vérifie que le texte n'a pas été altéré. Ce code calcule le checksum du texte courant et le remplace par "You are a LAMER!" (de checksum TEXT_CHECKSUM_LAMER) si ce checksum ne correspond à aucun des checksums de nos désormais deux textes originaux :

Ne factorisons pas ce code, mais répétons-le, pour en demander l'exécution en divers endroits de sorte que le lamer ne puisse s'en débarrasser en substituant simplement un RTS à la première instruction de ce qui constituerait autrement son unique occurrence.

;Attention au contexte dans lequel la macro est utilisée, car elle peut modifier la longueur du texte initial (qui doit être au moins aussi long que "You are a LAMER!" sous peine d'écraser des données) et donc embrouiller le code qui était en train de le parcourir

CHECKTEXT:	MACRO
	movem.l d0-d1/a0-a1,-(sp)
	lea text,a0
	clr.l d0
	clr.l d1
_checkTextLoop\@
	move.b (a0)+,d0
	add.l d0,d1
	eor.b #TEXT_XOR,d0
	bne _checkTextLoop\@
	cmp.l textChecksum,d1
	beq _checkTextOK\@
	move.l #TEXT_CHECKSUM_LAMER,textChecksum
	lea text,a0
	lea textLamer,a1
_checkTextLamerLoop\@
	move.b (a1)+,d0
	move.b d0,(a0)+
	eor.b #TEXT_XOR,d0
	bne _checkTextLamerLoop\@
_checkTextOK\@
	movem.l (sp)+,d0-d1/a0-a1
	ENDM

Très easter egg. On est jeune, on rigole.

Coder en assembleur 68000 est un travail exigeant. Le nombre important de registres disponibles et le souci permanent d'en optimiser l'usage conduit le codeur à empiler et dépiler dans sa propre mémoire l'usage qu'il en fait tandis qu'il progresse dans l'écriture du code. Dans mon souvenir, celui qui code en assembleur 80x86 est moins confronté à cette exigence, car le nombre des registres est si faible et leurs usages tellement contraints qu'il est indispensable de s'appuyer sans cesse sur la pile du CPU, pile dont il est plus facile de se souvenir du contenu que de celui de 13 registres.

Je n'étais pas parti dans l'idée de me remettre à coder sur Amiga lorsque j'ai entrepris de revisiter le code d'une cracktro dans la série d'articles précédents. C'est en relisant l'Amiga Hardware Reference Manual que je me suis rappelé que je n'avais jamais poussé bien loin l'étude de la manière dont le Blitter trace des lignes, fonctionnalité que je savais être utilisée pour produire notamment un sine scroll. Finalement, j'ai voulu clarifier les choses, et j'ai programmé à partir de rien cet effet.

Plus généralement, en feuilletant ce manuel mais aussi ceux du 68000, j'ai pu constater combien j'étais resté sur une vision très superficielle du fonctionnement du hardware et du CPU à l'époque. Si j'ai donc une leçon à formuler, c'est que chaque fois qu'on s'intéresse à une technologie, il faut se donner la peine de lire scrupuleusement l'intégralité de sa documentation de référence plutôt que de se contenter, par pure fainéantise, de s'en remettre à son intuition.

C'est qu'à ce régime, on prend non seulement le risque de manquer des fonctionnalités importantes, mais de plus celui d'en mal comprendre certaines. Par exemple :

	btst #14,$dff002

De prime abord, cette instruction teste le bit 14 du mot se trouvant à l'adresse $DFF002. En fait, la lecture de la description de BTST dans le M68000 Family Programmer's User Manual révèle que lorsque le premier opérande est N et le second est une adresse, c'est le bit N%8 (ie : N modulo 8) de l'octet se trouvant à l'adresse qui est testé. En l'espèce c'est donc le bit 14%8=6 de l'octet se trouvant à l'adresse $DFF002 qui est testé. Cela correspond bien au bit 14 de l'octet de poids fort du mot se trouvant à cette adresse, si bien que notre intuition se révèle pertinente. Toutefois, c'est par chance. Présumer ainsi de certains fonctionnements peut générer des erreurs d'autant plus difficiles à corriger qu'on est loin de soupçonner où elles se logent.

La lecture de la documentation de référence s'impose donc toujours comme un préalable difficilement contournable pour qui souhaite maîtriser véritablement une technologie. Et je dis bien la documentation de référence dans le texte, et non une de ses formes vulgarisées. C'est qu'au prétexte de rendre un savoir accessible, la vulgarisation prend trop souvent des libertés avec ce dernier, empruntant des raccourcis et faisant des impasses qui ne font que fourvoyer le talent et encourager la médiocrité. Une forme vulgarisée d'une documentation de référence ne doit jamais être considérée que comme un point d’entrée sur cette dernière. Elle ne saurait dispenser d’au moins en tenter la lecture, quand bien même cette entreprise peut se révéler ardue. C'est que la tendance est malheureusement plus aux exposés formels que didactiques - les auteurs des spécifications des technologies du Web auraient tout à gagner à lire l'Amiga Hardware Reference Manual !

Ce sera tout pour cette fois, et sans doute pour toujours en ce qui concerne la programmation en assembleur de l'Amiga - à laquelle je ne m'étais pas adonné depuis bientôt un quart de siècle. Je dédie ce travail à un vieux pote, Stormtrooper, sans la motivation duquel je n'aurais jamais entrepris de me mettre au metal bashing à l'époque, et à tous ceux dont les pseudos défilent dans les inévitables greetings que pourront lire les courageux qui assembleront le source de ce sine scroll. "Amiga rulez!"

A l'occasion de la production d'une craktro récemment, il m'est apparu que j'avais oublié d'activer une option de WinUAE permettant une émulation exacte du hardware. Il s'agit de l'option Cycle-exact (full), dont l'activation entraîne celle de l'option Cycle-exact (DMA/Memory access) :

L'activation de ces options est indispensable pour espérer programmer fidèlement pour tout Amiga. A défaut, le CPU émulé dispose de beaucoup plus de cycles qu'il n'en dispose en réalité, car il ne se fait pas voler des cycles par le DMA. Autrement dit, le résultat observé dans WinUAE a toutes les chances d'être bien plus rapide qu'il ne le serait sur un Amiga bien réel.

C'est ce que j'ai pu constater dans le cas du sine scroll, fort heureusement uniquement quand l'étoile est rajoutée. Sur Amiga 1200, j'ai corrigé ce problème de la manière suivante :

• en limitant la zone remplie au Blitter dans le bitplane de l'étoile au rectangle englobant cette dernière ;
• en limitant la zone effacée dans le bitplane du sine scroll à la bande occupée par ce dernier, et en l'effaçant au CPU pendant que le Blitter remplit le bitplane de l'étoile ;
• en limitant la zone effacée dans bitplane de l'étoile au rectangle englobant cette dernière, et en l'effaçant aussi CPU pendant que le Blitter est toujours en train de remplir le bitplane de l'étoile.

Cliquez ici pour récupérer le source. Le temps pris par une itération de la boucle principale s'évalue alors à 240 lignes, ce qui laisse assez de marge pour rajouter de la musique.

Sur Amiga 500, cette optimisation par la parallélisation ne permet toujours pas de tenir dans la trame. La seule solution est donc de précalculer les images de l'étoile, et de copier l'image courante dans le bitplane de l'étoile au Blitter. Cette dernière étant un motif périodique, il est possible de se contenter de précalculer 360 / 5 = 72 images. Ce nombre est à diviser par la vitesse de rotation de l'image, sous condition que 72 en soit un multiple.

Cliquez ici pour récupérer le source. Le temps pris par une itération de la boucle principale s'évalue alors à 242 lignes - ce qui comprend aussi l'effet d'une limitation la zone effacée au Blitter dans le bitplane du sine scroll à la bande occupée par ce dernier -, ce qui laisse assez de marge pour rajouter de la musique. Bien évidemment, cette version tourne encore plus rapidement que la précédente sur Amiga 1200, puisqu'elle le temps pris par une itération de la boucle principale est alors réduit à 183 lignes :

Une conséquence de la "découverte" de l'option, c'est que les temps indiqués plus haut dans l'article sont donc faux. Le sine scroll tient bien dans la trame sur Amiga 500 et Amiga 1200, mais une itération de la boucle principale prend nettement plus de temps que ce qui avait été indiqué, à savoir 183 lignes sur Amiga 500 et 136 lignes sur Amiga 1200 :

Ainsi, tout est remis en ordre ! Toutes mes confuses.