Mandelbrot POPOPO - Page 5

Regarde cet exemple, j'ai ajouté une boucle qui modifie VDE toutes les secondes en passant de 510 à 512, rien d'autre.
(oui je pourrai faire ça au joypad mais il faudrait faire une routine, c'est dans une autre langue, faut se renseigner la veille, tout ça....)

Quand VDE passe à 512 l'image remonte d'une ligne mais la 1ère ligne (blanche) n'est pas affiché (à la place c'est BG qui est affiché).

Je résume :
Je n'utilise pas de branchobjet pour gérer le démarrage de l'OP
J'utilise des valeurs de synchro que j'ai calculé et qui me semble juste (en supposant qu'elles se produisent bien au moment où je crois...)

VP = 523
ça je n'y touche pas, c'est la valeur initialisée par le BIOS. On est bien d'accord que ce registre n'indique pas à quel moment se termine VP, mais sa longueur en demie ligne (+1 puisque le compte démarre à zéro)
En NTSC 242p il y 524 demi lignes (262 lignes) donc 523 pour VP. VP se termine à la fin de la 524ème ligne

Je ne touche pas non plus à VEE qui normalement est correctement initialisé à 6 par le BIOS

Les registres suivant indique à quelle ligne ils sont actif et sont comptés à partir de 0
VS=518
VS se produit 3 lignes avant VP (6 demi ligne). 524-6=518
Le BIOS de la Jaguar initialise VS à 517. Suivant ma compréhension du fonctionnement des registres cette valeur n'est donc pas bonne et se produit 1 demi ligne trop tôt.

VBE=28
Le Vertical Blank se termine à la demi ligne 28. C'est la norme NTSC. En fait la norme c'est la ligne 21 donc 42 demi ligne, mais il faut retirer 1 car la norme NTSC compte les lignes à partir de 1 et il faut retirer 12 demi lignes car La norme compte à partir de la fin de la dernière ligne affiché alors que la Jaguar compte à partir de la fin de VS
Le BIOS initialise à 24

VDE=26
Normalement ça devrait être 28, mais comme l'OP doit préparer une ligne à l'avance...
Le BIOS initialise à 46 mais il doit surement le modifier plus loin

VDE=510
Normalement il devrait s'arrêter à la ligne 512 car la dernière ligne visible est 510, mais si je mets 512 la 1ère ligne visible de l'objet n'est pas affiché
Le BIOS initialise à 496 pour la version K et FFFF en version M. Pour la version K je pense qu'elle est également modifier plus loin dans le BIOS.

VBB et VEB=512
C'est la ligne ou commence la pré equalisation vertical et où commence également le blanking vertical.
Le calcul se fait en partant de VS qui à lieu à la ligne 518. VBB et VEB on lieu 6 demi lignes avant VS donc 518-6=512
Le BIOS initialise VBB à 500 et VEB à 511

L'affichage fait donc en tout 242 lignes, l'objet à afficher fait 240 lignes
Donc pour centrer l'objet je l'affiche une ligne plus bas. L'affichage commençant à la ligne 28, je met YPOS à 30...
Sauf que dans ce cas l'objet est affiché une ligne trop bas (donc à 32), je dois donc mettre YPOS à 28 pour qu'il commence à la ligne 30...

MAIS, si je change juste VDE, que je le met à FFFF ou même juste égale ou supérieur à VBB, alors l'objet commence à la bonne ligne (YPOS correspond bien à VC) mais sa 1ère ligne n'est pas affichée...

Fichier joint : PRO.COF

Note : avec virtualjaguar j'ai toujours le décalage de 4 pixels vers le haut comme signalé précédemment, par contre il réagit comme la Jaguar en modifiant VDE. L'image se décale d'un pixel.

Bon je sens que je vous ai troublé...

Du coup j'ai une autre question. En fait j'essai de voir pour faire un affichage bien carré (entendez bien fait)

J'essai juste de faire un affichage de 320*240 centré, qui commence et s'arrête bien proprement à VDB, VDE, HDB et HDE.

Et à l'horizontal j'ai un autre problème, si j'essai de paramétrer HDB et HDE pour faire une largeur pile de 320 pixel, ça déconne.

Je peux faire une largeur d'environ 322-324 pixel environ mais en dessous, l'écran se met à sauter, à trembler.

Y a t il un multiple quelconque à respecter pour que l'OP ne se mette pas à déconner ?

Note : au passage la routine de centrage d'Atari est bugée. HDB et HDE sont calculé à partir du centre théorique d'une ligne en cycle d'horloge. Sauf qu'ils oublient que l'image est divisé en 2 moitié.
du coup par exemple en 60Hz le centre est 823. HDB est bien calculé, mais HDE se retrouve décalé de +20 cycles environ.

Puisqu'il semble que j'ai mis tout le monde en PLS j'ai une petite question d'optimisation du pipeline (en fait 2)

D'abord,
On est bien d'accord que
cmp R0,R1 jr EQ,noloop nop jump CC,(R2)c'est pareil que :
cmp R0,R1 jump HI,(R2)
?

Les JRISC peuvent ils mettre à jour les FLAGS en même temps qu'une autre instruction écrit dans un registre de destination ?

Dans l'exemple :
cmp r0,r1 move r3,r4 jump hi,(r2)
Est ce que R4 pourra être écrit en même temps que les FLAGS sont mit à jour par l'instruction CMP ?

En gros est ce que ça se passe comme ça :

cmp r0,r1 | Rr0 Rr1 | |
move r3,r4 | Rr3 | ALU cmp |
jump hi,(r2) | Rflags Rr2 | | Wflags Wr4

?
Je ne crois pas avoir vu ce cas expliqué dans la doc (l'instruction cmp étant particulière puisqu'à priori elle ne bloque pas les registres concernés via le scorboard et ne modifie que les flags)

Au passage :
entre 10 et 11 secondes maintenant. j'approche quand même du rendement maximum des risc je crois.

SCPCD ça donne combien sur ta machine de guerre ?

Fichier joint : JAGMAND.COF

DEATH (./124) :


cmp r0,r1 | Rr0 Rr1 | |
move r3,r4 | Rr3 | ALU cmp |
jump hi,(r2) | Rflags Rr2 | | Wflags Wr4

ah flute... comment on fait pour que le texte soit aligné ?

DEATH =>
Pour ta question sur /EQ+CC = HI => oui car : /EQ = %00001, CC = %00100 et HI = %00101

Pour l'optimisation cmp/move, pour moi oui car :
le microcode de CMP n'active pas le bit wb to reg donc pas de wait states entre le cmp et move, puis le microcode de MOVE n'active pas le bit wb flags donc pas de wait states entre le move et le jump.

Je viens de tester ton dernier binaire sur la JagFPGA : ça prend environ 3s.

SCPCD (./129) :
Je viens de tester ton dernier binaire sur la JagFPGA : ça prend environ 3s.

Tu as déjà dis ça la dernière fois. Depuis j'ai gagné environ 2 secondes. ça doit bien aller un peu plus vite non ?

Pas forcément, tu peux avoir optimisé un truc sur le hardware original qui n’as pas ou quasi pas d’impact sur la super jag FPGA de SCPCD.

Death > en calcul théorique : si sur l'ancienne version sur jag c'était 12s et 3s sur jagFPGA ça fait un ratio de x4. donc avec une optimisation à 10s on serai à 2.5s sur jagFPGA.
Comme toutes les valeurs sont approximatives (mesuré avec un chronomètre manuel), ça m'étonne pas plus que ça que l'on n'observe pas de grosses différence : on est dans la marge d'erreur.

Godzil a fait une bonne remarque aussi : les DSP/GPU de la jagFPGA n'ont pas les même limitations hardware que les vrais, donc les optimisations n'ont pas forcement le même impact.