nouvelle version de DB92 - Page 6

pas mal pr l'afichage des noms de ROM_CAll par le 1111.
Justement, j'aillais dire que ça aurait été bien de le faire

Quelques bugs :

- On ne peut plus éteindre la calc dans le débugger, ça fait un assez gros crash (un moment j'ai eu un arrêt du balayage vertical de l'écran, avec une ligne un peu trop bleue à mon goût)
- On ne peut pas naviguer dans les informations symboliques (en fait il manque la barre qui surligne le label/la variable selectionnée).
- Quand on essaie de modifier la valeur d'une variable dans la fenêtre des infos symboliques, on obtient une address error.
(J'ai une 92+ HW2 si ça peut aider de le savoir)

Mais autosymb on-calc, c'est


Sinon, ça n'a aucun rapport, mais en passant à l'AMS 2.08, j'ai du refaire le lanceur PPG d'as qui plantait. Je l'ai envoyé à la calc, j'ai compilé sous SIDE sans problème.
Et puis j'ai testé DB92, j'ai voulu l'éteindre, ça a crashé violemment, j'ai reseté. Maintenant a chaque fois que j'essaie de compiler sous SIDE, j'obtient un crash avec barre noire . Mais si j'essaie de compiler dans l'home, c'est bon.
Je vois pas bien comment le crash de DB92 aurait pu influencer là dessus, mais pourtant...
Ce qui est encore plus bizarre, c'est que si j'installe PreOS 0.59 (hw2tsr), je n'ai pas de crash avec la compilation sous SIDE.
J'ai utilisé TIGCC 0.94b11 pour faire le lanceur "AS" si ça peut aider.

Ca me fait penser que ça serait chouette que JM modifie VTI pour qu'il émule la protection d'execution HW2 (et qu'on puisse mettre un breakpoint dessus).

EXtendeD a écrit :
Et puis j'ai testé DB92, j'ai voulu l'éteindre, ça a crashé violemment, j'ai reseté. Maintenant a chaque fois que j'essaie de compiler sous SIDE, j'obtient un crash avec barre noire . Mais si j'essaie de compiler dans l'home, c'est bon.

Installe h220xTSR.

Ce qui est encore plus bizarre, c'est que si j'installe PreOS 0.59 (hw2tsr), je n'ai pas de crash avec la compilation sous SIDE.

C'est parce que Nitro utilise NG_execute pour lancer les programmes, et que NG_execute bogue (avec la protection anti-exécution) si on l'utilise pour lancer un programme en assembleur/C sur HW2 AMS 2. h220xTSR corrige ce bogue. (Parce que ce qui rend les TSRs instable, c'est justement que NG_execute n'est pas fait pour permettre l'exécution simultanée de 2 programmes en assembleur ou C. h220xTSR corrige ce problème, et ça sert aussi pour SIDE.)

Ok, merci.
Pourtant je n'ai jamais eu de problème avec l'AMS 2.05.

Avec:
- TI-92+ HW2
- AMS 2.08
- h220xTSR 1.10
- PreOs 0.60
- librairies compressées de PreOs
DB92 me donne un "Address Error" lors du dérelogement de SMQ. Je ne sais pas si c'est la faute de DB92 ou de PreOs.

Arg
Je vais voir ca

je verrai pour tous ces problèmes (j'aurai mon PC à l'internat à partir de lundi donc je pourrai programmer plus souvent)

pour l'extinction le problème semble aléatoire, je pense que c'est le trap #4 qui fait planter (je suis déja obligé de lui donner un pointeur de pile autre que celui de DB92 car comme le trap #11 il fait un reset si A7 n'est pas dans les valeur habituelles)

G rien trouve

Encore quelques petits bugs pour db92 :
- lea Label(pc),a1 est mal désassemblé, on voit a0 au lieu de a1 (ça le fait pour tous les registres d'adresse)
- Dans la fenêtre des handles, l'appuie sur 'H' ne permet pas de selectionner l'handle.
- Si on appuie sur gauche ou droite dans la fenêtre des handles, cette fenêtre semble freezer (mais le reste de db92 fonctionne).

Sinon l'affichage des noms de ROM Calls pour le line-emulator ou le nostub est très pratique, c'est parfois plus simple de débugger sur db92 que sur VTI
Ce qui serait bien c'est que ces noms soient affichés même pour deux registres d'adresses différents (par ex. pour les programmes C avec OPTIMIZE_ROM_CALLS, move.l rc_name*4(a5),a0).

l'affichage des ROM_CALLS marche avec optimize_om_calls, les noms sont affichées pour toute instruction du type move.l x*4(Ax),Ay

Meme avec move.l 4(a0),a1 ?
C nul puisque ca peut ne pas etre une ROM_CALL

Si:

 include "OS.h"
 xdef _nostub
 xdef _ti89
 xdef _ti92plus
 ;Aucun registre ne doit être sauvegardé ici.
 pea.l hello_world(PC) ;passe le message à afficher en argument
 move.l $c8,a0
 move.l ST_helpMsg*4(a0),a1
 jsr (a1) ;appelle ST_helpMsg
 addq.l #4,a7 ;nettoie la pile
 rts
hello_world: dc.b 'Hello, World!',0

Et 4(a0), ça peut être WinActivate*4(a0).

Par exemple:

 include "OS.h"
 xdef _nostub
 xdef _ti89
 xdef _ti92plus
 move.l $c8,a0
 move.l (a0),a1
 move.l (a1),-(a7)
 move.l 4(a0),a1
 jsr (a1)
 addq.l #4,a7
 rts

Voilà, ici move.l 4(a0),a1 est bien un ROM_CALL!

Il a dit 'ça peut ne pas être' et non pas 'ça ne peut pas être'

Ah, bonne remarque.
Mais DB92 ne peut pas savoir que ce n'est pas un ROM_CALL si ça n'en est pas un! (Il y a le même problème avec ttdasm -name. La "solution" de ttdasm est d'afficher les noms de ROM_CALLs entre 2 points d'interrogation, style ?ngetchx?. )

D'où la remarque de PpHd

La dernière version est bien la 0.94 alpha ? L'affichage des ROM Calls lancées avec OPTIMISE_ROM_CALLS ne fonctionne pas chez moi (92+ AMS 2.08)

de plus le lea var(pc),a0 est correct

Bizarre...
Ca n'arrive que sur ma calc?

Non je viens de me mettre à tester un peu DB92 et moi non plus je n'ai pas le nom du ROMCALL, même avec la syntaxe move.l x*4(An),Am
En tout cas c'est vraiment bien comme programme, bravo!

Et le bug de Kevin, qqun d'autre la ? (Pb de reloc des progs kernels).

Problème de unreloc2 plus précisément (il n'y a pas de problème lors du reloc2).

PpHd, as-tu essayé si Prosit marche encore (pour voir si les fonctions (un)reloc(2) de PreOs marchent)?

Question: le fichier ROMCALL.BIN livré dans les sources est valide pour quelle version de l'AMS sur TI89?? (je parle evidement de la version 0.34 alpha)

Je dis ca pour savoir s'il est a jour ou pas

Complet pour 1.05, partiellement complet pour 2.05.

j'ai corrigé les bugs signalés, mais je ne peux pas mettre le fichier en ligne car je ne peux pas accéder au ftp (soit lycos a un problème, soit c'est la config du routeur du lycée)
J'ai le même bug que Kevin avec SMQ
avec TI89 HW2 AMS 2.08 patché PreOS 0.62 et librairies compressées (le bug n'arrive pas si les lib ne sont pas compressées)

C'est donc probablement un bogue de PreOs...
PpHd ne va pas être content...

voila :http://membres.lycos.fr/hwti/db92-nostub-alpha-035.zip
j'esprère que le serveur web marche bien car le serveur ftp fonctionne de temps en temps seulement, en fait il fonctionne pendant nviron 30 min si je change le mot de passe, puis après erreur comme quoi il ne peut établir la conection, je rechange le mot de passe et ça remarche)

Cette version fait freezer ma calc dès le lancement (et l'écran affiche n'importe quoi)

Sinon, il y a un petit bug dans la v0.34a : on ne peut pas débugger des programmes pour kernel qui executent un programme pour kernel, sur une calc non patchée avec hw2patch.
Le bug se trouve dans la nouvel routine d'exécution des programmes pour kernel (New_34), il faut remplacer sub.l #7+$40000,a6 par subq.l #7,a6, sinon la protection d'exécution des HW2 se déclenche à l'exécution du programme kernel (qui est executé par le programme kernel que l'on est en train de débugger).

Bug de db92 unreloc2.
Bon : c'est bien un bug de db92, pas de Preos.
Explication : db92 appelle la fonction reloc2/unreloc2 en mode superviseur donc avec sa 'Private Stack' de 512 octets (Je vous vois venir). Or, la relocation est une operation qui peut etre TRES couteuse en consommation de pile ! D'ou un debordement de pile inevitable ! Le bug apparait car la protection anti-perte d'handle elimine des handles avec une table de sauvegarde corrompu par le debordemebent de la pile.

Solution: mode user ou stack plus grande.