TabataDesign

Editeur Mémoire/Tableau Générique

Le but est de concevoir un éditeur d'octets (et plus si affinité) dont aucun paramètre n'est fixé en dur :
• Nombre d'octets affichés par ligne (a)
• Delta d'une ligne à l'autre (b)
• Contenu même de la cellule (c)
• Elements d'affichage (séparateurs)
• …

Cette façon de faire (ultra générique) s'oppose frontalement à l'instinct du demomaker (ultra spécifique - sauf pour l'improvized demo !). Les exigences du code sont tout autres :
• compact (mais pas obligatoirement le plus rapide).
• exécutable en ROM.
• destiné à être revu et modifié.
C'est justement ce qui rend l'exercice passionnant et édifiant.

Considérons (c). Dans le cadre d'un éditeur de raster des contraintes supplémentaires s'ajoutent. On peut aussi imaginer une conversion à la volée : affichage valeur logique de 0 à 26, stockage valeur hardware (de &40 à &5f).
Même dans le cas simple d'un éditeur de mémoire, ld a,(hl)/ld (hl),a ne suffirait pas, car il faut prendre en compte la connexion mémoire en cours (sous Monogams, on peut très bien examiner la ROM haute 31 alors que le code s'exécute dans une autre ROM).

On délègue donc la partie lecture/écriture de la cellule (le M du concept MVC).
Quels paramètres d'entrée pour une routine get_cell ?
Pointeur sur la cellule à lire (rejeté)
Non ! Le moteur d'édition n'a pas à connaître intimement ce qui est édité (Par exemple la position de la table de raster en mémoire). C'est cette isolation qui rend le code puissant et réutilisable.

Numéro ligne et colonne (rejeté)
Cette approche est tentante, car la routine ne dépendrait que des paramètres d'entrée, et non d'un état mis à jour ailleurs. Mais ce n'est pas très efficace, la plupart du temps, on demande plusieurs colonne sur la même ligne, et on ne veut pas forcer le moindre calcul superflu.

• Pas de paramètres !
Ligne et colonne sont définies au préalable (set_row and set_col).
Cela reprend le principe de la gestion texte ou graphique : on positionne d'abord le curseur, puis on trace.

En pratique, on passe deux paramètres : l'adresse de tampon où écrire le contenu de la cellule (en ASCII), et un context (inutilisé pour l'instant).
Tout cela est resumé en bas de page. Et dans le source.

Dispatch IO

La lecture clavier, l'écriture d'un caractère se fait en passant par des labels afin de pouvoir switcher à l'assemblage sur le pack de routines souhaité (firmware VS handmade VS test). Voir TABATA.O.
On s'inspire des vecteurs systèmes, mais rien n'empêche d'imaginer un pack de routines plus intéressant à utiliser.

  • km_read_key = &bb1b
  • scr_hw_roll = &bc4d

• txt_set_cursor = &bb5d
• txt_wr_char = &bb75
• txt_place_cursor = &bb8a

Voir interface par exemple ici: http://www.cpcwiki.eu/imgs/7/71/S968se15.pdf

Definition du tableau:

Considérons:
4004 00 00 00 00 00 00 00 00
400C 20 77 61 73 20 6e 6f 74

On veut décrire cela sous forme de données uniquement (même si certaines sont des adresses de routines !).
Voir TABATA.O

A coder:

tabata_init
tabata_iter

* System friendly (don't use EXX / EX AF)
* All-terrain (mustn't use firmware directly)
* Pas d'auto-modif (pour version ROM)

Interfaces:

set_row
; Positionne le "curseur" sur une ligne donnée (sans changer la colonne)
IN: HL= row # (Starts at 0)
Out: Carry set if OK, NC otherwise (out of range)   

set_col
; Positionne le "curseur" sur une ligne donnée (sans changer la colonne)
IN: HL= row # (Starts at 0)
    ; IX - 
Out: Carry set if OK, NC otherwise (out of range)   

get_cell
; Read cell at cursor position
IN: HL= buffer à remplir
Out: Carry set if OK, buffer rempli.
    ; NC Otherwise
Sauf mention contraire, le contenu de cette page est protégé par la licence Creative Commons Attribution-ShareAlike 3.0 License