Détecter la version HW d'une TI en 3 instructions - Page 2

Thibaut, je suis 100% d'accord avec Kevin Kofler.

La lecture d'un port inexistant ne renvoie pas nécessairement 0 mais une valeur qui peut être aléatoire ou complexe. Rien ne garantit que toutes les HW1 sont câblées d'une même manière et que toutes les HW2 sont câblées d'une même autre manière. On sait depuis longtemps qu'il existent des HW1 différentes, et des HW2 différentes (il n'y a qu'à voir Archive Utility 3 échouer sur certaines HW1 récentes ou encore le fait que certaines TI92+ HW1 ont la flash mappée en $200000 et $400000 et d'autres seulement en $400000).

Et $600010 n'existe pas sur HW1 ! Pas en lecture ! Sur HW1, le port $600010 réagit de la même manière que tout autre port inexistant.
Si tu veux, je peux (mais je ne perdrait pas mon temps à ça) t'écrire une routine pour que $600010 renvoie 0 sur HW1 (du moins sur la mienne)...

Si tant est que ta routine fonctionne pour les calcs existantes, elle ne peut pas avoir la prétention de fontionner sur les futurs HW. Et la V200 ? Elle est détectée comment avec ton code ???
Ta routine n'est tout simplement pas portable (tu le dis toi-même : "GX_DetectHardware est avantageuse tant que TI ne sort pas d'HW3, après on trouvera peut-être un autre moyen tout aussi efficace.") au niveau des sources, et encore moins au niveau du binaire.

pas de bol Thibaut

Franchement, pourquoi tant de haine

Sale ou pas, du moment que ca marche Et puis pour la HW3, c pas demain la veille qu'elle va sortir.

Il me semble que tu n'as rien compris du message de JM!!!

Désolé, je lisais les posts en diagonal

JM >> La lecture d'un port inexistant ne renvoie pas nécessairement 0 mais une valeur qui peut être aléatoire ou complexe.
On peut avoir une explication, les tests montrent (j'ai pas dit "prouvent") le contraire..................

>> Si tu veux, je peux (mais je ne perdrait pas mon temps à ça) t'écrire une routine pour que $600010 renvoie 0 sur HW1 (du moins sur la mienne)...
lol s'il faut une routine spécialement conçue pour que ça ne marche pas
Et si vraiment ce port n'est pas fiable, il y en a d'autres. Donc tout n'est pas perdu. Il y a par exemple sur HW2 un port indiquant le nombre de bits qui codent la valeur du contraste. Il n'existe pas sur HW1.

>> Ta routine n'est tout simplement pas portable (tu le dis toi-même
Argument plutôt ridicule, déjà réfuté à la page précédente.

Quelques précisions :
Toutes les calculatrices ont l'air de se comporter de la même manière pour les zones de mémoire non mappées (ex : $800000). db92 renvoie en général 61 00 : sur ma TI, d'autres valeurs apparaissent de temps en temps.
En fait, il semble que la valeur lue est la dernière qui est passée par le bus de donnée soit en général le contenu du cache d'instruction. Je n'explique pas les interférences que je rencontre dans db92 : peut-être l'écran qui accède à la mémoire, ce qui ne se produit pas sur HW2 et ça expliquerait pourquoi Kevin lit constamment $6100.
Il y aurait une autre différence entre les HW1 et HW2 : sur HW2, les ports inutilisés renvoient 0 sur HW2 renvoient 0 alors que sur HW1, le comportement est le même que pour les zones non mappées (sur ma TI, db92 lit en général $6100 en $600010).
Alors en admettant que toutes les HW1 sont comme la mienne, et que toutes les HW2 sont comme celle de Thibaut, un problème reste de taille : les interférences que je constate vont faire apparaître de temps en temps des 0 (à moins qu'en noirce/ssant le LCD ???) et une HW1 pourrait être détectée comme une HW2.

Bref, ça marche pas.

PS: j'ai pas encore lu ta réponse

Argument plutôt ridicule, déjà réfuté à la page précédente.
Je sais, mais quand je dis que les sources ne sont pas portables, c'est que la programmation ne consiste pas à optimiser au maximum au détriment de la maintenance. Si ça t'amuse de perdre autant de temps et de faire perdre celui de ceux qui vont maintenir tous les programmes qui dépendent de cette routine, et bien vas-y ! Pour quelques octets, je pense que tu seras le seul à utiliser cette routine SI elle marche.

JM a écrit :
Argument plutôt ridicule, déjà réfuté à la page précédente. Je sais, mais quand je dis que les sources ne sont pas portables, c'est que la programmation ne consiste pas à optimiser au maximum au détriment de la maintenance. Si ça t'amuse de perdre autant de temps et de faire perdre celui de ceux qui vont maintenir tous les programmes qui dépendent de cette routine, et bien vas-y ! Pour quelques octets, je pense que tu seras le seul à utiliser cette routine SI elle marche.

Entièrement d'accord. Y-en a marre des gens qui ne croient qu'en le "dieu vitesse" et/ou le "dieu taille"!

généralise pas Kevin, ca depend surtout de ce que tu fais .. pour les graphismes par exemple, c necessaire .. alors que là .. non, c'est pas le plus utile !

Je pense qu'il n'y a plus grand chose à dire...

Au lieu de chercher à optimiser avec des routines qui ne marchent pas toujours, documente les fonctions inconnues de TIGCC. On manque de monde pour faire ce boulot ! PpHd ne semble pas vouloir aider, même s'il a parfaitement les compétences pour le faire...

J'ai pas le temps de vous aider, je code GraphX et Einstein.

Après je vous aiderai si personne ne l'a encore fait.

thibaumt>ou pourrait-on obtenir des documentations please?

Malheureusement l'URL où j'avais eu ma doc est down http://alh.dhs.org/ti89/

>J'ai pas le temps de vous aider, je code GraphX et Einstein.
>Après je vous aiderai si personne ne l'a encore fait.

Je te prends au mot ?
Si tu ne te dépêches pas assez, il restera surtout des fonctions difficiles à documenter (genre toutes les fonctions de graphing)... Il faudrait que ceux qui documentent actuellement les fonctions inconnues soient bien bêtes pour choisir les fonctions les plus difficiles et les moins utiles...

Ben je te répondais. Maintenant il faudra voir si j'en suis capable.

Vous vous cassez le crâne sur des choses qui ne servent à rien vu que:

- Si cette routine s'éxecute seulement lorsque le prog démarre on s'en fout totalement du temps que ça prend. Vaut mieux aller chercher à optimiser ailleurs.
- Si vous utilisez la détection dans un endroit où elle se repète souvent, et vous y tenez tellement à sauver des cycles, alors il vaut mieux changer cela par du self-modifying code et détecter le hw une seule fois dans l'initialization.

> Si vous utilisez la détection dans un endroit où elle se repète souvent, et vous y tenez tellement à sauver des cycles, alors il vaut mieux changer cela par du self-modifying code et détecter le hw une seule fois dans l'initialisation.
Exactement. Si je ne me trompe, c'est ce que TIGCC fait avec CALCULATOR...

Thibaut: tu peux aussi faire de petites routines intéressantes. Par exemple, j'ai fait dernièrement des routines de sprintf pour des unsigned short et des unsigned long, en base 10 et en base 16, avec support d'un nombre minimal de digits (trailing zeros ou spaces le cas échéant). Le plus petit ratio temps AMS/temps de mes routines, sur la famille de routines, est voisin de 3; le plus grand est voisin de 13...
Ce n'est pas difficile...

thibaut : http://gdf68k.free.fr/doc/ la doc ki etait sur le site a ete recopiée ici par un gentil anoymme il y a kk tmps au cas ou le site ke tu mentionne serait down un jour :]

Kevin Kofler
a écrit : Entièrement d'accord. Y-en a marre des gens qui ne croient qu'en le "dieu vitesse" et/ou le "dieu taille"!

Je pense que c' est plutot bien les dieux vitesse et taille. Il suffit de garder un equivalent en C ou ASM non optimise commente ou dans un autre fichier, comme ca s' il y a des problemes on peut tj reemplacer par la version "stable". Surtout quand on est limites au niveau hardware (on peut pas acheter plus de RAM ou un 68k plus rapide pour notre precieuse TI)

Pendant qu'on y est, elle renvoie quoi ta routine de detection HW?

Merde t'as remonté ce topic honteux

Elle renvoie 2 sur HW2, et 1 sur... VTI.
Sur les HW1 réelles elle renvoie 2 car le port utilisé n'est pas accessible en lecture.

ben c bien alors thibaut, c pas pour detecter le hw, mais pour detecter VTI

Tu as raison !

Mon code de détection Hardware permettrait de détecter VTI :

GX_DetectVTI:  ; char GX_DetectVTI(void) // renvoie 1 si la calculatrice est une VRAIE HW1/HW2, ou 0 si c'est VTI
        tst.w       $600010
        sne         d0
        addq.b      #1,d0
        rts

Mais comme l'a déjà dit JM, le comportement du port sur un vrai matériel n'est pas garanti. Franchement, sa méthode de détection de VTI qui exploite un vrai bogue de VTI me semble plus sûre.

sa méthode de détection de VTI qui exploite un vrai bogue de VTI me semble plus sûre.
C'est d'autant plus sûr qu'il ne s'agit pas vraiment d'un bug. L'opposé BCD d'un nombre hexadécimal, moi je connais pas. Le comportement est tout simplement indéfini et je me base sur cette différence. Si par hasard, quelqu'un veut supprimer tous les bugs de VTI, il ne touchera pas à ça.