Ah oui c'est marrant : le clavier est tout perturbé, et si on appuies sur la touche "C" alors l'écran plante définitivement
NOTES:
- Sur TO7/T9000, c'est uniquement le caractère suivant tapé au clavier qui est perturbé, mais la touche "C" ne fait pas tout planter.
- On peut remplacer le PSET par "PRINT CHR$(31);" ca bug pareil. Ce n'est donc pas le LOCATE implicite du PSET qui cause soucis.
Explication (plausible) de ce qu'il se passe.
Le CHR$(31) est le début d'une séquence d'échappement du curseur pour le positionner à une coordonnée donnée. La sequence attendue est $1F(==31), $40+L, $40+C. Or là on envoie juste 31, c'est à dire le début de la séquence sans la fin. Ce sont les deux caractères suivants qui seront interprétés comme lignes et colonne. On fait SCREEN 0, qui se traduit part la séquence $1B,$23,$20,$40. Je pense que le moniteur interprète $1B et $23 comme des coordonnées et place le curseur en colonne $1B-$41==-38, ligne -30.. C'est à dire largement hors de l'écran. Le clignotement du curseur va alors perturber cet emplacement en RAM (probablement dans la page zero du moniteur) et faire passer un flag de l'état 0 à l'état $FF laissant croire au clavier que, par exemple, la touche majuscule-droite est enfoncée d'où les perturbations observées sur le clavier. Il termine alors l'affichage par le reste ($20), ce qui achève d'écraser les données en RAM hors espace écran, puis il avance le curseur d'une place, se rends compte qu'il est hors écran et le repositionne en haut et affiche le $40="@" que l'on finit par voir.
Autre bug possible avec le même principe de placer le curseur hors écran : faire "PRINT CHR$(31);:PRINT CHR$(27);:PRINT CHR$(35);".. on voit que le moniteur a alors un sacré gros problème (impossible à résoudre, même avec le reinit. prog. du MO5)