Mandelbrot POPOPO - Page 3

Autre chose, les calculs de début de l'affichage de l'image se base par rapport aux données fournis dans le fichier include Atari.
Hors les valeurs de la routine de Tyrant (donc zerosquare) ne sont pas les mêmes notamment pour VBE et VBB
Il en résulte un décalage de l'image vers le haut de 5 pixels (je n'ai pas regarder pour l'horizontal mais probablement que c'est décalé aussi)

En vertical il faut donc corriger les valeur soit de VBE et VBB (en les remontant de 5pixels) soit de la 1ère ligne d'affichage de l'image (en la descendant de 5 pixels)

dilinger (./60) :
Ca déchire comme on dit. Et il faut quel genre de budget pour reproduire ton JagFPGA?

Actuellement ça tourne sur un FPGA "mid-range", donc c'est plutôt hors de prix
Une fois que je l'aurai finalisé, je porterai sur un low-cost.

[quote]Zerosquare (./37) :

Salut Zerosquare

Je me suis repenché sur les valeurs de synchro que tu as calculé et je peux me tromper mais j'ai l'impression qu'il y a une erreur.

J'ai regardé pour la synchro horizontal pour le moment car la synchro vertical est plus compliqué à déterminé puisqu'elle peut être compté de plusieurs façons différentes suivant les "écoles", et je ne suis pas sûr de la façon dont la Jaguar gère ça...

Bref, pour commencer comme je l'ai dis plus haut, même dans le code de Tyrant (et donc le miens) il y a une erreur au niveau du centrage de l'image puisqu'on reprend tes valeurs de synchro mais on calcul le centrage en ce basant sur les .equ d'Atari qui se bases sur les valeurs de synchro d'Atari officielles.
Du coup le centrage est décalé autant pour l'affichage que le blanking d'ailleurs.

Pour tes valeurs de synchro, si je ne me trompe pas (...) ça donne une durée de Hsync de 9,5µs. Au lieu de 4,7µs. Et un Front Porch de 3,46µs au lieu de 1,5µs. Ce qui donne une durée de ligne visible de 46µs au lieu de 51,5µs (je crois).
Par contre le Back Porch est bon avec 4,44µs se qui est conforme à la norme NTSC

Alors ? Je me suis planté ou depuis ces valeurs tu as fais des corrections ?
Pour rappel voici les valeurs de ton code :

Init60HzI:
move.w #0,HC
move.w #1,VC
move.w #524,VP
move.w #512,VEB
move.w #518,VS
move.w #5,VEE
move.w #30,VBE
move.w #512,VBB
move.w #844,HP
move.w #1743,HS
move.w #780,HEQ
move.w #595,HVS
move.w #1697,HBB
move.w #118,HBE

Selon moi (si j'm'a pas gouré dans les calcul et si j'ai bien compris comment fonctionnait les registres de la Jaguar)
On devrait plutôt avoir ça pour les synchro horizontale ligne (uniquement, je n'ai pas calculé ni les synchro verticales ni les synchro d'égalisation)
Avec les explications :

Init60HzI:
move.w #0,HC
move.w #1,VC
move.w #524,VP
move.w #512,VEB
move.w #518,VS
move.w #5,VEE
move.w #30,VBE
move.w #512,VBB
move.w #844,HP ; (844+1)*2 1690 ~ 63,5555µs

move.w #1806,HS ; 782*2 1564 1690-1564= ~4,7µs Hsync
; move.w #1743,HS
move.w #780,HEQ
move.w #595,HVS

move.w #1786,HBB ; 762*2 1524 HS-HBB=Front Porch 1564-1524=40 ~1,5µs Front Porch
; move.w #1697,HBB

move.w #125,HBE ; ~4,7µs Back Porch

; total Hblanck period = (~) 4,7µ+4,7µ+1,5µs=10,9µs
; total video display period = (~) 63,5555µs-10,9µs=52,65µs ou 1690-125-40-125=1400=52,65µs

; move.w #118,HBE

Alors ?

Honnêtement j'ai pas retouché à ce code depuis des plombes, il se peut que je me sois planté à l'époque ou que j'ai repris une ancienne version foireuse...
Ceci dit il me semble que j'avais vérifié les signaux à l'oscillo à l'époque, et je me souviens qu'il y a des subtilités dans la doc (du genre que si tu lis pas attentivement, tu tombes dans le panneau).

Je vais essayer d'y rejeter un coup d'œil, mais ça ne sera probablement pas avant le prochain week-end.

[quote]Zerosquare (./65) :


SI, je ne me suis pas trompé dans mes calculs et compréhension des registres, il y a forcément une subtilité quelque part puisque tu as fais une petit programme affichant une image de 1374 pixel en 50Hz, ce qui n'est pas loin du maximum (~1382) en respectant la durée maxi visible de 52µs, 1400 en 60Hz
Alors que dans mes calculs plus haut le code utilisé par Tyrant ne laisserait que 1228 cycle pour la durée visible.

Je n'ai malheureusement plus d'oscillo depuis longtemps pour vérifier.

Bon.... je fais quelques essais pour essayer de comprendre comment fonctionne les valeurs des registres de synchro.... et je commence à avoir mal à la tête...

Sans oscillo difficile de voir à quoi correspond vraiment les registres.

En fait je ne comprends pas d'où part la référence 0 de chaque registre. Le point de départ quoi.
Je pensais que tout était réinitialisé à partir de HP, mais j'ai du coup un sérieux doute...
ça pourrait être réinitialisé à partir de HS.... mais dans ce cas il y a un problème avec HP qui devrait donc avoir une valeur supérieur à la longueur d'une ligne (ça expliquerai les valeurs qu'on trouve dans le BIOS)....

Non vraiment sans oscillo c'est galère.

Il est indiqué dans la doc que VDE doit être égale à #$FFFF sur Jaguar à cause d'un bug.

Mais j'ai essayé de mettre une valeur normal et ça fonctionne très bien. C'est quoi le problème ?

DEATH (./67) :
En fait je ne comprends pas d'où part la référence 0 de chaque registre. Le point de départ quoi.

Je me souviens plus (faudrait que je relise), mais c'est pas simple et de mémoire il y a un ou plusieurs pièges.

DEATH (./68) :
Il est indiqué dans la doc que VDE doit être égale à #$FFFF sur Jaguar à cause d'un bug.

Mais j'ai essayé de mettre une valeur normal et ça fonctionne très bien. C'est quoi le problème ?

C'est pas documenté, mais en pratique ça affiche un pixel parasite qui scintille au début de la dernière ligne. Je sais pas s'il y a d'autres effets secondaires, en tout cas j'en ai pas observés. Peut-être que ça dépend de la révision du hardware.

Je crois que je commence à comprendre commence fonctionne le comptage à l'horizontal.... c'est en 1/2 période de ligne j'ai l'impression, et non depuis le tout début de ligne

si HP fait (844+1)*2 alors la moitié d'une ligne c'est 844+1 et toute les valeurs qui sont sur la 2ème moitié doivent être compté à partir de la 2ème moitié et non du début

Moi je faisais bêtement pour HS par exemple : HS=HP-4,7µs (période de Hsync en 60Hz) et donc je calculais 1690-125 (~4,7µs) = 1565/2 = 782 (pour avoir la valeur de la 2ème moitié) auquel j'ajoute #$400 pour dire que c'est sur la 2ème moitié.

MAIS NON, parce qu'il faut compter à partir de la 2ème moitié et non du début de ligne (il faut retrancher la valeur de HP+1)

Donc ça fait : 1690-125=1565-(844+1)=720 !! et non 782.... (à 1 ou 2 cycle près)

Faut que je recalcul toutes les valeurs horizontal... mais du coup je vais retomber sur les valeurs que tu avais mises

Oui tout est compté en demies-lignes.

Zerosquare (./71) :
Oui tout est compté en demies-lignes.

Oui en recalculant les valeurs comme ça je retombe sur les mêmes que toi

j'ai quand même un problème avec ma TV car si je ne met pas la couleur de la bordure à 0, j'obtient des couleurs anormale de l'écran.
Si je met une couleur de bordure et que je décale un peut plus HBE l'effet s'estompe, si je décale encore plus ça disparaît.
J'avais modifié les réglages de ma TV il y a très longtemps avec le service mode afin de voir toute l'image mais elle n'est pas vraiment prévu pour ça et je me demande si ça ne décale pas la prise en compte du Hblank

Il est quand même complexe ce hardware

Brunni (./73) :
Il est quand même complexe ce hardware

C'est parce qu'à la base c'était un chipset graphique pour aller sur différentes machines (Falcon...) pour tout type d'écran.

donc la partie affichage/synchro vidéo est entièrement paramétrable (comme le videl sur Falcon)

Zerosquare (./71) :

Je viens de voir ce qui ressemble à un bug et qui semble être présent dans toutes les routines entrelacées que j'ai pu voir (basé sur ton code à priori)

Dans le code actuel ça ne change pas l'affichage mais ça peut potentiellement faire foirer d'autres chose
J'ai eu un doute en étudiant le code et j'ai eu à priori confirmation en traçant pas à pas sous virtualjaguar

Dans la routine d'interruption VI du 68000, on vérifie si on se trouve dans la trame paire ou impaire , puis on change la ligne d'interruption VI en fonction du résultat.
Par exemple en 60Hz l'interruption se produira alternativement à la ligne 507, 506, 507, 506.... (ou une autre valeur mais paire puis impaire)

Le problème :
imaginons que l'interruption se produise à la ligne 507.
Ok, on modifie VI pour que la prochaine interruption se produise à la ligne 506 de la trame suivante.
La trame passe... pas de problème
On arrive alors à la ligne 506 de la trame suivante
On modifie VI pour que la prochaine interruption se produise à la ligne 507 de la trame suivante..... mais actuellement on est à la ligne 506...
Du coup en relâchant l'interruption à ce moment, il y a toute les chances que l'interruption se reproduise juste après en passant à la ligne 507 !!
A moins que la libération de l'interruption se passe après la ligne 507, donc que le code de l'interruption soit relativement long (+ d'une demie ligne...)
Ca ne provoque pas de bug au niveau de la gestion de l'entrelacé puisqu'on test VC pour voir dans quel trame on est mais quand même.

Sous virtualjaguar ça se confirme. J'ai un compteur qui s'incrémente à chaque interruption VI. Et bien une fois sur 2 le compteur s'incrémente de 2 au lieu de 1 se qui confirme que l'interruption à lieu 2 fois 1 VBL sur 2

Alors ? Bug ou j'ai mal analysé ?

Pour autant que je me souvienne, il me semble l'interruption VBL ne peut être déclenchée qu'en début de ligne, et donc que le bug que tu décris ne peut pas se produire (et ça a aussi une conséquence en mode non entrelacé : si tu te plantes sur la parité de la valeur, tu n'as pas d'interruptions VBL du tout).

Je ne ferais pas confiance à Virtual Jaguar sur ce point, il n'est pas toujours très fidèle au hardware réel quand on creuse les cas particuliers.

DEATH (./74) :

Brunni (./73) :
Il est quand même complexe ce hardware

C'est parce qu'à la base c'était un chipset graphique pour aller sur différentes machines (Falcon...) pour tout type d'écran.

donc la partie affichage/synchro vidéo est entièrement paramétrable (comme le videl sur Falcon)

Absolument, le chipset de la Jaguar avait été prévu servir aussi de base à un micro-ordinateur (un peu le contraire de ce qui s'est passé pour l'Amiga 1000). Il y a d'ailleurs des fonctionnalités qui sont complètement inutilisées dans la console, comme le genlock d'un signal vidéo ou la compatibilité avec des processeurs non-68k (qui a servi pour faire les bornes d'arcade CoJag qui ont un CPU MIPS).

(si un jour je vide ma todolist, faudra que je fasse une Jaguar à x86 )

Intéressant
T’as des exemples de jeu pour la borne d’arcade jagMIPS ?

Y'en a un qu'un seul qui est sorti malheureusement, et c'est un jeu de tir au light gun 100% FMV. Donc honnêtement ça n'a pas grand intérêt, ni sur le plan du gameplay (répétitif au possible, même si certains apprécient) ni sur le plan technique (à part la vidéo, ça exploite très peu le hardware) :


Y'avait un jeu de baston 2D en chantier aussi, mais c'est resté un proto pas fini :

Ah ouais, rien que n'aurait pu faire une autre console de l'époque. Ça aurait été intéressant

Zerosquare (./76) :
Pour autant que je me souvienne, il me semble l'interruption VBL ne peut être déclenchée qu'en début de ligne, et donc que le bug que tu décris ne peut pas se produire (et ça a aussi une conséquence en mode non entrelacé : si tu te plantes sur la parité de la valeur, tu n'as pas d'interruptions VBL du tout).

Je ne ferais pas confiance à Virtual Jaguar sur ce point, il n'est pas toujours très fidèle au hardware réel quand on creuse les cas particuliers.

Plus exactement, l'interruption se déclenche en fin de ligne selon la condition suivante : (HC = HDE) && (VC = VI)

Merci pour la précision

Zerosquare (./79) :
Y'en a un qu'un seul qui est sorti malheureusement, et c'est un jeu de tir au light gun 100% FMV. Donc honnêtement ça n'a pas grand intérêt, ni sur le plan du gameplay (répétitif au possible, même si certains apprécient) ni sur le plan technique (à part la vidéo, ça exploite très peu le hardware) :

Plus exactement il y a eu 3 jeux. Area 51, maximum force et area51/maximum force duo. 3 rails shooter. En FMV pour le décore arrière, mais très certainement des objets (gros et avec beaucoup d'images) pour tout le reste voir même pour certaines parties du décore destructible.
Il y a également eu 3 autre jeux mais uniquement à l'état de prototype (jouables sous mame d'ailleurs)

Brunni (./80) :
Ah ouais, rien que n'aurait pu faire une autre console de l'époque. Ça aurait été intéressant

Je ne crois pas que ni la 3DO, la Saturn ou encore la playstation aurait pu reproduire fidèlement (pixel perfect) les 3 rail shooter de la Cojag.
Contrairement à ce qu'on peu lire parfois la (les) CoJag n'étaient pas des versions améliorées de la Jaguar. L'unique point commun c'était qu'elles contenaient le chipset de la Jaguar, TOM et Jerry.
Tout le reste est différent. A priori TOM et Jerry seraient cadencés à la même vitesse que sur Jaguar, mais ça reste à confirmer. Le CPU est remplacé par un 68020 à 25Mhz pour la 1ère version d'Area 51 puis par un mips R3000 à 33Mhz ensuite.
Suivant les versions et jeux la RAM est de 4 ou 6Mo et il existe des modèles avec la possibilité de mettre 8Mo (mais je ne sais pas si un des jeux l'exploite).
Les 3 rail shooter et le prototype du jeu de baston sont stockés sur disque dur, + de 500Mo pour area 51 et vicious circle, + 1Go et + 1,6 pour maximum force et maximum force duo. Les autres jeux sont sur ROMs
Une autre différence si ça ne suffisait pas, peut être pas toutes les cartes je ne sais pas, les ROMs sont sur un BUS de données de 64bits.
Bref je vous laisse imaginer la complexité et la puissance de ces joujoux.

Je ne suis pas sûr qu'aucun des jeux n'exploite vraiment la puissance des Cojag, mais pour les Jeux avec FMV je vois mal une console de l'époque faire aussi bien, notamment à cause des très gros graph des objets en 65K couleurs qu'il faut stocker en mémoire (à la rigueur une Saturn avec la cartouche d'extension 4Mo)

Par contre pour les 2 autres jeux, Freez et Fishin frenzy là oui. Il est même possible qu'une Jaguar puisse les faire tourner.

DEATH (./83) :
Plus exactement il y a eu 3 jeux. Area 51, maximum force et area51/maximum force duo.

Je n'ai pas cité Area 51 parce qu'il a d'abord été développé pour la CoJag à CPU 68K (ni le combo du coup, puisque ça ne fait que reprendre deux jeux qui existaient déjà).

DEATH (./83) :
Je ne crois pas que ni la 3DO, la Saturn ou encore la playstation aurait pu reproduire fidèlement (pixel perfect) les 3 rail shooter de la Cojag.

Je ne sais pas si c'est pixel-perfect, mais la version PS1 de Maximum Force n'a pas l'air vraiment inférieure à la version CoJag :


La version Saturn n'est pas très éloignée non plus :

DEATH (./83) :
Par contre pour les 2 autres jeux, Freez et Fishin frenzy là oui. Il est même possible qu'une Jaguar puisse les faire tourner.

Ceux-là je les ai délibérément pas cités, tellement c'est du gâchis comparé à ce dont le hardware est capable.

Zerosquare (./84) :

Je ne sais pas si c'est pixel-perfect, mais la version PS1 de Maximum Force n'a pas l'air vraiment inférieure à la version CoJag :

Elle l'est pourtant pas mal.

La version Cojag est en 360*240, sur PS1 ça doit être 320 voir même peut être 256, et elle n'est pas en plein écran
Mais surtout, la vidéo est super compressée sur PS1 c'est franchement cradoc
Après il faudrait vérifier en détails mais probablement que les animations des objets comportent moins d'images.
Pas sûr non plus que la version PS1 soit en 65K couleurs.

Les 2 sont jouable via émulateur et la différence est assez flagrante.

Pour en revenir au code, j'ai changé le mode de détection des trames paire ou impaire parce qu'en fonction de l'initialisation des registres, du moment où ils sont paramétré, du moment où le programme prend la main, de la vitesse du vent et de l'âge du capitaine, le résultat est parfois incertain.
J'avais un doute alors j'ai déplacé VI et VBB plus haut afin d'être dans la zone visible, j'ai inclus un changement de couleur de BORD1 en début d'interruption puis un autre un peu plus loin.

Résultat, avec la routine qui test le bit 12 de VC, en fonction de quand le programme prend la main, de l'endroit où les registres vidéo sont initialisé, etc. je ne sais pas si c'est un bug de la Jaguar ou du btst ou... bref j'ai des résultats aléatoire comme expliqué au tout début de ce sujet.
Soit les lignes paire et impaire sont inversées, soit il maque une trame sur 2, soit ça fonctionne.... Alors il y a des cas ou ça fonctionne à 100% mais c'est un peu la loterie si je change une valeur quelque part.

Mais grace au changement de couleur de BORD1 j'ai pu voir que l'interruption à bien lieu au bon moment à chaque trame (la routine n'a pas le même nombre d'instruction en fonction de la ligne paire ou impaire).

Du coup au lieu de tester le bit 12 de VC et que tout le fonctionnement de l'entrelacé repose dessus, je bascule l'état du bit 0 de VI à chaque trame quoi qu'il arrive et je test également son état pour savoir si on est sur une ligne paire ou impaire. Ca fonctionne à tous les coups.

En gros voilà le code avant :
btst.b #(11-8),VC ; we're testing bit 11 (the 12th bit) of VC but... bne .bottom ; btst only works on bytes when operating on memory ; top field ori.w #1,vi_line ; set line next VI will occur on move.w vi_line,VI ; and set it (VI is write-only) bra .done .bottom: ; bottom field andi.w #$fffe,vi_line ; set line next VI will occur on move.w vi_line,VI ; and set it (VI is write-only) add.l #((BMP_PHRASES)<<11),(a0) ; add IWIDTH to DATA to start one line lower .done:
et après :
move.w vi_line,d0 eori.w #1,vi_line ; set line next VI will occur on move.w vi_line,VI ; and set it (VI is write-only) ; test de VI donc de la ligne en cours qui semble être plus fiable que de tester le bit 12 de VC btst #0,d0 beq .done ; top field ; bottom field add.l #((BMP_PHRASES)<<11),(a0) ; add IWIDTH to DATA to start one line lower .done:

Pour ton code "avant", je ne suis pas convaincu que les accès en byte des registre 16-bit soient correctement géré dans la jag.
En tout cas, dans le doute je déconseille fortement de faire ce genre "d'optimisation"

SCPCD (./87) :
Pour ton code "avant", je ne suis pas convaincu que les accès en byte des registre 16-bit soient correctement géré dans la jag.
En tout cas, dans le doute je déconseille fortement de faire ce genre "d'optimisation"

c'est le code que j'avais repris de Tyrant, qu'il avait peut être repris de Zerosquare (mais pas sûr)

Mais il y a une autre subtilité...

Le code en question ne fonctionne QUE si l'image à afficher est sur un YPOS paire.
Si on veut afficher une image avec un YPOS impaire, il faut inverser le traitement des trames....

Le code ressemble donc à :
Si ligne (trame) paire et YPOS paire : DATA = DATA
Si ligne (trame) impaire et YPOS paire : DATA = DATA+IWIDTH

Si ligne (trame) paire et YPOS impaire : DATA = DATA+IWIDTH
Si ligne (trame) impaire et YPOS impaire : DATA = DATA

MAIS, il y a une autre subtilité....
je ne sais pas à quoi c'est dû, peut être un bug (encore) de la Jaguar), en fonction des valeurs de VBB, VBE, VDE, VDB... que sais je encore
Il peut y avoir un décalage paire-impaire dans les première valeur de YPOS...

Dans mon code actuel qui reprend le code d'origine, sans toucher aux registres vidéo "sensible" et en utilisant les valeurs Atari pour le centrage de l'image, pour toutes les valeur de YPOS comprise entre 0 et 32 (environ je crois), les trames sont systématiquement inversées comme si YPOS était toujours impaire.

L'affichage en entrelacé n'est déjà pas évident... mais la c'est le casse tête chinois !!

Ca a l'air bien compliqué l'entrelacement sur Jaguar.
J'avais essayé sur Falcon et dans mes souvenirs c'était bien plus simple: y'avait juste un bit à mettre pour activer l'entrelacement et un autre bit contrôlait le mode d'entrelacement. Soit les trames était affichés les unes par dessus les autres, soit elles était vraiment entrelacées.
Evidemment dans le TOS (4.02 en tout cas), en mode entrelacé c'est le mode d'affichage "par dessus" qui était utilisé. Ca nuisait pas mal la lisibilité.
Au début je pensais que c'était normal et que le mode entrelacé était censé être vraiment ignoble comme ça.
Quand ST Mag (en 1995...) a enfin publié un article sur le VIDEL, j'ai découvert le fameux bit et le vrai mode entrelacé! Ca améliorait pas mal la lisibilité.

DrTypoFr (./89) :
Ca a l'air bien compliqué l'entrelacement sur Jaguar.

C'est compliqué parce qu'il n'y a aucune information pertinente dans la documentation de la Jaguar pour l'utiliser. Soit parce qu'ils n'ont pas pensé que quelqu'un l'utiliserait, soit parce que ce mode est tout bugué.

Quoi qu'il en soit, la dernière version que j'ai faite fonctionne impeccablement bien sur une vraie Jaguar, mais plus sur virtualjaguar !!

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....