Re: MISTer FPGA

[xinyingho]

Encore une fois, il y a des techniques pour gérer l'input lag en software. Ça commence à être implémenté sur émulateurs, ça s'appelle le frame ahead, voir les messages d'Upsilandre qui en parle sur son topic N'ES...

Tu peux donner le lient vers le thread en question ou ça fait parti de son blog ?

[upsilandre]

Je ferais un billet bientot :) (d'ici quelques semaines)

[lincruste]

Il détaille dans ce post

[upsilandre]

Sauf que là, sur les bécanes ou c'est implémentées, ça marche. Avec un émulateur NES, Upsi a mesuré moins de lag que sur le vrai hardware, c'est assez dingue...

par contre attention, il me semble qu'Upsi joue en fenêtre réduite pour arriver à ce résultat, ça peut en rebuter certains.

https://www.blurbusters.com/blur-busters-lagless-raster-follower-algorithm-for-emulator-developers/

Fut un temps ou j'imaginais ce genre de solution mais même si c'est intéressant comme démarche (reproduire au plus prêt le fonctionnement des vrai machines c'est plutot cool) concrètement en situation de jeu c'est se compliquer la vie pour rien car un Run Ahead a 1 suffit a faire aussi bien et ca s’implémente en 2 secondes dans n'importe quelle émulateur. Et ca permet même de faire mieux puisque ca n’empêche pas d'ajouter aussi du frame delay (pas possible avec une émulation beam racing) voir de pousser a 2 ou 3 le Run Ahead si le jeu le permet.
Au final je pense que l'émulation beam racing ne permettrait pas d'égaler exactement l'input lag du vrai hardware car y a toujours potentiellement d'autre petite source d'input lag du coté des inputs ou de l'écran alors qu'avec du Run Ahead tu fais la meme chose (compenser la bufferisation de l'émulateur) tout en laissant la place a d'autre possibilité de réduction d'input lag pour compenser d'autres sources d'input lag et ainsi faire aussi bien que le vrai hardware voir mieux.

[upsilandre]

L'avantage d'une émulation beam racing ca serait par exemple dans un cas comme ma ROM test que j'ai utilisé pour mes mesures et qui est un test zero lag ou je fais le polling des input a chaque scanline et je modifie aussitôt l'affichage en réaction aux inputs. Cette rom test sur une vrai NES donnerait un input lag de 0ms impossible a reproduire avec du Run Ahead mais ca correspond pas du tout a la situation d'un jeu. Un jeu ne poll les input qu'une fois par frame pas 260 fois et puis ne change pas immédiatement l'affichage en réaction a l'input, il construit une image pendant au moins une frame complete avant de l'afficher. Ma ROM test est "zero lag" uniquement parce qu'elle ne fait rien justement, qu'elle n'a pas un jeu a faire tourner. Elle n'est pas représentatif de ce qu'est un jeu (mais pour les mesures c'est plus pratique).
Avec une émulation beam racing on pourrait reproduire ce comportement (a condition aussi de revoir la facon dont sont géré les input en émulation car aucun émulateur de poll les inputs au moment ou le code du jeu le demande. Ils le font qu'une fois en début de Vblank et bufferise ca pour toute la frame et ils ne vont meme pas chercher l'input sur le controleur mais dans le buffer de l'OS) mais ca servirait uniquement dans ce cas particulier pas pour un jeu. Donc la ca dépend vraiment si on veut etre le plus "accurate" ou juste avoir le meilleur input lag. L'émulation beam racing permettrait d'etre encore plus accurate (un peu a la facon MISTer) mais pas d'avoir le meilleur input lag.

[upsilandre]

Sauf que là, sur les bécanes ou c'est implémentées, ça marche. Avec un émulateur NES, Upsi a mesuré moins de lag que sur le vrai hardware, c'est assez dingue...

par contre attention, il me semble qu'Upsi joue en fenêtre réduite pour arriver à ce résultat, ça peut en rebuter certains.

Ca c'est vraiment mon petit bonus maison pour grignoter quelques ms mais c'est dispensable. La combinaison Run Ahead + frame delay suffit pour rivaliser ou supplanter le vrai hardware.
Mais tout ca demande des ressources. Le MISTer ca reste une bonne solution pour avoir un truc a la fois compacte, low-power, accurate et avec un bon input lag.

[Zarnal]

Sauf que là, sur les bécanes ou c'est implémentées, ça marche. Avec un émulateur NES, Upsi a mesuré moins de lag que sur le vrai hardware, c'est assez dingue...

par contre attention, il me semble qu'Upsi joue en fenêtre réduite pour arriver à ce résultat, ça peut en rebuter certains.

https://www.blurbusters.com/blur-busters-lagless-raster-follower-algorithm-for-emulator-developers/

Fut un temps ou j'imaginais ce genre de solution mais même si c'est intéressant comme démarche (reproduire au plus prêt le fonctionnement des vrai machines c'est plutot cool) concrètement en situation de jeu c'est se compliquer la vie pour rien car un Run Ahead a 1 suffit a faire aussi bien et ca s’implémente en 2 secondes dans n'importe quelle émulateur. Et ca permet même de faire mieux puisque ca n’empêche pas d'ajouter aussi du frame delay (pas possible  avec une émulation beam racing) voir de pousser a 2 ou 3 le Run Ahead si le jeu le permet.
Au final je pense que l'émulation beam racing ne permettrait pas d'égaler exactement l'input lag du vrai hardware car y a toujours potentiellement d'autre petite source d'input lag du coté des inputs ou de l'écran alors qu'avec du Run Ahead tu fais la meme chose (compenser la bufferisation de l'émulateur) tout en laissant la place a d'autre possibilité de réduction d'input lag pour compenser d'autres sources d'input lag et ainsi faire aussi bien que le vrai hardware voir mieux.

L'inconvénient, en prenant l'exemple concernant Retroarch c'est que le runahead n'est pas dispo pour le core P-UAE ou Hatari entre autres ( au moins du temps de la 1.7.x ). Si le(s) core(s) ne gère(nt) pas les sauvegardes d'état(s), c'est fichu. Je vais aller voir si il y a eu du neuf.

[upsilandre]

Oui dans Retroarch pour utiliser le RunAhead il faut le support des savestates mais c'est déjà fort que ce soit la seule condition pour ajouter cette fonction a des cores qui a la base ne l'intègre pas du coup c'est des dizaines de cores qui sont devenu subitement compatible avec cette fonction.
Ensuite les émulateurs eux même peuvent ajouter cette fonction. On la retrouve dans Bsnes et quand j'en ai parlé a Sour il me l'a ajouté dans Mesen. C'est pas très compliqué a priori (mais faut effectivement des savestates car une fois que t'as dérouler l'émulation sur une ou deux frames d'avance a destination de l'affichage il faut que l'émulateur puisse revenir a l'état initial de la machine grace a une savestate)

Pour simuler exactement le lag d'une vraie console sur un jeu classique il suffit de mettre 1 en RunAhead pour compenser la bufferisation de l'émulateur (car quand un émulateur émule le GPU il construit l'image dans un buffer alors que le GPU de la vrai machine construit l'image au raster directement sur l'écran) et 2ms de frame delay pour compenser le fait que les émulateurs scan les inputs un peu en avance et les bufferisent aussi (les émulateurs  récupères en général les inputs avant de dérouler la frame donc juste avant le Vblank alors qu'un vrai jeu va plutot interrogé le contrôleur en fin de Vblank voir un peu après)
Avec ca tu as exactement le lag d'une vrai console (la je parle seulement au niveau de l'émulateur, faut ensuite s'occuper du lag du controleur, de l'écran ou de l'OS) sans que ce soit vraiment très exigent en ressource.

[xinyingho]

Très intéressant, du coup les solutions software reste le roi tant qu'on ne dépasse pas les consoles 32 bits :)
J'imagine pas la puissance que doit demander d'ajouter la gestion du run ahead et du frame delay même si c'est relativement simple d'ajouter ça dans un emulateur.

Après, le FPGA garde un avantage côté préservation de l'histoire des jeux vidéo : les émulateurs travaillent au niveau des chipsets alors que le FPGA travaille au niveau le plus bas des transistors. Donc les solutions FPGA peuvent servir de documentation sur le hardware original au niveau de signification du plus bas niveau.
Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

[upsilandre]

Très intéressant, du coup les solutions software reste le roi tant qu'on ne dépasse pas les consoles 32 bits :)
J'imagine pas la puissance que doit demander d'ajouter la gestion du run ahead et du frame delay même si c'est relativement simple d'ajouter ça dans un emulateur.

Le défi d'input lag concerne surtout les machines 8-16bit, ces machines qui fonctionnent au raster et qui donc court-circuitent la bufferisation de l'image. A partir des consoles 32bit on est plus ou moins sur du framebuffer classique et donc l'émulation redevient assez raccord avec ce fonctionnement (reste donc qu'a maîtriser le lag controleur, écran, OS).
Donc dans l'absolu le RunAhead c'est surtout utile pour les console 8-16bit qu'il n'est pas possible d'égaler sans ca contrairement aux autres du coup ca tombe bien car c'est les moins exigeante en ressource.
Mais bon le RunAhead ou le frame delay ca peut aussi servir effectivement aux autres machines si on veut par exemple compenser d'autres sources d'input lag qu'on arrive pas a maîtriser mais ca demande des ressources.

Pour simplifier l'idée c'est d'exploiter le fait qu'en émulation software on peut exécuter le code bien plus rapidement que les machines d'origines ce qui peut servir a compenser les lacunes sur d'autres maillons de la chaîne mais faut des ressources (l'émulation demande deja plus de ressource que le hardware d'origine et exécuter l'émulation en accélérer encore plus).

[lincruste]

Très intéressant, du coup les solutions software reste le roi tant qu'on ne dépasse pas les consoles 32 bits :)
J'imagine pas la puissance que doit demander d'ajouter la gestion du run ahead et du frame delay même si c'est relativement simple d'ajouter ça dans un emulateur.

Après, le FPGA garde un avantage côté préservation de l'histoire des jeux vidéo : les émulateurs travaillent au niveau des chipsets alors que le FPGA travaille au niveau le plus bas des transistors. Donc les solutions FPGA peuvent servir de documentation sur le hardware original au niveau de signification du plus bas niveau.
Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

L'émulation au niveau du transistor avec le FPGA c'est peut-être vrai pour certaines architectures mais c'est loin d'être la règle. Je pense par exemple à la SNES, trente ans après sa sortie on ne sait toujours pas comment fonctionnent les s-ppu.

[Zarnal]

Très intéressant, du coup les solutions software reste le roi tant qu'on ne dépasse pas les consoles 32 bits :)
J'imagine pas la puissance que doit demander d'ajouter la gestion du run ahead et du frame delay même si c'est relativement simple d'ajouter ça dans un emulateur.

Après, le FPGA garde un avantage côté préservation de l'histoire des jeux vidéo : les émulateurs travaillent au niveau des chipsets alors que le FPGA travaille au niveau le plus bas des transistors. Donc les solutions FPGA peuvent servir de documentation sur le hardware original au niveau de signification du plus bas niveau.
Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

Je réponds DICE. 

A une époque, pong ramait lamentablement sur un 3Ghz.   Emulation au transistor.

[xinyingho]

Le défi d'input lag concerne surtout les machines 8-16bit, ces machines qui fonctionnent au raster et qui donc court-circuitent la bufferisation de l'image. A partir des consoles 32bit on est plus ou moins sur du framebuffer classique et donc l'émulation redevient assez raccord avec ce fonctionnement (reste donc qu'a maîtriser le lag controleur, écran, OS).[...]

Merci pour cette précision. C'est vrai que l'architecture CPU-GPU actuel qu'on utilise encore aujourd'hui s'est généralisé côté console avec l'arrivée de la 3D et la génération 32 bits.

L'émulation au niveau du transistor avec le FPGA c'est peut-être vrai pour certaines architectures mais c'est loin d'être la règle. Je pense par exemple à la SNES, trente ans après sa sortie on ne sait toujours pas comment fonctionnent les s-ppu.

On est d'accord. C'est pour ça que j'écrivais au conditionnel avec "les solutions FPGA peuvent servir". Il faut encore retrouver les documents de design originaux ou que des gens décappent ces chipsets et les cartographient au microscope électronique. C'est ce qui a été fait récemment sur le CPU de la Neo Geo.

Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

Je réponds DICE. 

A une époque, pong ramait lamentablement sur un 3Ghz.   Emulation au transistor.

Clair, Dice est bien le seul à le faire et on voit pourquoi :)

[Zarnal]

Très intéressant, du coup les solutions software reste le roi tant qu'on ne dépasse pas les consoles 32 bits :)
J'imagine pas la puissance que doit demander d'ajouter la gestion du run ahead et du frame delay même si c'est relativement simple d'ajouter ça dans un emulateur.

Après, le FPGA garde un avantage côté préservation de l'histoire des jeux vidéo : les émulateurs travaillent au niveau des chipsets alors que le FPGA travaille au niveau le plus bas des transistors. Donc les solutions FPGA peuvent servir de documentation sur le hardware original au niveau de signification du plus bas niveau.
Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

L'émulation au niveau du transistor avec le FPGA c'est peut-être vrai pour certaines architectures mais c'est loin d'être la règle. Je pense par exemple à la SNES, trente ans après sa sortie on ne sait toujours pas comment fonctionnent les s-ppu.

Le dernier article de byuu en parle justement.

Pour le 020 c'est pareil et arrêtez moi si je me trompe les docs techniques sont les mêmes pour tout le monde.

Si j'ai bien compris, les portes logiques ne suffisent pas pour " cloner " la machine d'origine. Il faut également analyser et bien comprendre comment ces dernières interagissent entre elles pour réussir à en faire une implémentation correcte ( depuis les docs techniques, decapping ). Toute explication sérieuse sera la bienvenue.

J'ai faux ?

Edit : après relecture, il semblerait. Le decapping à lui seul serait suffisant avec des scans suffisament grands.

Et si cela devait arriver :

" This would reveal to us all of the internal latches, and truly perfect emulation would now be possible: directly on FPGA emulators, and very rapidly in software emulators as well ".

Edit 2 : je ne sais plus trop du coup, je lis que le decapping seul semblerait ne pas suffire. Cela en reviendrait à valider ma remarque initiale


Ah les joies des infos contradictoires sur internet.

[Monokrom]

Hello. Je m'intéresse au MiSTer depuis quelques temps.

J'ai déjà lu pas mal de contenu.

J'ai toutefois quelques questions d'ordre pratique:
1) est-ce facile d'insérer/retirer la microSD quand l'ensemble est dans un boitier officiel?
2) à quel moment faut bidouiller le fichier .ini ? et comment faire?
3) peut-on éditer le contenu (y compris le .ini) via le RJ45? Comment?
4) à quel moment a-t-on besoin d'un clavier USB?
5) QUID des microSD: taille mini/maxi? format? 1 ou 2 et pourquoi?
6) QUID des saves des jeux? comment ça fonctionne?
7) peut-on mettre le bios que l'on veut pour le core NeoGeo? question subsidiaire: peut-on choisir un bios de manière indépendante pour chaque jeux neogeo? (sans avoir à re-choisir à chaque lancement?)

Merci

[xinyingho]

Si j'ai bien compris, les portes logiques ne suffisent pas pour " cloner " la machine d'origine. Il faut également analyser et bien comprendre comment ces dernières interagissent entre elles pour réussir à en faire une implémentation correcte ( depuis les docs techniques, decapping ). Toute explication sérieuse sera la bienvenue.

J'ai faux ?

Le decapping (décapsulation en français) et la photo/scan des circuits ne suffisent pas car derrière il faut pouvoir retranscrire les millions ou milliards de transistors dans la photo/scan sans faire une seule erreur. Sachant que pour l'instant tout est fait manuellement par quelques tarés pour lesquels j'ai beaucoup d'admiration, c'est très facile d'arriver à quelque chose qui marche pas ou qu'à moitié.

Il y a plusieurs choses à faire proprement :
1/ la décapsulation lui-même qui consiste à enlever la protection plastique pour faire apparaître le circuit imprimé sous-jacent. On décapsule trop profond et bye bye le circuit.
2/ les photos / scans doivent être faits au microscope électronique, difficile de faire la mise au point et d'avoir quelque chose de suffisamment clair tout le temps, surtout si la décapsulation n'a pas donné une surface suffisament plane et sans destruction de transistors.

Certains ont pensé à utiliser de l'IA pour faire le travail de reconnaissance des portes logiques. C'est carrément une bonne idée. Mais ça reste bien difficile à faire.

[slugman]

un exemple de décapsulation fait par furrtek

[Monokrom]

j'ai le MiSTer depuis hier soir

1) est-ce facile d'insérer/retirer la microSD quand l'ensemble est dans un boitier officiel?
pas pris de boitier du coup je sais pas
2) à quel moment faut bidouiller le fichier .ini ? et comment faire?
soit directement sur la microSD, soit en FTP ou en SSH ou en Samba ou encore via le menu du MiSTer
3) peut-on éditer le contenu (y compris le .ini) via le RJ45? Comment?
idem 2)
4) à quel moment a-t-on besoin d'un clavier USB?
juste au tout début pour naviguer vite fait vers la config d'un controleur, après quoi on peut tout faire au controleur.
5) QUID des microSD: taille mini/maxi? format? 1 ou 2 et pourquoi?
les 128 passent, le reste je sais pas encore
6) QUID des saves des jeux? comment ça fonctionne?
work in progress, mais de ce que j'ai lu, il faut activer auto-save et faut juste revenir au menu du core avant de quitter et ça save automatiquement
7) peut-on mettre le bios que l'on veut pour le core NeoGeo? question subsidiaire: peut-on choisir un bios de manière indépendante pour chaque jeux neogeo? (sans avoir à re-choisir à chaque lancement?)
un bios à définir pour le core. le choix d'un unibios est le bienvenu: ça conserve la région et AES/MVS indépendamment pour chacun des jeux (ce que je trouve hyper cool)

[LuckyGame]

Je découvre le travail de Furtek et même si je n'y connais rien, je vois à peu près ce qu'il essaie de faire et ça à l'air complètement dingue et immense.

J'ai une question bête, pourquoi Nintendo, Sega et tous les fabricants de consoles ou de Micro-ordinateurs ne dévoilent pas la documentation précise de création des vieilles machines? Y a prescription non ? De quoi ont-ils peur ? Et s'ils ne l'ont pas encore fait, ils le feront bien un jour pour que cette connaissance ne disparaisse pas à jamais ? ils ne sont pas fous à ce point ?

Pour rester dans le sujet malgré tout, ayant toutes les consoles Analogue, je vais continuer ainsi en espérant qu'ils continuent avec d'autres supports.
Toutefois je ne reste clairement pas fermé à la solution du Mister qui a l'air vraiment géniale.
Par contre ça a été repété plusieurs fois dans ce topic que ça se limitait jusqu'aux 16 bits et pourtant ça parle de Nintendo DS et PlayStation très prochainement...

[jObiwan]

J'ai une question bête, pourquoi Nintendo, Sega et tous les fabricants de consoles ou de Micro-ordinateurs ne dévoilent pas la documentation précise de création des vieilles machines? Y a prescription non ? De quoi ont-ils peur ? Et s'ils ne l'ont pas encore fait, ils le feront bien un jour pour que cette connaissance ne disparaisse pas à jamais ? ils ne sont pas fous à ce point ?

Probablement que les différentes consoles sont brevetées donc sous copyright donc la connaissance ne peut disparaître dans l'absolu. Pour rappel, à leur époque respective, que ce soit Nintendo ou Sega, des procès eurent lieu avec quelques éditeurs.

[xinyingho]

J'ai une question bête, pourquoi Nintendo, Sega et tous les fabricants de consoles ou de Micro-ordinateurs ne dévoilent pas la documentation précise de création des vieilles machines? Y a prescription non ? De quoi ont-ils peur ? Et s'ils ne l'ont pas encore fait, ils le feront bien un jour pour que cette connaissance ne disparaisse pas à jamais ? ils ne sont pas fous à ce point ?

Tu parles du point de vue du conservateur. Il faut voir que Nintendo et Sega restent des entreprises, qui collectivement marchent uniquement du point de vue économique (c-à-d pour faire de l'argent), même si individuellement il y a des gens qui pensent comme nous. Ensuite, il y a plusieurs raisons :
- cette documentation a été perdu avec le temps, les nouveaux projets (où des gusses peuvent effacer les vieilles archives pour faire de la place) et les déménagements.
- on ne leur a jamais demandé directement. Ca a l'air idiot comme ça mais les entreprises collaborent régulièrement avec des organismes de conservation, genre la BnF ou des musées comme le Computer History Museum en Californie.
- quand on leur a demandé, ils n'ont pas le temps ni le budget pour remettre à plat les vieilles archives qui restent. Il y a donc des projets comme SamSho Neo Geo Collection qui permettent de débloquer des budgets justifiant ce travail sur les archives.
- des raisons légales empêchent l'exploitation de ces archives. Les consoles contiennent des composants de plusieurs sociétés et donc ils ne peuvent pas sortir certaines choses de leur propre accord.
- et puis le rétro a le vent en poupe. Du coup, ils se gardent ces trucs sous le coude, le temps de faire des projets mercantiles avec.
Et il peut y avoir d'autres raisons encore.

Pour rester dans le sujet malgré tout, ayant toutes les consoles Analogue, je vais continuer ainsi en espérant qu'ils continuent avec d'autres supports.

Si tu achètes les machines d'Analogue, en espérant qu'ils fassent ce travail d'archivage, c'est une mauvaise raison. Analogue est une société qui est là pour faire de l'argent et qui n'est pas ouvert sur ses méthodes de reproduction de comportement des consoles. Ca a plusieurs implications :
- même s'ils surfent sur le mot FPGA pour justifier le prix de leurs machines, rien ne prouve qu'ils font vraiment du clonage des composants originaux. Il est même plus probable qu'ils mélangent clonage (en utilisant ce qui existe déjà sur le marché) et émulation plus classique sur le reste pour gagner du temps et éviter de dépenser trop.
- même dans l'hypothèse où ils arrivent à faire une reproduction parfaite des consoles, on a le même pb avec Nintendo ou Sega : toute la documentation qui en découle est privé et non-ouvert au public. Donc aucun intérêt.

Donc, du point de vue du conservateur, il y a plus de raisons de soutenir MisTer que de soutenir les produits Analogue. Avec MisTer, les gars fournissent toute la documentation qu'ils retirent de leur travail au public. Bon, après, si on ne suit pas de très près tout ça, c'est impossible de savoir quel core a fait l'objet d'un vrai travail de reproduction fidèle par décapsulation. Ils ont besoin de mettre leur wiki un peu plus clair sur ce processus...

[LuckyGame]

Merci Xing super intéressant. Par contre tu m'as mis un pique dans le cœur quand tu as dit qu'il était possible aussi que ce soit perdu, mon dieu
Après on voit le travail dément de Furtek et franchement j'ignorais vraiment que c'était si compliqué de comprendre le fonctionnement d'une console, je pensais même que n'importe qui avec un peu de connaissances pouvait le faire.
Je me disais ce ne sont que de vieux composants, suffit d'en reprendre des identiques voire meilleurs avec l'évolution, et d'en recréer une. Je pensais que chaque composant avait été reconnu et c'était donc simple de cloner.
Ça me paraît tellement fou qu'en 2020 la snes ou la Megadrive restent un secret, fou et tellement beau quelque part.
Qu'est-ce qui pose tant de problèmes à comprendre les entrailles de ces merveilles.
Je veux dire une bagnole quelqu'elle soit, même une de 1890 on est capable de la reproduire aussi à l'identique si on veut en regardant ses entrailles.
La différence entre une console et une bagnole c'est tout ce qui est virtuel ou que l'on ne voit pas c'est ça ? En gros le code des différents composants ? C'est fou qu'il n'existe pas de logiciel capable de lire chacunes de ces pièces et de récupérer le contenu. Je fais un peu de cartmod et j'ai un programmeur capable de prendre le contenu des roms et d'y injecter ensuite ce que je veux, ça n'existe pas pour d'autres composants ?
Pensez-vous qu'un jour de tels logiciels et outils existeront ?


Sinon pour ce qui est d'Analogue je prends avant tout pour la qualité de leur produit que ce soit sur la forme et le fond.
Je veux dire à l'écran pour moi c'est ultra fidèle voire mieux que l'originale et dans ma tête cela me permet d'être assuré de pouvoir jouer a la nes, Megadrive et Super Nintendo encore un paquet d'années dans les meilleures conditions possibles. J'ai même pris une super nt en double non déballée si un jour la première me lâche.
Je comprends que Mister soit une meilleure solution pour la sauvegarde de nos bonnes bécanes retro, et j'y viendrai je pense, c'est quasiment du même niveau qu'Analogue pour un prix bien moindre et un gain de place conséquent mais je suis aussi attaché au fait de pouvoir mettre mes cartouches et à l'objet et sur ce dernier point y a pas à dire les consoles Analogue envoient du lourd !
La prochaine Analogue Pocket merde c'est juste sublime...

[Titofff1970]

j'ai le MiSTer depuis hier soir

1) est-ce facile d'insérer/retirer la microSD quand l'ensemble est dans un boitier officiel?
pas pris de boitier du coup je sais pas
2) à quel moment faut bidouiller le fichier .ini ? et comment faire?
soit directement sur la microSD, soit en FTP ou en SSH ou en Samba ou encore via le menu du MiSTer
3) peut-on éditer le contenu (y compris le .ini) via le RJ45? Comment?
idem 2)
4) à quel moment a-t-on besoin d'un clavier USB?
juste au tout début pour naviguer vite fait vers la config d'un controleur, après quoi on peut tout faire au controleur.
5) QUID des microSD: taille mini/maxi? format? 1 ou 2 et pourquoi?
les 128 passent, le reste je sais pas encore
6) QUID des saves des jeux? comment ça fonctionne?
work in progress, mais de ce que j'ai lu, il faut activer auto-save et faut juste revenir au menu du core avant de quitter et ça save automatiquement
7) peut-on mettre le bios que l'on veut pour le core NeoGeo? question subsidiaire: peut-on choisir un bios de manière indépendante pour chaque jeux neogeo? (sans avoir à re-choisir à chaque lancement?)
un bios à définir pour le core. le choix d'un unibios est le bienvenu: ça conserve la région et AES/MVS indépendamment pour chacun des jeux (ce que je trouve hyper cool)

Avec du retard j'ajoute ceci:
1) est-ce facile d'insérer/retirer la microSD quand l'ensemble est dans un boitier officiel?
Pas évident avec des ongles court alors j'utilise un stylet de DS, mais du coup plus maintenant car je préfère largement me connecter en FTP.
2) à quel moment faut bidouiller le fichier .ini ?
Quand tu veux une résolution particulière et/ou même des résolutions et autres réglages par bécane.

Par exemple le meilleur compromis pour ma TV Sony Trinitron 4:3 et les 4:3 en général(genre PVM) est le 512x224(j'ai le réglage précis si tu veux)
4) à quel moment a-t-on besoin d'un clavier USB?
Tout ce qui est CORE de micro-ordinateur(c64, Amstrad etc..) tu as besoin d'un clavier, bien que certains cores sont agrémentés d'un VHD paramétré pour automatiser certaines actions uniquement à la manette. Exemple une certaine super release en VHD pour le MSX avec un menu de boot qui te lance direct un loader et tout est à la manette donc.
5) QUID des microSD: taille mini/maxi? format? 1 ou 2 et pourquoi?
Une carte de 512go passe très bien aussi

Je suis toujours fan du MiSTer et au final le core ATARI ST est venu compléter ce qui manquait en rapport au Mist.
CORE très réussi par ailleurs.

Depuis nous avons eu droit à l'implémentation du CORE CD ROM pour la TurboGFX/PC Engine, c'est juste énorme !

[torturedutopian]

Hello,

le MiSTer a un succès de dingue, étant donné que la DE10 est une carte de dév. massivement produite... Pour peu qu'on rajoute juste la SDRAM, c'est très peu onéreux ! (on peut s'en sortir bien au dessous du tarif indiqué ici)

Ca bouge de malade en ce moment : CPS 2 en cours de dév. (par le mec qui a implémenté la CPS 1), Cave 68k en cours, x68000 en cours, core Amiga qui se remet à bouger, le core ST qui déchire (infiniment meilleur que celui du MiST)...+ le mec de la Replay 2 qui a porté son framework sur MiSTer...

Ca permet d'avoir un lag quasi nul (en mode "low lag" / sans buffering, polling USB 1000 Hz, etc.), un rendu clean avec scanlines et mise à l'échelle à coefficient entier (même si perso j'aime bien les combi de pixel shaders sur PC), une synchro précise (fréq. exactes demandées à l'écran).

Après c'est sûr qu'on peut aussi avoir un super résultat en software, pour peu qu'on puisse / sache aligner les planètes (beam racing, run ahead,  etc.), qu'on ait une bonne machine etc. Mais perso j'ai toujours eu un mal de chien à avoir une émulation Amiga vraiment nickelle de chez nickelle (fluidité / réactivité) et là je suis aux anges + le côté minimaliste surtout. Je me retrouve dans la situation dans laquelle j'étais en 1995 sur mon A1200/68030. Minimalisme, pas de distraction, c'est top ! Enfin c'est une niche c'est sûr, y'a plein de gens contents avec une émulation sur Raspberry (moi je pouvais juste pas :-)

Edit : j'ai eu toutes les générations de FPGA Amiga, et jusque là je n'avais réussi à obtenir autant de fluidité sur écran LCD -- rapport aux timing supportés par la spécif. HDMI si je ne m'abuse. Ironiquement, en VGA j'avais bien plus de soucis.

[torturedutopian]

J'oubliais : la PSX arrive très bientôt.
Et la reproduction du son du lecteur de disquette Amiga en branchant un buzzer est très sympa :)

Edit : mais oui dans l'absolu, dans des conditions optimales et avec les nouvelles techniques évoquées plus haut, produire un hardware "custom" très spécifique comme ces machines FPGA n'est pas utile ou n'apporte rien de fondamental, je suppose.. Si ce n'est le minimalisme ou le côté préservation du patrimoine qui va encore plus loin qu'un simple patrimoine de la partie soft des machines. Le minimalisme n'est pas à négliger. C'est ce qui fait que l'immersion est optimale.

C'est comme avoir un smartphone sous Spotify en étant tenté de zapper à chaque piste et en étant interrompu par des notifs ou écouter un CD ou vinyle sur sa platine en étant 100% concentré. Ce n'est pas tant psychologique : l'outil induit des usages spécifiques.

[torturedutopian]

Je cite Orion :

"J'avais acheté un MiST a une époque, et j'ai été très déçu par la sortie vidéo VGA qui n'était absolument pas pixel perfect, on avais du stretching hideux, je l'ai revendu aussi sec"

Oui c'est vrai, j'avais un MiST, j'étais partagé. Ici, pour peu que tu le définisses dans les options, tu as un scaling "entier" + un réglage fin des timing vidéos.

[xinyingho]

Ooh j'avais pas vu ta réponse, désolé du retour tardif :p

Après on voit le travail dément de Furtek et franchement j'ignorais vraiment que c'était si compliqué de comprendre le fonctionnement d'une console, je pensais même que n'importe qui avec un peu de connaissances pouvait le faire.
Je me disais ce ne sont que de vieux composants, suffit d'en reprendre des identiques voire meilleurs avec l'évolution, et d'en recréer une. Je pensais que chaque composant avait été reconnu et c'était donc simple de cloner.
Ça me paraît tellement fou qu'en 2020 la snes ou la Megadrive restent un secret, fou et tellement beau quelque part.
Qu'est-ce qui pose tant de problèmes à comprendre les entrailles de ces merveilles.
Je veux dire une bagnole quelqu'elle soit, même une de 1890 on est capable de la reproduire aussi à l'identique si on veut en regardant ses entrailles.
La différence entre une console et une bagnole c'est tout ce qui est virtuel ou que l'on ne voit pas c'est ça ? En gros le code des différents composants ? C'est fou qu'il n'existe pas de logiciel capable de lire chacunes de ces pièces et de récupérer le contenu. Je fais un peu de cartmod et j'ai un programmeur capable de prendre le contenu des roms et d'y injecter ensuite ce que je veux, ça n'existe pas pour d'autres composants ?
Pensez-vous qu'un jour de tels logiciels et outils existeront ?

La différence entre une voiture et un chipset est qu'avec une voiture, tu peux pratiquement tout démonter à la main et observer les différents éléments à l'oeil nu. Les différences entre des voitures avec 50 ans d'écart n'est vraiment pas énorme mis à part pour tout ce qui est intégration électronique.
Pour un chipset à reproduire en FPGA, il faut du matos spécialisés qui coûte cher et des connaissances en électronique et en programmation pas forcément à la portée de tous. Une voiture est peut-être composée de quelques centaines de pièces détachées, un chipset contient facilement plusieurs dizaines de milliers de portes logiques. Et il n'existera jamais de logiciel pour "lire" le contenu d'un chipset car pour qu'un logiciel puisse faire ça, il faut que le chipset ait une porte d'entrée pour permettre ce genre de lecture. Ca n'existe pas donc il faut se débrouiller avec le décapsulage, des photos prises au microscope électronique et un déchiffrage de ces photos.

Il y a bien un projet d'intelligence artificiel pour déchiffrer automatiquement ces photos. A voir s'ils arrivent à un bon résultat à la fin.

Sinon pour ce qui est d'Analogue je prends avant tout pour la qualité de leur produit que ce soit sur la forme et le fond.
Je veux dire à l'écran pour moi c'est ultra fidèle voire mieux que l'originale et dans ma tête cela me permet d'être assuré de pouvoir jouer a la nes, Megadrive et Super Nintendo encore un paquet d'années dans les meilleures conditions possibles. J'ai même pris une super nt en double non déballée si un jour la première me lâche.
Je comprends que Mister soit une meilleure solution pour la sauvegarde de nos bonnes bécanes retro, et j'y viendrai je pense, c'est quasiment du même niveau qu'Analogue pour un prix bien moindre et un gain de place conséquent mais je suis aussi attaché au fait de pouvoir mettre mes cartouches et à l'objet et sur ce dernier point y a pas à dire les consoles Analogue envoient du lourd !
La prochaine Analogue Pocket merde c'est juste sublime...

Je vois que c'est la passion (un peu aveugle) qui te fait apprécier les produits d'Analogue. Mais pour moi, l'ultra fidélité n'est pas démontrée et les solutions logicielles me suffisent :p
Concernant le fait que tu te sens obligé d'acheter 2 Super NT en cas de panne, c'est un autre point qui me fait préférer MiSTer : comme c'est une solution ouverte, on pourra toujours trouver un moyen pour adapter les cores MiSTer sur les cartes FPGA du futur alors qu'avec Analogue, on est pied et poing liés à ce qu'ils nous proposent.

[cdga]

Si il y avait la possibilité d'acheter des adaptateurs pour lire des cartouches, ça serait quand même vachement plus tentant.

[lincruste]

Ouais moi aussi c'est le truc qui me retient.

[torturedutopian]

Sur la FAQ officielle :

"When will MiSTer support cartridges?
MiSTer will never use physical cartridges.
Not only is it outside the scope of the project which aims to replace the need for having real hardware, it is physically very impractical/impossible given the number of GPIO pins available from the FPGA."

Ce serait quand même possible à mon avis via des adaptateurs mais j'imagine qu'il faudrait dumper la cartouche donc on perd un peu en intérêt. (je ne suis pas spécialiste de la question :)

Cela dit effectivement, même si dans l'absolu il n'y a pas d'intérêt "objectif" dans la mesure où toutes les roms sont trouvables, et que le but des machines FPGA est de se départir une fois pour toutes du matériel vieillissant, je trouve que dans l'usage qui peut en découler, cela a un intérêt : se FOCALISER sur un jeu, réellement l'exploiter à fond, sans tentation d'appuyer sur une touche pour basculer sur un autre jeu en une fraction de seconde. + le plaisir (certes, qui vient d'une construction personnelle / mentale :) d'avoir l'objet et de continuer à faire fonctionner une vieille cartouche.

Déjà, le fait d'utiliser un FPGA plutôt qu'un émulateur permet cela (focalisation, 1 chose à la fois, minimalisme). Cela est renforcé par le fait d'utiliser une cartouche.

Alors évidemment le risque c'est de tomber dans la collectionnite :) D'ailleurs, combien de temps "survit" une cartouche ? Ca se "recappe" comme une machine ?

[torturedutopian]

(ça me rappelle l'armiga ou un truc du genre, qui avait un lecteur de D7 mais au final il fallait extraire la disquette et ensuite elle fonctionnait de la SD... Génial ! Finalement je préfère utiliser une image de disquette + reproduction du son du lecteur comme on peut le faire sous MiSTer

Cela dit, je suis frustré car j'ai récemment acheté plein de nouveaux jeux Amiga en D7...