Les fonctions de lib - Page 2

Ximoon
: Et ça marchera jusqu'à ce qu'il n'y ait plus de fantôme de la RAM du tout... une fois ne t'a donc pas suffit?

J'ai édité mon message pour préciser que c'est une mauvaise idée, et pas seulement à cause de ça. "(Mais la méthode "propre" est plus efficace parce qu'elle évite de devoir détecter le matériel pour savoir quoi ajouter.)" En revanche, c'est une méthode utile pour patcher les programmes existants, parce qu'elle ne change pas la taille du code. Il est très difficile de changer la taille d'un morceau de code dans un programme binaire seul.

Et d'ailleurs, quand je vois ce qui a été fait dans le passé, j'ai bien peur que les auteurs de kernels vont mettre un RAM_CALL tios::ghost_space pour remplacer l'adresse absolue plutôt que d'encourager l'usage de la méthode propre. Il n'y a qu'à voir tios::Heap, tios::FolderListHandle etc.

Pollux
:Ximoon> L'espace fantôme est quand même utile pour le patchage des progs existants, parce que ça a exactement la même taille... Même si c clairement à éviter dans les progs censés marcher partout.

Exact. (J'ai écrit le message ./31 avant d'avoir lu le tien.)

GoldenCrystal :
./28> Tu ne vas quand même pas nous faire croire que vous (TIGCC & TICT) n'y êtes pour rien dans la propagation de ce hack ?

Les auteurs des kernels l'ont utilisé et propagé bien avant nous. Regarde la source de TeOS, par exemple. (Il y a écrit noir sur blanc que c'est une bonne idée pour économiser quelques octets.) Et PreOs l'utilise aussi de partout.

Cette méthode figure dans le doc de TigccLib ?

Ximoon
: Cette méthode figure dans le doc de TigccLib ?

Non. Une recherche de "0x40000" ne trouve que: "enter_ghost_space", "EXECUTE_IN_GHOST_SPACE", "How can I create a program that is bigger than 24K and works on AMS 2.xx?".
La manière de laquelle fonctionne SetIntVec n'est pas documentée, c'est un détail d'implémentation qui ne regarde que nous. Et qui a de fortes chances de changer dans la prochaine bêta, d'ailleurs.

./32>
Oui, mais c pas bien de repousser la faute sur les autres...
(Il y a tant de choses qu'on pourrait dire sur ces deux phrases...)
Tout d'abord, je trouve ça étonnant que tu appuies ton argumentation sur des kernels, que tu ne cesses de critiquer. En tant que _nostubien, tu aurais au moins pu vouloir distinguer le nostub des kernels en supprimant les hacks qui dataient d'une ancienne époque (d'ailleurs tu fais aussi partie des personnes qui évitent les hacks le plus possible, il me semble...) Enfin, au moins, ça démontre une chose... (Y'a-t-il besoin de l'expliquer ? )

Et d'ailleurs, quand je vois ce qui a été fait dans le passé, j'ai bien peur que les auteurs de kernels vont mettre un RAM_CALL tios::ghost_space pour remplacer l'adresse absolue plutôt que d'encourager l'usage de la méthode propre. Il n'y a qu'à voir tios::Heap, tios::FolderListHandle etc.

Cela dit, ça m'étonnerait que TI mette plus de 2 Mo de RAM, surtout si la taille d'un fichier est tjs limitée à 64k (et si par hasard ce n'est plus le cas, il va y avoir un gros tas de progs à modifier, et ce sera pas des modifs triviales...)

D'ailleurs, encore un truc à rajouter: la méthode "propre" présuppose quand-même que le port 0x600001 reste à sa place habituelle. Qui est-ce qui vous garantit ça? Ce port peut changer de place, voire disparaître ou être protégé par la protection Flash, à tout moment. Sinon, pourquoi les gens chez TI interdiraient-ils l'accès direct aux ports lors de chaque concours de FlashApps?

Nous allons probablement utiliser la méthode "propre" pour les prochaines versions de TIGCC pour des raisons pratiques (plus court que de détecter le matériel pour connaître l'adresse de l'espace fantôme), mais je ne suis pas convaincu qu'elle soit plus sûre que l'autre pour le futur.

Moi je crois pas qu'ils changeront les ports I/O, parce que de toute façon ils sont bien obligés de se réserver 1 ou 2 Mo pour ça, alors autant les laisser à leur place... Et comme il y aura probablement plus de Flash que de RAM, dans le pire des cas on aura
0x0*****-0x3***** : RAM
0x8*****-0xF***** : Flash
ce qui laisse encore de la place...

Sinon, pourquoi les gens chez TI interdiraient-ils l'accès direct aux ports lors de chaque concours de FlashApps?

Pour ne pas encourager le reverse-engineering du hardware et pour ne pas faire connaître J89HW ?

Au pire ils changent l'adresses des ports, et le patch consiste juste à changer l'adresse dans le programme.
Ou alors tu rajoutes une pseudo constante IO_BASE dépendant du modèle... remarque vous pouvez le faire dès maintenant en la mettant réellement constante et en prévoyant le coup ... Ou alors tu contactes une voyante ça pourrait servir pour anticiper.

Kevin Kofler
: D'ailleurs, encore un truc à rajouter: la méthode "propre" présuppose quand-même que le port 0x600001 reste à sa place habituelle. Qui est-ce qui vous garantit ça? Ce port peut changer de place

Admettons, mais ça m'étonnerait beaucoup (le seul truc qui provoquerait ça serait une augmentation de la taille de la FlashROM)

, voire disparaître

Impossible

ou être protégé par la protection Flash, à tout moment.

Idem. La protection flash s'applique uniquement à la mémoire flash

Sinon, pourquoi les gens chez TI interdiraient-ils l'accès direct aux ports lors de chaque concours de FlashApps?

Je ne savais pas ça, mais il y a de fortes chances que ça n'ait strictement aucun rapport...

euh...merci...vous dites pas de prgm kernel mais bon y quant meme besoin de connnetre les fonction du tios pour prgmer en nostub ??? nan ? bon sinon NG = Norton Guide, c'est over pratique pour connaitre les 255 (environ) librairie de fonction en x86 (interruptions)... genre les fonctions dos, les fonctions graphiques (powwwwa) ou les fonctions pour gerer la souris... voila voila...

euh..j'ai regarder la doc TIGCC mais bon je l'avaos deja cela...et je crois qu'elle explique que les fonctions utilisé en C (j'en est fais un peu aussi de ca...) mais bon je me rappelle plus y avait po une histoire de prendre les argument des fonctions C est de pusher a l'inverse puis de faire un appel ? en asm bien sur... dac c'est po trop comprenhensible ce que je dis mais bon... vous savez vous ?
j'avais aussi un tut nostub aussi mais bon je vais lire celui de KK...

./31: Ben je voulais le mettre il y a un an. C'est une bonne raison pour le faire aujourd'hui.

GoldenCrystal
:

Kevin Kofler
: D'ailleurs, encore un truc à rajouter: la méthode "propre" présuppose quand-même que le port 0x600001 reste à sa place habituelle. Qui est-ce qui vous garantit ça? Ce port peut changer de place

Admettons, mais ça m'étonnerait beaucoup (le seul truc qui provoquerait ça serait une augmentation de la taille de la FlashROM)

Même pas. ROM_base est à 0x800000 maintenant.

, voire disparaître

Impossible

Ils pourraient très bien permettre l'accès aux vecteurs seulement dans les premières 10 secondes après un démarrage, par exemple.

ou être protégé par la protection Flash, à tout moment.

Idem. La protection flash s'applique uniquement à la mémoire flash

Totalement faux. La protection Flash s'applique aussi aux ports de la protection anti-exécution par exemple! (Le nom "protection Flash" est incomplet.) Donc elle pourrait très bien s'appliquer un jour à tous les ports.

screamX
: euh...merci...vous dites pas de prgm kernel mais bon y quant meme besoin de connnetre les fonction du tios pour prgmer en nostub ??? nan ?

Bien évidemment. Mais on les connaît suffisamment bien pour programmer avec depuis pas mal de temps déjà!

euh..j'ai regarder la doc TIGCC mais bon je l'avaos deja cela...et je crois qu'elle explique que les fonctions utilisé en C (j'en est fais un peu aussi de ca...)

Ce sont les mêmes qu'il faut utiliser en assembleur. AMS est écrit en C.

mais bon je me rappelle plus y avait po une histoire de prendre les argument des fonctions C est de pusher a l'inverse puis de faire un appel ? en asm bien sur... dac c'est po trop comprenhensible ce que je dis mais bon... vous savez vous ?

C'est bien ça. Cf. http://tigcc.ticalc.org/doc/asminfo.html.

PpHd :
./31: Ben je voulais le mettre il y a un an. C'est une bonne raison pour le faire aujourd'hui.

Ne le mets pas! Dis aux programmeurs d'utiliser bclr.b #2,$600001 et bset.b #2,$600001 à la place, ce serait plus productif. Ou penses-tu que la méthode de l'espace fantôme est plus portable que celle des ports?

Totalement faux. La protection Flash s'applique aussi aux ports de la protection anti-exécution par exemple! (Le nom "protection Flash" est incomplet.) Donc elle pourrait très bien s'appliquer un jour à tous les ports.

ça m'étonnerait. (Maintenant, pour l'argumentation, laissez-moi 3h, le temps que j'arrive à expliquer ça correctement sans dire de conneries)

merci les jeunes...surtout KK en fait... youpi je vais voire ce qu'on peut faire avec ca... héhéhéhéhé !

Totalement faux. La protection Flash s'applique aussi aux ports de la protection anti-exécution par exemple! (Le nom "protection Flash" est incomplet.) Donc elle pourrait très bien s'appliquer un jour à tous les ports.

Peu probable... TI ne va pas s'amuser à enlever la protection Flash à chaque auto-int 1... Mais ce serait posssible (mais très con) de le faire pour d'autres ports, par exemple 0x600017 ou autres choses pour la fréquence des ints.

Et puis si vous voulez avoir des scénarios apocalyptiques, on peut aussi envisager qu'il y ait un port de la TI qui doive être augmenté au moins 250 fois par seconde, et que seule l'auto-int 1 serait habilitée à incrémenter => on serait obligé de laisser l'auto-int 1 ralentir tous les progs

(suite du 44)Voilà, j'ai retrouvé ce que, je voulais dire
Le memmory mapped IO est juste une zone du bus mémoire qui est addressé au matériel de la TI plus ou moins directement (par exemple, il ya certains ports write-only, qui montrent que c'est bien direct). La protection flash ne diffère pas sur ce point (elle est aussi addressée au matériel) -> l'écriture dans ces ports est juste ignorée par la puce elle-même lorsque que les conditions requises ne sont pas toutes présentes. Ce n'est pas comme si il y avait une seconde interface avec le matériel qui pourrait toucher tous les ports, donc TI devrait rajouter une puce supplémentaire pour faire ça, et franchement, je ne pense pas que ça fasse partie de leur priorités.
(Comme j'ai écrit ça en deux fois, avec 3h d'intervalle, y'a p ê qq incohérences )

TI pourrait très bien faire faire ça à leur puce existante qui filtre déjà:
* les écritures en FlashROM, comme tu le dis,
* les lectures de la zone des certificats,
* les lectures/écritures de certains ports matériels en 0x700xx.
Ils n'ont pas besoin d'en rajouter une deuxième, juste de modifier celle qu'il y a déjà.

Petit argument en faveur des programmes kernels : je n'ai pas eu besoin de patcher txtrider pour qu'il tourne sur v200 car il était en kernel. Il se peut très bien qu'une licence interdise de patcher le programme ou qu'un patch ne fonctionne pas parfaitement (v200exep est très bien, mais je ne trouve pas que ce soit la méthode à préconiser vu qu'il ne peut pas trouver toutes les façons de déterminer le hw)

Flanker
: Il se peut très bien qu'une licence interdise de patcher le programme

Cette licence ne serait pas valide. On a le droit de faire ce qu'on veut avec un programme tant qu'on ne distribue pas ce qu'on a fait.
Et comme le patcheur lui-même n'est pas fait à des fins illégales, sa distribution est elle aussi sans problèmes.
Bref, les problèmes de licence sont inexistants.

ou qu'un patch ne fonctionne pas parfaitement (v200exep est très bien, mais je ne trouve pas que ce soit la méthode à préconiser vu qu'il ne peut pas trouver toutes les façons de déterminer le hw)

Tu vas voir si le patch Titanium (que je ferai si ExtendeD ne me devance pas ) va fonctionner. Je pense que c'est tout à fait faisable comme patch.

On a le droit de faire ce qu'on veut avec un programme tant qu'on ne distribue pas ce qu'on a fait.

on a le droit de le désassembler ???

Tu vas voir si le patch Titanium (que je ferai si ExtendeD ne me devance pas ) va fonctionner. Je pense que c'est tout à fait faisable comme patch.

tu veux que je te fasse un programme contre-exemple ? je suis sûr que c'est possible

Possible oui, mais improbable en pratique.

Et pas besoin de désassembler un programme pour le patcher. Il suffit de le modifier, et la modification à usage privé est permise sans restrictions. Et puis le désassemblage à des fins d'interopérabilité est autorisé. Ici, il s'agit d'interopérabilité avec une nouvelle calculatrice.

Il suffit de le modifier, et la modification à usage privé est permise sans restrictions. Et puis le désassemblage à des fins d'interopérabilité est autorisé

permise, autorisée par qui ?

n'empêche que ça reste une méthode sale, car non seulement tu peux louper un patch à faire, mais également tu peux faire un patch là où il ne faut pas en faire

exemple des datas

Flanker
:

Il suffit de le modifier, et la modification à usage privé est permise sans restrictions. Et puis le désassemblage à des fins d'interopérabilité est autorisé

permise, autorisée par qui ?

La loi. Les licences n'ont pas le droit de t'interdire tout. C'est pareil à peu près partout en Europe. Aux USA, c'est un peu plus compliqué, parce que là, des contrats que tu as signé peuvent t'interdire ce genre de choses, mais la validité des licences-contrat (contrats non-signés) n'est pas claire.

salut je voudrais genéré une matrice correspondant au table de la loi normale ou de poisson.comment le faire a partir des formule classique. je voudrais les grand étapes de l'algo le reste, je grater un peu et trouver.
Merci