Xpand : plus d'archives pour vos V200 - Page 6

geogeo :
Moi j'en ai 2 aussi, TI83+ et TI92+. La TI83+ je n'y touche plus.
Mais j'avoue que la TI92+ est mieux que la V200 même si elle est plus grosse et quelle a un look assez vieillo.

n'importe qoi, la v200 n'a que des avantages sur la 92+

Ça permet toujours que plus de personnes les lisent...

n'importe qoi, la v200 n'a que des avantages sur la 92+

son seul avantage objectif, c'est la mémoire supplémentaire (même sans xpand). Après, on peut trouver qu'elle est moins agréable à utiliser que la 92+ (c'est mon cas) à cause des touches mal placées

Elle a aussi l'avantage d'être plus compacte et plus légère.

Mmm, on dirait que le crash d'Xpand avec la barre noire provient plutôt d'une exécution en flash illégale. Pourtant il n'y a aucune raison qu'un mauvais masque de protection soit appliqué...

ExtendeD
: Mmm, on dirait que le crash d'Xpand avec la barre noire provient plutôt d'une exécution en flash illégale.

C'est ce que j'ai dit dès le départ.

Pourtant il n'y a aucune raison qu'un mauvais masque de protection soit appliqué...

Si tu ne l'as pas déjà fait, essaye de rentrer dans la routine avec laquelle AMS calcule le masque avec VTI ("Set PC to selection"), de rentrer la valeur pour l'adresse limite dans le registre où elle l'attend et de faire un step-by-step du calcul du masque. Ça devrait permettre de voir ce qui cloche si c'est bien un problème logiciel.

Mais il se peut aussi que ce soit une limitation du matériel.

n'importe qoi, la v200 n'a que des avantages sur la 92+

perso, à part la mémoire en plus, je ne trouve aucun avantage à la V200 par rapport à la 92+...

Kevin Kofler
: Elle a aussi l'avantage d'être plus compacte et plus légère.

Si tu ne l'as pas déjà fait, essaye de rentrer dans la routine avec laquelle AMS calcule le masque avec VTI ("Set PC to selection"), de rentrer la valeur pour l'adresse limite dans le registre où elle l'attend et de faire un step-by-step du calcul du masque. Ça devrait permettre de voir ce qui cloche si c'est bien un problème logiciel.
Mais il se peut aussi que ce soit une limitation du matériel.

La routine du calcul du masque utilise la routine patchée pour son calcul, il ne devrait pas y avoir de problème.

En fait une vraie émulation par VTI de la mémoire de la V200 avec réception de flash apps permettrait de trouver le problème en quelques minutes...

./158> justement, le "pus compacte", ça me gène : je trouve les touches trop petites
(et la détente au pouce me manque)

elle est plus compacte et plus légère, c'est un fait, mais je sais pas si c'est un avantage (idem pour les piles, j'ai l'impression de changer les piles de ma v200 plus souvent que celles de ma 92+, alors que je m'en sers moins)

elle est plus compacte et plus légère, c'est un fait, mais je sais pas si c'est un avantage

voila quelqu'un qui pense comme moi
et puis, le look dinosaure de ma 92, il est pas mal

Ca y'est, je crois que j'ai enfin trouvé le problème d'Xpand

et plus encore...

ExtendeD :
Ca y'est, je crois que j'ai enfin trouvé le problème d'Xpand

C' était quoi ?

ça y est, j'ai acheté des piles ! si t'as encore bvesoin d'un testeur, je veux bien essayer

Non, finalement ce que je croyais avoir trouvé ne va pas.
J'ai passé sous VTI toutes les routines exécutées dans la zone possible du crash (entre le message 'link transmission complete' à la réception de l'app et l'effacement du message).
Le seul truc qui ne pourrait ne pas aller est un fonctionnement tordu du port $700012 d'exécution en flash (la calc crasherait à l'envoi du message CM_INSTALL à l'app installée [ou OO_APP_NOTICE_INSTALL aux autres ?] par la ROM Call 0x428 que j'avais appellée SendInstallMsgs() dans Flash Apps Hider).

Pour vous montrer le comportement complètement bizarre du crash, voilà un des mails du testeur de crash (Matt Smith) que j'avais reçu en Janvier (listapps() retourne les adresses des apps en flash) :

After first sending just the 4 apps, here are the results of the listapps() program:

Calculus Tools: 34A946
CellSheet: 35821E
Finance: 340068
Stats/List Editor: 374B4E

Just to verify that this is the limit, I then sent Sketchpad to the calculator. I got the “Link Transfer Complete” message and a freeze, but no black bar this time. So, I did the usual remove a battery and reset routine. Then I sent Sketchpad first, followed by the other 4 apps in size order from smallest to largest. Here’s what listapps() said this time:

Calculus Tools: 3A42B0
CellSheet: 3B1B88
Finance: 3999D2
Stats/List Editor: 3CE4B8
The Geometer’s Sketchpad: 34006A

At this point I had 900155 bytes of Apps. I tried to send the Polynomial Root Finder, which is only 49KB, and I got the black bar with the “Link Transfer Complete” message at the bottom of the screen. Anyways, I hope this info will be helpful in correcting the problem, and as always, just let me know if you need more testing.

-Matt

PS: Just before I was going to send this email, I found out something rather interesting. I was able to send 987449 bytes of Apps. What I did was send Sketchpad first, then the Spanish Localization, then Finance, then the Polynomial Root Finder, then Calculus Tools, then CellSheet, then Stats/LE. It’s the same idea of transferring the largest app first, then transferring all the others in size order from smallest to largest. I have no idea why this worked. Here is the listapps() info though:

Calculus Tools: 34A946
CellSheet: 35821E
Espanol: 3999CE
Finance: 3A2A74
Polynomial Root Finder: 3AD34C
Stats/List Editor: 3E39B8
The Geometer’s Sketchpad: 34006A


Just to do more testing, I deleted all the apps again, then sent Cabri Geometry (427KB). Afterwards, I tried to send Sketchpad, but I got the same error (message and black bar). So, I pulled a battery and reset. I sent Cabri again, but testing my theory about sending the largest app first, then all others in ascending size order, I decided to try to send ALL the apps I have. So, after Cabri, I sent Spanish Localization, then Finance, then Study Cards, then Polynomial Root Finder, then Calculus Tools, then the Simultaneous Equation Solver, then CellSheet, then Symbolic Math Guide. However, it crashed after that last one. I didn’t get to check the App size on-calc, but without the Math Guide, it should have been 872931 bytes. The Guide would have put it at 1087820 bytes, so maybe this is closer to where Xpand’s limit really is, since earlier I got 987449 bytes of Apps on there. The weird thing is, it seems that you have to send the largest app first, then the others in size order (smallest to largest). And, since it crashed when receiving the Math Guide, I didn’t have a chance to run listapps() that time. So what I’m going to do for now is just send Sketchpad, then Spanish, Finance, CalcTools, CellSheet, and Stats/LE.

This is certainly interesting, hopefully it will help you pinpoint the problem too.

Arg.
Je pensais qu'un bit de $700012 ne fonctionnait pas, mais ce n'est pas ça, ça doit être plus compliqué.

Pas forcément. Il faut tenir à l'esprit que la routine d'initialisation se trouve généralement vers le début de l'application. Donc ce qui compte plus que la taille de toutes les applications est la taille de toutes les applications sauf la dernière.

Tu remarqueras aussi que dans tous ces dumps, les applications se trouvent en 0x3xxxxx. Aucune ne se trouve en 0x4xxxxx. Apparemment, dès qu'on essaye d'envoyer une en 0x4xxxxx, ça plante.

On dirait que la puce ne gère pas les limites entre 0x400000 et 0x500000, et que c'est ça qui a amené TI à limiter l'archive à 1 MO. Essaye de rajouter du code (en patchant la routine d'AMS) pour forcer la limite à 0x500000 si la valeur calculée se trouve entre 0x400000 et 0x500000.

Ca m'a l'air franchement d'un crade en mémoire les app flash.

On dirait que la puce ne gère pas les limites entre 0x400000 et 0x500000, et que c'est ça qui a amené TI à limiter l'archive à 1 MO. Essaye de rajouter du code (en patchant la routine d'AMS) pour forcer la limite à 0x500000 si la valeur calculée se trouve entre 0x400000 et 0x500000.

Pourquoi TI aurait voulu limiter l'archive à 1 Mo, autant produire des puces de plus faible taille et gagner de l'argent dessus tout en faisant une pub mensongère? Il y a bien une raison?

Ils ont limité l'archive parce qu'ils n'ont pas été fichus faire une puce de protection anti-exécution qui fonctionne (cf. ce que tu viens ce citer) et qu'ils veulent à tout prix interdire l'exécution en archive. Et la mémoire n'est pas vraiment gaspillée de leur point de vue parce qu'on peut y mettre des applications Flash.

>Tu remarqueras aussi que dans tous ces dumps, les applications se trouvent en 0x3xxxxx. Aucune ne se trouve en 0x4xxxxx. Apparemment, dès qu'on essaye d'envoyer une en 0x4xxxxx, ça plante.

Mais certaines Apps ont quand même du code en $4xxxxx sans crasher (la fin de la dernière app du troisième test arrive à $431139). Mais ça pourrait être des données ou du code encore non exécuté, donc ton truc se tient.


>Essaye de rajouter du code (en patchant la routine d'AMS) pour forcer la limite à 0x500000 si la valeur calculée se trouve entre 0x400000 et 0x500000.
Ca ça demande de la déprotection en artillerie lourde, je ne veux pas faire ça pour Xpand. Je vais cherché un petit patch qui vire simplement toute la protection d'exécution.

>On dirait que la puce ne gère pas les limites entre 0x400000 et 0x500000, et que c'est ça qui a amené TI à limiter l'archive à 1 MO.
Il n'y a pas de raison que la puce soit différente de celle de la 92+ (qui serait capable sur 92+ de protéger l'espace fantôme $210000-$3FFFFF en exécution comme l'espace non fantôme de la V200, mais je n'ai jamais testé). Donc le bug pourrait aussi exister sur 92+. Ca me permettrait de vérifier la zone exacte sur ma calc, je teste ça demain.

ExtendeD :
>Tu remarqueras aussi que dans tous ces dumps, les applications se trouvent en 0x3xxxxx. Aucune ne se trouve en 0x4xxxxx. Apparemment, dès qu'on essaye d'envoyer une en 0x4xxxxx, ça plante.
Mais certaines Apps ont quand même du code en $4xxxxx sans crasher (la fin de la dernière app du troisième test arrive à $431139). Mais ça pourrait être des données ou du code encore non exécuté, donc ton truc se tient.

Comme déjà dit, "Il faut tenir à l'esprit que la routine d'initialisation se trouve généralement vers le début de l'application.".

>Essaye de rajouter du code (en patchant la routine d'AMS) pour forcer la limite à 0x500000 si la valeur calculée se trouve entre 0x400000 et 0x500000. Ca ça demande de la déprotection en artillerie lourde, je ne veux pas faire ça pour Xpand. Je vais cherché un petit patch qui vire simplement toute la protection d'exécution.

Dans le padding à la fin du secteur 0x21xxxx, tous les bits sont à 1, donc on peut y rajouter du code quelconque sans avoir à effacer un secteur. Ne reste plus qu'à trouver un moyen d'y sauter à partir d'un endroit quelconque de la routine de déprotection sans avoir à passer un bit de 0 à 1. (Je ne sais pas si c'est possible, mais il faut regarder tout ce qu'il y a.)

Ca demande quand même de la vraie déprotection et des routines d'écriture en flash, je préfère éviter.

Je viens de faire quelques tests sur 92+ : $700012 protège bien aussi le ghost space comme je le pensais. Donc la puce ourrait être exactement la même sur V200. Mais je n'ai pas trouvé de trace du bug entre $400000 et $500000.

Es-tu absolument sûr que le calcul du masque fait par la routine de TI est correct pour la rangée 0x400000-0x4fffff?

Il n'y a pas de raison que ça marche moins bien qu'ailleurs :
((fin flash apps + 0x10000) & 0xFFFF0000) + 0x10000
swap
- 0x21
-> 0x700012

Voilà, j'ai finalement trouvé un patch qui convient

A quand la diffusion ?