Un newbies de Plus (^_^) - Page 5

Si ca marche tant mieux. Reste a que je sache pkoi. J'ai trop mal a la tete pour ca.

-

Trap c'ést plus ou moins comme int. Mais ca sert a praitquement que dalle.
Sauf la trap 12 et la trap 11 (et la trap 4 et la trap 0).
Oups, ca fait beaucoup
Non, sauf cas extremes, contente toi des rom-calls.
PS: Y'á pas de bios sur 89 et trap ne fait qu'áppeller une routine a une adresse determinee.

-

Ben trap 12 c'est pour passer en mode superviseur.
Le trap 11 c'ést pour hw2tsr

Et pour le fade down utilise plutot OSContrastDown et OSContrastUp.

LE trap #9 est un reste de la ti-92.

-

C'est ca.
Le move te permets de selectionner le numero de la fonction, le trap d'avoir l'adresse de la fonction, le jsr d'appeller la fonction.

-

PpHd
a écrit : Tu compiles avec : tigcc genscr16.c gendat.asm ?

Vérifie qu'il y a section ".data" au début de gendat.asm. Si ce n'est pas le cas, rajoute-le.
Non seulement s'agit-il de données, mais aussi tout doit être dans la section ".data" pour TIGCC, pour une raison simple: le code compilé par GCC ne peut accéder aux données en PC-relatif que s'il est dans la même section que celles-ci.

C'est pas une raison valable.

PpHd a écrit :
copy preos/include/* tigcc/include/asm

Tu sais très bien que je ne peux pas reprendre tes includes à la lettre parce que le linker n'est pas le même. Par exemple, on ne peut pas mettre _readonly parce que Obj2ti ne comprend pas. On doit mettre:

_flag_3
_readonly equ _flag_3

JM avait fixé ce format (et il en avait parlé sur ce forum), mais tu as préféré faire n'importe quoi pour MakePrgm.

Et puis, nous avons des nécessités de compatibilité que tu n'as pas. Avec le nombre de programmes qui utilisent doorsos.h, on ne peut pas se permettre de ne pas inclure un fichier doorsos.h avec des déclarations en doorsos::. D'ailleurs, tu nous rends le travail assez pénible avec tes headers compatibles seulement à 90% avec les anciens. Par exemple, le suivant ne marchera pas avec ton OS.h alors que ça marchait avec l'ancien:

;attends 2 appuis de touches
 ROM_CALL ngetchx
 jsr (a4)

tout ceci parce que tu as changé le registre utilisé pour les ROM_CALLs.
Il fallait mettre (ce que je vais probablement faire pour TIGCC):

 ifnd ROM_CALL_reg
ROM_CALL_reg equr a4 ;compatibilité
 endc

et utiliser ROM_CALL_reg dans la macro ROM_CALL. Comme ça, si on veut utiliser a0, on met:

ROM_CALL_reg equr a0
 include "OS.h"

Sinon, ROM_CALL2 devrait toujours utiliser a4, et ROM_PTR devrait utiliser ROM_PTR_reg, qui serait mis à a0 par défaut.
La raison pourquoi tout ceci nous rend le travail pénible est qu'il y a 2 jeux de headers incompatibles, et qu'on ne sait pas avec lesquels être compatibles. Moi, je suis pour la compatibilité avec les sources existantes. Mais quand il y aura plein de sources assemblées avec tes headers non-standard, on risque de finir par devoir mettre des ifd _preos_compat de partout et de mettre dans la documentation de mettre d'utiliser -v_preos_compat pour compiler des programmes prévus pour tes headers.

PpHd
a écrit : C'est pas une raison valable.

Si.
Et puis gendat.asm est un fichier de données, donc il doit de toute façon être dans .data!!!
Si ça marchait autrement avant, c'est parce que link.exe ne combinait pas les sections entre fichiers. GNU ld le fait.

-

Ah pardon PpHd, tu as quand-même pris le soin de renommer OS.h. Ça nous rendra la tâche un peu moins difficile. Merci.

Et il vaut mieux prendre les includes de TIGCC, qui sont compatibles à 100% avec Obj2ti, alors que ceux de PpHd contiennent des trucs du style _mistub (non supporté) ou _readonly (qui devrait être _flag_3, cf. ci-dessus).
Et les paquets d'includes sont tous les 2 "axés" à la fois kernel et _nostub.
Ceci dit, il y aura bientôt un tios.h qui permettra d'assembler les programmes faits pour les includes de PreOs qui sera livré avec une version future de TIGCC. (Je vais m'en occuper.)

-

En effet.

Mais pourquoi veux-tu programmer en kernel? À quoi sert une librairie dynamique qui contient juste 2 petites fonctions?! Il vaut beaucoup mieux les inclure dans ton programme!

(Et lis aussi ce que j'ai rajouté au message 134 en l'éditant.)

-

Kevin Kofler a écrit :
Tu sais très bien que je ne peux pas reprendre tes includes à la lettre parce que le linker n'est pas le même. Par exemple, on ne peut pas mettre _readonly parce que Obj2ti ne comprend pas. On doit mettre:

_flag_3
_readonly equ _flag_3

JM avait fixé ce format (et il en avait parlé sur ce forum), mais tu as préféré faire n'importe quoi pour MakePrgm.

Je ne m'en suis servi nulle part dans le linker, car aucune lib standard n ést en readonly. Et tu sais mon opinion sur les standards de JM (Une petite lacune de docs).

Et puis, nous avons des nécessités de compatibilité que tu n'as pas. Avec le nombre de programmes qui utilisent doorsos.h, on ne peut pas se permettre de ne pas inclure un fichier doorsos.h avec des déclarations en doorsos::. D'ailleurs, tu nous rends le travail assez pénible avec tes headers compatibles seulement à 90% avec les anciens. Par exemple, le suivant ne marchera pas avec ton OS.h alors que ça marchait avec l'ancien:

;attends 2 appuis de touches
 ROM_CALL ngetchx
 jsr (a4)

tout ceci parce que tu as changé le registre utilisé pour les ROM_CALLs.
Il fallait mettre (ce que je vais probablement faire pour TIGCC):

 ifnd ROM_CALL_reg
ROM_CALL_reg equr a4 ;compatibilité
 endc

et utiliser ROM_CALL_reg dans la macro ROM_CALL. Comme ça, si on veut utiliser a0, on met:

ROM_CALL_reg equr a0
 include "OS.h"

Sinon, ROM_CALL2 devrait toujours utiliser a4, et ROM_PTR devrait utiliser ROM_PTR_reg, qui serait mis à a0 par défaut.
La raison pourquoi tout ceci nous rend le travail pénible est qu'il y a 2 jeux de headers incompatibles, et qu'on ne sait pas avec lesquels être compatibles. Moi, je suis pour la compatibilité avec les sources existantes. Mais quand il y aura plein de sources assemblées avec tes headers non-standard, on risque de finir par devoir mettre des ifd _preos_compat de partout et de mettre dans la documentation de mettre d'utiliser -v_preos_compat pour compiler des programmes prévus pour tes headers.

Y'a deux jeux de fichiers includes ;
tios.h / romcalls.h -> comaptibile preos
doorsos.h / os.h -> Les memes qu'avant sans changement
tu vois que je suis pour la compatibilite

Et ROM_CALL2 utilise toujours a4, et ROM_PTR a0, c'est leur seule difference.
Et je signales que je n'ai jamais utilise doorsos.h, trop lourd a utiliser

Et puis gendat.asm est un fichier de données, donc il doit de toute façon être dans .data!!!
Si ça marchait autrement avant, c'est parce que link.exe ne combinait pas les sections entre fichiers. GNU ld le fait.

Ben j'ai compile avec la 0.94 comme ca et ca marchait pourtant. Explications ?

Et il vaut mieux prendre les includes de TIGCC, qui sont compatibles à 100% avec Obj2ti, alors que ceux de PpHd contiennent des trucs du style _mistub (non supporté) ou _readonly (qui devrait être _flag_3, cf. ci-dessus).

Ils n'en contiennent aucun !!!
Si juste une ligne
_mistub quelque part. Mais ca passe avec obj2ti.

Et les paquets d'includes sont tous les 2 "axés" à la fois kernel et _nostub.
Ceci dit, il y aura bientôt un tios.h qui permettra d'assembler les programmes faits pour les includes de PreOs qui sera livré avec une version future de TIGCC. (Je vais m'en occuper.)

Non
-> tios.h : mode kernel
-> RomCall.h : mode nostub.
-> include "tios.h'/n include 'romcalls.h'-> Mode mistub.

Et je parlais essentiellement des autres headers avec le numero de version !

>>Orion: Ton source

include "tios.h"
include "orionlib.h"
xdef _ti89
xdef _main
xdef _comment
_main:
jsr orionlib::fadedown
jsr tios::ngetchx
jsr orionlib::fadeup
rts
_comment: dc.b "Power by OrionSoft",0

Et il vaut mieux mettre les include de preos. Perso de toute facon les include de tigcc sont toujours ecrase par ceux de preos Donc t'inquietes pas cote compatibilite, ca roule.

Ceci dit, il y aura bientôt un tios.h qui permettra d'assembler les programmes faits pour les includes de PreOs qui sera livré avec une version future de TIGCC. (Je vais m'en occuper.)

Et les autres libs ? Et le mode mistub il sera supprote ?

-

_comment sert a definir le commentaire affiche dans les explorateurs.

les kernels c bien ,c même trés bien je trouve
sa permet de moins s'embetter avec les macro call
la sauvegarde de registre, etc...

100% d'accord. Et tu as une meilleure protection anti-crash. Par exemple, Preos evite la perte de memoire des programmes kernels, l'oublie d'appels a ER_catch, et bientot aussi la non-fermeture des fenetres

le seul truc que je suis pas d'accord c les jeux qui demande 10 librairies avant de pouvoir fonctionner , c pour sa que j'ai essayer de faire ma propre lib
ainsi, lorsque (plus tard) je ferais un jeu, ben au lieux
d'utiliser que 2 ou 3 fonctions de 4 ou 5 lib
ben je regrouperais ces fonctions dans une seule et unique lib
en adaptant les routines a mes besoins
ainsi, on aura besoin que d'une seul et unique lib (au lieux de plusieurs)
et le poids total sera diminuer car j'utiliserait seulement
les fonctions que j'aurais besoins

T'ás compris l'interet des libs, c'ést bien

>Orion:

>sa sert a rien, pour l'instant, c t juste pour savoir et comprendre comment
>fonctionnait les librairies, sa me servira pour plus tard

Ça ne te servira à rien, crois-moi.

>de plus si je fait du nostub
>je peu pas utiliser les librairies et je suis obliger de tout coder moi même

Connais-tu:
- les ROM_CALLs?
- les librairies statiques?
Par exemple, toutes les fonctions qui sont dans graphlib ont un équivalent exact soit dans la ROM, soit dans TIGCCLIB. Et mon tutorial explique comment utiliser les fonctions de TIGCCLIB. Cf. section V, en particulier V.2. C'est très facile en plus!

>en plus je voit pas kes que ta contre les kernels
>les kernels c bien ,c même trés bien je trouve
>sa permet de moins s'embetter avec les macro call

LOL, tu trouves que jsr doorsos:creenClear ou jsr tios:creenClear est plus simple que call ScreenClear ou ROM_CALL ScreenClear? Moi, je ne trouve pas que c'est le cas.
Et puis, jsr tios:creenClear prend 8 à 10 octets!!! (10 pour le premier appel, 8 pour tout appel successif au même ROM_CALL.) Alors que:

 move.l ScreenClear*4(a5),a0
 jsr (a0)

prend 6 octets seulement. (Ça me fait penser à ce qu'on devrait mettre une option OPTIMIZE_ROM_CALLS dans OS.h. Je vais m'en occuper quand je mettrai à jour les headers.)

>la sauvegarde de registre, etc...

LOL, parce que c'est dur de faire un movem.l d3-d7/a2-a6,-(a7) au début et un movem.l (a7)+,d3-d7/a2-a6 à la fin...
Et prends mon tutorial, il y a même le code pour la sauvegarde de l'écran prêt à être copié et collé. (Ça me fait penser à ce qu'on devrait mettre une option SAVE_SCREEN dans OS.h. Je vais m'en occuper quand je mettrai à jour les headers.)

>le seul truc que je suis pas d'accord c les jeux qui demande 10 librairies avant de pouvoir
>fonctionner , c pour sa que j'ai essayer de faire ma propre lib
>ainsi, lorsque (plus tard) je ferais un jeu, ben au lieux
>d'utiliser que 2 ou 3 fonctions de 4 ou 5 lib
>ben je regrouperais ces fonctions dans une seule et unique lib
>en adaptant les routines a mes besoins
>ainsi, on aura besoin que d'une seul et unique lib (au lieux de plusieurs)
>et le poids total sera diminuer car j'utiliserait seulement
>les fonctions que j'aurais besoins

N'importe quoi!!! Si tout le monde fait comme toi, au lieu d'avoir 4 ou 5 librairies dynamiques, on en aura une dizaine: une par auteur! C'est vraiment la pire des choses que tu peux faire!!!
Si tu ne veux pas utiliser trop de librairies dynamiques, fais-en une statique!!! C'est facile de faire une librairie statique avec A68k avec TIGCC. Et je peux t'aider avec ça si tu n'y arrives vraiment pas.

-

LOL, parce que c'est dur de faire un moveq.l d3-d7/a2-a6,-(a7) au début et un moveq.l (a7)+,d3-d7/a2-a6 à la fin...

moveq LOL

Et prends mon tutorial, il y a même le code pour la sauvegarde de l'écran prêt à être copié et collé. (Ça me fait penser à ce qu'on devrait mettre une option SAVE_SCREEN dans OS.h. Je vais m'en occuper quand je mettrai à jour les headers.)

Ben y 'a PUSH_LCDMEM et POP_LCDMEM dans RomCalls.h
Y'a aussi FAST_ROM_CALL

move.l ScreenClear*4(a5),a0
jsr (a0)
prend 6 octets seulement. (Ça me fait penser à ce qu'on devrait mettre une option OPTIMIZE_ROM_CALLS dans OS.h. Je vais m'en occuper quand je mettrai à jour les headers.)

MAIS: 1. Necessite un registre different de d0-d2/a0-a1
2. Ce registre doit etre restaurer
3. Ce registre doit etre charger.

Par exemple, toutes les fonctions qui sont dans graphlib ont un équivalent exact soit dans la ROM, soit dans TIGCCLIB. Et mon tutorial explique comment utiliser les fonctions de TIGCCLIB. Cf. section V, en particulier V.2. C'est très facile en plus!

Et api92 et shrnklib et genlib et ugplib et fargray et graphlib::gray7, elles y sont dans la ROM ?

LOL, tu trouves que jsr doorsos:creenClear ou jsr tios:creenClear est plus simple que call ScreenClear ou ROM_CALL ScreenClear? Moi, je ne trouve pas que c'est le cas.
Et puis, jsr tios:creenClear prend 8 à 10 octets!!! (10 pour le premier appel, 8 pour tout appel successif au même ROM_CALL.)

Surtout que dans os.h, ROM_CALL detruit a4 sans te le dire.
Heureusement que romcalls.h corrige ca. C'ést mieux pour faire des nostub

N'importe quoi!!! Si tout le monde fait comme toi, au lieu d'avoir 4 ou 5 librairies dynamiques, on en aura une dizaine: une par auteur! C'est vraiment la pire des choses que tu peux faire!!!
Si tu ne veux pas utiliser trop de librairies dynamiques, fais-en une statique!!! C'est facile de faire une librairie statique avec A68k avec TIGCC. Et je peux t'aider avec ça si tu n'y arrives vraiment pas.

On a encore de la marge. Et c'ést pas si grave.

ZipLib n'est ni dnas la ROM ni dans la TIGCCLIB...
la première fois que j'ai utilisé de" l'ASM, ct pour ZipLib...

Et tout savoir est chose utile...

Kevin Kofler a écrit :
LOL, tu trouves que jsr doorsos:creenClear ou jsr tios:creenClear est plus simple que call ScreenClear ou ROM_CALL ScreenClear? Moi, je ne trouve pas que c'est le cas.

En plus, en kernel on peut dire que preos est indispensable. et utiliser ROM_THROW (utilisable en nostub certes aussi, mais sur AMS 2.04 et superieure): 2 octets.
meme sur AMS 1.0x

pour la compatibiliét, mieux vaut utiliser les appels normaux...

Ou AMS 2.05. M'enfin bref que ce soit en kernel ou en nostub, mieux vaut les headers de preos.