Les fonctions de lib - Page 1

Ca fait longtemps que j'ai arrete l'asm 68k, je me suis mis a l'asm x86 et maintenant j'aimerais y revenir mais je ne trouve pas de doc d'explication des fonction du tios ou de doorsos ou plushell... genre NG pour le x86 vous savez pas ou je pourrais en trouver siouplé ??

Documentation des fonctions de AMS (la ROM): http://tigcc.ticalc.org/doc/
Tutorial _nostub: http://members.chello.at/gerhard.kofler/kevin/ti89prog/asmnstbf.htm
Les méthodes de programmation ont changé pas mal depuis l'époque de DoorsOS et PlusShell:
* On n'utilise plus les adresses absolues! C'est une manière certaine d'écrire des programmes qui ne marchent plus dès que TI met à jour leur AMS, donc à proscrire.
* Les kernels sont passés de mode (et d'autant plus les 2 que tu cites!).
* En revanche, ce sont les libraries statiques, chose totalement inconnue pour les TI-68k avant TIGCC, qui sont maintenant le state-of-the-art de la programmation sur TI-68k.
* L'assembleur est un peu passé de mode depuis que TIGCC permet de programmer en C, mais TIGCC gère aussi l'assembleur, et l'assembleur est toujours très utile pour pas mal de trucs.

Kevin, le Karl Lagerfeld des TI

Si tu veux etre underground, tu fais du kernel Yep Kevin, LOL

Si tu veux que ton programme ne marche pas sur la TI-89 Titanium, tu fais du kernel.
Pas de TSRs, pas de DLLs, bref le mode kernel est f**tu. Et ce n'est pas faute d'avoir essayé...

Mais non. Grace a HW3PATCH, les progs kernels tourneront sans recompilation 1 a 0 . Desole j'ai tape trop vite

Et vlan pkoi 1.0 ???

(euh oui là je crois que la 89 Titanium pour le nostub c'est un terrain miné, fait pas le malin Kevin )

PpHd :
Mais non. Grace a HW3PATCH, les progs kernels tourneront sans recompilation

Sauf qu'on ne l'a pas vu, ce patch, et on ne sait même pas encore s'il est possible d'en faire un. Il y a Pollux qui a emprunté ton pseudo? :-D

Ximoon :
(euh oui là je crois que la 89 Titanium pour le nostub c'est un terrain miné, fait pas le malin Kevin )

* J'ai déjà adapté un lanceur ExePack, et Bhuvanesh m'a confirmé qu'il marche. Et puis les programmes compressés peuvent aussi être décompressés tout simplement, la limite de 24 KO ayant été montée à 64 KO par TI.
* Les programmes qui utilisent l'espace fantôme pour écrire dans les interruptions peuvent être patchés, parce qu'il suffit de remplacer 0x400xx par 0x2000xx ou 0x4000xx dans les instructions qui modifient les interruptions. (J'ai testé ça.)
* N'ont un vrai problème que les shells (programmes non-indispensables, et puis ils peuvent faire ce que TICTex fait déjà pour les programme BASIC: recopier le nom dans la ligne d'entrée et quitter), les TSRs et les DLLs.

Mais avoue que changer juste les libs aurait été plus simple que patcher tous les programmes

Sauf si le principe-même de librairies dynamiques ne fonctionne plus.

Oui, mais plutôt que de corriger tous les programmes, on fait 1 programme qui fait que les libs dynamiques fonctionnent.

Jusqu'au bout il refusera de le dire

Il est plus facile de faire un patch qui modifie les programmes _nostub que de faire un patch qui modifie AMS. (Pour des raisons évidentes: AMS est protégé contre l'écriture, les programmes _nostub ne le sont pas.)

Oui, mais bon sang, à l'utilisation, c'est quand même moins contraignant d'avoir juste un programme à lancer pour corriger le problème, plutôt que de patcher chaque éxécutable qui pose problème !
Tu es un peu de mauvaise foi, là Kevin parce qu'un de tes arguments favoris pour démonter le mode kernel est que ça complique l'utilisation de devoir installer un kernel pour pouvoir utiliser un programme.

Sasume
: Tu es un peu de mauvaise foi, là Kevin parce qu'un de tes arguments favoris pour démonter le mode kernel est que ça complique l'utilisation de devoir installer un kernel pour pouvoir utiliser un programme.

Non, je ne suis pas de mauvaise foi. Maintenant (comme au début des HW2 d'ailleurs), on aura à installer pas un, mais deux programmes pour utiliser un programme pour kernel! Et cela même si le programme a été écrit spécifiquement pour la Titanium! Un programme _nostub tournera sans préinstaller quoi que ce soit après recompilation.

Et puis il y a pas mal de programmes pour kernel qui touchent aussi à 0x400xx pour les interruptions, donc qui auront besoin du même patch (celui à appliquer à chaque programme)!

Mouais on le changera pas hein.
Ceci dit moi ça me serait jamais venu à l'esprit d'utiliser un hack pour détourner des vecteurs alors qu'une méthode tout à fait propre existe...

Et elle est toujours valable sur Titanium ?
C'est la méthode qui consiste à déprotéger la mémoire basse ?
Il faut faire comment ?

move.w #0x700,d0
trap #1
...
trap #1

(pas taper )

Mettre à 0 le bit 2 à $600001.b
Il y'a aucune raison que ça ne marche plus, et si ça ne marche plus ça risque d'être dommage pour les nvg et détournements d'ints en général

Ximoon :
Ceci dit moi ça me serait jamais venu à l'esprit d'utiliser un hack pour détourner des vecteurs alors qu'une méthode tout à fait propre existe...

Il y a ce hack dans:
* TIGCCLIB (partout: SetIntVec, gray.s, les routines de remplacement pour OSV*Timer)
* ma version 3 plans de gray.s
* PreOs (à plusieurs endroits) et les autres kernels
* graphlib (du moins la version de PreOs)
* userlib (du moins la version de PreOs)
* PolySnd
* pas mal de programmes utilisateur. (Les programmes assembleur utilisent souvent la même méthode que SetIntVec.)

À peu près tout le monde l'utilisait.

À peu près tout le monde l'utilisait.

Parce que certaines personnes ont eu la mauvaise idée de la propager...

Ximoon :
Mettre à 0 le bit 2 à $600001.b
Il y'a aucune raison que ça ne marche plus, et si ça ne marche plus ça risque d'être dommage pour les nvg et détournements d'ints en général

Je pense que ça marche encore, les ports n'ont pas changé de place. Mais je peux faire un programme de test s'il y a un doûte.
Et il y a une méthode qui marche presque certainement (j'ai fait un programme pour le tester), et c'est d'utiliser 0x200000 ou 0x400000. (Mais la méthode "propre" est plus efficace parce qu'elle évite de devoir détecter le matériel pour savoir quoi ajouter.)

Oui, mais encore une fois dans ce cas le principal problème est qu'il soit par défaut dans Tigcclib, ce qui oblige à patcher tous les programmes... C'est moins nnuyeux dans PreOs et les libs dynamiques...

Kevin Kofler
:

Ximoon :
Mettre à 0 le bit 2 à $600001.b
Il y'a aucune raison que ça ne marche plus, et si ça ne marche plus ça risque d'être dommage pour les nvg et détournements d'ints en général

Je pense que ça marche encore, les ports n'ont pas changé de place. Mais je peux faire un programme de test s'il y a un doûte. Et il y a une méthode qui marche presque certainement (j'ai fait un programme pour le tester), et c'est d'utiliser 0x200000 ou 0x400000.

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?

* PolySnd

Au fait, qui-est-ce qui avait dit a geogeo d'utiliser ça ? Il me semble bien que dans les premières versions, il utilisait la méthode 'officielle'

Ximoon
:Oui, mais encore une fois dans ce cas le principal problème est qu'il soit par défaut dans Tigcclib, ce qui oblige à patcher tous les programmes... C'est moins nnuyeux dans PreOs et les libs dynamiques...

Tu n'as toujours pas compris que les programmes pour kernel sont:
* soit en C, alors ils ont exactement le même problème (SetIntVec est implémenté de la même manière que USE_KERNEL soit défini ou non),
* soit en assembleur, alors il y a de fortes chances qu'ils utilisent le exactement le même hack que nous.
Les interruptions sont utilisées pour beaucoup plus de choses que les niveaux de gris! Par exemple, il est indispensable de les rediriger pour faire de la lecture de touches bas niveau. (Les désactiver totalement comme le propose (de manière pas trop sérieuse) PpHd (./20) n'est pas une solution, parce que ça arrête l'horloge.) Bref, les programmes pour kernel doivent aussi être patchés.

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.

./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 ?