Mandelbrot POPOPO - Page 4

DEATH (./90) :
Virtualjaguar ne traite pas l'interruption vidéo de la même façon qu'une Jaguar
Déjà en entrelacé l'interruption VI peut avoir lieu 2 fois par ligne sur virtualjaguar donc je dois ajouter une boucle d'attente pour éviter que l'interruption ne se produise 2 fois de suite.
Ensuite, dans ma dernière version, allez savoir pourquoi, virtualjaguar traite les lignes paire-impaire de façon inversée par rapport à une Jaguar....
Je pete un cable....

Si cela peut compenser un peu, ce genre d'exemple peut aider a améliorer l'émulateur.

dilinger (./91) :

Si cela peut compenser un peu, ce genre d'exemple peut aider a améliorer l'émulateur.

honnêtement je perds la boule sur ce code. Je tourne en rond pour essayer de le faire fonctionner sur Jaguar et sur virtualjaguar en même temps, mais il suffit que je touche le moindre truc et l'entrelacé ne fonctionne plus d'un coté ou de l'autre...

Essayer de faire marcher ça sur VJ est une mauvaise idée. Je ne sais même pas s'il supporte "officiellement" le mode entrelacé vu que seuls quelques rares homebrews l'utilisent, et aucun jeu officiel. Donc la partie du code de VJ qui gère ça est probablement approximative ou buguée.

Contente-toi de faire marcher ça sur le vrai hardware, c'est déjà assez casse-tête

Zerosquare (./93) :
Essayer de faire marcher ça sur VJ est une mauvaise idée. Je ne sais même pas s'il supporte "officiellement" le mode entrelacé vu que seuls quelques rares homebrews l'utilisent, et aucun jeu officiel. Donc la partie du code de VJ qui gère ça est probablement approximative ou buguée.

Contente-toi de faire marcher ça sur le vrai hardware, c'est déjà assez casse-tête

je suis d'accord. Le problème c'est que sur mon dernier code, c'est la Jaguar qui ne se comporte pas normalement.
j'ai dû inverser le sens de traitement des trames et placer YPOS de l'image sur une ligne impaire...
Heureusement apparemment virtualjaguar traite YPOS de la même façon qu'il soit paire ou impaire

DEATH (./94) :
c'est la Jaguar qui ne se comporte pas normalement.

La Jaguar est ce qu'elle est, c'est au codeur de l'apprivoiser

Zerosquare (./95) :
La Jaguar est ce qu'elle est, c'est au codeur de l'apprivoiser

Ouais enfin la Jaguar elle est buggée aussi. On sais pas si certaines choses sont vraiment possibles.
Amer moi? Mais non

dilinger (./91) :

Si cela peut compenser un peu, ce genre d'exemple peut aider a améliorer l'émulateur.

J'ai dû inclure une boucle dans l'interruption VI pour contourner le problème avec virtualjaguar

en traçant au débugger je m'aperçois que VC est à 0 quand l'interruption VI à lieu (plus exactement $800 en trame impaire et $000 en trame paire) alors que VI est censé se produire à la ligne 506 ou 507

Y a pas comme un problème ?

voici la boucle que j'utilise, j'ai ajouté un chargement de VC dans d1 afin d'observer sa valeur réelle :

; boucle d'attente pour virtualjaguar move.w VC,d0 addq #3,d0 .memeligne: move.w VC,d1 cmp.w d1,d0 bne .memeligne
En plus il faut beaucoup beaucoup beaucoup de boucle pour passer à la ligne suivante ! Je peux garantir que le 68000 ne peut pas exécuter autant d'instruction en une seule ligne.
J'ai tracé pas à pas pendant pas mal de temps, je n'ai jamais vu VC augmenter. Il a fallu que je mette un breakpoint après cette boucle pour pouvoir la passer.

Il vaut mieux mettre l'émulateur de coté. Visiblement, il ne correspond pas aux attentes.
Si tu as une skunkboard, tu peux toujours utiliser la librairie pour communiquer avec le PC et transférer les datas qui t'intéressent.

Sinon il est aussi possible de corriger VJ

Je n'ai jamais utilisé le debugger de VJ, mais est-ce que quand ton 68k breakpoint tous le reste est aussi en pause ?
Car typiquement sur une vrai jag, si tu breakpoint le 68k, le reste tourne encore, donc quand tu lis VC il ne sera pas bon quand tu feras du pas à pas.

SCPCD (./99) :
Sinon il est aussi possible de corriger VJ

Je n'ai jamais utilisé le debugger de VJ, mais est-ce que quand ton 68k breakpoint tous le reste est aussi en pause ?

Oui, toute la machine est arrêté sur virtualjaguar en cas de breakpoint
Après je ne sais pas dans quelle mesure le reste est remis en route quand on fait du pas à pas.
Je pourrai faire un test en lisant HC par exemple.

Le debuggeur est orienté 68K car c'est ce que j'utilises pour le moment.
Oui, quand le 68K breakpoint, tout est en pause. Quand on trace le 68K, les cycles d'exécutions envoyés au 68K et au GPU sont mis à 0 pour garder un contrôle, le DSP reste piloté par la librairie SDL.
Quand on unpause, les cycles reprennent normalement jusqu'au prochain breakpoint ou à la demande de pause.

dilinger (./101) :
Le debuggeur est orienté 68K car c'est ce que j'utilises pour le moment.
Oui, quand le 68K breakpoint, tout est en pause. Quand on trace le 68K, les cycles d'exécutions envoyés au 68K et au GPU sont mis à 0 pour garder un contrôle, le DSP reste piloté par la librairie SDL.
Quand on unpause, les cycles reprennent normalement jusqu'au prochain breakpoint ou à la demande de pause.

tiens au fait j'ai remarqué une petite erreur d'affichage.
c'est uniquement visuel car le code exécuté est bien le bon :

move.l d0,(a0)+ move.l d1,(a0)+ movem.l d0-d1,bmpupdate
sous le débuggeur ça devient :
MOVE.L D0, (A0)+ MOVE.L D1, (A0)+ MVMLE.L A6-A7, $9108

Merci beaucoup pour cette information.
J'ai créé une issue dans
Je penses avoir une piste, il est probable que cela soit une legacy issue également se trouvant dans la version originale de VJ.

dilinger (./103) :
Merci beaucoup pour cette information.
J'ai créé une issue dans

M68K disassembly displays wrong instruction · Issue #30 · djipi/Virtual-Jaguar-RxGitHubUser reports a display disassembly error but the opcode is correct and correctly executed. Source code: move.l d0,(a0)+ move.l d1,(a0)+ movem.l d0-d1,bmpupdate Disassembly: MOVE.L D0, (A0)+ MOVE.L ...

Je penses avoir une piste, il est probable que cela soit une legacy issue également se trouvant dans la version originale de VJ.

J'ai regardé avec virtualjaguar 2.12 et effectivement il y a le même problème

DEATH (./100) :

SCPCD (./99) :
Sinon il est aussi possible de corriger VJ

Je n'ai jamais utilisé le debugger de VJ, mais est-ce que quand ton 68k breakpoint tous le reste est aussi en pause ?

Oui, toute la machine est arrêté sur virtualjaguar en cas de breakpoint
Après je ne sais pas dans quelle mesure le reste est remis en route quand on fait du pas à pas.
Je pourrai faire un test en lisant HC par exemple.

J'ai ajouté HC pour voir et il est bien mis à jour en mode pas à pas, mais VC ne bouge pas.

; boucle d'attente pour virtualjaguar move.w VC,d0 addq #3,d0 .memeligne: move.w HC,d2 move.w VC,d1 cmp.w d1,d0 bne .memeligne

DEATH (./105) :
J'ai ajouté HC pour voir et il est bien mis à jour en mode pas à pas, mais VC ne bouge pas.

Je n'ai pas d'idée pour le moment, je ne me désintéresse pas pour autant de ce problème, il faut juste que je trouves une piste.
Est-ce que tu as essayé d'utiliser ton code / démo sur l'émulateur Phoenix (http://www.arts-union.ru/node/23) C'est des russes qui l'ont développé et ca fait passer beaucoup plus de choses que VJ.

dilinger (./106) :

Est-ce que tu as essayé d'utiliser ton code / démo sur l'émulateur Phoenix (http://www.arts-union.ru/node/23) C'est des russes qui l'ont développé et ca fait passer beaucoup plus de choses que VJ.

ça ne fonctionne pas du tout. Juste un flash au début.

Au passage j'ai légèrement optimisé la boucle principale, ça doit être à 12,5 seconde peut être 12 (chronométré à la main...), pas évident sans comprendre exactement le fonctionnement du pipeline.

Il faudrait que je mette un compteur avec VI mais ma fainéantise m'empêche d'ajouter une routine pour pouvoir lire le résultat d'une façon ou d'une autre... peut être avec skunkCONSOLEWRITE de la Skunkboard...

Je ne sais pas si cela peut-être utile, mais combien de 68K cycles faudrait-il pour avoir un update du HC et du VC?

dilinger (./109) :
Je ne sais pas si cela peut-être utile, mais combien de 68K cycles faudrait-il pour avoir un update du HC et du VC?

Pour HC il est augmenté à chaque cycle d'horloge maître donc environ 37,5ns. Un cycle machine de 68000 c'est 4 cycles d'horloge mais comme elle est divisée par 2 ça fait 8.
Bref, quand le 68000 fait un cycle machine HC a déjà augmenté au minimum de 8.

Pour VC ça va dépendre de la longueur d'une ligne. Il suffit de multiplier (HP+1)*2. typiquement pour une ligne en 60Hz ou 50Hz ça fera environ 1690 cycles d'horloge principale, 845 cycles d'horloge 68000, 211 cycles machine.

Mais ça va aussi dépendre grandement de la charge sur le BUS

Peut être que je n'est pas attendu assez longtemps pour voir VC augmenter en pas à pas....

Dans virtualjaguar en mode pas à pas la valeur de HC semble augmenter bien trop vite par rapport aux cycles du 68000, de plus le bit 11 n'est jamais à 1 et HC semble compter sans s'arrêter jusque 3FF

DEATH (./110) :
Peut être que je n'est pas attendu assez longtemps pour voir VC augmenter en pas à pas....

C'est la question que je me posais.

DEATH (./111) :
Dans virtualjaguar en mode pas à pas la valeur de HC semble augmenter bien trop vite par rapport aux cycles du 68000, de plus le bit 11 n'est jamais à 1 et HC semble compter sans s'arrêter jusque 3FF

Dans le mode trace, les cycles d'exécutions envoyés au 68K et au GPU sont mis à 0 pour garder un contrôle. Cette injection perturbe probablement des synchros.
Pour mes besoins actuels, je n'ai pas besoin d'être synchronisé, je trace du C et de l'asm 68K en alternant avec des breakpoints.
Je suis désolé que ce mode trace 68K ne soit pas compatible avec tes besoins.

dilinger (./112) :

Je suis désolé que ce mode trace 68K ne soit pas compatible avec tes besoins.

C'est juste pour tester et éventuellement pour améliorer la compatibilité de virtualjaguar

Je me suis intéressé à l'affichage proprement dit et c'est une véritable cauchemar.

Pour ça je suis repassé en non entrelacé pour ne pas compliquer les choses et je ne me suis occupé que de l'affichage vertical et uniquement en 60Hz.

Alors en fait en temps normal on ne s'aperçoit pas des problèmes car on ne s'en rend compte uniquement que si on cherche à afficher la totalité d'une image de type NTSC
Soit en non entrelacé : 242p

A moins que je me sois planté en redéfinissant les valeurs de VS, VEB, VDB, VDE, VBB et VBE il n'y a aucune situation idéale.

Si je laisse la valeur de VDE à $FFFF comme préconisé par Atari, l'alignement de l'objet en YPOS est correct mais il manque systématiquement la 1ère ligne.
Cependant la 1ère ligne prend la couleur de BG
En fait cette situation se produit si VDE >= VBB

Si je défini VDE à une valeur inférieur à VBB la dernière ligne est décalée de 1 ou 2 pixels et la position de l'objet en YPOS est décalé d'une ligne vers de bas
De plus, dans ce cas je dois également décaler VDB d'une ligne vers le haut sinon la 1ère ligne ne sera pas affiché et prendra la couleur de BORD1/2

Alors dans le seconde cas je peux comprendre le fait qu'il faille démarrer VDE 1 ligne avant vu que l'OP doit pouvoir construire une ligne en avance mais le décalage de YPOS d'une ligne alors ça...

Quand au premier cas ... je ne sais pas.
J'imagine qu'il faudrait analyser les Netlist pour comprendre la logic de fonctionnement.

J'ai bien essayé quelques autres combinaisons comme VDE=VDB, l'image clignote une VBL sur 2
Ou encore VDE<VDB, ça donne la même chose que si VDE>=VBB, YPOS est bon mais il manque la 1ère ligne...

Chose amusante aussi, si on défini YPOS à une valeur inférieur à VDB, l'image s'affiche quand même mais comme si YPOS était égale à VDB
D'ailleurs du coup, comment fait on si on veut scroller une image vers le haut vu qu'il n'y a pas de valeur négative de YPOS ?

Dernière chose, si je défini le 2ème branch objet (celui qui détecte si VC>YPOS) plus grand que VDB, ça décale tout l'affichage d'autant !

OSCOUR !

Voici un petit exemple.
Uniquement en 60Hz

C'est une image 320*240 constituée de cadres permettant de voir exactement ce qui est affiché sur les bordures au pixel près

Il y a un cadre blanc d'un pixel (ou ligne) tout autour sur le 1er pixel, le 5ème, 10, 20 et 30 pixels avec une indication chiffrée et une flèche pour les 3 premiers. Et ce tout autour de l'image (droit, gauche, bas, haut)
Entre le 1er et le 2ème cadre ainsi que le 2ème et 3ème cadre il y a également des lignes de couleurs différentes pour voir chaque pixel/ligne facilement.
Dans le 1er cadre ça donne donc : blanc (1er pixel), rouge (pixel 2), vert (pixel 3), bleu pixel 4 et blanc (pixel 5)
Puis de nouveau rouge (pixel 6), vert (pixel 7) bleu (pixel) 8, rouge (pixel 9), blanc (pixel 10)

L'affichage est en 242p et l'image de 240lignes est centrée dessus. On voit donc en haut et en bas 1 ligne de la couleur de BG défini exprès en bleu
L'image est également centrée horizontalement avec les valeurs Atari de base.

Voici les valeurs paramétrées pour obtenir un affichage correct :

VS = 518
VBE = 28
VDB = 26
VDE = 510
VBB = 512
VEB = 512

Pour les 2 branch objet au début,
VC > 511
VC < 28

Pour l'objet 320*240
YPOS = 28

Ne pas oublier que les valeurs sont en demie ligne

Donc l'affichage commence ligne 28
VDE doit commencer 2 demie ligne avant pour que l'OP puisse construire la ligne suivante
VDE doit se terminer 2 demie ligne avant VBB sinon la 1ère ligne de l'objet n'est pas affiché (par contre la dernière ligne 242 est bien affiché puisque l'OP traite une ligne en avance)
YPOS de l'objet devrait être de 30 pour être centré puisque l'image fait 240 sur un affichage de 242, mais il faut décaler de 2 vers le haut à cause du bug
On ne voit pas la dernière ligne décalé de 2 pixels puisqu'à ce moment c'est la couleur BG

On a donc :
ligne 1 (28) : BG
ligne 2 (30) : début image (mais YPOS = 28)
ligne 241 (508) : dernière ligne de l'image
ligne 242 (510) : BG

Sur mon moniteur DAEWOO je peux voir toute l'image correctement. Sur virtualjaguar l'image est décalée vers le haut de 4 pixels ce qui ne m'étonne pas, virtualjaguar ne doit pas prendre en compte les subtilités tordues de la Jaguar. D'ailleurs sont elles les mêmes sur toutes les Jaguar ?

Fichier joint : PRO.COF

Si tu veux, tu peux rentrer une issue dans le git de mon Virtual Jaguar Rx, afin de garder trace du problème.
Tu peux aussi fournir un source (le plus court possible de préférence) qui représenterait le problème au mieux. Je ne promets rien, mais sait on jamais, si je trouves quelques choses au hasard de mes rajouts de features.

DEATH (./114) :
Chose amusante aussi, si on défini YPOS à une valeur inférieur à VDB, l'image s'affiche quand même mais comme si YPOS était égale à VDB
D'ailleurs du coup, comment fait on si on veut scroller une image vers le haut vu qu'il n'y a pas de valeur négative de YPOS ?

Dernière chose, si je défini le 2ème branch objet (celui qui détecte si VC>YPOS) plus grand que VDB, ça décale tout l'affichage d'autant !

OSCOUR

Dans le cas ou VDE = FFFF, l'OP est démarré à chaque ligne.
Pour éviter la surcharge et permettre l'affichage des bitmaps à partir de la bonne ligne il faut définir correctement les 2 branches de début en conséquence (en gros pour faire l'équivalent VDB/VDE).

Dans le cas ou VDE /= FFFF, l'OP est démarré à chaque ligne entre VDB et VDE, mais il y a potentiellement des bugs d'affichages (1er et/ou dernière lignes corrompu)


Dans tous les cas, la ligne courante de la bitmap est celle pointée par DATA.
Donc si tu mets un branch obj avant ton bitmap du genre :
branch VC > 511, .stop branch VC < 100, .stop bitmap YPOS= 28, DATA=$10000, HEIGHT=10 .stop: stopl'Obj bitmap ne sera pas mis à jour avant la ligne 100, donc quand la bitmap sera parsé à partir de cette ligne, pour l'OP la bitmap sera toujours valide, ie : YPOS <= VC && HEIGHT > 0.
Du coup dans cette exemple, la bitmap sera affichée sur les 10 prochaines lignes. (à chaque ligne traitée, l'OP va mettre à jour DATA & HEIGHT)

C'est le même principe si l'obj n'est pas parsé en mettant un YPOS < VDB avec un VDE /= FFFF.


Pour scroller vers le haut avec YPOS < VDB, il faut en fait avoir YPOS = VDB et mettre à jour en conséquence HEIGHT & DATA.

SCPCD (./117) :

Oui en effet, en étudiant de nouveau les champs des objets je comprends comment fonctionne l'OP pour l'affichage vertical
On ne peut pas dire que ça facilite la programmation... D'autant qu'à l'horizontal l'OP ne fonctionne pas de la même manière, gère le point 0 et les valeurs négatives

Par contre je ne comprends pas pourquoi je dois décaler la valeur YPOS de - 2 pour démarrer sur la bonne ligne. Bug Jaguar ou erreur dans le code ?

VC est la ligne courante affichée, donc il faut logiquement faire -2 (en non entrelacé) sur YPOS pour prendre en compte le remplissage du linebuffer une ligne avant.

Mais bon, en général on ne se prend pas la tête car en overscan toutes les TV ne sont pas calibrés pareil du coup on n'affiche rien d'important aussi près des bords, donc si on perds quelques lignes haut/bas c'est pas gênant.

SCPCD (./119) :
VC est la ligne courante affichée, donc il faut logiquement faire -2 (en non entrelacé) sur YPOS pour prendre en compte le remplissage du linebuffer une ligne avant.

Mais bon, en général on ne se prend pas la tête car en overscan toutes les TV ne sont pas calibrés pareil du coup on n'affiche rien d'important aussi près des bords, donc si on perds quelques lignes haut/bas c'est pas gênant.

Admettons, mais alors pourquoi si je mets VDE=FFFF ou même VDE=VBB alors je n'ai plus ce décalage de - 2 ? Par contre la 1ère ligne n'est pas affiché.