sr17 a écrit :



Pas si simple.



Le résultat, c’est qu’un processeur à 1Ghz suffit tout juste à émuler certains matériels qui tournaient à seulement 8Mhz. Par exemple, l’Amiga est une machine complexe à émuler.







Ben en fait si, c’est simple, quand c’est bien documenté.



Le plus difficile est souvent d’avoir accès à de l’information non documentée et d’émuler des bugs matériel. C’est d’ailleurs pour cette raison que l’amstrad CPC+ n’est toujours pas émulé correctement, alors que le C64 et ses copros, la megadrive ou même la super NES passe sans souci. Tout comme l’Amiga 500 d’ailleurs! Il a peut-être plen de copro mais tout est documenté et il n’y a jamais eu sur cette machine de code tricky, pour une simple raison -> Le hard était prévu pour.



Par contre, pour l’Atari pour lequel l’overscan n’est pas prévu dans les docs a exploité des tas de trucs tordus qui sont plus coûteux à émuler, et il a fallu attendre un peu que des codeurs Atari (Léonard par exemple) se penchent sur la question.



Bref, c’est faux, on émule très bien ce genre de machine avec des CPU à quelques centaines de MHz et on se cogne complètement qu’il y ait plusieurs puces qui tournent en simultané ou pas, vu que c’est é-mu-lé. On fait ce qu’on veut au cycle près.

ben51 a écrit :



Et l’émulation de l’écran cathodique ?







Y a plusieurs émulateurs qui proposent de belles imitations via des shaders

(effet bombé, effet matricielle rvb, pseudos-reflets, bavures, …)



Et techniquement, certains émulateurs sont obligés d’émuler l’écran, pour obtenir des dé-synchros, mettre plusieurs HBL par ligne (technique dite de rupture)

ben51 a écrit :



Oui justement quand je parle d’émulation cathodique c’est pas les filtre à l’instagram.

Mais bien de faire un rendue qui prend en conte la spécificité de ces écrans et leur utilisation (pixel rectangulaire, diffusion de la couleur entre pixel, rémanence de l’écran)







Ce dont tu parles est aussi du cosmétique " />



Mais oui, certains émulateurs simulent les retards de signaux, pour faire par exemple des effets de vague hard avec l’écran, ou même carrément des décrochages de VBL.

MickeyFreeStyler a écrit :



Avec l’émulation, tu ne peux pas comparer avec le puissance brute de chaque appareil.







Ce n’est pas une émulation, c’est une adaptation.



Et quand bien même. Émuler, ça ne bouffe pas un facteur 100, même en java.

sr17 a écrit :



Le fait que cela soit documenté n’empêche en rien que cela demande un énorme travail parce qu’il y a énormément de petits détails à gérer.







Je n’ai jamais dit le contraire. Je dis que c’est simple à faire, pas que ça ne demande pas de travail, saisis-tu la différence?





Non, ce n’est pas simple. Un bon émulateur, c’est beaucoup de travail, ça ne s’écrit pas en quelques jours. Pour certains émulateurs, les gars y bossent depuis des années. Rien qu’a lire les changelogs de certains émulateurs, on est impressionné par la quantité de travail qu’ils font à chaque version.





Si, si, c’est simple, on est là encore, sur un manque de documentation. Et souvent, ces modifications sont proposées par d’anciens programmeurs qui connaissent tous les petits trucs (Les évolutions de Winape, par exemple, sont le fait de demomaker, même si c’est Wilson qui se paluche le code au final)







Alors primo, je parlais de quelque chose de complètement différent : les ressources nécessaires pour l’émulation d’une machine ancienne et du fait que ce n’est pas parce que le proco mouline à seulement 8 mhz que c’est forcément hyper-léger à émuler pour un smartphone.





Tu n’as toujours pas l’once d’un début d’explication à ton argumentation. Et pour cause, les faits sont contre toi. Les émulateurs tournent du feu de dieu…







Pour le problème du CPC, les quelques tricks utilisés demandent évidement du reverse engineering et plus de resources pour une émulation plus détaillée.

Mais rien de vraiment plus complexe que sur d’autres bécannes. Il suffit de voir la complexité du hardware d’un 800XL et des tricks utilisés par les programmeurs… et pourtant cette machine est parfaitement émulée.





Le problème du CPC+, c’est surtout que son Asic est buggué jusqu’à l’os…





De plus, le CPC partait de circuits parfaitement standards et relativement bien documentés. Et les tricks utilisés étaient connus des programmeurs.





Non, il y a plus de 4 chipsets graphiques sur le CPC qui ont chacun des comportements différents ET utilisés par les développeurs de jeux vidéos, en particulier sur la fin de vie de la machine.





Je pense que le vrai problème du CPC, c’est que ce n’est jamais devenu une machine culte comme l’Amiga. Et donc personne n’est prêt à y investir autant de temps que pour d’autres machines.





Encore une fois, tu racontes n’importe quoi. Le problème du CPC, c’est sa complexité cachée et le manque de documentation. D’ailleurs, y a un super émulateur bien propre (ACE) qui tourne sur Amiga et qui a été programmé par une des plus grosses tronches sur CPC (Offset). Son développement a été très court.



Pourquoi? Parce qu’il connait la machine sur le bout des doigts.



Une preuve de plus que:

• c’est simple
  


• il faut être documenté
  
  
  
  Conclusion: t’as la doc, ça va vite, t’as pas de doc, c’est bugué et ça prend du temps.
  
  
  
  
  
  L’émulation n’est pas une baguette magique qui peut faire disparaitre par magie le coût de traitements parallèles. Si tu regarde un jour le code d’un émulateur, tu comprendra qu’il y a juste des bonnes optimisations qui permettent de ne pas tout simuler ou de ne simuler que ce qui est utilisé. Mais ce n’est pas toujours possible quand un circuit génére un état qui évolue de manière complexe au cours du temps et qu’il y a de nombreuses interdépendances entre les circuits.
  
  
  
  
  
  Tu as raison, ce qui fait disparaitre par magie le coût des traitement, c’est la puissance du CPU. Et ça tombe bien, les CPU modernes sont beaucoup plus puissants que les oldies qu’on émule. Elle est pas belle la vie?
  
  
  
  
  
  En conclusion, je t’engage à relire ce que j’ai écrit, a comprendre ce que j’ai dit et ce que je n’ai pas dit. Faire cela avant de contredire fait gagner du temps à tout le monde.
  
  
  
  
  
  Toi aussi hein, cf les premières lignes " />
  
  
  
  
  
  
  
  ps: Ah oui, devine quoi, c’est moi qui vait faire le portage d’ACE sur les autres plateformes " />
  
  
  

sr17 a écrit :



Pour le problème du CPC, les quelques tricks utilisés demandent évidement du reverse engineering et plus de resources pour une émulation plus détaillée.







Je voulais rebondir aussi sur cette idée reçue qu’il faille plus de resources pour une émulation plus détaillée.



Beaucoup d’émulateurs ont été écrit par des informaticiens qui n’ont pas de notions en électronique. Résultat, le comportement de la machine est mimé, imparfait, et surtout fondé sur des bases mauvaises. Du coup, pour améliorer l’émulation, on patch, on ajoute des rustines (super bien optimisées hein, en assembleur et tout) mais ça reste lourd et lent.



Alors que d’autres émulateurs sont écrits en C pur, mais par des gens qui connaissent le fonctionnement interne et électronique des puces. Et au final, on se retrouve avec des programmes moins optimisés certes, mais aux algorithmes bien plus simples et justes. L’émulation est pourtant meilleure et utilise moins de resources. Mais cela demande une connaissance approfondie de la machine. On a de beaux exemples dans les émulateurs C64.

sr17 a écrit :



Les ordinateurs étaient documentés pour que les programmeurs puissent écrire des programmes. Aucun ne l’a jamais été au niveau nécessaire pour écrire des émulateurs. Cela suppose que toute personne devant écrire un émulateur devra faire pas mal de reverse engineering.







Les documentations ont toujours été sommaires parce que les programmeurs n’étaient pas censés sortir des clous. Mais en fait, pour reprendre le cas du CPC que je connais bien, les docs existaient ailleurs, chez les fabricants tiers (puce audio, floppy, …) et se baser sur ces docs plutôt que du reverse, c’est ce qui fait qu’ACE est plus fidèle que les autres émulateurs, avec moins de resources. Dont actes ;)



Bref, faire du reverse, c’est bon à faire un émulateur usine à gaz, jusqu’au prochain bout de code tricky qui fera planter l’émulateur parce qu’on sortira une nouvelle fois des clous, au lieu d’émuler la puce correctement.

sr17 a écrit :



Non, faire du reverse, ça sers surtout à comprendre comment un circuit fonctionne et comment il se comporte dans les situations non documentées.







Au temps pour moi, j’avais compris autre chose " />