Fadest (./5) :
C'est pas déconnant, vu que les déclarations sont faites dans des tableaux, ton .o inclut donc en plus les 25*11 octets de la déclaration du tableau.
Si tu ne veux pas cet effet de bord, tu peux être courageux et utiliser de l'allocation mémoire dynamique, pour peu que els fonctions existent dans le kit BLL et surtout qu'elles soient fiables, mais ça reviendra au même, tu consommeras de la RAM, il faudra donc prévoir d'en laisser libre une fois ton programme chargé.

Donc non, il n'y a pas de bridage conscient dans les outils pour empécher les gens de bosser. Les outils ne sont peut-être pas parfait, avec pleins de trucs bizarres, mais c'est pas fait exprès

J'ai terminé la conversion en sprites chainés.

gain: une économie de 3,53 Ko (j'ai optimisé de ci delà, donc le gain réel avec le chainage est en réalité moins important).
tableau: passage de 16320 à 20400, car sinon il y a de gros soucis d'affichage (j'ai rajouté au pif 4080 (16320+4080 = 20400) afin que tout s'affiche correctement).
malus: je ne pourrai pas rajouter énormément de ligne, encore que le compilo doit avoir une limite en nombre de caractère. // SCB est un tableau de 63 sprites de 11 octets chacun extern char SCB[62][11] at (0xfff8-20400-62*11);

Conclusion: il y a du pifomètre + limitation codage = galère