 |
La NeoGeo est capable de faire le rendu d'une image
de 320 par 224 pixels, avec 4096 couleurs affichables simultanément
(sans tricher) sur une palette de 65536. La plupart des jeux n'utilisent
que 304 pixels en largeur, laissant une marge de 8 pixels noirs
à gauche et à droite.
Le rendu se fait d'une manière assez spéciale:
Il y a un plan fixe (souvent appellé "Fix
layer") qui peut comporter des pixels transparents et qui recouvre
tout l'écran (prioritaire).
Il utilise des tiles de 8x8 pixels, qui viennent du ROM S (ou des
fichiers .FIX sur NeoGeo CD). Il sert généralement
à afficher du texte comme les copyrights, les scores, les
barres de vie...
Tout le reste est considéré comme
des sprites.
Les fonds des jeux habituellement placés dans des couches
spéciales (backgrounds), sont ici formés par une suite
de sprites combinés.
Les sprites sont constitués de tiles de 16x16 pixels qui
viennent des ROMS C (ou des fichiers .SPR sur NeoGeo CD).
|
Une règle essentielle à retenir concernant
les couleurs: jamais plus de 16 couleurs par tile (que ce soit sur le
fix, ou dans les sprites). Tous les graphismes ont leurs couleurs codées
sur 4 bits.
Les sprites et le fix sont parametrés dans la RAM
vidéo (VRAM). Elle est complètement indépendante
de la RAM du 68K.
Elle est accessible qu'à travers des registres et elle est toujours
adressé en words (16 bits).
Le framebuffer n'est pas directement accessible: ce n'est
pas possible d'accédèr à la sortie vidéo pixel-par-pixel
sur les versions cartouche.
C'est peut être possible sur NeoGeo CD, mais ça serait probablement
très lent et donc inutile.
Les sprites sont controllés par 4 zones dans la
VRAM, appelées Sprite Control Banks, ou SCB.
Le fix n'a qu'une simple map.
 |
La pixel clock est à 6MHz, celà signifie
qu'un nouveau pixel est affiché toutes les 166.7ns.
Si on se réfère à l'horloge
principale (24MHz): Il y a 29 pixels de blanking à gauche,
320 pixels affichés, 7 pixels de blanking à droite
puis 28 pixels pendant la synchro horizontale.
Ce qui fait 29+320+7+28 = 384 pixels effectifs par ligne horizontale.
Il y a 8 lignes pendant la synchro verticale, 16
lignes de blanking, 224 lignes affichées, puis 16 lignes
de blanking.
Ce qui fait 8+16+224+16 = 264 lignes effectives par image.
La fréquence de rafraichissement est alors
de: 6 millions de pixels par seconde / 384 pixels de largeur / 264
pixels de hauteur = 59.18 images / seconde.
|
Notez bien qu'une adresse correspond à un word (16 bits), pas
à ses LSB/MSB.
 |
| Début |
Fin |
Taille |
Description |
| $0000 |
$6FFF |
$7000 |
Sprite Control Bank 1 (place
pour 512 sprites, mais seulement 380 sprites ont le temps d'être
affichés) |
| $7000 |
$77FF |
$800 |
Map du fix |
| $8000 |
$81FF |
$200 |
Sprite Control Bank 2. Un
word par sprite. |
| $8200 |
$83FF |
$200 |
Sprite Control Bank 3. Un
word par sprite. |
| $8400 |
$85FF |
$200 |
Sprite Control Bank 4. Un
word par sprite. |
| $8600 |
$865F |
$60 |
Géré par le
hardware. Liste des 96 sprites actifs pour la ligne en cours
de rendu (?) |
| $8680 |
$86DF |
$60 |
Géré par le
hardware. Liste des 96 sprites actifs pour la ligne en cours
d'affichage (?) |
|
L'adresse voulue en VRAM doit être écrite dans le registre
REG_VRAMADDR ($3C0000). Ce registre ne peut qu'être utilisé
en 16 bits et on ne peut pas le relire.
Les données sont lues et écrites dans le registre REG_VRAMRW
($3C0002), en words également.
Le GPU possède une fonction d'auto-incrémentation ou décrementation
de l'adresse en VRAM à chaque écriture (l'adresse ne change
jamais après les lectures).
La valeur du déplacement peut être écrite et lue dans
REG_VRAMINC ($3C0004), la valeur est signée et permet donc
aussi de décrementer l'adresse.
Par exemple, $0001 incrémente l'adresse de 1, et $FFFF la décrémente
de 1.
Il est conseillé d'attendre quelques cycles entre des écritures
successives en VRAM.
Des écritures trop rapides peuvent être l'origine de problèmes
sur le vrai hardware.
|
Github
