Re: Mes questions sur mon projet Coleco

[bfg]

Voila mon premier (et probablement dernier) programme assembleur sur Colecovision

https://youtu.be/uD5omwFFnog (a regardez en HD pour avoir le 60fps)


Alors vous emballez pas, c'est juste des expériences d'affichage, y a aucune mecanique de jeu derrière. On controle le personnage au pad mais on peut juste marcher vers la gauche ou la droite. Je voulais surtout m'amuser a faire du smooth scrolling au pixel a 60fps (mettez la video en HD pour avoir le 60fps) sur cette machine ou y a aucun scrolling.
Je pré-shift simplement tout le tileset au démarrage du jeu. Le gros atout de la Colecovision a l'epoque c'etait d'avoir beaucoup de VRAM mais en général totalement gaché par le mode 2. Et combiner a la flexibilité de l'adressage de toutes les tables on peut pas mal s'amuser avec cette VRAM je pense. Donc je voulais faire un truc qui profite au max de ca (evidement le pré-shift c'est une autre facon de gaché la VRAM) d'autant que comme par hasard on peut justement adresser 8 bank differente pour le tileset et c'est exactement ce qu'il fallait pour faire un smooth scroll au pixel.
Au final une fois tout bien préparé au démarrage du jeu l’intégration du smooth scroll est extrement simple. Je prend les 3 bit de poid faible des coordonnée X de ma camera et je les envoie dans le registre d'adresse de la table du tileset et c'est tout. A ce moment la ca prend aucune ressource CPU, c'est comme si l'offset au pixel etait hardware (facon C64 ou Intellivision).
Reste quand meme a faire le scrolling lui meme qui est software et qui demande a mettre a jour toute la tilemap. Je le fais en double buffering etalé sur 3 frames et au final ca prend peu de ressource aussi.
En tout pour toute la gestion du scrolling de A a Z ca me prend a peine 20 scanlines (soit 7.5% de ressource CPU) et avec du triple buffering (ou un scorlling bloqué dans une seul direction genre Contra)  ca prendrait encore 2 fois moins. Et le Vblank est tellement long (ca fait bisarre quand tu viens de la NES) que ca rentre largement pendant le Vblank . Par contre ma tilemap n'est pas compressé donc ca simplifie beaucoup les choses evidement (et puis j'ai fait un petit script python pour transformer les 4 tilemap 256x192 en une seule tilemap 1024x192 pour que ce soit encore plus optimale)
Evidement c'est rigolo ce smooth scroll parfaitement fluide sur Coleco mais c'est beaucoup de contrainte pour la construction du background en terme de couleur et de variété de tuile (faut penser les tuiles en binome) mais ca reste faisable.
Par contre la partie sprite est completement bullshit, alors oui ca tourne sur Coleco mais on pourrait pas faire un vrai jeu avec des sprites de cette qualité, la je me suis fait plaisir sur la demo parce qu'il y a qu'un seul sprite et parce que je voulais tester aussi l'affichage de sprite.
D'ailleurs pour ceux qui n'ont pas reconnu le level est piqué en grande partie de Megaman 2 et le sprite de Shatterhand.

Je crois comprendre le principe, mais je comprends pas comment tu construis la map ... Les tiles sont forcément dépendantes les unes des autres, et je bloque à visualiser la truc ...

[Tryphon]

Je suppose qu'il y a une map par offset modulo 8, sauf que ça ferait 8 maps et il dit qu'il n'y en a que 4. Peut-être des redondances (je suis claqué, mais j'ai l'impression qu'on pourrait s'en sortir avec 2 maps).

[TotOOntHeMooN]

Il n'y a qu'une map, c'est le tileset qui est "updaté" (pointeur en VRAM) pour simuler son scrolling au pixel, 8 fois par char.

[Tryphon]

Si t'as un truc genre :
111222
où 1 = carré noir, et 2 = carré blanc
Quand tu le bouges d'un pixel (mettons vers la gauche), la transition 12 doit bien utiliser une autre tile non ?
Ça va donner :
113222
où 3 est une tile formée d'une ligne blanche à gauche d'un carré noir ?

[TotOOntHeMooN]

tu as normalement des tiles de jointure pour faire la transition. 
Plus ta map est variée et plus ils sont importants...

Comme ici:

Ce qui est intéressant avec cette technique, c'est que tu peux animer gratuitement ta map sur autant de frames.

[upsilandre]

Pour revenir sur le Z80 j'avais l'espoir qu'avec tout ces registres et ce jeu d'instruction tres riche par rapport au 6502 ca permettrait un code plus condensé et lisible et en vrai c'est tout l'inverse, le jeu d'instruction est complexe et alambiqué avec plein de cas particulier pour chaque registre qui oblige donc a plein de va et viens entre les registres et des modes adressage tres limité et du coup c'est au final un code sensiblement moins lisible que sur 6502.
Le 6502 a tres peu de registre mais il est entièrement concu pour que la première page de la ram servent de registre, son jeu d'instruction est concu autour de cette idée,  du coup t'as 256 registres ce qui permet d'avoir en gros un registre par variable et surtout une étiquette par variable visible dans ton code alors que le Z80 est pas du tout concu pour bosser directement avec la RAM, y a d'ailleurs aucune operation arithmétique /logique /shift /test... applicable directement vers ou a partir de la RAM comme pour le 6502, faut passer d'abord par l’intermédiaire des registres. Le Z80 est centré uniquement sur ses registres interne (la ou le 6502 ets centré sur la page 0) et te pousse a faire de gros bout de code sans toucher a la RAM et donc non seulement tes variables sont donc des registres anonymes (donc pas d’étiquette visible meme sur de gros bout de code) mais elles ne cessent de changer de registre pour s'adapter au spécificité de chacun et donc c'est au final beaucoup moins lisible que du code 6502.

Les mode d'adressage sont ultra rudimentaire. T'as pas d'adressage indirect pour les pointeurs. Sur le 6502 tu a de l'adressage indirect (donc en gros le concept de pointeur est cablé en hard) notamment parce qu'ils avaient pas le choix puisque t'as pas de registre 16bit pour manipuler des adresses (donc encore une fois le 6502 utilise la page zero comme registre). Sur le Z80 la présence de registre 16bit permet de se passer de cette option puisqu'on peut manipuler des valeur 16bit mais au final ca manque d'avoir un veritable adressage indirect.
Le pire c'est l'adressage indexé avec ix et iy, quelle merde ces registres, leur jeu d'instruction est tres limité (surtout si tu te limite aux instruction non officiel c'est la cata) et leur principe est inversé par rapport au 6502, t'as une valeur fixe sur un octet + un index sur 2 octets au lieu d'une valeur fixe sur 2 octets (l'adresse du debut de ta table) + un index sur un octet pour te deplacer sur cette table (l'idéal serait 2 + 2). C'est nulle a l'usage (en plus d'etre couteux en cycle, c'est des opcodes alternatif sur 2 octets).

Si on prend la situation assez classique ou t'as dans ton accumulateur un resultat qui va te servir d'index pour récuperer la donnée qui t’intéresse vraiment dans une petite table. Sur le 6502 tu fais:

Code:

tax
lda tableAddr,x

C'est simple , claire, ca prend 6 cycles (7 si t'as pas de chance et que t'es a cheval sur 2 pages)
Sur Z80 ca va ressembler a un truc comme ca:

Code:

ld hl,tableAddr
ld e,a
ld d,0
add hl,de
ld a,(hl)

C'est laid et ca prend 39 cycles.
Au final pour simplifier ce genre de situation et eviter que ca ressemble a ca t'es un peu obligé d'aligner toutes tes tables sur des debuts de pages dans ce cas ca prend plus que 3 lignes et 18 cycles si je ne m'abuse donc ca va mais c'est chiant de devoir aligner toutes tes tables et peut couter en espace. Sur 6502 t'as pas besoin de te soucier d'ou se trouve ta table (sauf si tu veux gagner un cycle)
En fait sous prétexte que tu peux manipuler des adresses 16bit en interne alors faut tout faire soi meme. que ce soit l'adressage indirect ou indexé (Sur 6502 t'as meme de l'adressage indirect indexé).

Et d'ailleurs décu aussi sur les operations 16bit. Je m'attendais a ce que ce soit un atout mais au final y a quasiment rien comme instruction 16bit. Y a pas de soustraction 16bit ni operation logique ni shift/rotate et on peut pas faire d’addition avec une valeur immédiate. Y a pas non plus de comparaison 16bit et un dec/inc n’affecte meme pas les flag (on peut donc pas utiliser une valeur 16bit directement pour un branchement conditionnel ou un compteur de boucle).
On peut quand meme additionner et inc/dec (et pop/push) ce qui est bien utile mais c'est trop leger pour que ce support du 16bit fasse une difference notable.


Je préfere vraiment le 6502. Le 6502 est impressionnant car c'est un CPU de seulement 3500 transistors! bordel on se demande deja comment un CPU peut fonctionner avec si peu de transistors (moi ca me fascine) donc rien que la deja y a une sorte de satisfaction car c'est presque magique mais en plus il se contente pas de fonctionner, il se permet d'etre performant a fréquence tres basse et simple d'acces.
Du coup j'avais des attentes pour le Z80 et ses 8500 transistors. Alors ces transistors on les sent quand meme, on voit bien qu'il y a plein de registre et d'instruction mais ce que ca apporte est assez paradoxale car y a plus de negatif que de positif je trouve.
Cela dit faut quand meme que j'evoque aussi les truc que j'ai bien aimé...

[Invité]

Je me rappelle bien de ces exemples quand j'avais fait un peu d'ASM avec mon CPC à l'époque.
Ne connaissant aucun autre CPU, je me disais que pour les autres c'était pareil !! ^^

Pour en revenir à ma précédente question, vous y avez répondu avec brio, merci !!
Je voulais juste savoir s'il existait des combines pour avoir des Sprites colorés dans une même scène et alignés bien sûr.
Après je ne me risquerai à aucune discussion technique avec vous ... Je vous laisse entre Jedi.

[upsilandre]

Je crois comprendre le principe, mais je comprends pas comment tu construis la map ... Les tiles sont forcément dépendantes les unes des autres, et je bloque à visualiser la truc ...

la tilemap elle reste tout a fait classique, c'est le tileset qui est dupliqué 8 fois avec un décalage sauf qu'effectivement chaque tuile du tileset va etre dépendante de la tuile qui se trouve a sa droite dans la tilemap donc faut penser les tuiles en binome.
Si la tuile A peut se trouver a la fois a coté d'une tuile B mais aussi d'une tuile C dans la tilemap alors dans ton tileset tu devras prévoir 2 tuiles A (une pour pour le pré-shift avec B et une pour celui avec C) multiplier par 8 tileset (donc 16 tuiles A).

[Stef]

Upsilandre> Ta vision du Z80 montre quand même des "déformations" de part ton habitude du 6502 même si je suis d'accord sur un bon nombre de reproche que tu fais au CPU. Les modes d'adressage que tu cites sont effectivement obligatoire sur 6502 par manque de registre d'index 16 bits... mais je suis d'accord que le Z80 est frustrant sur plein de points.
Aussi le mode d'adressage du IX et IY a son utilité, ça te permet de parcourir un tableau de structure par exemple assez facilement, et pour un compilateur C ça va être très utile ce genre d'instruction, mais quand tu es en assembleur tu les utilises même pas tellement elles sont lentes (ces registres ont d'ailleurs disparu sur le CPU de la GB) !
Aussi il y a d'autres subtilités que tu découvriras avec le temps (notamment avec la gestion de la pile et les instructions d'échange) et tu te rendras compte que le CPU est moins mauvais qu'il y parait...
Et si je trouve que le Z80 est vraiment pas efficace en général, je trouve le 6502 pas mieux voire pire à ce niveau (je compte en cycle mémoire, pas en cycle CPU car ça n'a pas vraiment d'intérêt)... je me demande combien de transistors il y a dans le GB CPU, le 6800 et le 8080 ont environ 4000 transistors et ils s'en sortent pas mal à coté du Z80 qui en comporte le double

[upsilandre]

Bon maintenant les truc que j'ai bien aimé sur le Z80
Y a des instructions qui sont tres sympa. Le djnz qui est un branchement conditionnel si nulle et qui decremente en meme temps le registre qui sert de test, tres pratique pour les boucles classique, une instruction que j'aurais bien aimé sur le 6502. Et globalement y a du branchement conditionnel pour a peu pret tout, aussi bien les jump absolu que relatif que les call et les return de subroutine (alors que sur 6502 les branchement conditionnel c'est limité au jump relatif), ca c'est pas indispensable mais sympa, ca surprend quand tu viens du 6502.
Un truc que je trouve vraiment dommage sur le 6502 c'est qu'on a qu'un type de add (et sub) et c'est la version avec carry donc adapté pour une addition 16bit (histoire de pas ralentir plus les operations 16bit) mais pas 8bit, donc avant chaque addition t'es obligé de clear la carry (sauf si le contexte le fait a ta place), sur le Z80 tu a le choix des operations arithmétique avec ou sans carry selon les besoins, j'aurais bien aimé sur le 6502 avoir au moins les 2 add, on aurait pu profiter a fond de la rapidité des add du 6502.
Le outi (voir otir) qui incremente automatiquement la source c'est tres pratique pour communiquer avec le GPU qui lui aussi s'auto-incremente. D'ailleurs le Z80 a vraiment des instructions spécifique pour les port (et un signal suplementaire qui s'ajoute au bus d'adressage) ce qui permet de séparer les port du mapping mémoire du CPU (donc on a 64Ko entierement dispo pour la RAM/ROM) et surtout l'interet de ces instructions c'est qu'au lieu de manipuler des adresse 16bit elle manipule juste une adresse 8bit (256 ports) ce qui rend donc l'adressage des port plus rapide que la mémoire (l'inverse du 6502 et sa page zero qui est un adressage 8bit mais 16bit pour les port qui sont simplement dans le mapping mémoire du CPU) couplé au outi et otir ca donne un truc assez efficace.
J'aime bien aussi les instructions de test, on peut tester n'importe quelle bit de n'importe quelle registre (donc sans le modifier), sur le 6502 tu peux juste le faire sur le bit 7 ou 6.
Et la syntaxe est plutot pas mal, les ld avec la source d'un coté et la destination de l'autre c'est moins sujet a l'erreur je pense que les sta et lda que j'ai du inversé je ne sais combien de fois (mais bon la syntaxe c'est pas vraiment une histoire de cpu mais de convention).

Sinon dans les curiosités plus anecdotique t'as la possibilité de faire des operations arithmétique et logique de l'accumulateur avec lui meme (ca donne des truc un peu paradoxale, comme le add a,a qui est plus rapide pour faire un shift vers la gauche que l'instruction shift elle meme)
T'as aussi des variantes pour le shift et le rotate qui peuvent etre utile. Et les chargement de registre n'affect pas les flag contrairement au 6502, la y a du pour et du contre. pour un branchement conditionnel tu peux pas tester directement une valeur en la chargeant ce qui est pratique sur le 6502 mais ca peut aussi etre génant en t'empechant de charger un registre avant un branchement conditionnel.

Mais je pense que ce qui a fait le succes commercial du Z80 (notamment en arcade) c'est probablement sa plus grande flexibilité pour s'adapter a n'importe quelle hardware. Sa capacité a pouvoir se connecter directement a de la DRAM (et le marché a du vite basculer de la SRAM a la DRAM), son systemes d’interruption plus evolué (ce qui inclus les registres miroir), peut etre ses port plus simple a cabler sans polluer les 64Ko.
Je pense qu'on pouvait facilement l'integrer a n'importe quelle machine. C'est sans doute plus par ca qu'il a séduit que pas son jeux d'instructions ou son nombre de registre.

[TotOOntHeMooN]

Au début, pour sa compatibilité Intel 8080 quand même.

[upsilandre]

ah oui c'est vrai, le 8080 on le trouvais pas mal en arcade.
Mais la DRAM a beaucoup joué je pense.

[Stef]

Je vois que tu as quand même pas mal pris le temps d'étudier le Z80 après lecture de ce deuxième message... tu arrives à prendre du recul et contrairement à ce que je disais dans le premier message tu n'es pas trop déformé par la vision du 6502 (juste un peu peut être)
Le coup de l'instruction d'addition, on sent vraiment une économie de bout de chandelle mais à choisir je pense qu'il vaut mieux le ADC que le ADD tout de même, ça serait trop pénalisant pour les additions 16 bits (qui reste fréquente).

Comme Upsilandre je pense que le Z80 plaisait beaucoup à l'époque non pas par sa puissance et son jeu d'instruction mais plutot par ses fonctionnalités (gestion de port) et le fait qu'il soit capable de rafraichir de lui meme la DRAM (plus économique que d'utiliser un circuit dédié ou de la SRAM).

En lisant un peu plus les specs du GB CPU, ils ont tellement supprimé de choses dessus que le CPU se rapproche presque plus d'un 8080 que d'un Z80   Mais pour le coup, pour moi ils ont vraiment viré ce qu'il fallait et ajouter quelques instructions très pratiques. Je suis sur que le CPU tient dans 5000 voire 6000 transistors et n'est pas moins bon qu'un Z80

[Invité]

@upsilandre: tu devrais tester le Hu6280,il enlève bcp de frustration que tu peux avoir avec un simple 6502, sauf l'unique accumulateur .

Mais la DRAM a beaucoup joué je pense.

je pense aussi, avoir le rafraichissement de la DRAM intégré au CPU était un atout je pense .

[TotOOntHeMooN]

Je me demande quelle machine utilise le signal rfsh du Z80.
Pas la Coleco, pas le CPC, pas la SMS, pas la MD en tout cas.

Si je m'abuse, il suffit de coller un clock dérivée de la CPU (voir sa clock direct) sur la DRAM pour la rafraîchir.

[upsilandre]

J'ai voulu tenter d'utiliser les fonctions du bios PUTOBJ pour faire bouger un sprite software mais impossible d'avoir un truc fonctionnel, je vois le sprite bougé mais c'est completement glitché, y a 1000 truc a paramétrer, y avait peu d'espoir que ca fonctionne a la fin (je serais pas surpris que ce soit pas mal buggé, je serais étonné que ca ait ete utilisé).
C'est pas grave je voulais juste voir combien de temps prenait la routine et ca prend environ une frame par sprite software
Et meme probablement plus (le buffer qui sert normalement a la restauration ne semble pas etre utilisé)

[TotOOntHeMooN]

C'est cool d'avoir essayé ! 

[fanoplusplus64K]

Parce que des projets Homebrew terminés et réalisés en "Full ASM", j'en vois pas des masses en fait.

Parce que ça demande un investissement initial en terme de code beaucoup plus conséquent qu'en d'autres langages, mais au final le résultat est un cran au dessus en terme de performance (rapport vitesse/occupation mémoire)

Voila mon premier (et probablement dernier) programme assembleur sur Colecovision

Bravo, c'est bien fait, très bonne idée ce preshift, ça donne super bien, du premier coup d'oeil on pourrait penser à une NES même si c'est effectivement inexploitable dans un jeu sauf avoir des contraintes monstrueuses.
Perso, je trouve que le mode II de la coleco donne vraiment des résultats superbes, l'inconvénient c'est surtout le manque de RAM de la machine qui empêche de l'exploiter autant qu'on voudrait comme sur MSX (ah gradius!)

Je ne vais pas revenir sur le débat sur le Z80, j'ai d'ailleurs du mal à avoir un avis objectif sur ce CPU car c'est celui avec lequel j'ai appris à programmer.Perso, le plus gros reproche que j'ai à lui faire c'est le manque d'orthogonalité.Je pense qu'il faut aussi le resituer dans son époque, le set d'instructions est loin d'être pourri et je trouve qu'il est assez agréable à programmer une fois bien connu.Sinon, les opérations sur l'accumulateur sont justement extrêmement utiles dans le sens où charger un registre ne modifie par les flags, ça permet de tester l'accumulateur ou encore d'étendre la carry...
Après , j'ai envie de dire qu'effectivement ce n'est pas toujours facile à programmer dans le sens où il est plein de spécificité qui demandent à être connues pour en tirer le meilleur parti...

[upsilandre]

C'est cool d'avoir essayé ! 

D'ailleurs je vous met au défi de réussir a utiliser ces fonctions du bios, c'est beaucoup plus dure que de faire un smooth scrolling mutlidirectionnel
je soupçonne quand meme fortement que ce soit tres buggé car j'avais deja repéré un gros bug rien que sur la fonction de base PUT_VRAM qui permet de charger une table.
Je trouvais ca cool a utiliser au démarrage (ca economise des lignes de code) mais c'est buggé. Tu indique quelle table du veux charger (par exemple le tileset du background), a quelle index de la table tu veux commencer et combien de tuile tu veux transferer et c'est sur ce dernier critère que ca deconne. Si tu met un multiple de 32 ca fonctionne (32, 64, 96, 128...) mais si tu met 85 tu auras pas 85 tuiles mais 85 - 32 = 53 tuiles. Je suis aller voir en debug le code de la fonction dans le bios pour voir si c'est pas moi qui etait fou mais non j'ai bien trouvé l'erreur, y a effectivement un mauvais branchement conditionnel dans la boucle qui charge les tuiles ce qui lui fait sauter une rotation.

Je suis un peu décu car j'aimais bien l'idée du Bios mais soit c'est des fonctions quasi inutile (genre write_register, ca te prend quasiment autant de ligne que de le faire toi meme), soit c'est buggé, soit c'est ultra complexe et lourd en ressource. Donc je sais pas trop, je suis mitigé. J'aimerais bien savoir si c'etait utilisé (faudrait que je teste des jeux en mode debug).

[TotOOntHeMooN]

En fait, le BIOS c'était une bonne intention... Mais il aurait fallu qu'ils le test. 

[fanoplusplus64K]

Le gros souci sur des machines aussi petites c'est de faire des routines qui puissent convenir à tout le monde et performantes à la fois.
Malheureusement sur Coleco, comme sur d'autres d'ailleurs (va faire un jeu avec l'OS du CPC ) , c'est souvent incompatible et du coup on se retrouve avec un bios qui sert pas à grand chose.

[TotOOntHeMooN]

En fait, le BIOS ça fait bien une chose pour tout le monde : Pourrir les 64K d'adressage ! 

[upsilandre]

J'ai regardé quelque jeux au pif et ca utilise massivement les fonction de l'OS par dizaines d'appels et pas seulement au boot mais ingame.
L'usage des fonction graphiques a l'aire plus rare mais sur Donkey Kong j'ai chopé du PUT_VRAM (mais en chargeant chaque fois moins de 32 tuiles du coup ils evitent le bug), du flip horizontal de sprite et meme du PUTOBJ (sur de l'objet de type "complex" donc composé de plusieurs objet, probablement plusieurs sprite pour gérer un metasprite). Je crois que sur Donkey Kong quasiment toutes les fonctions de l'OS doivent y passé.
Par contre je pense pas que je trouverais un jeu qui utilise du PUTOBJ sur un objet "mobile" (sprite software)

[upsilandre]

Et donc vous utilisez quoi comme traducteur ASM et comme emulateur/debugger?

[fanoplusplus64K]

Et donc vous utilisez quoi comme traducteur ASM et comme emulateur/debugger?

Traducteur ASM ? , sinon j'utilise BlueMSX en emulateur/debugger, parfois mame.

[upsilandre]

On peut vraiment debugger avec BlueMSX? j'avais regardé vite fais et ca me semblait pas vraiment fonctionnel mais j'ai pas creusé, je suis resté sur Mekka.
et tu compile ton code avec quoi?

[fanoplusplus64K]

Oui, il marche plutôt bien même, tu peux même importer les symboles générés par ton assembleur.
En assembleur, j'utilise sjasm, qui est un des assembleurs parmi les plus avancés pour Z80.

[upsilandre]

ah oui effectivement ca fonctionne en faisant "break all" car par defaut il te met "dissassembly unavailable", j'avais pas ete plus loin. effectivement ca a l'aire plus fournit car le debug de mekka c'est le strict minimum, c'est en ligne de commande (mais ma petite experience me servira pour la master System)

edit: et les symbole ca marche, cool.

Et sinon vous utiliser le terme "compiler" pour l'assembleur? J'ai toujours du mal a considérer ca comme de la compilation, ca ressemble plus a de la traduction de mnemonique (et calculer les labels)

[ichigobankai]

Je connais pas sjasm.
Perso j'utilise wla-dx, assez connu comme assembleur Z80 (entre autre)

[fanoplusplus64K]

Et sinon vous utiliser le terme "compiler" pour l'assembleur? J'ai toujours du mal a considérer ca comme de la compilation, ca ressemble plus a de la traduction de mnemonique (et calculé les labels)

On utilise normalement le terme assembler même si on a tendance à dériver et utiliser le terme compiler pour tout, après sur les assembleurs 'modernes' tu as énormement plus que de l'assemblage bête et méchant avec des macros, des structures, des modules etc...

[Tryphon]

Perso je dis "assembler", c'est ce qui se disait quand j'ai appris l'assembleur (vers 1990)...