J' ai une Ams 2.05 :Pas trouvé de kernel - Page 3

>liquid: uniquement sur hw 2 kevin

C'est ce que j'ai dit:
mais sur HW2, on ne va plus voir grand chose (parce que LCD_MEM n'est pas un des 2 plans de gris)

Et quelle que soit la version matérielle, il faut avoir lu des tutoriaux sur les TSRs avant de vouloir mettre GrayOn en TSR.

merde g mal lu, g lu : "mais sur hw1 et sur hw2" au lieu de "et sur hw1 mais sur hw2"

Kevin ça s'adressait à moi les gris ?

Si oui, he bien je me souviens que toi et FL m'aviez dit que mon programme ne devrait pas marcher correctement, mais pourtant il marche, et mes nvg sont normaux

Correctement, c'est bien ce qu'ils ont dit
Ta lib fonctionne. Mal, mais elle fonctionne.

Ce qui m'énerve, c'est qu'il y a des programmeurs qui savent très bien qu'il y a des bogues aléatoires dans leurs programmes, parce qu'on le leur a dit plusieurs fois, mais qui font comme si rien n'était. Je répète pour Bob64:
[glow]Un bogue aléatoire est un bogue qui peut se manifester à n'importe quel moment! C'est pour ça qu'il s'appelle "aléatoire"! Donc même si tu ne l'as jamais eu, il existe quand-même![/glow]
Et donc il faudrait chercher à le corriger! (Par exemple en lisant les tutoriaux sur les TSRs, qui expliquent aussi très bien pourquoi ta méthode ne va pas du tout!)
[edit]Edité par Kevin Kofler le 08-03-2002 à 15:44:44[/edit]

Bien, on dirait que certains n'ont pas comprit...
Je répete donc pour MacIntoc et Kevin Kofler :

1) J'utilise, ainsi qu'un pote a moi, Vertel très souvent, et elle n'a JAMAIS buggé.
2) J'ai lu, et Uther m'a dit que les niveaux de gris n'ont aucune chance de planter sauf si l'utilisateur fait 'break' et que les nvg sont allumés.

Alors un bug aléatoire, je connais, ça arrive, et la justement il y en avait un que j'ai corrigé. Mais je pense quand même qu'avec Vertios, Interum & CMS2, si il y avait un bug aléatoire je l'aurais vu...

Alors d'accord, c'est possible que ce bug existe mais bon vous n'avez jamais vu le code de mon prog et vous me dites qu'il est buggé, déjà ça ça m'étonne, mais en plus ce 'bug' je l'ai jamais eu. Comment est-ce que vous voulez que je corrige qqchose qui n'existe pas ???

Je veux bien y mettre de la bonne volonté mais la quand même

c sûr, moi aussi g déjà eu ce pb : v-rally buggait chez certaines personnes alors que chez moi niet et pareil ds mon entourage ... il s'est avéré que c t une certaine config de cal/kernel qui créait des bugs ...

Mais elle est toujours aussi buggé (enfin, non, y a un bug de moins)

Cite-moi UN bug de vertel. Un seul !
(moi j'en connais un, mais je sais pas comment le résoudre)

>Bob64:
>2) J'ai lu, et Uther m'a dit que les niveaux de gris n'ont aucune chance de planter sauf si l'utilisateur fait 'break' et que les nvg sont allumés.

Ce que tu as lu est faux! Et Uther s'est trompé! Tu crois vraiment que je te raconte n'importe quoi??? C'est qui l'expert des TSRs? Uther ou moi??? Je trouve que le fait que tu me soupçonnes d'inventer un bogue qui n'existe pas, de la manière que tu le fais, est vraiment très insolent!

>Alors d'accord, c'est possible que ce bug existe mais bon vous n'avez jamais vu le code de mon prog et vous me dites qu'il est buggé, déjà ça ça m'étonne, mais en plus ce 'bug' je l'ai jamais eu. Comment est-ce que vous voulez que je corrige qqchose qui n'existe pas ???

Cf. plus haut! Bon, comme gras, rouge et effet "glow" ne suffisent pas pour que tu m'écoutes, on va rajouter des majuscules:
[glow]MÊME SI TU N'AS JAMAIS EU LE BOGUE, IL EXISTE QUAND-MÊME!!!!!!!!!![/glow]
Et je vais même rajouter:
[glow]CE N'EST PAS PARCE QUE TU NE COMPRENDS PAS POURQUOI IL Y A UNE ERREUR QU'IL N'Y EN A PAS!!!!!!!!!![/glow]

>Cite-moi UN bug de vertel. Un seul !

Elle installe un TSR avec la fonction GrayOn. C'est un bogue, point final!

J'ai déjà expliqué pourquoi c'est un bogue, mais je vais quand-même le refaire:
GrayOn redirige une interruption (l'auto-int 1 pour être précis) vers un endroit à l'intérieur de vertel. Dès que vertel a fini de s'exécuter, ce programme peut être déplacé en RAM, et donc le pointeur dans l'auto-int 1 n'est plus valable! (Et donc plantage!) Ce déplacement en RAM peut être causé par n'importe quelle fonction qui cause une compression du heap, y compris HeapAllocHigh et HeapAllocPtr (malloc) qui sont utilisées en interne à plein d'endroits dans AMS. Je n'ai pas besoin de voir le reste de ton code, le fait que tu utilises GrayOn pour installer un TSR est une erreur. (Je connais le code de GrayOn, et je sais exactement comment il fonctionne.)
À ceci se rajoute le problème de la protection des HW2: si entre 2 appels de vertel, la librairie a été déplacée, le prochain lancement peut déprotéger une autre zone, reprotégeant ainsi la zone vers laquelle l'auto-int 1 pointe. Mais ceci n'est même pas nécessaire pour causer un plantage, la compression du heap tout seul peut aussi tout faire planter.

Je ne peux que réitérer mon conseil:
[glow]APPRENDS L'ASSEMBLEUR AVANT DE VOULOIR FAIRE DU C!!! Surtout si c'est pour des choses techniques comme les TSRs![/glow]

Et toc

Et si vraiment tu es trop paresseux pour apprendre l'assembleur, lis au moins les tutoriaux de la TICT! En particulier S1P2 et S1P3. S1P3 se fonde sur S1P2 et explique comment fonctionnent les TSRs en C! Et Thomas Nussbaumer dit aussi exactement la même chose que moi:

A simple but COMPLETELY WRONG solution whould be to install an own interrupt handler, but don't restore the old one before returning from the main routine.

What's wrong with this approach?

In general there exists three kinds of memory blocks within the TI:

* unused memory blocks
* used memory blocks which position is NOT locked
* used memory blocks which position is locked

Used memory blocks which position is NOT locked are, for example, blocks where variables are stored, but which are not used actually.
From time to time the AMS performs some kind of heap re-organization (garbage collection). Unlocked memory blocks may change their physical location (address) during this garbage collection.
Only locked memory blocks will keep their positions for sure. They are marked as "not movable".
If a variable is used or if a program is executed the corresponding memory block is locked and will not change its position until it is unlocked again. For programs this unlocking is performed after the program returns from its main routine.
The code of the interrupt routine is also part of your program and by installing the interrupt routine its start address is written into the interrupt table.
If the corresponding interrupt occurs the processor will fetch this address from the interrupt table and tries to execute the routine which should be located there.
And that's the point! If the program exists the corresponding memory block gets unlocked and may be moved to somewhere else by the garbage collection, but the processor will still try to execute code at the previous (and now invalid) address. In almost all cases this will lead to a crash.

How to overcome this problem?

The only valid approach for this problem is NOT to unlock the memory block after the program returns from its main routine, but there is the next problem waiting: The unlocking of the memory block is performed automatically by the AMS !
The solution for this additionally problem is to make an own startup tool, which performs all steps the AMS will perform for a program, but which does NO unlocking at the end.

Donc maintenant qu'on est 3 experts à le dire (Thomas, FL et moi), tu vas enfin finir par nous croire???

Et pour savoir comment il faut faire, lis le tutorial S1P3! Il suffit de remplacer tout le code personnalisé pour créer une horloge dans sample.c par de simples appels à GrayOn, GrayOff et IsGrayMode.
[edit]Edité par Kevin Kofler le 08-03-2002 à 17:47:30[/edit]

Bon ça commence à m'énerver ça. Je sais que je suis loin de ton niveau en C, je sais que tu est un expert en TSR, MAIS C'EST PAS UNE RAISON POUR GUEULER EN ROUGE !!!

Bon, moi je vais rester calme :

Je trouve que le fait que tu me soupçonnes d'inventer un bogue qui n'existe pas, de la manière que tu le fais, est vraiment très insolent !
> Excuse moi mais comment est-ce que je suis sensé savoir que ma librairie est buggée alors que je n'ai jamais eu de problème ? Je sais que tu me l'a dit 50 fois mais j'aimerais bien voir ma lib planter de mes yeux.

CE N'EST PAS PARCE QUE TU NE COMPRENDS PAS POURQUOI IL Y A UNE ERREUR QU'IL N'Y EN A PAS!!!!!!!!!!
> C'est pas que je la comprends pas, c'est que je l'ai jamais vue.

Elle installe un TSR avec la fonction GrayOn. C'est un bogue, point final!
> J'étais loin d'avoir imaginé faire tout ça avec un seul petit GrayOn();

APPRENDS L'ASSEMBLEUR AVANT DE VOULOIR FAIRE DU C!!! Surtout si c'est pour des choses techniques comme les TSRs!
> Encore une fois je ne soupçonait pas avoir fait un TSR, moi


Et pour finir, si tu réponds ne crie pas en rouge, j'ai lu en entier tous tes posts, et pas plus le rouge que le noir

Kevin, est-ce que tu pourrais pas traduire les tutos ASM fondamentaux ?
Parceque moi, l'anglais... déjas que je suis à peine monolingue

Comment on fait pour désactiver la touche on sans bug?

>MacIntoc: Kevin, est-ce que tu pourrais pas traduire les tutos ASM fondamentaux ?
Parceque moi, l'anglais... déjas que je suis à peine monolingue

Déjà on prend la peine d'écrire en anglais et vous n'êtes toujours pas contents! Tu veux que je dise à Thomas d'écrire ses prochains tutoriaux en allemand (sa langue maternelle)?

>Zyriak: Comment on fait pour désactiver la touche on sans bug?

OSDisableBreak
[edit]Edité par Kevin Kofler le 08-03-2002 à 17:55:10[/edit]

Zyriak > Ce code EXEC désactive la touche ON jusqu'a ce que tu utilise certaines fonctions (va voir sur le site de FL) :
Exec "61024E7508D700074E5600002F0A347C00C82052206803B44E902052206803BC4E90246EFFFC4E5E4E7500000000"

Et celui ci la réactive :
"61024E7508D700074E5600002F0A347C00C82052206803B44E902052206803B84E90246EFFFC4E5E4E7500000000"

Kevin > De plus, je t'avais jamais vu en colere contre un newbie, et en C je suis un newbie.

Kevin>Oui, ça aurait certainement value mieux au départ. Ca aurait obliger d'autres personnes de traduire dans d'autre langue (quel fénéant je suis). Tandis qu'en anglais, comme tous le monde est censé le comprendre...

Et en basic, avec FLib :

flib("breakoff")

Et en basic, avec vertel("set_brek",0)

D'ailleurs ce que fait FLib est: OSClearBreak();OSDisableBreak();OSSetSR(0x0700);. Mais ce n'est pas très propre de laisser un SR modifié à la sortie et ça risque de boguer grave si AMS veut lire des touches. L'alternative est de rediriger spécifiquement l'auto-int 6, mais là encore, c'est une installation de TSR, et donc il faut faire très attention à ce qu'on fait (cf. la discussion ci-dessus au sujet de GrayOn).

>Bob64: Kevin > De plus, je t'avais jamais vu en colere contre un newbie, et en C je suis un newbie.

Bon, c'est la première fois que tu le vois alors.
Et quand on m'accuse directement de mentir (alors que j'ai déjà expliqué les raisons de ce que je dis au moins une fois, et que, alors qu'on n'a apparemment rien compris, on n'a même pas pris le temps de s'informer sur ce sujet pendant les plusieurs mois du moment où j'ai expliqué le problème pour la première fois jusqu'à maintenant) je ne peux pas réagir autrement.
[edit]Edité par Kevin Kofler le 08-03-2002 à 18:08:39[/edit]

Je ne t'as jamais accusé de mentir !!!
Je ne pense pas que tu me dise des conneries, surtout quand il s'agit de TSR (ce que j'ignorais...). Mais ça m'étonne d'être passé à travers ce bug malgré l'utilisation que je fait de vertel...

Bon pour le résoudre il suffit d'un GrayOff(); à la fin ?

Oui et non.
Plus précisément: oui, mais alors tu dois faire comme FL (tout l'affichage des niveaux de gris doit se passer à l'intérieur de vertel, si tu veux une image en niveaux de gris qui bouge, tu dois t'occuper de l'animation à l'intérieur de vertel).
Une alternative meilleure est probablement d'adapter le code du tutorial S1P3 de la TICT. (D'après ce que je vois, il y a surtout du code à virer et remplacer par des fonctions de gray.h, et pratiquement rien à rajouter.) Et d'installer h220xTSR sur HW2, ou alors de dire à tes utilisateurs de le faire.

Bien, donc la fonction gray désactivera de toute façon les nvg à la fin de l'appel de la librairie, comme fait flib je crois...
Pour le h220xTSR, ça m'embete un peu, puisque je veux que vertel n'aie besoin de rien d'autre pour fonctionner, comme flib.

Merci pr ces réponses.

Sans rancune ?

Quelle est le meilleur moyen de désactiver la touche on?
Et puis g pas compris comment a q uoi servent les fichiers de la ti avec extension Zip

Zyriak je t'ai répondu, post 77

j ésperais un moyen plus simple mais bon tant pis.c est quoi les risques d' erreur ou de plantage?

y'en a pas. Evite simplement de te retrouver dans un cas comme celui la :

Exec "61024E7508D700074E5600002F0A347C00C82052206803B44E902052206803BC4E90246EFFFC4E5E4E7500000000"
loop
endloop

Parceque bon c genant quand même pour arreter le prog

De tte façon j essaie tjrs de pas etre tro loin de mon tournevis (...)

G trouvé un fichier zip dans ma calc. et g pas compris comment y servait?

en y réflechissant:
si on fait une connerie avec exec on peut tjrs effecer evac reset?