Je veux faire quelques commentaires sur l'initialisations des balles :
1. Il faut constater que les coordonnées X sont deux octets (0-303) pendant que les coordonnées Y sont un octet (0-240).
2. Pendant le premier appel à LFSR_PRNG il n'y a que deux valeurs qui nous importent : 1 et -1. Donc on AND le numéro reçu avec $2, nous donnant ou 2 ou 0. Si nous soustrayons 1 ça nous donnera 1 ou -1, les vélocités que nous voulons. On fait la même chose pour la vélocité Y.
3. Ce que la routine LFSR fait c'est donner un numéro "aléatoire" qui ne se répète pas jusqu'à ce que tous les autres numéros seront donnés, donc si ton seed est 1, tu n'auras un autre 1 jusqu'après 255 itérations. C'est la même progression de numéros, chaque 255 itérations le pattern se répète. Je ne sais pas à quoi sert le set 6,a, peut-être pour avoir des valeurs plus hautes ? En tout cas le numéro sorti sera toujours entre 64 et 255.
4. Pour la coordonnée Y, c'est exactement comme tu dis. Si le numéro dépasse 240, on soustrait 128 (and $7F) pour avoir un numéro entre 112 et 127. Donc la coordonnée Y va toujours commencer entre 112 et 240.
5. La valeur de de n'a pas changé, donc on y ajoute 20 pour déplacer la coordonnée X 20 pixels vers la droite.
6. Je crois que le c c'est un vestige d'une version ancienne, maintenant le ld a,10 \ add a,c \ ld c,a ne sert à rien :P Il parait qu'auparavant on utilisait c pour garder la coordonnée Y.

x, xvel, y, yvel (4 bytes)

N'oublie pas que la coordonnée X = 2 octets

EDIT : Oh ! Et il semble que les boîtes de code sont toujours la même taille, même si le code n'occupe pas toute la boîte. Je crois que c'est très intéressant, cette idée ! Je crois que l'on peut analyser des bouts de code plutôt que des programmes entiers (par exemple, comment fonctionne le trajectoire des balles dans Phoenix, etc.)