Win3x.Org

Windows & DOS Community

3xNES

Répondre   Page 4 sur 5  [ 50 messages ]
Aller sur la page « 1 2 3 4 5 »
Auteur Message
Matthias
Sujet du message : Re: Émulateur NES
Publié : 15 juil. 2014 10:20
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)
 
Je suis en train de référencer les opcodes. C'est #######. :mrgreen: :mrgreen: :mrgreen:

Mais y'a quelque chose que je comprends pas, j'ai regardé dans un autre émulateur pour savoir comment il faisait :

Opcode TXS :
reg_SP = reg_X
NextPC = reg_PC + InstructionCourante.NoBytes
Opcode TXA :
reg_X = reg_A
If (reg_X = 0) Then
    reg_S = reg_S Or Zero_Flag
Else
    reg_S = reg_S And (Not_Zero_Flag)
End If

If (reg_X And &H80) Then
    reg_S = reg_S Or Sign_Flag
Else
    reg_S = reg_S And (Not_Sign_Flag)
End If
Pourquoi un code si simple au début, puis après toute une procédure de comparaison octale ?!
Il y a une raison ?

_________________

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


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 15 juil. 2014 12:51
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
Je ne comprend pas tout avec les "Labels".
Je pense que Reg_S est pour le registre Status ( désolé mais je pense encore en 8080/8085 ).

reg_S = reg_S Or Zero_Flag

C'est un opération rapide pour mettre un bit à ZERO dans le Registre du Status.

If (reg_X And &H80) Then

Ici c'est pour avoir le signe -127 +128 la base de la programmation. En Unsigned c'est 0 +256.
Donc pour avoir le signe il faut le récupérer en Bit 7 :

Sxxx xxxx Binary ( x = 0 ou 1 )



Je vais me pencher sur les Opcodes du 6502 et voir ce que je comprend.
Imagine que mes souvenirs date du SUPER 68000 16/32 bits hyper génial, mémoire linéaire, facile à programmer et tout et tout. Que je suis passé jadis rapidement sur le 8088/8086. Après ce fut l'Alcyane et le 8080/8085 ou il y avait déjà des registres 16 bits et là j'ai l'impression au premier regard qu'il n'y pas sur le 6502. Faut que je regarde ce qu'il y a vraiment comme instructions.

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

Je te conseil de commencer par toi même.
1 - Tu progressera ( vite )
2 - Tu aura probablement beaucoup de mauvaises idées :lol: mais le peu de bonnes idées pourraient être révolutionnaires. Tout progrès ce fait comme cela.
3 - Accepter ce que les autres ont découverts avant toi par la suite si c'est une meilleurs solution, c'est comme accepter de parler Français ( ou Anglais ) dans un jeu au lieu de vouloir faire comme certains l'ont fait en inventant une langue afin de ne pas copier.
4 - Si tu regarde un dictionnaire, un manuel scolaire il y a un (c) en premier page ou en dernière page. Comme quoi l'école est déjà illégale et demande aussi à faire de la copie "pirate". Alors accepte aussi la copie si tu comprend ce qui à été fait ( c'est comme à l'école :D ).

Je crois que tu le fais en Basic. J'ai rien contre ... hein !
Tu dois aussi avoir des opérandes logiques qu'il faut utiliser au maximum ( car tu sera sûr que ce sont des instructions et non des fonctions ). J'aime bien ce code car il est converti directement en instruction assembleur sans rien d'autres.

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

J'ai compris ton histoire d'entête ! :lol: :lol: :lol:
En gros cela reviendrait à créer un fichier image d'une disquette et dans l'entête préciser sont format physique.
Là c'est pour préciser si la cartouche à de la RAM, combien de pages de ROMs avec cette histoire classique de basculement de page et pour extraire les vrais de vrais données.

Encore une fois, c'est l'ignorance de cette machine de mon coté. Sur les Atari 8 bits + console 8 bits le maximum que j'ai vu dans les cartouches c'était 32Ko. Sur l'Alcyane, Rom direct. En gros la taille du fichier permet de tout savoir sur tout :lol:


J'ai trouvé cette ROM :
http://nickmass.com/images/nestest.nes
ici :
http://www.6502.org/tools/emu/

Si c'est une reprise de la méthode utiliser sur le 8080/8085 alors c'est tout bon.
De mon coté, je n'ai pas fais le test, il fallait que je modifie l'affichage pour l'Alcyane et le CPU était fini à 95%, il manquait les instructions qui n'était pas utiliser.

Ha oui, une méthode SIMPLE.
Tu fait afficher une "#######" pour toutes instructions que tu n'as pas fait. Comme cela, tu pourra rapidement avoir un résultat. J'avais fais cela et rapidement j'avais eux un résultat à l'écran.


Donc je vais regarder en détail les opcodes .. hein .. et toi avance malgré tout !

_________________

-----------------------------------------
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é : 15 juil. 2014 15:49
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)
 
Oui j'ai avancé un peu :)))

_________________

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


Haut
Profil Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 15 juil. 2014 22:07
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
Bon avec un CPU à 25 USD c'est un peu normal que je me pose des questions comparer aux Core i7 de l'époque à 179 USD qu'était le 8085 ou le 6800.

http://www.sbprojects.com/sbasm/6502.php

En gros il y a aucun registre !
Le PC ne peux être modifier, aucun mode de saut direct 16 bits, une pile de 256 maximum.
Vraiment une ####### ce CPU ( à part son prix à l'époque ).

http://idoc64.free.fr/ASM/base.htm#TXA

Ici les instructions me semble bien expliqué.

TXS :

Sert donc à charger le registre de pile. La pile c'est pour stocker l'adresse d'appel d'une fonction ( par exemple ). Possible aussi qu'il y a comme les autres des fonctions pour mettre des données sur la pile ) à voir par la suite.

Comme la pile fait que 8 bits ( ce qui m'avait perturbé ) pour charger la pile il faut mettre une valeur dans X puis transférer X dans SP.

Sur le lien tu t’aperçois que dans le tableau des flags c'est vide. Donc l'instruction comme je te l'avais écris au début est rapide, juste un transfert de registre. Ensuite "NextPC = reg_PC + InstructionCourante.NoBytes" j'aurais plus vu une simple incrémentation de reg_PC surtout que c'est une instruction de 1 octet donc un simple reg_PC++ ( en C++ ) est mieux car plus rapide.

Le fait qu'aucun flags est mis à jour vient du fait que c'est une instruction "système" et encore heureux qu'elle ne touche pas aux flags ce qui permet par exemple de changer de pile pour faire un calcul complexe. C'est vite dit, je sais car malheureusement pour en arriver là il y a des chances que d'autres instructions changent les flags.

TXA :

C'est une instruction de calcul. Par exemple tu fais une addition/soustraction et au lieu de faire un test si Zero tu transfert le résultat en X et en même temps tu aura le test du Zero. Cela permet de faire un compteur 16 bits plus simplement .. quoique j'ai pas chercher à programmer sur ce CPU :roll:

Tu as donc le transfert de registre :
reg_X = reg_A

Ensuite dans le tableau à coté de l'instruction tu remarquera que deux flags peuvent être changer.

Le Z :

If (reg_X = 0) Then
reg_S = reg_S Or Zero_Flag
Else
reg_S = reg_S And (Not_Zero_Flag)
End If

et le S :

If (reg_X And &H80) Then
reg_S = reg_S Or Sign_Flag
Else
reg_S = reg_S And (Not_Sign_Flag)
End If

Je suppose que la valeur Sign_Flag = 0000 0001b ce permet de garder la valeur de reg_S tout en forcant le bit 0 à 1. Que la valeur Not_Sign_Flag = 1111 1110b pareil sauf que 1 et 0 donne 0 ce qui permet de mettre le flag à "0".



Bref, pour moi c'est tellement évident que je n'ai pas trop compris le problème.
:lol: :lol: :lol:
Pour moi ce code est bon. Sur les instructions simple comme celui là cela va bien.
C'est sur certaines instructions que cela devient compliquer.

Sinon, les instructions secrètes c'est un peu comme le MMX :lol:
Si j'ai bien compris pour certaines cela permet de faire plusieurs instructions de base.
Il y aura aussi une instruction 6502 qui n'aurait pas été implémenter dans le CPU de la NES ( licence donc après chacun fait ce qu'il veux ). D'où fait Opcode par Opcode avec un gros "break" si tu n'as pas encore traité le cas de ce Opcode. Il t'en manquera probablement un jour, le jour que tu tombera sur une instruction secrète mais au moins tu aura cette alerte pour te le signaler.

Il n'y a pas d'instruction d'échange comme sur le 8080/8085 donc pas de registre temporaire.
Xchg sur le 8085.

Une des particularité du 6502 est qu'il occupe le bus pour allez lire les données ( logique :D ) mais que pendant son traitement le bus est libre ce qui permettait à la base de pouvoir libérer la RAM pour qu'un circuit vidéo puisse lire la VRAM ( partager ) pendant ces intervalles.

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

Attention le registre SP est 9 bits :
http://www.mdawson.net/vic20chrome/cpu/ ... y_1976.pdf
Il semble être fixer à 1 en permanence ... à vérifier.

Enfin, ce n'est plus un CPU mais un prémisse de Micro Controleur ce truc.
La gestion du son, des ports ( Registre interne + circuit pour gérer les manettes ) et encore d'autres choses ont été ajouté.
Ce n'est donc plus un simple CPU au point que le "core" à probablement été modifié lui aussi.

Quitte à ralentir ton code pour le moment, essaye de faire un log avec les adresses ou il y a un accès.
Par la suite, tu pourra faire deux compilations à moins que tu maitrise les directives en mettant alors les zones de tests, de log et autres debug avec le nécessaire pour les directives.

Et je te confirme qu'il faut vraiment compter les timmings !
Rien que pour le son, c'est pas avec ce type de CPU que tu peux programmer une interruption tout les X ms !
Si tu préfère, à l'époque tout tournait dans une boucle quitte à rajouter les fameux NOP ( no operation ) afin d'équilibrer une branche. Par exemple si tu arrive sur un bord de l'écran un "gros" traitement donc dans le cas contraire tout le monde rajoutait X NOP. Et encore des fois, cela ne suffisait pas car certaines instructions prennent 5 cycles et qu'un NOP deux cycles. Là il fallait faire des calculs pour rien faire avec des instructions qui consomme un nombre impaire de cycle.

Le mieux est de prévoir une resynchronisation variable. Tu commence par 1/10 sec ... l'idéal serait probablement autour de 1/120 mais déjà 1/60 serait bien.


Allez courage !

_________________

-----------------------------------------
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é : 15 juil. 2014 22:29
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)
 
C'est compliqué :roll: j'ai pas compris ces histoires de synchronisation, en gros on doit donner un rythme régulier au code? Sinon tout se téléscope et on obtient pas ce qu'on souhaite?

Mandrix est (vraiment!) un bon codeur, il a juste mal exploité certaines parties de VB6. Et crac, ça donne des résultats ####### parfois :mrgreen: Il manque aussi des opcodes dans son émulateur. J'ai pas trop le temps ces temps-ci, je suis à la préfecture pour un stage, mais je verrai ce week-end.


La NES, c'est vraiment un casse-tête Chinois...

Ou devrais-je dire... Japonais?

:lol:

_________________

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


Haut
Profil Citer
Jajan
Sujet du message : Re: Émulateur pour Windows 1.01
Publié : 15 juil. 2014 23:21
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1030
Inscription : 01 mai 2010 19:44
PC Rétro : Mon boulier !
 
J'ai essayé les 2 Alphas de 3xNES, il y a toujours une erreur de OpCode dès que je j'ouvre un fichier NES... :-(

_________________

>>> http://internetometer.com/give/46797
Άγαθῇ τύχῃ
HowTea : Ƹ̵̡Ӝ̵̨̄Ʒ


Haut
Profil Citer
tombcore
Sujet du message : Re: Émulateur NES
Publié : 15 juil. 2014 23:45
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 434
Inscription : 14 janv. 2003 14:50
 
attilavv a écrit :
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 ! ! !
Ce n'est pas totalement exacte. Les compilateurs actuels (c'est le cas pour le C, C++ et C# au moins) implémentent le switch comme une jump-table si les valeurs testés sont plus ou moins contiguës (tolérance de quelques espaces). Par contre si l'intervalle n'est pas continue, on repasse sur une série de test et branchement, dans ce cas il est effectivement plus optimisé de tester les valeurs les plus courantes en premier.

_________________

Tom - Ancien webmaster de Win3x.Org


Haut
Profil Citer
mafia2007
Sujet du message : Re: Émulateur NES
Publié : 16 juil. 2014 11:31
 
 
Matthias a écrit :
Aucun rapport mais bon, ça peut être porté sous DOS j'imagine.
Il y a des émulateurs qui fonctionnent sous Dos...


Haut
Citer
attilavv
Sujet du message : Re: Émulateur NES
Publié : 16 juil. 2014 14:16
Membre inscrit
Hors-ligne
 
Messages : 536
Inscription : 26 déc. 2008 13:22
 
@ tombcore, j'avais entendu parlé de directive sur certains C/C++ pour le faire et merci du renseignement.
@Jajan, des versions Alpha ? tu les trouve où ?


Dans les faits, il y a le signal d'interruption NMI qui vient du GPU tout les 1/50 ( ou 1/60 ) pour synchroniser le jeu sur une vraie console. Et cela serait le seul moment où il est recommandé de modifier la VRAM pour éviter des affichages bizarres.

Ce que j'ignore c'est si le GPU fait que de l'affichage et calcul de collision. Dans ce cas cela ira.
Si il fait plus, comme déplacer les sprites alors là cela va poser des problèmes.
Et là cela sera de vrai de vrai et de vrai gros problèmes !

Dans le cas contraire c'est un peu différent car le CPU est seul maitre à bord et seulement contrôler par le GPU. Ce que je veux dire c'est qu'il doit avoir fini son travail avant le détail d'une image. Les programmeurs eux ont tout fait pour, donc tu peux partir que c'est toujours le cas. Le principe est alors d'avoir un programme principal et une routine d'interruption qui doivent être relativement synchrone sur le même CPU car tout les 1/50 ( j'en ai marre de mettre ou 1/60 ) une interruption viendra déranger ce petit monde.

Si ton émulateur est trop lent : Il risque de ne pas avoir fini l'interruption précédente que déjà voila la nouvelle ! Si elle est remise à Zero en début, tu va rentrer en boucle infini et rapidement la pile sera pleine et de toutes façon le jeu ne pourra s'en sortir. Si c'est à la fin, tu aura une image sur X qui sera traité sans plantage avec un résultat aléatoire.

Si il est trop rapide et que le programme principe gére le son tu entendra déjà la fin de la musique ( ou je ne sais trop quoi si c'est par exemple pour la gestion de la difficulté pour Tetris ) !

D'où pour moi en fin d'Opcode :

- Mettre à jour le PC
- Ajouter X au délai.

En début de cycle, vérifier si le délai est >= au 1/50 et faire le nécessaire.
E plus cela te permet de savoir d'où tu en es avec ton émulateur, si tu dois faire des optimisations ou si tu as vrament de la marge en ajoutant un indicateur de vitesse.

De la sorte tu émule aussi le NMI comme cela. C'est à dire que le GPU vient de finir de dessiner une image et qu'il prévoit le temps de faire remonter le faisceau ( du canon à électron d'un tube cathodique ) en haut.


Je me suis fatigué pour rien :lol: :lol: :lol:

"By implementing a clock cycle counter in the CPU core, it is possible for emulated PPU hardware ..."
http://nesdev.com/NES%20emulator%20deve ... 0guide.txt

Et donc le GPU fait aucun calcul savant, comme du déplacement de Sprite.
Il est donc passif !

Attention à l'erreur de remettre le compte à ZERO !
Il faut faire une soustraction car il est possible que le délai soit dépassé si une instruction longue vient de faire dépasser le délai. C'est peu important :roll: mais à force image par image tu imagine les +1 +2 qui s'accumule :roll:

Ha oui, le NMI, c'est un signal ( une broche, un patte de la puce ) qui reçoit un signal électrique et qui va obliger le CPU à allez charger l'adresse en FFxxH ( à toi de la retrouver ) dans le PC mais avant allez mettre dans la pile l'adresse PC sur la pile pour la sauvegarder. Probablement aussi un flag qui doit bouger ... Bref, pour le moment la priorité étant de te faire admettre la nécessité de gérer les timmings, j'ai pas cherché ces détails que tu connais probablement.

_________________

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


Haut
Profil Citer
Jajan
Sujet du message : Re: Émulateur NES
Publié : 16 juil. 2014 14:19
Membre d'honneur
Avatar de l’utilisateur
Hors-ligne
 
Messages : 1030
Inscription : 01 mai 2010 19:44
PC Rétro : Mon boulier !
 
Pour les versions Alpha, c'est Matthias qui me les as donné, d'ailleurs j'adore les Alpha/Beta/RC et plus !!! :D

_________________

>>> http://internetometer.com/give/46797
Άγαθῇ τύχῃ
HowTea : Ƹ̵̡Ӝ̵̨̄Ʒ


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