Différence entre un PCB/MVS etc.. orginal et émulation

[Processor]

Salut à tous,

Je me demande quelle est la différence, si il y en a entre un système original et un système émulé.
La seule que je connaisse c'est que certaines limitations hardware de l'époque créaient des ralentissements qui n’existent
pas dans l'émulation.

Est-ce tout? peut-on simuler les performances hardware de l'époque?

[Jimmo]

Mame par exemple affiche même les ralentissements hardware

[Processor]

On peut donc considérer que l'émulation est parfaite?

[dapsaille]

C'est le but du projet Mame, à l'inverse des projets type Zinc et Viva Nonno par exemple.

[f4brice]

Mame essaie d'émuler l'électronique du PCB, et non pas le logiciel.
Le logiciel "réel" du jeu est exécuté sur l'électronique émulée.

Et il y a certaines situations qui posent(posaient) problème à Mame :

• Utilisation de logique discrète (pas de solution à ce jour, donc jeux non émulés ; exemples : Shark Jaws, Wheels, Missile X, etc...)
• Utilisation de circuits analogiques, principalement dans l'audio (soit pas de solution, soit utilisation de sons numérisés) ; autre exemple : Wheels (Midway, 1975) qui utilise une charge R-C comme timer de jeu
• Présence de composants complexes non documentés (nécessite reverse-engineering plus ou moins violent : Bubble Bobble, GTI Club, systèmes SEGA et CAPCOM, ...)

Sa principale lacune est la partie video, où Mame ne peut pas demander à la carte graphique du PC le mode video exact généré par le PCB.
Très souvent (sytématiquement ?), le jeu est synchronisé à 100% avec l'affichage vidéo.
Dans une "vraie" borne, le moniteur est "esclave" des fréquences vidéos imposées par le PCB (dans une certaine limite, bien sûr, d'où les réglages "HSYNC" et "VSYNC").
Avec Mame, la carte graphique va switcher (selon les préférences) vers un mode vidéo "au plus près" du mode requis par le jeu, mais elle reste 100% indépendante, d'où la présence de problèmes (que Mame subit).
Mame reste quand même un logiciel purement extraordinaire, que j'admire ! 
Le dump de ROMs et l'émulation de l'électronique ont déjà sauvé nombre de mes PCB.

[isKa]

Sa principale lacune est la partie video, où Mame ne peut pas demander à la carte graphique du PC le mode video exact généré par le PCB.
Très souvent (sytématiquement ?), le jeu est synchronisé à 100% avec l'affichage vidéo.
Dans une "vraie" borne, le moniteur est "esclave" des fréquences vidéos imposées par le PCB (dans une certaine limite, bien sûr, d'où les réglages "HSYNC" et "VSYNC").
Avec Mame, la carte graphique va switcher (selon les préférences) vers un mode vidéo "au plus près" du mode requis par le jeu, mais elle reste 100% indépendante, d'où la présence de problèmes (que Mame subit).

Pour Mame, je suis d'accord avec cette lacune, mais fort heureusement, un soft comme switchrez résout ce problème

enfin ça dépend sur quoi on l'affiche certes

Mais le moniteur est contraint d'accepter ce que la CG balance tout comme MAME, frequence et mode video exacte recalculé à la volée, et les potards sont de mises, enfin par le Hsync, on contourne le soucis, mais le Vsynch est obligatoire (et tant mieux ^^).

[Processor]

Sa principale lacune est la partie video, où Mame ne peut pas demander à la carte graphique du PC le mode video exact généré par le PCB.
Très souvent (sytématiquement ?), le jeu est synchronisé à 100% avec l'affichage vidéo.
Dans une "vraie" borne, le moniteur est "esclave" des fréquences vidéos imposées par le PCB (dans une certaine limite, bien sûr, d'où les réglages "HSYNC" et "VSYNC").
Avec Mame, la carte graphique va switcher (selon les préférences) vers un mode vidéo "au plus près" du mode requis par le jeu, mais elle reste 100% indépendante, d'où la présence de problèmes (que Mame subit).
Mame reste quand même un logiciel purement extraordinaire, que j'admire ! 
Le dump de ROMs et l'émulation de l'électronique ont déjà sauvé nombre de mes PCB.

Mais avec avec le soft15khz de sailorsat et quickres est-ce que justement on ne règle pas ce genre de soucis?

[isKa]

si justement, mais switchrez est bien plus confortable en utilisation tout comme groovymame qui t'évite le calcul manuel des modelines

5 min et tu obtiens la solution a cette lacune, te faut des heures et des heures pour soft 15 khz (titanesque!)

[f4brice]

De ce que j'ai compris, soft15kHz, switchres et autres outils permettent de faire sortir à la carte graphique une sortie vidéo proche de celle requise (résolution et fréquence), mais pas exacte.

Ainsi, par exemple le mode vidéo "320 x 250 @ 55 Hz" sera utilisé/choisi pour du "320 x 240 @ 54,8 Hz", et aussi pour du "320 x 200 @ 51,2 Hz", etc...
Or le jeu est prévu pour une fréquence de raffraichissement de 51,2 Hz (mon 2e exemple) et l'image est réellement affichée plus vite.

Donc dans ce cas, en gros, le jeu prévoit qu'il faut 19,53125 ms pour afficher l'image, or la carte graphique la fait afficher au moniteur en 18,1819 ms.

Mais si Mame sait communiquer d'une manière ou l'autre les fréquences exactes requises (il me semble que ce n'est pas le cas), alors ce problème n'apparait pas.

[isKa]

Non c'est pas tout a fait cela,

Mame offre une base de donnée qui regroupe les fréquences/ modelines (ini), soft 15khz est un logiciel qui les crée et ensuite faut que Mame les utilises (mal d'ailleurs..).

groovymame va extraire les modelines enlever les doublons de fréquences (car ils seront recalculés à la volée) ou mieux, créer a la volé carrement la résolution (en fonction de la résolution vertical : 1234X224 @ XXhz, 1234*256 etc etc...).

donc ton exemple de 320 x 240 @ 54,8 Hz sera cette option imposé à Mame, de même, un 320 x 250 @ 55 Hz le sera également.

La seul restriction est l'utilisation des données du moniteur, si on veut retrouver un aspect fidèlement emulé.

En gros, Mame offre la possibilité de choisir, mais il est plus réel de lui imposer en effet comme le fait groovymame par exemple

[Processor]

Très intéressant.

si on a une double sortie sur la carte graphique, on peut choisir, 15khz sur la première et 31khz sur la seconde?

[isKa]

avec soft 15 khz OUI, et c'est interessant !

Avec groovymame, NON, enfin, j'ai pas de cable VGA sous la main que mon HDMI et DVI lol

j'ai d'ailleurs ce soucis sur mon installation principal, j'ai un dual boot, le premier media center sous seven, et le second sous Xp64, et mon soucis est que le HDMI prend le pas sur le DVI (utilisé par groovymame), si on débranche le cable pas de soucis ! mais c'est un peu lourd !

je recherche une solution dans la base de registre pour desactiver le hdmi, sans succès pour le moment.

Soft 15 khz te permet de sélectionner la sortie utilisé, ce qui est bien sympa, d'ailleurs je vais regarder de ce coté car de toute façon, c'est deux softs intègre ces résolutions de manière identique (comme winmodeline également) avec un avantage certain pour groovymame et ces résolutions magiques 1234.

[Processor]

Petite question

http://www.ultimarc.com/jpac.html

If required, can divide a 31Khz VGA signal in half so that it will display a stable picture on a 15Khz arcade monitor. Useful for checking boot-up progress and configuration (not for application use). Automatically stops dividing the signal when it detects a correct 15Khz rate is being send by the PC.

ça signifie que lorsque le jpac détecte que le signal envoyé est en 31khz il le divise en 15khz? et lorsque il a le bon signal en 15khz, il le re-laisse passer normalement?

quelqu'un à déjà tester?

[isKa]

oué c'est cela, c'est surtout pour check un boot systeme(mais bon écran divisé en 2 et souvent desynchro)et protéger un écran natif 15 khz.

et puis c'est bien pratique pour le cablage, rapide et efficace !

(en prime, le rajout d'une CG en pci avec boot dessus peut masquer un affichage disgracieux)

[gc339]

ça signifie que lorsque le jpac détecte que le signal envoyé est en 31khz il le divise en 15khz? et lorsque il a le bon signal en 15khz, il le re-laisse passer normalement?

Le signal vidéo à 31 kHz n'est pas divisé en 15 kHz a proprement parler. Le jpac oblitère tout simplement une impulsion de synchronisation ligne sur deux. Le signal de synchronisation résultant se retrouve cadencé à 15 kHz alors que le signal vidéo RVB reste inchangé, c'est pour cela que l'on perçoit deux images juxtaposées dans le sens horizontal sur l'écran.
Ces deux images juxtaposées sont souvent déformées car le jpac ne modifie en rien la largeur des impulsions de synchronisation issues du 31 KHz. Ces dernières sont plus fines que celles d'un signal de synchronisation standard à 15 kHz et la plupart des moniteurs ont alors du mal à se synchroniser sur cet ersatz de signal à 15 kHz.

[isKa]

J'avais cru lire que c’était en fonction de la carte graphique que la synchro se faisait plus ou moins bien ? selon le modèle etc etc mais peu importe, la précision est importante et instructive!