save et restore du LCD dans un nostub - Page 2

cool, c'est vrai que j'avais oublié que je multipliais tous les trucs par 4 pour les mettre ;-)
si j'utilise les numeros c'est pour pas mettre d'include, de toute façon je met à côté en commentaire la rom_call à quoi ça correspond...
en plus vu que je suis en nostub je peux pas faire de "JMP" ou trucs comme ça pour les ROM_CALLs, je fous les numeros et tout...

ce qui est cool Kevin c'est qu'avec ta methode pour les ROM_CALL (t'avais repondu à un autre topic) ça bouffe quasi pas de place par rapport à un prog doorsos! mais c'est con que dans doorsos.h par exemple ce soit la methode "longue" (4 lignes je crois), la tienne en prend que 2...
et pourtant c'est la plus nulle qu'on retrouve partout

Déjà, prends OS.h de TIGCC, qui utilise une instruction de moins. (C'est moi qui l'ai fait changer à Sebastian Reichelt.)

Sinon, tu peux définir ta propre macro:

FAST_ROM_CALL MACRO
 move.l 1*4(a5),a0
 jsr (a0)
 ENDM

(À condition d'avoir fait move.l $c8,a5 au début.)

Si j'y pense, je vais demander à Sebastian Reichelt de mettre une option OPTIMIZE_ROM_CALLS aussi pour OS.h (comme pour tigcc.h en C). Ce n'est pas difficile pour moi de la programmer.

Il faudra d'ailleurs que j'optimise aussi mes programmes de cette manière.
[edit]Edité par Kevin Kofler le 29-06-2001 à 18:10:58[/edit]

Kevin Kofler planté

si tu fais

buffer_screen dc.l 0

et que tu tentes de sauvegardé l'ecran dedans en mode nostub (includ "Os.h")

eh ben cela te retournes une erreur du genre:

[protected memory]

Tu utilises quoi comme routine? Surement pas la mienne...

Il faut que tu alloues quelque chose avant d'utiliser un pointeur. buffer_screen: dc.l 0 n'alloue rien du tout (enfin, si, 4 octets, mais pas 3840...).

Il faut d'abord que tu appelles une des fonctions HeapAlloc* pour allouer de la mémoire. Le plus pratique: HeapAllocPtr (=malloc). Ensuite, tu peux mettre ce pointeur dans buffer_screen (mais autant le garder dans un registre comme d4 dans mon exemple si c'est possible), puis l'utiliser, et enfin appeler HeapFreePtr en fin de programme pour libérer la mémoire allouée.

Arf excuse moi c'est pas toi c'est Pollux qui à fait la faute en me disant que

buffer_screen dc.l 0 <=> buffer_screen dc.l 50!!!

kékidilui ?

Je vois mal ce que viendrait faire un dc.l 50 ici.

Kevin> nan j'ai pas fait de macro je m'en fous y'a que 2 lignes à recopier à chaque fois ;-)

FlashZ> euh ben oui c'est vrai mais depuis qqs jours j'arrête pas de penser "optimisation dans une boucle" alors faut m'excuser et sinon les deux instructions prennent la même place?

jarff je me suis planté sur tte la ligne!

une question pour Kevin!

Si je veus faire du nostub mais en même temps je veus utilisé les ROM CALLS comment je fais car avec:

include "Os.h"

xdef _nostub ;ça marche pas les appels de roms!

Tu utilises la routine
ROM_CALL HeaAlloc
par exemple

J'ai pas été très clair!

Si je veus faire un prgm nostub et que je veus aussi que dans mon programme je veus utilisé les Rom Calls comment je fais sous l'IDE de TIGCC!

car si je fais:

include "Os.h"

xdef _nostub
xdef _main
xdef tixx

;Il est impossible d'utilisé les ROM_CALLS!

Remplace jsr doorsos::HeapAlloc par ROM_CALL HeapAlloc. (Attention, cette macro détruit le registre a4.)

oki!

oué, bon ba envoie moi F0. (avec les sources)
c + prudent. (y'a peut etre une faute d'ôrteaugraf)

Tu les veux Pen^2 ?

Moi g la question inverse:
est-il possible d'empêcher le kernel de sauver et de restituer l'écran?

tu les as FlashZ ?

>est-il possible d'empêcher le kernel de sauver et de restituer l'écran?

Oui : faire du nostub

>tu les as FlashZ ?
Oui, biensur !

Ximoon: la dernière version de Unios le fait (arf, vi, t'as fargo II )

Ouais ! Fargo II (arff !tchou! )
moi j'ai unios

ouiiinnnnnn

Es-t-il possible d'empecher un nostub de sauver l'ecran ?

??
mais en nostub, l'ecran n'est pas sauvé par defaut, si ?

Non, en nostub, on doit le sauvegarder soi meme l'ecran.

exact!donc il faut se faire iéch à laissé un buffer de 3840 octets pour y mettre l'écran à moins de le mettre sur la pile

Il suffit de copier-coller le code que j'ai proposé sur la page 1.

Aussi (mais comme j'aime pas utilisé les ROMS CALLS !)

la seule ROM CALLS que j'utiliserais (si j'en utilise une c'est celle équivalente à Os::GKeyIn) por débuggé mes programmes!

a oui j'imagine que ParadiZe il a fait ces propres routine d'allocation de mémoire
puisqu'il n'utilise que GKeyIn comme rom_call !

bien non je n'aime pas non plus alloué de la mémoire à la façon Rom_Call!
si j'ai besoin de 100 octets je l'ai prend sur mon programme! Je fais juste

besoin_100octets_tu_me_les_fous_daccord dc.l 25