cherche beta testeurs pour shell - Page 2

>la moitié du nombre de words
la moitié du nombre d'octets plutot nan ?

puisque ce word indique le nombre de words à sauter


et sinon je ne savais pas que cette rom_call existait. je le faisais à la main, moi

moi non plus, je ne savais pas que ce rom_call existait, et je le fais aussi à la main. Mais comme le code correspondant fait qqes lignes, c'est pas très grave. Appeller le rom_call est à peu près aussi long

moué, mais c mieux d'apeller la rom call au cas où ils changent le format

si vous trouvez des bugs dans le désassembleur, pouvez m'indiquer c'est quel désassembleur qui buggue ? Y en a 2 (avec une routine commune, quand même), avec des raisons totalement différentes pour planter.
Et si possible l'instruction désassemblée...

Le code principal de ROM_CALL_3D1 est
movea.l 4(a7),a0
move.w 0x14(a0),d0
andi.w #0x7FFF,d0
addi.w #0xA,d0
[3 instruction correspondant à l'effacement de la partie haute de d0].
rts

> Appeller le rom_call est à peu près aussi long
En effet. Mais:

> moué, mais c mieux d'apeller la rom call au cas où ils changent le format
Voilà. Merci Pen².

bof, y aurait tellements de choses à changer dans la partie archive s'ils changent le format....

XDanger
> moué, mais c mieux d'apeller la rom call au cas où ils changent le format Voilà. Merci Pen².

Flanker
: bof, y aurait tellements de choses à changer dans la partie archive s'ils changent le format....

c pas une raison.
ça fait tjs un truc de moins
Et puis en plus comme ça, ça resterait compatible avec tous les AMS

ça se voit que t'as pas vu le code... Il est vraiment moche et si jamais ils changent qqc d'important, il y aura bcp bcp de choses à refaire

ah ? ba de toute manieres, je ne pense pas qu'ils changeront quelque chose de si tôt

maintenant qu'ils font rajouté le desktop, va falloir qu'ils se reposent pdt qqes années

Bon, est-ce que ce que j'ai marqué dans mon fichier:
// 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 !

est correct, étant donné que la routine fait principalement:
movea.l 4(a7),a0
move.w 0x14(a0),d0
andi.w #0x7FFF,d0
addi.w #0xA,d0
rts

Flanker > Si tu veux j'aimerait bien tester aussi tu trouvera une addresse mail ici ------------>

Godzil > mail envoyé

Flanker> j'aimerais aussi pouvoir tester ton shell s'il te plaît... Mail: illogict@online.fr

illogict > mail envoyé

T'1 d'après la description que tu donnes au post #0, il a l'air terrible ton explorer ! envoie-le moi STP : ---

Je sens la concurence dans l'air.

ça peut avoir plein d'avantages, un peu de concurrence !

Merci Tu veux dire quoi par "reconnaissance du format de compression acf" exactement ?

bin, il reconnaît si un fichier compressé en acf est un TEXT, un ASM, une EXPR...
Mais il est moins bien reconnu que le ZIP, le KOMP et le PEP (c'est moins précis)
En plus, on peut pas decompresser/compresser à ce format

Tu as fait comment pour trouver les codes que j'utilise dans l'en-tête des ACF ?

Si tu ne les as pas tous, je peux poster la liste complète.

Thibaut :
Tu as fait comment pour trouver les codes que j'utilise dans l'en-tête des ACF ?.

Bah, c'est facile, on prend un fichier du type voulu, on le compresse et on regarde avec tthedit.

Bien sûr, mais encore faut-il trouver l'octet en question et avoir un minimum de courage (que je n'aurais pas eu personnellement)

Faut bien rentabiliser l'éditeur hexa de CS
Je compresse 3-4 fichiers de type TEXT (par exemple), je regarde les points communs entre les headers. Après avoir grillé quel était l'octet concerné, je le remplace et je regarde avec einstein quel est le type affiché. Et je pense que j'ai la liste complète, merci

Voilà un screen animé à la demande de MacInToc. Il est assez gros ais ne montre que 1/100 de CS.

http://perso.wanadoo.fr/tisofts/divers/cs.gif

PS: je suis pas doué pour les screens désolé.

c vraiment ignoble. Dés que tu peut, essayes de faire un vrai interface.

En ce qui concerne le contenus du shell lui-même, c assez dur à voir dans un screen, mais ça à l'air pas mal, même s'il faudrait pensé à épurer l'ensemble (ce qui est prévu si g bien compris)

c'est dur de faire une interface jolie et qui prend pas trop de place
ok, les icônes sont moches, mais c'est normal, c'est moi qui les ai faites
Pour l'épuration, y aura toujours une version complète, vu que c'est celle qui sert. En plus, pour exécuter CS en flash, faut qu'il fasse 64ko, alors autant les utiliser

Mais nan, c pas dur. Au pire, ça prend 2Ko. Mais tu peut faire des trucs trés jolies en n&b dans 1Ko.
Les icones, je les comptes pas, elle ne font pas réellement parties de l'interface. Je parle ici essentiellement des menus et des boites.
CS en Flash, je suis pas sur que ce soit une bonne idée. Déjas, ça prendrais 64Ko minimum, ce qui est énorme (même si l'éditeur hexa et l'explorateur d'handle est inclus). Et puis, il n'y a rien à y redire, mais TI-GCC est quand même un bien meilleur compilateur que le TI FlashStudio (ou je c plus kel autre nom).
Aprés, tu fait ce que tu veux

MacIntoc
: c vraiment ignoble. Dés que tu peut, essayes de faire un vrai interface.

Moi, je la trouve très bien, son interface! C'est parce qu'il utilise les menus AMS (ce qu'il a raison de faire!) que tu râles?

mais si t'aimes pas les icônes, tu peux toujours le mettre en mode liste (qui est beaucoup plus pratique je trouve, surtout pour les handles).