Re: Mr ToutLeMonde et la programmation NES...

[Stef]

Haha c'est marrant comme à chaque fois tu vas nous dénicher quelques détails techniques croustillants, perso j'adore
En fait je ne connais pas bien le DMC mais vu la tête du sample on dirait du 1 bit ADPCM avec un delta de +1/-1 par rapport au bit précédent... C'est bien crado quand même et ça limite vachement le rendu des hautes fréquences ou des harmoniques dans un sens X'D
Enfin c'était déjà pas mal d'avoir claquer un canal PCM sur la NES :)
Sinon pour revenir à l'exemple des 2 jeux, j'ai vraiment l'impression que les samples n'ont même pas à vocation à reproduire le même son, sur Batman on voit que le début du sample part en saturation assez rapidement. On a l'impression qu'ils ont voulu créer un son plus explosif / claquant et réaliste dans un sens comparé à celui de Sylius, qui vu sa tête doit sonner plus proprement mais aussi un peu plus synthétique...

[upsilandre]

oui le DMC c'est du DPCM avec un delta 1bit sur 6bit    mais ca c'est le mode supporté en hardware avec le DMA qui se fait automatiquement pour alimenter le registre sans avoir besoin de s'en occuper donc c'est quand meme sympa.
Autrement tu peux aussi faire du vrai PCM 7bit mais tu bouffe ton CPU (mais j'ai prevu tantot de faire un test sur NES et de codé un format DPCM 44.7khz avec un delta 4bit sur 7bit juste pour voir, la machine poura pas faire autre chose ).

Le sample de Batman est surtout tres uniforme contrairement a celui de Silius qui a une evolution et qui est aussi tres propre c'est sure, ca se sent que ca ete récupéré sur un synthé je pense.
Le petit claquement/parasite en debut de sample Batman a cause de la saturation ca fait assez moche quand les samples s'enchaines a une cadence folle (la musique est tres speed).

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

Un peu de silius
https://youtu.be/MKYnHV7Ks_s?list=PL1059BF37B1B0FE79


Mais ce que je préfere dans Silius je crois que c'est leur facon de faire la batterie en melangeant le triangle wave (qui du coup est dispo puisque Sunsoft deplace la basse sur le canal DMC) et le noise.

[Invité]

Belle utilisation de la puce sonore de la nes ..

[vincent2105]

Merci de continuer de nourrir le topic upsilandre

Juste une info que je pense bon de partager... D'une manière générale, je trouvais particulièrement laborieux de créér des backgrounds un tant soit peu variés. D'un coté j'étais content d'avoir découvert que "Nes screen Tool" permettait de convertir un bmp en tileset ou nametable, mais vu que j'utilisais paint pour créer ou convertir une image cela ne me permettait pas de sortir grand chose de bon (problème de palette)  J'ai très récemment découvert "GraphicsGale", qui facilite le travail de toutes parts, et me permet de créer des bmp utilisables dans "nes screen tool". 

[upsilandre]

Tiens stef je cherche des samples lossless type wav de qualité, jusqu'a 96khz si possible. Des samples de voix parlé et de la musique afin d'avoir deja de bon data source pour quand je ferais des test . Si t'en connais ca m'interresse, ca m'evitera de chercher, et si c'est des samples qui ont un rapport avec le jeu video c'est encore mieux.

[upsilandre]

J'ai commencé a m'amuser a sampler sur NES.
J'ai pas reussit a trouver de sample intéressant en 96khz lossless sur le web donc au final je me suis retranché tout simplement sur mes vieux CD audio 44khz (au moins t'es sure que c'est du lossless). 96khz c'etait pour le fun vu qu'il est facile de faire passer un sample a cette frequence sur NES (en etant vraiment extrémiste on peut meme pousser a 256khz mais faut alors utiliser 5 octets par samples et tu te retrouve avec seulement 8 dixieme de seconde de sample sur une cartouche 1Mo) mais c'est pas forcement tres intéressant donc je me suis contenté d'une qualité 44khz et j'ai samplé un bout de CD a moi qui a plus de 20 ans, j'avoue c'est assez drole de faire sortir ca de la NES mais a peine 24 secondes de musiques pour une cartouche 1Mo (l'equivalent de la plus grosse cartouche officiel):
https://drive.google.com/open?id=0B399kteofpYuaGRjVUNiMU5aWlE
Ca sonne quand meme bien.

Ca c'est donc la version 44.7khz en PCM 7bit sans compression qui me sert de reference. Le bute c'est surtout de faire des versions plus economique avec compression, DPCM 44khz avec un delta 4bit puis des versions 22khz PCM, DPCM et surtout ADPCM (avec donc un delta adaptatif). C'est surtout cette version la qui m'interesse car c'est un peu plus compliqué/amusant niveau code et j'aimerais voir ce que ca donne niveau qualité.

Et puis c'etait l'occasion de trifouiller le MMC5 de Nintendo car je voulais au moins 1Mo de PRG-ROM pour mettre le sample donc fallait y passer (faudrait que je regarde si y a pas d'autre laternative de mapper mieux supporté et qui permet 1Mo de PRG). Ca m'a permis de m'amuser a jonglé et tester quelques truc avec ce mapper (tu galère un peu au debut pour bien l'initialiser car y a rien qui marche) et aussi de mieux maitriser les commandes interne a l'assembleur nécéssaire quand tu fait des truc un peu tordu niveau bank swhitching.
En plus ca m'oblige a faire des vas et viens avec Python pour produire les données au bon format ou faire des comparaisons, ca permet de pratiquer un peu, c'est tres bien.

[Stef]

Ah c'est excellent :) Désolé je n'ai pas vu ton précédent message. J'ai un sample en 192 Khz mais bon honnêtement tu n'entends déjà plus de différence au dessus de 44 Khz (perso c'est un peu ma limite, certains doivent monter un peu au dessus) et puis la ROM part trop vite après
La qualité est vraiment pas mal pour du 7 bits, ça passe très bien grâce au haut taux échantillonnage. On entend quand même une différence par rapport au 16 bits mais c'est très correct et très impressionnant d'entendre ça depuis les entrailles d'une NES =)
Sur MD j'ai codé un driver DPCM 4 bits 22 Khz qui mixe 2 canaux en soft sur le Z80, je pense qu'il est possible d'accomplir la même chose sur le 6502 de la NES surtout que le reglage de la bank du MMC5 doit être plus sympa que celui du Z80 sur la MD
J'aimerai bien passer à du ADPCM (en gardant les mêmes specs pour le reste), ça doit être possible si je fais ça bien (avec quelques LUT supplémentaires).
Aussi idéalement j'aimerai bien me faire un driver à très fort taux de compression mono canal @ 22 Khz au moins, genre une version allégé du MP3 (un truc qui tient sur un Z80 @4Mhz)... un taux de compression 1:8 serait pas mal (et bien sûr avec une bien meilleure qualité que du DPCM 1 bit :p).

[vincent2105]

Chapeau upsilandre   Je suis largué, mais c'est très intéressant à suivre, comme d'hab, et le résultat est vraiment top. Je serais curieux de voir si ca fonctionne sur un everdrive (de mémoire, j'avais lu qu'il y avait quelques soucis avec le MMC5), je regarderai à l'occasion.

[upsilandre]

J'aimerais tester sur une vrai NES mais normalement ca devrait pas marcher sur un everdrive car je crois que la limite c'est 512Ko de PRG-ROM.
Cela dit je pourrais utiliser aussi 512Ko de CHR-ROM.
Faudra un jour que j'achete une vrai NES et un everdrive.

[upsilandre]

Ah c'est excellent :) Désolé je n'ai pas vu ton précédent message. J'ai un sample en 192 Khz mais bon honnêtement tu n'entends déjà plus de différence au dessus de 44 Khz (perso c'est un peu ma limite, certains doivent monter un peu au dessus) et puis la ROM part trop vite après
La qualité est vraiment pas mal pour du 7 bits, ça passe très bien grâce au haut taux échantillonnage. On entend quand même une différence par rapport au 16 bits mais c'est très correct et très impressionnant d'entendre ça depuis les entrailles d'une NES =)
Sur MD j'ai codé un driver DPCM 4 bits 22 Khz qui mixe 2 canaux en soft sur le Z80, je pense qu'il est possible d'accomplir la même chose sur le 6502 de la NES surtout que le reglage de la bank du MMC5 doit être plus sympa que celui du Z80 sur la MD
J'aimerai bien passer à du ADPCM (en gardant les mêmes specs pour le reste), ça doit être possible si je fais ça bien (avec quelques LUT supplémentaires).
Aussi idéalement j'aimerai bien me faire un driver à très fort taux de compression mono canal @ 22 Khz au moins, genre une version allégé du MP3 (un truc qui tient sur un Z80 @4Mhz)... un taux de compression 1:8 serait pas mal (et bien sûr avec une bien meilleure qualité que du DPCM 1 bit :p).

Si tu fais du sampling avec le Z80, comme ca se passe les acces aux samples dans la ROM?
Tu reserves un petit buffer (double buffer?) dans la RAM que tu remplis avec des interruptions? le Z80 peut faire des interruptions?

[Stef]

Si tu fais du sampling avec le Z80, comme ca se passe les acces aux samples dans la ROM?
Tu reserves un petit buffer (double buffer?) dans la RAM que tu remplis avec des interruptions? le Z80 peut faire des interruptions?

En fait tu peux accéder à la ROM par banque de 32ko, mais le registre de réglage de la banque est lent (tu écris bit par bit) du coup tu as intérêt à ne pas écrire ce registre pour chaque octet de sample lu. Et du coup oui tu bufferises la lecture. Je le fais avec un buffer circulaire de 4x256 samples dans la RAM du Z80. je n'utilises pas d'interruption, je compte les cycles car il faut entrelacer le code du buffering lecture d'un côté avec l'écriture DAC de l'autre (là tu es bien content d'avoir les 2 sets de registres du Z80 pour ça, très pratique). Je pourrais utiliser le timer du YM2612, ça serait plus simple que compter les cycles... d'ailleurs pour mon prochain driver je compte utiliser cette méthode :)
Sinon le Z80 ne capte que l'interruption verticale sur la MD.

[upsilandre]

Chapeau upsilandre   Je suis largué, mais c'est très intéressant à suivre, comme d'hab, et le résultat est vraiment top. Je serais curieux de voir si ca fonctionne sur un everdrive (de mémoire, j'avais lu qu'il y avait quelques soucis avec le MMC5), je regarderai à l'occasion.

J'ai fais une nouvelle version ou j'ai divisé le sample en 2 morceaux, une partie en PRG-ROM (512Ko) et une autre en CHR-ROM (512ko) a laquelle j'accede au travers du PPU evidement (c'est le moment ou la pochette de disque disparait de l'ecran puisque j'ai besoin d'éteindre le PPU, facile a reperer)
https://drive.google.com/open?id=0B399kteofpYudHNkVjh5ZXVjSjA

Et donc normalement cette version la devrait fonctionner sur l'everdrive (qui est limité a 512Ko de PRG, meme si c'est suffisant pour les jeux officiels je trouve ca un peu domage). Ca m’intéresserait beaucoup de savoir si ca passe car j'acheterais sans doute un jour une NES et un everdrive donc j'aimerais bien que mes ROMs soit compatible (et ne pas avoir a remettre mon nez dans le code ce jour la). J'aimerais ecouter ca sur une vrai NES un jour. Au pire si ca passe pas je pourrais aussi faire une version plus courte sur mapper MMC1.
D'ailleurs en passant par la CHR-ROM je gagne un cycle sur le coeur de la boucle (grace a l’incrémentation automatique du PPU) donc en théorie on pourait monter encore un peu plus haut en frequence qu'avec la PRG-ROM (meme si ca sert a rien vu qu'on est au dela des 100khz).


J'ai pas beaucoup codé sur NES mais je commence a me sentir bien a l'aise pour construire mes ROMs comme je veux, mettre chaque type de data ou de code exactement ou je veux dans le fichier aussi bien que dans le mapping memoire (bank switching) mettre du code n'importe ou (CHR-ROM, PRG-ROM ou meme RAM), bank switcher du code en court d'execution ect...
Sur ce point j'arrive vraiment a faire tout ce qui me passe par la tete sans appréhension et ca c'est cool, ca me parait maintenant limpide. Pour ca c'est important de bien maitriser le fonctionnement du compilateur/assembleur (moi j'utilise asm6), y a pas grand chose de toute facon dans ce genre de compilateur rudimentaire mais ici juste bien comprendre les commandes enum, ende, base, org, align, $ (et le header iNES) et ensuite tu peux faire tout ce que tu veux. Ce genre de petit exercice est tres bien pour ca.

[upsilandre]

Si tu fais du sampling avec le Z80, comme ca se passe les acces aux samples dans la ROM?
Tu reserves un petit buffer (double buffer?) dans la RAM que tu remplis avec des interruptions? le Z80 peut faire des interruptions?

En fait tu peux accéder à la ROM par banque de 32ko, mais le registre de réglage de la banque est lent (tu écris bit par bit) du coup tu as intérêt à ne pas écrire ce registre pour chaque octet de sample lu. Et du coup oui tu bufferises la lecture. Je le fais avec un buffer circulaire de 4x256 samples dans la RAM du Z80. je n'utilises pas d'interruption, je compte les cycles car il faut entrelacer le code du buffering lecture d'un côté avec l'écriture DAC de l'autre (là tu es bien content d'avoir les 2 sets de registres du Z80 pour ça, très pratique). Je pourrais utiliser le timer du YM2612, ça serait plus simple que compter les cycles... d'ailleurs pour mon prochain driver je compte utiliser cette méthode :)
Sinon le Z80 ne capte que l'interruption verticale sur la MD.

Ca c'est quand meme sympa que le Z80 ait un acces direct a la ROM. Mais du coup le partage bus/rom avec le 68000 ce fait comment? le Z80 peut bloquer le 68000 le temps qu'il a besoin?

[vincent2105]

salut upsilandre, je viens de tester ta ROM sur  mon everdrive, et malheureusement, rien n'en sort, juste un écran gris. Je me suis fait avoir une paire de fois à cause d'un header mal défini, je tacherai de regarder aussi de mon coté si ca vient pas de là (dans la page ROM info j'ai : PRG : 32, CHR : 64, Memory : ex RAM)

[upsilandre]

Il te met Memory ext RAM? Tu sais pourquoi?
apres c'est du MMC5 donc peut etre que ca coince a cause de ca (mais bon j'utilise pas de features avancé, ca devrait passer).
Merci quand meme. Faudra que je m'equipe un jour, c'est quand meme plus marrant.

[upsilandre]

J'ai vu que dans le header y avait le onzieme octet qui etait "unofficial" mais dont l'un des bit peut etre utilisé pour indiquer la presence de RAM (et de facon inversé, faut l'activer pour indiquer l'absence de RAM) donc je me dis peut etre que l'everdrive utilise cette octet "unofficial" du header mais meme si c'est le cas je vois pas pourquoi ca ferait planter (a part si l'utilisation de 512ko de CHR et PRG ne laisse plus de place pour l'extension de RAM)
J'ai activé ce flag sur cette version: https://drive.google.com/open?id=0B399kteofpYudHNkVjh5ZXVjSjA

[vincent2105]

Non je sais pas, d'ailleurs je viens de corriger mon post, c'est "ex ram". 
Comme tu dis c'est surement du au fait que tu utilises le mmc5, le fabricant (krikzz) reconnait que ce mapper n'est que partiellement supporté (je n'ai pas regardé en détail)..
Dans tous les cas, si tu veux que je te teste des roms, y'a qu'à demander
Voir son programme tourner sur NES, c'est la cerise sur le gateau. 
Sinon, dans quelques temps je viendrai surement te solliciter à mon tour. J'ai bien envie de programmer le zapper..

EDIT : Je viens de voir ton message, et j'ai retesté ta Rom, mais c'est pareil :/ et j'ai toujours les mêmes infos rom.

[upsilandre]

Bon tanpis
Quand je ferais la version ADPCM 22khz (qui prend 4x moins de place) je le ferais en MMC1 pour voir.

Sinon, dans quelques temps je viendrai surement te solliciter à mon tour. J'ai bien envie de programmer le zapper..

Ca peut etre rigolo mais ca va pas etre facile a mon avis.

[upsilandre]

Une ultime version ou j'ai tenté d'initialiser un maximum de registres du MMC5 pour voir mais j'y crois pas trop:
https://drive.google.com/open?id=0B399kteofpYudHNkVjh5ZXVjSjA

[vincent2105]

C'est bon ça marche 

[upsilandre]

cool merci
C'est donc peut etre lié a la facon dont l'everdrive initialise le MMC5 comparé a l'emulateur (faut dire que le MMC5 a plus de registre que l'integralité de la NES, c'est dingue).
Ca m’étonnait que ca fonctionne pas car le support du MMC5 est quand meme annoncé a l'exception de fonction tres particuliere comme l'audio mais moi je faisais que du bankswitching, ne pas supporter ca ca revient a ne pas supporter du tout le MMC5.

Du coup je risque de te faire chier une derniere fois :) faut savoir maintenant qu'elle est précisement le truc qui posait probleme (la configuration du compteur de scanline, de l'ex RAM interne, de la RAM PRG...) car j'ai modifié plusieurs registres. Ca pourra toujours nous servir de bien comprendre MMC5.
Je te ferais une compile de 4 ou 5 versions de la ROM tout a l'heure et tu me dira laquelle fonctionne (quand t'aura le temps), teamwork

[vincent2105]

OK, pas de problème, au contraire :) Tu peux en mettre davantage si tu veux, ca prend vraiment rien comme temps. Je devrais pouvoir te tester ça dans la matinée, sinon en soirée.

[upsilandre]

Voila une compile, t'as juste a me dire laquelle fonctionne :)
https://drive.google.com/open?id=0B399kteofpYuU01SLXBlOU1HX1E

[vincent2105]

Alors là, y'a un truc étrange !  
J'ai testé chaque rom une à une, et elles passent toutes... Après j'ai retesté tes roms que j'avais téléchargées hier soir et la aussi elles passent (même après un power off)... 
Je sais pas si quelqu'un d'autre à testé, faudrait qu'il nous dise...

[upsilandre]

ah mince, on risque de rester dans le flou.
Donc meme ca ca passe? https://drive.google.com/open?id=0B399kteofpYuR1hqOXFNZlNNVjA

[vincent2105]

oui ça passe également.

[upsilandre]

J'ai tout enlevé, bon bah tanpis on saura jamais
Le principal c'est que le support du MMC5 a l'aire de fonctionner un minimum.
En tout cas merci pour les tests

[vincent2105]

De rien pour les tests (surtout si j'ai merdé hier soir  )
Si tu as besoin d'autres tests, n'hésite pas

[upsilandre]

(surtout si j'ai merdé hier soir  )

Ca serait mieux que ce soit ca mais je vois pas ce que t'aurais pu foirer, je doute que ce soit l'expliquation.

[Stef]

Ca c'est quand meme sympa que le Z80 ait un acces direct a la ROM. Mais du coup le partage bus/rom avec le 68000 ce fait comment? le Z80 peut bloquer le 68000 le temps qu'il a besoin?

Il y a effectivement un partage du bus qui est géré par le bus arbiter, le Z80 fonctionne en cycle steal, en gros il prend le bus quand il est libre et le retient le temps de l'accès avant de le rendre. Si tu fais pas mal d'accès au bus depuis le Z80 ça a donc un impact sur les performances du 68000, mais bon j'ai calculé une pénalité de l'ordre de 3-4% max pour un peu plus de 4x16000 accès par seconde, donc très raisonnable ;-)
Le seul truc dommage c'est que le Z80 n'est pas la priorité sur le bus par rapport au DMA, ça éviterait le problème des voix qui grésillent mais j'imagine que techniquement c'était compliqué d'interrompre un DMA.

[upsilandre]

ok merci
C'est sure que le confort d'avoir des ROM dédié comme sur NeoGeo ca serait autre chose.