Win3x.Org

J'avais eu une idée sordide durant mes 12 ans, tant et si bien que je me permets de vous la soumettre.

Dans l'interface graphique, en tant que frontend, créer une interface de Windows XP en plein-écran, avec un bureau et des fenêtres, et genre à la place de "Poste de travail" on aura "Ouvrir une ROM", "Corbeille" = Quitter, etc.

Cela fera vraiment la totale, si Windows est le centre de l'interface en plus xD

Limite du sondage : 10 Juillet 2014 !
Je l'ai raccourci !

J'ai eu beaucoup de mal à trouver un Emulateur qui tourne sur Mac...

Pour la NES? ça m'étonne. Parfois j'ai déjà vu des projets pour Mac.

De toute façon j'aime pas Mac

mafia2007 a écrit :

J'ai eu beaucoup de mal à trouver un Emulateur qui tourne sur Mac...

As-tu essayé Nestopia ? http://nestopia.sourceforge.net/downloads.html

Beau projet ( sens que c'est rare qu'il y a un vrai projet ici ).

J'ai toujours en cours avec Michel du 77 le projet ( de reprendre ) sur l'Alcyane.
A l'époque nous en avons longuement parler et nous étions d'accord pour partir sur un simulateur et non un émulateur.

La différence est qu'un émulateur se commence par la gestion du temps ou du temps réel si tu préfère.
Il faut donc tenir compte de tout les "petits" temps que mettent une instruction à être traité avec les "wait state" des RAMs et des autres puces dans certains cas. En gros dans tout tes routines il faut dans ce cas tenir compte de ce "petit détail" car l'ajouter par la suite devient vite une horreur.

Ensuite, il faut faire attention avec les languages modernes qui ont tendances à considérer que nos machines sont surpuissantes ( sans tenir compte évidemment que nous avons des Go de RAM ) au point d'optimiser la taille du programme au détriment de la vitesse.

Par exemple, faire une fonction AddTime ( 17ms ) va prendre beaucoup de temps pour le CPU à l'échelle d'un émulateur. A l'opposé, la programmation à l'ancienne qui consiste de tout faire pour éviter les sauts, les appels ( là c'est encore pire )

J'ai pas trop compris pourquoi tu as commencé de la sorte.
En principe il faut commencé par créer la RAM et dedans se trouve la RAM vidéo qui est alors à retranscrire dans la zone d'affichage. Le plus simple est alors de "détecter" l'écriture dans cette partie de la mémoire ( ce qui signifie un test pour toute écriture en RAM ) et directement de calcule le visuel.

Cela te permet par exemple de faire une ligne en ajoutant un petit bout de code pour remplir la zone de la RAM en ligne droit ou de faire un autre dessin.

Quand aux entêtes, elles seront lues directement par la ROM interne de la console quand tout commencera à tourner. Sauf si tu veux faire avant un contrôle pour t'assurer que c'est bien une ROM NES.


PS : Le plus long c'est de faire tout les instructions du CPU car là il faut avoir le DataSheet sous les yeux pour savoir ce qu'il se passe dans tout les registres.


Bon courage !

Ben j'ai commencé par l'instanciation des valeurs de la RAM. En gros tout le schmilblick qui pourra m'aider à manipuler la mémoire

Puis j'ai programmé un détecteur d'en-têtes pour pouvoir charger le programme dans la RAM, c'est une étape essentielle: savoir ce à quoi on a à faire! La VROM est prise en charge, mais elle viendra plus tard.

Ensuite j'ai commencé à étudier le fonctionnement d'une ROM: en fait, le fichier est bêtement chargé dans la mémoire et à chaque cycle on lit l'instruction suivante, à partir du program counter (registre PC 16-bits pouvant faire référence à 65536 octets dans la mémoire vive).

Et en dernier, j'ai l'intention de rajouter les opcodes qui agiront sur la mémoire elle-même.

Bon après j'ai pas trop compris, moi j'pense avoir bien commencé mon projet pourtant. Mon frère aussi a tenté de faire un émulateur. Il marchait plutôt bien mais ne rendait aucun graphisme. Il a perdu ses données 1 mois plus tard (disque pété) et l'émulateur a disparu dans les décombres de son ancien disque dur corrompu xD Il utilisait un tableau pour référencer les opcodes. J'ai déjà vu d'autres programmeurs qui utilisaient plutôt des classes avec un groupement des noms d'ailleurs l'un d'eux, Mandrix, qui a fait un ému baptisé Mercury, a codé des classes d'opcodes avec un référencement basé sur une valeur type String, genre "LDA", "CPY", etc. je vous raconte pas la lenteur. Don Jarret avec BasicNES a aussi utilisé des classes mais c'était avec des entiers et des énumérateurs, ça va plus vite.

Je pense opter aussi pour des classes d'Opcodes plutôt qu'une carte, ça a l'air plus plausible.

PS: Je sais pas pourquoi, mais plus j'écris et plus ça rame sur Win3x, c'est fou et terriblement emmerdant.

EDIT:

D'ailleurs voici un ancien site qui contient mes anciens projets d'émulateurs qui remontent à 2008 :

http://dxshadow.e-monsite.com/

Non mais j'étais vraiment à fond à l'époque Je veux bien reprendre l'idée de programmer une palette arc-en-ciel tiens

Cependant si vous voulez bien rigoler, regardez les sources de ce "ShadowNES" vous allez bien rire.

Je me souviens avoir imaginé le rendu à l'époque. Je voulais dessiner pixel par pixel sur un picturebox avec un For et GDI+ (jusque là ça va). Mais c'était tellement lent mdr. La théorie était bien mais maintenant que je suis plus sage en développement, je vais utiliser un rendu via GDI+ (toujours) mais avec une marshalisation mémoire. Ca va péter le feu. En fait, je traduirai les instructions de la NES vers un array de couleurs et Marshal va convertir le tout en une instance Bitmap qui va être affichée dans la fenêtre. Un peu complexe mais très propre et fonctionnel! Mais ça viendra lorsque j'aborderai le PPU

Matthias a écrit :

Ca va péter le feu.

Double rainboom !

Je ne connais pas la NES donc je me base sur :

http://en.wikipedia.org/wiki/Nintendo_E ... ifications

Je ne comprend pas trop ton système d'entête. C'était une console à cartouche, en gros une ROM que tu changeais avant de mettre en route la console. Pour moi tu as qu'à gérer le CPU qui ira lire l'adresse 0000H et donc exécuté le code qui s'y trouve. Sauf si il y a une EPROM de Boot qui commence par initialiser des choses puis va allez ensuite faire un saut sur la cartouche.

De mon coté, j'ai bien avancé sur l'émulateur Alcyane, un système proche d'un PC XT avec plein de carte possible. Je l'ai fais en JAVA. Il est prévu pour être aussi modulaire que la machine au point qu'il faut prévoir plusieurs CPU ( 8080 ou 8085 ) qui tourne en même temps sans être synchrone. Il y a un CPU de base, un CPU pour le lecteur de disquettes, un CPU pour certaines cartes série. Et le système est du type ARRAY donc j'ai aussi prévu de pouvoir lancer X instances. Sur l'Alienware en core i7 @2.8Ghz j'arrivais à faire tourner trois ou quatre instance sans problème et sans monter à 100%.

Michel du 77 qui lui l'a commencé en Borland a fait la même technique que moi. Un simple swith /case. Il suffit de prendre l'instruction qui est pointé par le PC ( Program Counter ) et de la passé par le swith et pour chaque valeur faire le nécessaire. Niveau vitesse il n'y a pas mieux car tu as qu'un seul saut, pas de branchement ( de fonctions ).

La différence entre un SIMULATEUR et un EMULATEUR c'est le respect au mieux du temps, la vitesse d'exécution.
Par exemple, quand tu fais tourner un jeu ancien de XT 8088 sur une machine moderne et que c'est injouable, c'est le principe du SIMULATEUR. De mon coté, Michel m'avait BIEN fait comprendre que sur l'Alcyane cela pourrait faire que du bien si le CPU est "overcloker" à mort.

Dans le cas d'une console ce n'est pas le cas. Les jeux que tu va émulé il faudra qu'il ont une vitesse proche de la console originale. Avec un Dual core actuel pour émuler un petit CPU 8 bit c'est bien trop puissant et il va se retrouver à tourner trop vite. Il faut donc que tu gére le temps réel.

http://www.e-tradition.net/bytes/6502/6 ... n_set.html

Et ici tu as "partout" à coté des instructions vers le bas une colonne CYCLE. C'est le nombre de cycle d'horloge à XMhz que prend chaque instruction.

immidiate ADC #oper 69 2 2
( à la fin 2 donc deux cycle )

zeropage,X ADC oper,X 75 2 4
( à la fin 4 donc 4 cycles )

absolute,X ADC oper,X 7D 3 4*
( ici c'est 4 cycle avec un accès mémoire et donc probablement X Wait State si la mémoire est lente )

Le CPU est à 1.789773Mhz. Il faut trouver si il a un diviseur car beaucoup de CPU de l'époque divisait la clock en interne pour faire ce qui s'appelle un cycle. Et le mieux après est de diviser ce nombre par le nombre de FPS rechercher. SAUF si il est nécessaire de "synchroniser" le CPU avec la vidéo. Par exemple si le CPU veux savoir si il y a un sprite en collision tu ne peux plus te permettre de grosse différence. Sur certains émulateurs le problème est tellement vrai qu'il est nécessaire de faire cela aussi finement que possible comme 1/1000sec ou plus.

---------------------------------------------------------

Sur cette machine, à ce que j'ai compris :

Il y a comme hardware :

- le CPU qui est 6502 ( en gros comme un 8085 que j'ai traité pour mon SIMULATEUR car égale au 8080 )
- 2Ko de RAM ( ram pour les données intermédiares )

http://en.wikibooks.org/wiki/NES_Programming/Memory_Map

Ici tu peux voir qu'il y a des "shadows", en gros des espaces identiques pouvant être adressés à plusieurs adresses. Or à cette époque souvent nous passions par ces "shadows" soit pour différencier certaines fonctions mais avec une adresse différente soit pour gagner une ou plusieurs instructions ce qui à l'avantage soit de gagner en vitesse soit en espace.

http://www.pagetable.com/?p=410

Ici j'ai trouvé ce que je cherchais, lors du "boot" le 6502 commence en FFFC/FFFD. Donc il doit avoir une ROM en fin des 64K d'espace adressable.

http://fms.komkon.org/EMUL8/NES.html#LABC

Ici je trouve que en 8000h - FFFFh se trouve l'espace pour la cartouche. Donc le Boot se fait par la cartouche de jeux directement.

Donc il suffit bien de "rien faire" à part exécuter l'instruction de RESET du CPU qui ira charger la valeur en FFFC/FFFD pour la mettre dans le PC.

Je vois aussi qu'il y a du DMA qui est utilisé par la partie graphique.
Faire attention à la gestion du temps avec cela comme pour les IRQ.

http://en.wikibooks.org/wiki/NES_Programming

Ici, je vois que c'est un système BI CPU et qu'il y a un autre processeur dédié pour la vidéo.
Contrairement au Atari 2600 ou c'était de la VRAM dans la plage d'adresse du CPU, là c'est séparé.
Il y a un canal de communication entre les deux ( adresse 2006h et 2007h ).
A ce que j'ai compris il y aura 2Ko de VRAM.
Le problème c'est les sprites et là c'est la partie CPU qui les gére.
Je pense que tu si commence par ne pas implémenter les sprites tu aura un résultat malgré tout.

Et ici cela ressemble à l'Alcyane, un CPU principale, un canal de discussion avec les autres processeurs.


-------------------------------------


Je me pose une question :

Quand tu démarre la console sans cartouche, tu as quoi à l'écran ?
( car je ne vois pas de ROM interne par exemple pour afficher Nintendo ou "insert cardridge". )

http://obrazki.elektroda.pl/8065347000_1323776847.jpg
Ici pareil ... pas de ROM !