hw - Page 3

arf, c pas kevin ki a apporté la preuve, il a juste donné l'explication
boon, ba puisque ça bugge plus, et que t'as édité ton post, ba je v éditer les miens aussi, comme ça y aura ke des posts vides dans la page, cool ça

Vire ta signature de merde connard

J'ai corrigé la routine:

;detect the hardware version
;Thanks to Julien Muchembled for the C version listed in the TI-GCC FAQ.
;Converted to assembly by Kevin Kofler
GetHardModel:
 move.l ($c8).w,d0
 andi.l #$600000,d0 ;get the ROM base
 movea.l d0,a0
 moveq.l #1,d0
 movea.l 260(a0),a1 ;get the pointer to the hardware parameter block
 adda.l #$10000,a0
 cmpa.l a0,a1 ;check if the hardware parameter block is near enough
 bcc.s hw1 ;if it is too far, it is HW1
 cmpi.w #22,(a1) ;check if the parameter block contains the hardware version
 bls.s hw1 ;if it is too small, it is HW1
 move.l 22(a1),d0 ;check the hardware version
hw1:
 rts
;end of hardware version detection routine

pour qu'elle puisse retourner autre chose que 1 ou 2, en vue de cela. (C'est aussi plus court. J'aurais dû mettre ça tout de suite.)
[edit]Edité par Kevin Kofler le 05-01-2002 à 22:13:23[/edit]

Il manque le label hw1 !
Sinon, ben merci t'es vraiment cool
[edit]Edité par Thibaut le 05-01-2002 à 22:27:49[/edit]

J'ai mis le label maintenant.

Et je pense que tu devras encore changer ta détection TI-89/TI-92+... La Voyage 200 aura 4 MO de ROM, présumablement (je ne vois pas comment ils feraient autrement) de $200000 à $5fffff, donc ça commence à $200000 et ça marquera TI-89. (Plein d'autres programmes auront le même problème, rassure-toi.)

On doit pouvoir se débrouiller pour la détection de modèle. Je vais réfléchir (arf je sais pas si c'est la peine tu vas trouver avant moi )

On peut utiliser les informations du "hardware parameter bloc". On doit pouvoir faire comme dans mon GetHardModel. Mais je ne sais pas s'il vaut le coup de travailler là-dessus tant qu'on ne sais pas du tout ce qu'il y aura là-dedans dans la Voyage 200...

Au fait, dans la bibliothèque, je retire tous les commentaires du code des fonctions (le fichier de sortie est limité à 64ko, faut éviter le gaspillage ). Il ne reste que l'en-tête pour dire que c'est de toi et JM, traduite en français d'ailleurs

tibo>pourquoi tant de haine et de violence?

vira TA signature de merde connard et je vire la mienne

Au fait, je me suis rappelé d'avoir lu ça dans la documentation de TIGCC:

ScrRect may be used also to determine a calculator type. If
ScrRect->xy.x1 == 159
then the calculator is TI-89, else it is TI-92 Plus.

Donc à priori, voilà une fonction qui devrait fonctionner sur V200:

GetCalcModel:
 btst.b #6,$C9
 bne.s ti92p
 move.l ($c8).w,a0
 move.l $2f*4(a0),a0
 cmpi.b #159,3(a0)
 bne.s v200
 moveq.l #89,d0
 rts
v200:
 moveq.l #100,d0
 add.b d0,d0
 rts
ti92p:
 moveq.l #92,d0
 rts

ca sent le cho autour d'alizé ici ..
:]

clair

Kevin : Tu m'autorises à l'intégrer dans system.azr ?

Oui.
D'ailleurs, pour les routines de quelques lignes, je ne vois pas vraiment d'intérêt de mettre des licenses et des restrictions dessus. Mais c'est toujours bien de demander.

Ok merci

A force je me demande même si j'aurai écrit la bibliothèque Azur pour quelque chose, vu qu'au final elle sera identique à celle de TIGCC qui pourraient être exportée pour AS (si Nitro code sont convertisseur COFF->ASobjectFiles)

>si Nitro code son convertisseur COFF->ASobjectFiles

Ouais, c'est vrai que tout se rejoindrait...
Mais c'est pas pour demain

Pourquoi pas le format des libs dynamiques ?