ASM83 afficher un texte

Bonjour

voila je débute (en assembleur) ne riez pas   

2eme exo que je fais (vraiment simple au départ... )
ça m'affiche bien bonjour (quand même !) mais après la calculatrice plante...

une idée ?

Code:

.nolist
#define TI83

#include "ti83.inc"

.list
.org $9327

start:
 bcall _clrlcdfull ; Efface écran
 ;bcall _newline ; Nouvelle ligne (utile ? pas ici)
 ld hl,ligne   ;Charge texte dans hl
 bcall _puts   ;Affiche le texte
ret

ligne:  ; lbl ligne
 .db "Bonjour de TI80 !",0
.end

merci

Bonjour,

On ne va certainement pas rire si tu débutes en asm (on est tous passé par là rassures toi ). Au contraire, je t'encourage à continuer comme ça, c'est vraiment un langage puissant, même s'il peut faire peur au début

Tu devrais avoir une erreur de compilation non?
Il faut toujours mettre (au moins) un espace (ou une tabulation) avant toute instruction, y compris ret...
Le ret ne devait pas être compilé, et donc du coup la calto ne sait pas quand le prgm est sensé s'arrêter.

Code:

.nolist
#define TI83

#include "ti83.inc"

.list
.org $9327

start:
 bcall _clrlcdfull ; Efface écran
 ld hl,ligne  ;Charge texte dans hl
 bcall _puts  ;Affiche le texte
 ret ;Un espace avant le ret

ligne:  ; lbl ligne
 .db "Bonjour de TI80 !",0
.end

(on est tous passé par là rassures toi Smile )

Ceux qui ont eu le courage de s'y mettre...

Bonjour
merci de vote patiente ;c'est vrai on est tous débutants un jour ou l'autre...
oui j'avais oublié la tabulation avant ret
mais ne n'avais pas d'erreur de complilation

Code:

.nolist
#define TI83

#include "ti83.inc"

.list
.org $9327

start:
 bcall _clrlcdfull ; Efface écran
 ;bcall _newline ; Nouvelle ligne (utile ? pas ici)
 ld hl,ligne1   ;Charge texte ligne1 dans hl
 bcall _puts   ;Affiche le texte
 bcall _newline ; Saut à la ligne ?
 ld hl,ligne2  ;Charge texte ligne2  dans hl
 bcall _puts   ;Affiche le texte
 ret

ligne1:  ; lbl ligne
 .db "pgm test2",0
ligne2:  ; lbl ligne
 .db "Bonjour de TI80 !",0
 
.end

ça marche mieux et j'ai indenté un peu plus proprement



Quand j’exécute la 1ere fois le texte est en haut , après il se met en bas comme sur l'image

il doit bien falloir encore quelques instructions.

Sympa l'ASM z80 ;-)

Faudrais que je m'y mette

Pour mettre le curseur en haut de l'écran, utilise la rom call _homeup ( bcall _homeup)

Au fait tu testes tes prgm asm directement sur ta calto? Si oui je te conseille de les tester d'abord avec un émulateur (wabbitemu par ex).


PS: Je viens de me rendre compte que tu t'es trompé dans le titre: c'est de l'asm 83 et pas 93

Wistaro a écrit:Sympa l'ASM z80 ;-)

Faudrais que je m'y mette

Oui  Wistaro m'es-toi y aussi !

m@thieu41 a écrit:Pour mettre le curseur en haut de l'écran, utilise la rom call _homeup ( bcall _homeup)

Au fait tu testes tes prgm asm directement sur ta calto? Si oui je te conseille de les tester d'abord avec un émulateur (wabbitemu par ex).


PS: Je viens de me rendre compte que tu t'es trompé dans le titre: c'est de l'asm 83 et pas 93

ah oui la TI93 n'est pas encore sortie il me semble (la TI92 si) je corrige le titre !
Pour l'instant en Assembleur je n'utilise que Tilem ou wabbitemu  et j'utilise Spam qui est rapide... Pour la suite je verrai en fonction des difficultés qui se présenteront

j'ai modifié le code et un peu le contenu en rajoutant

Code:

bcall _homeup ; haut d'écran

quelle différence entre Bcall et Call ?
là c'est l'image avec wabbitemu au dessus c'était avec Tilem2

merci à vous deux

Je pensais que tu prenais des photos avec une vraie calto
Avec wabbitemu tu peux prendre facilement des screenshot (animés avec la touche effacer au dessus de la touche retour à la ligne, et fixe en faisant glisser l'écran de la ti virtuelle comme si c'était une image).

En fait, lorsque tu programme pour 83+ en asm (ou en 83 et en 83+ avec ion), il faut utiliser bcall lorsque la routine est une de celle de la calto, et call lorsque c'est une de tes routines (tu verras ça plus tard). Si tu programme seulement pour 83/82stats, tu peux mettre toujours call, mais mettre bcall est une bonne habitude à prendre.

Heu non je faisais une copie partielle de mon écran. c'est tout..
là en prenant option take screenshot ça me donne ça :

sinon pour les gif animés comme une roue j'utilise l'option Record Gif

pour Call et Bcall je comprendrai sans doute mieux plus tard car je suis loin de faire mes propres routines. De plus ION Venus etc .. je ne comprends trop rien... à quoi ça sert ... je fais toujours du Envoi(9prgmZ...

Au début ce n'est pas important de s’embarrasser avec tout ça: apprend déjà les bases, tu verras les shell etc plus tard.
Retient juste que pour prendre de bonnes habitudes tu dois utiliser bcall lorsque ce sont des routines de la ti (_homeup/_puts/etc), et lorsque tu feras les tiennes tu utiliseras call pour les appeler.

(ION/Venus sont des shell, c'est à dire des prgm en asm que tu mets sur ta calto et qui te permettent de lancer d'autres prgm asm. L’intérêt? Ton programme asm prendra 2 fois moins de place puisqu'il sera codé en asm "pur" (un octet de code codé sur 1 caractère (et donc en mémoire ça prend bien 1 octet), tandis que sinon un octet de code est codé sur 2 caractères (donc en réalité ça prend 2 octet)) ).

Où as-tu as eu ton ti83.inc ? Je trouve étonant que tu ais la définition de bcall dedans. Ce n'est pas une instruction du Z80 mais un define. Et des gens l'utilisent comme une macro...

CALL appelle simplement la routine à l'adresse indiquée. C'est une instruction du Z80.
BCALL est une definition ou une macro écrite pour se faciliter la vie : elle appelle la routine 28h de TI qui sert elle-même à appeler la routine de TI demandée. Cette routine fait à notre place des opérations pénibles (dont la sauvegarde des registres actuels). Mais je croyais qu'elle existait uniquement sur ti83plus. Et en plus c'est une perte de temps pour beaucoup d'appels qui n'ont pas besoin de toutes ses actions.

Et si le terme macro te perturbe, sâche que c'est une définition qui peut recevoir des paramètres, et le préprocesseur substitue les arguments dans le code.

Code:

#define testmacro(xx,yy) ld xx , $ yy
 testmacro(bc,FF)
; on obtient : ld bc , $ FF

Code:

#define b_call(xxxx) rst28h \ .db xxxx
b_call(XXYY)

; on obtient :
; rst 28h
; .db XXYY

Le #define TI83 ne sert pas si ton programme est de toute façon écrit pour ti83. Un commentaire aurait suffit dans ce cas. Par contre le header de ION est conçu à la fois pour les ti83 et ti83plus, alors ce define sert à appliquer un des deux header et pas l'autre.

-----

Les shells ce n'est pas si difficile, pourquoi tout le monde en fait un mystère ?

Quand tu écris un code
ld bc,$FF
Le compilateur crée un code binaire que j'écrirai en hexadécimal.
$01FF

Ce code est celui que le processeur peut exécuter.

Ce code est illisible par les éditeur de texte et de programme TI-Basic car ceux-ci essayeront de les lire avec la table ascii ou avec les token de TI.
Dans une TI le token de code $01 est ">DMS". Le token de code $FF est "LinReg(ax+b)_".
Donc la TI affichera ">DMSLinReg(ax+b)_".
Cela est incompréhensible.

J'ai pris cet exemple qui est lisible bien qu'incompréhensible. Mais d'autres ne peuvent simplement pas être lus puisqu'aucun token ne correspondra à certains codes.

De même le code $01 n'est pas un caractère ascii imprimable, c'est un caractère ascii de contrôle. Donc ce n'est pas la peine d'essayer de le lire dans un éditeur de texte simple.

Donc on veut modifier le codage pour que le code $01FF puisse être saisi dans une TI à la main.
On veut donc afficher dans une TI "01FF".
Compte tenu des codes des tokens des chiffres et lettres majuscules, le code est
$30314646
Cela s'appelle un objet. Sur TI-planet on m'a dit "unsquished".
Dans un ordinateur qui éditerai ce programme assembleur, on fait du binaire "*.bin" un objet "*.obj" par ce procédé.

Au passage je signale que le code a doublé de taille ! Puisque chaque quartet de code binaire original est stocké en un token d'un octet, donc de deux quartets.

Pour une TI83, on insère les tokens "End:0000:End".
Pour une TI83plus on insère le token "AsmPrgm".
On peut alors lire

Code:

01FF
End
0000
End

Code:

AsmPrgm01FF

qui s'executent avec Send(9prgmXXX ou Asm(prgmXXX.

La calculatrice TI83plus est conçue pour pouvoir retransformer le programme basé sur l'objet en programme basé sur le binaire.
AsmComp(prgmA,prgmB)
Le code a été transformé, est donc devenu illisible, et le token AsmPrgm est devenu un token invalide de code $BB6D qui indique au système de la TI que c'est un programme "binaire" et elle refusera de tenter de l'éditer.

Mais le programmeur avec son ordinateur et un câble n'a que faire de cette démarche. Il veut compiler un programme en binaire et l'envoyer directement à la TI sans changer le codage. Et ne pas doubler sa taille.
Donc il utilise directement le binaire, pas l'objet.

Pour une TI83plus, il faut juste veiller à avoir placé le code $BB6D au début du programme binaire.

On veut faire pareil sur une TI83.
Mais le programme binaire n'est pas accepté par le système de TI. Il faut tricher avec un shell tel que ION, Venus, SOS, ICE, ... et d'autres.
Le shell est exécuté avec un début en forme Objet comme la TI veut, puis les programmes binaires sont lus par le processeur directement sous leur forme binaire.

Les shells ont aussi le fort avantage d'inclure des routines. ION et VENUS en ont, je ne sais pas pour les autres.
ION a aussi l'avantage de prévoir une compilation aussi bien sur TI83 que TI83plus d'un même programme, car un header est fourni pour ça.

Dans une TI82, le shell Ash ou Crash exploite une faille pour exécuter l'assembleur alors que cette faille n'est pas accessible manuellement.

Bonjour Linkakro,

merci pour cette analyse où je ne comprends pas tout (c'est le moins que l'on puisse dire) mais ça viendra un jour, peut-être

En tous cas tu fais une analyse poussée et un super travail.

Mais je n'en suis qu'au début du début ... (c'est à dire niveau zéro ou pas loin ..)

mais je suis persuadé que ça va être utile à tous ceux qui s’intéressent à l'assembleur et qui ont déjà un petit niveau.

Pour ce qui de ta question c'est m@thieu41 qui m'a donné un lien pour spam où j'ai trouvé ti83.inc,
Le lien ici
et c'est pour ça que j'utilise spam plutôt que Tasm (ça va 10 fois plus vite à compiler, mais il ne faut pas me demander pourquoi... ) et je ne sais pas si les codes sont optimisés ou pas.

justement en me promenant dans ce ficher et 83rom que j'ai eu (je ne ne sais plus où) j'essaie de comprendre en faisant un peu de code en essayant de comprendre ce que d'autres font, mais ce n'est pas facile

et voila ce que ça donne ... j'ai essayé de mettre des commentaires mais je ne comprends  -évidemment- pas tout. je vous avez bien dit de ne pas rire sur le premier message de ce billet.

Code:

; ti83 test sans include
_effaceEcran .equ $4755 ; ici on associe à un mot clé une adresse de la rom
_affiche .equ $470D ; on peut changer les étiquettes ...
_premiereLigne .equ $4775 ; un exemple
_sautLigne .equ $473D;
; currow .equ $800C ; adresse ram ? . // mis en commentaire
.org $9327
  call _effaceEcran
   call _premiereLigne
    ; ld de,$0103 ; ? ça se comprend comment ? pos xy ? // mis en commentaire
    ; ld (currow),de ; ? et celle là ? on se positionne sur la ligne ? // mis en commentaire
    ld hl,ligne1 ;  on recupere les infos de ligne1 (label)
    call _affiche ; attend les parametres
   ; adresse 470D de rom qui affiche ;
  ; // parametre attendus
    ; entree: HL  chaine // mis en commentaire
       ; (CURROW) Ligne en entrée
       ; (CURCOL)  Colonne  en entrée
     ; Sortie: chaine en HL est affichée
        ; (CURROW) ligne mise à jour ?
        ; (CURCOL) colonne mise à jour ?
  call _sautLigne
 ld hl,ligne2 ;  
  call _affiche ;
  call _sautLigne
 ld hl,ligne3 ;  
  call _affiche ;
  call _sautLigne
  ret
ligne1:
.db "ASM TI83 Test3",0
ligne2:
.db "Comprendre",0
ligne3:
.db "et apprendre",0

.end

Un grand merci  pour ton travail, et je relirais tes explications car ça me parait être une mine d'informations et de bon conseils. Bravo

En fait le bcall n'existe vraiment que sur 83+/84+ et sert à naviguer dans les pages Flash pour trouver les routines que tu veux appeler. Sur 82 stats, y'a pas de pages flash, que des pages RAM, donc y'a pas besoin de changer de pages.

Le #define bcall a été aussi mis dans ti83.inc pour des raisons de compatibilité. En réalité, c'est #define bcall call.

Par contre attention jo2geek, changer les noms des rom call n'est pas forcément une bonne chose à faire (ce sont des conventions, donc c'est mieux de les respecter si tu veux que d'autres personnes puissent facilement comprendre ton code, si chacun utilises ses propres noms on n'arrivera jamais à se comprendre ).

Bonjour m@thieu41
Bien noté et tu as raison il vaut mieux ne rien changer...
c'est pour mieux comprendre que j'avais mis cela.
j'ai même remarqué que l'on pouvais ne pas mettre de nom du tout mais ça devient vite incompréhensible style

Code:

call $473D ;  saut de ligne...

en fait j'ai compris que l'on appelle une adresse mémoire de la rom et cette adresse attend ou non des paramètres selon à laquelle est est dédiée. C'est bien cela ?
Mais je découvre et c'est pour ça que je me suis amusé à bousculer les habitudes voire à me passer des includes.
Mais je vais remettre de l'ordre dans mes prochains essais. Merci en tout cas de tes conseils.
à bientôt

Oui c'est exact, lorsqu'on fait call $XXXX, on appelle la routine qui débute à l'adresse $XXXX, et le fait de faire #define adresse $XXXX permet que le préprocesseur (qui lit le code avant la compilation) remplace toutes les occurrences d'"adresse" par "$XXXX

En fait je ne comprends pas trop à quoi servent certaines nuances..
ce qu'on appelle #define ?

par exemple dans ti83.inc il y a

Code:

#define _divHLbyA 400Ch

et ti83asm.inc

Code:

_divHLbyA   .equ   400Ch

voire écrit  $400C

quelles sont les normes ?

matrefeytontias a écrit:En fait le bcall n'existe vraiment que sur 83+/84+ et sert à naviguer dans les pages Flash pour trouver les routines que tu veux appeler. Sur 82 stats, y'a pas de pages flash, que des pages RAM, donc y'a pas besoin de changer de pages.

Le #define bcall a été aussi mis dans ti83.inc pour des raisons de compatibilité. En réalité, c'est #define bcall call.

donc pas de bcall pour les 83 de bases si je comprends bien.

double post inutile que je n'arrive pas à supprimer

Édite tes posts au lieu de double-poster s'il te plaît.

En fait .equ ou = servent à associer un nombre à un texte. #define c'est bien plus que ça, ça permet d'associer n'importe quel texte à un autre texte. Exemple, ces codes reviennent exactement au même :

Code:

_clrLCDfull .equ $4540
_clrLCDfull = $4540
#define _clrLCDfull $4540

L'avantage de #define, c'est qu'on peut faire de mini-fonctions sans avoir à tout réécrire, ce qui est impossible à faire avec .equ ou = :

Code:

#define ld16(w, x, y, z) ld w, y \ ld x, z

Avec cette fonction d'exemple, au lieu de faire

Code:

 ld l, e
 ld h, d

Tu peux faire

Code:

 ld16(h, l, d, e)

Ensuite, pour $HEXA ou HEXAh, c'est juste une convention, et ça marche aussi pour le binaire. Ces nombres sont identiques :

Code:

$4A7D ; hexa
4A7Dh ; hexa
0100101001111101b ; pareil en binaire
%0100101001111101 ; ^

Ensuite oui, les TI z80 non-flash n'ont pas de bcall, donc on utilise juste call.

matrefeytontias a écrit:Édite tes posts au lieu de double-poster s'il te plaît.
.

je ne comprends pas.. c'est à dire ?


en tous cas merci pour toutes ces explications qui me seront bien utiles.

Tu as posté deux messages d'affilée, ce qu'on évite de faire sur les forums en général. Rien de bien grave hein, mais en haut à droite de chaque message que tu as écrit tu as un bouton "Éditer" qui te permet de modifier le contenu du message. Si tu veux rajouter quelque chose, utilise cette fonctionnalité au lieu de faire un deuxième message.

.equ et = sont juste deux conventions pour la même chose. Cela ne fait qu'une association de nombre à un mot.
#define permet de définir n'importe quelle substitution du préproprocesseur, c'est -à-dire que cela remplace le code source comme du texte. Et avec des arguments c'est une macro.
Et dans ce dernier cas, il ne faut pas confondre avec des fonctions de language tel que C, car cela agit seulement avant la compilation en transformant le code source.

Bonjour
toujours dans mes essais et donc mes petites questions...

Code:

.nolist
#define _PutS $470D
#define _NewLine $473D
.list
 .org $9327
     ld hl,helloString
     call _PutS
     call _NewLine
     ret
helloString:
 .db "Hello world !",0
.end

et

Code:

   213193
    CD0D47
    CD3D47
    C9
    48656C6C6F20776F726C64202100
    End
    0000
    End

Les 2 envoyés sur la TI fonctionnent bien
le 1er je ne peux pas l'éditer
Le 2eme le peux l'éditer  ( j'avoue qu'en bricolant j'ai eu mem cleared.. )
Pourquoi ne peut-on éditer le 1er dans la TI ?

Quand je regarde la taille des programmes ils sont différents de 4 octets (même longueur de nom de programme)
En terme de taille entre la méthode Send(9pgrmxxx que j'utilise et les autres méthodes (shell, Axe,   la fonction ASM( de 83plus que je ne connais pas) etc .. ), qu'est qui est le plus optimisé ? (sur des programmes plus conséquent, évidemment..)

et dernières questio à quoi servent le .db et le ,0 derrière la chaine ? un retour à la ligne ?

Bien à vous

Bonjour,
Qu'entends tu par "le premier" et "le deuxième"?
Tu parles des 2 codes que tu as donné?
En fait, les codes sont les mêmes, mais lorsque tu utilises ton compilateur, pour plus de sécurité et éviter un ram clear en bidouillant n'importe quoi, il rend le prgm impossible à l'édition. C'est d'autant plus vrai si le compilo produit un prgm qui se lance avec un shell: on ne peut même pas modifier le code même en connaissant les correspondances en héxadécimal, puisque tu ne peux pas rentrer les tokens "bizarres".
Pour rendre possible à l'édition, tu peux utiliser le prgm PROTECT (il est sur l'ancien tout 82), ou le faire depuis ti program editor (une case à décocher en haut du code source).

Pour des programmes conséquents je te recommande d'utiliser un shell, pour toutes les raisons pour lesquels les shell ont été créés: taille divisée par 2 essentiellement.

.db indique que ce qui suit n'est pas du code, mais directement les octets à mettre dans l'espace mémoire correspondant.
,0 indique la fin de la chaine.

Bonjour,

m@thieu41 a écrit:Bonjour,
Qu'entends tu par "le premier" et "le deuxième"?
[..]

Pour des programmes conséquents je te recommande d'utiliser un shell, pour toutes les raisons pour lesquels les shell ont été créés: taille divisée par 2 essentiellement.
[..]
.db indique que ce qui suit n'est pas du code, mais directement les octets à mettre dans l'espace mémoire correspondant.
,0 indique la fin de la chaine.

Le "2 ème" ce sont les codes que je rentre directement dans la calculatrice

Quelle procédure les shells utilisent-ils  pour pouvoir réduire la taille des programme par deux ?

Ah d'accord je ne comprenais pas le .db  voilà c'est clair maintenant

pour la fin de chaine on aurait du s'attendre à ce que ce soit la fermeture des guillemets puisqu'on en met en ouverture de chaine..

Merci pour les explications

à bientôt

Les guillemets servent à la compilation: le prgm sait ainsi qu'il doit convertir les caractères selon leur valeur hexadécimale.
Le 0 sert pour la calto: lorsqu'elle affiche la chaine, elle sait qu'elle doit s'arrêter au 0. Il s'agit donc du caractère de fin de chaine.

Pour le shell:
Au lieu d'écrire CD3D47, le compilateur regroupera les chiffres 2 à 2. C'est ce que Linka explique plus haut.

Merci pour ces explications

pour l'explication de Linkakro c'est encore un peu confus à mon niveau de débutant assembleur

Je viens de penser que la notation "$" pour désigner la notation hexadéciamale peut perturber. Je remplacerai par la notation "(xxx)16"

Je résume les formats pour illustrer un peu ce que je n'ai pas suffisamment bien dit dans mon message à propos des shells.

A l'affichage de la TI tu écris
"ABC"
Dans la mémoire les données sont
hexadécimal (414243)16
binaire (0100 0001 0100 0010 0100 0011)2
Et réciproquement.

Dans la mémoire si tu stockes
binaire (1010 1011 1100 1101)2
hexadécimal (ABCD)16
A l'affichage tu liras
"randtanh^-1("
car le token "rand" ou "NbrAléat" a pour code (AB)16 et "tanh^-1(" ou "Arctanh(" a pour code hexadécimal (CD)16
Et réciproquement.

Si le code du programme compilé pour un processeur est "ABCD", on a le choix entre :

-utiliser la méthode 1 en saisissant manuellement "ABCD" dans l'éditeur de TI, puis exécuter avec Send(9prgm
Le code est (414243)16

-transférer les données qui contiennent le code (ABCD)16, puis
--soit utiliser un shell tel que ION
--soit avoir une ti83plus compatible et avoir prévu le code (BB6D)16 au début du programme

Comme la saisie manuelle de "ABC" stocke dans la mémoire (414243)16 donc un octets pour chaque digit hexadécimal (), cela prend plus de place (le double) que de stocker directement dans la mémoire (ABC)16.

Mince alors je vois ça et d'un seul coup ça me fait moins peur (peut être parce que j'ai fait du c++ avec arduino???) et j'ai envie de m'y mettre des que je peux sauver mes programmes (très très important ça !!!!)
Bien joué joy2geek !!!