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

pub détectée.

mais pas mensongére

PpHd a écrit :
moveq LOL

Oups... c'est corrigé. Je voulais dire movem évidemment!

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

OK, je vais voir ça. Il y aura en tout cas bientôt des headers à jour dans TIGCC. Mais là, je suis occupé avec le portage de patch TIGCC vers GCC 3.1 (j'ai récupéré un prerelease de GCC 3.1).

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

La directive OPTIMIZE_ROM_CALLS s'occupera de ça tout seul, comme en C.

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

Api92 -> dialogs.h, menus.h
Shrnklib -> ttpack, UnpackBuffer de ExtGraph
(Je vais d'ailleurs devoir faire un header ASM pour les constantes et macros à utiliser.)
Genlib -> ExtGraph, _rowread, _keytest et constantes pour _keytest.
ugplib -> C'est quoi? Il n'y a pas grand monde qui utilise ça en tout cas.
fargray, graphlib::gray7 -> OK, il est vrai qu'il n'y a pas encore les 7 niveaux de gris dans TIGCCLIB. Mais il n'y a pas grand monde qui les utilise.

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

Le fait que ROM_CALL détruit a4 est documenté dans mon tutorial.

squale92 a écrit :
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...

ttpack compresse beaucoup mieux.

Et tout savoir est chose utile...

Tout savoir est impossible!

PpHd a écrit :
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

squale92
a écrit : pour la compatibiliét, mieux vaut utiliser les appels normaux...

D'accord avec squale92. Même en kernel, celui qui utilise AMS 2.03 et Universal OS se retrouve avec un programme qui ne fonctionne pas.

(J'ai corrigé le lien pour ExtGraph, et j'en ai rajouté un vers compat.html pour les constantes pour _keytest.)

Kevin> je sais parfaitement que ttpack compresse bcp mieux que ZipLib : j'utilises moi-même ttpack pour KII.

Kevin> je sais parfaitement que ttpack compresse bcp mieux que ZipLib : j'utilises moi-même ttpack pour KII.
Pr la pharse suivante, joli...
dans ce cas, en savoir le plus possible est utile

si je ne me trompe, les appels de ROM_CALL par le 1111 sont plus lent que ceux par JSR, non ?

Kevin Kofler a écrit :
La directive OPTIMIZE_ROM_CALLS s'occupera de ça tout seul, comme en C.

Surtout pas. FAST_ROM_CALL est tres bien. On ne doit pas cacher cette particularite. En C, c'est bien ils sont faignant. Alors qu'en ASm, on risque d'oublier apres quelques heures de code que ce registre est reserve aux rom-calls, et donc -> paf. Tandis qu'avec FAST_ROM_CALL, c'est explicite.

Api92 -> dialogs.h, menus.h

C'est bien plus complet

Shrnklib -> ttpack, UnpackBuffer de ExtGraph
(Je vais d'ailleurs devoir faire un header ASM pour les constantes et macros à utiliser.)

Ca prend 2K dasn le programme

Genlib -> ExtGraph, _rowread et constantes pour _rowread.

Encore une fois tu prouve ta meconnaissance de genlib.

ugplib -> C'est quoi? Il n'y a pas grand monde qui utilise ça en tout cas.
fargray, graphlib::gray7 -> OK, il est vrai qu'il n'y a pas encore les 7 niveaux de gris dans TIGCCLIB. Mais il n'y a pas grand monde qui les utilise.

Juste les gens qui ont un kernel.

Le fait que ROM_CALL détruit a4 est documenté dans mon tutorial.

J'ai rajoute une doc sur les macos dans preos. Dans RAM_CALL.txt

ttpack compresse beaucoup mieux.

Mais pas on-calc.

D'accord avec squale92. Même en kernel, celui qui utilise AMS 2.03 et Universal OS se retrouve avec un programme qui ne fonctionne pas.

[/cite]
Il suffit que ce soit precise dans la doc du programme

/me dit que, malheureusement, y'a trop de gens qui lisent pas les readme

Suffit de faire un processus d'installation

tu veux dire, de rajouter un hook sur le 1111 ?
oéu ,j'y ait pensé... mais je sais pas trop...

quelle taille en plus installer ce hook ferait prendre au programme ?
et est-ce que le 1111 est effectivement plus lent que jsr ?

yeah !! à qd les gray 7 dans un jeu ?

Le 1111 est plus lent, mais pour une ROM_call qui est de toute facon lent, on s'en fout un peu

OK.
et donc, combien de place ça ferai gagner d'installer soin propre hook ?


enf ait, un appel de ROm_CALL fait quoi ? 8 octets non ?
(en nostub, sans optimize_ROM_CALL)

et un appel via le 1111, ça prend 2 octets, non ?

=> gain de 6 octets par appel de ROM_CALL ?


(dites moi si je me goure !)

Non, tu ne gourres pas. Le hook prend environ 200 octets.

je me gourre pas ?
houla, j'ai de la chance

le hook == 200 octets...
donc, ça serait rentable peut-être pour KII...

qd je suis en OPTIMIZE_ROM_CALL, je gagne 400 octets par rapport à qd j'y suis pas...
=> si je passait par le 1111, j'en gagnerai 600... dont 200 qui passeraient pour le hook...
=> gain de 400 octets (comme en utilisant OPTIMIZE_R_C), mais en laissant a5 libre...

Essayes de compiler avec le nouvel tigcc. Il y a un hook auto-installable. Je suis plus quelle directive (trop de define a definir, c'est chiant).

y'a #define FLINE-ROM_CALL, ou quelque chos ecomme ça...
mais je savias pas que ça installait le hook : je pensais que ça utilisait le 1111 simple, en faisant perdre la compatibbilité avec AMS<2.04

-

le 7 grays...
ma fois, pr un jeu...
ça demande 50% de graphismes en plus => il faut encore plus de RAM

-

chrono est en 4 gray je crois...
et sur proj ? bof, c déjà pas mal on real-ti !

PpHd
a écrit : Essayes de compiler avec le nouvel tigcc. Il y a un hook auto-installable. Je suis plus quelle directive (trop de define a definir, c'est chiant).

#define USE_INTERNAL_FLINE_EMULATOR

OK. merci !
je le connaissais pas celui-là

Et les 7 niveaux de gris, on peut très bien les mettre dans TIGCC. Et peut même en offirir 8 (il y aurait le choix entre des cycles 1-2-3 et 1-2-4.) C'est juste que je n'ai pas eu le temps de le faire jusqu'à présent. (Si quelqu'un veut le faire à ma place, il est le bienvenu. Envoyez-nous les sources et les headers adaptés.)

Le hook de Line1111 de TIGCC et son installation ne font pas 200 octets, juste une 60aine d'octets. Mais pourquoi ne pas essayer de l'optimiser encore plus ? __fline_handler:      move.w          (a7)+,d0      move.l          (a7)+,a0      move.w          d0,sr      move.w          (a0)+,d0      andi.w          #$7FF,d0      lsl.w          #2,d0      move.l          ($c8).w,a1      pea          (a0)      move.l          0(a1,d0.w),-(a7)      rts

Et pour l'installation, on peut gagner un peu en évitant le relogement :
(mmm, pas le droit à 2 sources dans le même post?)
move.l ($2c).w,-(a7)
lea __fline_handler(pc),a0
move.l a0,$4002C

Avec ça on gagne 8 octets par rapport à la routine originale, c'est dejà pas mal.

Mais utiliser un #USE_FLINE_ROM_CALLS sans #USE_INTERNAL_FLINE_EMULATOR force tout le monde à passer à l'AMS 2.05, et c'est pas plus mal.
Et le hook fait vraiment beaucoup gagner de mémoire avec beaucoup de rom calls. L'argument du temps d'appel ne vaut rien, on a tout à y gagner en utilisant ça (même en asm d'ailleurs).

Envoie ces routines à Sebastian s'il te plaît, c'est lui qui fait les releases.
Mais merci en tout cas.

Heu... Il manque beaucoup de tests la...

L'implementation actuelle n'effectue pas les tests d'anti-crash, et ne fonctionne pas en superviseur.

C'est pas bien, Et pas de detection si la rom-call existe bel et bien ?

Non, pas pour l'instant.

-