nouvelle version de DB92 - Page 2

PpHd > quand est-ce qu'on aura la nouvelle version (comme le site de la t3 est down) ?

j'ai créé un nouveau programme : http://membres.lycos.fr/hwti/hsf2RC.zip. Il permet de créer os.h, doorsos.h et romcalls.bin de DB92 à partir des sources de l'aide de TIGCC (Kevin si tu veux l'inclure dans TIGCC pas de problème)

Mauvais lien

Le bon est :
http://membres.lycos.fr/hwti/hsf2RC.zip

hwti: Des que j'aurais dixe les derniers bugs reports

nouvelle version http://membres.lycos.fr/hwti/db92-nostub-alpha-032.zip

Sympa

Attention, je vois 2 erreurs dans Display.h.

1.

	cmp.w	#2000,d0
	bgt	HandleNotFound

Le test devrait être d0>=2000, pas d0>2000, vu que le dernier handle est le n°1999 (il y en a 2000 en tout). Et puis, je pense qu'un test non signé est plus adapté. Remplace bgt par bcc.
2.

	cmp.l	#"68kP",6(a0)
	bne	kernel
		;_nostub symbolic info

Le test est à l'envers. Remplace bne par beq.

Mais à part ça: excellent travail!

Sinon:
- Le tree.inc est faux. ExtendeD l'avait corrigé à la main, il ne fallait pas le regénérer avec treemk.
C'était cette entrée de l'historique:
débogue correctement les appels de traps maintenant (merci à ExtendeD)
Maintenant, ça ne marchera plus. Il faut reprendre la version de tree.inc d'une des versions 0.24-0.31.
- Ton programme hsf2RC génère fadd etc. à la place de bcdadd etc. Il faut trouver un moyen d'empêcher ça, parce que c'est faux. Surtout pour OS.h/doorsos.h. D'ailleurs hsf2RC devrait être livré avec DB92, puisque ça fait partie des sources.

je vais voir pour tous les problèmes.
pour fadd et bcdadd dans la doc de tigcc, fadd est défini comme ROM_CALL et bcdadd comme macro

je pense que ce serait mieux d'inclure hsf2RC dans les sources de tigcc car il permet de générer OS.h et doorsos.h qui n'ont rien à voir avec DB92 et abec DB92 il n'aurait pas d'intérêt car il faudrait les sources de tigcc

pour tree.inc c'est parce que Extended n'avait modifié qu'un seul des 2 fichiers je pense, mais même si tree.inc est faux DB92 est bon (on ne peut pas le recompiler, c'est tout). Tout cela sera corrigé demain. Je vais voir pour que si on régénère le fichier ce soit bon.
Je vais aussi m'occuper s'une version on-calc de autosymb

Autre bug mineur dans 'db92.asm':

au label "Menu1_None" il faut rajouter "clr.w ROMCalls+WinOpenU" avant le rts.

Sans ça, il y aura un bug d'affichage!

Pour admirer le bug: activez le menu (touche APPS sur 89) et sélectionnez 'ROM Calls' pour la fenêtre du bas. Maintenant, selectionnez 'none' pour la fenêtre du bas. Pas très joli tout de même

hwti
a écrit : (on ne peut pas le recompiler, c'est tout)

Si c'est le cas, tu es en violation de la GPL. À corriger le plus vite possible!

c à dire C qui a fait une connerie?

c'est parce que j'ai eu un problème avec le zip ce matin (CRC dans tree.inc) donc j'ai remplacé par l'autre. Dans l'état actuel, si on recompile DB92, un jump over au desus d'un trap ne marchera pas

C a dire si je recompile DB92 0.32 avec TIGCC, ca va pô marcher
Poutant je l'ai fait et ca marche trés bien

Je ne voit pas le problème avec ce tree.inc

si ça va marcher, mais les trap ne seront plus reconnus comme des bsr, donc un jump over (F8 ou catalog) au dessus rentrera dedans.

les corrections sont faites (tree.inc est modifié avec treemk)
même adresse de téléchargement

C toujours à la même adresse qu'on peut le téléchager?

Pour autosymb on-calc :
Est-ce qu'il y a des équivalents dans TIGCC des fonctions de chaînes de caractère qui sont en ROM_CALL ? (éventuellement pour la rapidité, actuellement je ne pense pas que ce sera nécessaire)
Est-ce qu'il y a un équivalent de strnicmp (non présent en ROM_CALL) ?

Quelle est la meilleure solution pour le nom du fichier de sortie (on n'a pas d'extension .sdb sur calc) ?


Pour treemk (en C/C++ sur PC) : il y a des fonctions (gotoXY, textcolor, ...) que je n'ai ni dans VC++, ni dans MinGW32. Comment les avoir ?

hwti
a écrit : Pour treemk (en C/C++ sur PC) : il y a des fonctions (gotoXY, textcolor, ...) que je n'ai ni dans VC++, ni dans MinGW32. Comment les avoir ?

Ce sont des fonctions DOS. Une solution est donc d'utiliser DJGPP.
Alternative: conio.h pour MinGW32. (C'est plus complet que la version livrée avec MinGW32. En particulier, gotoxy et textcolor y sont. Certaines fonctions manquent encore, mais je ne sais pas si tu auras besoin des fonctions manquantes - si c'est le cas, tu devras utiliser DJGPP. Et il y a de bonnes chances que ça fonctionne aussi avec M$VC.)

Si tu fait une version on-calc (pour une utilisation avec AS) de autosymb, il faudra que le compilo le reconnaisse Donc, en sortie, faut pas aller chercher bien loin, il faut mettre les modifications dans la source asm directement.
Du style: autosymb("monrepmasource")

Parce que je ne sait pas si AS permet d'include un fichier contenant du code.
Enfin, a toi de voir.

Dernière chose, AS ne reconnait pas le '-*' a la fin des déclarations de type:
dc.w nom_label-*

Bonne chance

J'ai fait quelques tests et apparement, ça pourrai marcher

on peut inclure un fichier annexe avec un include. Le mieux serait donc de demander à l'utilisateur ou mettre le fichier de sortie:
autosymb("fichier_source","fichier_de_sortie")

Donc, rectification, il faut aussi allez voir les includes pour la recherche de labels et de variables.

Dans l'ensemble, il n'y a pas de grosse difficulter à le transcrire. Le seul problème pourrai venir de list.cpp et list.h, car ce sont des sortent de macros et il faudrai tout reprogrammer.

pour list.cpp et list.h, c'est déja fait, autosymb est maintenant en C. (c'est plus rapide qu'avant, ce qui est bien pour la TI)
le seul truc qui me pose problème est l'absence de strnicmp (soit je dois programmer une fonction, soit on impose les minuscules pour dc, ds et autres)

Peut-on faire un redimensionnement (HeapRealloc) sans que le TIOS fasse memmove (pour que je le fasse moi-même, ce serait plus rapide) ?

Dernière chose: dans BD92, il est fait référence à deux erreurs: "PC odd" et "Odd Adress". Ca signifie koi en francais compréhensible

En fait, 'strnicmp' correspond à 'strncmp' mais ne respecte pas les majuscules/minuscules.....

Faudrai que tu fasse ta propre fonction:
1. Tu recupère la ligne et tu la met dans un buffer
2. Tu la met en minuscule (faudrai tester tous les caractère et si compris entre 65 et 90 (en décimal, correspond à A...Z) tu fait +32 (ca le met en p'tit)
3. Tu fait un appel a 'strncmp'

"PC odd" c'est pour si PC est impair (par exemple si tu le modifie dans la fenêtre des registres).
"Odd Address" je sais plus de mémoire.

pour strnicmp j'avais déja pensé à ce que tu as mis, mais quitte à faire ça, autant faire une fonction en assembleur qui sera beaucoup plus rapide sans la nécessité d'utiliser un buffer)

hwti
a écrit : pour list.cpp et list.h, c'est déja fait, autosymb est maintenant en C. (c'est plus rapide qu'avant, ce qui est bien pour la TI)

OK.

le seul truc qui me pose problème est l'absence de strnicmp (soit je dois programmer une fonction, soit on impose les minuscules pour dc, ds et autres)

Et si tu implémentais strnicmp en termes de cmpstri (en mettant un '' temporaire et en remettant l'octet d'origine après)?

Peut-on faire un redimensionnement (HeapRealloc) sans que le TIOS fasse memmove (pour que je le fasse moi-même, ce serait plus rapide) ?

Non.

hwti a écrit :
"PC odd" c'est pour si PC est impair (par exemple si tu le modifie dans la fenêtre des registres). "Odd Address" je sais plus de mémoire.

Je suppose que c'est quand on veut aller à une adresse impaire dans la fenêtre du code. Mais je dis ça sans regarder la source, donc peut-être que c'est faux.

Kevin #56 >> Et si tu implémentais strnicmp en termes de cmpstri (en mettant un '' temporaire et en remettant l'octet d'origine après) ?

Beuuuuuuurrrrrrkkkk

En effet...
Mais s'il saît que les chaînes sont en RAM (pas en ROM) et que l'octet qu'il remplace est toujours dans le buffer (pas au-delà), ça peut passer.