Re: Mr ToutLeMonde et la programmation NES...

[Invité]

La NG par exemple sait faire du "swap" de tiles hardware.

[Tryphon]

Merci :)

[vincent2105]

j'ai retrouvé un post d'upsilandre à ce propos

De toute facon IRQ ou pas il faut miser sur le MMC3 je pense, notamment pour sa granularité au niveau du bank switching de la CHR-ROM.
Le MMC3 peut bank switcher des bank de 1Ko de CHR-ROM alors que le MMC1 c'est 4Ko (donc un tileset complet) et ca change tout (je parle dans le cas d'une configuration CHR-ROM) car avec cette granularité de 1Ko tu peux alors utiliser le bank switching de la CHR-ROM pour modeler ton tileset selon tes besoins (par exemple modifier seulement une partie du tileset des sprites pour remplacer un ennemi par un autre sans pour autant devoir aussi switcher le tileset de ton perso qui lui reste toujours le meme) donc t'as un bien meilleur controle sur ton tileset, pas autant qu'avec de la CHR-RAM qui permet de construire ton tileset sur mesure, mais bien plus rapidement (puisque les modifications du tileset sont alors instantané grace au bank switching) du coup ca permet aussi de faire tres facilement des animations de background ou des animations de sprites plus riche et ainsi exploiter l'un des plus gros atout de la NES.
Avec une granularité de 4Ko t'as aucun controle sur ton tileset (tu changes tout ou rien, y a pas d’intermédiaire) , Tu peux pas le découper en plusieurs morceau independant. Du coup l'utilisation de CHR-ROM devient un mauvais choix qui implique énormément de gachie.

Y a beaucoup de configuration de cartouches sur NES mais en gros t'as 2 configurations assez typique, les plus frequentes.
-- Les configurations 128Ko PGR-ROM + 8Ko CHR-RAM et un mapper MMC1 (ou UNROM)
-- Les configuration 128Ko PGR-ROM + 128Ko CHR-ROM et MMC3
La configuration CHR-ROM + MMC1 est une mauvaise combinaison (mais qui a quand meme ete utilisé parfois).

Sur NES y a eu une premiere phase avant les mappers ou les cartouches etaient alors exclusivement avec de la CHR-ROM.
Puis une seconde phase avec les mappers type UNROM et MMC1 ou la les cartouches sont passer presque essentiellement a une configuration CHR-RAM.
Et une troisième phase avec l'arrivé du MMC3 ou la CHR-ROM est alors revenu en force (sans pour autant eclipser totalement la configuration CHR-RAM qui a d'autre avantage mais presque).

[upsilandre]

On peut trouver d'autres exemples





Mais rien ne vaut celui ci



car la c'est shifté en temps réel par le CPU , ca serait pas possible a faire avec le bank switching de CHR-ROM a cause du scrolling multidirectionnel, il faudrait pas seulement 32 versions des tuiles mais cette fois (32x32) 1024 versions dans 1024 bank 1Ko.

[Hpman]

La NG par exemple sait faire du "swap" de tiles hardware.

L'auto animation? C'est pas vraiment adapté pour ce genre d'effets, un cycle de 4 ou 8 dont tu ne peux pas contrôler l'index. Tu peux juste contrôler la vitesse du cycle et éventuellement le stopper

[upsilandre]

Une autre facon astucieuse d'utiliser le meme trick de manière inversé (pour figer un background)

[brokestudio]

Excellent celui là ! Tellement "simple" que je n'y aurais même pas pensé je crois ... Bien vu en tout cas !

[Invité]

La NG par exemple sait faire du "swap" de tiles hardware.

L'auto animation? C'est pas vraiment adapté pour ce genre d'effets, un cycle de 4 ou 8 dont tu ne peux pas contrôler l'index. Tu peux juste contrôler la vitesse du cycle et éventuellement le stopper

Oui, je pensais à ça 

La nes est qd même énorme en tile swap  .

[vincent2105]

Une autre facon astucieuse d'utiliser le meme trick de manière inversé (pour figer un background)

C'est bien pensé oui. Le comble, c'est qu'il s'agit d'un homebrew si je dis pas de bêtise (Blade Buster).

[upsilandre]

oui c'est ca

[vincent2105]

Ca y'est j'ai franchi un palier, j'ai mon split screen   
Je vais pouvoir continuer mes bidouilles 

[vincent2105]

Isoler les attributes tables(1Ko)  de chaque circuit dans une bank à part, copier celle nécessaire dans l'extension RAM, puis bankswitcher les 2 banks PRG ROM pour récupérer les 16 Ko de nametables et faire scroller le tout... ça c'est fait ! C'était pas compliqué en soi, mais c'est surtout que ça me donne confiance pour la suite. 
Avec 512 Ko de PRG ROM (16Ko fixes+8Ko+8Ko), vu que j'ai besoin de 16Ko de nametable + 1Ko d'attribute table par circuit, je vais pouvoir en faire quelques uns sans me soucier de la place disponible en ROM, et d'autre part, tout est calé de facon à ce que je puisse facilement appeler tel ou tel circuit etc...

[vincent2105]

Je me pose une question, et au risque de m'enliser, je sollicite vos lumières. C'est pas très clair dans ma tête, excusez moi par avance si je la formule mal.
Il me semble possible de copier en RAM une routine présente dans une banque PRG ROM switchable, pour l'executer ensuite. Est ce que je dis une bêtise ?
C'est pas que j'en ai besoin dans l'immédiat, c'est surtout par curiosité...

[Invité]

Il me semble possible de copier en RAM une routine présente dans une banque PRG ROM switchable, pour l'executer ensuite. Est ce que je dis une bêtise ?

Non,tu as tout à fait raison, en général on utilise ce procédé pour faire du code auto modifié(ce qui n'est pas possible en ROM).

[vincent2105]

Ok merci Touko A la base, j'imaginais pas cette utilisation.
Bref, c'est cool, encore du grain à moudre

[Invité]

Ok merci Touko A la base, j'imaginais pas cette utilisation.
Bref, c'est cool, encore du grain à moudre

Ca apporte pas mal de possibilités .

Par exemple tu peux changer un saut à une fonction:

Code:

saut_fonction:
  jsr  Mafonction1
  ...
  ...
  ...
  rts

  lda #Mafonction2
  sta saut_fonction + 1 // On stocke l'adresse LOW de Mafonction2 après l'opcode de JSR
  lda #Mafonction2 + 1
  sta saut_fonction + 2 // On stocke l'adresse HIGH de Mafonction2 après l'adresse LOW

Après ça le JSR sautera à l'adresse de Mafonction2 et plus à Mafonction1



Voilà un petit exemple simple .

[vincent2105]

Ok je pense avoir compris ton exemple.

Sinon, tu aurais un exemple de copie d'une routine en RAM ? Enfin j'imagine qu'il suffit de remplacer les mnémoniques par leurs opcodes, et de copier le tout à l'adresse désirée via une boucle, non ? Dans ce cas, faudra que je trouve un moyen/outil simple pour récupérer ces octets.

[Invité]

une boucle de lda/sta suffit .
Par exemple en ROM tu as :

Code:

Mafonction:
  ....
  ....
  ....
  ....

  rts

Il faut connaitre la taille de ta fonction (en octets),et être sur de n'avoir que des sauts relatifs dedans,un JMP qui envoie plus loin dans la même routine devra être modifié après la copie .
Si elle fait moins de 256 octets tu peux faire:

Code:

debut_copie_fct:
  lda Mafonction , X
  sta Mafonction_en_ram , X

  inx

  cpx #taille
  bne debut_copie_fct


Ensuite l'appel à la fonction se ferra via:
JMP/JSR Mafonction_en_ram

PS: Tu n'as pas besoin de connaitre les opcodes, juste le début de la fonction à copier,la taille, et la destination,la copie est une simple copie de X octets .

[vingazole]

une boucle de lda/sta suffit .
Par exemple en ROM tu as :

Code:

Mafonction:
  ....
  ....
  ....
  ....

  rts
ApresMafonction:

Il faut connaitre la taille de ta fonction (en octets)

Si tu rajoutes un label ApresMafonction après ta fonction (cf code), tu dois avoir la taille de celle-ci égale à ApresMafonction-Mafonction.

[vincent2105]

Ok super j'ai compris merci

PS: Tu n'as pas besoin de connaitre les opcodes, juste le début de la fonction à copier,la taille, et la destination,la copie est une simple copie de X octets .

Oui... pourquoi faire simple quand on peut faire autrement

[Invité]

Exact, la taille peut facilement être calculée par un:
taille = adr_label_fin - adr_label_debut

Ok super j'ai compris merci 

n'hésites pas si je suis pas clair, car moi ou d'autres (comme vingazole) peuvent t'aider, exécuter du code en RAM est commun à tout les CPU .
Et surtout souvent ça peut ouvrir à pas mal de flexibilité, sans avoir plusieurs routines quasi identiques en ROM .

[upsilandre]

La RAM est dans l'espace mémoire du CPU au meme titre que la ROM, dans le prolongement, donc y a aucune différence, ce qu'on fait en ROM on peut le faire en RAM. Le CPU lui meme ne sait pas si c'est de la RAM ou de la ROM, il ne fait pas la distinction donc faut pas se formaliser la dessus.

Pour le hack de Megaman1 par exemple jetais obligé de mettre mon code en RAM, pas de place ailleurs. Et pour mon kernel de Space Invaders sur VCS obligé de faire du code auto modifié

[Invité]

 Oui... pourquoi faire simple quand on peut faire autrement 

Parce que des fois c'est plus marrant 

[vincent2105]

 Oui... pourquoi faire simple quand on peut faire autrement 

Parce que des fois c'est plus marrant 

C'était de l'autodérision qu'on soit bien d'accord

@upsilandre : maintenant que tu en parles ça me revient, j'avais zappé que tu étais passé par la RAM pour ton hack de megaman.

[Hpman]

La RAM est dans l'espace mémoire du CPU au meme titre que la ROM, dans le prolongement, donc y a aucune différence, ce qu'on fait en ROM on peut le faire en RAM. Le CPU lui meme ne sait pas si c'est de la RAM ou de la ROM, il ne fait pas la distinction donc faut pas se formaliser la dessus.

Pour le hack de Megaman1 par exemple jetais obligé de mettre mon code en RAM, pas de place ailleurs. Et pour mon kernel de Space Invaders sur VCS obligé de faire du code auto modifié

Certaines machines ont parfois des timing mémoires différents RAM/ROM 

[Invité]

C'était de l'autodérision qu'on soit bien d'accord  

J'avais compris . 

Certaines machines ont parfois des timing mémoires différents RAM/ROM  

La snes en mode hiROM par exemple .

[vincent2105]

Maintenant, faut que je m'occupe de la routine de chargement du circuit, de l'attribute table, de la palette et de la bank chr. 
Ca m'enchante pas des masses, alors pour me donner du coeur à l'ouvrage, je vais me pencher sur un nouveau tileset et une nouvelle map (série de nametables). Ca sera une source de motivation de pouvoir  afficher un bg totalement différent.
Je sais pas encore quel jeu je vais repomper : smb ? zelda ? smb3 ? Je vais faire un tour dans la ludothèque de la NES 

[vincent2105]

J'ai fait mon choix... Castlevania 2 "Simon's Quest" 
J'ai trouvé tout ce qu'il fallait là :
https://www.spriters-resource.com/nes/castlevania2simonsquest/
Théoriquement, grâce aux interruptions, je vais pouvoir utiliser 256 tiles pour  la piste et autant pour le bg accessoire.
En fonction du jeu repompé, je pense que je vais devoir retravailler les tiles de la piste pour respecter un minimum la perspective...

[vincent2105]

Je suis en train de préparer mes banks CHR ROM.
Finalement, je vais utiliser plus de 256 tiles pour le bg accessoire : je vais avoir 3, voir 4 banks de 2 Ko.
Depuis que j'ai découvert le tileset de castlevania et notamment les colonnes, je songe à jouer avec la priorité du sprite du joueur pour mettre du background accessoire en premier plan, le joueur passerait alors derrière les colonnes et autres éléments.
Un p'tit screen shot...

[vincent2105]

Seconde bank de 2 Ko prête... les 3 ou 4 banks  seront switchées en fonction du scroll (avec en permanence 2 banks de 2 Ko à disposition), mais je pourrais me payer le luxe de bankswitcher en plus sur une interruption, je n'écarte pas l'idée.
En tous cas, le tileset de Castlevania m'inspire, je pense qu'il y a moyen de faire un truc du tonnerre.
D'ailleurs, j'ai un p'tit regret, c'est que vu le style de jeu dans lequel je me lance, (course, donc scrolling rapide), il est quasiment inutile de faire l'anim de background, c'est pourtant une chose qui me plait particulièrement :/

[brokestudio]

Ca faisait un moment que j'étais pas passé par ici, c'est cool ça avance ! :)