Débutant en ASM, demande Tutorial - Page 3

ExtendeD : il a déjà été un peu atteind avec la ROM 2.08 : leur launcher (ttpack) ne fonctionnait pas
Il leur faut recompiler tous les lauchers de tous les programmes (ou se faire chier à utiliser un laucher pour tous les programmes, donc à devoir passer par l'écran Home à cause du paramètre réclamé par ttpack)

Alors que pour les progs kernel, il a suffit que les utilisateurs mettent à jour UN programme : le kernel

par ttpack ?
ou par ttstart ?

perso, j'utilise toujours ttstart : aucun lanceur personalisé.
comme ça, aucun pb d'incompatibilité (ttstart étant en règle générale le premier lanceur mis à jour ), et économie de mémoire (entre 1.5 et 2 ko par lanceur...)

et je l'utilise aussi pr le sprog kernels compressé en PPG, d'ailleurs

Je confond les deux, pardon. Mais ça ne change rien au constat : KERNEL POWWWAAAA

Kernel powa.... dans certains cas.
nostub powa dans d'autres


(mais je ne vais pas relancer le débat )

#49, Pen²: 2°/ et c qui l'autorité officielle sur TI ? Pas toi en tous cas [...]
Contrairement à toi, Kevin, fait partie d'une équipe qui est suffisamment connue et influente pour définir certains standards (standard de commentaires _nostub, notamment) pour la TI. C'est à dire la TIGCC Team, qui développe TIGCC, le principal outil de programmation sous 89/92+/V200 si on excepte l'outil officiel de TI, qui n'est que très peu utilisé pour les programmes ASM de toute façon. TIGCC n'interfère pas avec TI sur ce plan-là, contrairement aux kerneleux et leur format non natif...
Le kernel manque parfois de standards: trouvez-moi de façon simple (maximum 3 ou 4 instructions), compatible entre tous les kernels, l'adresse de début de la partie résidente en RAM du kernel... Ni DoorsOS ni UniOS ne le donnent autour de l'adresse 0x30; contrairement à PreOS (et KerNO), à 0x34. Je refuse d'augmenter la taille de tthdex pour des personnes (aussi compétentes qu'elles soient) qui n'ont pas été capables de se mettre d'accord.
Mais il est encore heureux que le format des programmes nécessitant un kernel soit compatible entre tous les kernels (ce format est incompatible avec le format d'AMS, rappelons-le encore une fois).
Pollux le disait une fois: si c'est incompatible avec TIGCC, ça sera peu utilisé, donc peu connu, donc peu utilisé...

> ExtendeD: ?? Explicite ta pensée.

#60, Thibaut: les faits sont exacts (sauf que le lanceur ne s'appelle pas ttpack, si j'avais envie d'être méchant je dirais que tu ne sembles même pas savoir exactement de quoi tu parles, que tu ferais mieux de te taire et d'aller coder tes projets...).
Mais les kernels (même PreOS, il suffit de lire 2 minutes les sources) ont encore quelques horreurs que le _nostub n'a/n'aura pas. Entre autres, le fait de rechercher les fonts par recherche des sprites en ROM. C'est très lent. Et de plus, ça n'est pas compatible AMS 2.xx: je vous rappelle que les fonts peuvent être redéfinies sous AMS 2.xx (les kernels trouvent d'ailleurs parfois les fonts du boot, ce qui est ridicule...).
Donc les RAM_CALLs correspondants ne reflèteront pas ce que l'utilisateur a fait sur sa calculette, c'est à dire un truc parfaitement prévu par le système mais pas par un kernel qui ne fait pas partie du système...
En plus, il est parfaitement trivial de trouver les adresses des fonts, sans rechercher les sprites, sur AMS 2.xx ET AMS 1.xx. Ca m'a pris bien moins d'une demi-heure, et je ne suis pas le plus grand maître de l'ASM 68k de tous les temps.

Ces RAM_CALLs deviendront bientôt obsolètes (s'il ne l'étaient pas encore), quand des remplacements de DrawStr auront été ajoutésà TIGCCLIB.
Ces remplacements seront:
- bien plus rapides (un bench plus détaillé que celui que j'avais posté il y a un moment sera cependant nécessaire, comme d'habitude je posterai le source de mon bench pour que tout le monde puisse le reproduire),
- compatibles _nostub et kernel (ce qui n'est pas le cas des RAM_CALLs non standard...).




(Je suis resté déconnecté plus d'une heure avant de poster ceci. Le dernier post que j'ai vu est le #60, de Thibaut).

Pollux le disait une fois: si c'est incompatible avec TIGCC, ça sera peu utilisé, donc peu connu, donc peu utilisé...

Ne fais pas de citations en dehors de leur contexte

TI-GCC ne pourra pas compiler de progs GT-Basic, c pas pour autant que ça sera peu utilisé

> Ne fais pas de citations en dehors de leur contexte
Excuse-moi. Ceux qui suivent la communauté connaissent le contexte, pas les autres, c'est vrai.
Par contre, je croyais que c'était à propos de GTC, pas de GT-Basic. Que je sache, GTC != GT-Basic (ou me suis-je encore perdu dans tes programmes, comme l'autre fois où je croyais que GTools == GTC ?)

ça n'est pas non plus à propos de GTC, c'était à propos de TI-Lib, mais Kevin a refusé le projet, donc les progs GTC pourront être disponibles en version utilisant la Virtual Machine (elle permet aussi d'exécuter les progs GT-Basic...)

Pour replacer la citation dans son contexte, toutes les solutions pour gagner de la place ne sont utiles que si elles sont universelles (incorporées dans TI-GCC comme switch par exemple) ou si elles sont suffisamment répandues à cause de leurs avantages (comme ce sera le cas pour la Virtual Machine). Par exemple, les libs dynamiques ne répondent à aucune de ces conditions, et ont été assez mal conçues (puisqu'à l'époque, les libs statiques n'existaient pas), ce qui explique le fait qu'elles sont maintenant désuètes, à l'exception de genlib.

trouvez-moi de façon simple (maximum 3 ou 4 instructions), compatible entre tous les kernels, l'adresse de début de la partie résidente en RAM du kernel...
Peut-être que ça n'avait pas été implenté parce que ce n'est pas très utile.

Mais il est encore heureux que le format des programmes nécessitant un kernel soit compatible entre tous les kernels
Ca me rappelle il y a assez longtemps quand les programmes devait être distribués au format DoorsOS et au format PlusShell

Donc les RAM_CALLs correspondants ne reflèteront pas ce que l'utilisateur a fait sur sa calculette, c'est à dire un truc parfaitement prévu par le système mais pas par un kernel qui ne fait pas partie du système...
Avec TI ça ne fait jamais de mal de prend du recul par rapport au système, ils peuvent être imprévisibles, et que les programmes deviennent incompatibles ils s'en tapent (presque) complétement.

> ExtendeD: ?? Explicite ta pensée.
Il suffit de pas grand chose. Un nouvel gestion de l'écran qui ne permet plus d'utiliser les routines de gray actuelles. Un nouveau format de SYM_ENTRY.
N'importe quoi qui rende incompatibles les routines en lib statiques ou les enrobages de tipatch.lib.

> sauf que le lanceur ne s'appelle pas ttpack, si j'avais envie d'être méchant je dirais que tu ne sembles même pas savoir exactement de quoi tu parles, que tu ferais mieux de te taire et d'aller coder tes projets...

Si j'avais envie d'être méchant, je dirais que tu es réellement très con quand tu as envie d'être méchant

ExtendeD a écrit :
Et moi j'attends l'HW3, le vrai, qui fera tomber l'Empire de tous ces tirans de nostubiens

Il y a déja eu une mise à jour du matériel, et elle n'a pas changé grand chose. Juste quelques ennuis d'ordre mineur avec les lanceurs et avec la détection du modèle.

Et en cas de changement matériel, les TSRs (et donc le mode kernel qui en dépend) sont la chose la plus à risque. Sache que ce n'est que grâce à moi que l'exécution de programmes pour kernel est possible avec AMS 2.07... Les programmes _nostub non-TSR sont plus faciles à faire marcher en cas de mise à jour de AMS, de changements au niveau de la protection anti-exécution, ... Si les programmes _nostub ne marchent plus, les programmes pour kernel ne marcheront plus eux non plus.

Thibaut
a écrit : Il leur faut recompiler tous les lauchers de tous les programmes

Ça prend 2 minutes, et n'importe qui peut le faire, vu que la source du programme compressé n'est pas nécessaire.

(ou se faire chier à utiliser un laucher pour tous les programmes, donc à devoir passer par l'écran Home à cause du paramètre réclamé par ttpack)

Tu connais le TICT Explorer? Pas besoin de passer par l'écran HOME! (Et oui, je sais qu'il y a aussi ça dans Einstein, mais tu ne l'as pas sorti...)

Alors que pour les progs kernel, il a suffit que les utilisateurs mettent à jour UN programme : le kernel

Pour les programmes compressés, il suffit également de mettre à jour un programme: TICT Explorer.

ExtendeD a écrit :
Donc les RAM_CALLs correspondants ne reflèteront pas ce que l'utilisateur a fait sur sa calculette, c'est à dire un truc parfaitement prévu par le système mais pas par un kernel qui ne fait pas partie du système... Avec TI ça ne fait jamais de mal de prend du recul par rapport au système, ils peuvent être imprévisibles, et que les programmes deviennent incompatibles ils s'en tapent (presque) complétement.

Tu penses vraiment? Je te signale qu'ils sont allés jusqu'à avertir Thomas Nussbaumer du problème avec ttstart (et d'expliquer la raison de ce changement: c'est pour détecter des chaînes Exec ou des programmes en assembleur foireux, de style Exec "4e444e75" sans le 0000 obligatoire) plusieurs semaines avant la sortie des V200 et de AMS 2.07.

> ExtendeD: ?? Explicite ta pensée. Il suffit de pas grand chose. Un nouvel gestion de l'écran qui ne permet plus d'utiliser les routines de gray actuelles.

Encore une? Ils viennent d'optimiser la gestion de l'écran pour les HW2, ils ne vont pas s'amuser à tout refaire encore une fois. (Je te signale que le design du matériel leur coûte de l'argent!)

Un nouveau format de SYM_ENTRY.

Je ne pense vraiment pas qu'ils changeront cette structure, à part en rajoutant des champs à la fin (ce qui ferait que les programmes _nostub qui utilisent les ROM_CALLs de vat.h continueraient à marcher, alors que les programmes pour kernel qui vont traffiquer dans MainHandle ne marcheront plus parce qu'ils n'ajouteront pas le bon décalage pour passer d'une variable à la prochaine). Cette structure est même présente dans le header tiams.h de leur SDK, donc ils n'ont vraiment pas intérêt à la changer!

N'importe quoi qui rende incompatibles les routines en lib statiques ou les enrobages de tipatch.lib.

Genre? Si tu as des doûtes sur la portabilité d'une routine précise, ça serait bien de nous en parler...

je pense qu'il faut d'abord penser aux utilisateurs: est-ce qu''on apprecie vraiment d'avoir a chercher des patchs, des kernels, des libs, pour faire tourner des programmes au final pas si nombreux...
mais bon, chacun fait comme il veut...

xeno
a écrit : je pense qu'il faut d'abord penser aux utilisateurs

C'est ce que je dis toujours.

mais qd les utilisateurs te demandent quel kernel installer, tu leur dit de ne pas en installer
(même si tu les renvoie en même temps vers PreOS)