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

Toujours en potassant un peu ma documentation sur les ports de la TI, j'ai vu qu'un certain Monsieur $600010 était capable de renseigner de manière hyper-fiable sur la version Hardware d'une TI68k !

Ben oui : ce qui est bien sur nos TIs, c'est que l'accès à une adresse inexistante ne provoque pas d'erreur... du coup on choisit un port existant sur HW1 mais pas sur HW2, qui contient à coup sûr une valeur différente de zéro ce port n'existant pas sur HW2, sa lecture renverra toujours zéro !

On peut par exemple choisir celui dans lequel est inscrite l'adresse de la mémoire vidéo.
S'il est à zéro cela signifie qu'il a été modifié par un programme bogué, donc que l'utilisateur ne voit plus rien sur son écran (enfin il voit la table des vecteurs d'interruption et le sommet de la pile ) et donc n'a pas eu d'autre choix que de reseter sa calc car il ne voyait plus rien, donc la valeur de ce port est toujours différente de zéro...

Voici donc la fonction de détection hardware la plus rapide et la plus petite qui n'ait jamais existée :

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

Si vous n'êtes pas convaincu, testez : http://alineasofts.free.fr/extern/hwtest3instructions.zip

Pour information, la routine classique de détection est celle-ci :

GetHardModel:
; Code C original de Julien Muchembled
; Convertit en ASM par Kevin Kofler
 move.l  ($c8).w,d0
 and.l   #$600000,d0
 move.l  d0,a0
 moveq   #1,d0
 move.l  260(a0),a1
 add.l   #$10000,a0
 cmp.l   a0,a1
 bcc.s   GetHardModel_hw1
 cmp.w   #22,(a1)
 bls.s   GetHardModel_hw1
 move.l  22(a1),d0
GetHardModel_hw1:
 rts

Y'a quand même une petite différence de taille et de vitesse, quoi

Bon, ça casse un peux tout de dire ça:

Et pour la détection de la calc ??

C'est pas le sujet. Ouvres un topic pour ça si tu veux

Thibaut a écrit :
Pour information, la routine classique de détection est celle-ci :

GetHardModel:
; Code C original de Julien Muchembled
; Convertit en ASM par Kevin Kofler
 move.l  ($c8).w,d0
 and.l   #$600000,d0
 move.l  d0,a0
 moveq   #1,d0
 move.l  260(a0),a1
 add.l   #$10000,a0
 cmp.l   a0,a1
 bcc.s   GetHardModel_hw1
 cmp.w   #22,(a1)
 bls.s   GetHardModel_hw1
 move.l  22(a1),d0
GetHardModel_hw1:
 rts

Y'a quand même une petite différence de taille et de vitesse, quoi

Mais ma méthode est plus propre.

Lol j'attendais cette réflexion insencée de ta part ! je savais exactement ce que tu allais dire

J'attend tes arguments VALABLES...

Valables, n'oublie pas ! c'est à dire qu'ils doivent prouver que ça ne marche pas en condition normale et humaine d'utilisation, (calto saine, on peut lire l'écran).


C'est pas la peine de te prétendre pro de l'optimisation mémoire si tu refuses d'accepter ce genre d'optimisation à cause de raisons idiotes

Correctness over optimization...

Moi, je lis la valeur qui donne la version matérielle. Toi, tu fais un bidouillage.

Oué bon c'est bien ça tu refuses d'admettre les idées des autres.

Ma méthode marche parfaitement sur toutes les calc.

Donc elle est valable.

Et je te signale que rien ne garantit qu'un port non utilisé est nécessairement relié à la masse! S'ils ne le relient à rien dans la prochaine version matérielle, la valeur sera aléatoire, pas nulle, et ta détection ne marchera plus.

Kevin, relier un port à la masse ne veut rien dire. Et ce port n'existe pas sur HW2 (j'ai fait des tests avant de l'affirmer), donc il ne risque pas "d'être relié à la masse" si sa signifiait quelque chose.

Les 16 lignes du bus de données sont toujours à zéro lorsqu'aucun composant n'y dépose aucune donnée. Donc en lisant mon port inexistant sur HW2, je suis sûr de trouver zéro.

Désolé pour toi, la routine de JM semble bien dépassée

Mais je peux me tromper, si un génie du fonctionnement hardware passe ici et dit que le bus de données porte une valeur aléatoire lorsque tous les composants n'y sont pas connectés, alors je ma méthode n'est plus valable. Mais je vois mal d'où pourrait venir cette tension si aucun composant ne l'alimente... De toute façon mes tests sont formels : il est bien à zéro lorsque tous les puces sont en état de haute impédence.

Mais si un pro passe par là et me contredit, pas de pb...

Va voir à $800000 avec db92 alors...
Moi, j'ai 61 00 61 00 61 00 61 00 61 00 61 00 ... Pas 00 00 00 ...

Je te parles de $600010 !
Y'a un rapport avec $800000

$800000 est un exemple de port relié à rien du tout.

Là on parle du port $600010 qui n'existe pas sur HW2 donc qui renverra toujours 0.

Il me semble que ce port était intégré à la puce gérant le LCD sur HW1. Mais la puce n'est plus la même sur HW2. Donc le port ne doit plus exister, je ne voit pas l'intérêt qu'ils auraient eu à gaspiller du temps pour intégrer ce port sur la nouvelle puce si le reste de la puce ne peut pas s'en servir.

Il faudrait vérifier.

Kevin> $8xxxxx est une zone de mémoire non mappée, alors que $6xxxxx est de toutes façons mappée (ou sinon tous les progs actuels seraient incompatibles - j'adore ce smiley ), donc si $600010 n'est pas utilisée par le hard, sa lecture renverra toujours 0 et non pas une adresse aléatoire...

Après, est-ce que TI va utiliser $600010 pour autre chose dans un HW3? la probabilité d'avoir un HW3 est assez faible, et puis de toutes façons tous les progs en gray (en tout cas les _nostub ) seraient incompatibles si $600010 avait un autre effet, donc je suis pas sûr que ça soit si risqué que ça...

Aaahhhhhh

Peut-on espérer qu'avec les prochaines versions de TIGCC les programmes perdront quelques octets ?

...et de GTC

J'ai quand même un très légé doute sur ma méthode : pourquoi JM n'y a-t-il pas pensé ?

Pollux a écrit :
Après, est-ce que TI va utiliser $600010 pour autre chose dans un HW3? la probabilité d'avoir un HW3 est assez faible, et puis de toutes façons tous les progs en gray (en tout cas les _nostub ) seraient incompatibles si $600010 avait un autre effet, donc je suis pas sûr que ça soit si risqué que ça...

Faux. Pas avec la version la plus récente de gray.s. $600010 n'est pas utilisé du tout si on est sur HW2 ou supérieure.

Bon en tout cas, admet que GX_DetectHardware est avantageuse tant que TI ne sort pas d'HW3, après on trouvera peut-être un autre moyen tout aussi efficace.

Et puis encore faut-il que ce port serve à autre chose sur HW3... ça m'étonnerait beaucoup : sinon ils auraient déjà réutilisé ce port et tous les autres rendus inutiles sur HW2.

en tout cas les chances sont fortes de penser qu'il y aura une incompatibilité au niveau des grays, et faible au niveau de $600010

Allez hop Kevin y'a un patch à changer dans TIGCC

Non. Je n'aime pas les bidouillages.

Tu fais ce que tu veux dans GraphX, mais moi, je ne perdrai pas mon temps à changer TIGCC.

la différence est de 26 octets, c pas énorme énorme mais c qd même sympa

Schade für der _nostub

Thibaut>>

Pollux a écrit :
la différence est de 26 octets, c pas énorme énorme mais c qd même sympa

On n'est pas à 26 octets près dans un programme en C, et la routine est exécutée une seule fois. Et j'insiste sur le fait que la méthode propre est une meilleure idée. Aussi en pensant aux émulateurs...

Et puis demandez à Thomas Nussbaumer de changer ça, pas à moi. C'est lui l'auteur de gray.s.

1) CE N'EST PAS UNE METHODE SALE ! il n'y a aucune raison de dire qu'elle est sale ! en quoi c'est un bidouillage si on sait que la lecture d'un port inexistant renvoie toujours zéro ? Bon Dieu, admet !

2) la détection du HW n'est-elle pas également faite au début de chaque programme


Pollux : tu dois être meilleur en anglais que moi, tu ne voudrais pas rédiger un mail à TN ? en mettant bien sûr tous nos arguments, parceque je connais quelqu'un qui va s'empresser de contacter TN pour tenter d'imposer encore son point de vue...

Montre-nous le mail si tu le fais

Ha oui et puis demande-lui aussi d'ajouter notre routine dans la FAQ de TIGCC, à côté de celle de JM qui trône là depuis longtemps

Thibaut
a écrit : 1) CE N'EST PAS UNE METHODE SALE ! il n'y a aucune raison de dire qu'elle est sale ! en quoi c'est un bidouillage si on sait que la lecture d'un port inexistant renvoie toujours zéro ? Bon Dieu, admet !

Si, c'est sale! Il y a un champ pour la version matérielle dans le "hardware parameter block". C'est la seule manière valable de lire la version matérielle. Toutes les autres méthodes sont sales!

2) la détection du HW n'est-elle pas également faite au début de chaque programme

Non. Seulement dans gray.s. Tout le reste de TIGCC n'a pas besoin de connaître la version matérielle!