Logicielsmoto.com

Que fait le code machine suivant (32 octets):
Ou celui-ci (28octets, mais c'est quasi la même chose):
Question subsidiaire: peut on faire encore plus court?

Y a pas plus court comme code et tu peux tester, ça marche!

1) dessine une fractale triangulaire
2) dessine la même fractale triangulaire
3) en 20 octets : CE40008E14001A01ECC44656A8C0E8C0EDC826301E26F139
Résultat :

Oui, je le reconnais, ne pas modifier E7C3 c'est un peu tricher. Mais c'est 8 octets de moins et ça marche
Sur MO5, le SWI #$06 permet de gagner 6 octets.

Exact, c'est le triangle de Sierpinski. Bravo!

Héhé.. Squizage du passage en mode forme ($E7C3). C'est pas mal.

Le truc que je voudrais faire c'est le même mais plus symétrique horizontalement.

Ben j'ai trouvé une façon de le faire en 48 octets tout pile: (en pilotant $E7C3 sinon ca merdouille sous ASSEMBLER):

Sur MO5 on pourrait optimiser en partant du bas de l'écran et en remontant car le pointeur video servirait aussi de compteur jusqu'à zero. Est-ce optimisable sur TO ?

sam (le quizz continue)

Bravo !

C'est passionnant d'optimiser le code. Un peu comme au temps des deulignes d'Hebdogiciel. Je n'ai pas trop le temps aujourd'hui, mais c'est un exercice que j'aime bien. Prehisto doit aussi être très fort à ce petit jeu, il va sûrement trouver un code plus court.
Dans le même genre, j'avais fait à l'époque une routine PAINT pour le remplissage d'un contour quelconque, avec appel récursif. Et, toujours avec des procédures récursives, la résolution des tours de Hanoï.

Ah ben j'ai encore optimisé: 44 octets (gain 4) et maintenant tout le code tient à l'écran

On peut peut être se passer de la manip sur E7C3 et aussi effacer l'écran en générant un fichier BIN pour K7 dont le nom contient les codes d'echappement monitor pour effacer l'écran et en utilisant pour le lancer. Mais je ne sais pas faire cela à partir d'assembler.

Prochain challenge: avoir un triangle (presque) équilatéral.

Sous ASSEMBLER, la commande pour assembler sur cassette est :

>AC:xxxxxxxx

ou xxxxxxxx est le nom de fichier, avec ou sans suffixe 'BIN'.

Si tu veux que ton programme rende la main au Basic une fois exécuté, les registres S, CC et DP doivent être restaurés dans leur état initial avant le RTS de fin. Car bien évidemment, le programme rend la main au Basic par un RTS. SWI, c'est seulement pour l'Assembleur.

Enfin, si tu veux que ton programme soit exécuté en LOADM,,R, il faut définir l'adresse d'exécution en argument de la directive END :

Oui, mais c'est la création d'un fichier binaire dont le nom n'est pas de l'ascii mais qui soit que je voudrais exploiter (C'est la séquence ansi(?) pour éteindre le curseur, passer le tour en noir et l'écran en blanc sur noir). Il faudrait probablement générer le fichier binaire en basic.

Si l'écran forme est à 0, sans le curseur qui clignotte, on peut probablement se passer du b pour stocker le bit du 1er rora et utiliser la zone video pour cela. ca fait gagner quelques octets (j'ai la flemme de compter)

A quoi vous jouez, là ?
Tout ça pour gagner de la place sur quelques dizaines d'octets ?


Malheureusement, tout affichage (et en l'occurence l'effacement de l'écran), met l'écran en mémoire couleur. Donc un traitement préalable pour passer en mémoire forme est nécessaire.

Ouais.. et c'est aussi fun que les mots croisés. A la base la formule c'est dans le genre: ou avec un "and":(de mémoire). Le truc que j'aimerais réaliser en peu de code machine c'est ceci:qui produit un triangle plus équilatéral:

Tiens il suffirait d'afficher l'image en mode 80cols. A creuser...
___
(*) les "one lines" sont faux comme ils sont écrit tels quels car pour l'interpréteur basic le next fait parti de la branche "then". Or si on ajoute un else avec un next, l'interpréteur croit qu'il y a un next de trop et sort une error "next without for" car il ne fait pas de disjonction dans le flot de contrôle (ca sent le bug).

Il est très fort ce Sam

Bon ca y est j'ai réussi, sans passer par le mode 80 cols, et en 44 octets:

Le truc rigolo est le inc $E7C3 pour faire basculer en mode forme après l'affichage du chr$(12) par le moniteur!

@tomix3 bah tu sais, il n'y a rien de neuf sur le triangle de sierpinski en quelques octets. Les autres machines font cela depuis un certain temps déjà. Sur amiga ca se faisait à coup de blitter car c'est une formule finalement simple au niveau des bits (décalage + xor).

sam (il est quand même très cool l'asm 6809.)

PS: Je viens d'apprendre le décés de B.Mandelbrot grâce auquel je me suis mis à l'asm 6809 pour optimiser le calcul de son célèbre ensemble Et dire qu'il apparaissait Samedi dernier dans la rediffusion d'un documentaire (ou ici) sur ARTE (encore visible sur youtube). RIP.

http://pouet.net/prod.php?which=56079

26 octets sur Atari XL/XE...
Qui dit mieux ?

Ben Daniel à réduit l'une de mes 1eres versions à 20octets, mais on peut encore faire un peu mieux (19 octets): ou en langage machine
Les trucs: bon bien sur sous basic le plan forme est actif par défaut (même technique que Gilles), mais l'astuce 1 positionne le bit C à 1 en avec seul octet au lieu du "ORCC #1" (B vaut 0 implicitement au début), ensuite l'astuce 2 compare U avec $5400 sans altérer le bit C ce qui est super important pour l'algo. On peut réduire le code si on trouve un bout de ROM qui charge un des registres d'adresse avec $4000, positionne C place la mémoire video en mode forme. ($EEB2 semble positionner la ram video) Mais c'est limite non reproductible d'une version de ROM sur l'autre.