Win3x.Org

Windows & DOS Community

3xNES

Répondre   Page 3 sur 5  [ 50 messages ]
Aller sur la page « 1 2 3 4 5 »
Auteur Message
Matthias
Sujet du message : Re: Émulateur NES
Publié : 12 juil. 2014 19:42
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1305
Inscription : 26 mars 2008 23:05
PC Rétro : P4 (NEC), Continental Edison (Celeron)
 
Le CPU peut gérer les sprites, sauf s'il y a de la VROM, autrement dit de la mémoire graphique dans la cartouche. Dans ce cas-là on utilise les données présentes dans la cartouche et on les charge dans la mémoire graphique.

C'est spécifié dans l'en-tête (nombre de pages de CHR) et c'est exactement pour cela que je détecte l'en-tête. Tout le monde fait ça en émulant la NES, car cela va déterminer son comportement.

Il y a aussi les contrôleurs mémoire (MMC) pour accéder à des banques supplémentaires, mais ça ne se fait pas en mapper #0. En effet, quand une ROM dépasse 32Ko de mémoire, on charge les banques supplémentaires depuis la cartouche elle-même afin que le processeur s'en serve ultérieurement grâce à des paramètres spécifiés dans la cartouche. Cela s'appelle le MMC! Multi-Memory Controller, ou Contrôleur Mémoire Multiple.

Pour l'heure j'ai pas trop avancé, je réfléchis un peu à comment émuler les opcodes. Mais je ne pense pas qu'émuler nécessite une précision d'enfer, une coordination impeccable certes. Mais pas forcément de précision.

_________________

[ img ]
Mon blog sur l'avant-garde :arrow: Cliquez ici


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 12 juil. 2014 20:19
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
Je ne sais pas si cela a de l'importance. Déjà c'est une console et elle a du être exploité dans ses moindres recoins donc possible que cela a de l'importance. J'ai lu que l'horloge du CPU était une division exacte de la partie graphique pour X raisons de transfert bidule.

Quoi qu'il en soit, tant que c'est TON CODE, je t'assure que faire de grosses modification c'est facile. En gros tant que tu comprend ce que tu fais. Après je pense que tu fais plus cela pour t'amuser qu'autre chose donc tu pourra toujours faire les modifications tout comme moi aussi car je n'ai pas gérer les timmings.

Pour les Optocodes, c'est une bonne méthode pour apprendre en même temps le fonctionne de la console et plus tard comprendre en cas de plantage. Faut s'y mettre c'est tout :D

_________________

-----------------------------------------
Alienware M18x i7 3840 / CF 7970 / 32Gb 1866Mhz / SSD 256 + Raid 512Gox2
Serveur Minecraft : ASUS portable W90VP T9400 3Ghz CF 4870.


Haut
Profil Citer
Matthias
Sujet du message : Re: Émulateur NES
Publié : 13 juil. 2014 18:27
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1305
Inscription : 26 mars 2008 23:05
PC Rétro : P4 (NEC), Continental Edison (Celeron)
 
Re,

donc si j'ai bien compris, chaque opcode (au nombre de 55: DMP, CPY, CPX, etc.) a plusieurs modes d'adressage, ce qui fait en tout et pour tout 151 instructions valides.
55 opcodes * 13 modes d'adressage - les opcodes qui n'ont pas tous les modes = 151 instructions valides
Et du coup, pourquoi certains opcodes n'ont pas certains modes d'adressage ?!

Je me demande.

_________________

[ img ]
Mon blog sur l'avant-garde :arrow: Cliquez ici


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 01:09
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
C'est une décission en "haut lieu" :lol:

Tu es sur un vieux CPU 8 bits avec peu de registres en interne et si vraiment il manque des modes d'adressage pour certaines instructions cela pourrait venir de là. Il y a aussi des modes d'adressage inutiles et quand tu traitera les instructions tu remarquera aussi que certaines sont identiques pour toi mais séparé ou expliquer. Ensuite tu as des instructions qui n'était pas utiles pour l'époque.

En traitant les 256 instructions tu remarquera probablement aussi certains détails. Sur le 8080/8085 par exemple les trois derniers bits servent souvent à définir le numéro de registre mais des fois le même optocode d'opération sont identiques ( les 5 premiers bits ) et tu t’aperçois alors qu'une autre instruction toute seule est en fin de compte la suite d'une autre avec un autre nom.

Alors oui, je dis bien de traiter 256 instructions quitte à faire beaucoup de copier coller !
Pour le 8080/8085 j'avais trouvé un programme de test de toutes les instructions, cela doit aussi exister pour le 6502.
A l'origine c'était pour détecter les différences entre toutes les marques car OUI il y avait des différences entre chaque marque de 8085 ( le 8080 est rester principalement Intel ).

256 instructions car il y a des instructions secrètes aussi !
Souvent c'est qu'une question de nombres de transistors qui fait que tu va trouver des instructions identiques mais secrètes ( non documentées ) par exemple si une instruction est 100110RR et qu'il y a "personne" en 110110XX alors pourquoi rajouter des transistors pour le bit 6 dans ce cas 100110RR et 110110RR sera identique.

Enfin c'est "logique" par exemple l'instruction RST ( reset ) si elle existe n'a pas besoin d'un mode d'adressage Indirect, immédiat ou autre.

http://www.intel-assembler.it/portale/5 ... atures.asp
Et tu risque d'en trouver d'autres ... sauf que ... Nintendo à fais ses puces donc il pourrait avoir encore des différences.

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

Je comprend ton "tout le monde fait cela" pour la partie graphique. C'est clair qu'il faut émuler que les partes actifs. Donc tout ce qui est de changer une couleur, mettre un pixel d'une couleur peux se traiter en instantané. C'est comme pour le son aussi.

Je comprend aussi le système de bascule pour les banks de la cartouche. C'est du classique.

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

Commence déjà avec un jeu tout petit car même si tu ne gère pas 50% des choses il devrait avoir un résultat. Par exemple un jeu de 8Ko donc pas de bank à changer, probablement peux de sprites ( voir aucun ).

Après si tu veux de l'aide, fait comme moi avec Michel du 77. Ouvre un site pour mettre les fichiers et autres datasheet que tu as déjà rassemblé. Nous pouvons probablement t'aider pour tout les optocodes tant que tu as fais la stucture, par exemple remplir les différents "case of" pour les 256 instructions potentiels.

_________________

-----------------------------------------
Alienware M18x i7 3840 / CF 7970 / 32Gb 1866Mhz / SSD 256 + Raid 512Gox2
Serveur Minecraft : ASUS portable W90VP T9400 3Ghz CF 4870.


Haut
Profil Citer
Matthias
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 02:54
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1305
Inscription : 26 mars 2008 23:05
PC Rétro : P4 (NEC), Continental Edison (Celeron)
 
Merci pour cette proposition d'aide!

Si tu as rien contre, je te mettrai sans doute dans les crédits, car arriver seul à faire un émulateur ça relève de l'exploit :mrgreen:

Rien que de trouver la documentation, c'est demander de l'aide, et donc tout le monde a droit à être cité quelque part.

En tout cas, je remercie déjà:

NESDev - un petit site technique sur la NES
NES Hacker Wiki - un Wiki qui rassemble quelques informations précieuses
DataCrystal - documentation technique très claire
John Pickens - documentation très claire aussi
Mandrix (pour son fascinant Mercury Project et son code clair et très bien documenté sur lequel je me suis basé pendant 8 années)
Don Jarret, David Finch, et Tobias Strömstedt (prononcer Shtreumshtête) pour leur excellent BasicNES
crispysix pour sa documentation (une des premières rédigées dans la langue de Molière)
Évidemment toi, Attilavv, pour tes idées et j'espère bientôt ton soutien ultérieur :mrgreen: ...
Michel et les autres membres de 3x pour leurs idées. Eh oui, rien que ça, ça m'aide. :P

Ce sera dans le "À propos" de 3xNES. S'il daigne marcher.
En tout cas, j'ai déjà programmé la boucle il y a une semaine, manque plus que les Opcodes et on aura un truc.



En tout cas, je vous cache pas ma peur de ne pas être à la hauteur. J'ai déjà vu un émulateur nommé Nintender. Il a été programmé par un mec qui débute aussi en émulation et il a obtenu un résultat épouvantable... Il n'y a qu'une seule ROM émulée qui fonctionne pas trop mal: une démo appelée WAVE. Aucun jeu commercial ne fonctionne, et les autres démos en général n'affichent qu'une bouillie de pixels dégénérés.

Bon on verra... :mrgreen: J'suis pas un programmeur de la dernière pluie non plus, et je sais que les membres me soutiendront!

_________________

[ img ]
Mon blog sur l'avant-garde :arrow: Cliquez ici


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 05:26
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
Aucun problème pour de l'aide ...
Alors il faudrait que tu commence par faire de l'administratif, le travail d'un chef de projet.

Refaire le premier message du topic avec le nécessaire.

- Outil de devellement. Ce qu'il faut ( donc une obligation ) comme logiciel, compilateur, addon et autres pour arriver à compiler dans les mêmes conditions que toi. Comment importer et exporter un projet ... en gros un minimum de procédures.

- Les liens que tu as trouvé sur la documentation et le mieux est directement les liens utiles avec une petite description.


Je veux bien faire le "CPU", les optocodes. J'ai déjà l'expérience avec le 8080/8085.
Même si cela parait long et ####### il y a beaucoup de copier coller.

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

Pour ce qui est de la difficulté :roll:
Oui, il y a les interruptions qui doivent bien fonctionner et comme je te l'ai écris le gros problème des timmings.

Pour commencer, l'idéal serait de trouver une ROM démo avec qu'un "Hello World" rien de plus. Le mieux est d'avoir un programme qui tourne correctement même si il rame beaucoup car optimiser le code vient après, à la fin quand tout est compris et fonctionnel.

Pour l'Alcyane, Michel du 77 m'avait bien expliqué qu'il y avait aucune raison de simuler ou d'émuler le CPU de la carte Floppy. Et il avait 1000 fois raison à un détail près que sur cette machine nous n'avons aucune documentation utilisateur ( j'ai toutes les documentations hyper technique ) au point que cela revient à avoir un IBM PC XT sans disque dur et une centaine de disquettes sans savoir ce qu'il y a dessus, sans savoir quoi écrire ( par exemple DIR, B: ou toto pour lancer toto ). D'où mon idée d'émuler le CPU du contrôleur floppy pour analyser les commandes.

Dans ton cas, c'est un peu différent. Déjà je pense qu'avec 2Ko les programmeurs ont eux l'idée d'utiliser des fois la mémoire vidéo comme mémoire de masse car plus lente. Même si c'était au détriment de la perte de la deuxième page graphique. En absence aussi d'une horlogue temps réel, la possibilité d'utiliser le circuit graphique en programmant une interruption et en faisant un compteur dessus.

Sur l'Alcyane, j'ai mis une semaine à comprendre une centaine d'octets pourtant en local ( sans accès extérieur ) tellement que le code était optimiser. Michel par la suite à apporter des petites corrections et m'a expliquer que c'était "que" pour gagner UN OCTET.

Sur ces anciennes consoles il était nécessaire encore plus qu'aujourd'hui de faire des optimisations !
De nos jours c'est un peu sur les routines équivalentes à DirectX, changer des détails dans le moteur, mais rien de méchant tout reste du standard.


Edit : As tu une vraie NES au moins ? Si oui, un programmateur d'EPROM ou une cartouche programmable ?

Commence par faire tourner cela :
http://www.planetemu.net/rom/nintendo-n ... inciano-pd

_________________

-----------------------------------------
Alienware M18x i7 3840 / CF 7970 / 32Gb 1866Mhz / SSD 256 + Raid 512Gox2
Serveur Minecraft : ASUS portable W90VP T9400 3Ghz CF 4870.


Haut
Profil Citer
Matthias
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 14:25
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1305
Inscription : 26 mars 2008 23:05
PC Rétro : P4 (NEC), Continental Edison (Celeron)
 
Pour émuler les optocodes sans me taper les 151 instructions, j'ai regardé comment faisaient Mercury et BasicNES :

Ils créaient une classe qui contenait tous les noms des Opcodes, et ils ont juste à les référencer dans un Select Case (ou un switch si vous aimez la famille des C)

Ensuite, en fonction de l'opcode, on regarde D'ABORD le nom de l'opcode (CPX), PUIS le mode d'adressage intrinsèquement. En gros on englobe TOUT en fonction du nom.

Ex:

CPX
└ Mode d'adressage 4
└ Mode d'adressage 2
└ Mode d'adressage 3

CPY
└ Mode d'adressage 2
└ Mode d'adressage 6

En gros on a plus que 55 cas à traiter, on regarde juste en second plan le mode d'adressage qu'on obtient automatiquement grâce à une fonction qui détermine en fonction du mode d'adressage voulu.

Et résultat y'a des économies de temps et de mémoire.


Sauf pour Mercury: cet idiot de Mandrix (désolé à lui, mais là c'est maladroit!) a programmé un Select Case sous une valeur STRING: il a mis les noms réels des opcodes! Ca fait ramer à mort le processeur! J'ai 4 en FPS! Je pense que une bonne partie des lags viennent de là...! A ce propos, chez moi, ça va pas mieux: écrire sur Win3x parfois, ça lague tellement sous le navigateur :? :?...

_________________

[ img ]
Mon blog sur l'avant-garde :arrow: Cliquez ici


Haut
Profil Citer
mafia2007
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 15:10
 
 
Matthias a écrit :
Le CPU peut gérer les sprites, sauf s'il y a de la VROM, autrement dit de la mémoire graphique dans la cartouche. Dans ce cas-là on utilise les données présentes dans la cartouche et on les charge dans la mémoire graphique.

C'est spécifié dans l'en-tête (nombre de pages de CHR) et c'est exactement pour cela que je détecte l'en-tête. Tout le monde fait ça en émulant la NES, car cela va déterminer son comportement.

Il y a aussi les contrôleurs mémoire (MMC) pour accéder à des banques supplémentaires, mais ça ne se fait pas en mapper #0. En effet, quand une ROM dépasse 32Ko de mémoire, on charge les banques supplémentaires depuis la cartouche elle-même afin que le processeur s'en serve ultérieurement grâce à des paramètres spécifiés dans la cartouche. Cela s'appelle le MMC! Multi-Memory Controller, ou Contrôleur Mémoire Multiple.

Pour l'heure j'ai pas trop avancé, je réfléchis un peu à comment émuler les opcodes. Mais je ne pense pas qu'émuler nécessite une précision d'enfer, une coordination impeccable certes. Mais pas forcément de précision.
Il serait intéressant de récupérer une ancienne machine et faire tourner l'émulateur sous dos, avec un DD remplit de ROM ! :D


Haut
Citer
Matthias
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 15:25
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1305
Inscription : 26 mars 2008 23:05
PC Rétro : P4 (NEC), Continental Edison (Celeron)
 
Aucun rapport mais bon, ça peut être porté sous DOS j'imagine.

_________________

[ img ]
Mon blog sur l'avant-garde :arrow: Cliquez ici


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 14 juil. 2014 15:44
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
Ben non, c'est lent comme méthode ( même si c'est plus rapide )

Tes opcodes sont en effet une valeur HEX de 00h à FFh ( ou 0 à 255 ) dans ton cas tu va devoir faire des opérations logiques sur tes opcodes à chaque fois. Ensuite, tu REFAIS un autre test et là encore une opération logique.

La VRAIE de vraie meilleur méthode est de partir d'une base ( label ) et d'ajouter ton opcode. Le problème c'est que cela prend plus de place mais niveau rapidité c'est l'idéal. En assembleur c'est facile, tu as tes quatre registre d'adresse 32bits et tu remplace le troisième par l'opcode ce qui te laisse 256 octets pour faire le traitement. En C/C++ c'est pas évident alors dans d'autres langages ... aie aie !

Après il y a le tableau de saut et tu additionne la valeur du tableau avec l'opcode, tu récupére la valeur et tu fais le saut. L'aventage c'est que c'est aussi rapide pour tout le monde.

http://stackoverflow.com/questions/1504 ... table-in-c

Sinon, la plus part des compilateurs remplace les "case of" par une série de "if" les un derrière les autres. Imagine alors le temps qu'il faut pour arriver à la dernière instruction. La solution dans ce cas est que de simple "if" bit par bit, des tests sur les bits mais cela fait toujours 8 tests ! ! !

Pour finir, les langages modernes utilisent beaucoup le principe de fonctions. Donc même une simple addition est une fonction avec ses sauvegardes de registres, ses tests ( des fois ) pour déterminer qu'elle est le code le plus optimiser ( par exemple addition simple, à virgule flotante, >128 bits donc sur plusieurs registres/octets ). Donc il faut vraiment éviter tout appel de fonctions car c'est terribles niveau performance.

Si tu préfère, dans l'industrie il est obligatoire de programmer pour qu'une autre personne puissent reprendre le travail par la suite, pour travailler en équipe et cela 1000 fois au détriment de la vitesse ou de la consommation mémoire.

Pour un émulateur et même sur une machine à +1Ghz ce qui inclus les Core i7 il ne faut plus penser de la sorte.

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

Je ne sais pas si tu as ce lien :
http://www.slack.net/~ant/nes-emu/6502.html

Il utilise la méthode "case of" mais il tri les opcodes en commençant par les plus utiliser.
Et tu pourra voir qu'il gére aussi les timmings ! ! !
Je sais que tu considère cela sans importance mais pourtant c'est nécessaire ! ! !

Toutes ses petits détails c'est la même différence entre un Atom et un Core i3 ! ! !

Tu dois émuler un CPU à 2Mhz ( j'arrondi ) et tu as en gros un CPU avec des cores à 2Ghz.
Tu as donc 2000 instructions ( une instruction 6502 prend minimum deux cycles ) pour émuler une instrution mais aussi le reste, la vidéo, le son ( si c'est du wav ) à traiter et en plus l'OS qui est derrière ( car tu n'es pas sous DOS ).

Je reviens sur la vitesse de traitement du 6502, même un NOP prend deux cycles d'horloge. Un cycle d'horloge est nécessaire pour charger l'opcode et un autre ( minimum ) pour l'exécuté. Tu peux donc considérer sa puissance comme divisé par deux ( nombre de mips ).

Je pense que tu as pas vraiment vu ce qu'il faut faire pour certaines instructions avec le registre de Status. Je pense à un ADC, test si Nul, Test si Zero, Test si Carry et Test si oVerflow. De plus tu es obligé de travailler sur 16bits ( ou 32 car plus rapide pour nos CPUs ) et d'arrondir par la suite la valeur avant de la stocker.

Rien que ces instructions vont te faire perdre du temps et beaucoup !
Et même si c'est programmer hyper proprement car il y a beaucoup de traitement.
La connerie que beaucoup font et que j'ai vu ailleurs est d'utiliser des fonctions comme :
Status_Z ( set ) et Status_Z ( reset ), ADC_RegA () ... uniquement que pour une fonction c'est tout les registres qui sont sauvegardés ( sauf en C++ si l'optimisation est bien réglé ).


Faudrait que je retrouve mon programme :roll: qui est sauvegarde sur une disque externe de 1To :roll:
Edit : avant faudrait que je refais le Windows, machine d'occasion et le Windows même pas refait depuis +de 2 ans :roll:

_________________

-----------------------------------------
Alienware M18x i7 3840 / CF 7970 / 32Gb 1866Mhz / SSD 256 + Raid 512Gox2
Serveur Minecraft : ASUS portable W90VP T9400 3Ghz CF 4870.


Haut
Profil Citer
Afficher : Trier par : Ordre :
Répondre   Page 3 sur 5  [ 50 messages ]
Revenir à « Projets abandonnés » | Aller sur la page « 1 2 3 4 5 »
Aller :