cherche beta testeurs pour shell - Page 1

Je suis en train de développer un shell,CS, (pour l'instant 92+ hw2 uniquement) et j'aimerais bien quelques beta-testeurs pour voir s'il y aurait pas quelques bugs.
Le seul gênant est qu'on peut pas le lancer depuis le desktop (comme app flash).
Il commence à être assez gros (50ko) mais il intègre pas mal de fonctions intéressantes (pour moi) : éditeur hexa, explorateur de handles et d'archive, 2 désassembleurs, ... Je pense que je ferais une version light quand il n'y aura plus de bug (les permiers tests donnent une taille d'environ 25ko, mais tout n'est pas optimisé)
et une version 89

Je veux bien être beta testeur.

J'ai une TI92+ HW2 avec ROM 2.08

Mon mail: geoffrey.anneheim@wanadoo.fr

Je veux bien que tu poste un screenshot

Vu ce qu'il dit, son shell m'a l'air sympa.

Justement, comme j'ai pas envie de tester j'aimerais bien voir un screenshot

Moi je veux tester pour TI-Fr, ça fait déjà 2 progs en test.

1° Ti-Fr existe pas, y'a le temps
2° De toute façon il faudra leur accord

Je viens de tester, tout d'abord j'arrive pas à envoyer le prog main.cslaunch.9xz, au bout de 2 sec le link ce coupe, ça vient du prog à 100%.

Donc avec juste Xcsii.
Quand je clique sur home, j'ai un bug, en bas ça affiche:

0x0001
0x0002
0x0003
0x0004
Handles

Dans archives j'ai des fichiers avec des nom 0x00xx, je poense que c'est des archives corrompus à cause de pedrhum.

Dans l'affichage de l'état de la mémoire il y a des bugs d'affichae, le texte ko n'y ets pas juste o.

Par contre comment tu fait pour savoir si on à détruit un secteur dans la mémoire Flash?

Au final je dit chapeau car c'est le meilleur shell que je vois sur TI avec des fonctions vraiment utile est interessante. Certe il est en noir et blanc ais ça arrache. La fonction HexEdit et très interesante surtout pour moi, pour voir les handles.... Ce qu'il manque c'est juste afficher la taille d'un handle.

Ca va être le premier shell que je vais garder définitivement sur ma TI.

Je t'assure je n'ai rien vu de mieux. Juste un pb la taille du programme, mais assez compréhensible pour ses fonctions et sa convivialitée.

A oui joublie dans FlashApp tu affiche Home, Graph, Window, CLock mais on ne peut les modifier ou y accéder, c'est normal?

Je suis heureux de tester ce shell.

Encore un truc le desassembleur et vraiment pratique et interessant, les fonctions de compression.... vraiment interessante, l'éditeur hexa d'un simpliciter à tuer mais très pratique. Au final je suis stupéfait par ce shell, la je sens que tu devrait faire de la PUB et même deman,der à texas d'en fair eune APP Flash tellement que je le trouve extraordinaire. Je dis bien aucun shell ne peut arriver à la cheville de celui-ci mais vraiment aucun.

Par contre ce qui est dommage avec le viewer de texte c'est qu'il ne peut pas ouvrir tout les programmes et surtout qu'il faut appuyer plusieurs fois sur les fléches pour défiler, rester appuyer aurait était mieux.

Apart les bugs mineurs que j'ai cité, je n'en constaste pas, si peut être un problème de link quand on quitte le prog.

Corrigé pas de bug de link.

Eh bin, ça fait plaisir !
Encore merci d'avoir servi de cobaye
Je réfléchis encore à l'exécution des flash app, mais c'est pas trivial. Dommage que cslaunch passe pas (d'ailleurs je comprends pas d'où ça peut venir), car il installe CS en tant qu'app flash sur 92+ (qui est alors exécuté en archive) Par contre, ça fait pas mal deux cas à gérer à chaque fonction sur les app flash. Le répertoire appflash sert donc pour l'instant à afficher les infos et à les effacer (sauf les built-in comme le HOME )
Pour le truc
"0x0001
0x0002
0x0003
0x0004
Handles "
, t'es sûr que c'est pas l'icône (la seule que j'ai trouvée - représenter un handle en icône, je savais pas trop comment faire) ? Fais enter dessus, je pense que ça devrais passer
Dans l'affichage de la mémoier, je pense que ce n'est pas un bug, j'ai mis 'o' pour octets, j'avais la flemme de faire la conversion en ko (j'aurais dû mettre des chiffrres après la virgule)
Après réflexion, pour cslaunch, c'est peut-être dû à TIconnect, car il vient de ma calculette (après assemblage, je dois l'exécuter une fois avec un kernel sur la calculette pour qu'il marche correctement).

Oui, il y a tout plein de trucs intéressants dans CS. Son gros défaut est de ne marcher que sur 92+ HW2. De toute façon, il ne sera jamais aussi bien sur tous les autres modèles, vu qu'ils n'ont pas ce que la 92+ HW2 a...

> "La fonction HexEdit et très interesante surtout pour moi, pour voir les handles.... Ce qu'il manque c'est juste afficher la taille d'un handle."
C'est aussi le job de tthdex (ma version interne que je n'avance pas beaucoup, du moins), sauf que lui n'édite pas la RAM et ne reconnaît actuellement pas autant de types de handles que CS... Aussi, tthdex n'a pas de désassembleur et n'en aura peut-être (probablement) jamais.
tthdex et CS ont un grandi ensemble, Matthieu et moi nous sommes passés diverses infos.

Pour le truc
"0x0001
0x0002
0x0003
0x0004 Handles "

Oui c'est l'îcone mais elle est assez mal affiché et fait penser au démarrage à u bug graphique.

J'ai aussi constaté un bug dans le desassembleur, ça me l'a fait une fois. Le prog a planté.

il a l'air bien ce shell, mais pourquoi ne pas avoir d'abord développé les outils séparemment ?
du genre le désassembleur, un utilisateur lamda ne s'en servira jamais, pas plus que de l'éditeur hexa.
Du coup ton prog est plus lourd et est moins accessible au pauvres nOObs
(tu me diras est-ce vraiment un mal? ben non je crois pas mais bon...)
Moi j'aimerais bien voir le désassembleur histoire de rigoler, et le browser de handle
parce que je m'en sers pas mal pour faire mes formats de données perso et vérifier que tout se
passe bien.
D'ailleurs si XDanger veut bien me passer les dernières sources de tthdex, je ferais bien qq essais pour voir.

J'avoue que plusieurs progs séparé auait était mieux, dans mon cas ce genre de shell est vraiment utile, pas trop le desassembleur mais ça peut servir. Mais vu tout ce qu'il offre et l'environnement je le trouve 100% mieux que tout shell existant sur TI.

Au faite un twins c'est quoi?

la copie en ram d'un programme archivé que tu es en train d'utiliser (en général)

veu bien tester aussi...

> EvaSDK : j'ai préféré tout réunir en un seul car je trouve que c'est plus pratique, on bascule très simplement entre le désassembleur et l'éditeur hexa, l'éditeur hexa est "calé" sur la variable sélectionnée, ... Je me sers d'à peu près tout. En plus, sur les 92+, il peut s'exécuter en archive et il faut alors bloquer un secteur de 64ko en entier => autant les rentabiliser
Enfin, je pense faire un version light sans tous ces outils. J'ai déjà fait quelques tests, j'arrive à 25ko, mais je pense pouvoir lui perdre encore qqes ko.

si tu utilises l'explorateur de handles pour voir si ton prog n'oublie des handles, l'option "filtrer les handles connus" pourrait t'être utile

> Geogeo : un bug dans quel désassembleur ? Désassemblage de fichier ou celui couplé à l'éditeur hexa ?

> damd3: il me faudrait ton email si tu le veux

un bug dans quel désassembleur ? Désassemblage de fichier ou celui couplé à l'éditeur hexa ?

Dans le désassembleur seul.


Le shell que tu as réalisé était il y a longtemps un de mes rêve et je suis heureux de voir que quelq'un l'a réalisé. Quand je le voit je me dit, qu'il sont con chez Texas de ne pas avoir fait un shell comme ça, il aurait vendu plus de caltos.... Dans tout les cas encore chapo et vraiment. Je suis heureux d'être bêta testeur.

Ah oui parcontre ce que je ne comprend pas c'est quand je vais dans archives, je vois des secteurs? (ça veut dire quoi?)

Aussi j'aime bien voir dans la mémoire flash les secteurs occupé et libre....

Au faite comment tu fait pour savoir si un secteur est corrompus?

la mémoire archive est divisée en secteurs de 64ko (64 sur la 89/92+ et le double sur v200). On est (à e que je sais) limité à deux opérations sur la mémoire archive : effacer un secteur de 64ko (en fait, on le remet à $FFFF) et "transformer des 1 en 0", i.e. quand on écrit en archive, on ne peut faire qu'un AND logique entre la donnée déjà écrite et la donnée qu'on veut écrire (d'où l'intérêt de tout remettre à $FFFF quand on efface). Le truc de transformer des 1 en 0 explique le choix des valeurs pour marquer qu'un fichier est archivé ($FFE0 sur ams 2x et $FFFE sur ams 1) et effacé ($FFC0 / $FFFC) : on peut transformer $FFE0 en $FFC0 mais pas le contraire.

Un fichier ne peut pas être à cheval sur deux secteurs (contrairement aux applications flash). Ca explique pourquoi la réorganisation des archives est une fonction assez complexe et qu'il vaut mieux archiver les gros fichiers avant les petits (qui vont venir compléter les secteurs entamés).
le fait de voir les secteurs dans l'explorateur d'archive permet de choisir quels sont les fichiers à désarchiver avant de faire un garbage memory (par exemple, si tout plein de petits fichiers occupent un secteur entier) puis d'archiver un gros fichier et enfin de réarchiver les petits fichiers

sinon je vois pas trop à quoi tu fais référence quand tu parles de secteurs corrompus. A quel endroit du shell on voit ça ?

Dans les infos Etat mémoire tu donne archive détruit.

c'est une fonction du tios qui donne l'état de la mémoire archive : EM_survey
Collects some useful information about the archive memory.

EM_survey collects some useful information about the archive memory and stores them in six variables pointed to by arguments. *inUse is the number of used bytes. *freeAfterGC is the number of bytes which will be free after performing garbage collection (see EM_GC). free is the number of free bytes (not counting bytes occupied by "deleted" blocks, which will become "free" only after the garbage collection). *unusedSectors is the number of bytes in "unused" sectors. I don't know why the archive memory contains usually one unused sector (i.e. sector which is never used for archiving purposes). The program called "MoreMem" just marks such unused sectors as "sectors in use" to get more archive memory (?). *badSectors is the number of bytes in bad sectors, but I am not so sure what "bad sectors" really means. *allExceptBaseCode is the number of all bytes in the Flash ROM which are not occupied by TIOS. This argument is new in AMS 2.xx, but you must use six arguments even on AMS 1.xx. If you don't need a particular information, you may pass NULL as the argument. TIOS will see it's a null pointer and will not save anything in it.

TIOS uses only freeAfterGC and free and always passes NULL to everything else. *freeAfterGC + *free is used to tell the user how much archive memory is available. Thanks to Johan Eilert for information how EM_survey should be used correctly on both AMS 1.xx and AMS 2.xx.

Ah d'accord, mais dans le cas comment programmer ce genre de fonction, je veux dire comment ça fonctionne?

Le secteur et parcourus, on écrit dedans et si la valeur écrite et fausse alors corompus?

> D'ailleurs si XDanger veut bien me passer les dernières sources de tthdex, je ferais bien qq essais pour voir.
Il ne marche pas actuellement. J'ai trouvé un bug bête que je vais corriger (HeapDeref "manuel" à partir d'une adresse impaire, puisque j'ai oublié le lsl.w #2,%%dn; j'ai réécrit une grande partie du code de startup et ça ne va pas tout seul pour le moment...), mais rien ne dit qu'il n'y en a pas d'autres...
Et il manque au moins un bout de code, qui est pour le moment remplacé par un truc très sale qui ne marche peut-être que sur l'AMS sur lequel je le teste...
Donc, pas avant quelques jours, désolé...

j'ai vaguement regardé le code de EM_survey, et je crois qu'elle parcourt toute la mémoire archive, secteur arpès secteur. A l'intérieur d'un secteur les emplacements de fichier s'appellent des blocs. Un secteur a un format bien standard :
Offset Taille Sens/valeur :
0 2 $FFFF/$FFFE/$FFFC indique si le secteur est vide/utilisé/plein

2 2 $FFE0/$FFC0 indique s'il s'agit d'un fichier archivé / effacé
4 8 répertoire du fichier
12 8 nom du fichier (ça sert après un reset pour récupérer les archives)
20 n c'est le handle du fichier

2+n 2 $FFE0/$FFC0 indique s'il s'agit d'un fichier ....

A propos du handle, les deux octets qui précèdent les handles sont également recopiés (t'as peut-être remarqué que si tu vas à un handle dans mon éditeur hexa, il y a deux octets surlignés à la ligne précédente), il servent à indiquer la taille du handle (bits 0 à 14 : c'est la taile divisée par 2) et s'il est verrouillé (ce qui est toujours le cas en archive). C'ets avec ces 2 octets qu'on détermine n (et surtout pas avec ceux qui indiquent où est le TAG) pour pouvoir aller au bloc suivant.

Une partie des infos que tu postes au début est disponible dans la doc de TIGCC à EM_write.

>A propos du handle, les deux octets qui précèdent les handles sont également recopiés (t'as peut-être remarqué que si tu vas à un handle dans mon éditeur hexa, il y a deux octets surlignés à la ligne précédente), il servent à indiquer la taille du handle (bits 0 à 14 : c'est la taile divisée par 2) et s'il est verrouillé (ce qui est toujours le cas en archive). C'ets avec ces 2 octets qu'on détermine n (et surtout pas avec ceux qui indiquent où est le TAG) pour pouvoir aller au bloc suivant.
Ca, c'est le job d'un ROM_CALL appelé en interne (disponible dans la jump table sous AMS 2.xx seulement, malheureusement...), notamment par EM_findEmptySlot.

c'est le ROM_CALL_3D1, non ?
et il indique pas n, il indique la taille du header divisée par 2 (soit (n+20)/2)

Merci pour tout ça.

> c'est le ROM_CALL_3D1, non ?
Exact. Et je n'avais pas relu mon fichier dans lequel il est écrit:
// C'est la routine qui renvoie la moitié du nombre de words qu'il faut pour
// pointer sur le début du prochain bloc dans l'archive (!), voir EM_write
// pour plus d'explications...
// Elle est appelée par une sous-routine de EM_findEmptySlot pour trouver le
// prochain bloc libre. JAMAIS BESOIN DE L'APPELER pour cette raison !