Re: Mr ToutLeMonde et la programmation NES...

[vincent2105]

Vous voulez rigoler ? 
Mon bug... il n'a lieu que sur émulateur, pas sur ma NES !!! 

[Invité]

Comme tu le dis c'est pas l'idéal puisqu'il faudrait que j'utilise l'instruction BIT. Je verrai ca plus tard 

Disons que l'instruction BIT t'évite à recharger A à chaque fois (si le test est faux) .
Mais ça marche aussi très bien avec AND .

Avec BIT

LDA bouton_presse
BIT tab_bouton
bne .test_bas
; // Code si bouton haut préssé
...
...

.test_bas:
BIT tab_bouton + 1
bne .test_gauche
; // Code si bouton bas préssé
...
...

.test_gauche
BIT tab_bouton + 2
bne .test_droit
; // Code si bouton gauche préssé
...
...

.test_droit:
BIT tab_bouton + 3
bne .test_xxx
; // Code si bouton droit préssé
...
...

Avec AND

LDA bouton_presse
AND tab_bouton
bne .test_bas
; // Code si bouton haut préssé
...
...

.test_bas:
LDA bouton_presse
AND tab_bouton + 1
bne .test_gauche
; // Code si bouton bas préssé
...
...

.test_gauche
LDA bouton_presse
AND tab_bouton + 2
bne .test_droit
; // Code si bouton gauche préssé
...
...

.test_droit:
LDA bouton_presse
AND tab_bouton + 3
bne .test_xxx
; // Code si bouton droit préssé
...
...

Mon bug... il n'a lieu que sur émulateur, pas sur ma NES !!!  

 
En général c'est plutôt l'inverse .

[vincent2105]

Bon j'ai essayé avec l'instruction BIT, mais  quelque soit l'instruction de branchement qui la suit, je n'obtiens pas ce que j'attends :/
Juste une petite rectif, avec CMP il fallait brancher avec BNE pour tester le bouton suivant, par contre avec AND il faut brancher avec BEQ.
Pour l'instruction BIT, j'approfondirai plus tard je pense, la j'ai plutot envie de faire apparaitre differents ennemis au fur et à mesure qu'on scrolle 

[upsilandre]

sinon y a aussi les instructions de decalage/rotation si on veut tester des bit successif, ca depend de la situation.

Pour ce qui est des bug meme si ca n'a rien a voir je sais qu'il y a un bug hardware sur les input quand le canal DMC est utilisé (a cause des interruptions)

[Invité]

Juste une petite rectif, avec CMP il fallait brancher avec BNE pour tester le bouton suivant, par contre avec AND il faut brancher avec BEQ. 

Alors c'est que tu as une couille quelque part .
Car justement BNE ça veux dire que ce que tu as dans A n'est pas égal à l'entrée testée (le but du BNE est justement de passer au test de l'entrée suivante si non égal) .
BIT et AND font la même chose, la seule différence c'est qu'en plus de ne pas détruire A, BIT teste aussi le bit 7 et 6 .

Ensuite, selon comment se goupille les bits de ton pad tu peux utiliser une jmp table,c'est encore plus rapide.

[vincent2105]

sinon y a aussi les instructions de decalage/rotation si on veut tester des bit successif, ca depend de la situation.

oui justement, la routine de lecture du pad que j'ai repompé d'un tuto les utilise. 

Code:

  LDX #$08
ReadControllerLoop1:
  LDA $4016
  LSR A           ; bit0 -> Carry
  ROL boutons_j1    ; bit0 <- Carry
  DEX
  BNE ReadControllerLoop1

Pour ce qui est des bug meme si ca n'a rien a voir je sais qu'il y a un bug hardware sur les input quand le canal DMC est utilisé (a cause des interruptions)

Le canal DMC (pour les samples si je dis pas de bêtise) je vais m'en passer, ca me fera une source de bugs en moins.  Par contre, j'espère vraiment que je serai capable de mettre un peu de son sur tout ca si j'arrive à quelquechose de correct.

[upsilandre]

En tout cas moi j'ai essayé le Python (en lisant ce topic) et c'est vraiment tres sympa, parfaits je pense comme complement retro-gaming, ca m'a convaincu.

Du coup comme premier programme python j'ai fais un programme qui decrypte les fichiers ROM du famicom disk pour en extraire un maximum d'information. Je m'etais pas mal intéressé au Famicom Disk mais me manquait des informations plus précise et général sur l'utilisation et les disquettes donnent pas mal d'informations dans leurs metadata.

le FDS utilise des disquettes (qui ont 2 faces, et qu'il faut retourner manuellement) qui ne contiennent pas de secteur ou de track, y a juste une seul piste en spiral comme un CD sauf que sur un CD tu peux quand meme faire des acces random (meme si c'est lent), sur les disquettes FDS non. a chaque acces tu lis l'integralité de la piste (donc de la disquette) pour récuperer les fichiers qui t'intéresse.
Donc c'est un systeme tres simplifier que ce soit pour la mecanique du lecteur (une piste en spirale) que pour la gestion des fichiers (pas d'acces random)  mais qui correspond bien au besoin puisque l'usage le plus classique va etre de charger l'integralité (ou quasi) de la face A dans la ram interne (qui emule la ROM cpu et la ROM gpu d'une cartouche 40ko classique sans mapper) au boot de la machine et donc c'est surtout sur cette premiere tache qu'il faut assurer l'efficacité car elle va s'effectuer a chaque fois que tu lance ton jeu donc le principale c'est que cette etape la soit rapide. Cette grosse simplification du systeme (et la faible densité) leur a sans doute permis d'avoir un chargement complet rapide (c'est 6 seconde le loading) a cout faible.

Ce qui est amusant dans la gestion des fichiers des disquettes FDS c'est que ce n'est pas le programme mais chaque fichier qui decide tout seul si ils doivent etre charger au boot et surtout a quelle endroit (quelle adresse mémoire), tout ca est inscrit dans leur metadata ce qui est assez original (et intéressant car ca nous donne des informations précieuse), y a aussi des noms de fichier dans les metadata mais facultatif, ce n'est pas utilisé pour la gestion des fichiers (qui sont géré uniquement par leur ID, ils peuvent d'ailleurs avoir la meme ID, il se distingue de toute facon par l'adresse a laquelle ils vont s'auto-charger) mais les nom de fichier nous donne aussi des informations donc ca vallait le coup de les récupérer aussi.

Donc mon petit programme te demande un path (vers un dossier) et il va chercher toute les ROM FDS contenu dans ce dossier (en séparant celle qui sont des ROM officiel de celle qui ne sont pas officiel) et les analyser pour extraire un max d'info et sortir 4 fichiers. un fichier qui contient les details de chaque disquettes et un autre qui contient plutot un résumé avec quelques stats (et pareille pour les ROM non officiel). Et avec Python tu fais ca vraiment tres facilement et rapidement.

Faut rappeler que Metroid, Zelda, Castlevania, Kid Icarius, Mario 2... sont des jeux qui ont ete concu pour le Famicom Disk avant d'avoir le droit a des portages cartouches donc c'est quand meme intéressant de s'y pencher.

Par exemple pour Metroid ca donne ca en version détaillé

Spoiler:

Y a les informations lié a chaque face et les informations de chaque fichier avec notamment le nom, l'adresse a laquelle il est destiné (et j'ai meme précisé si c'etait la WRAM ou la VRAM et meme si c'etait dans le tileset ou la tilemap). J'ai verifié et indiqué aussi si jamais c'etait un fichier vide (souvent le cas pour les fichier de sauvegarde qui se trouve en fin de disquette) ou quand c'etait un fichier qui contient le text de licence Nintendo qui s'affiche au debut et qui sert de controle. et d'autre type d'information.
Et a la fin y a la quantité total de donnée de la face. y a 3 chiffres different. le total de fichier, le total en ajoutant aussi les metadata, et le total juste de fichier de donnée pour le jeu (donc sans les fichier vide ou fichier de licence) qui est le chiffre qui m'intéresse.
La juste avec les nom des fichiers et leur destinations on peut deja deviner un peu leur fonction.


En version résumé (sans les détails) ca donne ca (sur les jeux licencié)

Spoiler:

Avec a la fin quelques stats

average bytes per side: 48026 (max: 54608)
average bytes per file: 3855 (max: 32896)
average files per side: 12 (max: 40)

Faut compter en général 50Ko par face. Ca en fait quand meme la disquette avec la plus faible densité que je connaisse. J'ai pas trouvé historiquement de disquette plus faible. Du coup le support s'est tout de suite fait rattrapé par les cartouches et son atout s'est vite limité a ses capacités d'ecriture.

Les fichiers complets
https://drive.google.com/open?id=0B399kteofpYuUEhjZTdDczhZWmM
https://drive.google.com/open?id=0B399kteofpYuMkxWODFBR3h6NVE
https://drive.google.com/open?id=0B399kteofpYudzBJR202VHFhdWM
https://drive.google.com/open?id=0B399kteofpYuYjhGTkRIaFF1TE0

[vincent2105]

touko, concernant le branchement à utiliser après l'instruction AND, j'ai essayé sur http://skilldrick.github.io/easy6502/ et c'est avec BEQ qu'on passe aux cas suivants si la valeur dans A n'est pas égale à l'entrée testée.
Voici le code que j'ai testé, il affiche trois couleurs si la valeur en A est égale à l'entrée testée. 

Code:

lda #$01
and #$01
beq fin
LDA #$01
STA $0200
LDA #$05
STA $0201
LDA #$08
STA $0202
fin:

Concernant l'idée d'utiliser une jmp table, j'utilise déjà le registre X pour boucler et ainsi traiter les 2 pads... Peut-être que je ferai comme tu dis à moins d'avoir à ajouter d'autres choses.

@upsilandre je vais prendre le temps de lire ton post

[Invité]

Justement y'a un souci quelque part .
ex: si REG A = $0F
AND #$0F
Va donner 0, donc A = $0F, BEQ = branchement si égal .
donc si tu lis ton entrée pad dans A, et que tu testes si on a préssé haut par exemple
LDA _mon_entree_pad ; // A = le code pour haut
AND #HAUT
bne .pas_haut    ; // A n'est pas egal à haut
; // Ici A = HAUT donc on execute le code pour l'appui sur haut du pad
...
...

.pas_haut :

Concernant l'idée d'utiliser une jmp table, j'utilise déjà le registre X pour boucler et ainsi traiter les 2 pads... 

Tu peux utiliser Y pour boucler 
Mais je viens de voir que le 6502 ne gère pas le jmp indexé .

[vincent2105]

Je suis pas sur de comprendre. Tu maintiens que c'est BNE qu'il faut utiliser ? mon petit exemple sur skilldrick prouve bien le contraire pourtant ? (et dans ma routine de gestion des inputs, je suis dans un cas identique et ça fonctionne avec beq). Ceci dit, ca ne me parait pas logique non plus...

[vincent2105]

Toujours aussi pointu upsilandre  J'ignorais totalement l'existence de ces disquettes.

Et a la fin y a la quantité total de donnée de la face. y a 3 chiffres different. le total de fichier, le total en ajoutant aussi les metadata, et le total juste de fichier de donnée pour le jeu (donc sans les fichier vide ou fichier de licence) qui est le chiffre qui m'intéresse.

Concretement que veux tu faire ? localiser des fichiers CHR_ROM ?

[Invité]

Je suis pas sur de comprendre. Tu maintiens que c'est BNE qu'il faut utiliser ? mon petit exemple sur skilldrick prouve bien le contraire pourtant ? (et dans ma routine de gestion des inputs, je suis dans un cas identique et ça fonctionne avec beq). Ceci dit, ca ne me parait pas logique non plus...

Non tu as raison, je m'embrouille tout seul là 
le flag Z est à 0 .

Donc un AND génère un 0(Z=1) si les 2 valeurs ne sont pas identiques .
Donc BEQ si les 2 valeurs ne sont pas identiques sinon BNE .

Le résonnement s'inverse avec un AND, cad que 2 valeurs avec des bits qui correspondent donne un and différent de 0.

[vincent2105]

Je ne comprends toujours pas
Je te mets un bout de mon code qui test si le bouton "droit" est enfoncé ou non.
Si la valeur qui suit LDA est égale à celle qui suit AND, alors BEQ est "ignoré". C'est bizarre j'avoue, mais c'est bien ce qu'il se passe aussi dans l'exemple que je t'ai proposé pour l'emulateur sur skilldrik.

Code:

 LDA boutons_j1
  AND #%00000001
  Beq .pas_droite
  
  LDA joueur_1_X        ; code a executer si la valeur
  CLC                   ; "boutons_j1" est égale à celle
  ADC vitesse_J1        ; qui suit l'opcode AND
  STA joueur_1_X
  LDA #DROITE
  STA direction_J1

.pas_droite:

EDIT : j'ai vu que tu avais édité

[Invité]

Oui, le pire c'est que quand je code, je fais des BEQ et BNE naturellement, mais dés que je réfléchis, ça va plus 
En gros si une opération donne 0 le flag Z = 1 .
BNE branche si Z=0, et BEQ si Z=1 .

Un :
LDA #%00000001
AND #%00000001

Va forcement te donner un résultat différent de 0, donc Z=0 .
un:
LDA #%00000011
AND #%00000001

Aussi car les bit 0 des 2 valeurs sont à 1.

Par contre un:
un:
LDA #%00000001
AND #%00000010
Va te donner un Z=1, car aucun bit des 2 valeurs ne correspondent .

Avec un AND si au moins 1 bit de chaque valeur est à 1, Z sera =0(valeur non nulle) .

[vincent2105]

Ok, là on est d'accord
Maintenant, va falloir qu'on se penche sur le cas de l'instruction BIT

[Invité]

Elle fait pareil, mais teste en plus les bit 7 et 6 (flags N et V ) et fonctionne pas avec une valeur en immédiat sur 6502, faut y mettre une adresse,et surtout ne touche pas A, c'est utile pour ne pas avoir à recharger A à chaque foi .

[vincent2105]

Elle fait pareil, mais teste en plus les bit 7 et 6 (flags N et V ) et fonctionne pas avec une valeur en immédiat sur 6502, faut y mettre une adresse .

Ah ok, je testerai ca...
Du coup on branche de la même façon qu'avec AND c'est ce que tu veux dire ?

[Invité]

Oui,et tu as aussi la possibilité de tester N et V de la valeur à l'adresse après le BIT .

[vincent2105]

Le registre d'état j'avoue que je n'y ai jamais mis le nez dedans sérieusement.
J'ai juste vu qu'on avait N pour négatif, V pour débordement, mais concrètement j'en ai toujours fait abstraction. Si tu as un exemple dans lequel on peut constater leur utilité, je suis preneur

[Invité]

V est pas souvent utilisé, et son fonctionnement est pas clair ,perso je l'utilise pas .
N sert à savoir si un nombre est négatif ou pas, utile si tu utilises des nombres signés .
il est aussi utile si tu veux tester une valeur inférieure à 0, style la valeur 0 t'est nécessaire, mais pas $FF, tu vas utiliser les tests BPL et BMI,en gros testent si le bit 7 et à 0 ou 1 .

Tu as aussi les illegal opcode, et il me semblent qu'elles soient présentes sur le CPU de la nes :
http://codebase64.org/doku.php?id=base:6502_6510_coding

les opcodes illégales sont ici:
http://codebase64.org/doku.php?id=base:extra_instructions_of_the_65xx_series_cpu

Super site sur le coding C64 

[vincent2105]

Merci pour les liens
J'ai parcouru les "illegales"... C'est sympa de pouvoir réaliser 2 opérations avec une seule opcode... mais ma foi, ça m'a l'air d'être une sacrée gymnastique ! Dans le peu que j'ai pu faire, je ne pense pas avoir pu en caser une :p

[vincent2105]

Bon, j'ai les grandes lignes de mon futur petit jeu maintenant, on peut le définir comme un shmup horizontal dans l'univers MARIO. 

En zieutant les différentes ROMs de jeux que j'avais téléchargées, je me suis apercu que les 3 opus de Mario avaient leurs éléments graphiques en CHR_ROM, ils sont donc facilement réexploitables, ce qui n'est pas le cas de tous les jeux. 

Il n'y aura en quelque sorte qu'un seul niveau. Avec au choix le skin SMB1, SMB2 ou SMB3... 

Le niveau sera de longueur infinie. Tant qu'on est vivant, on avance... et la difficulté progresse. La petite originalité sur laquelle je planche  est le caractère aléatoire de la génération du niveau. A chaque partie, le joueur découvre un background différent, créé aléatoirement au fur et a mesure du scroll tous les 64 pixels (un écran fait 252px). J'ai déjà résolu une partie du problème.

A voir si j'arrive au bout, puisque le gros morceau sera la détection des collisions, mais je suis plutot bien parti.  

@upsilandre : j'ai lu ton post concernant les disquettes famicom, mais je ne sais pas si tu as vu ma question : concrètement, que comptes tu faire avec les infos récoltées ?

[vincent2105]

J'ai atteint mon premier objectif, afficher un background de facon aléatoire au fur et à mesure que l'on scrolle (tous les 64px)


Taches suivantes :
- mettre à jour les attributs pendant le scroll (il s'agit de choisir la palette desirée (parmi 4) pour chaque zone de 16x16 pixels)
- créer des colonnes de background de 208x64 pixels qui remplaceront mes colonnes de chiffres.
Si j'arrive jusque la, j'approfondirai certainement la routine de choix du background à afficher pour que le tout garde une certaine cohérence tout en restant le plus varié possible...(La, y'a du pointeur en perspective :p )

[tetsuro]

C'est passionnant, bon boulot, courage !

[vincent2105]

Merci tetsuro, ca fait super plaisir

Ce soir j'attaque mon prochain casse-tête : mettre les attributs à jour en fonction du scroll... Je suis toujours excité à l'idée de faire un truc nouveau... jusqu'a ce que je m'y casse les dents

[drfloyd]

Bon, j'ai les grandes lignes de mon futur petit jeu maintenant, on peut le définir comme un shmup horizontal dans l'univers MARIO.

Un peu façon SUPA ZAZAI ?
Enregistrer

[vincent2105]

Un peu oui dans la mesure ou ca sera  de l'horizontal sans interaction avec le background (j'ai pas le niveau), mais y'aura bcp moins de boulettes...
J'aimerais bien reussir à créer des patterns de déplacements un peu originale pour les ennemis...
Dans tous les cas, faut deja que j'arrive à gérer les collisions et ca c'est pas gagné puisque je l'ai jamais fait, comme je l'ai dit, je fais ca pour apprendre / en guise d'exercice ludique.

[tetsuro]

Je suis et vis ta douleur par compassion, j’essaie aussi de faire un jeu mais sur Megadrive, mais la programmation sur Nes ça à l'air costaud, j'aimerais un jour faire comme toi, mais je dois déjà essayer de faire un jeu Megadrive, c'est mon objectif, je suis ton travail avec grand intérêt, courage Vincent !

[vincent2105]

Merci encore testuro et bon courage au passage pour ton projet 
 
Avec le recul, en vous lisant toi et vetea, je me rends compte que je donne vraiment une impression de galérer plus qu'autre chose alors que c'est pas du tout comme ça que je le vis dans l'ensemble.
Certes il y a des fois ou ca coince sévèrement, mais la plupart du temps, je bidouille dans la joie et la bonne humeur. Ce loisir m'intéresse toujours autant, j'essaierai de moins chouiner à l'avenir

Bref, je ne voudrais pas que mon cas personnel semble décourageant pour ceux qui voudraient se lancer dans la même aventure, bien au contraire. 

[vincent2105]

Bon, l'idée du shmup ne me motive plus tant que ça, du coup  l'exercice qui consistait à mettre à jour les attributs au fur et a mesure du scroll sur un background aléatoire me parait bcp moins intéressant. :/

Je reconnais que quand je perd l'intérêt, y'a rien a faire, j'avance plus... Alors je passe pas mal de temps a trouver une idée de jeu, mettre en place un minimum de code etc.
Grosso modo, je fais 2 pas en avant, un en arriere... c'est un de mes gros défauts, j'ai tendance a me disperser...

La je suis en train de réfléchir à générer aléatoirement une map de taille infinie (qu'on parcourait sans scrolling). Comme d'hab au debut , je suis hyper motivé

[Invité]

Je reconnais que quand je perd l'intérêt, y'a rien a faire, j'avance plus... Alors je passe pas mal de temps a trouver une idée de jeu, mettre en place un minimum de code etc.
Grosso modo, je fais 2 pas en avant, un en arriere... c'est un de mes gros défauts, j'ai tendance a me disperser...

Tu n'es pas le seul, c'est pas facile de rester a fond dans un projet, surtout quand tu dois faire des partie qui ne t'intéressent pas .