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 !