Titarom: la Titanium sur VTI ! - Page 1

Je me rend compte que de plus en plus de développeurs reçoivent des bugs reports concernant leurs programmes lorsqu'ils sont exécutés sur TI-89 Titanium, et l'absence d'émulation pose pas mal de problèmes.

Plutôt que ceux possédant la version privée du package aient à effectuer les tests pour d'autres, j'ai décidé de rendre publique sa distribution. La seule contrainte par rapport à cette nouvelle version est qu'elle comporte un programme de patch d'AMS 3.00, plutôt qu'un image de la ROM prépatchée.
Vous devez donc trouver un OS Update de l'AMS 3.00 vous même pour pouvoir utiliser Titarom. Pas la peine de me mailer/mm pour en obtenir, ni pour avoir la version prépatchée, il y a suffisament de Titanium qui circulent pour mettre la main sur un Update (il se trouve sur le CD livré avec). Et ce n'est pas une bonne idée de rendre trop publique la distribution d'une Update, TI fait plutôt attention à ça.

Les ROM dumps ne peuvent pas être patchés, donc pas d'émulation du boot pour cette version.
Techniquement la plus grande partie des patches appliqués ont pour but de déplacer ROM_base de 0x800000 à 0x200000 (VTI pensera l'émuler comme un TI-89 standard). Atttention, un programme tournant correctement en émulation ne veut pas dire qu'il tournera sur HW réel (par exemple le ghost space à 0x40000 existe toujours sous VTI).
Et les patches étant presque au nombre de 44000 et étant souvent approximatifs, certains sont manquants ou mauvais : l'AMS crash à plusieurs endroits. Pas la peine d'essayer d'éxecuter du TI-Basic par exemple (et il n'est pas nécessaire de me reporter tous ces problèmes).

N'essayez pas d'envoyer un AMS 3.00 patché à votre TI-89 standard : il n'est pas du tout prévu pour tourner dessus (notamment sur HW1), et pourrait facilement la rendre définitivement inutilisable (même si le boot sur calc réelle a été protégé).

Le package contient de plus un document contenant plusieurs informations à propos de l'AMS 3.00 et de l'HW3. Il n'est pas très bien organisé et est plus ou moins complet (il n'était pas destiné à être distribué à l'origine), mais contient plusieurs choses intéressantes.



http://www.ifrance.com/ti68k/Titarom.zip

ifrance, ça suxx.

pas encore essayé, mais
excellente idée que de diffuser ceci (me rappelle le boulot que tu avais déjà fait pour la 2.07 )

naPO: En même temps pour héberger une 20aine de fichiers binaires de qq ko chacun... C'est d/lable, c'est l'essentiel

./4> d'ailleurs, tu pourrais pas faire une liste des trucs qui y sont ?

Je sais plus trop.

Je viens de jeter un coup d'oeil, rien de très intéressant.

arf, ok

tu as modifié la doc ou pas depuis la version précédente ?

Quelques détails je crois. Fait un coup de diff (ou je peux le poster).

nan, c'est bon, je regarderais ça tout seul, merci

Ca me rassure que beaucoup de gens s'y mette pour devellopper une meilleur compatibilité pour la Titanium si rapidement
Au depart en achetant celle nouvelle calculatrice je pensais avoir a fait un mauvais choix
j'avais testé des programmes et jeux qui, la plupart faisait planter l'appareil et je pensais qu'il aurait fallu plusieurs mois pour develloper de nouveau programme qui marcherais sur cette becane
et ensuite g trouver GhostBuster en cherchant un peu, ca rendait deja pas mal de programmes compatible
Et la je vois qu'il y a de plus en plus de programmes qui deviennent compatible avec la TI89T
C'est vraiment cool que ca avance aussi rapidement

je trouve surper que des gens se donnent autant pour que tout le monde puissent exploiter au maximun ces TI
C'est super ce que vous faites, continuez comme ca

bon v alller tester Titarom voyons ce qu'il a dans le ventre

ExtendeD > il faudrait modifier HeapDeref (remettre l'adressage en abs.w) pour que 'set program entry breakpoint' fonctionne


Sinon on peut trouver AMS3.00 avec ti-connect 1.5

Mais du coup, on ne teste plus vraiment la compatibilité AMS 3!
Mets plutôt un breakpoint sur 0x28CA58.

hwti :
Sinon on peut trouver AMS3.00 avec ti-connect 1.5

En standalone aussi maintenant.

ça fait longtemps qu'elle est téléchargeable, bien avant la versoin 1.5

J'ai lu ta doc , et particulièrement:

Autres ports
============

$71004D
-------

USB: Searching for device... pour envoi à partir du var-link à 34A1A8
La plupart des ROM Calls semblent fonctionner avec les anciens ports
i/o à $6000xx (LinkTxQueueActive, OSLinkReset, OSLinkClose, ...)
Regarder toutes les RC de link.h. (utilisation en même temps que
5B35:1). Par exemple 349E58, 34A284, 34B868, et encore quelques
routines après ces adresses (search).
et trap #4 : 347664, 347160
Envoi des données par bloc ? (il y a des memcpy dans trap #11 : $15)

J'ai une maigre contribution à apporter:

L'usb transfère ses données par paquets, qui arrivent dans les appareils sur ce que l'on appelle des endpoints, et à chaque endpoint est associé un buffer qui est chargé par un transfert DMA, puis il y a déclenchement d'une interruption (ici l'AI3) pour signaler la réception d'un paquet.

Le code applicatif va ensuite lire les infos dans les buffers de réception, puis il est classique qu'il copie les descripteurs demandés par l'hôte dans les buffers de sortie avant d'appeler la routine d'envoi, d'où la présence d'appels à memcpy).

Voici un exemple de descripteur HID pour une souris qui justifie un memcpy:

const char ReportDescriptor1 [] =      {0x05, 0x01,	/* usage page */
					0x09, 0x02,	/* usage mouse */
					0xa1, 0x01,	/* collection (application) */
					0x09, 0x01,	/* usage (pointer) */
					0xa1, 0x00,	/* collection (linker) */
					0x05, 0x09,	/* usage page (buttons) */
					0x19, 0x01,	/* usage minimum (1) */
					0x29, 0x03,	/* usage maximum (3) */
					0x15, 0x00,	/* logical minimum (0) */
					0x25, 0x01,	/* logical maximum (0) */
					0x95, 0x03,	/* report count (3 bytes) */
					0x75, 0x01,	/* report size (1 bit) */
					0x81, 0x02, 	/* input (3 bits) */
					0x95, 0x01,	/* report count (1 byte) */
					0x75, 0x05,	/* Report size (5 bits) */
					0x81, 0x01, 	/* input (constant 5 bit padding) */
					0x05, 0x01,	/* usage page (generic desktop) */
					0x09, 0x30,	/* usage X */
					0x09, 0x31,	/* usage Y */
					0x15, 0x81,	/* logical minimum -127 */
					0x25, 0x7F,	/* logical maximum 127 */
					0x75, 0x08,	/* report size (8) */
					0x95, 0x03,	/* report count 2 */
					0x81, 0x06,	/* input (2 position butes X & Y) */
					0xc0, 0xc0};	/* end collection */

A ce propos je me permets de vous signaler un document pouvant vous intéresser à propos du fonctionnement de l'usb:
Il s'agit de la documentation associée au microcontrôleur PIC 16C765 de Microchip, qui contient un périphérique USB.
Déja, le datasheet explique en détail le fonctionnement des endpoints et compagnie:

Présentation du produit
Datasheet du contrôleur

L'intérêt est que Microchip fournit un exemple de firmware en C implémentant les fonctions d'une souris HID. Vous verrez par l'exemple que de nombreux port IO sont nécessaires pour paramétrer tous les endpoints (taille de buffer, adresse etc) mais aussi pour configurer l'hôte (état contrôleur, interruptions, etc...) [chapitre 10, page 57]
Le lien direct vers le zip en C est ici (la version ASM ne vous apportera certainement pas grand chose, le PIC est un processeur RISC)

Ma contribution consiste donc
-d'une part à confirmer que le transfert de données avec l'usb se fait sous forme de blocs
-d'autre part à vous donner un exemple d' IRQ de traitement de paquets USB pour que cela vous donne des idées quand vous verrez des trucs similaires dans le code d'ams. Je pense particulièrement aux constantes de USB_defs.H qui définissent par exemple les types de paquets: vous retrouverez certainement les mêmes valeurs immédiates dans l'autoint qui gère l'usb.

En espérant vous aider.