Par contre y aurait il un avantage à convertir les instructions BASICODE en LM 6809
Je ne connais pas assez les fonctions du BASCODER, mais j'ai pas l'impression qu'il faille du LM car le basic Thomson est suffisamment avancé pour avoir des instructions de "haut-niveau" : on est loin du C64 où il faut poker pour changer les couleurs à l'écran ou jouer de la musique. Note: il manque l'affichage de chaines au pixel près en mode graphique en basic Thomson. Dans tous les cas il faudrait garder les points d'entrée normalisés (numéros de lignes) et y mettre un EXEC vers le point d'entrée ASM. On aurait donc toujours quelque chose entre les lignes 0 et 1000, sans compter le surcout en mémoire des routines en LM.
Evidement, certaines instruction du BASICODER faites par Thomas seraient plus rapide en ASM, mais je pense qu'il y aurait déjà moyen d'en coder certaines plus efficacement en BASIC1 simplement en utilisant des tableaux précalculés. Par exemple la lecture d'un caractère au clavier
Code : Tout sélectionner
200 IN$=INKEY$:GOTO 214
210 IN$=INKEY$
212 IF LEN(IN$)=0 THEN 210
214 IN=ASC(IN$+CHR$(0)):IN=IN-20*(IN=11)-20*(IN=8)-20*(IN=10)-20*(IN=9)-98*(IN=29):RETURN
pourrait être réécrite comme suit:
Code : Tout sélectionner
200 IN$=INKEY$:GOTO 212
210 IN$=INPUT$(1)
212 IF DECODE%(1)=0 THEN DIM DECODE%(127):FOR IN=0 TO 127:DECODE%(IN)=IN-20*(IN=11)-20*(IN=8)-20*(IN=10)-20*(IN=9)-98*(IN=29):NEXT:REM <- PRECALCUL TABLE DECODAGE
214 IN=DECODE%(ASC(IN$+CHR$(0))):RETURN
Mais est-ce que ca changerait beaucoup les performances du code ? C'est une saisie au clavier, pas besoin d'aller super vite. Sans compter que la table de décodage mange 254 octets précieux alors qu'à la base toutes les variables du Basic Thomson (et donc dans cette incarnation du BasiCode) sont des nombres flottants sur 4 octets donc intrinsèquement lentes à traiter.
Ca serait d'ailleurs un truc à regarder de plus près: est-ce que le BasiCode impose aux variables d'être des réels ou peut-il marcher avec certaines variables (les O<quelque-chose> ?) en entiers 16bits auquel cas il serait plus rapide pour certaines opérations n'utilisant que ces variables O<quelque-chose>. Ou alors l'inverse: toute les variables sont des entiers 16bis, et seules les H<quelque-chose> et V<quelque-chose> seraient des nombres flottants (utilisées pour les coordonnées écran entre 0.0 et 1.0). Je n'arrive pas trop à savoir. Peut-être que Thomas (s'il arrive à traduire ce que j'écris) pourrait nous éclairer ?
[EDIT] Cette spec indique que les valeurs numériques sont des nombres flottants simple précision. Bon c'est fichu pour accélérer les calculs avec des entier 16bits, et pire: leur traitement en ASM est super super pénible et pas tellement plus rapide que le basic au final.
En fin de compte peut-être que seule la lecture des données en binaire sur casette devrait se faire nécessairement en ASM (le basic étant trop lent), mais uniquement sur MO dont le magnéto est plus versatile que celui du TO lequel est incapable de lire les signaux carrés décrit dans
le standard.
