Re: Mr ToutLeMonde et la programmation NES...

[Invité]

Je suppose que comme tu es obligé d'utiliser des sprites sur SMS tu vas faire clignoter le hud comme un sapin ..

[vingazole]

Sinon il y avait la possibilité de passer en legacy mode (TMS 9918) midframe puisqu'il n'y a pas de scrolling hard dans ce mode : c'est possible techniquement (il y a une démo sur SMSPower, il me semble) mais les couleurs dispos sont très moches, c'est peut-être une option qui a été étudiée et abandonnée.

[upsilandre]

C'est étonnant que tu puisse changer de mode dans la frame sans que ca glitch completement. Ca pourait etre pas mal.

[Invité]

Sinon il y avait la possibilité de passer en legacy mode (TMS 9918) midframe puisqu'il n'y a pas de scrolling hard dans ce mode : c'est possible techniquement (il y a une démo sur SMSPower, il me semble) mais les couleurs dispos sont très moches, c'est peut-être une option qui a été étudiée et abandonnée.

Vu le hud minimaliste en couleurs c'était peut être jouable .

[Stef]

Y'a toujours des bidouilles pour s'en sortir mais c'est vrai que ce VScroll latché à chaque frame, c'est sacrément dommage... ça te prive d’emblée de tout un paquet d'effet. Et surtout techniquement ça ne s'explique pas vraiment... c'est une valeur à lire par scanline, pour un processeur vidéo qui rend ligne par ligne c'est difficile compréhensible.

[Invité]

C'est peut être un héritage du VDP qui à la base n'a pas du tout de scrolling,c'était plus simple d'implémenter le scroll vertical comme ça .
Il me semble aussi d'ailleurs que le zoom de sprites x2 ne concerne que les 4 premiers sprites, ou un truc comme ça, qui était la limite / ligne de l'ancien VDP .

[vincent2105]

GIF TIME!

J'ai donc fais un gif de la grotte SMS.

.

Merci upsilandre pour les GIFs/infos ! Ca donne un aperçu de la complexité de la réalisation, quel casse-tête

[upsilandre]

Un exemple de la difficulté a gérer les priorités quand les 2 parois avec des priorités inverse sont trop proche. Difficile de choisir le flag du sprite.

[Stef]

Oui j'avais remarqué ce problème sur NES, je l'avais souligné plus haut.. c'est un problème qui apparait assez souvent dés qu'il y a pas mal d'éléments de priorité dans les environs, forcément ça ne peut pas toujours passer.
Sinon Tu dis que les mouvements se font sur la base du tile sur NES, mais ce n'est pas le cas pour les sprites. Peut être que les positions finales (arrêtées) sont alignés sur les tiles mais les déplacements des sprites en eux même sont smooth heureusement ^^ (pas comme sur PC-88).

[upsilandre]

oui tu te deplaces de facon smooth (heureusement) entre les intersections d'une grille a la tile (comme un DQ sauf que DQ c'est a la metatile 16x16). Sur SMS t'es completement libre (ce qui change un peu le gameplay).

[vincent2105]

Oh punaise ! j'ai réussi à combiner cette routine de priorité avec une routine que j'avais écrite il y a quelques mois pour créer une map de 89 x 89 écrans !!  

[vincent2105]

Bon, les transitions d'un écran à l'autre sont pas nickel, mais je m'en occuperai plus tard.

Je vais créer une vingtaine de nametables, puis je les utiliserai pour garnir une partie de la map (environ 10 x 5). Chaque nametable fera 1Ko.  Ma routine me permet d'aller en chercher 224 différentes. Sur une map de 89*89 ca semble peu, mais certaines zones seront peu diversifiées (mer par exemple), et d'autres zones seront tout simplement inaccessibles (certains endroits dans zone montagneuse). Après, je peux monter jusqu'à 89*89 mais je dis pas que je le ferai :p

Ca me permettra de vérifier que j'ai pas de bug. Je partagerai la ROM dès que j'aurai fini.

[Invité]

Oh punaise ! j'ai réussi à combiner cette routine de priorité avec une routine que j'avais écrite il y a quelques mois pour créer une map de 89 x 89 écrans !!  

Relis toi les premiers posts de ce topic,histoire de te faire rigoler 

[vincent2105]

Je me souviens bien des débuts oui    toi et Vingazole vous étiez mes sauveurs
Après dans mes galères, y'a eut le coup du pointeur de pointeur (avec toi), puis la configuration du mmc3 (avec upsilandre)... Heureusement qu'il y a GAMOPAT

[Invité]

C'est dans ces moments là que tu vois ta progression 

[upsilandre]

a oui il est quand meme vieux ce topic, j'avais pas vu.

[vincent2105]

Oui, je prends mon temps

Bah justement, c'est pas facile de coder au boulot... J'étais en train de préparer mes nametables entre 2 clients, j'en avais fait une bonne quinzaine, mais... Préalablement, vu que mes tileset sont scindés en fichiers de 1ko, il a fallu que je les repositionne dans nes screentool aux mêmes adresses que dans mes banks. Bah raté, j'ai placé un tileset une ligne trop haut dans nes screen tool, du coup je vous dis pas le bazar quand j'ai lancé ma ROM     Bref j'ai plus qu'a recommencer  !

[upsilandre]

J'ai bien bossé aujourd'hui. J'ai bouclé le hack de Megaman1 dans la journée et le resultat est tres sympa, je vous laisse découvrir

https://drive.google.com/open?id=0B399kteofpYuQlJUeDVXbERfZmc

[vincent2105]

J'utilise fceux, j'ai que l'écran titre sans son.

[upsilandre]

J'utilise fceux, j'ai que l'écran titre sans son.

bisarre moi ca marche sur Fceux

[upsilandre]

J'ai testé sur 5 emulateurs different et ca marche nickel. T'es sure que t'as bien mis le son?

[vincent2105]

Ca y'est !  Ca dépote ! C'est excellent encore une fois 
Par contre avec fceux 2.2.2 ca passe pas chez moi (tes ROMs de keziah passent pourtant), j'ai pu la lancer correctement sur une vieille version : fceuxd sp 1.07

[upsilandre]

J'ai verifié effectivement Fceux 2.2.2 ne gère pas plus de 16 bank en UROM (du coup sur Keziah ca marche mais t'as juste les premieres secondes). C'est étonnant, tous les emulateurs le gère et a priori c'etait le cas des anciennes versions. C'est le cas aussi de la dernière version 2.2.3 que j'utilise.

[vincent2105]

J'ai bien bossé aujourd'hui. J'ai bouclé le hack de Megaman1 dans la journée et le resultat est tres sympa, je vous laisse découvrir  

https://drive.google.com/open?id=0B399kteofpYuQlJUeDVXbERfZmc

Je viens de réécouter, j'adore !   Bizarre que t'aies pas plus de retours  
Hier je voulais mettre le lien de ma rom, mais je vais attendre qu'elle soit un peu plus consistante

[Stef]

J'ai essayé, tout de suite l'intro a plus de gueule
Bien joué, tu as hacké ça super rapidement ! Mon hack sur les voix de Street Figther 2 MD m'avait pris un peu plus de temps :p pourtant je connais bien la machine

[upsilandre]

Ouai ca rend bien. J'aime bien l'anachronisme car Megaman1 est un jeu tres minimaliste (et c'est ca qui etait intéressant aussi, il me fallait un ecran titre statique et sans musique, c'est le cas de ce MM1 donc l'ecran titre est vraiment basique, et fallait aussi un jeu avec des musiques cultes)

Le temps que prend un hack c'est difficile a predire a l'avance je pense, ca depend de sur quoi tu va tomber, c'est la surprise. Et puis cette fois j'avais bien préparer mon environnement la veille, c'etait beaucoup moins du bricolage que les fois précedente pour modifier/inserer du code dans la cartouche original.

Pour le sample j'ai choisie du 22khz car sur ce morceau j'arrivais vraiment pas a percevoir la difference, le flac que j'ai utilisé vient peut etre d'un mp3, difficile a savoir. Et surtout ca me permetait de mettre tout le morceau (3mn10) sur une cartouche 2Mo et c'est ce que je voulais (la configuration UROM 4Mo est pas compatible avec le header iNES classique donc c'est compatible avec tres peu d'emulateur).
Truc marrant c'est qu'avec un format 4bit ca ne rentrait pas, manquait 10 a 15 secondes, du coup mon format 3.56bit a vraiment ete utile car la j'ai meme de la marge.


-- premiere etape c'etait de trouver comment augmenter la capacité de la cartouche sans faire buguer le jeu et son bank switching. heureusement MM1 c'est une configuration UROM (c'etait le bute aussi du choix de MM1) donc tres facile a upgrader. C'est le constat que j'avais fait dès que je m'etais intéressé a ce mapper.
A la base MM1 a 8 bank 16Ko, suffit d'ajouter toutes tes bank entre la 7eme et la 8eme (derniere) bank originel et le jeu n'y verra que du feu. J'ai donc ajouté 120 bank , 119 qui me servent pour les data du sample et une pour le code.

-- Seconde etape trouvé un espace libre dans la bank fixe du jeu original pour y mettre mon bout de code. En UROM y a une bank qui est fixe, qu'on ne peut pas bouger, et qui est donc celle du jeu d'origine. Sachant que la seconde bank du mapping CPU (la seul qu'on peut switcher) je dois la reserver pour les data du sample que je vais bank switcher pendant la lecture ca pose tout de suite un probleme. Ou mettre tout le code?
La bank fixe par definition contient tout le coeur du jeu et est donc bourré a craquer. Heureusement j'ai quand meme trouvé un peu de place dans la toute derniere page de la bank fixe. 224 octets de libre (verifier en faisant une partie complete avec le data/code logger en action).
C'etait pas suffisant car rien que pour la table de delta j'ai besoin de 256 octets + 128 octets pour la table qui gère les bus conflit du bank switching UROM + environ 2 pages (512 octets) de code, en gros me faut pas loin de 1ko.
Du coup j'ai quand meme utilisé ces 224 octets pour mettre la table des bus conflit (128 octet, en 4Mo c'etait 256 octets ce qui aurait ete plus chiant, autre interet des 2Mo) qui est necessaire tout de suite  et le bout de code qui me permet de prendre le controle proprement puis de bank switcher pour récuperer une bank dans laquelle j'ai mis le reste du code que je copie alors en RAM, la seul solution pour pouvoir executer mon code de sampling tout en laissant libre la bank switchable.
Heureusement a l'ecran titre la RAM sert quasiment a rien donc pas dure de trouver de la place (on fiat quand meme quelque test pour verifier que ca pose pas de probleme). Une page de RAM pour la table de delta et les 2 dernière page de la RAM pour le code. Pas oublier de nettoyer toute la RAM avant de rendre la main au jeu.

-- Apres faut trouver a quelle endroit du code originel du jeu je vais placer ma deviation. C'est a dire un jump vers les 224 octet de libre en fin de bank fixe. La ca peut prendre un peu de temps pour trouver le meilleur endroit. Je me suis placé apres la routine nmi et juste avant les test du pad. A partir de la tu prend le controle, faut pas oublier de replacer dans ton code les instructions que t'as ecraser avec ton jump et prevoir aussi un flag pour que le code du sampling ne soit executé qu'une seul fois a l'ecran titre.
Et surtout désactiver l'interruption nmi sinon tu gardera pas longtemps le controle.

-- ensuite j’exécute donc mon code de sampling qui se trouve en RAM. Mais il a fallut quand meme que j'y integre la gestion du pad pour qu'on puisse quand meme lancer le jeu en pressant start comme sur le jeu d'origine. Donc j'ai ajouter une gestion des input dans mon code de sampling ce qui n'etait pas tres difficile en 22khz (j'ai le temps entre 2 samples).
ensuite une fois identifier une pression sur start fallait trouver la meilleur solution pour transmettre cette information directement au jeu originel pour qu'il traite ca lui meme et que ca soit donc vraiment transparent, comme a l'origine. Donc la je suis passé directement par le buffer pad utilisé par le jeu lui meme et je rend alors la main au jeu en sautant la routine qui remplis ce buffer (puisque je l'ai deja fait) et donc la suite ce fait tout seul.

-- dernière etape, quand je rend la main au jeu ne pas oublier de le faire proprement. Réactiver le nmi, replacer la bank originel au bon endroit, effacer la RAM qu'on a utilisé, activer le flag pour indiquer que l'ecran titre est deja passé ect...


Moi j'adore faire ca. Je suis content d'avoir eu l'idée de faire des rom hack, c'est toujours amusant a faire sans te bouffer tout ton temps. Apres c'est vrai que ca n’intéresse personne (toujours pas réussit a trouver  sur un forum un spécialiste de MM2 pour tester mon menuing   ) mais c'est suffisamment amusant a faire pour soi pour qu'on s'en contente et puis tu te fais ton propre set de jeu personnalisé, c'est classe. J'ai deja mon MM1 a moi, mon MM2 a moi, mon Ghost'n Goblins a moi, mon DQ1 a moi   .

[upsilandre]

En video
https://youtu.be/5mvDjXXfBNg

[vincent2105]

Très intéressant tout ça, merci d'avoir pris le temps de tout détailler pas à pas. Tu maitrises bien le sujet. Y'a un passage qui reste encore du chinois pour moi, c'est la table des bus conflicts. J'aimerais bien comprendre de quoi il retourne, quand t'auras un peu de temps pour m'expliquer... :)
edit : y'a bien une page sur le wiki, mais malgré tout, j'arrive pas a concevoir ce qui engendre un bus conflit.

A bus conflict occurs when two logic devices output different values on the same bus line. When two signals are asserted at the same voltage, the one with less impedance generally wins. In the NES, this generally happens when a program writes to a mapper whose registers overlap ROM but the ROM does not shut off its output, causing a potential conflict on the PRG data bus. Most ASIC based mappers include logic to disable the ROM's output enable during writes, putting the ROM's outputs into a high-impedance state and preventing the bus conflict. But many mappers, especially discrete logic mappers, do not.

Bon de toute facon, avec le mmc3 on n'a pas ce problème.

[Stef]

Merci d'avoir pris le temps de bien détailler le processus :) En fait tu t'es quand même bien pris la tête pour ton hack !
Le fait de devoir charger ton code en RAM depuis une bank ROM, pour ensuite l'executer et remettre tout en bon état... C'est loin d'être un hack trivial. Limite mon hack MD pour SF2 est plus simple à mettre en oeuvre, seul l'écriture du driver était peut être un peu tricky (pour se conformer aux specs du jeu).
Tu vas devenir un spécialiste hacking sur NES

[upsilandre]

Très intéressant tout ça, merci d'avoir pris le temps de tout détailler pas à pas. Tu maitrises bien le sujet. Y'a un passage qui reste encore du chinois pour moi, c'est la table des bus conflicts. J'aimerais bien comprendre de quoi il retourne, quand t'auras un peu de temps pour m'expliquer... :)

En fait c'est simple. Pour interagir avec un mapper comme UROM (qui n'est pas vraiment un mapper, juste quelque porte logique) tu dois ecrire dans l'espace memoire réserver normalement a la ROM.
Evidement on ne peut pas ecrire dans la ROM et c'est pas prevu pour mais le bus de donnée et d'adresse qui sert a ecrire est le meme que ce celui qui sert a lire.
Du coup quand le CPU tente d'ecrire dans la ROM juste pour indiquer au mapper la bank que tu veux switcher le bus d'adresse de la ROM est solicité aussi et donc en retour la ROM place sur le bus de donné ce qui se trouve a cette adresse comme si t'etait en lecture en meme temps que le CPU envoi le numeros de bank que tu lui a demandé d'envoyer. Les 2 données sont en concurence simultané sur le bus de donnée et le plus fort en tension l'emporte.

Du coup pour etre sur de ton coup suffit au moment d'ecrire en ROM pour indiquer la bank au mapper d'ecrire a une adresse en ROM qui contient deja la donné que tu veux envoyer du coup les 2 données (celle en ecriture par le CPU et celle en lecture dans la ROM) sont les meme et donc peu importe le conflit.

Donc pour ca faut prevoir une table en ROM qui contient tous les numeros de bank, par exemple si t'as 8 banks tu fais une table a l'adresse $8000 qui contient les data $00, $01, $02, $03, $04, $05, $06, $07
Et quand t'as besoin de bank switcher pour par exemple activer la bank 3 tu fais:
lda #$03
tax
sta $8000,x

Ainsi t'es sur que la valeur que tu va ecrire est aussi la valeur en lecture qui se trouve en ROM a cette adresse.
Maintenant suffit sans doute de pas grand chose pour eviter ce genre de conflit mais la configuration UxROM est tellement basique qu'ils ont pas jugé de consomer un composant discret supplementaire pour par exemple bloqué la ROM quand la pin "write" du CPU est active (a mon avis suffirait d'une seule porte logique supplementaire mais en meme temps suffit de 8 octet de ROM pour regler les bus conflit donc ils ont sans doute considéré que ca valait pas le coup.)
Les vrai mappers gère ce genre de chose, faut vraiment que ca soit tres rudimentaire comme cablage pour avoir ce probleme.

[upsilandre]

Merci d'avoir pris le temps de bien détailler le processus :) En fait tu t'es quand même bien pris la tête pour ton hack !
Le fait de devoir charger ton code en RAM depuis une bank ROM, pour ensuite l'executer et remettre tout en bon état... C'est loin d'être un hack trivial. Limite mon hack MD pour SF2 est plus simple à mettre en oeuvre, seul l'écriture du driver était peut être un peu tricky (pour se conformer aux specs du jeu).
Tu vas devenir un spécialiste hacking sur NES

Sauf que c'est un hack de l'ecran titre donc ca simplifie quand meme les choses. C'est pas du ingame, la je prend le controle total un instant puis ensuite tu rend la main total au jeu. t'as pas besoin d'y aller avec des pincettes. Mais oui c'est jamais vraiment simple meme quand ca en a l'aire.

Prochain hack (pas tout de suite, je vais rejouer un peu) le menuing de Zelda qui a les memes defauts que celui de Megaman2 (en moins génant), j'avais dit que je m'en occuperais donc faut que je le fasse.
Je pourais dire que ca va etre simple mais en faite j'en sais rien, ca dépend vraiment de ce que tu va decouvrir ou pas, c'est toujours la surprise.