Powermax:



J'arrive un peu trop tard, mais l'info servira pour d'autres personnes au sujet des rétro-projecteurs CRT :

Ils sont tous équipés de tubes 7" (à focus électro-statique) , et la taille de l'image dépend du miroir et des optiques !!! 

En clair, des modèles 41, 43 ou 46" d'un même fabricant embarquent le même matos. On peut transformer un rétro 46" en 41", ou vice versa. La taille du caisson du haut (qui comporte le miroir et l'écran) change, mais les tubes sont identiques dans le caisson du bas. Les optiques elles aussi sont identiques, c'est un déplacement de la lentille supérieure qui permet de caler l'image selon les dimensions voulues.

Après, au dessus de 46", les optiques changent (pour correspondre à nouveau à plusieurs tailles), mais il est possible de les adapter, car tous les rétro utilisent des tubes 7" (les vidéo-projecteurs CRT eux peuvent utiliser des 8 et 9").

Bref, pour celui qui récupère un Megalo HS, il faut conserver le miroir, l'écran (lentille de Fresnel), ainsi que les optiques. Ensuite, il est question de récupérer un rétro grand public, et de ne conserver que la partie qui embarque les tubes (support métallique + chassis, tout ce qui se trouve dans le caisson du bas).
Après, faut revoir l'orientation du miroir dans le Megalo, parce que les tubes ne seront pas forcément à la même inclinaison et même distance, et aussi voir comment adapter les blocs optiques du Megalo sur les autres tubes (car il y a peu de chances que les optiques du nouveau rétro permettent une image assez grande et nette si on part de modèles de taille 41 à 46").

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

L'image semble tout à fait normale. Pour bien en être sûr, affiche une mire, comme celle ci par exemple:



Les tons sombres et les tons lumineux doivent tous apparaitre au niveau des emplacements délimités par des points.


Sinon, au niveau des chassis arcade, oui la norme du signal est plus élevée que celle prévue à domicile et pour le monde PC. Donc, quand on envoie un signal à 1V sur un écran qui exige en général entre 2.5 et 5V, on se retrouve avec une image sombre. Mais ton chassis, puisqu'il indique clairement des niveaux entre 1.5 et 4V, peut se débrouiller avec un signal à 1V. Il faut au besoin augmenter un peu le réglage contraste sur l'écran (qui agit sur l'amplification du signal justement, mais avec des limites).

T'as besoin d'acheter un ampli vidéo si sur ton écran arcade t'as une image trop faiblarde même avec le contraste au maximum.

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.

Plutôt que de citer de jeux, il serait intéressant et surtout utile de lister les drivers MAME qui supportent ces jeux. Certains comportent de nombreux titres, d'autre une poignée, ou même un seul.

Je dis ça parce que je bosse depuis quelque temps sur la question de l'affichage par MAME, et donc la question des paramètres vidéo de ces dits drivers, histoire d'assurer un rendu 15 kHz fidèle (là ça va, c'est pas dur), mais surtout avec une synchro parfaite, sans lag (exit le triple buffering).

De nombreux drivers ne sont pas ou mal renseignés sur les paramètres vidéo, du coup ça coince au niveau des modelines. Si du point de vue statique on peut afficher un rendu pixel perfect sans problème malgré ça, il en va autrement dès qu'il est question de considérer le mouvement. Je détaillerais pas plus, j'ai déjà pas mal développé ça sur Neo-Arcadia (ici), juste qu'il est question à un moment donné d'être limité en nombre de modelines à gérer par les pilotes de carte graphique ou les front-ends. On parle de 60 à 200 modelines maxi. Pour contourner cette limite, il faut passer par des astuces de génération à la volée (cf GroovyMame), mais qui ne sont pas infaillibles, d'autant plus lorsque le taux de rafraîchissement est une simple mesure faite sur la PCB, avec peu de chiffres significatifs.

La question rejoint aussi la compilation d'un build plus léger, qui ne comporte que le meilleur.
Alors plutôt que de citer des jeux Neo Geo, on listera simplement le driver: neogeo.c
Pareil pour les jeux Capcom : cps1.c, cps2.c, cps3.c etc.
Pour Ghouls n' Ghost : gng.c (-> supporte deux jeux seulement). Pour Toki: toki.c (un seul jeu !)

Donc, plutôt que de citer des centaines de titres, arriver à dresser une liste des 200 drivers incontournables de MAME, qu'ils rassemblent plusieurs jeux, ou ne traitent qu'un seul titre. Même si le driver comporte 10 bouses et une seule perle, le citer quand même.

C'est pas interdit de citer quelques jeux par driver pour situer le truc :

- simpl156.c ( Osman, Charlie Ninja...)
- seta2.c    ( Denjin Makai 2...)
- psikyosh.c ( Tetris GM 2, Dakaru Tenshi...)
- etc.

Nombre de ces drivers ne sont pas bien renseignés sur l'affichage, aussi il faut les mettre à jour, ce qui n'est pas vraiment une priorité absolu pour les devs quand on voit que certains n'ont pas bouger là dessus depuis 10 ans. Même depuis la dernière refonte du rendu vidéo de MAME, ils ont conservé des paramètres approximatifs. Et à vrai dire, tout le monde s'en fout, puisque la majorité des gens jouent sur LCD, peu font l'effort de sortir un signal à 15 kHz.

Donc voilà, piochez dans votre liste de jeux favoris (et commencez par les jeux un peu moins connus, si possible), et indiquez le driver qui le supporte. Après, c'est Bibi, expert en scanlines et guru du tube cathodique , qui se charge d'assurer l'écriture des paramètres vidéo dans ces drivers, au plus proche de ce qu'il est possible de gérer par des modelines fiables, et en accord avec le hardware des jeux.
Et après, y a juste le Build Ultime qui en sort.


Merci de votre coopération.

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

Toutes les TV émettent un sifflement, qui correspond à la fréquence de ligne : 15 kHz. On est dans le spectre audible, sauf à s'être ruiné les oreilles en discothèque/concert de rock/écoute de baladeur à niveau trop fort etc.

Maintenant, le sifflement peut s'aggraver avec l'usure du THT, à cause de la chaleur. Tu peux toujours refaire les soudures, ça coûte rien, mais à mon avis il est nécessaire de changer la pièce. Ca ne supprimera pas le sifflement, mais l'atténuera à un niveau normal (celui de la pièce en neuve).

Pour un Trinitron, ça vaut amplement le coup. Ce sont les meilleurs tubes cathodiques, et en plus c'est une opération qui concerne la pièce qui tend à claquer en 1er sur le chassis des CRT. Donc, le changer maintenant, c'est éviter de changer le BU et autres composants associés.

Maintenant, si ta copine râle toujours, c'est une façon indirecte pour dire :
" jette moi ce gros cube pourri à la poubelle et achète un superbe écran plat, top design qui se mariera à merveille dans la déco du salon "

Citation de: Hervéni le Vendredi 18 Janvier 2013, 23:40:32 PM
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°).

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

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

CitationDe 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").

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

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

Un tube 16/9 est en réalité un gros tube 4/3, mais pour lequel on a été radin pour la hauteur. Il n'est pas question que le yoke ait une déviation plus importante (> qu'un tube 4/3 de la même hauteur d'affichage), il s'agit de celui qui serait prévu si le tube faisait la largeur constatée en 16/9, et la hauteur 4/3 équivalente.

Donc, la diffusion "normale" sur ce tube correspond en fait au 16/9 d'un tube 4/3 (image écrasée donc), et quand tu passes en mode "zoom", il s'agit de ce qui correspondrait au simple ratio 4/3. L'image est tronquée, parce que le tube est lui même physiquement tronqué.

Pour avoir un vrai 4/3 là dessus, il faut encore plus "comprimer" l'image qu'il n'est possible de le faire. Un peu comme si tu voulais diffuser une petite image 4/3 au milieu d'un tube 4/3 (avec de grosse bordures noires, donc).

Y a pas de solutions miracles. Plus l'agrandissement ou la réduction de la taille d'image sont importante, plus l'image se déforme.

Si tu mettais un yoke de tube 4/3 prévu pour un tube de hauteur équivalente, t'aurais un bon ratio 4/3, mais du coup tu te retrouverai avec le problème inverse: impossible d'étirer l'image plus que de mesure (pour atteindre la largeur totale du tube), et problèmes de géométrie.

Bref, c'est pas la joie, c'est pas tous les tubes 16/9 qui ont l'électronique pour gérer les deux ratio correctement.

Bonne année !

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

Il s'agit d'un tri-tube. Un tube pour chaque couleur primaire: rouge, vert, bleu.

Ce sont des tubes à haute intensité, le phosphore est de fait encore plus sensible au bombardement d'électron sur des motifs fixes (Insert Coin, logos etc).
Le marquage n'épargne aucun des trois tubes. L'usure normale des tubes (perte de luminosité) varie individuellement en fonction de la source, du contenu affiché, il n'est pas nécessaire de les changer les trois à la fois.

Pour les changer, il faut repérer la référence, et trouver un modèle de rétroprojecteur qui embarque les mêmes tubes (c'est du 7" dans la très grande majorité pour les rétros, que ce soit en arcade ou pour le marché domestique). Sinon, adapter le pin-out des neck-boards (les ampli vidéo), car c'est souvent ce qui empêche l'échange de tubes.

Un entretien basique est toujours bon: nettoyer la poussière accumulée sur le miroir et sur les optiques.

Le liquide de couplage optique/refroidissement des tubes peut se troubler au fil du temps, et réduire la luminosité et le focus de l'image.
Ca se change, c'est un mélange de propylène glycol et de glycérine (changer les joints aussi!).

Bref, un tri-tube, c'est pas évident à entretenir et à discerner l'usure sans démonter un peu, mais une fois bien réglé, c'est super.

Ca m'arrive d'en récupérer sur le trottoir, pour panne de circuit de convergence (classique), ou simplement parce qu'ils sont sales ! (poussière accumulée depuis des années sur le miroir et les optiques).

D'occasion, ça vaut que dalle de nos jours, mais faut gérer le transport.

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

Citation de: Thieum le Vendredi 22 Juin 2012, 00:19:49 AM
Dans ce cas que penser de D-pad hero?

C'est un anachronisme.

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.

Il vaut mieux opter pour une solution type "banc de reproduction" qu'un scan à défilement manuel, qui dans tous les cas ne permettra pas de saisir l'intégralité du side-art en une fois.

L'idée, c'est d'entourer le side de repères millimétrés, et de prendre des photos selon un axe le plus perpendiculaire possible, en faisant varier la hauteur de l'appareil sur un système à glissière. De cette façon, l'erreur est minimisée, la distance la plus constante possible, et la correction se fait en redressant chaque portion avec un bon logiciel, en s'aidant des marges millimétrées.
Bref, c'est quand même un sacré boulot, et pour bosser en résolution suffisante une fois l'assemblage final effectué, faut un PC qui turbine bien.

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