Ca ressemble à un phénomène nommé streaking dans le jargon CRT, ça se produit à droite des images : dès que l'intensité diminue, le point lumineux précédent fait une sorte d'écho (et forcément ça ne peut se passer qu'à droite, vu que le canon balaye de gauche à droite) et ça touche à l'amplification vidéo.
Si un réglage du THT ne solutionne pas le problème, il faut checker les capacités des condensateurs du cap-kit, il pourrait y avoir eu une erreur...(dont les effets se manifestent après que la température de fonctionnement ait légèrement altéré les valeurs).
A part ça, je vois pas trop...

Disons, en priorité les jeux à 100%.
Le but de la manoeuvre, c'est de faire une grosse mise à jour générale de MAME. Mais bon, c'est un énorme boulot, alors autant commencer par l'essentiel, et surtout ce qui est jouable dans les meilleures conditions.
A côté, c'est pas que les jeux de Mahjong ou les Gals Panic aient un besoin crucial d'être joués sans le lag habituel de MAME, causé (entre autre) par les options triple bufering / Wait for sync etc. qui génèrent un délai de une à deux frame supplémentaires (16 à 32 ms en gros). Par contre, un bon shoot bien raide ou un Tetris The Grand Master, on apprécierait de gagner deux précieuses frames à ce niveau. Parce que même si ces jeux sont diffusés à résolution native (pour la partie visible de l'image !), la question de la synchro dépend de tous les paramètres du signal (nombre de pixel total et de lignes totales en dehors de la surface visible, et le pixel clock). Il faut que la modeline corresponde exactement à ce qui est inscrit dans les drivers. Et c'est là où ça coince...

Par exemple, pour le driver simpl156.c, il est indiqué un vague " 58 Hz " pour le taux vertical (et ce depuis près de 10 ans). Alors, c'est facile de diffuser une image de 320x240 à 15 kHz avec un nombre de paramètre très variés (cf PowerStrip, Soft15kHz etc.), mais c'est quasi *impossible* d'obtenir un parfait 58.0000000000000 Hz (nombre qui est utilisé pour définir le délai entre deux frames dans l'émulateur). Pour les modelines, on est limité à des nombres intégraux pour tous les paramètres (nombre de lignes, de pixel par ligne etc). Même le pixel clock doit être un nombre entier, en Hz (même si on le lit en MHz, donc avec une virgule).
Pour obtenir un "parfait" 58 Hz, il faut un pixel clock qui risque d'être un nombre de Hz à virgule. Mais ça, c'est juste du point de vue des maths. Ce qui contraint encore la chose, c'est que en fait, le pixel clock ne peut pas dépasser une précision de l'ordre du kHz... Ca tient du fait que le pixel clock des cartes graphiques est déterminé par une PLL qui se base sur un oscillateur de 27 MHz sur la carte graphique (quelque fois 25 ou 13.5), qui sera multiplié et divisé par des nombres entiers pour arriver au plus proche de la fréquence désirée.
Disons que pour respecter le taux indiqué par MAME tu ai besoin d'un pixel clock de 5.17486954 MHz (soit 5174869.54 Hz), même si celui ci est écrit dans la modeline, il sera déjà ramené à une valeur arrondie 5174870 Hz), qui sera elle aussi transformée ( 5175 kHz !). Et en dernier lieu, y a de fortes chances que la possibilité permise par la PLL donne 5174 ou 5176 kHz. Donc, on perd la synchro, puisque ces changements font qu'il n'est plus possible d'obtenir un parfait 58 Hz , alors que l'émulateur lui continue de déterminer des transferts de données par rapport à ce taux mathématiquement parfait. Résultat, malgré un rendu pixel perfect à l'écran, la différence entre les valeurs de l'émulateur et la réalité de la carte graphique entrainent un phénomène nommé tearing, en plus d'un décrochage son. Pour y remédier, il est nécessaire d'activer le triple buffering ou autre options qui sont là pour compenser l'écart...... Et qui induisent du lag, parce qu'il est nécessaire de stocker une à deux frames pour assurer un défilement sans accrocs à l'écran.
Pour échapper à la fois au tearing et au buffering, il faut que les paramètres de MAME correspondent à ce qu'il est possible de générer au niveau signal, par des modelines qui ont des contraintes que n'avaient pas les systèmes émulés.

La plupart des systèmes arcade sont heureusement basés sur des nombres entiers, qui sont aisés à retranscrire avec des modelines. Sur le topic posté sur Neo-Arcadia, j'ai pris l'exemple du MVS :
un pixel clock de 6 MHz tout rond (soit 6000 kHz), 264 lignes, 384 pixels par lignes.
Ce sont ces paramètres qui nous donnent le taux indiqué au boot de chaque jeu (ici : 59.185606 Hz)

En hz:
6000000 / 384 = 15625 Hz de fréquence de ligne. Divisé par 264 lignes à afficher : 59.185606060606 etc.

Mais simplement: 384*264 / 6 = 16896 µs par frame. Un nombre entier.

Il est facile d'écrire une modeline qui respecte ces paramètres, qui seront assurés sans mal par n'importe quel carte graphique (il est plus facile de produire 6 MHz que de respecter 5.17486954 MHz).
Si les paramètres de MAME et de la modeline correspondent (on obtient le même taux vertical en Hz, et surtout le même nombre de µs), alors ça roule.

L'autre modeline que j'ai pris en exemple, avec son pixel clock à 6.675189 MHz (au lieu de 6 tout rond, comme ce qui est constaté sur le vrai hardware), non seulement on obtient pas le taux vertical exact, mais en plus il est impossible que la PLL de la carte graphique produise une telle valeur, même s'il s'agit d'un nombre entier de Hz (parce qu'on ne dépasse pas la précision de l'ordre du kHz).
Et sur le web, on en trouve beaucoup des modelines avec des pixel clock improbables de ce genre. Qu'il s'agisse d'une écriture manuelle ou du résultat issu d'un générateur (qui se tient au plus proche mais à peu de chances de tomber sur les paramètres exacts).

Tous les jeux qui sont listés pour un taux générique de 60 Hz (qui ne correspond certainement pas à la réalité du hardware), ou une mesure avec un ou deux chiffres significatifs après la virgule (ex: 59.61000 Hz) témoignent de drivers mal renseignés au niveau affichage, et d'une impossibilité de générer des modelines qui respectent ces valeurs approximatives.

Même quand on essai de viser un bô 60 Hz tout rond avec une fréquence de ligne de 15720 Hz (pour 262 lignes en standard, because 262x60 = 15720), il est impossible de tomber sur un bon pixel clock.
Exemple : afficher une image qui comporte 320 pixels visibles par lignes, plus les marges pour la synchro. Disons 445 pixels au total par ligne. On obtient: 445 x 15720 = 6995400 Hz pour le pixel clock, soit 6.9954 MHz... Oui mais en fait, 6995.4 kHz, et on va devoir zapper ce 0.4 de trop.
Ha mais avec ce pixel clock arrondis, ça colle plus :

6995000 / 445 = 15719,101123595505617977528089888 Hz de fréquence.
Divisé par 262 lignes : 59,996569174028647396860794236212 Hz

Malgré le résultat mathématique exacte de la modeline, en fin de chaîne on ne peut pas le retrouver, et on abouti à un écart entre l'émulateur (qui se base toujours sur 60 Hz) et les paramètres arrondis de la modeline (on ne constate plus le 60 Hz parfait). Résultat : on se tape du tearing ou du lag induit par les options de synchro...

Dans la réalité des systèmes, pour 320 pixels visibles par lignes, on aura tendance à trouver 448 pixels au total (multiple de 8 ), et le pixel clock sera un nombre bien pratique issu d'un oscillateur standard. Ex: 28 MHz, qui sera divisé par 4 : 7 MHz.

Et 7000000 / 448 = 15625 Hz. Pour afficher 240 lignes visibles, compte tenu de l'overscan qui existe aussi pour les moniteurs arcade, on va dépasser les 262 lignes habituellement rencontrées (pour les jeux qui n'affichent que 224 lignes visibles en fait). On va obtenir 272 ou un peu plus selon les systèmes, donc le taux vertical va baisser :

- pour 224 lignes visibles, on peut avoir 262 lignes totales : 15625 / 262 = 59.637405 Hz environ
- pour 240 lignes visibles, 272 lignes totales : 15625 / 272 = 57.444853 Hz environ

Dans les faits, les systèmes arcade ne visent que très rarement 60 Hz, et 15625 Hz est une fréquence bien pratique qui est pas mal répandue. Les systèmes ne peuvent pas aboutir à des taux verticaux bien ronds, du genre 58.000000000 Hz, ça demanderait des oscillateurs dédiés au lieu de se baser sur des valeurs génériques.
La durée des frames est plus souvent considérée du point de vue des microsecondes que des Hz, et surtout il s'agit d'assurer une image visible qui tienne compte de l'overscan des moniteurs (5 à 10%), parce que c'est pas tous les exploitants qui sont là pour ajuster l'image sur l'écran de leur bornes, même si ceux ci le permettent aisément.

Donc voilà, y a pas des masses de drivers bien renseignés, et pour ceux là il faut fournir une modeline qui corresponde (ce qui est loin d'être systématique !). Pour les drivers qui sont mal renseignés, il faut écrire les bons paramètres dans les sources, et ensuite compiler un bon build qui déchire.  
Et si les paramètres du système émulé ne sont pas possibles à assurer avec une modeline (parce que le nombre de pixels par ligne n'est pas un nombre entier, ou que la valeur  du pixel clock dépasse la précision du kHz), il faut écrire des paramètres qui soient gérable par les modelines, parce qu'on ne peut pas faire autrement.

Exemple : le PGM de IGS (448x224) est donné pour un taux de 60 Hz par MAME(valeur générique), ce qui est faux. Un seul jeu tourne à cette fréquence, tous les autres ont une fréquence proche du MVS. En examinant le système, il apparaît que le pixel clock provient d'un oscillateur de 33.8688 MHz (qui est un produit standard, on le rencontre dans les lecteurs CD-rom, ça n'a pas été déterminé juste pour ce système). En divisant par 4, on obtient le pixel clock du système : 8.4672 MHz, soit 8467.2 kHz ... Pas possible à retenir, donc il n'est pas question d'écrire cette valeur dans le driver. On choisira une valeur un peu au dessus, car il n'est pas non plus sûr que la PLL de la carte puisse produire 8467 kHz.
L'essentiel, c'est que le résultat des paramètres de l'émulateur corresponde à celui de la modeline, qui elle même doit correspondre à ce qu'il est possible de matériellement produire au niveau de la carte graphique (les limites de la PLL).

Je continuerai en détail plus tard (sachant que le topic sur N-A est bien fourni), là j'ai fait ce petit topo pour bien préciser certaines limites et les problèmes récurrents de MAME, qui ne seront dépassés que lorsque les paramètres auront été fixés correctement. Chose qui n'est pas à attendre de la part de la plupart des gars de la MAME Team, sinon ça ferait des lustres que la question aurait été réglée.
Il n'y a que ceux qui veulent à la fois la fidélité du 15 kHz (scanline feeling) et échapper au lag qui se penchent en détail sur la question, et c'est une extrème minorité.

J'ai déjà une liste perso sur laquelle je bosse (qui comporte bien sûr les gros classiques connus de tous), mais n'hésitez pas à proposer les drivers qui comportent des jeux qui ont retenu votre attention, et qui sont moins cités sur les topics de ce genre.

Sur Neo CD, la musique est au format wav. , ce sont quelques fois les mêmes musiques que la version cartouche, et souvent c'est "remixé" avec plus ou moins de bonheur. Par exemple, la bande son d'un Last Resort cartouche a du punch et du mordant, alors que la version CD est molle et aseptisée.
La Neo CD, ça vaut le coût pour les jeux de 1ère génération (jusqu'à 1992 à peu près), qui ne sont pas ou très peu affectés par les temps de chargements. Et concernant la bande son, ça vaut le coup pour les jeux basés quasi que sur des samples, parce que la version cartouche a un taux d’échantillonnage de 18 kHz seulement. La bande son d'un Pulstar sonne beaucoup plus clair sur CD, grâce à l'échantillonnage à 44 kHz.
Mais rien ne vaut le rendu si particulier du YM2612, qui est d'ailleurs bien plus exploité dans les jeux de 1ère génération.

Pour moi, à deux trois exception près, la Neo CD n'a que peu d'intérêt, même sur le plan de l'émulation (ou greffer les musiques CD sur quelques roms).

Donc si j'ai bien compris (ce qui n'est pas gagné), ça fait des années que je peste contre cette pauvre télé pour qu'elle me sorte du 4/3, alors qu'elle même est persuadée que c'est ce qu'elle fait depuis le début … on ne l'aurait juste pas informée que son tube est tronqué ?

Exactement.

La grosse contrainte pour un tube, c'est la distance "est-ouest" , parce que l'affichage est géré par lignes (et non par colonnes).
Il est aisé de réduire la hauteur de l'image : " l'écraser " pour faire du 16/9. Je rappelle que dans le monde broadcast, la résolution reste identique quelque soit le ratio : en PAL, du 768x576, ça sert aussi bien pour le format 4/3 que pour le format 16/9. On ne passe pas à la réso "1024x576" pour faire du 16/9 en PAL. On compte sur la faculté du CRT pour déformer l'image, de façon à retrouver les bonnes proportions (on parle d'anamorphose).

Il est plus difficile de "balayer plus large". Donc, le tube 16/9, il est en réalité comme un tube 4/3 de la largeur du tube 16/9. Pour changer ce fait, il aura fallu attendre l'augmentation de l'angle de déviation des yokes, pour les derniers tubes (vers les 130°, quand avant on restait vers 110°).

En revanche j'ai peut-être pigé l'utilité des ratios "à la con" que l'on trouve par exemple dans les options de VLC.

ils sont prévus en fonction de la déformation imposée pour certains contenus.

Et celui que je devrais choisir pour ma TV s'il était dispo c'est le 1:1 (que je force artificiellement en trifouillant le service mode en fin de compte).

En faisant du 1:1 avec VLC, il s'agit de déterminer que l'image est un carré en réalité. C'est réduire la taille horizontale à celle verticale.
Certaines TV 16/9 font ça en mode 4/3 : l'image est rétrécie non pas en terme de balayage, c'est la résolution qui est réduite (avec bordures noires donc). La hauteur d'image reste identique, le balayage reste identique (toute la longueur), mais le contenu est amputé. Ce sont souvent les TV de bonne gamme, qui font du PIP (picture in picture). Mais c'est un post-traitement : dégradation de l'image, et ajout de lag'.

De vrais arnaqueurs illusionnistes ces fabricants de TV …

Un gros tube 4/3 aussi large qu'un tube 16/9, ça commence à sérieusement peser, c'est une augmentation de coût substantielle à tous les niveaux (fabrication, transport, stockage). Sûr que rien ne vaut un bon tube Trinitron 4/3 de 40" (qui fait en mode 16/9 quasi l'équivalent d'un tube 16/9 32").

D'ailleurs, du point de vu du châssis de la TV, ce ne serait pas vraiment le 4/3 qui n'est pas géré, mais bien le 16/9 qui serait bridé, non ?

Le chassis ne fait que du 4/3. Il est censé bossé sur un tube 4/3. Quand il fait du 16/9, c'est toujours du 4/3, mais écrasé verticalement. Il se trouve que l'image alors visible dans ces conditions correspond pile poil à la surface de la dalle du tube.
Ca en devient le mode standard.

Maintenant je ne m'explique pas la différence dans la gestion des ratios entre le RGB et le composite.
En composite, "l'illusion" finale du 4/3 existe mais pas en RGB … faut-il considérer qu'en composite la gestion des formats se ferait de manière "software", alors qu'en RGB elle se ferait en "hard", d'où la limite imposée ?

Je teste jamais mon matos en composite (et y a pas des masses de tubes 16/9 qui me sont passés entre les mains par rapport à du 4/3), alors j'ai pas souvenance d'avoir rencontrer ce cas... Sachant que en fin de chaîne, un tube bosse toujours en RGB, je vois pas l'utilité de contraindre le balayage suivant la nature de la connectique... Mais bon, il est vrai que le signal RGB est souvent routé hors des différentes puces chargées de traitements (ex: le sharpness, qui n'existe naturellement pas pour le RGB), il est possible que certains réglages du service mode soient eux aussi limités.

Bonne année !

La santé, l'arcade, et du bon tube cathodique, bien sûr !

Oui, mais un scanner à plat, alors. Et suivant la borne, ça doit pas toujours être évident de maintenir le scanner contre le side.

Pas mal, sauf que les rythm games ça fait pas du tout partie de l'héritage 16-Bit.
Pour peu, on pourrait parler d'anachronisme.

Pour moi, le problème des bartops, c'est l'écran LCD (beurk ! ), et le panel incliné, qui plus est surélevé.

Ca fait de jolis objets (quand l'écran est éteint ! ), mais à l'utilisation...