cherche beta testeurs pour shell - Page 10

arg ! je viens de m'apercevoir d'un bug méchant sur V200
il faut que PreOS ait été installé pour pouvoir installer CS comme appli flash (sinon on a un plantage du style protection anti-exécution)
le truc bizarre, c'est que PreOS peut très bien avoir été désinstallé du moment que la calc n'a pas été éteinte. Il faut juste qu'il ait été installé avant la première exécution.
En revanche, CS peut continuer à se lancer en archive depuis cslaunch (sans passer par l'appli flash) sans aucun souci. D'où peut bien venir ce bug ? de la RAM ?

c'est bien ce que je pensais, il faut h220xtsr pourtant je ne suis à aucun moment dans le ghost et j'utilise très peu la RAM (pas plus q'une vraie app flash)

je pense tester les configs de lancement suivantes
* shift - on
* ACB depuis le desktop
* ACB depuis le menu APPS
* depuis le Homehw2patch
* avec cslaunch
* avec ttstart
* avec sstart
* depuis un programme basic
* depuis un shell (reste à savoir lequel ^^)
le tout avec les "patchs"suivants :
* rien
* h220xtsr
* hw2patch
* PreOS h220xtsr
* PreOS hw2patch
et sur V200 et 92+
soit pas loin d'une centaine de tests
est-ce que j'ai oublié qqc dans le lot ?

Flanker :
arg ! je viens de m'apercevoir d'un bug méchant sur V200
il faut que PreOS ait été installé pour pouvoir installer CS comme appli flash (sinon on a un plantage du style protection anti-exécution)

Même problème sur ma TI 92+ ams 2.08

Sinon très bien se shell, faudrait ajouter un tsr qui le lance quand on fait [2nd][-] (pour remplacer le var-link koi )

je m'en suis jamais rendu compte car ma 92+ est hw2patchée. Je vais voir si je peux faire qqc d'autre qu'imposer la présence d'un patch. Pour le TSR, il n'y a aucun pb pour faire ça Je pourrais même le rajouter comme fonction de CSlaunch

quelle idée de se servir du var-link ...

jusqu'a présent le var-link était encore (à mon avis) le meilleur shell, mais le tien en reprend toutes les possibilitées et en ajoute de nouvelles, tout en gardant autant que possible les même combinaisons de touches, c'est surtout ça qui est bien

Autre chose (je ne sais pas si c'est un bogue déjà connu): Si dans le var-link on fait un [F6] sur la fausse flash-app crées par cslaunch("acb") la calculatrice plante.

c'est gentil, ça
pour le bug F6, c'est bizarre, ça marche très bien sur ma 92+ et sur ma v200
va falloir que je réfléchisse à ça en détail

bon, un bug de résolu. Même s'il n'y a aucun patch, ça marche désormais sans problème en application flash
c'est chiant toutes ces protections. C'est vraiment dommage qu'hw2patch ne soit plus mis à jour

Bon le bogue du F ne re produit plus et je me souvines plus trop bien comment il s'était produit

Une autre améioratio qui serait cool, se serais la sauvegarde du mode de visualisation (arborescnece ou icone)

si tu n'archives pas csdata, c'est le déjà cas
le mieux, c'est de choisir toutes ses préférences, de quitter cs pour les enregistrer dans CSdata et de l'archiver ensuite pour les conserver après un plantage

J'ai eu un gros bug sur ti89.
J'ai compressé un fichier avec pepzip et jusque là pas de problème.
Mais après j'ai fait enter sur le fichier compressé et c'est la catastrophe.
Il m'a fait une erreur mais je sais pas laquelle.
Je suis retourné dans le home de la ti (j'ai quitté cs), et en allant d'en le var-link et j'ai eu le droit à une erreur memory suivit de 2 ou3 autres erreurs.
Je suis retourné dans le var-link et mon fichier ne faisait que 2 octets et ca faisait planter la calc, et impossible de le supprimer.
Alors je reset ma calc et quand je relance cs, mon fichier fait 39 octets au lieu de 24 ko.
Je quitte cs et le var-link me dit qu'il fait deux octets et alors je retourne dans cs qui me dit qu'il fait 3 octets .
Je ne sais pas si ca vient de cs ou pepzip mais c'est spécial.
J'ai quand même réussi à virer le fichier en le déverrouillant et le désarchivant avec cs, ouf...

tu pourrais m'envoyer le fichier et ta version de pepzip ?

J'ai pepzip version 1.11 et cs 1.00b1.8 (d'ailleur il faudrait changer le "a propos" dans cs)
J'ai réussi à retrouver mon fichier en le resortant de la poubelle et il etait compressé normalement et je l'ai décompressé normalement.
Désolé, mais je préfère ne pas te l'envoyer.

comme tu veux.
Pour le "à propos", je vais le faire maintenant

y avait juste la date à changer, et la version de TIGCC à changer (0.95b6 -> 0.94SP4). Je vais peut-être pas faire un upload pour ça

Flanker
: y avait juste la date à changer, et la version de TIGCC à changer (0.95b6 -> 0.94SP4).

Au lieu de rétrograder TIGCC, reporte-moi le bogue! Dis-moi la source qui bogue, je déboguerai ça! Tu dis que la version actuelle de CS ne compile pas? As-tu mis le switch -d de A68k? Si oui, je vais voir ce qui se passe. Et tu peux aussi désactiver les optimisations du linker si le problème vient de là.

J'ai pas dit que la version actuelle de CS ne compile pas. C'est la version de cslaunch qui compile très bien mais qui plante à l'exécution malgré le switch -d !

C'est ce que je voulais dire par "ne compile pas", désolé pour l'imprécision. Je vais regarder les dumps du linker.

Mais il me faut les sources pour ça. Donc si tu pouvais me mailer les sources de cslaunch s'il te plaît.
(Au passage, j'en ai marre de devoir te demander et redemander ça. Je t'ai déjà demandé les sources avec lesquelles il y a un problème au moins 5 fois. Mais tu préfères râler dans tous les sens sans me donner le moyen de résoudre ton problème. J'en ai marre des utilisateurs non-coopératifs qui ne font que critiquer! )

Je t'ai déjà demandé les sources avec lesquelles il y a un problème au moins 5 fois. Mais tu préfères râler dans tous les sens sans me donner le moyen de résoudre ton problème.

c'est faux, juste au ./288 . Je n'ai vu ce problème qu'avant hier et je n'ai pas râlé, je suis passé directement à la 0.94SP4 sans me plaindre, vu que je n'ai plus confiance en la 0.95. Aucun de mes programmes ne s'est réassemblé correctement du premier coup.
Pour les autres problèmes, tu dis que c'est une erreur utilisateur ...
et au passage t'es complètement off-topic

Flanker :
c'est faux, juste au ./288 . Je n'ai vu ce problème qu'avant hier et je n'ai pas râlé, je suis passé directement à la 0.94SP4 sans me plaindre, vu que je n'ai plus confiance en la 0.95.

C'est bien dommage. J'espère pouvoir rétablir ta confiance en corrigeant ton problème.

Aucun de mes programmes ne s'est réassemblé correctement du premier coup.
Pour les autres problèmes, tu dis que c'est une erreur utilisateur ...

Ben oui, parce que tu n'as pas mis le switch demandé dans la documentation. Mais j'ai déjà dit qu'on va probablement le mettre automatiquement dans les futures bêtas.

Et merci pour m'avoir (enfin) envoyé la source qui pose problème.

Première erreur: section ".data". Avec TIGCC 0.95, le code va dans .text normalement.

Mais ton problème est ailleurs.

C'est bizarre. Le linker n'a fait que 2 optimisations:
1. bne _bad_arg: bne.w _bad_arg -> bne.s _bad_arg
2. pea bad_arg_str: pea bad_arg_str.l -> pea bad_arg_str(PC)
Les 2 optimisations m'ont l'air valides.

C'est un hack invalide de ta part:
;PATCH AZER : (+$6A) $6706 -> $67CC
L'offset n'est pas bon après optimisation du linker. Déjà le commentaire n'est pas à jour (tu mets $67CA) et puis c'est:
;PATCH AZER : (+xyz) $6706 -> $67C6
après optimisation. (J'ai aussi remplacé +6A par +xyz parce que la taille du stub et du header est susceptible de changer à tout moment.)
Si tu modifies directement l'exécutable, il ne faut pas t'étonner si tu as un problème en changeant de version de TIGCC, surtout à optimisations activées. (Il suffit de désactiver les optimisations du linker pour que tes hacks marchent.)

j'avais compris dès le ./296, t'inquiète pas

Correction: Remplace:
move.w #$67CA,8(a0)
par:
move.w #$6700+((_kernel_ou_nostub+8)-(debut+6)),8(a0)
Une différence d'adresses est à coder telle quelle.

EDIT: Faute de frappe corrigée.

PS: (_kernel_ou_nostub+8) m'a l'air d'être l'adresse que tu veux viser d'après mes calculs, mais si je n'ai pas bon, mets l'adresse à viser par ton beq.

--