Mister FPGA

[funkycochise]

Ajout des jeux du bundle Seta, Visco, Sammy https://www.patreon.com/Meathax/posts/s ... -167087644

[funkycochise]

Atari System 2

[AstarteLegion]

SF III Third strikes serait dispo ce vendredi pour les patréons de Jotego

J’ai vu ca. Mais je n’ai pas compris si il faudra la Dual Ram ou pas?

non pas besoin de dual RAM

[kobras]

Third strike est dispo
Par contre, c'est bizarre car Jotego dis que c'est le dernier jeux CPS3 alors qu'il manque encore Jojo Bizare adventure

[funkycochise]

Arabian https://misterfpga.org/viewtopic.php?t=10702





Outrunners www.patreon.com/Meathax/posts/outrunners-1993-167420740

[AstarteLegion]

Third strike est dispo
Par contre, c'est bizarre car Jotego dis que c'est le dernier jeux CPS3 alors qu'il manque encore Jojo Bizare adventure

Il a deja fait JoJo bizarre adventures, je l'ai testé. je sais pas si tu parles d'une version spécifique mais JoJo est jouable en tout cas

[kobras]

Third strike est dispo
Par contre, c'est bizarre car Jotego dis que c'est le dernier jeux CPS3 alors qu'il manque encore Jojo Bizare adventure

Il a deja fait JoJo bizarre adventures, je l'ai testé. je sais pas si tu parles d'une version spécifique mais JoJo est jouable en tout cas

T'es sur ? Car moi, j'ai que JoJo's Venture mais pas sa suite JoJo's Bizarre Adventure

[subman]

Core CPS3 de Javi : https://github.com/javi-ivaj/cps3-fpga/ ... /tag/beta4
*

javi_cps3.JPG

A tester pour comparer

[AstarteLegion]

Third strike est dispo
Par contre, c'est bizarre car Jotego dis que c'est le dernier jeux CPS3 alors qu'il manque encore Jojo Bizare adventure

Il a deja fait JoJo bizarre adventures, je l'ai testé. je sais pas si tu parles d'une version spécifique mais JoJo est jouable en tout cas

T'es sur ? Car moi, j'ai que JoJo's Venture mais pas sa suite JoJo's Bizarre Adventure

ah sorry sorry j'ai confondu, tu as raison! du coup je sais pas quand es ce qu'il va nous le sortir celui la , mais ca devrait pas tarder je crois.

[Be_nO]

Je ne me suis pas penché sur le sujet mais compatible avec le retour de force Outrunners ?

[funkycochise]

Avancée Cave CV1K



maintenant il a dit qu'il s'occupait d'optimiser le chargement

[Bobala954]

Core CPS3 de Javi : https://github.com/javi-ivaj/cps3-fpga/ ... /tag/beta4
*
javi_cps3.JPG


A tester pour comparer

Salut, merci beaucoup. Cela fonctionne assez bien chez moi - ça permet au moins de tester

[Cotw]

Le dév du core Cave a écrit un commentaire concernant son utilisation de l'IA Claude. Il l'utilise bien comme un assistant pour pousser au maximum la précision de son core et il a pu ainsi accomplir seul ce qu'aurait fait une équipe sur un an. Il tient à se démarquer de ceux qui utilisent l'IA pour coder rapidement les parties complexes sans vérifier quoi que ce soit.

Quel est l’avantage d’un FPGA ? C’est qu’il permet de rester très proche du matériel lui-même. Si ce que vous souhaitez émuler est un matériel donné, vous pouvez l’étudier en profondeur puis l’implémenter sur un FPGA, afin qu’il se comporte presque exactement comme l’original.

Cependant, lorsque les documents de développement d’origine ne sont pas disponibles, les développeurs n’ont d’autre choix que de procéder à la rétro-ingénierie du matériel original. Traditionnellement, il s’agit d’un processus extrêmement coûteux en temps et en argent, qui peut facilement nécessiter des dizaines, voire des centaines d’heures de travail. Aujourd’hui, les agents d’IA ont considérablement progressé et nous permettent d’explorer rapidement un champ des centaines de fois plus vaste que ce qu’un seul humain peut appréhender. Mais le travail d’ingénierie n’a pas disparu. Il existe toujours quelque part. La seule différence est de savoir s’il est pris en charge par un humain ou par un agent d’IA.

Malheureusement, lorsque l’objectif est de développer rapidement un core, il faut réduire ce travail. Les éléments difficiles à vérifier sur le matériel d’origine, ou qui peuvent être déduits au moyen d’hypothèses raisonnables, sont souvent laissés de côté. Le matériel graphique en est un exemple. Aujourd’hui, MAME décrit la majeure partie des informations nécessaires à l’affichage de l’image. Une méthode fréquemment utilisée consiste donc à mesurer certains éléments, comme les timings vidéo du matériel original, puis à réimplémenter le système graphique de manière à respecter ces caractéristiques. Étant donné que beaucoup de cores développés aujourd’hui à l’aide de l’IA sont créés sans même examiner le véritable circuit imprimé, cette méthode peut être considérée comme un moyen rentable de produire des cores de grande qualité.

Mais que faudrait-il faire pour se rapprocher autant que possible du matériel original ? Il faudrait analyser l’intégralité de ses circuits : processeur, son, graphismes, partie analogique… absolument tout. Cette approche est toutefois extrêmement inefficace, et très peu de personnes sont capables de la mettre en œuvre. Ces projets ne sont pas des travaux rémunérés : il s’agit, pour la plupart, de projets personnels réalisés par passion.

Comme j’analyse et retrace des ASIC depuis plusieurs années, la plupart d’entre vous savent probablement déjà que retracer un ASIC n’est pas impossible en soi. Le CV1k utilisait toutefois un FPGA à la place d’un ASIC. Pouvons-nous alors également déterminer la structure des circuits qu’il contient ? La réponse est « oui ».

Pour utiliser un FPGA, il faut y charger un fichier appelé « bitstream », qui configure les circuits internes du FPGA. Le MiSTer que vous utilisez repose lui aussi sur des bitstreams : les fichiers .rbf sont des bitstreams. Contrairement à du code machine compilé, un bitstream est cependant étroitement lié à l’agencement matériel de la puce. Sa rétro-ingénierie est donc beaucoup plus difficile que la décompilation d’un binaire ordinaire.

Le FPGA présent sur la carte CV1k sert à générer les graphismes affichés à l’écran, et il est généralement désigné comme le « blitter ». En travaillant avec Claude, j’ai réussi à comprendre le format du bitstream du FPGA EP1C12F324 utilisé comme blitter sur la carte CV1k, puis à le reconstituer sous la forme d’une netlist. J’ai également reconstruit du code RTL à partir de cette netlist — bien entendu, ce RTL est très différent de celui qui avait été utilisé à l’époque du développement original.

Autrement dit, je suis parti de ce qui n’était, à l’origine, qu’un bloc opaque de données de bitstream. Je l’ai converti en une netlist permettant de simuler les circuits logiques sur un ordinateur, puis je suis allé encore plus loin en l’abstrayant sous la forme d’une description du circuit numérique qu’un être humain peut réellement lire et comprendre. Pourquoi me suis-je donné autant de mal ? Pour la même raison que celle qui me pousse à décapsuler des ASIC afin d’en révéler les circuits internes : je voulais vous proposer un core offrant le niveau de fidélité le plus élevé possible.

Si d’autres développeurs s’étaient attaqués à ce projet, ils auraient peut-être implémenté un blitter « suffisamment proche » de l’original avant de passer à autre chose. Mais ce n’est pas ainsi que je travaille. J’ai vu quelqu’un affirmer sur Twitter que le core CV1k avait été « vibe codé » et qu’il ne fallait pas le soutenir financièrement. Je pense qu’il lui était facile de dire cela simplement parce qu’il ne me connaît pas.

Pour donner un ordre de grandeur, la quantité de travail réalisée ici aurait normalement nécessité une équipe composée de plusieurs spécialistes travaillant pendant plus d’un an. Les agents d’IA m’ont toutefois énormément aidé dans le développement du core CV1k. Mais même lorsque plusieurs personnes utilisent la même IA, la qualité du résultat final dépend toujours de la personne qui l’utilise.

[mael_]

Le dév du core Cave a écrit un commentaire concernant son utilisation de l'IA Claude. Il l'utilise bien comme un assistant pour pousser au maximum la précision de son core et il a pu ainsi accomplir seul ce qu'aurait fait une équipe sur un an. Il tient à se démarquer de ceux qui utilisent l'IA pour coder rapidement les parties complexes sans vérifier quoi que ce soit.

Quel est l’avantage d’un FPGA ? C’est qu’il permet de rester très proche du matériel lui-même. Si ce que vous souhaitez émuler est un matériel donné, vous pouvez l’étudier en profondeur puis l’implémenter sur un FPGA, afin qu’il se comporte presque exactement comme l’original.

Cependant, lorsque les documents de développement d’origine ne sont pas disponibles, les développeurs n’ont d’autre choix que de procéder à la rétro-ingénierie du matériel original. Traditionnellement, il s’agit d’un processus extrêmement coûteux en temps et en argent, qui peut facilement nécessiter des dizaines, voire des centaines d’heures de travail. Aujourd’hui, les agents d’IA ont considérablement progressé et nous permettent d’explorer rapidement un champ des centaines de fois plus vaste que ce qu’un seul humain peut appréhender. Mais le travail d’ingénierie n’a pas disparu. Il existe toujours quelque part. La seule différence est de savoir s’il est pris en charge par un humain ou par un agent d’IA.

Malheureusement, lorsque l’objectif est de développer rapidement un core, il faut réduire ce travail. Les éléments difficiles à vérifier sur le matériel d’origine, ou qui peuvent être déduits au moyen d’hypothèses raisonnables, sont souvent laissés de côté. Le matériel graphique en est un exemple. Aujourd’hui, MAME décrit la majeure partie des informations nécessaires à l’affichage de l’image. Une méthode fréquemment utilisée consiste donc à mesurer certains éléments, comme les timings vidéo du matériel original, puis à réimplémenter le système graphique de manière à respecter ces caractéristiques. Étant donné que beaucoup de cores développés aujourd’hui à l’aide de l’IA sont créés sans même examiner le véritable circuit imprimé, cette méthode peut être considérée comme un moyen rentable de produire des cores de grande qualité.

Mais que faudrait-il faire pour se rapprocher autant que possible du matériel original ? Il faudrait analyser l’intégralité de ses circuits : processeur, son, graphismes, partie analogique… absolument tout. Cette approche est toutefois extrêmement inefficace, et très peu de personnes sont capables de la mettre en œuvre. Ces projets ne sont pas des travaux rémunérés : il s’agit, pour la plupart, de projets personnels réalisés par passion.

Comme j’analyse et retrace des ASIC depuis plusieurs années, la plupart d’entre vous savent probablement déjà que retracer un ASIC n’est pas impossible en soi. Le CV1k utilisait toutefois un FPGA à la place d’un ASIC. Pouvons-nous alors également déterminer la structure des circuits qu’il contient ? La réponse est « oui ».

Pour utiliser un FPGA, il faut y charger un fichier appelé « bitstream », qui configure les circuits internes du FPGA. Le MiSTer que vous utilisez repose lui aussi sur des bitstreams : les fichiers .rbf sont des bitstreams. Contrairement à du code machine compilé, un bitstream est cependant étroitement lié à l’agencement matériel de la puce. Sa rétro-ingénierie est donc beaucoup plus difficile que la décompilation d’un binaire ordinaire.

Le FPGA présent sur la carte CV1k sert à générer les graphismes affichés à l’écran, et il est généralement désigné comme le « blitter ». En travaillant avec Claude, j’ai réussi à comprendre le format du bitstream du FPGA EP1C12F324 utilisé comme blitter sur la carte CV1k, puis à le reconstituer sous la forme d’une netlist. J’ai également reconstruit du code RTL à partir de cette netlist — bien entendu, ce RTL est très différent de celui qui avait été utilisé à l’époque du développement original.

Autrement dit, je suis parti de ce qui n’était, à l’origine, qu’un bloc opaque de données de bitstream. Je l’ai converti en une netlist permettant de simuler les circuits logiques sur un ordinateur, puis je suis allé encore plus loin en l’abstrayant sous la forme d’une description du circuit numérique qu’un être humain peut réellement lire et comprendre. Pourquoi me suis-je donné autant de mal ? Pour la même raison que celle qui me pousse à décapsuler des ASIC afin d’en révéler les circuits internes : je voulais vous proposer un core offrant le niveau de fidélité le plus élevé possible.

Si d’autres développeurs s’étaient attaqués à ce projet, ils auraient peut-être implémenté un blitter « suffisamment proche » de l’original avant de passer à autre chose. Mais ce n’est pas ainsi que je travaille. J’ai vu quelqu’un affirmer sur Twitter que le core CV1k avait été « vibe codé » et qu’il ne fallait pas le soutenir financièrement. Je pense qu’il lui était facile de dire cela simplement parce qu’il ne me connaît pas.

Pour donner un ordre de grandeur, la quantité de travail réalisée ici aurait normalement nécessité une équipe composée de plusieurs spécialistes travaillant pendant plus d’un an. Les agents d’IA m’ont toutefois énormément aidé dans le développement du core CV1k. Mais même lorsque plusieurs personnes utilisent la même IA, la qualité du résultat final dépend toujours de la personne qui l’utilise.

C'est intéressant de savoir qu'il garde une certaine maîtrise de ce qu'il fait, avec l'aide de la genAI (j'ose pas écrire malgré).
Je croise les doigts pour que ça continue pour les cores créés en mode augmentés, dans le futur.

[galsia]

C'est dingue que des développeurs aient à justifier leur utilisation d'ia quasiment en s'excusant, bordel le niveau du public jv est effarant.

[Cotw]

Je pense que beaucoup passent à côté du train IA et ne savent pas vraiment en quoi ça consiste. Ce type est parfaitement clair sur le sujet. Il est plus efficace pour une personne de manager des agents IA pour faire avancer un développement que de monter et organiser une équipe de plusieurs personnes qui travailleraient sur le temps libre (c'est implicite). Et ça va beaucoup plus vite pour un résultat plus fiable. Sous réserve que la personne derrière fasse cela sérieusement