Chaine Exec 2 - Page 1

-

Orion_ a écrit :
premiérement, je voudrais savoir qui les a trouver et qui les a publier en premier ?

??
y'a pas spécialement de premier !

et deuxiemement, pourquoi a la fin de chaque chaine exec il y a toujours un:
rts
ori.b #0,d0

le rts j'imagine que tu le sais, le ori, ça correspond au 0 à la fin, sans lequel ça plante la TI. mais pkoi ça la fait planter sans, là....

pourquoi il y a un rts et un nop ? et que designe l'adresse: 0x600013 ?

rts : ben cf + haut..
nop : va savoir.. essaye sans.
600013 => regarde dans une doc sur les ports

le 0 a la fin c'est pour la table de reloc.(qui ici est vide)

ah, ok.

et c quoi la routine d'AMS qui permet de reloger une chaine exec ?

je pense que le TIOS se charge du relogement lors de l'appel a la commande exec.
A mon avis la fonction est la meme que pour reloger un prog.

-

le relogement sert a pouvoir executer un prog qui n'est pas charge a une adresse fixe en ram:
voici un petit exemple:

_main:
bra label
...
label:
...

lorsque le cpu execute le bra, il a besoin de savoir a quelle adresse se trouve le label or cette adresse change en fonction de l'adresse ou est charge ton prog. la table de relogment sert a calculer ces adresses.

mauvais exemple (un bra est toujours suivi d'un déplacement relatif)
mais le principe est bon

bon ex :
lea label(pc),a0

Mais non ! non plus Ton exemple est aussi relatif au compteur programme !

Bon exemple : clr.w MonLabel

m****, c vrai en +
g pensé lea, g rajouté pc par habitude

  move.w  #0,-(a7)
  pea     message(pc)
  clr.l   -(a7)
  pea     ($4C00).w
  bsr     GX_DrawStr
  lea     14(a7),a7
  rts

message:
  dc.b    "Julien va te coucher :p",0
  even

Qu'as-tu à répondre ? ( y'a un piège)

Pen^2
a écrit : nop : va savoir.. essaye sans.

C'est A68k qui rajoute ça parfois parce que la taille d'une section d'un fichier objet au format AmigaOS-hunks doit être multiple de 4. Tu peux le virer sans conséquences.

Ced a écrit :
je pense que le TIOS se charge du relogement lors de l'appel a la commande exec. A mon avis la fonction est la meme que pour reloger un prog.

En effet, c'est EX_patch qui se charge de tout. Cf. sources de h220xTSR.

Pen^2 : ALORS ???????

Je crois que j'ai trouvé! (mais je ne vous promet rien, je suis un sous-nioob en asm68k sur cette plate-forme, je me sens mieux sur le simulateur 68k du lycée, qui est beaucoup plus simple):
bsr GX_DrawStr
Si GX_drawStr est une fonction de librairie, alors le bsr mène vers une reloc, car la lib n'est pas forcément à la suite du prog (Adresse_lib-Adresse_prog!=constante)
Alors, j'ai réussi à comprendre quelque chose ou je suis encore plus nul que je croyais?

C'est faux. Ça crée un "relogement PC-relatif" qui sera relogé en un appel PC-relatif (donc qui n'a plus besoin de relogement en temps d'exécution) par ld.

> derniére question, pour la commande qui grille l'ecran:
> move.b #0xFF,0x600013

Pourquoi cela grille-t-il l'écran? (sur la doc de fargo ce port n'y est pas)

LowLevel.txt

:WO [600012]
    <..543210|........> = LCD horizontal frequency (?maybe?)
			: The TI-92's ROM writes $31 to this port during
			: initialization.
    <........|76543210> = $100 - number of LCD scanlines
			: If the number of scanlines is smaller than $80 (the
			: actual height of the LCD) the display will be
			: duplicated in the lower half. Decreasing the height
			: darkens the LCD; increasing the height lightens the
			: LCD. The TI-92's ROM writes $80 to this port during
			: initialization.

maintenant peut-être que c'est inexact (voire les docs plus récentes...)

Regardez j89hw.txt. Il est disponible entre autres sur http://tict.ticalc.org.

XDanger a écrit :
Regardez j89hw.txt. Il est disponible entre autres sur http://tict.ticalc.org.

Eh ben j'ai regardé et il dit rien sur le port 0x600013

C'est parce qu'il a documenté $600012 comme un word entier!

$600012 -W ($3180 => 240x128 screen)
	:15-14	-
	:13-8	LCD logical width =(64-n)*2 bytes =(64-n)*16 pixels
		The LCD controller DMA will send this many pixels to the
		screen for each line (= between each RS).
	:7-0	LCD logical height =(256-n)
		Number of "row syncs" (RS) between each "frame sync" (FS).
		(This is the (logical) screen height.)
		Note: The contrast must often be adjusted when the logical
		screen height is changed.  By default, each screen line is
		"visited" during 1/128 of a frame but if the logical height
		is set to e.g. 100, each line is now "visited" more often
		(1/100 of a frame) and will appear darker at the same
		contrast level because of this.
	This register is actually two 8-bit registers and each subregister
	can be written to without disturbing the other 8 bits.
	Note: The internal counters in the screen controller restarts on
	writes to this register, but no FS or RS is generated.  Use this
	during grayscale initialization to force the screen refresh into a
	known state (for synchronization).

Kevin Kofler a écrit :
C'est parce qu'il a documenté $600012 comme un word entier!

Whoops qu'est-ce-que je suis con

Donc si on écrit 0xff sur $600013 on lui dit que le LCD logical height est de 256-255=1
Pourquoi ça grille l'écran? Parce que ça fait que chaque ligne soit visitée pendant trop longtemps? (1/1 of a frame)

Parce que ça crée un survoltage.

Pourquoi ça crée un survoltage ? (j'y connais rien en ASM)

Ce n'est pas prouvé ! Ou alors j'ai loupé un épisode... Personne n'a voulu essayé
Nan mais peut-être que certains ont eu accès à des TI à moitié bousillées sur lesquelles ils pouvaient tester n'importe quoi et surtout ça !
En attendant, on applique le principe de précaution...

... tout comme pour l'écriture en flash : JE pense, après une simulation que personne n'a reproduite, qu'on peut rendre une calculatrice intuilisable en détruisant les certificats.
Il y a déjà suffisamment de personnes qui se trouvent avec une TI bloquée sur le boot, pour une raison que personne n'explique : je pense même que ces personnes s'y prennent mal...

Et tu as encore un doûte sur la corrélation entre les 2 phénomènes du #26? Pour moi, le moins qu'on puisse dire est qu'il est très probable que les calculatrices bloquées sur le boot le sont à cause d'une zone des certificats corrompue. On a déjà vu toutes sortes de zones de certificats corrompues de manières plus ou moins bizarre (#ID disparu, certificats apparus sans que la personne ne les ait installés, ...), donc ça ne m'étonnerait pas.

JM a écrit :
Ce n'est pas prouvé ! Ou alors j'ai loupé un épisode... Personne n'a voulu essayé
Nan mais peut-être que certains ont eu accès à des TI à moitié bousillées sur lesquelles ils pouvaient tester n'importe quoi et surtout ça ! En attendant, on applique le principe de précaution...

Ça crée un bel écran bleu en tout cas. Il y a des gens qui ont essayé. Mais ils ont retiré les piles avant que l'écran n'ait été détruit, donc je ne sais pas si on peut détruire effectivement l'écran comme ça.

JE pense, après une simulation que personne n'a reproduite, qu'on peut rendre une calculatrice intuilisable en détruisant les certificats.

Il me semble qu'ExtendeD avait rendu une (deux ?) Ti inutilisables...
je sais pas si ct exactement en faisant ça...
mais ça devait être ds le style