Avancement de jsnesAI

État des chantiers

Bugs d'affichage connus

Astérix (E) — non corrigé (blocage préexistant)

• Ce n'est pas un problème PAL. Mesuré : en NTSC et en PAL la console produit des images identiques octet pour octet ; l'option pal: true ne change rien et ne peut donc pas être le correctif.
• La ROM est un UNROM (mapper 2, CHR-RAM, miroir vertical) qui boucle sur LDA $07 / BEQ à $FEC3, en attendant que la RAM $07 devienne non nulle. Aucune routine ne l'écrit, et le gestionnaire de NMI sort par JMP $C839 avant de la mettre à jour.
• Le comportement est identique sur jsnes 2.1.0 et sur le dépôt amont : ce n'est donc pas une régression de ce fork. Reste à trancher entre dump incomplet et bug historique de jsnes (les trois dumps (E) disponibles se comportent pareil).
• Recommandation : ne pas exposer d'option pal comme « correctif » tant que la cause réelle n'est pas levée.

Punch-Out — corrigé

• Cause : le verrou CHR du MMC2 n'était pas sollicité au bon moment. La cartouche ne voit que les accès du PPU aux tables de motifs, et c'est l'octet de poids fort qui porte l'adresse de déclenchement : $0FD8 exactement pour la fenêtre gauche (une seule ligne de tuile, celle du haut) et la plage $1FD8-$1FDF pour la fenêtre droite (à chaque ligne).
• Le PPU synthétise désormais cette adresse pour chaque tuile de fond et pour chaque sprite : (table + tuile) * 16 + ligne + 8. Le comportement par ligne tombe tout seul des plages du mapper, sans cas particulier.
• Les accès de sprites sont eux aussi signalés, y compris en 8×16 : la table est choisie par le bit 0 du numéro de tuile, et le déclenchement était appliqué avant le dessin (le sprite qui bascule doit encore utiliser l'ancienne banque) et sur toutes les lignes du sprite au lieu de sa première.
• Le cache de motifs par ligne de tuile est invalidé à chaque ligne de balayage pour ces cartouches : sinon la tuile $FD/$FE gardait le motif de la ligne précédente et le public se réduisait à des bandes plates.
• Vérifié contre FCEUmm (EmulatorJS local) : mêmes lignes de cordes, même épaisseur de public, même départ de tapis (ligne 80). Sortie rendue indépendante du découpage du compositeur (0 pixel d'écart).
• Bug au passage : la fenêtre $FD/$FE de mapper9.js utilisait des plages $0FD8-$0FDF / $0FE8-$0FEF au lieu des adresses exactes de la documentation NESdev — sans effet visible, mais faux.

Punch-Out — ancien état (pour mémoire)

• Le public et le ring s'affichaient en tuiles répétées et fausses (bandeau du haut corrompu).
• Cause : le verrou CHR du MMC2 (mutateur $FD/$FE) ne basculait pas au bon moment.

Mappers reconnus

Chaque mapper vit dans son propre fichier et n'est chargé qu'au moment où une ROM le déclare. Un numéro inconnu retombe sur NROM plutôt que de refuser de démarrer.

→ Voir les 256 numéros de mappers NES, un par un (désignation, exemples de jeux, état de l'émulation dans jsnesAI).

0 NROM · 1 MMC1 · 2 UxROM · 3 CNROM · 4 MMC3 · 5 MMC5 · 6 FFE F4xxx · 7 AxROM · 8 MROM · 9 MMC2 · 10 MMC4 · 11 Color Dreams · 12 MMC6 · 13 CPROM · 14 SL-1632 · 15 Multicart · 16 Bandai FCG / LZ93D50 · 19 Namco 163 · 20 Famicom Disk System · 21 VRC4a / VRC4c · 22 VRC2a · 24/26 VRC6 · 25 VRC4 · 34 BNROM · 37 PAL-ZZ (multicart) · 38 PCI556 · 47 NES-QJ (multicart) · 65 Irem H-3001 · 66 GxROM · 69 Sunsoft FME-7 · 71 Codemasters · 79 NINA-03/06 · 85 VRC7 · 90 J.Y. Company · 91 Shenzhen JY · 94 UN1ROM · 118 TxSROM · 119 TQROM · 140/141 Jaleco JF-14 · 153 Bandai FCG + WRAM · 159 Bandai FCG + X24C01 · 180 UNROM · 193 → 11 · 205 JC-016-2 (multicart) · 228 Action 52 · 240 Jing Ke · 241 BxROM

Non couverts, rencontrés dans la collection : 18, 23, 32, 33, 40, 41, 60, 64, 67.

Historique

• 21 OCTOBRE 2026 — session en cours
  Un dossier pour les sauvegardes, et une sauvegarde qui le dit
  « Sauvegarder » passait par un téléchargement, dont le seul signe était une ligne dans la console du navigateur : le téléchargement peut être avalé sans rien dire, et le bouton semblait ne rien faire. Le panneau affiche maintenant ce qui s'est passé.
  Le nouveau bouton « Dossier des sauvegardes » ouvre le sélecteur de dossier du navigateur, et le dossier est retenu d'une session à l'autre : la sauvegarde part directement dedans, et le chargement y lit par défaut, la liste des sauvegardes étant affichée dans le panneau. Sans dossier, les deux boutons gardent leur comportement d'avant.
• 21 OCTOBRE 2026 — session en cours
  Le son de la Namco 163 ne casse plus le jeu suivant
  Le module de son était enregistré dans l'APU et lit la RAM de la puce à travers le mapper. Quand une autre cartouche était chargée, le module restait enregistré alors que le mapper qu'il lisait avait été remplacé : il levait une exception à l'image suivante, et le jeu chargé après un jeu mapper 19 ne démarrait plus. L'APU oublie désormais les modules de la cartouche précédente.
• 21 OCTOBRE 2026 — session en cours
  Mapper 19 : la Namco 163 pour de bon
  Le numéro 19 portait le nom de « Namcot 106 », une puce qui n'a jamais existé sur une carte : le vrai circuit est une Namco 163. La carte était implémentée avec une carte de registres entièrement fausse, si bien que Namco Classic II plantait sur un JMP $FFFF au reset, et que les onze autres jeux de la collection ne montraient qu'un écran noir.
  Les registres sont maintenant à leur place — un bloc de $800 par registre, à partir de $E000 pour les trois fenêtres PRG de 8 Ko, $8800 à $B800 pour les huit fenêtres CHR de 1 Ko, $C000 à $DFFF pour l'arrangement des écrans, $F800 pour la protection d'écriture et le port d'adresse des 128 octets de la puce. L'IRQ arrive quand l'octet bas du compteur boucle : Namco Classic II l'arme juste là où il veut sa ligne de découpe, et avec la lecture NESdev du compteur sur quinze bits l'interruption arrivait des dizaines de milliers de cycles trop tard, et le jeu attendait une interruption déjà passée.
• 20 OCTOBRE 2026 — session en cours
  Mappers 21 et 22, Asterix en couleurs, et le PAL automatique
  Le VRC4 et le VRC2 de Konami partagent leurs registres ; seul le câblage des lignes d'adresse change. Le numéro 21 doit donc répondre au VRC4a et au VRC4c, dont les adressages ne se recouvrent pas, et le numéro 22 au VRC2a, dont le numéro de banque CHR est lu sans son bit de poids faible. Les IRQ sont comptées en cycles CPU, comme sur le VRC4 déjà présent.
  Asterix, lui, sortait avec le ciel orange et le tronc bleu : la palette de vNES est rangée en BGR et le tampon d'image attend du RGB. Le rouge et le bleu étaient donc inversés dans tous les jeux, depuis toujours. Asterix est en outre une cartouche PAL dont les vieux dumps iNES mentent sur le système vidéo ; la détection se fait sur l'en-tête NES 2.0 ou sur le CRC du PRG, et la frame passe à 312 lignes toute seule.
• 20 OCTOBRE 2026 — session en cours
  Mapper 16 : Bandai FCG / LZ93D50, EEPROM 24C02 comprise
  Le numéro 16 recouvre deux circuits Bandai qui partagent le même plan de banques : PRG de 16 Ko à $8000 (quatre bits de registre), dernier banc fixe à $C000, et huit fenêtres CHR de 1 Ko. Le FCG-1/2 place ses registres dans $6000-$7FFF et écrit son compteur d'IRQ directement ; le LZ93D50 les place dans $8000-$FFFF et passe par un verrou. Les deux plages sont décodées, et la dernière utilisée choisit le mode du compteur — aucun mélange n'existe sur une vraie carte.
  Le compteur descend à chaque cycle CPU et l'IRQ part quand il vaut déjà zéro, puis la ligne reste basse jusqu'à l'écriture d'acquittement dans $A : c'est la formulation retenue par Mesen pour que le même compteur convienne aux trois familles Bandai (16, 153 et 159).
  L'EEPROM 24C02 est modélisée au niveau des fronts I2C, pas comme un tableau d'octets : START/STOP, adresse de composant, ACK au neuvième coup, pages de 8 octets qui rebouclent, START répété pour relire. Les écritures sont recopiées dans batteryRamData et rechargées au reset. 12 tests dans test/mappers.spec.js. npm test : 300 verts, 1 ignoré.
• 20 OCTOBRE 2026 — session en cours
  Débordement de page en zéro page : cpu_test5 passe ses 11 tests
  Le vrai cpu.nes de blargg s'arrêtait au test 07-ind_x puis verrouillait le CPU sur un JAM à $0200. La cause était le rebouclage des pointeurs en zéro page : pour (zp,X) et (zp),Y, l'octet haut du pointeur était lu à $0100 (la pile) quand le pointeur commençait à $FF, au lieu de $00. Le test place justement son pointeur à $FF : STA ($FF,X) écrivait donc à $00FF, écrasait le pointeur avec A, puis écrivait à $0002, et le modèle d'instruction copié en $0200 finissait par contenir un JAM.
  src/cpu.js utilise maintenant load16bitZeroPage() pour ces deux modes : l'addition (zp + X) et la lecture du pointeur rebouclent dans la zéro page. Un test de pénalité de page mort a été retiré (le mode (zp,X) n'en a pas). Le bug de page de JMP ($xxFF) était déjà correct, donc 11-special passe aussi.
  4 tests de régression dans test/cpu.spec.js (lecture et écriture par pointeur rebouclé pour les deux modes). cpu.nes affiche désormais « All tests complete » ; apu_test.nes reste à 8/8. npm test : 288 verts, 1 ignoré.
• 20 OCTOBRE 2026 — session en cours
  Horloge APU au cycle près et DMC : apu_test 8/8
  Le compteur de frames ne se contente plus d'avancer d'un cran tous les 14915,5 demi-cycles : il suit le calendrier du matériel (NESdev), en cycles CPU depuis la remise à zéro. Les horloges quart/demi-frame tombent donc exactement à 7457, 14913, 22371 et 29829 cycles, le drapeau d'IRQ est armé sur trois cycles consécutifs (29828-29830) et la gigue est reproduite : une écriture dans $4017 prend effet 3 ou 4 cycles plus tard selon la phase de l'horloge APU.
  Le DMC suit maintenant les mêmes règles : $4013 ne change que la longueur du prochain échantillon (rechargée au démarrage ou à chaque bouclage), une écriture de $4015 avec le bit 4 est ignorée tant qu'il reste des octets, le tampon d'un octet est rempli immédiatement au démarrage (d'où l'IRQ instantanée d'un échantillon d'un octet), une boucle recharge son compteur dès que le dernier octet est lu, et une lecture de $4015 n'efface plus le drapeau d'IRQ DMC.
  apu_test.nes passe ses 8 tests, y compris la gigue, les timings de longueur et les 19 sous-tests DMC. Les sauvegardes d'état antérieures à cette version relancent proprement la séquence de frames au chargement.
• 20 OCTOBRE 2026 — session en cours
  APU : longueurs de note, drapeau d'IRQ et opcodes non documentés
  apu_test.nes échouait au test 1 : l'APU n'était cadencé que si emulateSound était actif, ce qui gelait le compteur de frames, les compteurs de longueur et l'IRQ de frame quand le son était coupé. Il tourne désormais toujours. Le triangle et le bruit rechargeaient leur longueur même quand $4015 les avait désactivés (le matériel ignore la recharge), et une écriture dans $4017 effaçait le drapeau d'IRQ sans condition : seul le bit 6 l'acquitte. Les tests 1 (longueur), 2 (table) et 3 (drapeau) passent ; le test 4 (gigue d'horloge) s'arrête au sous-test 5 et les tests 5-6 demandent une horloge APU au cycle près, le test 7 (DMC) reste partiel.
  Côté CPU, les 256 opcodes étaient déjà décodés, mais deux sommes de contrôle de cpu_test5 étaient fausses : AXS ($CB) modifiait V (il ne touche qu'à N, Z, C) et SHY/SHX ($9C/$9E) utilisaient le poids fort de l'adresse indexée au lieu de l'adresse littérale, sans la corruption de page du matériel. Les tests 02-immediate et 06-abs_xy ne signalent plus d'erreur.
• 20 OCTOBRE 2026 — session en cours
  Diagnostic des faux .nes + aide visible pour le Port Test
  Deux fichiers apu_test.nes et cpu.nes refusaient de se charger : ce n'étaient pas des ROMs mais les pages GitHub du dépôt nes-test-roms enregistrées avec l'extension .nes (elles commencent par <!DOCTYPE html>). Le diagnostic de la page reconnaît maintenant le HTML (et affiche le titre de la page), le ZIP et le GZip, et explique qu'il faut cliquer sur « Raw » avant d'enregistrer.
  Le cartouche Port Test affichait toujours INPUT PORT ERROR 00 00 00 00 : c'est le résultat d'une console nue, le jig NES-INP-01 restant une option. Une note sous la case à cocher et un rappel dans la ligne d'état de la ROM expliquent désormais que INPUT PORT OK demande de la cocher (ce qui réinitialise la console).
• 19 OCTOBRE 2026 — session en cours
  Mapper 20 : Famicom Disk System
  Le FDS complet : 32 Ko de RAM, BIOS 8 Ko, registres $4020-$4033, IRQ timer et lecteur de disquette (blocs, marques, CRC, faces, écriture). Les images .fds se chargent depuis la page, la face se choisit et le disque modifié s'exporte ; la BIOS n'est pas livrée, l'utilisateur fournit son disksys.rom (champ dédié, localStorage ou fichier à côté de la page). 19 tests mocha, dont un démarrage réel de la BIOS avec un disque synthétique.
• 19 OCTOBRE 2026 — session en cours
  Ports manettes fidèles au matériel + Port Test Controller (NES-INP-01)
  Le cartouche Nintendo World Class Service — Port Test affichait INPUT PORT ERROR 00 00 FF 00. Ce n'était pas un bug de l'émulateur : désassemblé, son test lit huit fois $4016 puis $4017 en échantillonnant les bits 3 et 4 (D3/D4 du bus, exposés sur les ports manettes) et compare à $D5/$55/$2A/$AA : c'est la signature du Port Test Controller NES-INP-01, le boîtier de test d'usine qui pilote D3/D4 sur les deux ports. Sans ce jig, une vraie console nue affiche la même erreur, les lignes restant non pilotées.
  Corrigé au passage deux vraies imprécisions du protocole : le strobe maintenu haut recharge le registre (les lectures avançaient au lieu de renvoyer l'état de A), et après le 8^e bit une manette officielle renvoie 1 indéfiniment ($41, open bus compris) au lieu de 0 puis d'un bouclage à 24 lectures. D3/D4 de $4017 ne sont plus forcés par le Zapper quand aucun Zapper n'est branché — l'affichage du cartouche passe de 00 00 FF 00 à 00 00 00 00, exactement ce que montre une console nue. Le jig s'active en option (nes.opts.portTestController, case à cocher dans le panneau, désactivée par défaut) : le cartouche affiche alors INPUT PORT OK. 10 tests dédiés.
• 19 OCTOBRE 2026 — session en cours
  Mapper 37 (PAL-ZZ, le triple cart Nintendo) implémenté
  Super Mario Bros. + Tetris + Nintendo World Cup (Europe) est trois jeux MMC3 sur une seule cartouche, isolés les uns des autres par un registre de banque externe que le MMC3 ne voit que comme sa PRG-RAM : $6000-$7FFF, xxxx xQBB. Q2 devient PRG/CHR A17, et Q0·Q1 forcent A16 haut — d'où trois « cellules » de 64 Ko et une de 128 Ko. La traduction est appliquée aux deux fonctions de chargement de banques du MMC3, ce qui règle aussi les fenêtres câblées $C000/$E000 sans réécrire ses tables. Le verrou est piloté par le bit 1 de $A001 (comme une écriture vers la PRG-RAM), n'est pas relisible, et le bouton Reset le remet à zéro comme la ligne /RESET du CIC. 13 tests dédiés ; le détail de la formule A16 a été vérifié contre le RTL MiSTer (mapper 37 = « European Triple Cart »).
• 19 OCTOBRE 2026 — session en cours
  Mapper 47 (NES-QJ, V'Ball + World Cup) implémenté
  Même famille, forme minimale : Super Spike V'Ball + Nintendo World Cup range deux jeux MMC3 de 128 Ko derrière un seul bit dans $6000-$7FFF. Ce bit est PRG/CHR A17, sans aucune ligne forcée : l'A16 du MMC3 traverse tel quel, d'où des blocs de 128 Ko (seize banques de 8 Ko) au lieu de cellules de 64 Ko. Même traduction par-dessus le MMC3 que le 37, même verrou $A001 bit 1, même remise à zéro au Reset, même registre non relisible. 10 tests dédiés.
• 19 OCTOBRE 2026 — session en cours
  Mapper 205 (JC-016-2, multicarts 15-in-1 / 3-in-1) implémenté
  Le troisième de la famille MMC3-multicart, et le seul avec un vrai câblage propre : deux bits de sélection de bloc dans $6000-$7FFF, soit quatre blocs dont deux de 256 Ko — dans ceux-là, l'A17 du MMC3 circule encore et c'est l'A18 qui est fourni par le registre — et deux de 128 Ko. Les notes NESdev donnent le mapper sous forme de table masque/OU (PRG $1F/$00, $1F/$10, $0F/$20, $0F/$30 ; CHR $FF/$000…$7F/$180) : elle est transcrite telle quelle, et elle explique aussi pourquoi chaque bloc finit sur sa propre dernière banque — c'est ce qui donne à chaque jeu son vecteur de reset. Recoupée avec le RTL MiSTer (mêmes deux lignes d'A17/A18). 13 tests dédiés.
• 17 OCTOBRE 2026 — session en cours
  MMC2 corrigé (Punch-Out) et MMC5 accéléré
  Mapper 9 : le verrou CHR est rappelé par le PPU à chaque accès de motif — tuiles de fond et sprites — avec l'adresse exacte ($0FD8 pour la fenêtre gauche, $1FD8-$1FDF pour la droite) au lieu d'une plage, l'ordre « après le fetch » est respecté, et le cache de tuiles est invalidé par ligne de balayage. Le public, les cordes et le tapis de Punch-Out sont maintenant identiques à FCEUmm. Mapper 5 : les deux jeux de registres CHR sont décodés une fois chacun et la bascule n'est plus qu'un échange de pointeur — 43-55 fps → ~300 fps sur CV3 et Gemfire. Correction au passage d'un rognage des sprites 8×16 (la borne de plage utilisait +8 au lieu de +16 et les trois bornes srcy2 étaient décalées d'une ligne), ce qui rend le rendu indépendant du découpage du compositeur.
• 17 OCTOBRE 2026 — diagnostic
  Analyse de performance MMC5 (mapper 5)
  Profilage V8 : 45 % du temps CPU part dans le changement de banques CHR (462 updateChrBanks()/frame → 3 700 load1kVromBank()), et 29 % dans les re-rendus partiels de sprites qu'il déclenche (1 863/frame au lieu d'un seul). CV3 (E) tombe à 43 fps, sous les 60 requis. Diagnostic : le MMC5 bascule ses deux jeux de registres CHR (fond / sprites) deux fois par ligne, et chaque bascule recopie 8 Ko.
• SESSION PRÉCÉDENTE
  VRC6 (mappers 24 / 26) et son audio réécrits
  Implementation conforme à la doc NESdev. Akumajou Densetsu (J) et ses traductions démarrent, affichent le logo, l'écran de mot de passe et la saisie de nom. Plus de plantage PC -1.
• SESSION PRÉCÉDENTE
  Rangement du dépôt
  48 scripts de diagnostic déplacés de la racine vers tools/, chemins relatifs réécrits, tools/README.md ajouté.
• OCTOBRE 2026
  Mappers 12, 13, 14, 38, 79, 119, 140 et corrections
  MMC6, CPROM, SL-1632, PCI556, NINA-03/06, TQROM et Jaleco JF-11/JF-14. Correction du mapper 66 (bancs PRG de 32 Ko) et du mode 1 Ko du Namcot 106.
• OCTOBRE 2026
  Page index-nes.html et manette mobile
  Nouvelle interface d'émulateur, pavé tactile, configuration clavier et manette, sauvegarde d'état.