nesquick - Page 1

Voici nesquick, un émulateur NES pour ti89. Pour l'instant c'est quasiment inutilisable, parce que seul le CPU 6502 est complètement fini. La NES contient en + du CPU un PPU, chargé de l'affichage et plus généralement des entrées/sorties, et il n'est pas encore émulé entièrement dans cette premiere version.
En fait pour l'instant, seule la ROM de démo fournie dans le pack fonctionne.
n'oubliez pas de lire le readme pour avoir tous les détails
nesquick v0.1

Trop bien par contre on voit que un bout de jeu a la mario lol et on peut pas quitter!! Mais c'est super ca promet!!!! Bon courage

Oui c'est normal, ce n'est pas le jeu entier, seulement un background composé des tiles de smb1, qu'on peut scroller a gauche et a droite.
la touche pour quitter je rajouterai ca dans la prochaine version
Petite précision: il faut obligatoirement archiver la rom avant de la lancer, sinon ca ne marche pas (je viens de corriger ca).

C'est joli et prometteur, même si c'est déjà assez lent !
(Il faut quand même ajouter la touche pour quitter de toute urgence !)

Bon courage pour la suite

nesquick sux, libérez groquick !

Salut !
Encore du bon boulot
vu que je ne n'ai pas trop suivi l'evolution de ton concurrent ti-nesulator de Godzil, j'aimerais savoir où tu en es par rapport a lui niveau emulation des chip de la NES et niveau rapidité d'émulation ?

Même question que LionelA rapport a la vitesse, penses-tu que dans les versions futures tu pourrait arriver a un resultat assez bon ??

je sais pas ou Godzil en est avec TI-Nesulator, relis le topic ou demande lui directement. Je me souviens pas trop je, crois qu'il s'est focalisé surtout sur la version PC au début, et déja a l'époque il avait réussi a avoir rapidement un truc utilisable.
Pour ce qui est de la vitesse d'émulation, ca va dépendre des jeux, mais le plus couteux est le PPU. L'ecran doit etre rafraichi en permanence et il va falloir limiter le fps pour que l'emulateur ne passe pas la majorité de son temps dans le moteur l'affichage (le PPU donc).
on verra pour la vitesse, de toute maniere ca sera jamais jouable je pense, pour aucun jeu (si peut-etre un nibbles).
l'important c'est que de faire en sorte que le CPU soit bug-free (et c'est pas du gateau :/)

Si j'avais le temps j'aiderais bien pour la partie émulation (recompiler le code pour 68k, par exemple, ou encore déterminer à l'avance ce qu'il faudra rafraîchir la prochaine fois que l'écran sera redessiné)
Pour ce qui est du PPU, ça serait pas jouable avec des sprites pré-shiftés ? Ou ça demanderait trop de RAM ?

(mon post est aussi valable pour Godzil hein ^^)

nan ca me parait tendu pour pre-shifter les sprites :/
potentiellement n'importe quel tile peut aussi etre un sprite, et il peut y avoir jusqu'a $2000 octets de tiles 8x8 pour un jeu donné (je n'ai pas la doc technique sous les yeux mais je crois que c'est ça)

Mais on peut faire un cache des derniers préshifts, par exemple... Ca pourrait être bien de modifier un ému sur PC pour pouvoir logger les coordonnées d'un sprite + hash de son contenu à chaque affichage, pour voir si ça serait jouable ou pas.

L'émulation du CPU est écrite en ASM pur ou en C ? Elle consomme beaucoup de RAM ?
Tu devrais t'associer avec Godzil, il a déjà fait une bonne partie du PPU il me semble et il était en train de recoder le CPU, mais #vapor#...

En tout cas, bravo, tu m'épates

./11 > le truc aussi, c'est que la nes affiche systématiquement a chaque frame les 64 sprites qui sont peut etre a l'écran. Il y en a sans doute beaucoup moins que ca a dessiner pour une frame donnée, mais je ne crois pas qu'on puisse prévoir le nombre exact qui apparaitra effectivement a l'écran, elle se contente de or-er chacun des sprites sur le background (pas de masques sur NES a ma connaissance).
./12 > le CPU est en asm, je crois que c'est nécessaire pour avoir un truc rapide, toutes les données relatives aux opcodes sont manipulées avec des registres, donc pas de RAM consommée. et Godzil est libre de le reprendre, il n'y aucun probleme pour ca

Bah 64 sprites 8x8 en OR, ça se fait à 30 fps en consommant une faible part du CPU, nan ? Donc c même pas la peine d'essayer d'optimiser violemment...

Tu fais comment pour rechercher les instructions (je veux dire à partir d'un opcode, trouver le code que tu dois exécuter pour l'émuler) ? Une simple table de saut ?

Oui tous les opcodes sont codés sur 1 octet, une table de saut de 256 éléments suffit.

personnelement le goulet d'étranglement est l'émulation du CPU l'affichage de l'écran ne prend guere plus que 20/30% du temps d'éxécution

mais bon mon CPU Asm este en cours de débugguage

Pollux: faire du JIT prendrais trop de temps le CPU de la nes est trop simple pour perdre du temps la dessus et puis les donnée sont trop facilement mélangé a du code donc "recompiler" une rom moyen :/

On peut analyser le code sur PC et recompiler avant l'exécution... Le pb, c que ça ne marchera pas sur 100% des roms (l'analyse peut être incapable de déterminer si une adresse pointe sur l'écran, par exemple), mais ça peut se corriger à la main si ça n'arrive pas trop souvent.

le pbm :/ c'est que le faire a la mains c'est surement aps a la porté de tout le monde
et redistrubuer les roms est deja illégal alors des roms modifié :/ :/


Le pbm de la nes c'est que la mémoire n'est pas linéaire, mais fonctionne par page j'ai peur que la modification du code soit assé complexe :/

pour l'écran c'est pas trop complexe c'est pas un framebuffer et les io sont "well known" comme on dit

Je suis pas sûr de tout comprendre
Il s'agit bien de recompiler des roms nes a partir des binaires pour donner du code 68k ?
Si certaines roms auraient besoin de petites modifs "a la main", il ne serait pas possible de faire des fichiers de modifs pour ces roms ? (comme ça on reste dans la legalité ?)

Godzil :
le pbm :/ c'est que le faire a la mains c'est surement aps a la porté de tout le monde et redistrubuer les roms est deja illégal alors des roms modifié :/ :/

C'est presque légal de faire des patch, et c'est totalement légal de rajouter des cas plus ou moins ad-hoc dans l'analyseur.

Le pbm de la nes c'est que la mémoire n'est pas linéaire, mais fonctionne par page j'ai peur que la modification du code soit assé complexe :/

pour l'écran c'est pas trop complexe c'est pas un framebuffer et les io sont "well known" comme on dit

Oué enfin disons que tout ce qui est conversion espace d'adressage NES -> espace d'adressage TI, il vaut mieux le faire statiquement.

lionelA :
Je suis pas sûr de tout comprendre

sisi

Il s'agit bien de recompiler des roms nes a partir des binaires pour donner du code 68k ?
Si certaines roms auraient besoin de petites modifs "a la main", il ne serait pas possible de faire des fichiers de modifs pour ces roms ? (comme ça on reste dans la legalité ?)

oui et oui

Pollux: regarde du coté des mappeurs

Toute la rom n'est pas mappé en même temps bon ok on peut a la limite garder le principe des pages mais bon

pour ce qui est de la traduction il y aura tjrs le hard a émuler (et puis bcp de jeux jouent avec certain fonctionnement bizzare du hard ce qui risque de passer bizzarement avec traducteur de code. Mais bon meme faire du HLE avec des jeux codé en ASM :/

Alors tu nous fais ça pollux ? cool !
Sinon serieusement, l'avantage de cette technique serait un gain de vitesse (vraiment significatif ?)
Tu prefererais pas faire la meme chose pour gb n&b ? (je sais pas si c'est + ou - puissant qu'une nes)

Sinon derniere question quelle est la taille des roms de nes environ (et gb) ? ca rentre dans une TI non PedRomisée ? (et pourra t'on couper la rom en plusieurs bouts de 64ko ?)

nesquick v0.2
+ on peut lancer une ROM même non archivée (corrigé)
+ corrections de bugs dans le CPU:
-> stack correctement émulée (opcodes JSR/RTS/RTI/PHP/PLP corrigés)
-> opcode AND (absx et absy) corrigé
-> correction d'un bug dans les constantes de nesquick.h (SP_IDX et V_FLAG mal définis)
-> opcode ROR (acc) corrigé
+ PPU
-> registres en accès écriture (W) : 100%
-> $2007 (R) : corrigé
-> affichage de tous les sprites
+ nouvelle rom: nibbles.nes !
- l'écran est trop petit...

Godzil > le code de blocks.nes se charge d'écrire dans le registre PPU $2005, et le moteur d'affichage affiche la name-table scrollée en fonction de la valeur trouvée dans $2005.

oui mais ya un bug (si tu veux je te send la derniere version de tines (pc)) ton scrolling déconne a un certain moment

si tu veux tester ton emu je te conseille

NEStress.nes (un ptit coup de google) et pour l'ecran trop petit une solution rapide de facilité : fenetre glissante sur l'ecran, ie ecran virtuel


edit:

Et pour l'affichage des background & co un tilemap peu fonctionner mais montrera ces limites des que tu va avoir besoin d'un scrolling précis :/ (enfin je te laisse chercher ^^) http://www.nesdev.com est un bon début


edit 2: tu as pas oublié d'émuler le "bug" de RTI j'espere ^^

cool, un peu de "concurrence" positive, ça va nous relancer godzil et on risque d'avoir enfin du résultat

par ça faute 2042 risque d'etre avancé

./28 > oué c'est avec cet esprit de concurrence positive que les choses avancent plus vite
./27 > ok il me semblait bien avoir vu NEStress.nes quelquepart mais je l'ai jamais d/l. Ce soir en rentrant du taf je l'essaye.
Pour le scrolling qui déconne je vois pas a quel niveau? A un moment effectivement, l'affichage scrollait a gauche tout seul une fois toutes les 10 secondes, sans qu'aucune touche n'aie été appuyée, et en désactivant l'émulation du NMI (qui ne servait que pour les palettes pour blocks.nes) le probleme a disparu. Donc apres tout ca a peut etre rapport avec ce que tu me dis sur l'opcode RTI, mais je n'ai connaissance d'aucun bug a propos de cet opcode sur un vrai 6502? (pour JSR ou l'adresse de retour etait en fait addr - 1 ok, pour le bug connu du JMP absolu indirect ok, mais pour RTI?)
et enfin pour le scrolling et tout ce qui est affichage finalement, je verrai bien le moment venu... pour l'instant c'est des séances intenses (=> comprendre nuits blanches) de débuggage du CPU mais avec la version débug de l'ému fceu sur PC les choses sont + faciles je te le recommande d'ailleurs pour le débuggage de ton CPU asm.
./29 >