clrscr - Page 1

j'essaye_décrire_une_routine_qui_efface_l'écran
mais_ce_qui_suit_ne_fonctionne_pas_(pas_de_plantage_mais_rien_ne_se_produit)

move.w #$F00,d0
move.l $4C00,a0
loop:
clr.b (a0)+
dbra d0,loop

de_plus,_lorsque_je_met_clr.w_ou.l_a_la_place_de_clr.b_ça_plante.

par_contre_si_j'enleve_la_boucle_et_que_je_met
clr.b($4c00)
là_ça_m'efface_bien_le_premier_octet_de_l'écran_comme_prévu.

pourtant,_rien_ne_se_passe_avec_un
clr.b(a0)
byzarre...

si ca plante avec w ou l>adresse impaire
t sur de ce que tu as mis dans d0??

bah_j'ai_mis_la_taille_de_l'écran_en_bits,_tout_smplement_(ou_alors_en_w_ou_en_l
qd_je_teste_clrw_et_clrl)
apparamment,_l'adresse_de_l'écran_est_paire_en+...

move.l #LCD_MEM,a0
move.w #959,d0
boucle
clr.l (a0)+
dbf d0,boucle
essai ca

effectivement_ça_fonctionne
en_fait_il_fallait_tout_simplement_mettre_un_#_avant_l'adresse_de_l'ecran
qu'on_charge_dans_a0_au_départ
mais_pourquoi_ce#_est_il_nécessaire?

fallait s'y attendre à ça ...

Nerick a écrit :
effectivement_ça_fonctionne
en_fait_il_fallait_tout_simplement_mettre_un_#_avant_l'adresse_de_l'ecran
qu'on_charge_dans_a0_au_départ mais_pourquoi_ce#_est_il_nécessaire?

Le # est nécessaire car sinon ce n'est pas l'adresse qui est stocké, mais la valeur que l'on trouve a l'adresse. Voila.

Et il faut toujours utilise LCD_MEM pas $4C00

et mettre move.l $4c00,a0 va mettre le long se trouvant a l'addresse $4c00 dans a0, et ta boucle va aller ecrire a l'addresse pointee par ce long, cad a une addr relativement aleatoire.. si t'as pas resete depuis ke t'as essaye ce, reset, ca a du foutre la merde qque part en ram...

pour mettre le nombre $4c00 dans a0, soit tu fais:

move.l #4c00,a0
soit:
lea $4c00,a0

et effectivement c mieux d'utiliser LCD_MEM
et Kevin: put1 c pa vrai ca, il cherche a comprendre comment ca marche, pas a utiliser tes putains de rom calls!!! ca devient vraiment lourd...

et si tu veux faire une boucle comme ca pr effacer l'ecran, n'utilise pas de .b ! tu peux effacer 32 pixels a la fois en utilisant un long..

move.w #$F00/4,d0 ;g la flemm de calculer 3840/4...
lea LCD_MEM,a0
loop clr.l (a0)+
dbf d0,loop

et encore mieux:

move.w #$F00/4,d0 ;g la flemm de calculer 3840/4...
moveq #0,d1
lea LCD_MEM,a0
loop move.l d1,(a0)+
dbf d0,loop

si tu veux + rapide, tu devra passer par des movem

PpHd
a écrit : Et il faut toujours utilise LCD_MEM pas $4C00

C'est la même chose de toute façon!

-

Et je trouve ça vraiment débile:

tiré de tios.h de PreOs: LCD_MEM equ _RAM_CALL_021

1. Ça crée des incompatibilités avec les anciens kernels pour rien.
2. Ça gaspille une place importante en relogements pour rien.
Cette adresse est constante de toute façon, donc utilisez la constante!!!

-

bah nan, moi dans tios.h j'ai ca:
LCD_MEM equ $4c00

PpHd a changé ça dans les tios.h les plus récents.

-

je c, ms moi je le re-change a chake nvelle version de PreOs

Et tu as raison de le faire.

Correction :
move.w #$F00/4-1,d0 ;g la flemm de calculer 3840/4...
moveq #0,d1
lea LCD_MEM,a0
loop move.l d1,(a0)+
dbf d0,loop

tiré de tios.h de PreOs:
LCD_MEM equ _RAM_CALL_021


>1. Ça crée des incompatibilités avec les anciens kernels.
Oui.
>2. Ça gaspille une place importante en relogements.
T'exageres encore
>Cette adresse est constante de toute façon, donc utilisez la constante!!!
Tu n'a rien compris aux principes du MiddleWare. Donc je vais pas detailler plus.
Tous les ports IO, et les adresses systemes doivent etre exportes sous forme de _RAM_CALL. D'áilleurs y va avoir en plus :
IO_PORT1 equ _RAM_CALL_026 ; = $600000
IO_PORT2 equ _RAM_CALL_027 ; = $700000
VECTOR_TAB equ _RAM_CALL_028 ; = $40000

Mais je parle dans le vide alors,

mue...
bah ac mon systeme vu ke j'utilise ces defs dans mes sources, il suffit de changer de tios.h sans retoucher la source et on a la version avec RAM_CALLS...
pour l'instant, j'utilise les addr directement dans les define, sans ramcalls...

ben d'ailleurs, c'est pour Ti, et c'est tres peu probable que Ti change ;'addr de la scrmem.. et si ils la changent, ca s'accompagnera de changements radicalement differents du hw, et y faudra certainement reecrire les progs.. dc au nivo de la Ti, je sais pas si ca vo le coup
enfin bon, c mon avis

PpHd a écrit :
Tu n'a rien compris aux principes du MiddleWare. Donc je vais pas detailler plus. Tous les ports IO, et les adresses systemes doivent etre exportes sous forme de _RAM_CALL.

Je ne comprends pas pourquoi tu insistes à gaspiller de la place en relogements, et de la RAM dans PreOs, pour des adresses constantes par pur esprit dogmatique ("Tous les ports IO, et les adresses systemes doivent être ...", sans aucune justification pour expliquer pourquoi ça a un sens dans ce cas précis).

sBibi a écrit :
ben d'ailleurs, c'est pour Ti, et c'est tres peu probable que Ti change ;'addr de la scrmem.. et si ils la changent, ca s'accompagnera de changements radicalement differents du hw, et y faudra certainement reecrire les progs.. dc au nivo de la Ti, je sais pas si ca vo le coup
enfin bon, c mon avis

Entièrement d'accord.

PpHd a écrit :
IO_PORT1 equ _RAM_CALL_026 ; = $600000 IO_PORT2 equ _RAM_CALL_027 ; = $700000

Parce que tu crois qu'ils ne vont changer que l'adresse de base? S'ils changent les ports, ils changent très probablement tout!

VECTOR_TAB equ _RAM_CALL_028 ; = $40000

Si tu as vraiment peur que TI va sortir un modèle avec plus de RAM (improbable, ils ont déjà refusé d'augmenter la RAM dans la V200, heureusement), mets VECTOR_TAB equ $100000 et c'est bon. Le RAM_CALL est vraiment inutile.

sBibi a écrit :
bah ac mon systeme vu ke j'utilise ces defs dans mes sources, il suffit de changer de tios.h sans retoucher la source et on a la version avec RAM_CALLS...
pour l'instant, j'utilise les addr directement dans les define, sans ramcalls...

Mais il faudra recompiler le programme.

ben d'ailleurs, c'est pour Ti, et c'est tres peu probable que Ti change ;'addr de la scrmem.. et si ils la changent, ca s'accompagnera de changements radicalement differents du hw, et y faudra certainement reecrire les progs.. dc au nivo de la Ti, je sais pas si ca vo le coup

Ils l'ont deja fait. Cf passage TI-92 I (Adr screen $4400) a Ti-92 II (Adr screen $4C00). Et je bosse aussi pour l'emulation des progs kernels sur Dioxygene. Grace a la redirection des ports, ca sera simple a emuler. Et ca ne ralentit rien du tout dans le programme !

Kevin Kofler a écrit :
Je ne comprends pas pourquoi tu insistes à gaspiller de la place en relogements, et de la RAM dans PreOs, pour des adresses constantes par pur esprit dogmatique

C'est bien ce que je dis. Tu ne comprends pas.

("Tous les ports IO, et les adresses systemes doivent être ...", sans aucune justification pour expliquer pourquoi ça a un sens dans ce cas précis).

Parce que le cahier des charges d'un middle ware doit exclure le bas niveau d'une architecture. En exportant ces RAM_CALL,, j'offre au systeme d'exploitation la possibilite d'avoir a emuler seulement une partie des Ti, et ca marchera quand meme. Il peut placer l'ecran ou il veut (Il s'occupera de convertir les formats), la table des vecteurs peut etre toucher indirectement, les ports IO peuvent etre emuler (Suffit de faire une adresse erreur en mettant les IO_PORT a une adresse impaire, puis traduire l'instruction precedente). Il pourra tester si les rom-calls ont bien ete tous redefinis (et pas d'utilisation de la rom officielle de texas), de meme que les ram_calls (on peut par exemple interdire si MainFolder n'est pas emule). Bref j'offre une couche d'abstraction supplementaire pour faire tourner les progs kernels dans des environnements qui pourront etre differents -Atari, amiga, o2, mac, ... - (mais a base de 68k) sans a avoir a emuler le processeur, et le mapping memoire.

Kevin Kofler a écrit :
Parce que tu crois qu'ils ne vont changer que l'adresse de base? S'ils changent les ports, ils changent très probablement tout!

Tout a fait !
mais la le kernel pourra essayer de faire une emulation de l'ancien materiel (Difficile mais pa s impossible).

Si tu as vraiment peur que TI va sortir un modèle avec plus de RAM (improbable, ils ont déjà refusé d'augmenter la RAM dans la V200, heureusement), mets VECTOR_TAB equ $100000 et c'est bon. Le RAM_CALL est vraiment inutile.

Ce n'est pas que pour ca. C'est pour aussi eviter qu'ils ne touchent directement aux interruptions si necessaire (sur un autre systeme).

Kevin est de mauvaise fois, il ne changera jamais

Cher Kevin Ô Dieu tout puissant qui lui seul a le droit d'imposer ses idées, sachez que les quelques octets pris en plus par la technique de PpHd sont certainement rien à côté des 50.000 patches que vous nous foutez en têtes des programmes compilés par TIGCC, qui en plus sont recopiés dans chaque programme.