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 :
( 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 : Tout sélectionner
Modeline "384x224" 7.500 384 400 435 486 224 240 243 259 -hsync -vsync
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 : Tout sélectionner
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
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 : Tout sélectionner
MCFG_SCREEN_RAW_PARAMS(PIXEL_CLOCK, HTOTAL, HBEND, HBSTART, VTOTAL, VBEND, VBSTART)
- 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 . 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 : Tout sélectionner
Modeline "384x224" 7.552440 384 400 435 486 224 240 243 259 -hsync -vsync
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 , 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 : Tout sélectionner
Modeline "576x224" 11.25 576 600 653 729 224 240 243 259 -hsync -vsync
Rien n'a changé à la verticale.
On obtient ceci :
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 :
- 576x224 non filtré :
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.