Cherche documentation assembleur TI82stat

Vu qu'il utilise #define TI83, il n'y a pas à ce soucier de ce détail, qui ne concerne que les ti flash... Lorsqu'on code avec ion exclusivement pour ti non flash (ti 83 ou équivalent donc), on peut utiliser indifféremment bcall ou call, dans l'include de ion il y a ce qu'il faut pour que le compilo comprenne.
Par contre si tu code pour TI 83+ et pour TI 83 (ou pour 83+ uniquement), il faut faire attention à la distinction: bcall XXX pour une rom call XXX présente dans la calto, et call XXX pour appeler une de vos routines personnelles (routines de ion comprises).

Les routines d'ion sont installées sur la calto en même temps que l'installation d'ion, donc elles sont disponibles sur 83 du moment qu'ion y est installé.

Du coup vient la question: quel est le modèle de ta calto?

Et aussi concernant NOLIST/LIST: NOLIST permet de définir une portion de code qui ne sera pas dans le fichier .list, et LISTY permet de définir ce qui sera dans le fichier .list.
Donc il est judicieux de mettre NOLIST concernant les parties de code dont on est sur qu'il n'y a pas d'erreurs (les includes notamment), et LIST quand on est pas sur (le prgm en lui même).
.NOLIST

Code:

#define TI83
#include  "ionVT.inc"
.org $9327
.LIST

Petit détail sans importance: tu n'as pas besoin de mettre 2* "end" à la fin du prgm, un seul suffit.

Maintenant recompile avec le détail du LIST/NOLIST et passe moi le contenu du fichier .list pour voir ce qui ne va pas.

Ma calto est une Ti-82 Stats.fr sans aucun doute. Donc je met comme si c'était une ti-83.

Alors, pour ce qui est du fichier .list :

Code:

6    09327: -  -  -  -     
7    09327: 06 64 -  -     ld b,100
8    09329: CD AA 91 -     bcall ionRandom
9    0932C: 26 00 -  -     ld h,0
10  0932E: 6F -  -  -     ld l,a
11  0932F: CD 09 47 -     call _disphl
12  09332: C9 -  -  -     ret
13  09333: -  -  -  -     
14  09333: -  -  -  -  .end


Voilà, je ne connaissais pas le .list, je le faisait effacer dans mon compiler.bat alors je n'ai jamais pu regarder ce qu'il y avait ^_^
En tout cas c'est intéressant... enfin personnellement je ne vois pas d'erreur dans le code hexa...

Oh j'oubliais!
Il y a une convention pour l'en-tête de tout prgm compilé pour ion, afin qu'il soit reconnu comme tel...
Essaye de compiler:

Code:

#define TI83
.nolist
#include "ion.inc"

#ifdef TI83P ;inutile ici mais au cas où tu aurais à compiler pour TI 83+ ça peut toujours servir
   .org progstart-2
   .db $bb,$6d
#else
   .org progstart
#endif

   ret
   jr nc,start
   .db "NomPrgmPourIon",0
   
.list
start: ;Le code commence ici après le lbl start
  ld b,100
  call ionRandom
  ld h,0
  ld l,a
  call _disphl
  ret
.end

Super maintenant ça bug plus, sauf que le programme ne s'exécute pas. Mais soyons positif, plus de plantage =p

Pour voir un peu ce qu'il se passait j'ai mis jr start juste après le label, mais il n'est jamais utilisé. À part ça, j'ai mis exactement ce que tu as mis en remplaçant bien sûr le "NomPrgmPourIon" par "test" vu que mon programme s'appelle test.z80.

Tu l’exécute bien avec ion? (avec le programme A)?

Tu l’exécute bien avec ion? (avec le programme théta)?

Oui utiliser ion, mais l'aparté n'est pas clair du tout.
Installation en exécutant ION pendant que IONZ est présent.
Puis utilisation en exécutant A pendant que thêtaION est présent.

Autant pour moi je pensais à tors que le prgm de lancement s'appelait théta mais c'est bien A qu'il faut exécuter (j'édite mon message pour corriger)

Ouais mais Ion ne le détecte pas...
Je rappelle mon code au cas où j'aurais fait une faute :

Code:

#define TI83
 .nolist
 #include "ion.inc"

#ifdef TI83P ;inutile ici mais au cas où tu aurais à compiler pour TI 83+ ça peut toujours servir
 .org progstart-2
 .db $bb,$6d
#else
 .org progstart
#endif
 ret
 jr nc,start
 .db "tuto",0
      
   .list
start: ;Le code commence ici après le lbl start
 ld b,100
 call ionRandom
 ld h,0
 ld l,a
 call _disphl
 ret
.end

Il ne le détecte pas? Alors comment fais tu pour le lancer?   

J'utilisais send(9prgmTUTO) ^^'
Je l'ai exécuté avec venus aussi car apparemment il peut faire les programme pour ion... mais rien non plus. Je ne sais pas ce que je doit faire ce ne serait pas un problème qui vient du header ?

Déjà les programmes pour ion ne peuvent pas être lancés avec SEND(9prgmXXX
Ni avec vénus si tu utilises des routines de ion!
Donc:
Transmet ion sur ta calto.
Installe le (en lançant prgmION)
Puis pour l'utiliser:
prgmA et là tu choisis ton prgm...

J'ai juste un doute avec ton prgm, tu peux me passer le prgm que tu transmet à ta calto? (héberge le quelque part et passe moi un lien)

C'est bien ce que je fais, je sais utiliser ion ^^

Heu ouais, si tu veux... https://mega.co.nz/#!MZpRDawa!2X_LL4TUqU-J3lnvA2U0ka3crOkgXXF-fg6Lw7UMa54

C'est bien ce que je pensais
Voici le code de ton prgm:

Code:

C9180E52616E646F6D20486561727473000664CD000026006FCD0947C9
End
0000
End

Il est unsquished! C'est à dire codé avec des caractères hexadécimaux, et non pas codé pour un shell...
Ce type de prgm se lance bel est bien avec la commande SEND(9prgmXXX, mais comme tu utilises des routines de ion à l'intérieur du prgm... ca ne peut pas fonctionner...

Ca vient de l'Assembleur que tu utilises je vais te passer ce qu'il faut pour y remédier

L'assembleur que j'utilise ? J'utilise un assembleur pas pour Ion en gros... je devrais changer mes habitudes ou c'est juste le header qu'il faudra changer ?

Non c'est du fait que soit tu utilise par derrière un logiciel pour "unsquisher" tes prgm vers de l'asm codé en caractères hexadécimals, lançable avec la commande SEND(9prgm uniquement, ou que ton Assembleur le fait directement.

Dans cette archive tu trouveras tout ce qu'il faut pour compiler pour Ion ou en unsquished à partir d'un même code:
https://www.mediafire.com/?5y9flubi7bl44e1
Lance compilerPourIon pour obtenir un prgm utilisable avec ion, et CompilerUnsquished pour un prgm qui doit être lancé avec SEND(9prgm (attention celui ci devra ne pas comporter l'en tête d'ion et ne pas utiliser de routines d'Ion. Réfère toi au code source que j'ai mis avec pour voir comment je fais (du coup dans l'exemple ça ne fait pas d'aléatoire, il aurait fallu définir une routine d'aléatoire à utiliser uniquement si on unsquishe le code ensuite)).

Dans les propos il y a confusion entre le langage assembleur et le logiciel assembleur. Le logiciel assemble un code de langage assembleur.

Il se trouve que les programme peuvent avoir deux formats.
Soit ils sont lisibles dans l'éditeur de TI (unsquished) et on peut les exécuter avec Send(9prgm soit ils ne le sont pas (squished) et c'est le processeur qui pourrait le lire directement. Cependant le système de TI83 est conçu pour lire des unsquished. ION apporte à la fois des routines et l'avantage de lire des squished. Avantage puisque la création squised demande moins de travail et donne un résultat plus léger.
Spasm permet ici de compiler le binaire et bin2var permet de convertir en programme TI.
L'embrouille est que bin2var donne des squished et bin2var2 donne des unsqhished.

Sauf erreur, bin2var comme bin2var2 donnent des unsquished à partir de fichiers .bin, et peuvent donner des squished pour 8xp ("An update to Bin2Var that makes ready-to-run unsquished 83p and 8xp files, as well as ready-to-run squished 8xp files without requiring .db statements at the beginning of your asm file" cf description de bin2var2 sur ticalc.org)
spasm se charge directement de convertir un code soit en prgm squished soit en fichier .bin inutilisable tel quel.
bin2var2 n'est qu'une amélioration de bin2var...
Il me semble bien que c'est ça puisque j'ai déjà utilisé les 2 pour obtenir des unsquished...

EDIT du 27/03 à 17h00: En fait Linka a raison, je me suis trompé quand à l'utilité de bin2bin83...

Non je conteste en lisant le paragraphe suivant du readme et chacun des batch fournis.

Bin2var.exe squishes, Bin2var2.exe doesn't.  The syntax is the same for both.
Bin2var(2) input.bin output.ext
  valid output extensions are 82P 83P 8XP 85s 86p 86s, although I only modified 83P and 8XP
  The others still work exactly the same.

Il ne reste plus qu'à remplacer tasm par spasm. "sq" dans les titres de batchs pour "squished".

83asm.bat a écrit:@echo off
tasm -80 -i -b %1.z80 %1.bin
bin2var2 %1.bin %1.83p
del %1.bin >nul

83sqasm.bat a écrit:@echo off
tasm -80 -i -b %1.z80 %1.bin
bin2var %1.bin %1.83p
del %1.bin >nul

83pasm.bat a écrit:@echo off
tasm -80 -i -b %1.z80 %1.bin
bin2var2 %1.bin %1.8xp
del %1.bin >nul

83psqasm.bat a écrit:@echo off
tasm -80 -i -b %1.z80 %1.bin
bin2var %1.bin %1.8xp
del %1.bin >nul

Oui spasm peut générer des 83p et 8xp. Mais les 83p m'ont posé des problèmes que j'ai attribué au format et personne n'a contredit mes observations sur ti-planet (dans le sujet de spasm_gui).

Ouha, bravo et merci beaucoup ! Ça marche à merveille, juste un truc que je n'ai pas très bien compris : pourquoi la ligne #ifdef ION ? Si c'est pour savoir si on a définit Ion je pense que ce n'est pas nécessaire de le mettre vu que le programmeur doit savoir quand il utilise ion ou pas ? Ou alors c'est une convention, mais dans ce cas ce n'est pas très pratique ^^

Ah et que veut dire #defcont ? Ce n'est pas dans le programme mais j'en profite pour vous demander à quoi il sert parce que dans bell.inc dans les lignes 250 il y a ça et SPASM m'avertit d'un problème... en gros c'est ça :
#defcont \ out (0),a
Et SPASM :
bell.inc:266: error: Can't recognize ' ' as an instruction or macro. J'ai enlever tous les espaces de la ligne mais il me met quand même une erreur :p

Allez si vous ne savez pas ce que c'est ce n'est pas grave, vous avez déjà résolu mon problème pour ion et je vous en suis reconnaissant :)

Une doc de TASM.
http://guide.ticalc.org/advanced/asse.htm
La page de documentation de SPASM qui semble incomplète.
http://wabbit.codeplex.com/wikipage?title=SPASM%20Preprocessor

#defcont permet d'annoncer que cette ligne est la suite du define précédent.
Le symbole \ marque le retour à la ligne pour le contenu du define.
Tant que le code n'est pas trop large pour ton éditeur, tu peux te contenter de tout placer sur la même ligne et marquer les retours du contenu du define avec le "\".
#define bcall1(xxxx) rst $28 \ .dw xxxx
#define bcall2(xxxx) rst $28
#defcont \ .dw xxxx

Merci beaucoup en tout cas, je vais essayer de me débrouiller avec ça =)

Désolé, mais je suis sur que bin2var permet aussi d'obtenir des unsquished à partir de fichiers .bin...
C'est d'ailleurs ce programme que j'ai utilisé récemment afin de rendre des programmes unsquished au ti concours...

Je n'ai pas de problèmes avec les 83p générés par spasm (ils sont squished par contre), mais je confirme qu'il ne faut pas utiliser spasmgui.exe pour les 83p, mais bien spasm.exe.

(Il me semble par contre avoir lu qu'il faut rajouter une ligne au début du fichier contenant le code source pour avoir un prgm squished avec bin2var mais je suis pas sur et je retrouve plus...)

Ici: http://tiplanet.org/forum/viewtopic.php?f=41&t=9133&start=20
Premier message troisième page: il utilise bin2var et obtient bien un prgm unsquished...


@Clarsis: mon "#ifdef ION" c'est pour pouvoir produire des prgm pour ion (qui utilisent ses routines) comme des prgm unsquished ou squished mais pas pour ion (vénus etc), à partir du même code source, en fonction de si ION est définis ou pas, tu utilises une routine de ion ou une routine perso (qui reste à définir). Du coup tu peux distribuer ton prgm en squished pour ion ou pas ou en unsuished, libre à l'utilisateur averti de choisir ce qu'il préfère (même si ce n'est pas indispensable je te l'accorde, perso je te conseille d'éviter d'utiliser des routines de ion (parce que tes prgm ne sont alors plus lançable par d'autres shell comme vénus etc)).

Ici: http://tiplanet.org/forum/viewtopic.php?f=41&t=9133&start=20
Premier message troisième page: il utilise bin2var et obtient bien un prgm unsquished...

contra-sh a utilisé bin2bin83 pour réaliser l'étape d'unsquish, juste entre spasm et bin2var.

(Il me semble par contre avoir lu qu'il faut rajouter une ligne au début du fichier contenant le code source pour avoir un prgm squished avec bin2var mais je suis pas sur et je retrouve plus...)

Parles-tu simplement du $bb6d en début de programme ? Ou autre ?
Puisque Bin2var2 ajoute les mots-clés lors de l'unsqhish, le code source n'a plus besoin de rien. Sinon il faut ajouter soi-même des mots-clés, et dans le cas d'un 8xp squished on peut simplement insérer $bb6d dans le code source. Quoi d'autre selon toi ?

Okay je viens de comprendre ma confusion: je ne savais pas que bin2bin83 permettais de faire l'unsquish, pour moi c'était juste pour passer d'un 83P/8xp à un bin sans rien changer dans le code... Du coup je pensais que c'était bin2var qui faisait l'étape l'unsquish...
Autant pour moi désolé.

Ok, en effet, c'est sûr que c'est mieux de ne pas utiliser Ion, par exemple IonRandom n'a rien de plus que random...

IonRandom est une routine définie par ion mais random? Je n'ai jamais entendu parler de cette rom call (elle n'est pas référencée sur wikiti je crois).

Ça se passe dans ti83.inc mais pas que je pense, c'est très pratique et ça marche pareil que IonRandom je crois :
- b est la limite
- le resultat est dans a, la limite est 255, c'est dommage d'ailleurs pour un + ou - ^^

La ligne :

Code:

#define _Random 50B6h

Tu peux toujours tirer 2 nombres au hasard: le premier tu le mets dans h et le second dans l, et comme ça tu peux aller jusqu'à 65.535
en fait tu es sur que ça ne génère pas un nombre aléatoire entre 0 et 1 dans OP1? Il me semble que c'est pour ça que je ne l'ai jamais utilisé mais je ne suis pas sûr du tout
Ca me parait bizarre qu'ils aient refais une routine pour ion qui existait déjà nativement...
Voici une routine d'aléatoire si c'est bien ce que j'ai dis plus haut:
http://wikiti.brandonw.net/index.php?title=Z80_Routines:Math:Random

Ah ouais je n'y avais pas pensé...

Ben si puisque j'ai fait mon + ou - avec et il y avait des nombres jusqu'à 255. Peut-être que celle de Ti83.inc à été inventée après ^^
Bon, c'est vrai que y'a des petits trucs énervant mais normaux puisque c'est convertit en binaire (le nombre est 240, on écrit 100, il met que c'est moins, on écrit 200, il met que c'est plus ^^) mais je pense que Ion est pareil, ou alors ce serait là son truc en plus...

L'include ne sert qu'à référencer les rom call de la calto, il ne définis aucune routine.

clarsis a écrit:Bon, c'est vrai que y'a des petits trucs énervant mais normaux puisque c'est convertit en binaire (le nombre est 240, on écrit 100, il met que c'est moins, on écrit 200, il met que c'est plus ) mais je pense que Ion est pareil, ou alors ce serait là son truc en plus...

Je n'ai pas compris, ça ne peut pas être moins que 100 et plus que 200...
Ce n'est en aucun cas une question de la routine utilisée pour l'aléatoire, mais de celle utilisée pour l'affichage ou l'input: certaines fonctionnent en héxa et d'autres en décimale selon ce que tu fais. (il n'est pas question de décimal d'ailleurs...)
Donc rien à voir avec ion ou pas.
Mais par contre c'est sur que tu te retrouves avec un nombre compris entre 0 et 255 puisque c'est le cas de tout registre .
Je vais regarder tout à l'heure voir si ça change OP1 ou pas pour confirmation.

Par ailleurs il faut s'assurer que le codage et les opérations sont de signe adéquat. Par exemple ne pas confondre -128 (en complément à deux) et +128 (en naturel) car les deux sont codés %1000_0000.