Re: Mr ToutLeMonde et la programmation GameBoy...

[Invité]

L'idée des ports et des instructions associé c'etait je pense d'avoir un adressage 8bit avec une instruction qui prend un octet de moins et qui est plus rapide que pour le reste de l'adressage (l'equivalent de la page zero du 6502 et ses instructions associés) en plus d'eviter de découper en tranche les 64Ko.

Y'a aussi des instructions de transfert à travers des ports sur le hu6280, et je trouve ça vraiment utile et pratique .

Je n'ai toujours pas tapé la moindre ligne de code, mais tous ces registres me donnent déjà le tournis... c'est une gymnastique différente. Moi qui voulait changer d'air, je suis servi. 

Oui ce sont 2 CPU radicalement différents .

[Stef]

L'idée des ports et des instructions associé c'etait je pense d'avoir un adressage 8bit avec une instruction qui prend un octet de moins et qui est plus rapide que pour le reste de l'adressage (l'equivalent de la page zero du 6502 et ses instructions associés) en plus d'eviter de découper en tranche les 64Ko.

Justement je pense que les instructions suivantes sont une très bonne compensation :

LD A,(C)      = LD A,($FF00+C)
LD C,(A)      = LD ($FF00+C),A
LDH A,(a8)   = LD A,($FF00+a8)
LDH (a8),A   = LD ($FF00+a8),A

Ca simule une high page :)

[upsilandre]

C'est vrai qu'en faite c'est exactement les instructions IN/OUT du Z80 (on retrouve meme le registre c) mais cablé et nommé autrement.

[upsilandre]

En fait si tu regarde bien suffit en interne de cabler le signal IORQ du Z80 sur A8/A9/A10/A11/A12/A13/A14/A15 plutot que de le faire sortir sur une pin dédié et tu transforme alors les instructions out/in en ces nouvelles instructions. Donc c'est quand meme bien des instructions Z80 finalement.

[vincent2105]

L'idée des ports et des instructions associé c'etait je pense d'avoir un adressage 8bit avec une instruction qui prend un octet de moins et qui est plus rapide que pour le reste de l'adressage (l'equivalent de la page zero du 6502 et ses instructions associés) en plus d'eviter de découper en tranche les 64Ko.

Justement je pense que les instructions suivantes sont une très bonne compensation :

LD A,(C)      = LD A,($FF00+C)
LD C,(A)      = LD ($FF00+C),A
LDH A,(a8)   = LD A,($FF00+a8)
LDH (a8),A   = LD ($FF00+a8),A

Ca simule une high page :)

a8, ça correspond à quoi ?

[Stef]

A un offset 8 bits encodé dans l'instruction (et donc forcément ça prend 4 cycles de plus), mais c'est quand même bien pratique, et ça reste bien plus rapide que ces fichus instructions (IX+d) complètement inutiles sur le Z80.

Le LD A,(C) c'est 8 cycles, aussi rapide que le LD A,(HL) donc optimal :)

En fait si tu regarde bien suffit en interne de cabler le signal IORQ du Z80 sur A8/A9/A10/A11/A12/A13/A14/A15 plutot que de le faire sortir sur une pin dédié et tu transforme alors les instructions out/in en ces nouvelles instructions. Donc c'est quand meme bien des instructions Z80 finalement.

C'est l'équivalent mais quand tu regardes le CPU de prêt tu te rends compte qu'ils ont quand même coupé large comparé au Z80 et vraiment on est beaucoup plus proche du 8080 au final. Mais les quelques ajouts sont quand même très réfléchis et rendent le CPU très interessant, plus que le Z80 pour moi en tout cas :)

[vincent2105]

Ah ok, quel couillon,  j'étais encore en train de chercher un registre :p
Merci :)

[upsilandre]

Le LD A,(C) c'est 8 cycles, aussi rapide que le LD A,(HL) donc optimal :)

Ce qui est intéressant c'est plutot d'avoir un LD ($ff00 + n),A (charger un port) a 12 cycles au lieu de 16 cycles pour un LD (nn),A (charger une variable en RAM)
Mais bizarrement dans les 2 cas c'est plus lent que sur Z80 (11 cycle le OUT (n),A et 13 cycles le LD (nn),A)

[Stef]

Oui bien sur tout les accés en page haute sont plus rapide car tu économises un byte à fetcher. Aussi le GBCpu s'aligne sur 4 cycles pour toutes ses instructions ce qui n'est pas le cas du Z80, je pense qu'ils ont fait ça pour simplifier les accés mémoire (1/4 de la fréquence CPU comparé à 1/3 sur le Z80 avec le refresh en plus). De ce fait les instructions du GBCpu sont souvent plus lente que sur le Z80... Mais grâce à ça le CPU peut être cadencé un peu plus rapidement en théorie (bon il ne tourne qu'à 4 Mhz sur GB et 8 Mhz sur GBC mais aussi pour des histoires économie d'énergie je pense). Je pense que ça fait un très bon CPU pour la GB, son nombre réduit de transistors doit bien limiter sa conso (je serai vraiment curieux de savoir combien il en comporte, le 8080 en a 4500 de base soit "seulement" 1000 de plus que le 6502).

[upsilandre]

En fait sur les 256 octets de cette page "255" y a pas que les port I/O mais y a aussi 128 octets de RAM qui sont mappé la du coup ca ressemble plutot effectivement a un usage comme la page zero du 6502. Donc on peut charger des variables en 12 cycles au lieu de 13 sur le Z80. Et a l'inverse on accede pas a la VRAM par des port I/O mais directement dans le mapping mémoire du CPU (donc plutot avec du LD (HL+),A), ca inverse toute la problematique qui du coup est a l'avantage de la GB dans les 2 cas par rapport au Z80.

[Stef]

Oui la VRAM est mappée directement sur le CPU sur GB, ce qui est super pratique :) Ca signifie aussi que le BUS est partagé entre le CPU et le GPU mais comme le CPU de la GB est souple sur les timings mémoire ça passe facilement :)
Sinon même en conservant un port GPU en high page, ils auraient pu avoir de bons résultats avec :
LD A,(HL-)
LD (C),A
16 cycles pour transférer 1 byte soit aussi rapide que LDI sur Z80.
Enfin bon, j'imagine qu'il y a moyen de s'amuser un peu plus avec ce CPU

[upsilandre]

A la petite nuance que LDI ou OUTI décremente aussi un compteur en bonus.
Le principal de toute facon c'est d'avoir la VRAM mappé sur le CPU, ca permet plus de chose.

[upsilandre]

Je pensais pas que la Gameboy color ajoutais autant de feature. Quand tu combines les atout de la GB + ceux de la GBC ca défonce complètement la NES (le probleme c'est toujours la resolution comme pour la GG ou meme la GBA).

[TotOOntHeMooN]

Le principal de toute facon c'est d'avoir la VRAM mappé sur le CPU, ca permet plus de chose.

Sur CPC aussi !

[vincent2105]

Je pensais pas que la Gameboy color ajoutais autant de feature. Quand tu combines les atout de la GB + ceux de la GBC ca défonce complètement la NES (le probleme c'est toujours la resolution comme pour la GG ou meme la GBA).

Perso, la "Color, je ne l'ai pas connue, elle est sortie 7/8 ans après ma GB, ça m'intéresse moins, mais effectivement sur le papier, la NES semble à la ramasse. :)

Ce soir, je me lance, première routine d'affichage de background. Je ne l'ai pas testée, je vais créer quelques tiles et un background à cette fin. Jusque là, j'utilisais Nes Screen Tool, pour des tests rapides, mais ça colle pas avec la GB, je vais voir avec GraphicsGale, si vous avez une autre application à me conseiller je prends. 

Sinon, voilà mon code (très inspiré de la routine de Furrtek). Tout commentaire ou correction bienvenu :) . 

Code:

LOAD_BG: 
  ld    hl,$9800      ; servira de pointeur VRAM, adresse où afficher la tile
  ld    de,BACKGROUND   ; servira de pointeur ROM pour recuperer le numero de tile à afficher
  ld    bc,32*32      ; servira de compteur d'itération (1024 tiles, plus grand que la taille de l'écran, mais simplifie les choses)
 
BG_LOOP:
  ld    a,(de)         ; charge numero de tile
  ldi   (hl),a         ; (hl)=A et incremente hl

  inc    de            ; permet de passer à l'octet suivant dans BACKGROUND
 
  dec    bc             ; decremente le compteur , si 0 on sort de la boucle
  ld   a,b             ;Une limitation du Z80 fait que le flag Z (zéro)
                  ;n'est pas mis à 1 si le résultat d'un DEC sur un registre 16 bits est égal à zéro
                  ;On doit donc ruser et utiliser l'opération logique OR
                  ;pour mélanger les registres B et C dans le registre A,
                  ;pour voir si tous le bits sont à zéro. On peut ensuite faire un JR NZ.
  or     c
  jr    nz,BG_LOOP 

[lincruste]

Pour les tiles et les maps, il te faut les utilitaires de Harry Mulder:
Gameboy Tile Designer:
http://www.devrs.com/gb/hmgd/gbtd.html
Gameboy Map Builder:
http://www.devrs.com/gb/hmgd/gbmb.html
Les deux sont complémentaires, et surtout on peut modifier une tile dans l'un et voir le résultat dynamiquement dans l'autre !
Sinon pour partir d'une image pour un décor il y a un convertisseur en ligne très utile, le Tile Data Generator:
http://www.chrisantonellis.com/gameboy/gbtdg/

[vincent2105]

Merci encore pour les liens lincruste, je regarderai ça ce soir  

Pour charger les tiles, je vais devoir là aussi modifier la routine du tuto. 
Vu qu'une tile occupe 16 octets, et qu'il travaille sur un registre 8 bits, on ne peut charger que 16 tiles (16x16=256). Pour avoir un nombre de tiles bcp plus important, il faut donc travailler avec un compteur d'itération 16bits comme je l'ai fait plus haut pour charger un background.   
Ca change de la NES et des banks CHR ROM que j'utilise systématiquement. Un avantage, c'est  qu'on ne gaspille pas de mémoire. 
Maintenant je me demande s'il est possible de réaliser des anims de background grâce au bankswitch .  De ce que j'ai vu on a 16ko fixes et 16 switchables, j'imagine que c'était grâce au cablage de la NES, mais j'ai pas eu le temps de creuser davantage, ça peut-être sujet à discussion.

[upsilandre]

Perso, la "Color, je ne l'ai pas connue, elle est sortie 7/8 ans après ma GB, ça m'intéresse moins, mais effectivement sur le papier, la NES semble à la ramasse. :)

C'est meme quasiment mieux qu'une GameGear. Je sais pas si y a vraiment eu un catalogue optimisé pour la Gameboy color mais faut que je jette un oeil.

[upsilandre]

Ca change de la NES et des banks CHR ROM que j'utilise systématiquement. Un avantage, c'est  qu'on ne gaspille pas de mémoire.

Devoir charger son tileset en VRAM ca reste aussi quelque chose de tres courant sur NES, c'est une grosse partie du catalogue.

 
Maintenant je me demande s'il est possible de réaliser des anims de background grâce au bankswitch .  De ce que j'ai vu on a 16ko fixes et 16 switchables, j'imagine que c'était grâce au cablage de la NES, mais j'ai pas eu le temps de creuser davantage, ça peut-être sujet à discussion.

Tu peux oublier la bankswitching.
A la limite sur GBC y a moyen de simuler un bankswitching en VRAM sur 4 bank et seulement pour le Background (pour le bankswitching en VRAM rien de mieux que la Coleco ).

[Stef]

Perso, la "Color, je ne l'ai pas connue, elle est sortie 7/8 ans après ma GB, ça m'intéresse moins, mais effectivement sur le papier, la NES semble à la ramasse. :)

C'est meme quasiment mieux qu'une GameGear. Je sais pas si y a vraiment eu un catalogue optimisé pour la Gameboy color mais faut que je jette un oeil.

Reste les tiles en 2BPP, c'est quand même une grosse différence avec la GG et ses tiles en 4BPP.

[upsilandre]

Mais a coté de ca t'as + de couleurs affichables (16 palettes 2bpp contre 2 palettes 4bpp), une palettes 15bit (contre 12bit). Un véritable second layer "window" pour le HUD (et le hud ca pose pas mal de probleme sur 8bit). 2 set de 384 tuiles. Un vrai DMA entre la VRAM et les mémoires activable pendant le Vblank et le Hblank (couplé a des tuiles 2bpp ca offre du potentiel). +25% de sprites par scanline (le probleme des 8bit). Du flipping de sprite (tout en ayant cette fois aussi le flipping de tuile BG et meme de la priorité a la tuile BG). Un CPU au moins 2x plus performants. 4x plus de RAM.
C'est pas mal quand meme. Je la voyais pas comme ca la GBC.

[Stef]

Ah oui bien sur elle est plus "puissante" que la GB, en même temps elle est arrivée tard la GBC : fin 1998 ! Soit (à 1 mois prêt) en même temps que la dreamcast ! Perso je la trouve vraiment très faible en comparaison de son année de sortie... même pour une portable. La résolution n'a pas bougée et puis les tiles en 2BPP laissaient (en tout cas pour moi) encore cette impression d'être sur la génération NES :-/ son seul intérêt c'était son autonomie malgré ses 2 seules piles LR6, mais techniquement elle était complètement à la ramasse.

[TotOOntHeMooN]

Clair, le 2bpp c'est juste la loose...

[Invité]

Ouai mais bon si c'est pour avoir une portable qui te bouffe 6 piles en 1h30, je vois pas vraiment l'intérêt non plus ,hormis des gfx en 4 bpp .
Et l'autonomie, c'est toujours ce qui a donné aux GB l'avantage en terme de vente sur les autres portables,même plus puissantes (et y'en avait bcp) .
Et c'était aussi surement un moyen pour nintendo d'améliorer sa GB et de rester compatible sans tout repenser et pour un prix similaire .

[vincent2105]

Je me laisse finalement tenter par ce fameux GBDK...
Passage au C donc, et tout n'est pas clair.

J'arrive à afficher un background d'après une tile map de 90 octets et de metatiles 16x16 px.
J'utilise une condition "switch" qui me permet de savoir quelle metatile afficher grâce à la fonction "set_bkg_tiles". Pour l'instant, je n'ai que 3 metatiles (vide, buisson, rocher).
Le problème, c'est que mon switch va s'allonger quand j'ajouterai d'autres metatiles, donc si j'en ai une cinquantaine, ça risque de ne pas être jo-jo. J'essaie de trouver une alternative (envoyer en paramètre l'adresse de la metatile à afficher)

[lincruste]

Pourquoi tu utilises une tuile pour le vide ? C'est obligé ?

[vincent2105]

J'ai une tilemap de 10 * 9 metatiles (de 16x16 px). 
Pour afficher un background j'utilise une boucle et j'affiche pour chaque octet de la tilemap la metatile voulue.

Voila la tilemap de l'exemple au dessus : 

Code:

unsigned char map[] =
  {
  0,0,1,0,0,0,0,0,2,0,
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,1,0,
  0,1,0,0,0,0,0,0,0,0,
  0,0,0,0,0,2,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,2,0,
  0,2,2,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0
    
  };

Donc "0" pour une zone vide de 16x16, "1" pour un rocher et "2" pour un buisson. 
Vu que je traite chaque octet, je suis obligé d'avoir une metatile "vide". 
Je sais pas si je suis plus clair 

[lincruste]

Parfaitement clair, merci.
Je me contentais de coller les tilemaps de tile map builder sans chercher à comprendre leur fonctionnement.