1

Bonjour
Je m'interresse à la manière dont les informations sont transmises sur le port mini USB, au niveau de la ti 89 titanium.
Quelqu'un pourrait il me guider ? que se passe t-il exactement quand la ti 89 ti est branchée sur un ordi par exemple ? Peut on créer un programme C qui s'adapterait à un protocol existant ?

2

Je m'interresse à la manière dont les informations sont transmises sur le port mini USB, au niveau de la ti 89 titanium.

La 89T s'expose comme un device USB en classe propriétaire, et TI-Connect utilise un protocole propriétaire pour communiquer avec. Ce protocole a été reverse-engineered en particulier par Romain Liévin (roms), documenté et implémenté dans les librairies utilisées par TILP (libticables, libticalcs).
que se passe t-il exactement quand la ti 89 ti est branchée sur un ordi par exemple ?

Le protocol normal de découverte USB smile
Peut on créer un programme C qui s'adapterait à un protocol existant ?

Plus ou moins: il faudrait que tu nous en dises davantage sur ce que tu veux faire smile
En effet, l'assez gros code de l'OS lié à l'USB n'est que partiellement documenté (par ExtendeD, qui lit toujours plus ou moins yAronet - il avait posté son travail dans un topic sur yAronet, mais je n'ai pas le lien sous la main), et que les ports hardware ne sont pas complètement documentés non plus (mais a priori, le contrôleur USB est assez flexible).
Tu trouveras le meilleur connaisseur des ports hardware USB sur IRC, le chan #ti sur EFNet (anglophone). C'est Brandon Wilson, qui a un analyseur USB et l'a utilisé il y a quelques mois pour faire une version 84+(SE) du jailbreak de la PS3, puis l'a porté sur 89T. Il a encore d'autres projets dans les cartons pour l'USB sur 84+ et 89T.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

3

slt,
Merci de la réponse, en gros il suffirait que je maitrise le protocole de transfert série pour pouvoir l'implémenter sur la 89ti. Une fois fait, je pourrais donner l'impression au pc que je suis un équipement branché sur le port série et donc pouvoir utiliser l'hyperterminal pour faire une petite communication entre la calc et l'hyperterminal. J'espère que j'ai pas une vision simpliste des choses...

4

Oui. Mais comme Brandon et moi te l'avons écrit sur #ti, "le protocole de transfert série" est en réalité le protocole d'un des chips série, type FTDI2232 ou CP2102, qui ont leur propre driver. Il faut que tu fasses en sorte que ta 89T se comporte comme l'un de ces chips.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

5

je vois. oui il ne me reste plus qu'à comprendre exactement le protocole de communication de l'un de ces chips et à l'émuler.

6

C'est pas la seule solution, et pas forcément la meilleure.

Si le débit de données est faible, le plus simple est probablement d'implémenter la classe USB HID, qui sert normalement pour les claviers/souris/manettes de jeu..., et qui est nativement supportée par Windows et Linux.

Si tu as besoin de plus, tu peux créer ton propre protocole (qui peut être minimaliste) et utiliser un driver générique, comme LibUSB (Linux, Windows) ou WinUSB (Windows XP SP2 et plus).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7

Tu as tout à fait raison smile
Mais d'après notre (BrandonW, godbod et moi) discussion sur IRC, il voudrait faire un protocole type production d'informations sur le port série, et ne veut pas coder côté ordinateur.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

8

Bah, s'il code pas côté PC, il devra coder davantage côté TI, ce qui n'est pas forcément plus simple tongue

D'ailleurs, les protocoles utilisés par les différents bridges USB-série sont documentés quelque part ? Par exemple, FTDI ne le fournit pas publiquement ; y'a un driver Linux public, donc on peut retrouver comment ça marche, mais est-ce qu'il y a un document récapitulatif ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

c'est la question à 100 000 $ Zerosquare, j'ai même contacter mon prof de VHDL pour savoir s'il en sait quelque chose... Merci à tous de montrer tant d'interessement à ce sujet chinois . En parallèle je cherche sur google, l'information qui me permettra de débuter.

10

Le driver Linux pour les puces FTDI a l'air assez bien commenté...
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

Merci ! donc pour bien fixer les choses, je travaillerais avec un driver VCP de FTDI, il répond bien à la problématique. le lien est la version 1.5.0 du driver en version 32 bits. sauf erreur. Pour l'hyperterminal, je travaillerais avec gtkterm ( gloire à Linux !) smile
Oui Zerosquare, très commenté le driver ! tant mieux...

12

C'est pas vraiment le driver le plus compliqué... prends le temps de lire ma réponse dans l'autre topic.

13

salut à tous, est ce que quelqu'un comprends exactement se qui se passe dans le code suivant ? :
unsigned char* FindTSR(unsigned char* signature) { unsigned char* end = HeapEnd(); while (end) { if (*end == ((MAGIC_TSR >> 24) & 0xff) && *(end+1) == ((MAGIC_TSR >> 16) & 0xff) && *(end+2) == ((MAGIC_TSR >> 8) & 0xff) && *(end+3) == ((MAGIC_TSR ) & 0xff) && !strncmp(end+4,signature,8)) { return end; } end-=2; } return NULL; }

je lis actuellement le cours sur les TSR à cette adresse : http://tigcc.ticalc.org/tut/tsrclock.html

Je vous remercie d'avance.

14

on scanne la mémoire à rebrousse poil pour trouver une séquence d'octets

cette séquence permet de trouver l'adresse d'un programme TSR.

on est obligé de faire ça car on ne connait pas à priori l'adresse de chargement du programme.

15

Ouah, ça scanne toute la RAM eek

Et quel est l'intérêt du and $FF ? C'est pas casté en char automatiquement ? *end est un char, non ?

De plus, end est initialisé à HeapEnd, donc end+x pointera à une adresse mappée on sait pas comment, il n'y a pas de risque de faux positif ?

16

oui mais le magic pourrait contenir des trucs négatifs pour un int

(le résultat intermédiaire MAGIC>>n subit une extension de signe
si magic est >=0x80000000, magic>>n sera négatif, il faut le &ff pour virer tous les bits inutiles au delà du 8e, dont celui de signe).

heap end doit être aligné sur 4, donc au max on pointera sur le dernier char du mot.

on ne fait le strncmp que si les 4 octets matchent, et comme ça arrivera probablement pas à la position heapend, on dépasse jamais.

17

Merci.
squalyl (./16) :
on ne fait le strncmp que si les 4 octets matchent, et comme ça arrivera probablement pas à la position heapend, on dépasse jamais.

C'est un coup de poker, risque minime, mais amha ça ne reste pas clean. Lire les adresses non mappées renvoie la dernière valeur passée par le bus de données apparemment : topics/16048-detecter-la-version-hw-dune-ti-en-3-instructions

18

Je me demande comment godbod a bien pu trouver un lien vers cette copie du tutorial TICT S1P3, qui est bien antérieur à la sortie de la 89T...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

19

Folco: c'est pas un coup de poker, c'est garanti.

cette signature MAGIC_TSR n'apparait qu'au *début* d'un TSR, il est forcément suivi par le nom du TSR puis par le code de ce TSR. on ne lira jamais d'addresses non mappées.

la doc TIGCC est pas claire sur HeapEnd. Je pense que c'est un pointeur les derniers octets valides de la mémoire, et pas vers le premier octet au delà de la mémoire. Et comme la heap fait tout aligné sur 4 octets...

Surtout ce qui manque c'est la valeur de HeapEnd. Je suis sûr que ce n'est pas la fin de la RAM.

Sinon on a un bug et il faudrait commencer à HeapEnd - 4:

01 unsigned char* FindTSR(unsigned char* signature) {
02	    unsigned char* end = (unsigned char*)HeapEnd() - 4; /*voire sizeof(uint32_t), mais bon, y'a déja des nombres en dur %) */
03	          
04	    while (end) {
05	        if (*end     == ((MAGIC_TSR >> 24) & 0xff) &&
06	            *(end+1) == ((MAGIC_TSR >> 16) & 0xff) &&
07	            *(end+2) == ((MAGIC_TSR >>  8) & 0xff) &&
08	            *(end+3) == ((MAGIC_TSR      ) & 0xff) &&
09	            !strncmp(end+4,signature,8))
10	        {
11	            return end;
12	        }    
13	        end-=2;
14	    }
15	      
16	    return NULL;
17	} 

et puis faut pas faire d'arithmétique void* embarrassed

Comment c'est implémenté dans PedroM?

20

Le heap est aligné sur deux octets, pas 4.
Et HeapEnd() renvoie le premier octet après la RAM (256*1024 dans PedroM, ça doit donc être identique sous AMS). Ca confirme ce que je pensais, end est utilisé ici typiquement comme une adresse alignée (sinon while(end) serait toujours vrai).

Donc en lisant à HeapEnd() + 1/2/3/4, on lit bien n'imorte où.

21

ah ouais. Bah c'est un bug.

Ca fait pas address error, j'ai déja utilisé cette fonction, donc ça doit lire des FF ou bien un ghost space si les lignes d'adresses sont pas toute décodées.

d'ailleurs pour pinailler encore plus pointutement, il faudrait initialiser end à HeapEnd() - 4 - 8, ça serait un chouia plus rapide trigic

22

Ah mais tout à fait grin

Par contre, je reviens sur le and $FF, j'ai pas très bien compris. Reprenons ton exemple :
MAGIC_TSR == $80000000
MAGIC_TSR >> 24 == $FFFFFF80

Mais end est un char*, donc *end est un char, donc MAGIC_TSR>>24 va être tronqué en $80 de toute façon, non ?

23

le résultat de MAGIC>>24 est un signed int. Donc pour lui c'est 0xFFFFFF80 ce qui fait un beau -128

end est un unsigned char * donc *end vaut 0x80, c'est à dire +128.

la conversion caste tout en int

(magic>>24) l'est déja -> -128
*end est un unsigned byte égal à 0x80=128, donc pas d'extension de signe, en int ça donne 0x00000080 = +128

C'est mort, ce sera jamais égal.

donc on prend (MAGIC>>24)&0xFF ce qui donne 0x00000080 == 0x80

CQFD grin

24

Rah je me ferai jamais à tous ces concepts fumeux, à cette conception de signé et de non signé qui vient prendre de la place sur mes précieux bits grin

En tout cas, merci pour l'explication en étape grin

25

je vois que ça a suscité des questions smile ...
Le HeapEnd( ) renvoi une adresse sur la fin de la RAM n'est ce pas ? En tout cas c'est bien ce que dit la doc http://tigcc.ticalc.org/doc/alloc.html#HeapEnd roll

Debroux, je m'en doutais même pas ... smile mais dis moi c'est un mauvais choix pour le tuto ?

Sinon le reste est clair, merci.

26

Le HeapEnd() renvoi une adresse sur la fin de la RAM n'est ce pas ?

Pas sous AMS.
En tout cas c'est bien ce que dit la doc

Non, ça n'est pas ça que dit la doc wink
La doc dit que ça retourne la fin du tas. Et sous AMS, la fin du tas n'est pas à la fin de la RAM, mais 12 octets avant (3FFF4)..
Debroux, je m'en doutais même pas ... smile mais dis moi c'est un mauvais choix pour le tuto ?

Vu que tu as une 89T, oui. Mais je me demande sur quel site tu as pu tomber pour être pointé vers S1P3 plutôt que vers SampleTSR (fais bien attention à utiliser la version compatible 89T) ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

27

Donc l'exemple donné est safe sous AMS, je m'en doutais, j'ai jamais eu de pb avec grin

et comme supposé ça dépend de la définition de HeapEnd() grin

ce genre de TSR a t il un sens sous PedroM?

28

Niarf... J'ai une culture encore trop pauvre en hardware ti... sad

29

ca viendra grin*
godbod (./26) :
Le HeapEnd( ) renvoi une adresse sur la fin de la RAM n'est ce pas ? En tout cas c'est bien ce que dit la doc http://tigcc.ticalc.org/doc/alloc.html#HeapEnd roll.gif
non c'est pas clair: end c'est quoi? un pointeur vers le dernier octet allouable ou vers le premier octet non allouable qui suit le dernier allouable?
HeapEnd = "fin de la heap" m'a fait douter.
les deux sont possibles, apparemment c'est la deuxième interprétation (et c'est la plus logique finalement) smile