Routines 'système' de Ndless

[Noury]

Je n'ai pas de TI-nspire modèle W en ma possession, et je me suis toujours demandé : dans ce mode 240x320, d'où démarre le buffer écran, je veux dire, de quel coin de l'écran ?

Dans mon cas, TI-Nspire CX CAS récente, les adresses mémoire commencent en haut à gauche (adresse 0 du buffer)
Ensuite ça descend jusqu'à 479.
Puis on va sur la droite pour la seconde colonne qui commence à l'adresse 480
etc...
Enfin, la dernière colonne se termine à l'adresse 153599.
Ce qui nous fait 480x320. 480 en vertical, et 320 en horizontal.
C'est curieux, je pensais qu'on était en 240x320.

Chaque octet semble contenir la couleur (o=noir, 255=blanc). Je n'ai pas essayé toutes les valeurs intermédiaires, mais j'ai eu à un moment du bleu ciel (0x7F).

Je reste perplexe. Pourquoi 480 ?

Ceci dit, pour dessiner les caractères, ça ne facilite pas la tâche.

[critor]

480=240*2

L'écran étant par défaut en 16-bits, ça colle.

[Noury]

Ah d'accord !
Deux octets par pixel...
Merci pour l'info.

Mais donc on peut l'utiliser également en 480x320. C'est d'ailleurs ce que j'ai fait, mais du coup on n'a que 256 couleurs. Et le risque c'est d'avoir les caractères "tassés" en vertical. Sauf à faire de toutes petites polices.

[grosged]

Ah ok, merci pour la structure d'un écran 240x320
Personnellement, si l'on souhaite programmer de manière "universelle", je pense que le choix d'un mode 8bpp comme standard serait l'idéal, car même les modèles monochromes dits "classiques" seraient gagnants. En effet, j'ai remarqué qu'en basculant en mode 8bpp, on gagne 1 bit supplémentaire pour coder les couleurs : ainsi, 32 des 256 couleurs constituant la palette sont réellement exploitables , au lieu des 16 couleurs en mode 4bpp normal
(voir archives_voir.php?id=1126139 )


image en 32 niveaux de gris (sur nspire MONOCHROME)

EDIT: sinon, que pensez-vous d'une fonte en 8x12 (mode texte 40x20) ?
ça ferait ni trop grand ni trop petit...
Et avec 12 pixels de haut, ça favorise un bel équilibre de certaines minuscules (lettres g, j, p, q, y)

[Noury]

Personnellement, si l'on souhaite programmer de manière "universelle", je pense que le choix d'un mode 8bpp comme standard serait l'idéal, car même les modèles monochromes dits "classiques" seraient gagnants. En effet, j'ai remarqué qu'en basculant en mode 8bpp, on gagne 1 bit supplémentaire pour coder les couleurs : ainsi, 32 des 256 couleurs constituant la palette sont réellement exploitables , au lieu des 16 couleurs en mode 4bpp normal

Si j'ai bien compris, tu n'utiliserais qu'un octet sur les deux disponibles sur la dernière CX CAX pour être compatible avec tous les modèles.

EDIT: sinon, que pensez-vous d'une fonte en 8x12 (mode texte 40x20) ?
ça ferait ni trop grand ni trop petit...
Et avec 12 pixels de haut, ça favorise un bel équilibre de certaines minuscules (lettres g, j, p, q, y)

J'avais pensé à du 16x6. 16 vertical et 6 horizontal. Pour avoir un écran de 30 lignes et 52 colonnes. C'est ce qui est utilisé dans MicroPython porté sur Nspire.
Mais j'avoue que le côté "artistique", ce n'est pas mon fort.
Je vais pour ma part continuer à faire un truc minimaliste, à titre d'exercice (en assembleur).
Au fait, tu va faire ça en C ou en ASM ?
Autre question, tu travailles sur la calculatrice seulement, ou tu utilises l'émulateur ?

[grosged]

Oui, on peut, bien sûr, rester sur du 16bpp. Dans ce cas, on vise délibérement la compatibilité CX (CAS) / CX (CAS) II
Après tout, les nspire monochrome commencent à dater, et il y a de moins en moins d'utilisateur si je ne me trompe...Mais bon!..ça se discute, hein!?

La fonte 6x8 utilisée par MicroPython me paraît un peu trop petite (à mon goût).
On pourrait la grossir légèrement en passant en 8x8 (texte=40x30), 8x10 (texte=40x24), ou même 8x12 (texte=40x20).

Concernant la TI-nspire, Je programme uniquement en Assembleur, uniquement sur calculatrice.
J'ai un peu réfléchi à une façon d'afficher du texte sur les modèles 240x320, mais comme d'habitude, je pense à plein de choses en même temps (comme une gestion de la couleur d'affichage/couleur de fond/ou même transparence)...Et pourquoi pas , inclure la possibilité de préciser les coordonnées d'affichage (et ce, en mode "texte" ?..ou "graphique".?..)
Par exemple, (en mode 16bpp):

pointeur1: .hword couleur-affichage,couleur-fond
pointeur2: .byte PositionX,PositionY (ou .hword PositionX,PositionY si graphique)
pointeur3: .asciz "Hello World!"

Ainsi, la routine d'affichage de "base" pourrait s'étofffer d'options , dépendemment du pointeur choisi et de l'appel émis

[critor]

Les Nspire monochromes peuvent très bien être réglées en 16bpp.
Il faut juste allouer un nouveau buffer écran le temps de l'exécution du programme Ndless, puisque le buffer 4bpp n'aura plus assez de place.

[grosged]

Ah mais oui !!! Bien vu, critor !! J'oubliais qu'on pouvait modifier l'adresse de buffer-écran

[Noury]

Bonjour,

J'ai finalement fait l'exercice. J'ai pu écrire la chaine "Hello World!" sur l'écran depuis un programme assembleur.
Ça ne fera pas l'objet d'une bibliothèque, car il y a un OS, et ce serait dommage de se priver d'appeler des fonctions qui existent déjà, et qui sont certainement plus performantes et plus efficaces.

Voici les règles que je me suis fixées pour cet exercice:

Le principal choix qui a été fait est qu'on gère soi-même l'affichage.
C'est-à-dire qu'on décide de tout.
Ça veut également dire que cette procédure permet l'affichage d'une ligne, ou une partie de ligne, de texte à des coordonnées indiquées.

La chaine de caractères à afficher se trouve au label "texte"

Les coordonnées d'affichage (ligne, colonne) se trouvent au label "pos".

les couleurs des caractères se trouvent au label "colors" (arrière plan, caractère)
Le format des couleurs est un codage sur 16 bits en hexadécimal.

L'écran fait 24 lignes de 40 caractères.
Chaque caractère est dessiné dans une matrice de 10 lignes et 8 colonnes (pixels)
On accède au caractère à afficher dans la table des caractères par son code ascii.

Parmi les choix retenus:
- si une ligne dépasse la limite des 40 caractères, il y a troncature. Pas de retour à la ligne.
- si on dépasse les 24 lignes, il n'y a pas de scrolling
- seuls les caractères imprimables sont pris en compte. Les caractères de contrôle (CR, LF...) ne le sont pas.
- il n'y a pas de mise en forme (gras, italique, barré...)

Je mets le code source et le tns en PJ, pour le cas où ça intéresserait quelqu'un.

J'espère qu'il n'y a pas d'erreurs sur la police de caractères, je l'ai saisie manuellement pixel par pixel.

Voici ce que ça donne:

[BackStage]

nbenm

merci pour le code source