NEO-ARCADIA

Le forum d'arcade francophone
Nous sommes le 19 oct. 2019, 22:07

Fuseau horaire sur UTC+02:00




Publier un nouveau sujet  Répondre au sujet  [ 43 messages ]  Aller à la page 1 2 Suivant
Auteur Message
MessagePublié : 19 févr. 2013, 20:47 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Un petit topo vite fait sur les modelines et la façon de designer les timings de l'affichage pour les PCB dans le milieu arcade, façon qui diffère avec le matos prévu pour le marché domestique.
Le matos arcade est prévu pour tourner en RGB (sans codage de couleurs), donc y a de bonnes libertés prises par rapport au standard NTSC et les chiffres associés. Mais y a quand même certaines contraintes à respecter, les chiffres ne sortent pas d'un chapeau non plus.

Le problème de la génération de modeline, c'est justement qu'on peut balancer à peu près n'importe quoi comme chiffres...
D'où le fait qu'on ne trouve jamais de modelines qui soient fidèles aux systèmes émulés, même si elles sont valides et que l'écran affiche quand même une image.

Tout d'abord, une petite représentation du signal video d'un système prévu pour une résolution de 384x224 :

Image

( Par convention, on place d'abord les périodes de synchro, et on termine par les front porchs. Du point de vue du système, c'est un intervalle continu bien sûr, c'est ce qu'on appelle la période de blanking :
qui comprend front porch, puis sync, puis back porch)


Toutes les données sont indiquées, je remets la modeline :
Code :
Modeline "384x224"   7.500   384 400 435 486   224 240 243 259  -hsync -vsync
cette modeline donne bien le taux de rafraîchissement vertical indiqué par MAME : 59.583393 hz.

Mais ça ne correspond pas à une fréquence de 15.734 kHz (NTSC), ni même aux alentours de 15.720 kHz (utilisé pour faire du 60 hz tout rond avec 262 lignes).
La fréquence est de 15.432 kHz. On est même en dessous du PAL (15.625 kHz).

Pour comprendre ça, il faut avoir à l'esprit que les cartes arcade se contentent du "minimum" au niveau affichage : la résolution visible, plus les porchs/synchro. Contrairement à un système domestique, il n'est pas question d'inclure des bordures autour de l'image utile (comme on peut le voir sur une Megadrive par exemple, qui affiche 240 lignes même si le jeu en fait 224), et de prévoir un pixel clock basé sur la fréquence du color burst du signal NTSC (multiple de 3.59 Mhz).

Ici, pour 224 lignes affichées, on place deux gros porchs de 16 lignes, et on place 3 lignes de synchro, de façon à respecter le délai de 2 ms requis par les moniteurs. Ca nous fait un total de 259 lignes, au lieu de 262... Mais c'est pas grave, de nombreux systèmes arcade n'affichent pas 262 lignes (cf le MVS : 264 lignes), et ne visent pas un taux de 60 hz. Faut que ça dure aux alentours de 16.7 ms, peu importe le taux.

Les chiffres servant à constituer cette modeline respectent les infos piochées dans le code source de MAME ( cps3.c )
Code :
 2487      /* video hardware */
 2488      MCFG_SCREEN_ADD("screen", RASTER)
 2489      MCFG_SCREEN_RAW_PARAMS(XTAL_60MHz/8, 486, 0, 384, 259, 0, 224)
 2490      MCFG_SCREEN_UPDATE_DRIVER(cps3_state, screen_update_cps3)
 2491  /*
 2492      Measured clocks:
 2493          V = 59.5992Hz
 2494          H = 15.4335kHz
 2495          H/V = 258.955 ~ 259 lines
( note : les mesures relevées reflètent le délai de propagation global du système, chaque composant ajoutant son propre délai dans la chaîne. Il faut toujours viser un peu en dessous pour déterminer comment l'affichage a été pensé )

Examinons la ligne intéressante :

(XTAL_60MHz/8, 486, 0, 384, 259, 0, 224)

Ces valeurs correspondent aux variables suivantes qui déterminent l'affichage :
Code :
MCFG_SCREEN_RAW_PARAMS(PIXEL_CLOCK, HTOTAL, HBEND, HBSTART, VTOTAL, VBEND, VBSTART)
Ca donne :

- PIXEL_CLOCK = pour le CPS3, un oscillateur de 60 MHz divisé par 8, ce qui nous donne 7.5 Mhz .
- HTOTAL = nombre total de pixels par ligne : 486
- HBEND = la fin de la période de blanking. Ici, ça correspond au début de l'affichage de l'image, au pixel n° 0
- HBSTART = le début de la période de blanking, soit à la fin de l'image, à partir du pixel n° 384

>> Avec ça, on détermine l'interval de blanking : 486 - 384 = 102 pixels.
Mais par contre, on connaît pas la répartition entre la synchro, le back porch et le front porch... (j'y reviens après)

- VTOTAL = nombre de lignes total (259)
- VBEND = fin du blanking (0)
- VBSTART = début du blanking (224)

>> 259-224 = 35 lignes. Mais là aussi, on connaît pas la répartition...

Pour déterminer ce qui se passe pendant l'interval de blanking, il faut déjà avoir en tête les standards des moniteurs.
- pour l'horizontal, il faut environ ~ 4.7 µs de Hsync
- en vertical : ~ 200 µs de Vsync.

Pour déterminer ça, je me suis basé sur les données du MVS, système bien documenté. Pour la Hsync, ils se sont tenus à 4.63 µs (soit 27.75 pixels pour la modeline correspondante, qu'on arrondit à 28). Ici, 35 pixels nous donnent 4.67 µs.
Et avec ce chiffre, on arrive à avoir une proportion :
Hsync + front porch = back porch
35 + 16 = 51

C'est ce que j'ai constaté sur pas mal de systèmes, ça semble être une règle, et ça explique en partie pourquoi le nombre total de pixels par ligne n'est pas un multiple de 8, bien commode pourtant ( ici pour le CPS 3, on aurait pu avoir un pixel clock de 8 Mhz et 512 pixels au total, vu que 512 c'est un joli 64x8 ).

En vertical, 3 lignes donnent 194 µs (on le constate aussi sur les systèmes domestiques).
Il nous reste donc 32 lignes pour les porchs. Normalement, le front porch est toujours plus petit que le back porch, mais en arcade, on compte aussi sur ces porchs pour centrer l'image, sans avoir besoin d'inclure une bordure autour de l'image. Comme pour le MVS, 32 lignes ça nous donnes deux bons porchs de 16 lignes.

Donc, tous les chiffres sont justifiés, la modeline correspond bien à ce qu'indique MAME, et les infos manquantes correspondent aux standards des moniteurs et la façon de gérer les porchs comme on le constate pour d'autres systèmes arcade (qui diffère de ce qui se fait à domicile).

Bref, c'est LA modeline du CPS3, et pas aut' chose :P . Ce n''est pas celle des CPS 1 et 2, ni celle d'un autre système qui affiche aussi 384x224.
Et j'ai eu beau chercher sur le net, je n'ai rien trouvé qui s'en rapproche. Les modelines donnent 262 ou 261 lignes (?), y a pas le même nombre de pixels total, le pixel clock est jamais à 7.5 Mhz (des fois plus de 8 Mhz), et les infos du blanking sortent des standards des moniteurs ( plus de 5µs pour le Hsync). Ca passe quand même, mais c'est pas la joie, et les différences de timings se traduisent par des artefacts, ou le recours aux options de synchro (wait for sync, tripple buffering) des émulateurs, qui induisent du lag. C'est bien beau d'avoir de jolies scanlines, mais faut que ça réponde au stick, faut que le timing soit OK.


Maintenant qu'on a cette superbe modeline du pixel parfait et de la parfaite synchro, c'est pas dit que le chassis de son tube cathodique puisse gérer le signal... (15.432 kHz, c'est un peu bas).

Il va falloir bidouiller un peu. Alors, on conserve la structure globale de la modeline (pour respecter les proportions active display/blanking ), et on ajuste un seul paramètre : le pixel clock.
Pour revenir à des paramètres proches de son écran, on peut faire le calcul simple :

486 lignes x 15625 hz = 7593750 hz. Ca nous donne un taux vertical de 60.33 hz

On est un peu au dessus de 60 hz, et y a quand même de la marge en dessous du taux standard de 15.625 kHz du PAL.

Donc, on va viser un beau 60 hz tout rond :

60 x 259 = 15540 hz
15540 x 486 = 7552440 hz

La modeline correspondante :
Code :
Modeline "384x224"   7.552440   384 400 435 486   224 240 243 259  -hsync -vsync
C'est comme si on avait remplacer l'oscillateur de 60 Mhz sur la PCB par un oscillateur de 60.41952 MHz (soit un écart de 0.007 %).
Mais on a pas changer la structure du système, on va pas lui demander d'afficher 500 pixels au lieu de 486, ni 262 lignes au lieu de 259. Tout reste identique en proportions, et donc en nombre de cycles.

Ce type d'overclok se fait officiellement pour la Neo Geo, à savoir que l'oscillateur de base à 24 MHz du MVS est remplacé par un oscillateur de 24.1678 MHz sur les dernières révisions de carte mère AES.
Mais pour 24 ou 24.1678 MHz, une ligne complète est toujours constituée en 1536 cycles.



Maintenant, autre cas :

votre écran accepte sans broncher la modeline officielle 8) , mais c'est votre carte graphique qui fait défaut :
manque de bol, elle descend pas en dessous de 8 MHz (voire 10...). :?

On peut pas doubler la résolution horizontale, car 486 px, ça donne 972 , on est au delà du PAL (945 maxi, pour un pixel clock de 14.75 Mhz).
Pas de panique, on va simplement procéder à une augmentation de 150 % :
le pixel clock passe de 7.5 mHz à 11.25 Mhz. Là on est bon. :)

Mais y a pas que le pixel clock qui augmente de 150 % : tout ce qui est à l'horizontal l'est aussi !

H_DISP = 384 > 576
H_FPORCH = 16 > 24
H_SYNC = 35 > 52.5
H_BPORCH = 51 > 76.5

Note: il faut arrondir les valeurs pour les modelines :
Hsync + Bporch = 129, soit 53 + 76


Ainsi, on obtient la modeline suivante :
Code :
Modeline "576x224"   11.25   576 600 653 729   224 240 243 259  -hsync -vsync
Et magie, on conserve toujours le même taux vertical, la même durée pour la synchro et les porchs.
Rien n'a changé à la verticale.

On obtient ceci :

Image

Ici, l'image a été étirée à l'horizontal sans interpolation, ce qui nous donne des alternances de colonnes qui font 1 ou 2 pixels de large. C'est dans ce cas précis qu'une interpolation bilinéaire est souhaitable. La petite dégradation n'affecte pas les lignes entre elles, seulement les transitions à l'horizontal sont lissées. On conserve une précision de ligne "scanline powa !"

Comparez (exemples doublés verticalement pour se donner une idée) :

- 576x224, bilinéaire :

Image

- 576x224 non filtré :

Image

Sur un CRT, la différence entre une image 384x224 et une 576x224 filtrée en bilinéaire est minime, faut avoir le nez collé à l'écran pour constater la dégradation. Par contre, lors des scrollings, on se rend compte de l'irrégularité du rendu 576x224 non filtré.

La suite bientôt (exemple de l'affichage d'un système domestique, avec la modeline exacte).
Stay tuned. 8)


Dernière modification par Epsylon le 23 févr. 2013, 20:20, modifié 1 fois.

Haut
   
MessagePublié : 19 févr. 2013, 21:41 
Hors-ligne
Life is life
Avatar de l’utilisateur

Inscription : 06 juin 2005, 22:04
Messages : 8433
Localisation : Paris 13eme
Pfou! 8O

_________________
Image
"C'est abusé on voit mal les persos dans ce niveau, même les boules d'énergie on les voit pas!!" Paroles de Sac


Haut
   
MessagePublié : 20 févr. 2013, 01:23 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
La suite, avec une machine que j'affectionne particulièrement : la Megadrive de Sega. 8)

Deux modes graphiques sont disponibles : H32 et H40, soit 256 ou 320 pixels par lignes.
Ces modes sont déclinés en NTSC et PAL, et en entrelacé (cf le mode deux joueurs de Sonic 2).

On va juste s'occuper du NTSC non entrelacé, en 224 lignes. Donc : 256x224 et 320x224 .

L'horloge principale (Master Clock) de la MD est basé sur une multiplication du color burst NTSC :

3.579545 x 15 = 53.693175 MHz

[ note : de là on dérive la fréquence du 68000 : en divisant par 7, on obtient 7.67 MHz et des brouettes, pour un processeur donné à 8 MHz ]

Le signal NTSC était originellement à 15.750 kHz pour 60 Hz, 525 lignes. En passant à la couleur, il a été décidé de ralentir légèrement ce signal, de façon à placer les porteuses son et couleur (color subcarrier, qui donne le fameux color burst qui nous intéresse ici). On est passé à 15.734 kHz et 59.94 Hz. Oui mais pour du 525 lignes entrelacé, soit 262.5 lignes par trame.
Or, le signal nommé 240p, c'est un signal non standard, en ce sens qu'il supprime la fameuse demi ligne de l'entrelacement. Donc, 262 lignes nous donnent non pas 59.94 Hz mais 60.05 Hz. Aussi, on tend à baisser la fréquence horizontale, de façon à rester au plus proche du taux NTSC : 15.7 kHz pour 59.92 Hz.

Le processeur graphique de la MD est une évolution de celui de la Master System, on retrouve les paramètres de celui ci. Pour le mode H32 (256x224), le pixel clock est déterminé par une division par 10 : 5.3693175 MHz .

Divisé par la fréquence désirée (15.7 kHz), ça donne environ 342 pixels au total. Les infos du blanking sont basées autour de 20% de ce total. Ca donne 284 pixels par ligne environ pour la partie visible (active display). Et dans ces 284 lignes, on affichera les 256 qui constituent l'image du jeu à proprement parler.
La partie visible est donc constituée d'une bordure à gauche, du contenu du jeu (32 tiles de 8 pixels), et d'une autre bordure à droite. Le reste est dédié aux porchs et à la synchro horizontale. C'est le temps disponible entre deux lignes (notamment pour les rasters effects : parallaxes et autres distorsions, ou changement de palette à la volée).
26 pixels sont dédiés à la synchro horizontale (4.84 µs), le back porch est pratiquement de même taille (28 px, c'est au cours de celui ci que doit se produire le color burst), et on termine par un court front porch (8 px).

C'est la même chose pour les lignes verticales : 224 lignes pour le jeu, plus des bordures de 8 lignes en haut et en bas pour coller au standard de 240 lignes. Le reste (22 lignes) est l'intervalle de blanking vertical : 3 lignes de synchro (191 µs), un front porch de 3 lignes, et un back porch de 16. On obtient bien 262 lignes.

Pour le standard vidéo domestique, le front porch est toujours plus court que le back porch, on reste à 262 lignes, on se tient au plus proche du standard NTSC.

Maintenant, voici une représentation du signal (ici le Special Stage de Sonic CD, le jeu switch entre les deux modes, même s'il y a des jeux MD qui ne fonctionnent qu'en H32) :

Image

La modeline correspondante :
Code :
Modeline "284x240"   5.369318   284 292 318 342   240 243 246 262  -hsync -vsync
C'est la modeline du mode H32 de la MD. Ce n'est pas celle de la Master System, ni celle de la Snes, ni de la PC Engine, qui fonctionnent aussi en 256x224.

A la rigueur, on peut supprimer les bordures, et les intégrer dans les porchs, mais faut respecter le positionnement et conserver le même nombre de pixels total :
Code :
Modeline "256x224"   5.369318   256 279 305 342   224 235 238 262  -hsync -vsync
En horizontal, on a : back porch + 13 , front porch + 15
En vertical: back porch + 8 , front porch + 8

Si ça intéresse quelqu'un, je ferais le détail du mode H40, y a des subtilités à ce niveau. Et je ferais aussi le détail des Nes/Snes (là ça devrait attirer plus de monde :P ).
Voilà, pour tout ceux qui s'intéressent à la fidélité de l'émulation, et avec le moins de lag possible.


Dernière modification par Epsylon le 23 févr. 2013, 20:22, modifié 2 fois.

Haut
   
MessagePublié : 20 févr. 2013, 01:38 
Hors-ligne
stick dans le cul
Avatar de l’utilisateur

Inscription : 24 avr. 2010, 20:45
Messages : 12166
Localisation : DTC
grand fou :o 8)

_________________
Defi Shmup en cours : R-Type

Kretinou
Citation :
L'original et l'émulation c'est comme au Bois de Boulogne. Pour 100 euros tu peux te faire sucer par la plus belle des putes slaves ou gratos par un beau travestis. Tu peux vivres avec cette idée mais ca reste que t'es un peu pd.


Haut
   
MessagePublié : 20 févr. 2013, 08:26 
Hors-ligne
stick de rhodium

Inscription : 09 janv. 2004, 20:17
Messages : 3872
Localisation : Paris now
Très détaillé tout ça epsylon, merci pour tes posts la dessus :wink:

_________________
Image


Haut
   
MessagePublié : 20 févr. 2013, 12:50 
Hors-ligne
stick de platine
Avatar de l’utilisateur

Inscription : 11 mars 2011, 14:05
Messages : 2636
Localisation : 93 Montfermeil
Toujours aussi complet tes posts et au bout de la 3eme relecture j'arrive à comprendre :idee:

Vivement la suite.

_________________
Image


Haut
   
MessagePublié : 20 févr. 2013, 18:53 
Hors-ligne
Stick-o-phile
Avatar de l’utilisateur

Inscription : 29 août 2004, 23:47
Messages : 20451
Localisation : Lormont (à côté de Bordeaux)
Le vrai Epsylon est de retour 8)


Haut
   
MessagePublié : 20 févr. 2013, 19:02 
Hors-ligne
stick de diamant
Avatar de l’utilisateur

Inscription : 12 oct. 2006, 20:40
Messages : 6110
Localisation : Lyon
Citation :
Le vrai Epsylon est de retour 8)
+1000

Jte prefere vraiment comme ça plutot que dans ton delire de puissance skizophrene...

La question que je me pose c est quel taff tu fais pour connaitre tout ça... Jme refuse a penser que c est uniquement tes passions qui t ont conduit a emmagasiner autant d'info technique...?

Pas contre tu devrais plutot editer ton premier post pour rassembler ses pertinentes infos non ?

_________________
Citation :
Vous avez des tutos pour gagner l'evo ?


Haut
   
MessagePublié : 20 févr. 2013, 21:22 
Hors-ligne
stick d'or
Avatar de l’utilisateur

Inscription : 26 août 2005, 19:02
Messages : 1468
:agenoux:

_________________
Comme disait mon grand-père tout les ans il y a de plus en plus de cons, mais cette année j’ai l’impression que les cons de l’année prochaine sont déjà là.


Haut
   
MessagePublié : 21 févr. 2013, 02:01 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
La suite :

toujours à propos de la MD, le mode H32 est très légèrement différent de ce celui de la Master System :
La MS affiche 192 lignes de jeu, mais dans une image visible de 243 lignes totales. On a 27 lignes de bordure, 192 lignes du jeu, et une autre bordure de 24 ligne en dessous. On continue avec un front porch de 3 lignes, et 3 lignes de synchro. Du coup, pour rester à 262 lignes totales, le front porch fait 13 lignes (16 pour la MD).

On obtient la modeline suivante :
Code :
Modeline "284x243"   5.369318   284 292 318 342   243 246 249 262  -hsync -vsync
Tout le reste est identique. Mais ce sont deux modelines différentes, et ça correspond à deux parties actives différentes en terme de cycle (240 et 243).

243 lignes car le standard NTSC c'est 525 lignes dont 485 visibles. On a donc des nombres impaires à la fois pour les 262.5 lignes totales et aussi pour les lignes affichées: 242.5 . En informatique, on ne compte que sur des nombres entiers, on arrondit à 243 (pour la trame entrelacée complète on alterne entre 242 et 243 lignes). C'était valable du temps de la MS, après on a standardisé le tout à 480 lignes. On recadre (cropping en anglais) pour éviter d'avoir à gérer ces demi lignes. Toutes les cartes d’acquisition délivrent une image de 480 lignes.


Retour à la MD, avec le mode H40 (320x224) :

bien qu'on affiche une plus large résolution (320 px au lieu de 256) et donc un plus grand nombre de pixels total par ligne, on reste au même nombre de cycles :
3420 cycles pour une ligne complète (qui donnent 342 pixels par lignes en mode H32).

Pour ce mode, le pixel clock ne dérive pas directement d'une division simple du master clock (Mclk) comme c'est le cas habituellement. Ici, le VDP génère son propre timing en variant entre deux fréquences déterminées par une division par 4 et 5 du Mclk : 13.4 MHz et 10.7 Mhz, qui seront à nouveau divisées par deux en interne par le VDP (-> 6.7 et 5.3 MHz). Ce procédé sert à créer la synchro horizontale (Hsync), la fréquence redevient constante pour la partie active et les porchs ( Mclk divisé par 8 ).
Pourquoi une telle manoeuvre ? Mais pour coller au taux du NTSC. Avec un pixel clock constant (celui divisé par 8 ) et pour 3420 cycles, on obtient une fréquence légèrement supérieure à 60 Hz. Le truc consiste à bidouiller la synchro de façon à faire légèrement baisser le taux au final. Le VDP oscille durant ce cours intervalle (établit à 4.77µs ) pour générer les pulsations requises par l'écran, et redevient constant pour afficher le reste.
Bref, il n'y a donc pas de modeline définitive pour ce cas, il ne s'agit même pas de switcher entre deux modelines (une pour la synchro et l'autre pour le reste), vu que même pendant le cours laps de la synchro, le VDP n'est pas à fréquence constante (il oscille entre 13.4 et 5.3 Mhz).
Bref, un beau bordel à émuler fidèlement, donc c'est en fonction de l'émulateur, du choix opéré pour ce cas. Le plus simple est de fixer le pixel clock et d'assurer les 3420 cycles à cette fréquence.

Normalement, selon les docs officielles, on devrait avoir 420 pixels par ligne au total, mais en comptant les 3420 cycles à fréquence fixe (sans la bidouille Hsync), ça nous donne 427.5 pixels :
- la Hsync se fait en 313 cycles, et divisé par 8 ça nous donne 39.175 pixels (normalement c'est prévu pour un équivalent de 32 pixels).
- le back porch se fait en 259 (32.375 pixels)
- le front porch en 64 (8 pixels).

La partie active se fait en un nombre multiple de 8 bien sûr : 2784 cycles, soit 348 pixels (et pas 320 seulement).

Du coup, on obtient la modeline suivante :
Code :
Modeline "348x240"   6.711647   348 356 395 427   240 243 246 262  -hsync -vsync
Et la représentation du signal :

Image

On a 59.99 Hz en vertical, mais sur une vraie machine, avec le délai de propagation on dépasse légèrement 60 Hz.

Pour revenir au taux désiré (59.92 Hz), il suffit de baisser un peu le pixel clock :
Code :
Modeline "348x240"   6.7039   348 356 395 427   240 243 246 262  -hsync -vsync
Le tout, c'est de rester cohérent : conserver le nombre de cycles par lignes, et le nombre de lignes total. La fréquence en sortie importe peu, c'est le nombre de cycles qui compte. C'est pourquoi les modelines doivent être fixées là dessus. La marge ( l'adaptation à ses besoins ) doit être assurée selon de légères variations du pixel clock (prises en compte par l'ému), pas sur le nombre de lignes ou de pixels par lignes.

Même la répartition des porchs (qu'on souhaite modifier pour centrer l'image sans intervenir sur l'écran) doit être fixe, parce que y a des compteurs de pixels qui déterminent à quel moment il faut commencer l'affichage. Et ça correspond pas toujours au début de l'image, ni même au début de la bordure juste avant l'image.
Sur une MD, le pixel 0, c'est pas celui qui commence l'image de 320x224, ni même celui qui commence la bordure de 13 pixels à gauche. Non il est déterminé en plein dans le back porch, juste après le color burst qui se produit au cours de celui ci. Le début de l'image 320x224, c'est le pixel n° 30.

En arcade par contre, vu que y a pas de bordures et de color burst dans le back porch, on tend à commencer à la sortie de la période de blanking, donc le pixel 0 est bien celui du début de l'image visible. Mais c'est pas non plus toujours le cas.



La suite plus tard : un petit topo sur le MVS. :terry-min


Dernière modification par Epsylon le 23 févr. 2013, 20:23, modifié 1 fois.

Haut
   
MessagePublié : 22 févr. 2013, 00:44 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Hop ! Retour en arcade, avec le fameux MVS de chez SNK. Un système bien documenté, et pourtant, pas la trace d'une modeline correcte sur le web...

Alors, sans plus attendre :

Image
Code :
Modeline "320x224"   6.000   320 327 355 384   224 240 248 264  -hsync -vsync
En détails :

Un Mclk de 24 MHz, depuis lequel on dérive les fréquences du 68000, du Z80, du YM2612, et bien sûr le pixel clock :
6 MHz tout rond.

384 pixels par lignes, ça nous fait une fréquence horizontale de 15.625 kHz exactement. Dans ces 384 pixels, la Neo affiche 320 pixels pour la partie active display, quoi qu'il arrive ! Même si on parle souvent de 304x224, il n'en est rien, la Neo ne possède pas deux modes graphiques (un de 320 et l'autre de 304 px). Si on ne voit que 304 pixels sur certains jeux, c'est parce que deux colonnes de 8 pixels noirs sont affichés dans ce qu'on appelle le "fix layer", qui comporte aussi les scores, barre d'énergie, timers etc. et qui est au 1er plan, au dessus de tous les sprites ( je rappelle que la Neo n'a pas de plan de scrollings, tout est fait à base de sprites ! ). Ce ne sont pas des bordures à proprement parler, ajoutées à côté de la fenêtre utile (comme pour la MD), et ça ne fait pas partie des porchs.

Ensuite, dans les 64 pixels dédiés au blanking, on a:

Hsync : 111 cycles , 27.75 pixels
Back porch : 118 cycles , 29.5 pixels
Front porch : 27 cycles, 6.75 pixels

Au total, 256 cycles, 64 pixels. Les valeurs ont été arrondies de façon à retrouver ces 64 pixels. Ajoutés aux 1280 cycles de la partie affichée, ça nous donne bien 1536 cycles par ligne.

En vertical : 224 lignes entourées de deux porchs de 16 lignes, et 8 lignes de Vsync, soit 264 lignes au total. 8 lignes de sync, curieux car normalement 3 sont requises... Ca n'empêche bien sûr pas l'écran de fonctionner, c'est juste que la fenêtre totale de 384x264 est constituée de multiples de 8 bien commodes, aussi bien à l'horizontal qu'à la verticale.
C'est aussi entre autre pour ça qu'on tend à souvent retrouver la fréquence de 15.625 kHz, car ça permet d'utiliser des pixels clocks intégraux issus d'oscillateurs standards. La Neo aurait pu afficher 262 lignes (59.63 Hz de taux vertical), mais bon y a pas de contraintes issues du monde broadcast et du marché domestique.
C'est pour ça qu'on rencontre tant de fréquences verticales qui semble "bizarres". Pourquoi ne pas viser un 60 Hz tout rond bien commode ? Parce que l'accent est mis sur la praticité du design, ou sur l'économie de mémoire vidéo.

Cette modeline donne bien un taux de 59.185606 Hz, conforme à MAME et autre émulateur qui vise la précision. Impossible de retrouver exactement ce taux autrement.

Examinons une modeline trouvée sur le web:
Citation :
modeline 320x224@59p 6.675189 320 336 392 424 224 236 257 266 -hsync -vsync
Déjà, c'est bien, on évite de réduire l'affichage à 304x224. Et le taux vertical correspondant se veut proche de celui indiqué par MAME :
59.18560257 Hz.
On est pas loin, après tout. C'est pas que l'écart soit visible à l'oeil . :lol:
Mais manque de bol, tout le reste est foiré :

Avec un pixel clock aussi éloigné de celui prévu à l'origine (6 Mhz !), il faut forcément placer plus de pixels par lignes, donc plus que 384, et plus de 1536 cycles.
Ici on a 424 px... :? :
- 56 px de Hsync (8.39 µs au lieu de 4.7)
- des porchs de 32 et 16 px.

En vertical, 266 lignes... :o dont 21 lignes de Vsync... 8O

Bref, on dérape dans tous les sens :P , y a rien qui colle à la réalité ni du système, ni de l'émulateur qui se veut au plus proche du hardware.
Respecter le taux vertical (se focaliser là dessus pour déterminer une modeline), ça ne garanti pas un résultat fidèle. Avec cette modeline, impossible d'avoir une synchro parfaite sans lag, parce que le nombre de cycles ne correspond pas, ni le pixel clock.

Et c'est comme ça pour toutes les modelines trouvées sur les topics relatés au sujet. Même les fichiers xml générés par des logiciels selon les données de son écran et la valeur du taux vertical mentionné par MAME ne peuvent pas aboutir à des modelines fidèles. Par exemple, pour le CPS3, impossible de trouver une modeline à 7.5 MHz de pixel clock, parce que les utilisateurs indiquent très souvent 15.5 KHz de fréquence mini dans les paramètres qu'ils donnent au générateur de modeline... Manque de bol, y a pas mal de systèmes qui tournent en dessous de 15.5 KHz.

Pour arriver au taux vertical le plus proche, y a plein de chemins possibles, vu que l'affichage sur un CRT, c'est quand même très flexible au niveau des timings, mais y a aucune chance de correspondre au nombre de cycles du système émulé,et à la répartition exacte des parties synchro et porchs.




Maintenant, pour ceux dont l'écran n'accepte pas le taux de 59.18Hz, il suffit d'augmenter légèrement le pixel clock:

pour 60 Hz désirés, on a 60 x 264 lignes = 15.840 kHz de fréquence horizontale.
Multipliés par 384 pixels par lignes (1536 cycles ! ) = 6.082560 MHz de pixel clock.
Code :
Modeline "320x224"   6.082560   320 327 355 384   224 240 248 264  -hsync -vsync
C'est comme si on avait utilisé un oscillateur de 24.330240 MHz sur la PCB au lieu de celui de 24 tout rond.

Faut pas oublier que SNK a changé cette valeur pour les révisions de carte mère suivantes :

Image
(carte mère version aes3-3)

Ici, 24.167829 MHz pour le Mclk, ce qui nous donne un pixel clock de 6.04195725 MHz, et un taux vertical de ~ 59.599484 Hz.
Code :
Modeline "320x224"   6.04195725   320 327 355 384   224 240 248 264  -hsync -vsync



Donc, si on comprend tout ça, au lieu d'écrire des modelines avec des chiffres qui sortent du chapeau et de tenter d'ajuster le tout pour coller au taux voulu, ou de générer des modelines pendant que l'émulateur fonctionne (et qui seront foirées parce que les paramètres fournis ne collent pas forcément à la réalité), il suffit juste de modifier le Mclk.

Pour la Neo Geo, on pourrait avoir trois options niveau utilisateur :

1) 24.000000 MHz -> 59.18 Hz
2) 24.167829 MHz -> revision SNK 59.6 Hz
3) 24.330240 MHz -> 60.00 Hz

Le tout, pour resté cohérent, associé à la modeline Kivabien 8) , et qui ne change jamais en dehors du pixel clock (toujours 384 pixels x 264 lignes et les paramètres associés).

Mais pour se faire, faut écrire directos la valeur du Mclk dans le code source, j'ai rien vu qui ne permette de modifier facilement cette valeur du point de vue utilisateur...

Pour les autres systèmes émulés, c'est pareil : choisir le Mclk d'origine (pour rester au plus proche du hardware), ou switcher pour un qui délivre au final un taux de 60 Hz si on peut pas faire autrement.

Donc, avec ces quelques exemples, vous aurez compris que je ne suis pas partisan de la génération de modeline, car après tout les systèmes émulés ne changent jamais de propriétés. Quand on fait un overclock sur une machine, on ne peut agir que sur l'oscillateur, on ne taille pas dans les processeurs vidéo pour qu'ils soient en mesure d'afficher plus ou moins de lignes ou de pixels. Et on ne peut pas changer la répartition des porchs. Tout est fixé.
Donc, en toute logique, les modelines aussi sont fixes. 8)


Haut
   
MessagePublié : 23 févr. 2013, 20:47 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
J'aurais pu commencer par ça, mais voici maintenant une visualisation d'un signal vidéo sur un oscilloscope, histoire de bien piger de quoi il s'agit au niveau de ce qui est envoyé à l'écran :

Image

De gauche à droite : la fin d'une ligne, le blanking, et le début d'une autre. On voit les variations des lignes affichées (amplitude de 0.3 à 1V), puis un très court intervalle (le front porch, 0.3V), puis les pulsations de la synchro horizontale (à 0V), et de nouveau un palier à 0.3 V (le back porch) dans lequel on trouve ce qu'on appelle le color burst, dont la fréquence de sous porteuse dépend de la norme NTSC ou PAL. C'est avec ça qu'on reconstitue les couleurs sur un signal composite. En pur RGB c'est absent bien sûr.

Les porchs sont des signaux à 0.3 V (ça correspond à "afficher du noir" ), il s'agit en quelque sorte de "pauses" pour laisser le temps à l'électronique du tube de bien piloter le yoke. Si les porchs sont absents ou trop courts, on constate des défauts à l'affichage.

En arcade, les porchs sont souvent très longs car il n'est pas prévu de bordures pour la partie active, et le nombre de pixels total par ligne n'aboutit pas forcément à une répartition 25% blanking / 75% affichage.

A noter que si pour la Neo Geo on en est venu à réduire la partie affichée à 304 pixels (en utilisant les tiles du fix layer comme un "overlay"), c'est parce qu'avec les timings de son signal, on tombe dans la partie "overscan" du signal standard et la mise au point des TV qui est associée.
384 pixels au total, c'est un peu juste pour afficher 320 px utiles. Il aurait fallu plus proche de 400. La MD, pour afficher ses 320 px utiles, prévoit un nombre total de 420. Résultat : sur toutes les TV, peu importe les écarts de mise au point, on voit toujours les 320 px, alors que sur Neo, on ne verra que 302 à 306 px en gros. Il faut donc procéder à un recadrage sur l'écran. Mais ça n'est pas prévu à domicile, et même en arcade, c'est pas tous les opérateurs qui daignent tourner un ou deux potards pour ajuster l'image...


Haut
   
MessagePublié : 26 févr. 2013, 14:22 
Hors-ligne
stick de rhodium
Avatar de l’utilisateur

Inscription : 12 mai 2006, 00:01
Messages : 3351
Localisation : Campagne profonde
Cool de la lecture pour ce soir :-D .


Haut
   
MessagePublié : 27 févr. 2013, 08:58 
Hors-ligne
stick de zinc
Avatar de l’utilisateur

Inscription : 08 juil. 2010, 18:04
Messages : 257
Merci Epsylon ^^
Maintenant faut que je lise tout 20 fois pour que je comprenne un peu :p

_________________
--
" jte fai pipi dans ta bouche etAruba va continue à me voir tue le français"
Zahro


Haut
   
MessagePublié : 27 févr. 2013, 13:39 
Hors-ligne
stick d'or
Avatar de l’utilisateur

Inscription : 26 août 2005, 19:02
Messages : 1468
C'est vrai que c'est du lourd là... 8O

_________________
Comme disait mon grand-père tout les ans il y a de plus en plus de cons, mais cette année j’ai l’impression que les cons de l’année prochaine sont déjà là.


Haut
   
MessagePublié : 27 févr. 2013, 20:54 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Wé, c'est du lourd ! 8)

Pour ceux qui réalisent pas, toutes ces précisions autour des timings de l'affichage et des modelines associées permettent d'exploiter le maximum des possibilités de l'émulation :
pour un affichage à la fréquence exacte, on échappe au tearing ou au lag induit par les options triple buffering & Co, et on peut réduire la latence audio à 1.

L'émulation est basée sur un pré-rendu par frame (et non par lignes, ce qui est hors d'atteinte de nos jours), donc on peut pas réduire le délai en dessous de 1 frame (16 ms). Mais on peut l'atteindre, et dans les meilleures conditions !
Pour ça il faut déjà absolument respecter le temps de l'intervalle du blanking vertical (données en millisecondes qui sont converties en attosecondes dans les émulateurs). Et pour se faire, il faut respecter la durée des lignes à l'horizontale. Ca ne peut se déterminer correctement que si on part du pixel clock correct.

Là, pour l'exemple du MVS, c'est pas la modeline de 266 lignes (!) qui va donner un temps exacte pour l'intervalle du Vblank.
Le taux vertical a beau être *très proche* de celui indiqué par Mame, ce n'est pas le bon :roll: . Ca se traduit donc par de petites saccades (même si peu visibles et éloignées dans le temps), et un grésillement du son qui arrive au bout d'un certain temps. Donc, on retourne avec une latence audio de 2 frames et activer le tripple buffering.

C'est normal, le pixel clock du MVS est prévu à 6 MHz, non pas à 6.675189 (écart de 11%). Il est prévu à 6, parce que le Mclk est de 24. Et c'est aussi ce Mclk qui affecte le timing du Z80 et du YM2612 qui assurent la partie audio.

Pour 6 MHz et 264 lignes (de 384 pixels), on a 40 lignes de Vblank, qui durent : 2.560 ms

Pour 6.675189 MHz et 266 lignes (de 424 pixels) : 2.66779 ms

Donc voilà, du point de vue du taux vertical, en fin de chaîne, l'écart apparaît insignifiant. Mais du point de vue du Vblank, l'écart est bien là, significatif (4%). Ca suffit pour provoquer des artefacts visuels et des décrochages son.

Pour se débarrasser du tripple buffering et autres options qui sont là pour compenser les écarts, pas de mystère :
il faut que les valeurs correspondent exactement. C'est grâce à ça qu'on peut enfin activer uniquement l'option "throttle" (= respecter le rythme du jeu).


Haut
   
MessagePublié : 27 févr. 2013, 21:53 
Hors-ligne
stick d'or
Avatar de l’utilisateur

Inscription : 04 juin 2009, 12:33
Messages : 1061
Si un jour tu sors un livre sur le sujet, j'achète les yeux fermés.
:merci:

_________________
Peg, je vais te répéter ce que je dit tous les matins au réveil.....
Qu'est ce que que tu fais encore ici?


Haut
   
MessagePublié : 27 févr. 2013, 22:53 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Plutôt qu'un livre, je vais sans doute pondre quelques pages web, classées selon les noms de drivers utilisés par Mame.
Y a des cas qui sont évidents, suffit de lire et d'écrire la modeline suivant les infos, mais y a pas mal de cas qui méritent une mise à jour, du genre le jeu qui indique un "58 hz" tout rond en taux vertical, ce qui n'a pratiquement aucune chance d'être constaté sur le vrai hardware. Pareil pour la masse de jeux prévus pour un beau "60.000000" hz, ça n'a aucune chance de se produire ou presque, et on peut pas écrire de modelines fiables (corrélées au hardware, au Mclk) en 240p pour afficher une telle fréquence, à moins d'utiliser des pixels clocks avec une précision de 0.000001 MHz , qui ne sont pas garantis d'être utilisé de façon complètement fiable par les cartes graphiques.
Dans le standard Matrox par exemple, la précision s'arrête à 0.001 MHz.

Pour une parfaite synchro, il va falloir mettre à jour les valeurs dans le code source, selon la terminologie employée depuis la refonte du moteur de rendu (screen.c).

C'est du boulot, et c'est pas vraiment une priorité, vu que le gain concerne surtout les joueurs qui utilisent des CRT... Et vu que la majorité des gens (développeurs comme utilisateurs) jouent sur des LCD (qui sont très limités en plage de fréquence, donc pour lesquels la synchro identique à l'originale n'a pas de sens), tout le monde s’accommode sans mal du classique tripple buffering et du lag induit par les options de ce genre, pour des écrans qui de toute façon provoquent déjà leur propre lag...


Retour avec un autre exemple, le jeu Bubble Bobble, vu sur un autre forum :
Citation :
I've tested the new Groovymame with Bubble Bobble and noticed a strange behavour. It seems that the correct modeline required by the game is the following:

Modeline "256x224_60 15.63KHz 59.19Hz" 5.25 256 272 296 336 224 235 238 264 -hsync -vsync
Alors, déjà les 5.25 MHz de pixel clock, je sais pas d'où ils sortent... Faudrait un oscillateur de 21 ou 42 MHz sur la carte, ce qui n'est pas franchement le plus utilisé.

Un coup d'oeil sur le driver ( bublbobl.c )
Code :
   10  Main clock: XTAL = 24 MHz
   11  Horizontal video frequency: HSYNC = XTAL/4/384 = 15.625 kHz
   12  Video frequency: VSYNC = HSYNC/264 = 59.185606 Hz
   13  VBlank duration: 1/VSYNC * (40/264) = 2560 us
Coup de chance, tout est clairement indiqué (ce qui n'est pas le cas de nombreux autres drivers...)

Le reste :
Code :
  777      /* video hardware */
  778      MCFG_SCREEN_ADD("screen", RASTER)
  779      MCFG_SCREEN_RAW_PARAMS(MAIN_XTAL/4, 384, 0, 256, 264, 16, 240)
On est proche du schéma Neo Geo : des multiples de 8, une fréquence de 15.625 kHz.
Les chiffres correspondent (384 x 264, 6 MHz pour le pixel clock), on obtient donc le même taux vertical : 59.185606 Hz.
Et aussi le même Vblank de 40 lignes, vu que les jeux affichent tous les deux 224 lignes parmi 264.
A l'horizontale, la Neo affiche 320 pixels par lignes, et Bubble en affiche 256. Donc, 128 pixels à prévoir pour la synchro horizontale de Bubble.

On obtient la modeline suivante :
Code :
Modeline "256x224"   6.000   256 292 320 384   224 240 248 264  -hsync -vsync
Une représentation :

Image

Ici, le fond à damier représente la portion dédiée aux infos de synchro (vu que le fond du jeu est noir). La partie verte est la Vsync (8 lignes), et la partie rouge la Hsync (28 pixels), le reste ce sont les porchs (signal à 0.3 V).

C'est au plus proche du hardware, en respectant la durée Hsync (ici 4.67 µs).


La modeline indiquée en premier (avec 5.25 de pixel clock, 336 pixels par lignes) nous donne aussi 2.560 ms de Vblank, là c'est un coup de chance ! :lol: Ca vient du fait que la fréquence horizontale est respectée :

5.25 Mhz pour 336 pixels par ligne au total, ça donne pile 15.625 kHz, tout comme 6.00 divisé par 384 pour la Neo.
Mais tout comme 7.00 divisé par 448, ou encore 5.00 divisé par 320. 15625 c'est un nombre très pratique.

Le gars qui a écrit cette modeline a respecté une logique relativement proche du hardware et a maintenu l'intervalle du Vblank, mais il est pas allé jusqu'au bout pour respecter le pixel clock, et il est un peu juste sur la Hsync ( 24 pixels, 4.57 µs, mais c'est sans doute pour assurer des multiples de 8, qui sont quelque fois requis par les cartes graphiques pour le timing horizontal, vu que c'est la norme VGA à la base ).

Dans ce cas, pas d'écarts sur le point essentiel pour les émulateurs, à savoir la durée du Vblank et le nombre total de lignes (le tout relaté à la fréquence horizontale).
Mais c'est pas le cas pour de nombreuses modelines qui trainent sur le web, qui sont toutes farfelues avec des chiffres qui ne s'accordent à rien, et qui n'ont donc quasi aucune chance d'assurer une durée de Vblank conforme à ce qui est prévu par Mame.
Là j'examine des logs issus de ces générateurs de modelines, c'est pas bien folichon tout ça... Passage obligé par la case tripple buffering. :roll:

Bref, y a du boulot ! :bobble:


Haut
   
MessagePublié : 27 févr. 2013, 23:56 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Petit retour sur la question de l'overscan, et du pourquoi du comment de la résolution Neo Geo "tombée" à 304x224 (alors qu'on reste techniquement toujours à 320x224, quoiqu'il arrive).

Le fichier .png ci dessous est construit selon les timings du signal NTSC, à 13.5 MHz de pixel clock. On a une fenêtre totale de 858x525 pixels, avec la partie synchro dédiée, en noir. La bordure bleu indique le format visible total, la zone rouge transparente la partie overscan : les téléviseurs sont mis au point pour porter cette partie hors de la surface du tube, de façon à afficher ce qui est comprit dans la partie cadrée en jaune (safe area dans le jargon)

Image



Quand on positionne les images relatives aux timings de la Neo, ça donne ça :

Image

On s'aperçoit que effectivement, y a des parties qui sont rognées, et qui correspondent pratiquement à 8 pixels de chaque côtés. Bref, sur l'immense majorité des TV, aucune chance pour l'utilisateur de voir le contenu complet de l'image, à moins d'intervenir sur la mise au point de son écran (potards ou service mode). Donc, y a pas mal de jeux Neo qui ont été conçus pour s'occuper de la partie des 304 pixels visibles. Le reste sera masqué par des tiles noires inclues dans le fix layer. Mais les timings ne changent pas ! C'est toujours le même signal qui est envoyé, ce n'est pas un autre mode graphique.




Maintenant, l'image d'une Megadrive :

Image

Là on se rend compte que les bordures (ici en bleu, comme le background) sont prévues de façon à ce que peu importe la mise au point du téléviseur du joueur, l'image utile soit intégralement visible.

Bref, pour afficher 320 pixels par lignes, on a deux designs différents. Pour les consoles, on tâche de rester au plus proche du signal broadcast, et on inclut des bordures (qui ne sont pas des porchs !), et en arcade, on se contente du minimum, et on compte sur l'opérateur pour ajuster au besoin l'image sur la borne (ce qui n'est pas fait si souvent, suffit de voir les bornes d'occasion).


Haut
   
MessagePublié : 28 févr. 2013, 22:07 
Hors-ligne
stick de zinc
Avatar de l’utilisateur

Inscription : 27 sept. 2008, 00:45
Messages : 362
Localisation : Saint-Maur-des-Fossés (94)
Incroyablement précis et abordable ...
Excellent !!!

Grace à toi on comprend bien mieux comment sont interprétés les modelines.


Haut
   
MessagePublié : 01 mars 2013, 11:31 
Hors-ligne
stick de platine
Avatar de l’utilisateur

Inscription : 20 janv. 2012, 12:25
Messages : 2668
Localisation : Nancy (54)
Une mine d'or, je me régale.
Y a du taff, mais un super support de cour là ^^

Un grand MERCI à toi.

_________________
La candy japonaise c'est comme un string, moins il y a de matière et plus c'est chère.
Image


Haut
   
MessagePublié : 01 mars 2013, 19:02 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Ca va, je vois qu'il y a des gens qui saisissent l'intérêt du truc. :)

Je me suis remis à l'émulation y a pas longtemps, et je me suis rendu compte de plusieurs trucs :

- déjà Mame est devenu très volumineux, il met des plombes à se lancer et à scanner les roms
- je m'en balance de tous ces jeux de Mahjong, de gambling ou autres conneries :volatiliz
- il me faut un bon p'tit build compilé avec que les drivers essentiels
(et si possible un ptit front-end 240p friendly, que j'ai toujours pas trouvé)
- mais plus que ça, il m'en faut un qui assure un rendu avec le moins de lag possible, une synchro au quart de poil de mammouth près

Et là, malgré les efforts de certains gars qui ont pondu des trucs bien foutus, on se heurte à une limite :
le manque de définition des paramètres vidéo dans de nombreux drivers...

Par exemple, quand il est annoncé un taux de "59.61 Hz" et basta (suite à une mesure depuis la PCB, mais pas franchement précise et surtout peu utile isolée), le driver vidéo de Mame se contente de convertir cette donnée en attosecondes.
Maintenant, il est impossible d'écrire une modeline fiable pour cette fréquence. Faisons un essai tout simple :

59.61 Hz, pour un standard de 262 lignes, et disons 336 pixels par lignes, soit 59.61 x 262 x 336 = 5247587.52 .
Donc, un pixel clock de 5.24758752 MHz... Tu crois que ta carte graphique va le prendre en charge avec une précision digne de la Nasa ? :lol: ...
Dans le meilleur des cas, un joli arrondi au Hz près : 5.247588 MHz. Ha mais du coup, on obtient plus 59.61 Hz pile poil, mais :

59,610005452562704471 Hz. Comparé à:

59.610000000000000000 Hz, valeur inscrite dans le code source du driver.

D'un coté Mame détermine une frame qui dure 16.776 ms, mais plus précisément:

16775708773695685 attosecondes. Et là avec la modeline, on envoie des données qui correspondent à :
16775707239211615 attosecondes...

L'écart est là, ça se traduit pas une légère désynchronisation, à laquelle on remédie par du buffering.

Mais là, c'est un cas optimiste. La précision du pixel clock peut tout à fait être ramenée à 0.001 Mhz près, soit 5.248 MHz... On augmente encore le décalage en attosecondes.

Et si tu regardes les modelines générées par Switchres & co, c'est juste deux chiffres après la virgule :
là on arrondit à 5.25 Mhz... Donc, l'écart augmente encore. :roll:

Alors, à moins d'avoir du bol et de tomber sur un jeu qui se base sur la fréquence de 15625 Hz et de tomber par chance sur le bon nombre de lignes requis (comme pour l'exemple de Bubble Bobble, avec 264 lignes au lieu des 262 auxquelles on s'attend), c'est impossible d'avoir un truc qui tient la route. Donc retour à la case tripple buffering.

Aussi, pas de secret, il faut écrire les valeurs correspondantes dans le code source (à peine une dizaines de lignes par driver), en accord avec la modeline qui reflètera ces valeurs (sachant qu'on est limité à des nombres entiers pour les pixels et lignes, et une précision de pixel clock de deux ou trois chiffres après la virgule dans de nombreux cas).
Les conversions en attosecondes seront concordantes, donc l'émulateur communiquera à la carte graphique ce qu'elle peut afficher à la bonne cadence, sans avoir besoin de compenser les écarts.
Throttle et puis c'est tout. 8)

Et là, tu jettes un coup d'oeil sur la liste des taux de rafraîchissement gérés par Mame, et y a plein de jeux donnés pour des taux tout ronds ( 60.000000 Hz...) ou avec seulement un ou deux chiffres significatifs après la virgule (59.610000 Hz, 57.500000 Hz...). Et dans les configs des joueurs, plein de modelines avec des pixels clocks foireux, et des chiffres qui sortent du chapeau... :roll:

Bref, il va falloir mettre un peu d'ordre là dedans.
Image

:lol:


Haut
   
MessagePublié : 02 mars 2013, 00:10 
Hors-ligne
stick d'or
Avatar de l’utilisateur

Inscription : 21 janv. 2009, 22:21
Messages : 1425
Localisation : Près d'Orleans
Je suis ton topic avec beaucoup d'attention mais il y a encore pas mal de trucs que je ne comprend pas, j'essaierai de te faire une liste de mes interrogations ce weekend. :wink:

En tout cas chapeau pour le boulot, du grand art et de quoi faire bien avancer le shmilblic ! :-D

_________________
Image

Image


Haut
   
MessagePublié : 08 mars 2013, 16:42 
Hors-ligne
stick de bronze

Inscription : 08 avr. 2005, 18:48
Messages : 171
Citation :
- déjà Mame est devenu très volumineux, il met des plombes à se lancer et à scanner les roms
- je m'en balance de tous ces jeux de Mahjong, de gambling ou autres conneries :volatiliz
- il me faut un bon p'tit build compilé avec que les drivers essentiels
(et si possible un ptit front-end 240p friendly, que j'ai toujours pas trouvé)
- mais plus que ça, il m'en faut un qui assure un rendu avec le moins de lag possible, une synchro au quart de poil de mammouth près :lol:
Tu as essayé le build officiel ? (en ligne de commande)
Si tu lances un jeu, seul celui-ci est scanné et ça se lance généralement en 5 secondes.

Le topic a l'air intéressant sinon, mais je devrai le reparcourir car je n'ai pas tout le vocabulaire (tu commences un peu fort dès le début en parlant de modelines & compagnie :))


Haut
   
MessagePublié : 08 mars 2013, 20:40 
Hors-ligne
Théoricien du pixel
Avatar de l’utilisateur

Inscription : 17 oct. 2006, 23:42
Messages : 1222
Localisation : Marseille
Là j'utilise Mame Plus! XT, les jeux se lancent rapidement une fois que l'émulateur est opérationnel, pas de soucis. Juste qu'il faut deux bonnes minutes pour qu'il soit opérationnel, le dit émulateur... Je suis sur un Athlon X2 2 Ghz, XP 32 bits (130 Mo en ram).
Si j'ajoute deux roms et fait un "audit all games", ça prend pas mal de temps. J'utilise pas le Mame de base, et je vais directos passer à une solution type GroovyMame, que je suis en train d'étudier, et surtout je vais compiler un build avec les seuls drivers qui m'intéressent.
Mais avant de les compiler ces drivers, il va falloir écrire les paramètres vidéo dans les sources, parce que dans l'état actuel, il est impossible de synchroniser parfaitement l'émulateur avec la carte graphique pour tous les drivers qui ne sont pas bien renseignés sur ces paramètres. Et y en a un paquet... :roll:
C'est pour ça que je vois tant de modelines plutôt approximatives, et qui obligent donc à utiliser le triple buffering & co.
Pour l'instant, y a pas de solution optimale, même si GroovyMame fait un travail remarquable, y a jamais un taux de 100% constant.

Donc, ce topic s'adresse déjà aux gens qui connaissent un tant soit peu ces questions de modelines, de synchro, de throttle. C'est pas destiné aux novices (qui en plus se trouveront à jouer sur du LCD) ! Pour eux, il suffit de se cantonner aux options de synchro de Mame, c'est le plus simple. Mais la simplicité a un prix : le lag. Et c'est justement pour y échapper que je me suis penché en détail sur la question.

La réponse est simple : il faut spécifier des paramètres qui soient en accord avec ce que peuvent supporter les modelines. GroovyMame par exemple ne fait qu'interpréter une valeur donnée (le fameux taux vertical, le bout de la chaîne) et génère une modeline au plus proche, en fonction des données de l'écran de l'utilisateur. Ca ne colle jamais à 100%, sauf en de rare cas. En fait, ce logiciel a été conçu pour éviter de se taper le boulot de base : écrire les bons paramètres pour chaque driver. Mais c'est pourtant le palier qu'il faut franchir pour atteindre une synchro sans accro. ^.^



Par exemple, le driver de Toki (toki.c ) indique ceci :
Code :
  427      /* video hardware */
  428      MCFG_BUFFERED_SPRITERAM16_ADD("spriteram")
  429  
  430      MCFG_SCREEN_ADD("screen", RASTER)
  431      MCFG_SCREEN_REFRESH_RATE(59.61)    /* verified on pcb */
  432      MCFG_SCREEN_SIZE(32*8, 32*8)
  433      MCFG_SCREEN_VISIBLE_AREA(0*8, 32*8-1, 2*8, 30*8-1)  /* verified */
un taux de 59.61 Hz, vérifié sur la PCB. De même qu'une résolution active de 256x240 (et non 256x224 comme beaucoup le pensaient avant).
Oué, c'est bien bô, mais impossible de générer une modeline qui produise pile poil 59.61000000000 Hz (comme expliqué juste un peu plus haut). C'est pourtant selon cette valeur seule qu'est calculé le temps de chaque frame pour le jeu, pour respecter cette vitesse mesurée.

Plusieurs oscillateurs sur la PCB : un de 20 Mhz, qui semble être le Mclk (divisé par deux = vitesse du M68000). Oué mais divisé par 4, ça donnerait que 5 Mhz de pixel clock, c'est trop léger pour afficher 256 pixels visibles. C'est faisable, mais ça signifierait des porchs très courts, et donc une image très étirée sur l'ensemble des moniteurs. Or, sur toutes les photos du jeu qui tourne dans une borne, on tend à constater une fenêtre étroite. Ce n'est certainement pas l'utilisateur qui a tenu à régler son écran pour avoir une telle image, il s'agit donc des réglages de base de l'écran, et donc ça signifie pour le jeu des porchs longs, donc un total de pixel plus grand, donc un pixel clock plus élevé que 5 MHz. A côté, on trouve aussi un classique 14.318 MHz (basé sur un multiple du color burst à 3.58 MHz), mais là c'est pour certains processeurs sons, et divisé par deux, ça ferait vraiment trop grand comme pixel clock pour 256 pixels...
Reste un dernier oscillateur sur la carte : 12 MHz. A priori, il sert aussi pour certaines puces, mais ça pourrait très bien convenir pour dériver le pixel clock après une division : 6 MHz.

Après quelques essais, on obtient la modeline suivante :
Citation :
Modeline "256x240" 6.000000 256 292 320 384 240 248 251 262 -hsync -vsync
Image

On obtient un taux de 59.637405 Hz, très proche de celui mesuré.
384 pixels par lignes (48x8), pour 262 lignes (standard non entrelacé), ça semble tout a fait probable.
Pour l'horizontal, les porchs sont distribués selon la formule " Hsync+ front porch = back porch" , ici 28+36 = 64.
La Hsync (28 pixels) fait 4.67 µs, mais il est probable que sur la vrai carte, on trouve 28.5 pixels pour 4.75 µs.
En vertical, 3 lignes de Vsync. Et même topo : Vsync + Fporch = Bporch. (3+8 = 11)

Et quand on fait la correspondance entre ces timings et ceux de la mise au point de base d'un tube, on obtient ceci :

Image

Et là, on s'aperçoit bien que la partie du haut de l'image sort du cadre de la "safe area" (et même du "total display"), ce qui a amené à penser que le jeu était d'une résolution de 256x224 (le score a été décalé d'une tile de 16 vers le bas pour être bien visible, ce qui tend à valider cette supposition).
La fenêtre du jeu est légèrement décalée à droite, entourée de "bordures" noires. Si on ne touche pas aux réglages de son écran de borne, c'est ce qu'on constate à peu près en réel avec une vraie PCB. Donc les timings de la modeline ont de fortes chances d'être au plus proche de l'original.
La différence mesurée (59.61 Hz, un écart de 0.02 Hz à peu près) provient de la dérive en fréquence de l'oscillateur, selon l'usure lié à la température de fonctionnement, les extinctions/allumages etc., choses qui affectent tous les systèmes.

Donc, pour pouvoir jouer à ce jeu avec une synchro parfaite (sans tearing, sans lag ! ) il faut spécifier ces paramètres, et utiliser cette modeline. Et sur son écran, procéder aux réglages pour centrer/étirer l'image, exactement comme dans la réalité avec une vraie PCB.


Haut
   
Afficher les messages publiés depuis :  Trier par  
Publier un nouveau sujet  Répondre au sujet  [ 43 messages ]  Aller à la page 1 2 Suivant

Fuseau horaire sur UTC+02:00


Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité


Vous ne pouvez pas publier de nouveaux sujets dans ce forum
Vous ne pouvez pas répondre aux sujets dans ce forum
Vous ne pouvez pas modifier vos messages dans ce forum
Vous ne pouvez pas supprimer vos messages dans ce forum
Vous ne pouvez pas transférer de pièces jointes dans ce forum

Rechercher :
Aller :  
Développé par phpBB® Forum Software © phpBB Limited
Traduction française officielle © Miles Cellar