DB92 en _nostub - Page 3

Juste pour dire que le projet n'est pas mort, mais que ExtendeD et moi, nous sommes en train de corriger plusieurs choses et que je ne veux pas sortir une alpha tant que les corrections ne sont pas au point.
[edit]Edité par Kevin Kofler le 01-01-2002 à 04:27:14[/edit]

Le format n'est pas si complique Quand a si je peux les rajouter, oui, mais ca me fait chier Je prefererais autre chose

Hum... Pphd qui dit qu'il préférerait autre chose ??
serait-ce par rapport au vieux débat ?

Autre chose quoi? La version kernel de DB92?

Et l'alpha 0.24 de DB92 _nostub sortira probablement demain.
[edit]Edité par Kevin Kofler le 02-01-2002 à 02:57:54[/edit]

Une autre methode ! Fait un mistub : rajoute cela au debut de db92 et compile en nostub :

_begin:
bsr.w _start
cnop 0,4
dc.b "68kP"
dc.w 0
dc.w _comment-_begin
dc.w _main-_begin
dc.w 0,3,0,0,0,0,0,0,0,0,0,0
_comment dc.b "Db92-MiStub version",0
EVEN
_start:
move.l ($34).w,-(a7)
beq.s Nokernel
rts
NoKernel:
addq.l #4,a7
_main:

Je veux bien faire ça, mais ça ne va pas aller avec la version actuelle de ExePack. Il va falloir que j'utilise la version compatible kernel que j'ai en main (faite par ExtendeD et corrigée par moi) et qui n'est pas encore officiellement sortie.

Pas mauvaise idée PpHd

Je l'avais depuis longtemps, mais je ne suis pas vraiment fasciné par cette idée de programme hybride. C'est plus simple avec reloc2 et unreloc2 - je sais exactement ce qu'il y a comme hooks. Je me demande si je ne vais pas finir par reloger moi-même les programmes pour kernel (j'ai déjà une grande partie des routines nécessaires en main, mais on n'y est pas encore - quand ça sera fini, on pourra lancer les programmes pour kernel avec un lanceur style ttstart). Mais avec le programme hybride ("mistub" comme l'appelle PpHd), on peut déboguer les programmes kernel compressés sans trop de problèmes. Mais je sens que ça va planter si on essaye de déboguer un programme pour kernel sans kernel, parce que le breakpoint qui initialise tout ne sera jamais atteint.

Moi, j'avais une autre idée: si tu mettais une variable globale dans la table des vecteurs qui, si je la mets à 1, fera que PreOS n'installeras pas ses hooks au lancement d'un programme pour kernel? Il y aura à mettre le traîtement de ça en plus de reloc2/unreloc2, mais pas de stub bizarre.
[edit]Edité par Kevin Kofler le 02-01-2002 à 17:33:19[/edit]

Pas mal

Mais je ne sais pas si je finirai ça (le lanceur émulateur de kernel), parce que c'est compliqué avec les libs (pour l'instant, ça ne marche que sans librairies dynamiques - je n'avais pas du tout décidé quoi en faire: les reloger au besoin, les linker statiquement, les réécrire pour être statiques facilement, ... - , et ce n'est pas fini du tout - c'était prévu pour un format issu d'un convertisseur que j'avais à peine commencé, et il n'y a rien du tout pour le dérelogement - je prévoyais mettre les routines d'émulation de kernel dans le programme et de compresser ce dernier avec ExePack pour être sûr que la version relogée est à jeter, tout ça dans le convertisseur - c'était en fait un projet de convertisseur kernel->_nostub), qu'il y a plein de problèmes (programmes kernel compressés, programmes qui appellent une routine en dehors de l'espace d'exécution du programme sans rajouter $40000, ...), et que ça ne ferait que rendre plus populaire un format stupide, compliqué et inefficace. C'est pour ça que j'avais abandonné le projet. Mais j'ai réutilisé une partie de ses routines de recherche des RAM_CALLS pour DB92 _nostub.
[edit]Edité par Kevin Kofler le 02-01-2002 à 17:42:54[/edit]

Bref, disons que je retiens toujours que la solution la plus simple est que le kernel exporte ses fonctions de relogement, comme il est d'ailleurs prévu dans la spécification. (Cf. kernel.txt dans la documentation de DoorsOS.) Pour moi, tout kernel ne supportant pas ces fonctions est à considérer bogué.

Et puis le stub de PpHd n'est pas compatible avec KerNO (ça va me donner un beau "KerNO does not support DoorsOS programs" si j'essaye de lancer DB92 avec KerNO ...) Mais bon, ça s'arrange (un cmp et un beq de plus et ça marche).
[edit]Edité par Kevin Kofler le 02-01-2002 à 17:58:11[/edit]

Pour l'histoire du stub de Kerno, c'est tant pis pour lui si ca routine d'execution en fait rien !
>Mais je sens que ça va planter si on essaye de déboguer un programme pour kernel sans kernel, parce que le breakpoint qui initialise tout ne sera jamais atteint.
Non, ca va faire un rts de suite, sans d'autres pb je pense.
>si tu mettais une variable globale dans la table des vecteurs qui, si je la mets à 1, fera que PreOS n'installeras pas ses hooks au lancement d'un programme pour kernel? Il y aura à mettre le traîtement de ça en plus de reloc2/unreloc2, mais pas de stub bizarre.
Et si par enchantement elle trainait (i.e. un programme l'a mise), ca ferait n'importe quoi.
Et ma solution est la plus simple a mon humble avis.
Tu n'as qu'a mettre le breakpoint tout le temps sur la premiere instruction.
qu'importe.
Le bsr envoies a un endroit, ou trois lignes plus bas, on accede au _main.

Non, je t'assure que ça va planter s'il n'y a pas de kernel (ou s'il y a KerNO). Mais je peux détecter ces conditions quand j'ai un programme pour kernel devant moi. Mais ça ne me dit toujours pas pourquoi tu ne veux pas mettre 2 fonctions qui font partie d'un jeu de 4 fonctions demandées dans les spécifications.
[edit]Edité par Kevin Kofler le 02-01-2002 à 21:25:34[/edit]

Parce qu'elle ne devrait pas y etre a mon avis. Et ma methode marche avec unios aussi.

Bon, je vais voir ce que ça donne en programme hybride, mais pas avant la sortie officielle de l'ExePack compatible kernel (celui qui fonctionne - celui sorti par ExtendeD n'était pas adapté à la version de TIGCC qu'il a utilisée pour le compiler).

Et pour l'alpha, elle est renvoyée d'un jour parce que j'attends la réponse d'ExtendeD à mes mails au sujet de ses corrections.

Au fait, le nouveau lanceur ExePack est déjà dans la version de TIGCC du 1er janvier. Mais je ne veux quand-même pas faire du mistub, parce qu'on ne pourra pas déboguer grand chose avec Universal OS et sa double recopie en RAM si je le mets.

Et j'ai retiré la protection du trap 11 pour le moment, et elle ne sera dans la prochaine alpha que si ExtendeD la répare très vite... (Il ne répond même pas en ce moment. J'ai déjà fait des corrections, mais il reste toujours des problèmes.) Donc ne déboguez pas enter_ghost_space ou les fonctions EM_* étape par étape ou avec un point d'arrêt en ROM, ça ne marchera pas. (Ça ne marchait pas mieux avec les protections à leur état actuel.)
[edit]Edité par Kevin Kofler le 04-01-2002 à 21:11:33[/edit]

J'avais sorti la 0.24 alpha pour un moment, mais en fait il y a des trucs qui ne marchent toujours pas et j'ai donc changé d'avis et remis la 0.23. (Les "corrections" de ExtendeD ne marchent pas du tout. )
[edit]Edité par Kevin Kofler le 04-01-2002 à 23:44:21[/edit]

J'ai corrigé ce qui m'énervait le plus (les nouvelles combinaisons de touches ne marchaient pas si le programme à déboguer était actif), mais j'attends quand-même demain pour sortir la nouvelle alpha. Peut-être que ExtendeD aura aussi répondu à mes mails entretemps.
[edit]Edité par Kevin Kofler le 04-01-2002 à 23:59:33[/edit]

J'ai implemente le (un)reloc(2) dans Preos. Ainsi que le Hot Reboot (Rebootage a chand sans pertes des handles). Il me reste le SHIFT+ON.

et les gris parfait, il y sont ?!
et l'acceleration materiel par le biais du soft aussi ?!

>misato: et les gris parfait, il y sont ?!

1. Prends graphlib de DoorsOS.
2. Remplace la routine graphlib::gray4 par:

 movem.l d1-d2/a0-a1,-(a7)
 bsr GrayOn
 movem.l (a7)+,d1-d2/a0-a1
 move.l __D_PLANE(PC),plane0
 move.l __L_PLANE(PC),plane1
 rts

3. Remplace la routine graphlib::gray2 par:

 movem.l d1-d2/a0-a1,-(a7)
 bsr GrayOff
 movem.l (a7)+,d1-d2/a0-a1
 moveq.l #0,d0
 rts

4. Compile tout ça avec tigcc.exe de TIGCC 0.93.

À priori, cela devrait suffir pour avoir les "gris parfaits" avec un kernel autre que Universal OS. Je ne garantis pas que ça marchera. Je peux avoir fait une erreur.

On pourra avoir la beta avant demain 18h? siouplé (pour ceux qui partent le dimanche soir et n'ont pas d'ordis la semaine...

arf... toujours po le shift+ON
PpHd> si tu peux m'envoyer une bêta avant dimanche milieu d'après-midi

Moi aussi, je la veux la beta avec (un)reloc(2), pour pouvoir tester le débogage de programmes pour kernel avec DB92 _nostub.
[edit]Edité par Kevin Kofler le 05-01-2002 à 23:46:24[/edit]

Houla, Kevin qui demande une bêta d'un Kernel !!!
PpHd> je n'aurai jamais pensé que ce jour arriverai


(kevin> je précise que ce n'est nullement méchant)

Parlant d'alphas et de bêtas, mais revenant au sujet (): J'en ai eu assez d'attendre et j'ai sorti une nouvelle alpha de DB92, la tant attendue 0.24 alpha.
Nouveautés:
- débogue correctement l'instruction RTE maintenant (merci à ExtendeD)
- débogue correctement les appels de traps maintenant (merci à ExtendeD)
- correction de ON+ESC sur TI-89, ajout de DIAMOND+ON pour éteindre et 2nd+GAUCHE+DROITE+ON (TI-89) ou 2nd+MAIN+ON (TI-92+) pour réinitialiser (reset) (merci en partie à ExtendeD)
- attend que la touche soit lâchée avant d'initier une action pour éviter que le programme à déboguer reçoive l'appui de touche
- correction de quelques bogues concernant la touche F2
- nettoyage de la source et des commentaires (traduction de ces derniers en anglais)
- trouve maintenant la petite fonte sur VTI (mais il n'existe toujours aucune version de VTI avec laquelle DB92 marche à 100
Mais attention:
- Le débogage des traps et des RTE n'est toujours pas parfait. Notamment, TI-Chess plante toujours si on utilise [F5] ou [r] après l'avoir arrêté avec [ON]+[ESC]. (C'est probablement un problème avec les RTE.)
- Il n'y a toujours pas de protection du trap 11 parce qu'elle ne marche pas correctement et que ExtendeD ne répond pas à mes mails. (Il doit être parti en vacances.)
- Phoenix plante toujours si on débogue étape par étape ou avec un point d'arrêt en ROM les 2 endroits où il modifie le vecteur Trace.
- J'espère qu'il n'y a pas de nouveaux bogues. Si vous en trouvez, n'hésitez pas à me les reporter ici ou par mail.

Pour la télécharger, c'est ici. (Je vous rappelle que c'est une alpha et que vous ne devez pas vous attendre une stabilité géniale. Je me demande d'ailleurs pourquoi hwti a retiré la désignation "bêta" de sa version: la plupart de ces bogues concernent aussi la version kernel, et donc "bêta" était déjà un euphémisme...)
[edit]Edité par Kevin Kofler le 06-01-2002 à 01:08:59[/edit]

>misato:et les gris parfait, il y sont ?!
Ca depend de la sous-version du HW2. Y'a meme certains HW2 sur lesquelles le gray7 marche convenablement
Disons que ca devrait etre bon. Demain la beta a tous.

cool