Le deal à ne pas rater :
Sélection d’ebooks gratuits en français proposée par La Fnac
Voir le deal

MISTer FPGA

Page 6 sur 6 Précédent  1, 2, 3, 4, 5, 6

Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par xinyingho le Lun 27 Jan 2020 - 20:10

@Tryphon a écrit: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 ?

xinyingho
Patient contaminé

Nombre de messages : 794
Date d'inscription : 23/07/2018

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Lun 27 Jan 2020 - 20:17

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

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par lincruste le Lun 27 Jan 2020 - 20:17

Il détaille dans ce post
lincruste
lincruste
Guéri miraculeux

Masculin Nombre de messages : 2300
Age : 40
Localisation : RP
Date d'inscription : 07/06/2014

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Lun 27 Jan 2020 - 20:35

@Zarnal a écrit:
@marmotjoy a écrit:
@Tryphon a écrit: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.


Dernière édition par upsilandre le Lun 27 Jan 2020 - 21:11, édité 1 fois
upsilandre
upsilandre
Infirmier

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Lun 27 Jan 2020 - 20:44

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
upsilandre
Infirmier

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Lun 27 Jan 2020 - 20:54

@marmotjoy a écrit:
@Tryphon a écrit: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.
upsilandre
upsilandre
Infirmier

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Zarnal le Mer 29 Jan 2020 - 17:29

@upsilandre a écrit:
@Zarnal a écrit:
@marmotjoy a écrit:
@Tryphon a écrit: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. Mr. Green
Zarnal
Zarnal
Patient incurable

Masculin Nombre de messages : 1972
Age : 45
Localisation : Tours
Date d'inscription : 27/06/2016

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Mer 29 Jan 2020 - 19:03

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.
upsilandre
upsilandre
Infirmier

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par xinyingho le Mer 29 Jan 2020 - 20:50

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 :/
xinyingho
xinyingho
Patient contaminé

Masculin Nombre de messages : 794
Age : 40
Localisation : Nanterre
Date d'inscription : 23/07/2018

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par upsilandre le Mer 29 Jan 2020 - 21:02

@xinyingho a écrit: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).
upsilandre
upsilandre
Infirmier

Masculin Nombre de messages : 3607
Age : 45
Localisation : val de marne 94
Date d'inscription : 31/05/2015

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par lincruste le Mer 29 Jan 2020 - 21:18

@xinyingho a écrit: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.
lincruste
lincruste
Guéri miraculeux

Masculin Nombre de messages : 2300
Age : 40
Localisation : RP
Date d'inscription : 07/06/2014

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Zarnal le Jeu 30 Jan 2020 - 7:59

@xinyingho a écrit: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.  Mr. Green

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

Masculin Nombre de messages : 1972
Age : 45
Localisation : Tours
Date d'inscription : 27/06/2016

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par xinyingho le Jeu 30 Jan 2020 - 8:17

@upsilandre a écrit: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.

@lincruste a écrit:
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.

@Zarnal a écrit:
@xinyingho a écrit:Si on essayait de faire pareil en software, on ne pourrait pas jouer au jeux tellement ce serait lent :/

Je réponds DICE.  Mr. Green

A une époque, pong ramait lamentablement sur un 3Ghz. MDR  Emulation au transistor.
Clair, Dice est bien le seul à le faire et on voit pourquoi :)
xinyingho
xinyingho
Patient contaminé

Masculin Nombre de messages : 794
Age : 40
Localisation : Nanterre
Date d'inscription : 23/07/2018

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Zarnal le Jeu 30 Jan 2020 - 8:19

@lincruste a écrit:
@xinyingho a écrit: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. Razz

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

J'ai faux ?

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

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. MDR
Zarnal
Zarnal
Patient incurable

Masculin Nombre de messages : 1972
Age : 45
Localisation : Tours
Date d'inscription : 27/06/2016

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Monokrom le Mer 4 Mar 2020 - 0:34

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
avatar
Monokrom
Patient contaminé

Masculin Nombre de messages : 116
Age : 37
Localisation : Finistère
Date d'inscription : 11/05/2014

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par xinyingho le Mer 4 Mar 2020 - 1:20

@Zarnal a écrit:
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. Razz

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.
xinyingho
xinyingho
Patient contaminé

Masculin Nombre de messages : 794
Age : 40
Localisation : Nanterre
Date d'inscription : 23/07/2018

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par slugman le Mer 4 Mar 2020 - 1:44

un exemple de décapsulation fait par furrtek

slugman
slugman
Patient incurable

Nombre de messages : 1729
Date d'inscription : 18/02/2008

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Monokrom Hier à 22:07

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)
avatar
Monokrom
Patient contaminé

Masculin Nombre de messages : 116
Age : 37
Localisation : Finistère
Date d'inscription : 11/05/2014

Revenir en haut Aller en bas

MISTer FPGA - Page 6 Empty Re: MISTer FPGA

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Page 6 sur 6 Précédent  1, 2, 3, 4, 5, 6

Revenir en haut


 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum