Suite à l'article précédent, j'ai mis sur le dépôt GitHub un petit utilitaire Python qui reproduit les conversions entre la valeur du nombre et son codage en 4 octets.
Parfois, voir du code est plus simple qu'un long discours.
Et parce qu'on ne sait jamais trop quel sera la vie future du dépôt, voici le code des deux principales fonctions de l'outil.
importmathdefget_byte(number):"""Takes the current number, and returns the next byte encoding it with the reminder of the number to encode. """number*=256result=int(number)returnresult,(number-result)defencode(number):"""Gets a number, returns it's encoded four bytes (memory layout, so exponent at the end)."""# If the number is zero, the encoding is immediate.# In fact, only the exponent has to be 0.ifnumber==0:return[0,0,0,0]# Gets the sign from the number for later encoding …
Lors d'une discussion sur le forum system-cfg à propos de la fonction RND une question a été posée sur le format des nombres dans le VG5000µ. C'est une question qui revient et que je voulais documenter pour mémoire, me posant régulièrement la question et oubliant juste après...
Différents formats
Distinguons déjà deux choses : les nombres manipulés par le système, et les nombres manipulés par le BASIC. Les premiers sont de diverses formes en fonction des besoins, de type entier, signé ou pas, sur 8 ou 16 bits la plupart du temps. Il n'y a pas grand chose à dire sur eux.
Les seconds sont ceux manipulés par le BASIC, qui est un BASIC Microsoft sur VG5000µ, et ce qui sera valide dans cet article le sera pour d'autres machines avec BASIC Microsoft et un processeur Z80. Au moins dans les grandes lignes, mais pour ce que j'ai vu en comparant …
Depuis quelques temps, je planche à mes heures perdues sur ma prochaine vidéo. Et le sujet est le langage de programmation Logo. Après avoir survolé le BASIC, cela me semblait une suite logique.
En me plongeant dans l'univers Logo, j'ai cherché à mieux connaître le robot qui y est associé : la tortue Jeulin. Et j'ai été très étonné de voir aussi peu de ressources dessus. Et pourtant, il semble qu'elle ne soit pas si rare chez les collectionneurs.
Grâce à l'aide de photographie envoyées sur le forum system-cfg par Fool-DupleX (merci à lui), j'ai tenté une modélisation. Ça m'a pris... un certain temps.
Le résultat n'est pas correct au milimètre, mais donne une relativement bonne idée.
Pour ces quatre nouveaux hooks, je ne suis pas très inspirés. Il s'agit de hook destiné au traitement des entrées sorties. Trois d'entre eux sont appelés lors d'une impression de caractères, le quatrième pour de l'acquisition.
Routines en sorties
Voici les trois premières :
$47DF, prthk : début de commande PRINT.
Est appelé en tant que première instruction de l'exécution de l'instruction PRINT.
À ce moment là, HL pointe vers les arguments de PRINT et le flag Z est à 1 s'il n'y a rien dans ces arguments.
Si vous rendez la main à la routine, elle déroulement l'affichage.
$47E2, outhk : début d'impression de caractère -> pour rerouter vers de nouvelles sorties
Est appelé pour chaque caractère envoyé sur un périphérique de sortie (en $3bd0)
La variable système (prtflg) désigne le périphérique.
Le caractère à afficher est dans le registre A.
Attention, ce caractère est à comprendre par rapport aux modes d'affichage : est-ce …
En premier, l'argument passé à CALL est évalué, puis est ensuite transformé en entier sur 16 bits.
Cette adresse, précédée par l'opcode pour JP à une adresse absolue 16 bits est placée dans le hook calhk. La routine saute enfin vers cette adresse, qui agit comme un tremplin vers l'adresse indiquée à l'instruction CALL.
Comme c'est le RET de la routine appelée qui fera office de RET pour l'ensemble de l'instruction CALL, la préservation de l'environnement est à la charge de la routine …