fichiers externes - Page 2

merci
en fait pour l'include ca devrai aller si je decompresse dans le fichier externe (parce que la ce sera bon il le trouvera )

il ya une autre solution c'est de faire un fichier avec l'extension personnalisé et dans ton executable tu cree une table d'offset de donné par rapport au debut du fichier!
par exemple la map1 commence en 0
la map2 commence en 1768 et comme ca tu aditionne ton pointeur de debut de fichier avec l'offset pour obtenir la map!
c'est un peu barbare mais ca marche bien (pokered marche comme ca a l'epoque je connaissait pas les libs et je savais pas qu'on pouvait faire des lib en C )

C'est pas barbare, c'est une excellente méthode, utilisée très souvent !

toutes mes maps sont comme ça... a quelques détails près...

C'est même la méthode à utiliser.
Je répète que pour les données, il y a les fichiers de type personnalisé. On ne crée pas une librairie dynamique pour des données seulement!

je voit po pq
en plsu c plus simple alors ....

Pkoi ? Ca existe, c'est tres simple a utiliser, ca marche tres bien, ca verifie la version tou seul, ca le trouve tout seul, ou est le pb ?

meme raisonnement

bah... moi je trouve ça plus simple lol
je récup l'addr du début de mon fichier, je sais qu'au début il y a mettont une str, je saute o prochain 0, mettons qu'après j'aie des vars je transforme l'addr en addr paire, je sais exactement a kel addr les vars sont, je c a combien d'octets est le début de ma map, etc, etc, je vois pas ou est le pbl a faire ça non plus

-

Mais elles ne sont pas faites pour ça (même si PpHd a fait l'erreur d'encourager cet abus avec son flag stupide, inutile et non-portable _readonly).

"non-portable" ??? Tu peux t'expliquer ?

Ça ne marche qu'avec PreOs.

Kevin, peux-tu m'expliquer pourquoi tu encourages a utiliser des kernels qui sont depasses ?
Le plus fondamental des kernels, c'est de pouvoir evoluer commme on le desire, sans etre soumis a la rom, et de pouvoir mettre une couche d'abstraction entre le programme et la rom, ceci, afin d'assurer une bonne compatibilite.
Certes il y a du probleme, du a certains programmes. Mais ces programmes utilisent des methodes nostub (a savoir je me demerde pour trouver la bonne valeur)
pour acceder aux donnees. Or ces donnees ont change s de placs, ou sont invalides. Le kernel ne peut rien corriger.
La qualite propre de l'homme est de detourner les choses de leur usage d'origine pour en faire quelque chose qui lui convient.
Pouvoir acceder a des constantes sans aucun surcous de code, est pour moi une plus-value fondamentale.
Ensuite, kevin arrete de penser que obj2ti est bien. Pour les programmes assembleurs, makeprgm est bien. Compare juste les messages d'erreurs des 2 programmes : avec un, c'est quasi impossible de debogguer, avec l'autre, c'est la simplicite meme de comprendre d'ou vient l'erreur.

oui, la je suis d'accord... d'ailleurs je n'utilise que makeprgm...
mais bon ça change pas que mon système de maps me va très bien

PpHd
a écrit : Kevin, peux-tu m'expliquer pourquoi tu encourages a utiliser des kernels qui sont depasses ?

Je n'encourage pas à les utiliser, mais ce n'est pas une raison de créer des programmes incompatibles.

Le plus fondamental des kernels, c'est de pouvoir evoluer commme on le desire, sans etre soumis a la rom,

Qu'est-ce que vous avez tous contre AMS?

et de pouvoir mettre une couche d'abstraction entre le programme et la rom, ceci, afin d'assurer une bonne compatibilite.

Tu as oublié le préfixe "in-" devant "compatibilité".
Non, franchement, il n'y a aucune raison de rajouter une "couche d'abstraction", AMS a déjà un niveau d'abstraction suffisant.

Certes il y a du probleme, du a certains programmes. Mais ces programmes utilisent des methodes nostub (a savoir je me demerde pour trouver la bonne valeur) pour acceder aux donnees. Or ces donnees ont change s de placs, ou sont invalides. Le kernel ne peut rien corriger.

Ce ne sont pas des méthodes _nostub, ce sont des méthodes sales tout simplement (bon d'accord, mes TSRs ne sont pas exactement propres non plus ).
La méthode _nostub, c'est d'utiliser les ROM_CALLs au lieu d'aller traffiquer directement dans la RAM, avec ou sans RAM_CALLs.

La qualite propre de l'homme est de detourner les choses de leur usage d'origine pour en faire quelque chose qui lui convient. Pouvoir acceder a des constantes sans aucun surcous de code, est pour moi une plus-value fondamentale.

On peut accéder à des constantes si elles sont exportées. Si elles ne sont pas exportées, il y a une raison (cf. ma réponse précédente). Et AMS 2 exporte pratiquement toutes les adresses et variables données par les RAM_CALLs des kernels.

Ensuite, kevin arrete de penser que obj2ti est bien. Pour les programmes assembleurs, makeprgm est bien. Compare juste les messages d'erreurs des 2 programmes : avec un, c'est quasi impossible de debogguer, avec l'autre, c'est la simplicite meme de comprendre d'ou vient l'erreur.

J'ai toujours réussi à trouver d'où viennent les problèmes avec les messages d'erreur de Obj2ti. Et le jour où MakePrgm comprendra le COFF, on en reparlera.

"J'ai toujours réussi à trouver d'où viennent les problèmes avec les messages d'erreur de Obj2ti"

Mais toi tu es surdoué, Kevin, ne l'oublie pas...

Kevin Kofler
a écrit : Qu'est-ce que vous avez tous contre AMS?

c'est lent a chier

Tu as oublié le préfixe "in-" devant "compatibilité". Non, franchement, il n'y a aucune raison de rajouter une "couche d'abstraction", AMS a déjà un niveau d'abstraction suffisant.

non, ça c'est selon TON raisonnement, comme quoi ams c le paradis...

Ce ne sont pas des méthodes _nostub, ce sont des méthodes sales tout simplement (bon d'accord, mes TSRs ne sont pas exactement propres non plus ).
La méthode _nostub, c'est d'utiliser les ROM_CALLs au lieu d'aller traffiquer directement dans la RAM, avec ou sans RAM_CALLs.

c'est pas ça le problème... ça va toujours pour TON raisonnement comme quoi on devrait utiliser les ROM_CALLS pour TOUT! mais dans le cas ou on ne les utilise pas, un prog _nostub deviendra de plus en plus incompatible au fur et a mesure que les choses évolueront, alors que le kernel, tu le change, et les progs kernels, tu les laisse...
bien, sur rien n'est parfait, et je me demande combien de programmes kernels utilisent SCR_MEM a la place de TOUTES les occurences de $4c00... fin bon ça c un exemple con, ça m'étonnerait que Ti change l'addr de l'écran et si ils le font, bah de tte façon la plupart des jeux _nostub intéressants seront a changer aussi...

On peut accéder à des constantes si elles sont exportées. Si elles ne sont pas exportées, il y a une raison (cf. ma réponse précédente). Et AMS 2 exporte pratiquement toutes les adresses et variables données par les RAM_CALLs des kernels.

cf ma réponse précédente a moi aussi

J'ai toujours réussi à trouver d'où viennent les problèmes avec les messages d'erreur de Obj2ti. Et le jour où MakePrgm comprendra le COFF, on en reparlera.

heu, bon la je pense pas pouvoir répondre, je comprends pas ton abréviation COFF, tu parle de quoi au juste?

C'est le format des fichiers objet traîtés par GNU ld.

erf ok... heu quel intérêt pour compiler en asm avec a68k par exemple??

Kevin Kofler a écrit :
Je n'encourage pas à les utiliser, mais ce n'est pas une raison de créer des programmes incompatibles.

Les kernel ont toujourseu pour objectif une compatibilite ascendante.
Si un vieux kernel n'est pas capable de lancer des nouveaux programmes, il n'y a aucun probleme.

Non, franchement, il n'y a aucune raison de rajouter une "couche d'abstraction", AMS a déjà un niveau d'abstraction suffisant.

Avec la tigcclib, c'est vrai. Mais si on veut les faire tourner sur ti-92, comment on fait ?
Et je te signales aussi que ti a change pas mal de choses entre ams 1.0x et ams 2.0x.
Entre autres des rom_calls ont disparus...

Ce ne sont pas des méthodes _nostub, ce sont des méthodes sales tout simplement (bon d'accord, mes TSRs ne sont pas exactement propres non plus ).
La méthode _nostub, c'est d'utiliser les ROM_CALLs au lieu d'aller traffiquer directement dans la RAM, avec ou sans RAM_CALLs.

Non, c'est la methode je me dermerde pour avoir une variable que les rom_calls ne me donnent pas.

On peut accéder à des constantes si elles sont exportées. Si elles ne sont pas exportées, il y a une raison (cf. ma réponse précédente). Et AMS 2 exporte pratiquement toutes les adresses et variables données par les RAM_CALLs des kernels.

Et la compatibilite avec AMS 1.0x ? Et la fonte ? Et l'adresse de la table d'handles ?

J'ai toujours réussi à trouver d'où viennent les problèmes avec les messages d'erreur de Obj2ti. Et le jour où MakePrgm comprendra le COFF, on en reparlera.

Et bien tu es fort. Moi j'ai vraiment du mal parfois.
Ok, je sais que je dois rajouter le COFF (M'enfin je compte m'en sortir autrement) et l'utilisation de plusieurs fichiers objets

sBibi
a écrit : erf ok... heu quel intérêt pour compiler en asm avec a68k par exemple??

Qu'avec ld, on peut faire de la vraie compilation séparée au lieu d'utiliser de grosses saletés comme include "partie2.asm" qu'on voit dans à peu près toutes les sources.

PpHd a écrit :
Les kernel ont toujourseu pour objectif une compatibilite ascendante. Si un vieux kernel n'est pas capable de lancer des nouveaux programmes, il n'y a aucun probleme.

Si on peut avoir une compatibilité dans les 2 sens, pourquoi ne pas le faire?

Avec la tigcclib, c'est vrai. Mais si on veut les faire tourner sur ti-92, comment on fait ?

1. On ne supporte plus les calculatrices préhistoriques.
2. Je veux bien voir comment tu veux faire tourner Chrono sur TI-92. Non seulement il n'y a pas assez de mémoire, mais en plus tu utilises plein de trucs de PreOs qui n'existent pas dans Fargo.

Et je te signales aussi que ti a change pas mal de choses entre ams 1.0x et ams 2.0x. Entre autres des rom_calls ont disparus...

Ce n'étaient que des routines internes pour l'écriture en FlashROM. Personne ne les utilisait.

Non, c'est la methode je me dermerde pour avoir une variable que les rom_calls ne me donnent pas.

Mais non. Un programmeur _nostub utilisera HeapDeref au lieu d'aller traffiquer dans tios::Heap.

Et la compatibilite avec AMS 1.0x ?

Pourquoi est-il acceptable pour toi de n'être compatible qu'avec le kernel le plus récent, mais pas de n'être compatible qu'avec l'AMS le plus récent???

Et la fonte ?

DrawChar, c'est pour les chiens?
Et si vraiment on veut faire des trucs rapides, on utilise DrawChar dans un buffer et on dessine les caractères à partir de ce buffer.
Et puis il est très facile de trouver les fontes dans un programme, et si on le fait correctement, ça marchera même mieux que la RAM_CALL (ça sera compatible avec VTI).

Et l'adresse de la table d'handles ?

1. HeapDeref, c'est pour les chiens?
2. HeapTable est exporté par AMS 2: _rom_call_addr(1104).

Kevin Kofler a écrit :
Qu'avec ld, on peut faire de la vraie compilation séparée au lieu d'utiliser de grosses saletés comme include "partie2.asm" qu'on voit dans à peu près toutes les sources.

Ca permet d'optimiser les appels en bsr quand meme.

Si on peut avoir une compatibilité dans les 2 sens, pourquoi ne pas le faire?

Ah. Et comment faire ?

1. On ne supporte plus les calculatrices préhistoriques.

Elles ne sont pas prehistoriques du tout !

2. Je veux bien voir comment tu veux faire tourner Chrono sur TI-92. Non seulement il n'y a pas assez de mémoire, mais en plus tu utilises plein de trucs de PreOs qui n'existent pas dans Fargo.

Certes, mais la compatibilite avec des programmes seraient cool non ?

Ce n'étaient que des routines internes pour l'écriture en FlashROM. Personne ne les utilisait.

Ah. J'en connaissais qui les utilisait pourtant

Mais non. Un programmeur _nostub utilisera HeapDeref au lieu d'aller traffiquer dans tios::Heap.

C'est quand meme plus pratique en asm.

Pourquoi est-il acceptable pour toi de n'être compatible qu'avec le kernel le plus récent, mais pas de n'être compatible qu'avec l'AMS le plus récent???

Bonne question. Parce qu'un kernel c'est simple et rapide a changer, et moins dangereux (dans le pire cas on n'installe pas le kernel). Enfin, bon, si je trouve une vrai bonne raison je te le ferais savoir.

DrawChar, c'est pour les chiens?
Et si vraiment on veut faire des trucs rapides, on utilise DrawChar dans un buffer et on dessine les caractères à partir de ce buffer.

Ca bouffe de la RAM, deja que j'en manque

Et puis il est très facile de trouver les fontes dans un programme, et si on le fait correctement, ça marchera même mieux que la RAM_CALL (ça sera compatible avec VTI).

C'est Vti qui devrait rajouter une espece de boot code aux tib, plutot.

1. HeapDeref, c'est pour les chiens?
2. HeapTable est exporté par AMS 2: _rom_call_addr(1104).

A, je connaissais pas. Mais c'est pas compatible ams 1.0x

PpHd
a écrit : Ca permet d'optimiser les appels en bsr quand meme.

Tu peux aussi faire des bsr avec plusieurs fichiers objet. Les relogements PC-relatifs 16 bits sont supportés depuis longtemps par notre système de linking. Seul problème: si le bsr va à plus de 32 KO de distance (c'est la raison principale pour laquelle AS ne l'utilise pas pour les jbsr générés par GCC). Mais tu as le même problème avec les include "partie2.asm".

Ah. Et comment faire ?

Ne pas utiliser _readonly par exemple (mais de vrais fichiers de données)... Ou même ne pas rajouter des flags inutiles dans le kernel tout simplement.

>Mais non. Un programmeur _nostub utilisera HeapDeref au lieu d'aller traffiquer dans tios::Heap. C'est quand meme plus pratique en asm.

N'éxagère pas quand-même! C'est très facile d'appeler HeapDeref.

C'est Vti qui devrait rajouter une espece de boot code aux tib, plutot.

Et il le sortirait d'où?

A, je connaissais pas. Mais c'est pas compatible ams 1.0x

void *HeapTable;
HeapTable=AMS1?(*(void **)(long)*((short *)HeapDeref+4)):_rom_call_addr(441);
(J'espère que je ne me suis pas trompé dans cette ligne.) Personne ne t'empêche de faire la même chose en assembleur.
(C'est bien 441 d'ailleurs, pas 1104, j'ai mal lu les sources de DoorsOS.)

Kevin Kofler a écrit :
Tu peux aussi faire des bsr avec plusieurs fichiers objet. Les relogements PC-relatifs 16 bits sont supportés depuis longtemps par notre système de linking. Seul problème: si le bsr va à plus de 32 KO de distance (c'est la raison principale pour laquelle AS ne l'utilise pas pour les jbsr générés par GCC). Mais tu as le même problème avec les include "partie2.asm".

Je trouve que c'est sale de faire des relogements 16-bits entre fichier de donnees.
Ca peut empecher de mettre les fichiers objets dans n'importe quel ordre.

Ne pas utiliser _readonly par exemple (mais de vrais fichiers de données)... Ou même ne pas rajouter des flags inutiles dans le kernel tout simplement.

S'il est inutile pkoi je m'en sers alors ?

N'éxagère pas quand-même! C'est très facile d'appeler HeapDeref.

Je disais ca pour la souplesse d'utilisation.

Et il le sortirait d'où?

Il pourrait se demerder sans trop se faire chier quand meme

void *HeapTable;
HeapTable=AMS1?(*(void **)(long)*((short *)HeapDeref+4)):_rom_call_addr(441);
(J'espère que je ne me suis pas trompé dans cette ligne.) Personne ne t'empêche de faire la même chose en assembleur.
(C'est bien 441 d'ailleurs, pas 1104, j'ai mal lu les sources de DoorsOS.)

Le systeme actuel marche tres bien, donc bon voila, la flemme.
Mais je garderais ca sous la main.

OKon va faire comme Kevin propose:
ne programmons qu'avec des rom_calls, et en _nostub
...
...
...
...
En basic quoi

Et t'as vu Jurassic Park? Les dinos c'est dangereux si on ne s'en occupe pas comme il faut...

Ximoon
a écrit : Et t'as vu Jurassic Park? Les dinos c'est dangereux si on ne s'en occupe pas comme il faut...

T'es

Ximoon> et la marmotte, elle met le chocolat dans le papier d'alu...

bon g des pbs avec les rom calls
y'a qqchose qui marche po symfind retourne tjrs 0 dans d0
voici le code
        pea.l carte(pc)         jsr tios::SymFind         addq.l  #4,a7         tst.w   d0         beq     aaa2         rts aaa2:      lea 4(a7),a7      bra exit ;et en var :   dc.b 0  dc.b "carte" carte: dc.b 0