[Tech 240p] à propos des modelines, pixel clock et porchs

Complémentaire à la partie Matos, vous trouverez ici de nombreux tutos. C'est communautaire, tout le monde peut créer un tuto.
Message
Auteur
Avatar de l’utilisateur
Epsylon
Théoricien du pixel
Contact :
Messages : 1222
Inscription : 17 oct. 2006, 23:42
Localisation : Marseille
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#26 Message par Epsylon »

Pour confirmer, deux images:

- ici, la PCB qui tourne sur une borne européenne :

Image

Je doute fortement que le joueur ait réglé son écran de façon à obtenir ce centrage, il s'agit certainement du réglage de base. On branche la PCB et c'est parti. Bien sûr, d'autres joueurs effectueront le petit ajustage de façon à avoir une image plein écran, bien calée.


- ci dessous, l'image qui est censé apparaître en 4/3, dans la partie "safe area", selon les timings fournis plus haut :

Image

Ca semble bien correspondre, les marges autour de l'affichage utile semblent de taille quasi identique, et le score apparaît bien à ras du haut de l'écran (224 lignes affichées, les 16 du haut sont hors de la surface du tube).

Bref, c'est du plus que probable, au plus proche du vrai matos, et surtout applicable sans problème par une modeline kivabien. 8)

Avatar de l’utilisateur
Shardik
stick d'argent
Messages : 753
Inscription : 03 mars 2012, 17:20
Localisation : Alsace, Over the rainbow
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#27 Message par Shardik »

Un superbe référencement. Beau boulot epsylon !
<°)))><

Avatar de l’utilisateur
Gakman
stick d'argent
Contact :
Messages : 955
Inscription : 15 janv. 2007, 18:29
Localisation : Nancy (France)
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#28 Message par Gakman »

Très intéressant, on attend la suite !
@++
Gakman
-> http://gakman.free.fr

Avatar de l’utilisateur
mr_de_fursac
stick de plomb
Messages : 95
Inscription : 10 mai 2005, 13:43
Localisation : Pau
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#29 Message par mr_de_fursac »

Captivant.
Je suis loin de maitriser ou comprendre tout ce que tu dis mais ça fait plaisir de voir des gens aller au bout des choses.

soudara
stick de bronze
Messages : 104
Inscription : 30 janv. 2010, 11:10
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#30 Message par soudara »

salut
vraiment genial moi qui croyait etre deja bien avec mes resos et frequences vertical native j'etait loin du compte , je vient de tester la modeline que tu donne pour le cps3 j'ai du retoucher toute la geometrie de mon ecran pour recaler comme il faut , je vait me baser sur tes resolutions par contre j'ai encore bocoup de mal a comprendre tout les calcul que vous faites ,
peut tu me redonner un exemple pour la resolution native de demon front en 448X224 comment tu calcul par rapport au drivers donner dans mame apres j'essaierait de me debrouiller pour les autres resolution qui m'interesse et en poster une et voir si se que j'ai fait est correct.
en fait si je comprend bien si on veut vraiment se rapprocher au maximum des pcb d'origine y'as pas le choix faut retoucher la geometrie pour chaque jeux emuler pas possible d'avoir 50 resolution differente qui se cale parfaitement sur l'ecran sans toucher a la geometrie j'ai juste ?
je te remerci d'avance pour tes lumieres
++++++

Avatar de l’utilisateur
Epsylon
Théoricien du pixel
Contact :
Messages : 1222
Inscription : 17 oct. 2006, 23:42
Localisation : Marseille
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#31 Message par Epsylon »

Pour l'exemple donné pour le CPS-III, il faut surtout retenir la taille de la fenêtre (frame) totale : 486x259, ainsi que le pixel clock : 7.5 MHz. La répartition des porchs illustre une façon qui est souvent utilisée en arcade et qui est "fausse", à savoir établir une égalité Fporch + Sync = Bporch, ce qui abouti à avoir une image plus ou moins décentrée par rapport au réglage de base du moniteur, qui suit de près les timings du standard NTSC. C'est à dire que les moniteurs arcade sont aussi concernés par l'overscan, sachant que celui varie un peu entre le standard NTSC à 12.27 MHz (jusque dans les 80's), et celui à 13.5 MHz (depuis le début des 90's).

La fenêtre du CPS-III est dimensionnée de telle sorte que la partie active display correspond à la zone de 5% d'overscan du NTSC à 13.5 MHz, et que les informations du HUD soient incluent dans la zone "safe action", qui est determinée à 93.4% de largeur et 93% de hauteur. Dans la page précédente, je m'appuie sur des données du vieux standard, c'est pas très éloigné mais du coup ça n'explique pas pourquoi chez Capcom ils ont choisi de telles dimensions pour la frame du CPS3, alors que les chiffres du nouveau standard permettent de comprendre ces choix (c'est pas que Capcom tenait absolument à avoir un 59.59 Hz pour le taux vertical...).
Bref, pour une meilleure visualisation:

Image

L'image du jeu (384x224) rentre dans la zone 5% (rouge). Les informations du HUD touchent la bordure verte (safe action), et même si l'écran est calé avec une mise au point de 10% d'overscan (jaune), ça passe quand même, le gros des infos est présent (le score sera un peu rogné, hors de la surface visible du tube).

Mais ceci a du sens si l'écran respecte bien le standard pour sa mise au point, ce qui est loin d'être le cas, tellement c'est un peu la foire pour s'y retrouver avec tous ces chiffres. Ca a l'air con dit comme ça, mais c'est difficile de trouver des infos à propos de où commence et où s'arrête le signal , cf cette page (en anglais, et c'est long), à propos des programmeurs de logiciels de capture video:

http://lurkertech.com/lg/video-systems/

Morceau choisi :
The deep, dark secret of old-school video equipment is that it actually doesn't care exactly where the edges of the picture are located. It just leaves enough margin so that nobody's information will get cut off, and is happy with that.

Instead, old-school video engineers are much more concerned with making sure that the picture center is maintained by all pieces of processing gear.

That is the reason why if you look at the analog and digital electrical specifications, you will see the picture center being specified in insane detail, but you will see little, if any, mention of where the picture starts and ends (either vertically or horizontally).
Y a des tas d'infos sur telles ou telles durées (qui varient selon les sources...), et même dans le monde de l'acquisition vidéo (cf le lien au dessus), c'est un peu la confusion pour savoir quoi cadrer, et quand (ce qui fait que les résultats de captures varient un peu selon les logiciels, en fonction des chiffres retenus). Les chiffres n'ont jamais été spécifiés de façon claire. Ca a évolué avec le passage au tout numérique et la HD, parce que les écrans matriciels se foutent de l'overscan et doivent afficher une image au dimensions bien définies.

Pour le signal NTSC, j'ai eu du mal à rassembler tous les chiffres qui m'ont permis d'écrire cette modeline (qui a légèrement été réajustée depuis la création de ce topic) :

Code : Tout sélectionner

Modeline "720x480"   13.500   720 733 797 858   480 484 492 525  -hsync -vsync Interlace
Je ne suis pas encore sûr de tous les chiffres, mais déjà au niveau horizontal, je sais que Hsync + Bporch = 125, car de cette façon, le centre de l'image correspond bien au standard PAL qui a été aligné dessus (13.5 MHz est la fréquence retenue pour les deux standards, avant c'était 12.27 et 14.75 MHz). Du coup, ça donne 13 de Fporch, et pas 14 comme certaines sources. Ca fait que 1 pixel d'écart, mais du coup ça décale l'image.
Pour la position vertical, j'ai redescendu l'image de 1 lignes, je suis passé à 2 pour le front porch, et non plus trois.

Une fois tous ces timings bien calés, c'est à ce moment qu'on peut faire la correspondance pour designer les timings des jeux qui vont être affichés par un ecran dont on aura assuré la bonne mise au point, au plus proche du standard (sachant que même sortie d'usine, les écrans n'ont pas tous la même mise au point, ils sont traités avec des générateurs de mires qui n'ont pas tous les mêmes données, et tous ne visent pas à assurer la même proportion pour l'overscan).

Donc, si vous êtes en mesure de balancer la modeline du NTSC postée plus haut, et d'assurer un centrage correct ainsi qu'un overscan de 5% sur votre écran (pas la peine de maintenir toute la frame visible, y a pas grand chose qui exploite toute la surface), vous pouvez donc opter pour la modeline suivante pour le CPS-III :

Code : Tout sélectionner

Modeline "384x224"   7.500   384 404 440 486   224 233 236 259  -hsync -vsync

En détails :

H_FPORCH = 20
H_SYNC = 36 ( 4.8 µs de synchro )
H_BPORCH = 46 ( Hsync + Bporch = 82 pixels )

V_FPORCH = 9
V_SYNC = 3
V_BPORCH = 23 ( Vsync + Bporch = 26 lignes )


MAIS, car il y a un mais, tout ceci n'est cohérent que si votre carte graphique permet bien de paramétrer les timings selon une précision de 1 pixel... Et malheureusement, quand bien même vous pensez que c'est le cas, le driver, silencieusement au dernier moment, il arrondit tout selon des multiples de 8 au niveau horizontal pour correspondre à la norme VESA, qui prévoit les timings selon des blocs de caractères de 8 pixels de large (c'est la base selon laquelle le registre du CRTC fonctionne). Et le fait d'outre passer cette limite, ça tient plus de l'exception que de la norme...

Donc, prévoir soigneusement ses timings selon des chiffres justes (ceux du standard NTSC et ceux des informations concernant les systèmes arcade et les émulateurs), ça ne garantit pas le succès de l'opération.
Je bosse sur le sujet en ce moment, donc j'ai pas encore suffisamment d'infos, mais va falloir revoir toute cette logique pour s’accommoder de cette limite du CRTC, parce que c'est pas facile d'y échapper. Même les cartes avec TV out continuent de fonctionner en base 8 pour la partie VGA (la précision au pixel n'affecte que les modes TV, en composite ou S-video donc... :? )
en fait si je comprend bien si on veut vraiment se rapprocher au maximum des pcb d'origine y'as pas le choix faut retoucher la geometrie pour chaque jeux emuler pas possible d'avoir 50 resolution differente qui se cale parfaitement sur l'ecran sans toucher a la geometrie j'ai juste ?
Le fait est que toutes les cartes arcade n'assurent pas une logique respectée à la lettre, et sachant que les données sont différentes pour les jeux des 80's et des 90's. Il est possible " d'harmoniser " toutes ces différences en s'en tenant à un seul standard bien compris (en l’occurrence, le NTSC avec ses chiffres bien définits), mais ça n'est possible que si sa carte graphique permet de réellement piloter les timings au pixel près. Si tel est le cas, en respectant les tailles de frames de chaque système, oui il est possible de caler les parties active display au même endroit sur son écran. Certes, les images n'auront pas toutes exactement la même taille à l'écran, mais ça sera suffisamment proche. Seulement, il en va autrement quand on passe en base 8 ...
peut tu me redonner un exemple pour la resolution native de demon front en 448X224 comment tu calcul par rapport au drivers donner dans mame
Je me suis occupé de ce driver, mais ça mérite un petit post détaillé. Et encore une fois, les timings n'ont de sens qu'en fonction d'une référence sur laquelle on cale la géométrie de son écran. Si on parle en base 8, il faudra aussi assuré la géométrie de son écran selon une modeline basée sur les multiples de 8 (ce qui ne correspond pas du tout au monde broadcast), histoire que ça ait du sens.

L'idée à la fin étant d'avoir les jeux qui tournent au plus proche de la fréquence prévue à l'origine, et sans avoir à toucher aux réglages de son écran.

soudara
stick de bronze
Messages : 104
Inscription : 30 janv. 2010, 11:10
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#32 Message par soudara »

salut
deja je veut te dire merci pour toute tes explications t'assure vraiment
donc voila j'ai fait quelques test sur ma aero avec une trinitron cabler en rgb vga peritel et soft15khz
alor pour le cps3 en utilisant exactement la modeline de ton 1er post
Modeline "384x224" 7.500 384 400 435 486 224 240 243 259 -hsync -vsync
alor sous mame en direct drawn avec juste throttle activer et switch resolution to fit en selectionnant ta modeline avec sync sound activer latency 1/5
tout le reste desactiver ,wait vsync ,sync monitor refresh,triple buffering
j'ai une ligne horizontal qui balaye l'ecran regulierement
meme probleme avec metalslug avec ta modeline et les meme options je croit que le probleme c'est que mame ne donne pas la meme frequence de rafraichissement vertical
parcequ' avec toki et bubble bobble avec excatement la meme configuration que street3 et mslug avec tes modelines et les frequences verticale qui colle parfaitement a celle de mame c'est juste splendide tout est syncroniser son et image j'obtien la meme image que sur la photo de la borne que ta poster avec bande noire sur les coter avec le bout d'image au dessus du score de toki rogner par le bord de l'ecran mais le rendu est vraiment exceptionel c tellement net precis et fluide
merci en tout cas
j'attend avec impatience ton sujet traitant le pgm ,cave
++++++

Avatar de l’utilisateur
Epsylon
Théoricien du pixel
Contact :
Messages : 1222
Inscription : 17 oct. 2006, 23:42
Localisation : Marseille
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#33 Message par Epsylon »

soudara a écrit : alor sous mame en direct drawn avec juste throttle activer et switch resolution to fit en selectionnant ta modeline avec sync sound activer latency 1/5
tout le reste desactiver ,wait vsync ,sync monitor refresh,triple buffering
j'ai une ligne horizontal qui balaye l'ecran regulierement
Si le but de ces modelines, c'est de correspondre à la durée de frame prévue par MAME, il faut quand même que l'émulateur puisse se synchroniser avec la carte graphique. Sous Windows, on est dans un environnement multi tâches où le temps réel n’existe pas, donc il faut au moins attendre le signal de synchro de la carte graphique. Les options Vsync et WaitForSync vont dans ce sens. En fait, les problèmes générés par ces options (auxquels on remédie classiquement par l'usage du triple buffering qui engendre de l'input lag ) ne sont dues qu'à la non correspondance entre le mode de la carte graphique et le pré-rendu de MAME. Ceci dit, le fait de ne rien cocher permet de savoir si on a bien atteint la durée de frame : le phénomène de tearing apparait, mais il reste localisé au même endroit à l'écran. Si le tearing se déplace, ça veut donc dire que non seulement y a pas de synchronisation entre l'ému et la carte graphique, mais également que la durée de frame ne correspond pas (ce qui peut provenir d'une modeline qui ne correspond pas ou qui a été modifiée en interne par le driver pour passer en base 8, et ainsi ruiner le timing original).
je croit que le probleme c'est que mame ne donne pas la meme frequence de rafraichissement vertical
Toutes les versions de MAME n'ont pas forcément les mêmes taux pour les jeux ! Ca change de temps à autre, il faut bien surveiller ça.
De même, le throttling code peut subir des variations d'une version à l'autre. Certains jeux peuvent en être affectés, car tous les drivers ne sont pas écrits exactement de la même façon (suffit de voir comment sont gérés les paramètres vidéos...).
j'obtien la meme image que sur la photo de la borne que ta poster avec bande noire sur les coter avec le bout d'image au dessus du score de toki rogner par le bord de l'ecran
Oui mais là ça décrit l'exemple typique des paramètres (mal) conçus en arcade. L'idée est d'obtenir la bonne vitesse du jeu, mais si possible corriger les erreurs de dimensionnement de frame et de centrage, de façon à ne pas avoir à toucher aux réglages de son écran (ce qui est quasi obligatoire sur une vraie borne avec de vraies PCBs).

Ceci dit, vu la faible marge de manoeuvre, on risque de ne plus atteindre la durée exacte de frame, mais des builds alternatifs comme GroovyMAME compensent très bien les écarts, surtout pour la partie audio (j'en ai causé en détail avec l'auteur de ce build).
Donc, quand c'est possible, viser la durée exacte, mais sinon, s'en approcher le plus possible. Le tout étant d'éviter les saccades et l'input lag, qui sont les écueils récurrents du MAME de base.

Avatar de l’utilisateur
Epsylon
Théoricien du pixel
Contact :
Messages : 1222
Inscription : 17 oct. 2006, 23:42
Localisation : Marseille
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#34 Message par Epsylon »

Bon, maintenant, un p'tit topo sur le PGM , avec sa résolution particulière de 448x224 (mais toujours au format 4/3 !).

Que nous dit MAME ?

Code : Tout sélectionner

  523      /* video hardware */
  524      MCFG_SCREEN_ADD("screen", RASTER)
  525      MCFG_SCREEN_REFRESH_RATE(60) // killing blade won't boot (just displays 'error') if this is lower than 59.9 or higher than 60.1 .. are actual PGM boards different to the Cave one?
  526      MCFG_SCREEN_VBLANK_TIME(ATTOSECONDS_IN_USEC(0))
  527      MCFG_SCREEN_SIZE(64*8, 64*8)
  528      MCFG_SCREEN_VISIBLE_AREA(0*8, 56*8-1, 0*8, 28*8-1)

Alors voilà, y a UN jeu qui ne boot pas si on met autre chose que 60 Hz, et ça suffit pour ruiner les timings de tous les autres, qui fonctionnent pourtant à une autre vitesse...
En effet, quand on reprend quelques builds antérieurs (0.140, fin 2010) :

Code : Tout sélectionner

 1540       /* video hardware */
 1541 	MCFG_SCREEN_ADD("screen", RASTER)
 1542 	MCFG_SCREEN_REFRESH_RATE(59.17) // verified on pcb
 1543 	MCFG_SCREEN_VBLANK_TIME(ATTOSECONDS_IN_USEC(0))
 1544 	MCFG_SCREEN_FORMAT(BITMAP_FORMAT_INDEXED16)
 1545 	MCFG_SCREEN_SIZE(64*8, 64*8)
59.17 Hz, mesuré et confirmé par d'autres possesseurs de ce système.

Mais bon, les deux fréquences sont bonnes, c'est juste que y a un seul jeu qui a besoin de 60 tout rond. Et dans tous les cas, aucune indication sur les paramètres vidéo, sur comment on atteint l'une ou l'autre fréquence... Sinon, une fenêtre standard surdimensionnée pour les deux versions du code source :

MCFG_SCREEN_SIZE(64*8, 64*8) , soit 512 x 512 :o

Je vous déconseille bien évidement de générer une modeline de 512x512... :roll:

Alors voilà, va falloir inspecter la PCB. Quels sont les oscillateurs qui pourraient fournir un bon pixel clock (après division) pour une telle résolution ?
Sachant qu'à l'horizontal, on a besoin de prévoir entre 20 et 30% d'info de synchro, soit une fenêtre de 537 à 582 pixels au total. Sachant qu'il faut qu'on soit entre 15 et 16 kHz, ça nous donne à la louche entre 8 et 9 MHz de pixel clock. Et faut trouver une combinaison qui permette de passer du taux standard (environ 59.17 Hz ) à exactement 60 Hz (même si la PCB prévoit un peu de marge, qui correspond aux écarts de fréquence des oscillateurs). Ca peut se faire en modifiant le nombre de lignes totales ou le nombre de pixels à l'horizontal (nombre de cycles).

La carte propose deux oscillateurs :
- 33.8688 MHz (valeur standard utilisée dans les lecteurs CD)
- 50 MHz

On pourrait opter pour celui à 50, bien rond et facile, mais ça nous donnerait 8.333333333 (etc.) MHz après division (par 6).
A côté, celui à 33.8688 donne exactement 8.4672 MHz après division par 4.
Le flair epsylonien est de rigueur ici ( :roll: ), c'est cette valeur qui sera retenue.
Mais bon, avec ça, faut se démerder à tomber sur ~16.667 ms de durée de frame (1/60).

A la louche, on peut avoir un nombre total de pixels de : 8.4672 x 16666.6667 = 141120.00028224, soit 141120 pixels.
Maintenant, vous vous souvenez du CPS-III, de sa fenêtre taillée pour la zone de 5% d'overscan du NTSC ?
Et bien les systèmes étant de la même période, on peut supposer qu'il en va de même pour le PGM. Alors, je vous fais grâce des tâtonnements, pour vous livrer directos les chiffres :

pour un taux de 60 Hz exactement, la fenêtre totale du jeu est de 560 x 252 (ce qui nous donne bien 141120).
Chaque ligne se compose de 2240 cycles.
La fréquence horizontale est de : 8.4672 / 560 = 15120 Hz , un nombre fort commode qui va bien pour afficher 252 lignes à 60 Hz : car 15120 / 256 = 60 tout rond.

Les timings pour le jeu Killing blade :

Code : Tout sélectionner

Modeline "448x224"   8.4672   448 468 508 560   224 231 234 252  -hsync -vsync
Image
(note: le screenshot est pourri mais j'ai que ça sous la main :lol: )

On correspond bien à la zone de 5% d'overscan, même si une petite partie du haut de l'image (au dessus du timer) est un peu rognée (on retrouve le même principe pour l'affichage des jeux Neo Geo, et de pas mal de systèmes).

Ici, il y a 40 pixels pour la Hsync (4.72 µs), mais il est probable que le vrai hardware donne 40.25 pixels (161 cycles), pour atteindre les 4.75 µs des moniteurs arcade.



Maintenant, qu'en est-il des autres jeux mesurés à 59.17 Hz ?
Et bien la fenêtre totale change légèrement, tout en conservant le même pixel clock : on passe à 559x256, ce qui nous donne environ 59.168157 Hz (~16900.98 µs).
On est proche du taux mesuré, et un peu en dessous, ce qui est bon signe (les oscillateurs ayant tendance à augmenter en fréquence avec la chaleur et l'usure du temps, donc les mesures sont toujours un peu plus élevées que ce qui est prévu niveau hardware).

Les timings :

Code : Tout sélectionner

Modeline "448x224"   8.4672   448 467 507 559   224 233 236 256  -hsync -vsync
Image

Note : ce mode profite d'une période de Vblank un peu plus longue (256 lignes contre 252), ce qui est appréciable en terme de cycles CPU.

Bien sûr, je ne suis pas absolument sûr à 100% de ces chiffres, mais ça colle à la réalité du standard NTSC (qui affecte aussi la mise au point des écrans arcade), et ça s'appuie sur un pixel clock plausible.

Maintenant, faut que le driver pgm.c soit mis à jour, et ces infos sont quand même nettement plus précises que ce qui est donné pour l'instant (c'est à dire pas grand chose).

Ceci dit, les cartes graphiques, dans le meilleur des cas, ne peuvent accepter une précision qui dépasse 0.001 MHz, donc il n'est pas possible de prendre le 8.4672 tel quel (ça fait 4 chiffres après la virgule). Pour viser un 60 Hz avec un pixel clock gérable, il faut monter un peu en fréquence, à 15600 Hz. Ainsi, on obtient : 15600 x 560 = 8.736 MHz. Et on affiche 260 lignes pour obtenir 60 Hz tout rond.

Code : Tout sélectionner

Modeline "448x224"   8.736   448 468 508 560   224 235 238 260  -hsync -vsync
Pour obtenir du 59.17 Hz environ :

Code : Tout sélectionner

Modeline "448x224"   8.615   448 468 508 560   224 235 238 260  -hsync -vsync
On conserve la même fenêtre mais on fait varier le pixel clock, contrairement à ce qui se passe sur le vrai hardware, où un seul pixel clock est possible.

A venir : les jeux Cave de 1ère génération.

Avatar de l’utilisateur
Seifer63
stick de bronze
Messages : 151
Inscription : 16 nov. 2008, 03:46
Localisation : Clermont-Ferrand
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#35 Message par Seifer63 »

Vraiment énorme Epsylon :) C'est exactement le genre de sujet que j’adore !

J'ai essayer de monter un modeline pour le CPS1 en reprenant ce que tu fais dans ton premier post.

En fouillant dans cps1.c, j'ai trouvé ça:

Code : Tout sélectionner

 
3163  //  MCFG_SCREEN_REFRESH_RATE(59.61) /* verified on one of the input gates of the 74ls08@4J on GNG romboard 88620-b-2 */
3165  //  MCFG_SCREEN_SIZE(64*8, 32*8)
3166  //  MCFG_SCREEN_VISIBLE_AREA(8*8, (64-8)*8-1, 2*8, 30*8-1 )
3167      MCFG_SCREEN_RAW_PARAMS(XTAL_16MHz/2, 518, 64, 448, 259, 16, 240) /* guess: assume that CPS-1 uses the same exact timings as CPS-2 */
Ce qui nous fait un Pixel Clock de 16MHz/2 = 8 MHz.
Le Horizontal Rate est de 8 000 000 / 518 = environ 15 444.01544 Hz = environ 15.44401544 kHz
De fait, le Vertical Rate est de 15 444.01544 / 259 = environ 59.6294 Hz (ça à l'air proche des 59.61 mesuré).

Maintenant on calcul de VSync et le Hsync:
1) HSync
1 / (PIXEL Clock / 518) nous donne la durée pour afficher une ligne horizontale soit 64.75 µs pile.
Vu que le HSync doit durer environ 4.7 µs, cela correspond à (4.7 x 518) / 64.75 = 37.6 soit 38 px de HSync.

2) VSync
1/((PIXEL Clock / 518) / 259) nous donne la durée pour afficher une ligne verticale (par équivalence, on peut aussi faire 64.75 x 259) soit 16 770.25 µs pile.
Vu que le VSync doit durer environ 200 µs, cela correspond à (200 x 259) / 16 770.25 = 3.0888... soit 3 px de VSync.

Pour le calcul des porch, j'ai repris la formule d'Epsylon pour le CPS3 (je ne sais pas si c'est correct dans ce cas là)
Ce qui donne pour la verticale:
(259 - 224 - 3) / 2 = 16 px pour le front et le back porch vertical

pour l'horizontale:
(518 - 384) / 2 = 67 px pour le back porch horizontal
67 - 38 = 29 px pour le front porch horizontal

Pour la Modeline, ça nous donne donc:

Code : Tout sélectionner

Modeline "384x224@52.629"  8   384 413 451 518    224 240 243 259    -hsync -vsync
Je tiens à préciser que je ne suis pas encore 100% sûr de mon coup sachant que le PIXEL CLOCK n'est pas certifié dans le cps1.c. Du coup Epsylon, est-ce que tu pourrais jeter un œil et dire si le calcul est bon ou si je me suis planté quelque part (ce qui est fort probable, lol)

Avatar de l’utilisateur
Hasary
stick de carton
Messages : 4
Inscription : 03 nov. 2004, 22:32
Localisation : Blida
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#36 Message par Hasary »

Bonjour,
j’essaye de définir une custum modeline pour afficher les jeux 240x320 (V) de mame sur un écran horizontal. (TV PAL ou NTSC 4:3).
je me suis basé sur le jeu "outzone" comme exemple, je vise à obtenir une image en:

- perfect aspect ratio du jeu
- 60 hz tout rond (obligé pour TV NTSC??)
- rotation (bien sure^^) tout en exploitant le max d'espace vertical de l’écran

le but en image:

Image

ma TV étant en 4:3 j'ai calculé le x en se basant sur le y=320 du jeu qui doit correspondre au y de ma résolution:
x=320*4/3 = 426.6666 que j'ai arrondi en 426
ça me fait donc une résolution de 426x320
en entrant ses paramètres sur l'outil winmodelide ça me sort ceçi:

Code : Tout sélectionner

Modeline "426x320 15,7KHz 59,9Hz" 8.182 426 440 479 520 320 408 414 525 interlace -hsync -vsync  
mais le résultat en test est terrible; bien que la résolution est correcte, j’obtiens une image rétrécie verticalement avec deux énormes bandes noir en haut et en bas...

Image

je ne suis pas capable de faire une modeline "à la main" alors j'ai besoin de votre aide, comment modifier cette modeline pour étirer l'image verticalement?

De plus, si cet outil winmodeline qui donne automatiquement des modelines à partir de la résolution souhaitée et le type de moniteur,mais n'est pas très "correct" pourquoi ne pas développer un soft qui auto-gen modelines à partir des sources de mame. je suis partant si quelqu'un s’intéresse et accepte de m'aider.

Avatar de l’utilisateur
mr.bombjack
stick de platine
Messages : 2047
Inscription : 28 juil. 2011, 16:53
A remercié : 5 fois
A été remercié : 28 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#37 Message par mr.bombjack »

avec la méthode du modeline pour du pixel perfect, a chaque changement de jeu, on fait comme avec une PCb, on est obligé d'ajuster l’écran avec les potards en largeur/longueur et en position haut/bas et en position gauche/droite ?
ImageImageImage

Avatar de l’utilisateur
Hasary
stick de carton
Messages : 4
Inscription : 03 nov. 2004, 22:32
Localisation : Blida
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#38 Message par Hasary »

J'ai trouvé une page sur le net qui explique mon objectif:

http://easymamecab.mameworld.info/html/monitor8.htm

mais j'arrive toujours pas à réaliser la modeline correspondante , quelqu'un peut help?

soudara
stick de bronze
Messages : 104
Inscription : 30 janv. 2010, 11:10
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#39 Message par soudara »

salut

en fait les jeux a resolutions verticaux son juste des resolutions horizontaux avec un ecran tourné en mode

portrait,

par defaut mame lance les jeux verticaux en horizontaux faut juste faire tab rentrer dans le menu et effectuer

une rotation de 90 degres dans video ensuite tourner l'ecran en mode portrait

exemple demon front 448x224 horizontal et ddp2 224x448 vertical , n'essayer pas de creer une reso 224x448

elle existe pas c bien 448x224 avec une rotation dans le menu video et vous aurait le jeux en reso native en

vertical je dit sa car jai vu sur des forum des gens essayer de crée ses resolutions

@+

Avatar de l’utilisateur
mr.bombjack
stick de platine
Messages : 2047
Inscription : 28 juil. 2011, 16:53
A remercié : 5 fois
A été remercié : 28 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#40 Message par mr.bombjack »

Étant neophyte dans l’émulation quelqu'un peu m'éclairé sur le modeline.
Avec la méthode du modeline pour du pixel perfect, a chaque changement de jeu, on fait comme avec une PCb, on est obligé d'ajuster l’écran avec les potards en largeur/longueur et en position haut/bas et en position gauche/droite ?
ImageImageImage

Avatar de l’utilisateur
Quartz63
stick de bronze
Messages : 139
Inscription : 16 juin 2014, 12:54
Localisation : Issoire, Puy de Dôme
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porch

#41 Message par Quartz63 »

Merci Epsylon pour ce post si complet! 8O
J'avoue qu'il devrait me falloir une bonne soirée complète et une cafetière pour en arriver à bout mais le sujet est vraiment digne d'intérêt! :roi:
Joyeux propriétaire d'une SEGA NEW ASTRO CITY avec CrossBox Horizontale inside! :p
Imageimagik

Rastan
stick de platine
Messages : 1528
Inscription : 22 nov. 2004, 21:43
A remercié : 0
A été remercié : 1 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#42 Message par Rastan »

Je viens de retrouver ce topic très très intéressant même si je ne comprend pas tout :P et je m'aperçois que ma version de 3.3 n'a pas une fréquence verticale de 15,432 Khz comme l'original mais de 15,670 Khz... Comment faire pour atteindre ce taux en créant une modeline? J'ai essayé d'entrer toutes les données de la modeline d'epsylon mais je ne tombe jamais sur les bons chiffres. C'est toujours approximatif. Du genre au lieu de 404 je vais avoir, par exemple, 402, au lieu de 440 j'aurais 444 etc...
Si quelqu'un savait comment faire afin de m'expliquer tout ça ce serait vraiment cool! 8)
Merci! :)

peSlug
stick de plastique
Messages : 7
Inscription : 30 juin 2015, 18:09
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#43 Message par peSlug »

Petite question, maintenant qu'il y a les super resolutions, où peut on ajuster ses modelines ? Mame.ini (de groovymame) n'en contient plus

Merci !

Nevohteeb
stick de plastique
Messages : 40
Inscription : 03 déc. 2009, 14:34
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#44 Message par Nevohteeb »

Epsylon a écrit : 19 févr. 2013, 20:47 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.
Bonjour à tous,

J'aimerais comprendre d'où viennent les informations ci-dessus concernant les interval de blanking de 4.7us et 200us.
En effet, sur la notice de mon Hantarex MTC9110 je vois :
  • Video pass band : -3dB at 12 MHz
  • Horizontal blanking : 12us
  • Vertical blanking : 1ms
  • Horizontal scanning frequency 15.625kHz +/- 0.5kHz adjustable
  • Vertical scanning frequency 45-65 adjustable
On voit bien que les valeurs que j'ai ne correspondent pas. Ai-je un écran particulier?

Avatar de l’utilisateur
Jontox
stick de plomb
Messages : 73
Inscription : 13 sept. 2016, 18:49
Localisation : Arlon (Belgique)
A remercié : 2 fois
A été remercié : 6 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#45 Message par Jontox »

C'est dommage mais il semblerait que Epsylon ne soit plus présent sur le forum depuis pas mal de temps

Epsylon
Joined: 17 Oct 2006, 23:42
Last active: 27 May 2014, 19:30
Total posts: 1222
[0.11% of all posts / 0.24 posts per day]
Search user’s posts

Il me semble effectivement que chaque moniteur dispose d'un profil différent.

J'aurais tellement apprécié avoir auj. le point de vue d'Epsylon sur Grovvymame, VMM..., bref tu constateras dans le lien ci-dessous que Calamity (celui qui gère GroovyMame) a explicité la nécessité de connaître les caractéristiques précises de chaque écran afin que Groovymame puisse proposer automatiquement le modeline le plus adapté pour le pcb concerné, en resumé c'est le raisonnement exposé par Epsylon, automatisé et en fonction de l'écran utilisé, le nec plus ultra :-D
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=46

Nevohteeb
stick de plastique
Messages : 40
Inscription : 03 déc. 2009, 14:34
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#46 Message par Nevohteeb »

Jontox a écrit : 22 juil. 2020, 19:13 bref tu constateras dans le lien ci-dessous que Calamity (celui qui gère GroovyMame) a explicité la nécessité de connaître les caractéristiques précises de chaque écran afin que Groovymame puisse proposer automatiquement le modeline le plus adapté pour le pcb concerné, en resumé c'est le raisonnement exposé par Epsylon, automatisé et en fonction de l'écran utilisé, le nec plus ultra :-D
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=46
je vois ça.
J'utilise switchres moi, qui est intégré à MAME.

http://forum.arcadecontrols.com/index.p ... 405.0.html

Le souci c'est que les personnes qui ont réalisé switchres donnent des valeurs pour mon écran qui :
1) sortent de nulle part
2) ne correspondent pas tout à fait à ce que je vois dans le service manual.

Pour le moment j'ai réussi à générer deux dodelines qui m'intéressent, à savoir le 320x224 et le 448x224, mais pas le 384x224.
Je vais essayer avec VMM.

Avatar de l’utilisateur
Jontox
stick de plomb
Messages : 73
Inscription : 13 sept. 2016, 18:49
Localisation : Arlon (Belgique)
A remercié : 2 fois
A été remercié : 6 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#47 Message par Jontox »

Quand tu dis: "Sortent de nulle part", tu veux dire en terme de résolution ou de fréquence de rafraîchissement ?

Nevohteeb
stick de plastique
Messages : 40
Inscription : 03 déc. 2009, 14:34
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#48 Message par Nevohteeb »

Jontox a écrit : 28 juil. 2020, 18:58 Quand tu dis: "Sortent de nulle part", tu veux dire en terme de résolution ou de fréquence de rafraîchissement ?
Il y a plusieurs valeurs qui m'interpellent.
Dans VMM et dans Switchres, voici les valeurs utilisées pour un écran Hantarex MTC 9110 :

Code : Tout sélectionner

// Hantarex MTC 9110
	else if (!strcmp(type, "h9110") || !strcmp(type, "polo"))
	{
		fill_monitor_range(&range[0], "15625-16670, 49.5-65, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 192, 288, 448, 576");
		return 1;
	}
Sachant que, dans l'ordre, on a :

Code : Tout sélectionner

HfreqMin-HfreqMax, (values in kHz), VfreqMin-VfreqMax, (values in Hz), HFrontPorch, HSyncPulse, HBackPorch, (values in microseconds),                VfrontPorch, VSyncPulse, VBackPorch, (values in miliseconds), HSyncPol, VSyncPol, (0 = negative, 1 = positive), ProgressiveLinesMin, ProgressiveLinesMax,(number of lines), InterlacedLinesMin, InterlacedLinesMax (number of lines)
On voit dont déjà que les valeurs de fréquences horizontales et verticales ne correspondent pas au service manual de l'écran, puisque d'après ce dernier on devrait avoir :
  • H : 15125Hz-16125Hz (15625Hz +/- 500Hz)
  • V : 45Hz-65Hz
Ensuite, toujours sur le service manual on lit :
  • Horizontal blanking : 12us
  • Vertical blanking : 1ms
Les valeurs utilisées dans VMM et switchres donnent :
  • Horizontal blanking : 2 + 4.7 + 8 = 14.7us
  • Vertical blanking : 0.064 + 0.160 + 1.056 = 1.28ms
Enfin, d'où viennent les valeurs de front et back porchs ? J'imagine bien qu'elles viennent de quelque part, juste j'aimerais comprendre d'où et pourquoi on ne retrouve pas les valeurs du constructeur.

Pour info, j'ai généré les dodelines suivantes avec switchres, en me basant sur les données trouvées dans le fichier .dat généré par MAME :
  • ModeLine 320x240x60.00 6.63984 320 336 368 424 240 242 245 261

  • Modeline 384x224x59.63 7.904513 384 400 440 504 224 235 238 263

  • Modeline 448x224x59.17 9.408014 448 472 520 600 224 236 239 265

  • Modeline 448x224x60.00 9.396 448 472 520 600 224 234 237 261

  • Modeline 384x224x60.00 7.89264 384 400 440 504 224 234 237 261

  • Modeline 320x224x59.19 6.650094 320 336 368 424 224 236 239 265

  • Modeline 320x224x60.00 6.63984 320 336 368 424 224 234 237 261


Les vertes fonctionnent, les rouges pas.
Dernière modification par Nevohteeb le 01 août 2020, 18:03, modifié 1 fois.

Avatar de l’utilisateur
Jontox
stick de plomb
Messages : 73
Inscription : 13 sept. 2016, 18:49
Localisation : Arlon (Belgique)
A remercié : 2 fois
A été remercié : 6 fois

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#49 Message par Jontox »

Effectivement, je comprends.
Les valeurs du manuel sont celles que tu renseignes et non celles reprises dans le code source de VMM.

A ce stade, je te suggère de poster ton dernier message sur le forum arcade controls.
Calamity suit de près ce forum, et est toujours réactif.
http://forum.arcadecontrols.com/index.p ... 23.40.html

En ce qui concerne les valeurs de Porch, il me semble que ce sont des standards définis dans la norme NTSC.
Ce qui devrait signifier que dans le cas de ton écran que le HSyncPulse est inférieur de 2.7 us et abaisse le Horizontal blanking à 12 us (2 + 2 + 8 ).

Je ne suis pas expert, mais ca serait vachement intéressant d'avoir l'avis de Calamity sur ce point.

N.B.: Je pensais sincèrement que Calamity avait mis la main sur ces écrans pour encoder les monitors specs dans son outil, où alors pour certain modèle les valeurs lui ont été transmises sans vérification de son côté.
Je m'attendais également que les plages de fréquences réelles H & V d'un moniteur devait être légèrement plus large que les valeurs renseignées dans le manuel, permettant ainsi à VMM de pousser les modèles connus au delà des prescriptions techniques du fabriquant et accepter en conséquence plus de ModeLine.

Tiens nous au courant...

Nevohteeb
stick de plastique
Messages : 40
Inscription : 03 déc. 2009, 14:34
A remercié : 0
A été remercié : 0

Re: [Tech 240p] à propos des modelines, pixel clock et porchs

#50 Message par Nevohteeb »

Jontox a écrit : 29 juil. 2020, 14:05
A ce stade, je te suggère de poster ton dernier message sur le forum arcade controls.
Calamity suit de près ce forum, et est toujours réactif.
http://forum.arcadecontrols.com/index.p ... 23.40.html
J'ai voulu m'inscrire mais:
Sorry, registration is currently disabled.
C'est dommage parce que je suis d'accord avec toi, je pense que les personnes qui portent ces projets savent de quoi ils parlent et ils pourraient dissiper mes doutes en m'indiquant simplement leurs sources.

J'ai vu qu'on pouvait passer des options nous même à Switchres et VMM pour la génération de dodelines via l'option -crt_range. Je vais essayer.

Répondre