Re: Megadrive et Super Nintendo : parlons technique !

[TotOOntHeMooN]

Et puis quitte à avoir un prix par volume avec de la 100ns, tu pouves faire la même chose avec n'importe quelle autre RAM .

Je ne m'avancerai pas sur ce point. Les marchés des composants électroniques sont bien plus complexe que cela.

Sinon, la rétro-compatibilité SMS a clairement plombé la capacités de la MD... 
Alors que l'adaptateur cartouche pouvait contenir ne serait-ce le VDP de la SMS. Mais on ne refera pas l'histoire. 
(oui, avec un switch de bus en fonction de l'usage pour avoir le Z80 et sa RAM sur le port cartouche)

[Invité]

La PS2 n'était pas plus facile qu'un autre parce qu'il y avait le CDROM

Mais il est fort probable que le choix du processeur de la PS2  , un dérivé du MIPS n'a pas était au hasard (certes un CPU custom mais qui se base sur l'architecture MIPS comme la PS1).
Pour la PS3 ,  l’architecture MIPS était un peu vieillissant , Sony a préfère passer sur un autre type de CPU et donc perdre la rétrocompatibilité :p

Bref la rétrocompatibilité se fait j'ai l'impression que si les contraintes ne sont pas trop problématique et leur choix laisse aussi une trace sur la prochaine génération de console du coup

Sinon, la rétro-compatibilité SMS a clairement plombé la capacités de la MD...

Ben comme la SNES j'ai envie de dire sauf que la rétrocompatibilité n'a pas était faite au final , mais son architecture un peu zarb sont justement les traces de cette volonté d’être compatible avec la Nes :p

A l'identique pas sur , mais ce que veux dire Touko , c'est que le principal (le cpu et les I/O peuvent être refait) et il est vrai que tout les émulateurs ont un souci de timing :/

[TotOOntHeMooN]

Ben comme la SNES j'ai envie de dire sauf que la rétrocompatibilité n'a pas était faite au final , mais son architecture un peu zarb sont justement les traces de cette volonté d’être compatible avec la Nes :p

Je n'ai pas d'infos concernant les limitations de la SNES liées à cela, je ne saurai donc dire. (sur MD, on a tronqué le VDP niveau bande passante et couleurs affichables)

[airdream]

Est-il possible aujourd'hui de reproduire à l'identique le hard de la Super Nintendo et la Mega Drive ?

Le FGPA?

MD: https://www.analogue.co/mega-sg/

SNES : https://www.analogue.co/super-nt/

Ou encore la TECTOY MegaDrive : https://www.tectoy.com.br/pre-venda-mega-drive-edicao-limitada/p/995040461825

[upsilandre]

La PS2 n'était pas plus facile qu'un autre parce qu'il y avait le CDROM

Mais il est fort probable que le choix du processeur de la PS2  , un dérivé du MIPS n'a pas était au hasard (certes un CPU custom mais qui se base sur l'architecture MIPS comme la PS1).

Le choix d'un core Mips pour le CPU de la PS2 n'a a priori pas de lien avec la rétrocompatibilité puisque la PS1 est émulé par le chip I/O qui intégrait le CPU de la PS1 (et que Naughty Dog utilisait aussi dans leur moteur 3D PS2).

[Metalik]

Est-il possible aujourd'hui de reproduire à l'identique le hard de la Super Nintendo et la Mega Drive ?

Le FGPA?

MD: https://www.analogue.co/mega-sg/

SNES : https://www.analogue.co/super-nt/

Ou encore la TECTOY MegaDrive : https://www.tectoy.com.br/pre-venda-mega-drive-edicao-limitada/p/995040461825

Non pas Tectoy. C'est de l'émulation...

Sinon pour répondre à la question de Shingo. Oui il est possible de reproduire le hard de la SNES et de la Megadrive grâce à la technologie FGPA.

Cependant ça reste à réserve dans le sens ou ça reste très loin des technologie d'origine et qu'il faut que la copie soi bien conçu, et qu'elle dispose d'un suivie en cas de problème. C'est l'atout du FGPA; c'est des puces programmable, au moindre bug, à la moindre incompatibilité il y a moyen de rectifier.

Sinon, d'un point de vue technique, c'est vraiment 100% fiable et faisable, mais il faut que ce soi bien fait. Et mine de rien, ce n'est pas aussi évident; puisqu'il faut vraiment reproduire tout un système, avec son BIOS, ses bugs éventuel, et ses bizarrerie diverses. Il faut reproduire tout un système et son comportement, et ça va bien au delà de la simple question de la superposition de puces, il faut reproduire un comportement, une osmose.

D'ailleurs du côté de de SEGA, si je raconte pas de conneries, c'est d'autant plus vrai puisque en 2005 ils ont carrément délivré toutes les spécificités technique de la Megadrive et de son BIOS. Ce qui à permis d'amélioré grandement le phénomène d'émulation en un rien de temps (même si il est vrai que c'était déjà pas mal auparavant). Mais dès que SEGA à lâcher les ressources le bon à été spectaculaire en matière d'émulation.    

Par exemple, et sans précision de ma part, je sait que par exemple sur Megadrive certains développeurs ont obtenu des effets inattendu et bizarre en alignant des lignes de codes, et qu'ils ont même été parfois inclus dans des jeux. C'était un peu comme des "surprises du hardware" que proposait la console (de manière général, une machine programmable, propose de toute façon toujours quelques surprises et des possibilités qui n'étaient pas prévue de base par les concepteurs; il y a toujours quelqu'un pour surprendre et trouver un "truque").

Maintenant, est ce que un FGPA copiant le hardware Megadrive pourrait produire ce genre de surprise ?...
Normalement, en principe, oui si le FGPA est une copie parfaite du système original, mais ce n'est pas prouvé non plus et il faudrait des codeurs de qualité professionnel et si possible de l'époque s'y mettent pour répondre à la question. 

Le mieux dans la conception d'une nouvelle SNES-Megadrive resterait d'utilisé au maximum les composants d'origine encore disponible en série, et voir d'en recycler d'autres, mais malheureusement, sur ce genre de machines il ne reste plus grand chose. Surtout dans le cas SNES où la quasi totalité des puces de la console ont été conçu et produite uniquement pour la console.

[Invité]

La PS2 n'était pas plus facile qu'un autre parce qu'il y avait le CDROM

Mais il est fort probable que le choix du processeur de la PS2  , un dérivé du MIPS n'a pas était au hasard (certes un CPU custom mais qui se base sur l'architecture MIPS comme la PS1).

Le choix d'un core Mips pour le CPU de la PS2 n'a a priori pas de lien avec la rétrocompatibilité puisque la PS1 est émulé par le chip I/O qui intégrait le CPU de la PS1 (et que Naughty Dog utilisait aussi dans leur moteur 3D PS2).

Tu es sur ??
Je me souviens pas que la PS2 ait incorporé quoi que ce soit de la  PS1, il me semble que c'est plutôt sur les première PS3 jap que le hard de la PS1 avait été intégré.

[Invité]

la PS1 est émulé par le chip I/O qui intégrait le CPU de la PS1 (et que Naughty Dog utilisait aussi dans leur moteur 3D PS2).

J'en suis étonnée parce que le proc de la PS1 est une vrai tortue obsolète comparé à la PS2, je vois pas vraiment l’intérêt de gaspiller du temps a faire de la 3D avec (parce qu'il ne permet pas de faire des matrice 4x4) et que tu peux espérer au mieux avoir que 3000-4000 triangle avec ! (et ça c'est pour une matrice 3x3)  , sans parler que les calculs de la PS1 ne sont pas fait pour avoir un Zbuffer , donc en plus faudra trier tes triangles et avoir le fameux clignotements des triangles qui va avec ,bref tu comprend pourquoi je suis étonné de son utilisation  
Peut etre qu'il est utilisé pour les SFX néanmoins...
Une optimisation du VU0 et VU1 plus poussé leur permettrais des gain beaucoup plus significatif

Normalement, en principe, oui si le FGPA est une copie parfaite du système original, mais ce n'est pas prouvé non plus et il faudrait des codeurs de qualité professionnel et si possible de l'époque s'y mettent pour répondre à la question.

C'est bien connu de nos jours on a que des mauvais programmeur hein ! ...

[Invité]

Pour la ps1 c'est de la semi emulation.

[Tryphon]

La PS2 n'était pas plus facile qu'un autre parce qu'il y avait le CDROM

Mais il est fort probable que le choix du processeur de la PS2  , un dérivé du MIPS n'a pas était au hasard (certes un CPU custom mais qui se base sur l'architecture MIPS comme la PS1).

Le choix d'un core Mips pour le CPU de la PS2 n'a a priori pas de lien avec la rétrocompatibilité puisque la PS1 est émulé par le chip I/O qui intégrait le CPU de la PS1 (et que Naughty Dog utilisait aussi dans leur moteur 3D PS2).

Tu es sur ??
Je me souviens pas que la PS2 ait incorporé quoi que ce soit de la  PS1, il me semble que c'est plutôt sur les première PS3 jap que le hard de la PS1 avait été intégré.

Il me semble bien qu'Upsi a raison. C'est le hard de la PS2 (ou tout au moins le EE) que les premières PS3 embarquent (pour les versions plus récentes l'émulation est logicielle).

Concernant les consoles FPGA, de ce que je comprends, c'est aussi de l'émulation (hardware au lieu de software, donc plus rapide) avec les mêmes limites : on ne peut émuler que ce que l'on connaît parfaitement, or ce n'est pas le cas de tous les composants, dont les comportements sont principalement connus par les efforts des devs d'émulateurs. Ce n'est jamais parfait (cf la démo Titan Overdrive qui a conduit à la découverte de nouveaux comportements du VDP). J'ai du mal à comprendre l'excitation autour de ces projets.

[Zarnal]

Concernant les consoles FPGA, de ce que je comprends, c'est aussi de l'émulation (hardware au lieu de software, donc plus rapide) avec les mêmes limites : on ne peut émuler que ce que l'on connaît parfaitement, or ce n'est pas le cas de tous les composants, dont les comportements sont principalement connus par les efforts des devs d'émulateurs. Ce n'est jamais parfait (cf la démo Titan Overdrive qui a conduit à la découverte de nouveaux comportements du VDP). J'ai du mal à comprendre l'excitation autour de ces projets.

Pareil. On veut te mettre dans la tête que ce sont d'excellentes photocopies, que cela éclate les émulateurs mais dans la pratique ce n'est pas le cas. C'est une alternative, pas un remplacement. Et que l'on ne vienne pas parler latence, ce n'est pas le propos.

Exemple pour l'overdrive 2 FPGA :



Mégadrive originale :

[TotOOntHeMooN]

Quand les premières versions de UAE (émulateur Amiga)sont arrivées à la fin des années 90, tout le monde crachait dessus car c'était lent et perfectible compaté à Fellow (un autre). C'est un choix de vouloir prendre des raccourcis pour atteindre un objectif ou de prendre son temps en se disant qu'avec l'évolution des technologies et le savoir, les choses seront meilleurs dans un futur proche.

Vous pouvez transposer cela aux FPGA qui permettent de reproduire des comportements de façon encore plus précise. Après, ce n'est pas aujourd'hui qu'il faut porter un jugement définitif à ce sujet... Ca viendra plus vite que vous ne le pensez, maintenant qu'il est aisé de décaper un composant pour en faire de la rétro-ingénieurie. A ce moment vous avez une précision qui est de l'ordre du fonctionnement des portes logiques.

De plus, de nombreux logiciels qui se disent "émulateurs", ne sont en fait que des "simulateurs" de comportement. Sachant que les FPGA et autres PLD sont utilisés dans les systèmes de jeux depuis très longtemps... Mettre la main sur leur fichiers de configurations (définition) sera le graal pour rapidement reproduire du hardware passé, somme se fut le grall de pouvoir dumper des ROM, mais à une autre échelle.

[Tryphon]

Pourquoi c'est plus aisé de décaper un composant qu'avant ?

Et pourquoi, à ma connaissance, ça a été rarement fait sur les composants consoles ?

[Hpman]

Un FPGA ne fait pas tourner de programme, il adopte une configuration.

La ou un émulateur se contente de savoir que tel registre gère tel aspect du hardware, pour le reproduire à l'identique en FPGA il faut aller voir sur le die comment il est physiquement implémenté.

Pas mal de chips ont été scrutés, mais principalement des CPU/chips audio, pour aller lire le microcode ou diverses tables de données.

[TotOOntHeMooN]

Décaper c'est une chose, après il faut avoir accès à un microscope électronique capable de prendre un clichet global dans une résolution suffisante pour voir l'agencement des transistors afin de pouvoir en étudier les patterns, si possible. En plus, hormis pour les espions qui clonnaient du hardware (car on parle de ça finalement), cette technologie n'était pas forcément accessible et surtout dénuée de sens pour le grand publique.

Après, on peut constater que des programmeurs utilisent des FPGA un peut comme ils le feraient avec un émulateur... Ils ne font pas un travail d'électronicien si l'on peut dire. Et hormis avoir un système embarqué, l'intérêt se réduit à peau de chagrin. Je pense que la confusion sur l'efficacité des FPGA par rapport aux émulateurs se résume à cette pratique. Alors qu'à la base, un FPGA permet de tester la définition d'un design modélisé dans le but d'en faire un ASIC. (circuit figé au même titre qu'une CPU ou autre chip custom)

MAME a une définition des composants depuis longtemps, car le fait de gérer plusieurs hardware qui ont des éléments en commun les ont poussés à faire les choses bien. Il y a déjà quelques émulateurs de "petits jeux" 8-bit qui tournent grace à cela. On peut très bien imaginer un jour pourvoir cloner des systèmes d'arcade plus modernes dans un FPGA grace au travail accompli et à accomplir.

Pour faire un parallèle façon SF : Si les émulateurs permettaient de créer des humanoïdes, alors les FPGA permettraient de créer aussi des humains.

[Tryphon]

Un FPGA ne fait pas tourner de programme, il adopte une configuration.

On pourrait ergoter sur ce qu'est réellement un programme

La ou un émulateur se contente de savoir que tel registre gère tel aspect du hardware, pour le reproduire à l'identique en FPGA il faut aller voir sur le die comment il est physiquement implémenté.

Sauf que, si j'ai bien compris, peu de chips sont connus au niveau du die, du coup je suppose que les FPGA se contentent de leur faire adopter un comportement compatible avec toutes les observations connues jusqu'à présent, non ?

Ce qui explique qu'une démo comme Titan Overdrive II ne passe pas sur un FPGA ?

Et au passage, quand un chip est connu au niveau du microcode, on trouve assez vite des émulateurs software qui se basent là-dessus sur leur implémentation.

Du coup, vraiment, j'ai du mal à voir en quoi c'est plus "fidèle"...

Décaper c'est une chose, après il faut avoir accès à un microscope électronique capable de prendre un clichet global dans une résolution suffisante pour voir l'agencement des transistors afin de pouvoir en étudier les patterns, si possible.

Donc c'est pas si aisé

Après, on peut constater que des programmeurs utilisent des FPGA un peut comme ils le feraient avec un émulateur... Ils ne font pas un travail d'électronicien si l'on peut dire. Et hormis avoir un système embarqué, l'intérêt se réduit à peau de chagrin. Je pense que la confusion sur l'efficacité des FPGA par rapport aux émulateurs se résume à cette pratique. Alors qu'à la base, un FPGA permet de tester la définition d'un design modélisé dans le but d'en faire un ASIC. (circuit figé au même titre qu'une CPU ou autre chip custom)

Oui, ça je suis d'accord. Mais je parle effectivement de ces consoles (les micros je sais pas) FPGA qu'on nous vend comme un net progrès par rapport aux émulateurs, alors que dans l'esprit c'est la même chose, avec les mêmes limitations (à part la rapidité).

Pour faire un parallèle façon SF : Si les émulateurs permettaient de créer des humanoïdes, alors les FPGA permettraient de créer aussi des humains.

J'ai pas compris le parallèle

[upsilandre]

Tu es sur ??
Je me souviens pas que la PS2 ait incorporé quoi que ce soit de la  PS1, il me semble que c'est plutôt sur les première PS3 jap que le hard de la PS1 avait été intégré.

Oui certain. Les PS1,PS2 et PS3 c'est des machines que je connais tres bien.
Un petit tour sur Wiki https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications

Input Output Processor (IOP)
I/O Memory: 2 MB EDO DRAM
CPU Core: Original PlayStation CPU (MIPS R3000A clocked at 33.8688 MHz or 37.5 MHz+PS1 GTE and MDEC for backwards compatibility with PS1 games) Automatically underclocked to 33.8688 MHz to achieve hardware backwards compatibility with original PlayStation format games.
Sub Bus: 32-bit
Connection to: SPU and CD/DVD controller.

Et sur PS3 c'est pas le hard de la PS1 qui etait intégré mais celui de la PS2 (la PS1 est émulé en soft sur PS3)

[Zarnal]

Cela sera plus fidèle lorsque le " niveau transistor " sera atteint je suppose ?

Là le problème pour moi c'est que l'on essaye de te faire prendre des vessies pour des lanternes du genre c'est mieux car ce sont des portes logiques (argument revenant le plus souvent). A terme certainement mais pas à ce jour. Et je ne vais pas mettre (par choix) 200 euros pour de l'approximatif. Parce que si on va au bout des choses on obtiendra bien des +- des clones si j'ai bien compris.

[Tryphon]

Cela sera plus fidèle lorsque le " niveau transistor " sera atteint je suppose ?

C'est aussi comme ça que je le comprends. Mais je dirais que quand on en sera là, les émulateurs softwares aussi seront plus fidèles (mais faudra des super PC pour les faire tourner )

[Hpman]

On pourrait ergoter sur ce qu'est réellement un programme

Bah c'est une vraie différence. On peut pas dire qu'une porte nand fasse tourner un programme, elle à juste un comportement qui régit l'état de la sortie en fonction des entrées.
Un FPGA c'est pareil, même si le langage pour le définir ressemble un peu à du code.

Sauf que, si j'ai bien compris, peu de chips sont connus au niveau du die, du coup je suppose que les FPGA se contentent de leur faire adopter un comportement compatible avec toutes les observations connues jusqu'à présent, non ?

Ce qui explique qu'une démo comme Titan Overdrive II ne passe pas sur un FPGA ?

Et au passage, quand un chip est connu au niveau du microcode, on trouve assez vite des émulateurs software qui se basent là-dessus sur leur implémentation.

Du coup, vraiment, j'ai du mal à voir en quoi c'est plus "fidèle"...

Tu peut tirer énormément d'infos en analysant les entrées/sorties, les cycles et timings des bus etc...
Dans la plupart des cas ça va suffire pour reproduire le comportement et tu n'auras pas besoin du die. Le die viens en dernier recours quand on arrive pas à comprendre certains aspects (genre un chip FM, tu vas pas inventer les tables utilisées, faut aller voir).

Dans le cas overdrive II ca utilise des registres debug peu/pas documentés jusqu'a peu donc ça va prendre probablement un peu de temps à être implémenté.

Un FPGA sera fidèle au clock pulse près. Les émulateurs en sont encore bien loin.

Un exemple de problèmes que n'aura pas un FPGA:

[upsilandre]

J'en suis étonnée parce que le proc de la PS1 est une vrai tortue obsolète comparé à la PS2, je vois pas vraiment l’intérêt de gaspiller du temps a faire de la 3D avec (parce qu'il ne permet pas de faire des matrice 4x4) et que tu peux espérer au mieux avoir que 3000-4000 triangle avec ! (et ça c'est pour une matrice 3x3)  , sans parler que les calculs de la PS1 ne sont pas fait pour avoir un Zbuffer , donc en plus faudra trier tes triangles et avoir le fameux clignotements des triangles qui va avec ,bref tu comprend pourquoi je suis étonné de son utilisation  
Peut etre qu'il est utilisé pour les SFX néanmoins...
Une optimisation du VU0 et VU1 plus poussé leur permettrais des gain beaucoup plus significatif

Quand je dis qu'il l'utilisait dans leur moteur c'est vraiment au sens large (c'etait dans leur pipeline et ils etaient assez fier d'aller chercher la moindre ressource, c'etait leur signature par rapport a d'autre studios), c'etait pas pour faire du calcule sensible de transformation ou de lighting ou ce genre de chose. De souvenir ils l'utilisaient beaucoup pour la décompression des data et les décisions lié au streaming et plus étonnant (c'est surtout ca qui m'avait marqué), pour Jak&Daxter1 au moins, ils l'ont aussi utilisé pour une passe de tri de géométrie (sans doute pour préparer le clipping ou l'occlusing) mais je sais plus exactement de quelle ordre, c'est assez vague comme souvenir, probablement une phase grossière de tri.
Je le tiens de source sure puisque je le tiens de 2 programmeurs Naughty Dog de l’époque que sont Christophe Balestra devenu par la suite le co-directeur de Naughty Dog et avec qui j'avais eu la chance de discuter lors d'un repas IGDA en 2006 (ou il avait deja prit les rênes du studio et préparait la revolution Uncharted) et dans la discussion il m'avait parlé de cette époque PS2 et de ce qu'ils s'amusaient a faire avec le chip IOP.
Et je le tiens de Dider Malenfant un autre Francais de Naughty Dog plus ancien (qui a donc vu arriver et accueilli Balestra) qui a ensuite fondé Ready at Dawn et qui a l'époque etait codeur sur le tout premier Jak&Daxter (Balestra est arrivé en cours de dev du second épisode je crois) et qui avait notamment en charge le code IOP et encore une fois j'ai eu la chance de discuter directement avec lui aussi a l'époque ou il trainait sur le forum playfrance pendant le développement de Jak&Daxter (y a environ 17-18 ans) et ca m'avait marqué justement. Malheureusement en 18 ans le site playfrance a eu pas mal de remaniement, a priori tout ca a disparu.

[Tryphon]

Tu peut tirer énormément d'infos en analysant les entrées/sorties, les cycles et timings des bus etc...
Dans la plupart des cas ça va suffire pour reproduire le comportement et tu n'auras pas besoin du die. Le die viens en dernier recours quand on arrive pas à comprendre certains aspects (genre un chip FM, tu vas pas inventer les tables utilisées, faut aller voir).

Certes, mais ces données-là ont été justement déterminées pour permettre à la base la création d'émulateurs, et les devs d'émulateurs continuent à se baser dessus.

Dans le cas overdrive II ca utilise des registres debug peu/pas documentés jusqu'a peu donc ça va prendre probablement un peu de temps à être implémenté.

C'est donc exactement la même problématique que pour les émulateurs : c'est fidèle à ce qu'on sait, ni plus, ni moins.

Un FPGA sera fidèle au clock pulse près.

Quand la machine sera connue à ce niveau-là.

Les émulateurs en sont encore bien loin.

Même Higan ? Même Exodus ?

Un exemple de problèmes que n'aura pas un FPGA

Je peux pas voir la vidéo. Ça consiste en quoi ?

[Zarnal]

Même Higan ? Même Exodus ?

Un exemple de problèmes que n'aura pas un FPGA

Je peux pas voir la vidéo. Ça consiste en quoi ?

Un glitch pour garou.

Mais il semble comparer mame à une vraie NG. Je me trompe ? Et dans ce cas je voudrais bien voir une version FPGA.

[Tryphon]

ok mais en quoi ce glitch montre la supériorité d'un FPGA sur un ému cycle-accurate ?

[Zarnal]

ok mais en quoi ce glitch montre la supériorité d'un FPGA sur un ému cycle-accurate ?

Parce qu'il est censé disparaitre avec un FPGA bien utilisé (voir remarque de totoon plus haut).

[TotOOntHeMooN]

Cela sera plus fidèle lorsque le " niveau transistor " sera atteint je suppose ?

Indirectement, on est déjà au niveau transistor sauf qu'on assemble des portes logiques sans les manipuler directement.
Un peut comme manipuler des molécules, plutôt que les atomes qui les composes... On est pas à se niveau avec un programme informatique.
Il y a confusion entre language de description d'un modèle électronique (ça pourrait-être un schéma aussi) et une simulation de comportement.

A la base, les FPGA servent à tester un design (le VDP de la Megadrive par exemple) avant de faire fabrider en série des ASIC pour l'intégrer dans les consoles.
Certains systèmes d'arcade (CAVE par exemple) utilisais déjà directement des FPGA pour se faire, car plus rentable pour eux vu la quantité de PCB produite.

[Tryphon]

ok mais en quoi ce glitch montre la supériorité d'un FPGA sur un ému cycle-accurate ?

Parce qu'il est censé disparaitre avec un FPGA bien utilisé (voir remarque de totoon plus haut).

Mais il disparaîtrait tout autant avec un ému cycle-accurate non ?

[Tryphon]

Tiens, questions sur les FPGA (parce que mine de rien je trouve ça fascinant) :

1) c'est "reconfigurable" un FPGA ?

2) imaginons que je cherche à monter un petit projet (genre une console custom). Y'a des ressources pour apprendre à s'en servir ? Faut quoi comme niveau ? Où peut-on l'obtenir online (me répondez pas "à l'école", j'aurais rien contre mais je peus plus )

[Hpman]

Bah c'est sur que sur le papier tu peut simuler chaque transistor par logiciel, sauf que au jour d'aujourd'hui ce n'est pas le cas, donc un FPGA bien gaulé restera supérieur encore un moment (sans parler du cout).

Tu as aussi d'autres avantages, un FPGA tourne en temps réel, la ou un émulateur tourne généralement avec une frame de latence minimum.
Sur un émulateur tu peux pas brancher de cartouche, la ou une machine fpga prend tout comme la vraie console.

[Hpman]

Tiens, questions sur les FPGA (parce que mine de rien je trouve ça fascinant) :

1) c'est "reconfigurable" un FPGA ?

2) imaginons que je cherche à monter un petit projet (genre une console custom). Y'a des ressources pour apprendre à s'en servir ? Faut quoi comme niveau ? Où peut-on l'obtenir online (me répondez pas "à l'école", j'aurais rien contre mais je peus plus )

C'est reconfigurable, il y a une serial eeprom externe ou de la flash integrée selon les modèles.

Le langage c'est Verilog et/ou VHDL. Tu auras tout ce qu'il te faut pour la syntaxe online, après il faut quand même un certain savoir faire pour architecturer ton bouzin correctement. Tu peut trouver plein d'exemples pour les cartes de dev les plus répandues.

[Tryphon]

Bah c'est sur que sur le papier tu peut simuler chaque transistor par logiciel, sauf que au jour d'aujourd'hui ce n'est pas le cas, donc un FPGA bien gaulé restera supérieur encore un moment (sans parler du cout).

Sauf qu'aujourd'hui, les consoles FPGA reposent sur des données incomplètes, et ne sont donc pas plus fidèles qu'un ému software.

Tu as aussi d'autres avantages, un FPGA tourne en temps réel, la ou un émulateur tourne généralement avec une frame de latence minimum.

Tout à fait. D'un autre côté c'est plus facile de mettre un ému software à jour non ?

Sur un émulateur tu peux pas brancher de cartouche, la ou une machine fpga prend tout comme la vraie console.

À la condition qu'on y ait développé un port cartouche. Port cartouche que rien ne t'empêche d'interfacer avec un PC d'ailleurs...