Re: Megadrive et Super Nintendo : parlons technique !

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

[Zarnal]

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.

Si, DICE. A genou le CPU pour tenter de jouer à pong.

Pour la latence, une précision s'impose. Il y en a également un minimum sur le FPGA (comprendre ce n'est pas 0 de chez 0, tout comme le hard) ? J'ai entendu les deux sons de cloche.

[Tryphon]

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.

Oui, c'est plutôt le deuxième aspect qui pêche (verilog et VHDL j'ai déjà un peu regardé comment ça marche, d'ailleurs verilog c'est rigolo on dirait de l'ADA, ça faisait 2O ans que j'en n'avais pas vu ).

Par cartes de dev tu entends quoi ?

[Invité]

Je rejoins assez Tryphon qu'un émulateur fait aussi bien qu'un FPGA.

Le souci de tout les émulateurs que j'ai pu constater (vu le nombre de console que j'ai codé) , et comme le dis Touko un souci de timing , il y'a un gros souci de timing entre émulateur et un vrai hard (ce qui me semble logique).
Et c'est la première chose que j'ai pu remarquer comme différence sur ému/hard réel que ça soit sur SNES ou PS2 :p

Mais que cela soit clair  ,le souci n'est pas le CPU principal , il est pas très compliqué d'émuler un CPU de post 1995, les cycles sont fixes et bien connu et c'est facile à coder aux cycle près , par contre pour les I/O  et le timing du rendu/sonore ah ah plus complexe x)

Par contre un bug sur du hard réel mais invisible sur un ému sur SNES , c'est la lecture du joypad , si tu le fait au dehors du temps 'voulu' , cela fait des glich graphique , il est probable que sur un FPGA qui émule tout un système/architecture correctement arrivera a reproduire ce 'bug' , sur un émulateur c'est plus complexe parce que ben techniquement lire le joypad pose aucun souci et n'a aucune raison de créer un bug graphique !

@upsilandre
Après il est vrai que sur la plupart des consoles le processeur sonore ne fait absolument pas grand chose (vu que sur PS2 IOP sert de proc sonore il me semble) donc lui faire faire des calculs et pas un mal.
D'ailleurs j'avais déjà pensé a faire de même sur SNES , que le proc sonore fasse un peu de calcul (pour le moment , je ne sais pas quel genre de calcul , mais ça viendra )

[Hpman]

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

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

Tu parle de mettre à jour le code ou déployer unpatch? Si demain on découvre un registre sur un hard, ca peut être tout à fait trivial à ajouter en verilog et très complexe à émuler en logiciel.

Bah non si je fait une cartouche avec un mapper custom, un émulateur ne saura pas la lire. Un fpga s'en fiche, il fonctionne comme le vrai hard.

Cartes de dev = carte FPGA toute prête pour faire du dev, avec plus ou moins de choses integrées pour faire joujou

Pour la latence, une précision s'impose. Il y en a également un minimum sur le FPGA (comprendre ce n'est pas 0 de chez 0, tout comme le hard) ? J'ai entendu les deux sons de cloche.

Pour une sortie analogique c'est 0, après si y'a une sortie HDMI possible que ça impose un délai pour l'encodage, je connais pas les détails du signal. En tout cas ça s'ajoute aussi à un ému.

[Tryphon]

Tu parle de mettre à jour le code ou déployer unpatch?

C'est pareil. Je veux dire que sur une console FPGA qui sortirait aujourd'hui, le code verilog n'est certainement pas fidèle vu que la machine n'est pas encore complètement documentée. Dans un an, les dev auront fait progresser ce code mais il sera difficile pour quelqu'un l'ayant acheté cette année de mettre à jour (enfin je suppose).

Alors qu'avec une console basée sur un émulateur, mettre à jour le code de l'émulateur est très simple.

Bah non si je fait une cartouche avec un mapper custom, un émulateur ne saura pas la lire. Un fpga s'en fiche, il fonctionne comme le vrai hard.

Je crois qu'on ne s'est pas compris. Pour moi, il y a 3 choses :

* la cartouche
* le lecteur
* l'"exécutant" (FPGA ou émulateur)

Le mapper est dans la cartouche. Du point de vue de l'exécutant, qu'il y ait ou non un mapper est transparent.

Je crois que toi tu parles d'un émulateur PC qui lit des fichiers binaires, et qui donc doit émuler aussi les mappers. Moi je parle d'un émulateur qu'on aurait interfacé avec un lecteur de cartouche (et donc capable d'envoyer et recevoir des signaux).

Pour moi ton histoire de mapper c'est lié aux E/S du système, pas au cœur (FPGA ou émulateur soft) proprement dit.

Le problème est d'ailleurs réversible : si ta console FPGA gère les images ROM (ce qui semble être le cas de la future MD), alors tu dois implémenter la gestion des mappers (et des systèmes de fichiers)...

[upsilandre]

@upsilandre
Après il est vrai que sur la plupart des consoles le processeur sonore ne fait absolument pas grand chose (vu que sur PS2 IOP sert de proc sonore il me semble) donc lui faire faire des calculs et pas un mal.
D'ailleurs j'avais déjà pensé a faire de même sur SNES , que le proc sonore fasse un peu de calcul (pour le moment , je ne sais pas quel genre de calcul , mais ça viendra )

Dans la PS2 y a encore un autre chip qui process l'audio (avec aussi sa propre RAM)

[Tryphon]

Cartes de dev = carte FPGA toute prête pour faire du dev, avec plus ou moins de choses integrées pour faire joujou

OK, mais est-ce que tu aurais des ressources sur comment implémenter un petit CPU avec, ou même un petit système complet ? (soyons fou : une vieille console comme une Atari 26OO ?)

[Hpman]

Alors qu'avec une console basée sur un émulateur, mettre à jour le code de l'émulateur est très simple.

Bah les cartes flash type everdrive sont à vbase de FPGA, ça se met à jour très bien...

Je crois qu'on ne s'est pas compris. Pour moi, il y a 3 choses :

* la cartouche
* le lecteur
* l'"exécutant" (FPGA ou émulateur)

Le mapper est dans la cartouche. Du point de vue de l'exécutant, qu'il y ait ou non un mapper est transparent.

Je crois que toi tu parles d'un émulateur PC qui lit des fichiers binaires, et qui donc doit émuler aussi les mappers. Moi je parle d'un émulateur qu'on aurait interfacé avec un lecteur de cartouche (et donc capable d'envoyer et recevoir des signaux).

Pour moi ton histoire de mapper c'est lié aux E/S du système, pas au cœur (FPGA ou émulateur soft) proprement dit.

Le problème est d'ailleurs réversible : si ta console FPGA gère les images ROM (ce qui semble être le cas de la future MD), alors tu dois implémenter la gestion des mappers (et des systèmes de fichiers)...

Bah oui mais la encore tu cause d'un truc théorique qui existe pas. Un émulateur ne simule pas les signaux du hardware.

Moi un émulateur qui tourne en live avec une cartouche externe je veux bien qu'on me le présente. Je branche une cartouche NG avec ses 150+ signaux et on voit à quelle vitesse ça tourne

Exemple de systeme FPGA? Le minimig par exemple, qui fait tourner un amiga: https://github.com/rkrajnc/minimig-de1 (dossier rtl pour les fichiers verilog)

[TotOOntHeMooN]

Enfin, il y a plein de façon de se renseigner sur les FPGA (et même les émulateurs) et beaucoup de sites en parlent.
On s'éloigne quand même bien de la SNES vs MD niveau technique là... 

[Tryphon]

Alors qu'avec une console basée sur un émulateur, mettre à jour le code de l'émulateur est très simple.

Bah les cartes flash type everdrive sont à vbase de FPGA, ça se met à jour très bien...

Ah ? Je savais pas (et pourtant j'en ai une !)

Bah oui mais la encore tu cause d'un truc théorique qui existe pas.

Ben comme toi : un FPGA qui simule parfaitement une console, j'en connais pas

Moi un émulateur qui tourne en live avec une cartouche externe je veux bien qu'on me le présente. Je branche une cartouche NG avec ses 150+ signaux et on voit à quelle vitesse ça tourne

Ça n'existe bien sûr pas (faut dire que je vois pas trop l'intérêt quand c'est tellement plus pratique de balancer des ROMs), mais je doute que gérer 150 signaux (ou même 1000) demande une puissance énorme (c'est plus émuler les ALU qui va peser).

Exemple de systeme FPGA? Le minimig par exemple, qui fait tourner un amiga: https://github.com/rkrajnc/minimig-de1 (dossier rtl pour les fichiers verilog)

Merci, je mets ça de côté. J'ai cependant peur que ça soit un peu difficile comme architecture si je veux juste comprendre comment ça marche

[Tryphon]

Enfin, il y a plein de façon de se renseigner sur les FPGA (et même les émulateurs) et beaucoup de sites en parlent.

Pas tant que ça. J'ai fait des recherches avant de poser la question, et je n'ai rien trouvé de très didactique à ce sujet.

On s'éloigne quand même bien de la SNES vs MD niveau technique là... 

Pas vraiment, vu qu'on partait principalement du nouveau clone Mega SG.

[Hpman]

Ça n'est pas parfait par manque d'infos, la ou un émulateur restera imparfait même avec toutes les infos disponibles.

Et dans la vraie vie tu raccordes comment 150 signaux derrière un pc pour que tout ça tourne en temps réel ?

[Invité]

Quand j'apprends qu'il est plus facile d'émuler une SNES à une Mega Drive, je trouve que c'est révélateur.

Par contre quand j'ai demandé s'il était possible aujourd'hui de reproduire le hard de la Mega Drive ou de la Super Nintendo, je ne voulais pas parler d'émulation et de reproduction du hardware à l'identique ou du moins similaire.

Quand je vois le prix de la Mega Drive FPGA, je me dis qu'avec 100 euros de plus, on pourrait peut-être réaliser une vraie Mega Drive en respectant le hardware de l'époque non ?

L'émulation, je trouve que cela à de l'intérêt dans le sens où on installe un programme gratuit pour profiter de nombreuses fonctionnalités qui ne sont pas disponibles sur le matériel d'origine. Par contre, un émulateur vendu sous forme de console dans le but de remplacer la vraie machine, je suis beaucoup plus septique, sauf si c'est uniquement pour des tests ou du développement et encore... car au final on aligne les billets pour quelque chose qui ne sera jamais vraiment identique à une vraie console. Mais ce qui est fou, c'est devoir utiliser des machines 100 fois plus puissante qu'une Mega Drive pour tenter de reproduire la vraie Mega Drive...

D'ailleurs c'est risqué de développer un jeu Super Nintendo ou Mega Drive en s'appuyant essentiellement sur émulateur puis de regarder à la fin si cela tourne correctement sur le vrai hardware.

[Invité]

Dans la PS2 y a encore un autre chip qui process l'audio (avec aussi sa propre RAM)

Certe mais il est fort probable que les jeux commerciaux de la PS2 ne l'utilise pas (et que je ne l'utiliserai pas) , parce que j'ai vu aucune doc officiel mentionner le SPU1 ,la doc officiel ne parle que du SPU2

D'ailleurs c'est risqué de développer un jeu Super Nintendo ou Mega Drive en s'appuyant essentiellement sur émulateur puis de regarder à la fin si cela tourne correctement sur le vrai hardware.

j'aurais dit développer un jeu sans test hard est risqué tout simplement ,et encore je trouve la SNES et la MD bien émulé moi comparé au consoles 32/64 bits etc etc , qui sont eux quasiment impossible a émuler correctement.

[Invité]

D'ailleurs c'est risqué de développer un jeu Super Nintendo ou Mega Drive en s'appuyant essentiellement sur émulateur puis de regarder à la fin si cela tourne correctement sur le vrai hardware.

Du moment où tu titilles pas le hardware, t'as peu de risques,surtout avec les derniers émulateurs
Même si c'est inutile de tester toutes les 5 mins, il faut qd même le faire de temps en temps, pour être sur .
C'est plus sur le rendu des couleurs et du son que ça peut être délicat .

[Invité]

Mais c'est possible que ça plante sur Mega Drive et non sur émulateur, n'est-ce pas ?

[upsilandre]

Dans la PS2 y a encore un autre chip qui process l'audio (avec aussi sa propre RAM)

Certe mais il est fort probable que les jeux commerciaux de la PS2 ne l'utilise pas (et que je ne l'utiliserai pas) , parce que j'ai vu aucune doc officiel mentionner le SPU1 ,la doc officiel ne parle que du SPU2

Oui mais c'est quand meme le SPU2 qui compute l'audio et avec sa propre RAM, l'IOP fait juste son boulot d'I/O.

[TotOOntHeMooN]

Mais c'est possible que ça plante sur Mega Drive et non sur émulateur, n'est-ce pas ?

Oui. Ca veut dire que c'est mal émulé. C'est fréquent quand on ne respecte pas les timings.

[Invité]

Mais c'est possible que ça plante sur Mega Drive et non sur émulateur, n'est-ce pas ?

Oui évidemment.

[Tryphon]

Ça n'est pas parfait par manque d'infos, la ou un émulateur restera imparfait même avec toutes les infos disponibles.

Oui. Ce que je veux dire, c'est que tant qu'on manque d'infos (ce qui sera le cas encore un moment), je ne suis pas convaincu qu'une console FPGA fasse vraiment mieux qu'un bon ému.

Et dans la vraie vie tu raccordes comment 150 signaux derrière un pc pour que tout ça tourne en temps réel ?

Aucune idée, je suis pas électronicien

Mais je doute que ce soit quelque chose de franchement insurmontable.

Mais c'est possible que ça plante sur Mega Drive et non sur émulateur, n'est-ce pas ?

Oui, perso ça m'est arrivé souvent. Deux situations typiques :

* quand j'ai fait un "romhack" sur PS2, je ne savais pas qu'il fallait que les adresses soient alignées (ça faisait 25 ans que j'avais pas fait d'asm, et jamais sur un Mips), et j'ai lu des mots 16 bits à des adresses impaires. PCSX2 l'accepte en couinant à peine, une PS2 plante.

* sur Shinobi, j'ai eu des erreurs de pointeurs, qui pointaient sur des adresses illégales. Sur émulateur, ces adresses étaient pleines de O, que mon code considérait comme un marqueur de fin et le problème était invisible, alors que sur MD on y trouvait des nombres indéterminés et mon code finissait par planter.

[Invité]

Quand j'apprends qu'il est plus facile d'émuler une SNES à une Mega Drive, je trouve que c'est révélateur.

et donc, ça révèle quoi?

Quand je vois le prix de la Mega Drive FPGA, je me dis qu'avec 100 euros de plus, on pourrait peut-être réaliser une vraie Mega Drive en respectant le hardware de l'époque non ?

quel est l'intérêt "commercial" de sortir une console identique à 300 balles quand tu trouves des originales à 25 euros?

[Invité]

Oui, perso ça m'est arrivé souvent. Deux situations typiques :

* quand j'ai fait un "romhack" sur PS2, je ne savais pas qu'il fallait que les adresses soient alignées (ça faisait 25 ans que j'avais pas fait d'asm, et jamais sur un Mips), et j'ai lu des mots 16 bits à des adresses impaires. PCSX2 l'accepte en couinant à peine, une PS2 plante.

* sur Shinobi, j'ai eu des erreurs de pointeurs, qui pointaient sur des adresses illégales. Sur émulateur, ces adresses étaient pleines de O, que mon code considérait comme un marqueur de fin et le problème était invisible, alors que sur MD on y trouvait des nombres indéterminés et mon code finissait par planter.

D'ailleurs, j'ai remarqué certains comportement très différent entre émulateurs ne serait-ce déjà qu'avec Kega Fusion et Gens. J'imagine que voir que son programme plante sur le vrai hardware une fois le projet terminé doit être infernal.

Tiens hier, je me demandais si c'était vrai d'affirmer que la Super Nintendo était plus puissante sur la partie graphique que la Mega Drive. Pour la partie audio, avant je pensais que la SNES était bien plus performante, mais je ne savais pas du tout ce qu'il était possible de tirer du processeur sonore de la Mega Drive et surtout pourquoi une telle puce avait été choisie. À mes yeux se sont juste deux solutions différentes, mais pour la partie vidéo, est-ce qu'en terme de puissance brute le processeur vidéo est au dessus de celui de la Mega Drive bien que dans les deux cas se sont des évolutions d'un côté de la NES et de la Master System ?

Si oui, quel intérêt à l'époque d'avoir choisie une puce graphique si puissante pour la coupler à un processeur si faible ? Aujourd'hui, on peut se permettre d'avoir une carte 3D plus puissante que son processeur principal, car elle pourra lui venir en aide pour différent calcul, mais je trouve cela douteux de le faire dans les années 90 où il était important d'accorder les deux puces en termes de puissance.

D'ailleurs, SEGA avait choisi d'ajouter un 68K plus puissant justement pour ne pas limiter son processeur graphique dans le Mega CD.

[wiiwii007]

Ça n'est pas parfait par manque d'infos, la ou un émulateur restera imparfait même avec toutes les infos disponibles.

Oui. Ce que je veux dire, c'est que tant qu'on manque d'infos (ce qui sera le cas encore un moment), je ne suis pas convaincu qu'une console FPGA fasse vraiment mieux qu'un bon ému.

Je parle de mon expérience perso, uniquement, et pour avoir bien testé la Snes Mini et la Super NT. J'ai une différence sur l'input lag, et pour moi ça change tout. Après tu as la simplicité d'accès qui fait plaisir, tu prends, tu branches, t'as une Snes moderne.

Pas besoin de se prendre le choux avec tous les paramètres à la noix des ému. C'est plus complet qu'une mini, mais ça reste plus cool qu'un OSSC.

[Zarnal]

Ça n'est pas parfait par manque d'infos, la ou un émulateur restera imparfait même avec toutes les infos disponibles.

Oui. Ce que je veux dire, c'est que tant qu'on manque d'infos (ce qui sera le cas encore un moment), je ne suis pas convaincu qu'une console FPGA fasse vraiment mieux qu'un bon ému.

Je parle de mon expérience perso, uniquement, et pour avoir bien testé la Snes Mini et la Super NT. J'ai une différence sur l'input lag, et pour moi ça change tout. Après tu as la simplicité d'accès qui fait plaisir, tu prends, tu branches, t'as une Snes moderne.

Pas besoin de se prendre le choux avec tous les paramètres à la noix des ému. C'est plus complet qu'une mini, mais ça reste plus cool qu'un OSSC.

Cela ne sort qu'en HDMI ces FPGA MD/SFC ? Ou tu peux te brancher en péritel sur CRT ?


Et dans la vraie vie tu raccordes comment 150 signaux derrière un pc pour que tout ça tourne en temps réel ?

Tu achètes un MEGA PC.  
https://en.wikipedia.org/wiki/Amstrad_Mega_PC

[wiiwii007]

Tu n'as qu'une sortie HDMI. D'ailleurs sur une de mes 2 TV HD ready, la Super NT ne fonctionne pas, ça ne s'affiche tout simplement pas 

[Invité]

Mais c'est possible que ça plante sur Mega Drive et non sur émulateur, n'est-ce pas ?

Par exemple ce hack freeze sur ma MD au 1er boss, alors que sur émulateur ça passe.
https://www.romhacking.net/hacks/3621/

[Invité]

Tiens hier, je me demandais si c'était vrai d'affirmer que la Super Nintendo était plus puissante sur la partie graphique que la Mega Drive. Pour la partie audio, avant je pensais que la SNES était bien plus performante, mais je ne savais pas du tout ce qu'il était possible de tirer du processeur sonore de la Mega Drive et surtout pourquoi une telle puce avait été choisie. À mes yeux se sont juste deux solutions différentes, mais pour la partie vidéo, est-ce qu'en terme de puissance brute le processeur vidéo est au dessus de celui de la Mega Drive bien que dans les deux cas se sont des évolutions d'un côté de la NES et de la Master System ?

Si oui, quel intérêt à l'époque d'avoir choisie une puce graphique si puissante pour la coupler à un processeur si faible ? Aujourd'hui, on peut se permettre d'avoir une carte 3D plus puissante que son processeur principal, car elle pourra lui venir en aide pour différent calcul, mais je trouve cela douteux de le faire dans les années 90 où il était important d'accorder les deux puces en termes de puissance.

Pour le CPU principal de la SNES ,c'est qu'a la base elle devait être compatible avec la Nes , mais Nintendo a pris du retard et le succès de la MD a fait en sorte que la SNES est sorti plus rapidement sans les finitions (et sans la compatibilité Nes du coup )
Pour le processeur Sonore , ils sont bien différents , néanmoins pour l'époque le SPC700 est vraiment unique dans son genre  vu qu'il est capable de jouer des Samples , ce qui permet d'avoir des instruments à jouer.
Ensuite le CPU de la SNES n'est pas super long non plus , mais plus complexe , de nos jour cela se voit surtout qu'il n'existe aucun bon compilo pour ce processeurs

Si on doit faire un point fort/faible entre la SNES et la MD voici ce que je dirais :
La SNES Point fort :
-Nombre de palette et de couleur
-1 BG pour le hud spécifique
-128ko de RAM
-Plusieurs effet intéressants , la transparence , le HDMA et le mode 7
Point faible :
-Une gestion des sprites complexe et limité sur certain point (8x8,16x16,32x32, 64x64 uniquement , possible de switch que entre 2 taille)
-Un cpu hybride 8/16bits
-Une plus basse résolution
-8ko de RAM seulement disponible rapidement le reste se fait via une instruction plus longue

La MD Point fort :
-Un bon CPU
-jusqu'à 320px par scanline
-Une meilleur gestion des sprites
Point faible :
-La palette et le nombre de couleur
-Un BG en plus pour le hud aurait était appréciable

NT :Après je connais moins la MD , donc je ne dis que ce qui m'a déranger personnellement sur cette console :p

@Tryphon
Pour PCSX2 son but est juste d’émuler les jeux commerciaux , il a pas pour but d’être fidèle a la console ni meme a un CPU, l'alignement c'est presque un détails vu les gros souci d'émulation que j'ai pu relever dessus que ça soit le CPU ou le hard  

[Zarnal]

Justement en parlant du mode 7, que serait il possible de faire de manière soft/hard avec la MD sans la coucher (dans le cadre d'un jeu bien sûr, pas une démo technique) ?

[Invité]

néanmoins pour l'époque le SPC700 est vraiment unique dans son genre  vu qu'il est capable de jouer des Samples 

Commodore l'avait déjà fait sur l'amiga en 85 .

Un cpu hybride 8/16bits

Sur ça je suis pas d'accord, c'est plus la fréquence qui pose problème,la PCE n'a aucun soucis avec son CPU 8bits .
Après si c'est pour avoir des compilos de haut niveau et une facilité de prog en ASM, ok .

Sur MD je rajouterai l'audio et les interruptions en point faible .

Justement en parlant du mode 7, que serait il possible de faire de manière soft/hard avec la MD sans la coucher (dans le cadre d'un jeu bien sûr, pas une démo technique) ?

Tu as la demo style mario kart sur MD, voilà ça donne un bon aperçu.

[Tryphon]

Y'a quoi comme BTA à la SOR / Final Fight sur PCE ?