Liste des ROM_CALLs - Page 1

Où pourrais-je avoir la liste complète des ROM_CALLs avec leurs paramètres et une description de ce qu'elles font ?
Merci

je laisse a kevin l'immense jouissance de te donner l'url de la doc de tigcc

sBibi :
Faut bien un peu lui faire plaisir parfois

Mais j'aimerais bien l'avoir en FR cette doc ...
C'est pas que je sois une merde en anglais mais bon, j'aime pas faire d'effors
Autre chose aussi sur cette doc, toutes les syntaxes sont en C, si par exemple je veux utiliser sprite8 en asm je fais comment ? jsr tigcclib::sprite8 ? avec les paramètres dans la pile ?

TechNIC a écrit :
Où pourrais-je avoir la liste complète des ROM_CALLs avec leurs paramètres et une description de ce qu'elles font ?
Merci

http://tigcc.ticalc.org/doc/

TechNIC a écrit :
Mais j'aimerais bien l'avoir en FR cette doc ...
C'est pas que je sois une merde en anglais mais bon, j'aime pas faire d'effors

Il y a http://tigcctrans.sourceforge.net, mais la traduction n'est pas du tout à jour.

Autre chose aussi sur cette doc, toutes les syntaxes sont en C, si par exemple je veux utiliser sprite8 en asm je fais comment ? jsr tigcclib::sprite8 ? avec les paramètres dans la pile ?

Déjà, c'est bsr Sprite8 ou jsr Sprite8 si c'est à plus de 32 KO de distance. Les majuscules comptent, et il n'y a pas de tigcclib::.
Ensuite, pour les paramètres, ça dépend de la version: les versions jusqu'à la bêta 13 prenaient les paramètres sur la pile. Les bêtas récentes utilisent maintenant le passage par registres dans les fonctions implémentées en C (les fonctions en assembleur n'ont pas encore été converties). C'est-à-dire:
- Les 4 premiers scalaires sont passés dans d0-d3.
- Les 4 premiers pointeurs sont passés dans a0-a3.
- Le reste des paramètres est passé sur la pile comme avant.
- Pour des fonctions à nombre de paramètres variable (comme printf), tous les paramètres sont passés sur la pile.
Pour Sprite8, cela veut dire:
* x est passé en d0
* y est passé en d1
* height est passé en d2
* sprite est passé en a0
* vm_addr est passé en a1
* mode est passé en d3

Ca devient complique a gerer la

ça serait pas possible, dans la doc, de préciser dans quels registres sont passé chaque paramètre ?
(ça serait bien pratique je penses )

(si ce n'est pas déjà fait)

squale92 a écrit :
ça serait pas possible, dans la doc, de préciser dans quels registres sont passé chaque paramètre ?
(ça serait bien pratique je penses )
(si ce n'est pas déjà fait)

Complètement d'accord avec toi !! Comment je fais moi pour savoir les paramètres de sprite8 ?? c'est pas marqué dans la doc !
Je vais retourner voir genlib si ca continue !!

même si ça parait logique pr les gens qui ont l'habitude... je doute que les newbies sachent !
ils pourraient essayer de ^passer les param par la pile, comme pr les rom_call, ou pr les fonctions standars

C'est une bonne idée, mais c'est assez compliqué à gérer. J'ai peur qu'il ne fasse taper ça à la main à chaque fois.

Je vais quand-même dire à Sebastian de rajouter une information que la fonction utilise le passage par registres avec un lien vers une information qui précise quels registres sont utilisés. (C'est autogénérable.)
Mais en fait, les programmeurs en assembleur: vous râliez toujours que TIGCCLIB n'utilise pas le passage par registres et que c'est plus lent, et maintenant vous râlez qu'elle l'utilise.

oué, j'en ai peur
vu qu'il faudrait modifier tous les protoypes notés dans la doc (enfin, pas tous, mais presque )

On ne va certainement pas modifier les prototypes, vu que c'est du passage par registres automatique, pas par spécification explicite.

arf, oué, c vrai
dsl

Kevin Kofler : j'ai la version 0.94 Beta 15 de TiGCC et je n'ai pas tigcclib.h ou encore sprites.h dans mes includes.
J'ai tenté de les copier dans le dossier include de ASM mais il ne reconnait pas les en-têtes (normal c'est en C )
Que faire ? ou plutot Comment faire ?

Mon source :

move.w #12,d0 ; Décalage en X
move.w #15,d1 ; Décalage en Y
move.w #8,d2
lea sprite,a0
move.l #LCD_MEM,a1
move.w #SPRT_XOR,d3

bsr Sprite8

Explication simple: on n'a pas besoin d'includes pour utiliser TIGCCLIB en assembleur.

Il te faut juste la valeur de SPRT_XOR. D'après la documentation, c'est défini comme:
enum SprtModes {SPRT_XOR, SPRT_OR, SPRT_AND};
Donc SPRT_XOR vaut 0. Donc autant utiliser un clr.w d3.

Juste pour continuer le sujet:
Ou peut-on avoir une liste des trap???

A part la doc de doorsos...
de tête:
trap #1 : changer le masque d'interruption (regarde des tutoriaux pour ça).
trap #2 : reset
trap #4 : shutdown
trap #9 : plusieurs fonctions, faut voir la doc de doorsos
trap #11 : la plupart des fonctions sont exportées en rom calls.
trap #12 : passage en mode superviseur

Je réussis pas à acceder au site de doorsos et je ne l'ai plus (unios) bon et maintenant PreOS

http://doors.ticalc.org

Et tiens, il y a encore TIGCC 0.65 qui traîne là-bas.
Si je pense au nombre de changements qu'il y a eu entretemps...

Le trap #3 fait un deref avec UniOs (Feature non documente comme d'habitude avec unios).

S'cuse moi Kevin, j'ai pris le tutorial que tu déconseilles sur ti-fr, mais pour les ROM_CALLs il parle de tios.h et moi je n'ai que doorsOS.h et OS.h
Comment je fais les ROM_CALLs dans cette situation ?(par quoi remplacer jsr tios::fonction ?)
http://tigcc.ticalc.org/doc/ n'en parle pas
désolé je suis moi aussi un newbie

Tu as regarde preos ? Dans la partie include ?

Non, j'ai un pack développeur doorsOS.
Je downloade preOS tout de suite!

Voila, c'est fait

Très bonne résolution ma foi

Link
a écrit : S'cuse moi Kevin, j'ai pris le tutorial que tu déconseilles sur ti-fr, mais pour les ROM_CALLs il parle de tios.h et moi je n'ai que doorsOS.h et OS.h

Parce que c'est un tutorial pourri. Même pas foutu d'utiliser les headers livrés avec TIGCC!

Les headers assembleurs de tigcc sont pourris !

oullllaaaaaaa
ca va gueuler
faut dire que une new liste des rom_call BIEN FAITE ET EN FRANCAIS EXPLIKE ET TOUT
ce serai bien ......encourageons les bonnes volontées

Te rends-tu compte du boulot que c'est de traduire une doc pareille en une autre langue ?
Les plus nombreux à râler à propos de la doc non traduite, ce sont les français...

normal que ce soit les français qui ralent le plus
les fr sont pas mal nombreux à coder sous TIGCC...
et puis, on a une réputation de gueulard