WLib : Topic de dev

Hello les gens

J'ai l'honneur d'inaugurer ce sous-forum avec le premier programme ASM du site, WLib !

Y'a un petit moment, je me suis pris de pitié pour les pauvres 82 stats/83 qui n'avaient rien pour les aider à programmer en Basic ... J'ai donc décidé aujourd'hui de remédier à cela !

WLib est un programme ASM comparable à XLib ou Celtic : il permet d'utiliser des fonctions supplémentaires en plus des fonctions du TI-Basic. Je crois que je peux appeler ça du Basic étendu.

Alors vu que je n'ai pas d'ordi en ce moment, j'ai dû encore une fois tout faire en hexa avec mon bon vieil émulateur sur mon téléphone. Conséquence : il n'y a pour l'instant que deux fonctions utilisables

Voilà donc comment marche le truc : vu que sur les 82 stats/83 y'a pas de parser hook (ce qu'utilise les libs de basic étendu pour changer l'effet de fonctions TI-Basic, comme det( ou conj( ), il faut charger les arguments et numéro de la fonction à appeler, puis lancer Send(9prgmWLIB).

Là où je suis fier de moi c'est que tous les arguments d'une fonction sont passés par la liste LPARAM, que vous créérez pour l'occasion :PWLib va allez directement pêcher les arguments dans cette liste. Si LPARAM n'existe pas au moment de l'appel d'une fonction qui nécessite des arguments, la fonction ne fera juste rien. Par contre, si y'a pas assez d'arguments ... Big bordel (même si pour l'instant la seule fonction qui prend des arguments n'en attend qu'un )


Assez parlé, et place au code ! À recopier sur la calculatrice pendant que c'est assez court pour être possible, NON COMPATIBLE TI-83+/84+ MAIS UNIQUEMENT TI-82 STATS/83 :

Code:

CDDC4E
CDFC4E
7B
FE02
D0
6F
2600
29
118093
19
7E
23
66
6F
E9

010003
21298E
7E
2F
77
23
0B
79
B0
C8
18F6

CD8493
D8
EB
23
23
E7
CDFC4E
4B
42
C5
21298E
112A8E
3600
010B00
EDB0
C1
C5
211C91
112891
01F402
EDB8
CD9C4B
C1
0B
79
B0
C8
18EA

3E93
4E93

218C93
E7
CD2A44
C9

015D504152414D0000
End
0000
End

Exemple en Basic :

Code:

:ClrDraw
:0:Send(9prgmWLIB
:64->LPARAM(1)
:1:Send(9prgmWLIB

Liste des fonctions disponibles :

• invScreen (fonction 0) : inverse les pixels de l'écran. N'attend aucun argument
  
• shiftDown (fonction 1) : scrolle l'écran vers le bas. Attend comme seul argument le nombre de lignes à scroller.
  

Voilà, je serai plus efficace à bosser dessus quand j'aurai mon PC :Pceci dit, le système d'argument et de reconnaissance de fonction est déjà bouclé, donc ça devrait se limiter à "ajouter des fonctions jusqu'à plus d'idées".


Enjoy

Dernière version + documentation ici : http://mattias.refeyton.fr/espace-ti/Wlib/Wlib.zip

Merci!
Mais pourquoi NON COMPATIBLE TI-83+/84+ ?

Parce que c'est de l'hexadécimal, de l'asm "compilé" (c'est pas vraiment juste mais je ne sais pas comment dire) pour la Ti 82stats/83, et que les adresses des fonctions ne sont pas les mêmes sur la ti 83+/84+, donc tu fais planter ta ti...

Matref a écrit:Par contre, si y'a pas assez d'arguments ... Big bordel

Pourquoi donc?
Il suffit de vérifier que la taille de la liste corresponde et c'est tout non? Je ne sais pas quelle rom call tu utilises pour récupérer l'adresse de la liste mais normalement elle devrait aussi renvoyer sa taille dans un registre non? (ou sinon la taille doit etre dans la VAT ou au début de la liste je ne sais plus)

Parce que WLib utilise des ROM calls, et que les adresses de ces dernières changent entre les 82 stats/83 et les 83+/84+ (en plus d'autres trucs en rapport avec les adresses).


M@thieu41 : j'aurai pu, mais n'ai pas pensé à ajouter cette protection, puis ne l'ai pas fait puisque ça aurait bougé toutes les adresses relatives (labels etc).

Ah la la... voilà pourquoi l'asm non compilé c'est mieux que l'hexa compilé  
En plus tu aurais pu avoir une compatibilité avec la 83+/84+

Sans blaaaaagues, je te rappelle que j'ai que l'émulateur de TI-83 sur mon téléphone pour programmer, j'ai pas d'ordi jusqu'à Lundi.
EDIT : je précise parce que je me suis mal fait comprendre apparamment, WLib se veut un programme pour une base de Basic étendu. La TI-83+/84+ en a pas du tout besoin, y'a déjà XLib, Celtic III, les DCSB libs... WLib est ciblé TI-82 stats/83.

Bien sur, mais ça permettrait une compatibilité pour les prgm qui utiliseront ta librairie de basic étendu, ce que les autres ne permettent pas

Effectivement, c'est une possibilité, j'y avais pas pensé je peux donc finir complètement une des deux versions, puis tout simplement la recompiler en changeant de fichier include

Et ainsi naîtra la première lib de basic étendu pour TI z80 non flash, et la seule qui soit cross-compatible o/

EDIT : j'y pense, comme je n'ai aucune idée de ce dont un programmeur Basic a besoin, lâchez toutes vos idées de fonctions à implémenter, mais éviter de proposer une fonction parce que vous avez en tête un programme qui l'utilise...

Je te donne quelques idées en vrac :
_Afficher un sprite (en mode or, xor ou and),
_Créer un programme et son contenu,
_Vérifier l'existance d'un programme,
_Modifier/Récupérer les données d'un programme,
_La saisie directe d'une touche,
_Eteindre la ti,
_Controler l'etat des piles/mémoire...

Certains ne servent pas toujours, mais peuvent être intéressants dans certains cas. La fonction d'affichage de sprite peut être très intéressante, mais il faut voir comment transmettre les données du sprite sans utiliser trop de mémoire...

m@thieu :
un sprite 8*8 ça prend 8 octets donc 16 quartets, c'est pas dramatique d'écrire ça en 16 tokens dans l'éditeur BASIC. Et 16 en décimal ça prend maxi 2 tokens, on va dire 32 tokens.
Donc du 8*8 tient en 16 ou 32 tokens, c'est pas dramatique.
Si tu veux faire plus grand, tu peux faire une tilemap, ou utiliser une Pic (ou autre donnée bien choisie voire préparée à l'ordinateur)

Les modes "or,xor,and" c'est en anglais ce que j'appelle "set,toggle,reset". Je sais pas ce que tout le monde utilise...

matrefeytontias :
Tiens c'est pas la première fois qu'on parle (mais sur espace-ti) de librairie de basic étendu à utiliser sans hook... mais tu es sûrement le premier à te lancer.  

Je te conseillerais plutôt une liste personnalisée contenant "WLIB" dans son nom.

*** Je crains que les idées sur la syntaxe et les variables aillent vraiment trop loin...

Des fonctions de gestion (création,affectation,suppression, test d'existence, renommage,...) pour tout ce que TI ne fait pas (programmes par exemple et surtout test d'existence de n'importe quoi).

Eventuellement usage de pointeurs (nombres) pour indiquer des données.

J'hésite entre tout faire à partir de fonctionnalités ou permettre au lecteur de liste d'interpréter en fonction de types qui seraient indiqués.
la première serait probablement plus simple à créer, l'autre peut-être plus simple et rapide à executer.

Accéder à des variables "pirates" comme celles de XtraToken ou les programmes que tu dissimules avec HIDE.
>gestion (affectations, suppressions, nom,test d'existence, renommage)
>que les autres fonctions de gestions soient déclinée pour ces variables pirates
>>copie dans une variable standard et visse-versa
>>utiliser pointeur

Pouvoir donner des informations sous forme de chaînes, en indiquant dans la liste des numéros pour dire dans quelle chaîne se trouvent les informations qu'on donne. (ou pointeur ou encore plus tordu pour des chaines pirates)
(Je sais que tu ne voudras pas utiliser Ans, tu l'as déjà rejetée de ma part sur espace-ti)

concepts sur les variables:

***

Une fonction pour insérer dans une chaine (désignée en argument) le token portant le numéro fourni en argument !!!!
Eventuellement prendre une liste de numéros pour pouvoir créer facilement une chaine spéciale réutilisable en Basic sans Wlib.

Des fonctions de pixels qui supportent de dépasser de l'écran sans planter.

Une fonction d'écriture qui permette d'écrire avec des arguments similaires à printf en language C, en utilisant une chaine de caractères.
Je désire très fort pouvoir contrôler
-retour à la ligne manuel et/ou auto
-les variables à intégrer
-permettre de récupérer les coordonnées de la fin dans des variables numériques
-que des caractères puissent dépasser de l'écran sans planter
D'ailleurs la saisie des données peut être répartie entre la chaine et la liste... du genre texte dans chaine et variables dans la liste, ou même dans une autre liste qu'on désignerai dans celle des paramètre.

Permettre d'effectuer certaines actions en utilisant une variable chaîne au lieu que ce soit en dur comme l'habitude du Basic.
>les executions de programmes
>les accès (lecture/écriture/) aux listes personnalisées
>>Cependant on peut se débrouiller sans si on a des fonctions de gestions comme j'ai parlé plus tôt.

Sauver et rappeler l'emplacement de la lecture du programme ?
Je ne sais pas encore dans quelles situations cela serait utile et irremplaçable.
Cela éviterait juste à Persalteas d'utiliser une variable et des Goto dans Herssahe.
Je pense que ce serait fiable tant qu'on n'a pas modifié le programme entre temps.

Pouvoir effectuer sur des matrices des tests entre termes et sur des listes des tests globaux.

Executer un programme qui contient uniquement des listes snas devoir appeler WLIB entre chaque ligne.
(pour chaque ligne forcer la TI à executer les listes comme du basic, en utilisant la pile pour sauver l'état précédent de l'interpréteur Basic)

Un break pour des boucles.

Je cale cette fois, l'après midi a été longue. A plus.

Alors la moitié des trucs que tu as demandé est infaisable par moi Je te rappelle que je suis pas Xeda ou tr1p1ea moi ...

Ce que je ne ferai pas :

Impossible d'utiliser des pointeurs ; impossible de push/pop des adresses, le Basic est bien plus compliqué que ça ; impossible de passer des arguments de types multiples, les listes ne peuvent contenir que des nombres (mais j'ai mon idée) ; laisse tomber printf ; une fonction automatisée d'exécution de chaîne, y'aura qu'à la copier dans un programme puis l'exécuter ; les variables pirates (trop dur à gérer) ; j'en oublie sûrement.

Ce que je ferai sûrement :

Supports des sprites (sauf AND, et pas clippés) ; pixels clippés (OR/XOR/AND) ; tout faire avec les programmes et appvar (sauf renommer et cacher, faudra utiliser ZHIDE) ; l'exécution chaînée (exécution de plusieurs fonctions de WLib à la suite, tant qu'il y a pas à changer les arguments ...) ; allumer/éteindre l'écran (le programme tourne toujours ... Faut pas oublier de le rallumer avant de quitter) ; du tilemapping ; et j'en oublie sûrement.

Par contre soyez bien conscients que ça arrivera pas dans un mois hein.

Pour le passage d'arguments autre que des nombres, j'ai pensé à une manière. Exemple, on veut afficher en (0;16) le sprite dans Str1 :

Code:

:"3C4281818181423C->Str1
:0->LPARAM(1)
:16->LPARAM(2)
:1->LPARAM(3)        // utiliser le sprite dans Str_1_
:xxx:Send(9prgmWLIB

Il faudra évidemment savoir quel argument de quelle fonction correspond à quoi, mais c'est le plus léger et rapide à l'écriture comme à l'exécution.

Je vois que je me suis mal exprimé ou que j'ai noyé le poisson :
je voulais justement proposer de stocker une chaine puis dire dans la liste paramètre quelle variable chaine utiliser.
{idfonction,indice_chaine}
J'essayais de m'économiser des définitions de cas en disant d'inclure les syntaxes les unes dans les autres. A tous les coups tu as lu un "{chaine}" qui ne t'a pas éclairé. Cela revenait à dire d'inclure "type,indice"

Je préfère demander/proposer pour rien que taire quelque chose qui pourrait intéresser.
J'ai émis la plupart des choses que je désire et des idées qui ne me tienne pas à coeur. Ex : Les pointeurs je m'en fiche mais je me disais pourquoi pas, la gestion de variables (genre liste) dont le nom est dans une variable (chaine en l'occurrence) m'intéresse beaucoup.

Prend ton temps et tes moyens. J'encourage.

Merci de m'avoir répondu

Bump,

Je me suis occupé de plusieurs choses qui ne seront donc pas à faire plus tard : l'indirection fonctionne (exemple, passer 3 en paramètre pour indiquer Str3), θ sera utilisée comme variable de sortie (j'ai bouclé la routine qui lui assignera 0 ou 1), et j'ai mis en place une sécurité qui arrête la fonction en cas d'un nombre d'arguments insuffisants.

Également, la vérification de l'existence d'un programme fonctionne. J'ai bien peur que la lib devienne un peu beaucoup trop grosse pour être recopiée à la main (rien que là elle fait environ 350 octets).

Je pense que de toute façon c'est mort pour faire un truc potable à la main. A la limite, si tu y tiens vraiment et si c'est possible, tu pourrais la diviser en plusieurs parties afin que l'on se serve un peu comme on veut, mais ça risque de créer une jolie pagaille.

A mon avis, ce n'est pas le problème prioritaire... En même temps, je ne suis pas trop concerné par le recopiage, mais bon.

En tout cas, super projet ! En attendant l'hypothétique Grammer 82, ça va faire plaisir à pas mal de monde. Bravo et merci !

Merci

Aussi j'ai oublié de le préciser, la liste WLIB est maintenant utilisée pour passer les paramètres. Ça gêne personne personne θ comme variable de sortie ?

Aussi, est-ce que je devrais arrêter le programme et afficher ERR:ARGUMENT quand y'a pas assez d'arguments pour une fonction ? Ça peut être pratique nan ?

Ouais quand il y a un problème avec les arguments c'est bien de renvoyer cette erreur au moins on sait ce qui va pas, tandis que si tu fais rien bah on peut continuer comme si ça avait fait ce qu'on voulait, et du coup bah ça fait tout tomber à l'eau de toute façon...

Par contre théta je ne sais pas trop, ce n'est pas la variable la moins utilisée... Pourquoi pas genre une variable de statistique où autre qu'on utilise presque jamais?

Parce que θ contient juste un float, et les floats c'est facile de les mettre à 0 ou 1 (une ROM call en fait, _OP1set0 ou _OP1set1). Les variables statistiques je sais pas les utiliser.

Aussi, moi ça me plaîrait moyennement d'aller dans 14 menus pour trouver une variable que je vais utiliser souvent. Une autre proposition de variable de sortie ?

Pourquoi pas Rép tout simplement?
Je crois que c'est plus dur à manipuler en asm, mais ça serait plus pratique pour nous je pense.

Ou sinon W (pour WLib), parce que je sais pas les autres mais j'ai l'habitude de me servir des premières variables, de théta, de X, Y ou Z à la rigueur, mais très rarement W ...

Pas bête ... Ça va pour tout le monde W ? (ceux qui lisent ça)

Yep, bonne idée.  

Okay ben je fais ça alors

LOL, moi j'utilise tout le temps W comme compteur. Tant pis.

Je pensais que tu pourrais indiquer les variables d'entrée/sortie de la même façon que tu indiquerais la chaine pour un sprite.
Je pensais aussi que tu formaterais toutes les syntaxes des fonctionnalités pour utiliser des routines communes de ton programme.
Ainsi ce ne serait pas forcément une variable fixée... en plus tu as à ta disposition les romcalls RclSysTok et StoSysTok.

Tu appelles float le codage de TI, mais pourquoi, puisque la convention IEEE754 ne définit pas la mantisse en BCD comme fait TI ?

Quand je dis "float", je désigne l'implémentation de TI, j'vais pas répéter "les floats de TI".

Ça serait un gâchis de performances et de clareté que de permettre plusieurs variables de sortie.

Et sinon en mettant une sortie "standard" (W ou autre), et permettre en argument facultatif une sortie spéciale? Sinon ce n'est pas trop grave: tu choisis une variable (pas trop utilisée non plus), et on s'adaptera si on veut utiliser ta lib.

Nan nan, il y aura une sortie, ça va être trop compliqué sinon.

Création de programme terminée ! Elle créé un nouveau programme dont le nom et la taille en octets sont passés en argument (dans cet ordre), et écrase le programme existant du même nom s'il y en a un. C'est le fopen(file, "w") du C.

EDIT : je le remplis avec quelque chose le programme créé ?

Heu... il faudrait qu'on puisse choisir si on veut effacer l'ancien ou pas, parce que là c'est un peu brutal de le supprimer comme ça...

Une liste de tokens passé en arguments dans une chaine? Par contre il faudrait par exemple remplacer ":" par des retours à la ligne, et les "->" par des sto, puisqu'on ne peut pas les mettre directement dans une chaine en ti basic...
Sinon ça ne sert à rien de créer un prgm vide  

Pour éviter de supprimer un programme existant, tu vérifies s'il existe avec 5:Send(9prgmWLIB), ça renvoie 1 ou 0 dans W selon qu'il existe ou pas respectivement.

Ce que je voulais faire, c'est créer un programme vide (là j'ai fait en sorte qu'il soit rempli de :, comme ça on peut l'exécuter sans bugs même si on le remplit pas complètement) qu'on puisse remplir et vider comme on veut, avec des fonctions d'overwrite (pas d'insertion pour l'instant, je galère beaucoup trop avec ça).

EDIT : j'ai prévu que deux ':' à la suite ferait un saut de ligne, et que "->" ferait un sto (l'opérateur binaire, pas unaire).

Ca peut aller, même si ça risque de prendre rapidement beaucoup de place, si on doit mettre 2 ":" à chaque fois pour un retour à la ligne...

Pour l'insertion tu peux utiliser la rom call InsertMem qui marche bien (j'avais un projet (un peu à l'abandon en ce moment) qui l'utilisait, et ça marchait : http://www.yaronet.com/posts.php?s=157496 ). Ce n'est pas très compliqué, mais il faudrait trouver un moyen pour savoir où insérer ces instructions...

Le risque étant qu'on veuille afficher ':' dans une chaîne de caractère par exemple ... alors que "::" c'est assez rare quand même.

Pour insérer les instructions, on peut toujours compter par lignes. J'ai aussi pensé à un système de gestion de programmes ressemblant à celui du C : on ouvre un programme (s'il n'existe pas il est créé), ce faisant on initialise un curseur virtuel défini par un numéro de ligne et un numéro de caractère. On peut alors écrire à l'emplacement du curseur, y insérer des trucs (peut-être) ou le déplacer. Quand on a fini, on ferme le programme. Le souci étant qu'on ne pourra ouvrir de cette manière qu'un programme à la fois, parce que bon merci bien hein, mettre à jour une table en relation avec un programme Basic c'est ouff >_>

C'est vrai, c'est embêtant, "::" est une bonne idée du coup.

Ca pourrait être pas mal comme ça, et pourquoi pas rajouter une commande qui permettrait de lire une ligne du programme? (en la stockant dans une chaine par ex).
Par contre, tu parles "d'ouvrir" un prgm, j'espère que tu ne veux pas qu'il soit "refermé" après? parce qu'on ne peut pas en être sur (même si l'utilisateur de la lib pense à le faire, celui qui lance le prgm basic peut très bien quitter le prgm avec un "On", et là ça ne fermera pas du coup...).
Mais je ne comprends pas pourquoi tu dis ne pouvoir ouvrir qu'un prgm à la fois? Qu'entends tu par "mettre à jour une table en relation avec le prgm"?