Détermination de la version du matériel ? - Page 1

Je voudrais savoir comment est-ce qu'on peut détecter si la calculatrice est HW1 ou HW2 ? Je n'ai aucune idée de comment cela peut se faire.

Le bit de poids fort de ($70001D) change regulierement d'etat sur les HW2 mais reste figé sur les HW1.

regarde dans gray.s

GetHardware:
	move.l	$C8,d0
	andi.l	#$600000,d0
	move.l	d0,a0
	move.l	$104(a0),a0
	move.b	#1,Hardware
	sub.l	a0,d0
	cmpi.l	#-$10000,d0
	bls.s	__hardware
	cmpi.w	#$16,(a0)
	bls.s	__hardware

	;move.b	#2,Hardware
	addq.b	#1,Hardware
__hardware:
	rts

Voilà ce que j'utilise pour PolySnd.

Galmiza
: Le bit de poids fort de ($70001D) change regulierement d'etat sur les HW2 mais reste figé sur les HW1.

Méthode de détection totalement foireuse. On n'a pas le droit de lire ce bit sur HW1, il n'est connecté à rien de déterminé.

Voilà ce qui sera dans TIGCC 0.95:

#ifdef DOORS
#define _CALCULATOR _ram_call (0,const unsigned char*)
#define HW_VERSION ((unsigned short)(_CALCULATOR[1]))
#else /* !DOORS */
unsigned short __get_hw_version(void) __attribute__((const));
#define HW_VERSION (__get_hw_version())
#endif /* !DOORS */

avec:

| Hardware version detection, adapted from gray.s
| Copyright (C) 2002 Thomas Nussbaumer.
| Copyright (C) 2003 Kevin Kofler.
| See License.txt for licensing conditions.
 
	.xdef __get_hw_version
 
__get_hw_version:
    |--------------------------------------------------------------------------
    | get the HW parm block using the algorithm suggested by Julien Muchembled
    |--------------------------------------------------------------------------
	move.l   0xc8:w,%d0
	andi.l   #0x600000,%d0 | get the ROM base
	movea.l  %d0,%a0
	movea.l  260(%a0),%a1  | get pointer to the hardware param block
	adda.l   #0x10000,%a0
	cmpa.l   %a0,%a1       | check if the HW parameter block is near enough
	bcc.s    L.is_hw1      | if it is too far, it is HW1
	cmpi.w   #22,(%a1)     | check if the parameter block contains HW ver
	bls.s    L.is_hw1      | if it is too small, it is HW1
 
    |--------------------------------------------------------------------------
    | check for VTI (trick suggested by Julien Muchembled)
    |--------------------------------------------------------------------------
	trap     #12         | enter supervisor mode. returns old (%sr) in %d0.w
	move.w   #0x3000,%sr | set a non-existing flag in %sr (but keep s-flag)
	move.w   %sr,%d1     | get %sr content and check for non-existing flag
	move.w   %d0,%sr     | restore old %sr content
	btst.l   #12,%d1     | this non-existing flag can only be set on the VTI
	beq.s    L.not_vti   | flag not set -> no VTI
 
    |--------------------------------------------------------------------------
    | VTI detected -> treat as HW1
    |--------------------------------------------------------------------------
	| Fall through...
 
L.is_hw1:
    |--------------------------------------------------------------------------
    | HW1 detected
    |--------------------------------------------------------------------------
	moveq.l  #1,%d0      | set %d0 to 1 (HW1)
	rts                  | return 1
 
L.not_vti:
    |--------------------------------------------------------------------------
    | Real calculator detected, so read the HW version from the HW parm block
    |--------------------------------------------------------------------------
	move.l   22(%a1),%d0 | get the hardware version
	rts                  | return it

La licence est celle de TIGCCLIB.

PS: !"§%&/()=?, la balise pre continue à avaler les lignes vides! Il faut encore mettre des espaces pour les garder.

Y'a une autre methode purement hardware base sur le port 600000.
Mais je dois etre l'un des rares a la connaitre.

Vas-y, explique (que je vois si je ne la connaissais vraiment pas).

Merci tout le monde

Ben cherche. C'est pourtant pas tres complique.

Bon, je n'avance pas vraiment.
J'ai demandé à quelques personnes de m'aider, mais elles sont peu nombreuses, donc je ne sais pas si je peux me fier aux résultats pour l'instant.
Donc on a à l'adresse $600000, $04 pour les TI-89 HW2 et $2C pour les TI-89 HW1.
Pour l'instant, 2 TI-89 de chaque HW ont été testées seulement :/

Donc si vous pouvez apporter votre contribution ce serait sympa.
Il suffit de lire la valeur du port $600000 et de donner la valeur ici avec le modèle et la version du HW.
Merci.

En fait, je pense que tu devrais tester du côté du "battery checker" qui n'est présent que sur HW2.

Le bit 2 du port $600000 ?
Ou bien ceux que johan qualifie de battery checker au port $70001D ?

Ne touche pas aux ports pour la détection du matériel, ils ne sont pas prévus pour. La routine propre est celle que j'ai postée. Si tu te mets à traffiquer des ports pour détecter la version, tu risques d'avoir des ennuis si une HW3 sort. Avec ma routine, tu auras 3 en résultat.

Je ne vois aps trop ce que TI pourrait encore sortir. Les TI 68k sont quasiment au maximum de leurs possibilités et une nouvelle calculatrice impliquerait probablement un nouveau matériel différent voire incompatible avec celui des calculatrices actuelles, donc il n'y a pas vraiment de problème.

Si, il reste encore de la place pour 2 MO de FlashROM supplémentaire (pour en aboutir à 4 MO comme sur V200) dans l'espace d'adressage de la TI-89.

Et puis, ils peuvent faire des révisions du matériel sans sortir un nouveau modèle. La TI-89 HW2 en est un bon exemple.

Quelles révisions ? Quel intérêt ? Si ils font des révisions, soit c'est important donc ça apporte une incompatibilité, soit ça ne l'est pas et ça reste à peu près compatible, mais ça n'a aucun intérêt.

GoldenCrystal
: Quelles révisions ? Quel intérêt ?

Vendre du matériel moins cher pour le même prix.

Mais pour vendre moins cher -> révisions plus ou moins importantes donc incompatibilités obligatoires avec la majorité des programmes.

Kevin> Je ne les traffique pas, je les lis jute. Ça ne va pas ?
Et si tu détectes une HW3 avec ta fonction de détection, le programme continue quand même ?

Sasume
: Kevin> Je ne les traffique pas, je les lis jute. Ça ne va pas ?

C'est toujours du traffiquage.

Et si tu détectes une HW3 avec ta fonction de détection, le programme continue quand même ?

Au programme de décider comment il réagit. Ma fonction ne fait qu'implémenter HW_VERSION.
Personnellement, je conseille de tester HW_VERSION>=2 et de le traîter comme une HW2, c'est le mieux qu'on puisse faire.

Sasume> tu peux *peut-être* aussi essayer d'écrire 0xFF dans le port 0x600000:

$600000 RW ($00)
:7 Keep clear (=0)
:6 Keep clear (=0)
:5-3 -
:2 1: Battery voltage level is *above* the trig level.
(see $600018). :1-0 -

Je suis pas sûr d'avoir bien compris, mais on doit pouvoir mettre les bits 7-6 à 1 sur les HW1 (et ce n'est pas possible sur ma V200)

Ce sont des hacks à ne pas utiliser! (Cf. ./13)
Il y a une méthode officielle (passer par le "hardware parameter block" comme le fait mon code) qui marche très bien, je ne vois pas pourquoi vous perdez votre temps à chercher autre chose!

kevin a raison pas la peine de ce compliquer(a moins que tu veuiklle refaire une ROM :
- tu utilise le ramcall CALCULATOR en kernel
- tu utilise _get_hw_version en nostub

Kevin Kofler :
Ce sont des hacks à ne pas utiliser! (Cf. ./13)

OK, je ne savais pas...

Il y a une méthode officielle (passer par le "hardware parameter block" comme le fait mon code) qui marche très bien, je ne vois pas pourquoi vous perdez votre temps à chercher autre chose!

Parce que ça pourrait être plus petit !
T'es vraiment soûlant Kevin quand on essaie d'améliorer un truc qui existe déjà.

sur ce point la je le défends si tout le monde ce met a utiliser de salles hack ca va poser des problèmes si il y a un changement. Les hacks doivent etre évité lorseque c'est possible. Il vaut mieux les laisser au kernel ou a la limite dans des libs.

Uther
: kevin a raison pas la peine de ce compliquer(a moins que tu veuiklle refaire une ROM

Même pour refaire une ROM, mon code marche.

oui mais ce que sasume critiquait ce n'est pas à propos du hack. il ne savait apperement pas que c'était un hack et il l'a dit.

ce qu'il critique c'est le fait que Kevin s'oppose toujours à toute amélioration de ce qu'il a fait.
Sasume cherchait une possibilité d'améliorer ce code simplement, ce que Kevin ne semble pas apprécier vu sa réaction

Microbug
: ce qu'il critique c'est le fait que Kevin s'oppose toujours à toute amélioration de ce qu'il a fait.

Le fait que cette routine soit de moi (elle n'est d'ailleurs pas vraiment de moi, cf. les commentaires au début!) n'a absolument aucune importance. La méthode que j'utilise est connue depuis longtemps. (C'est JM qui l'a trouvée en premier.)

Je suis d'accord avec le résonnement de Kevin, en plus la routine ne prend pas beaucoup de place et n'est pas lente.
Je ne pense vbraiment pas que TI va sortir une version HW3 mais ce genre de hack avec le métériel peut donner des résultats inattendus...