New Double Dragon EP01
-
Gibs,
si tu utilises WinUAE je te conseille vivement de jeter un œil au DMA Debugger (Commande V depuis le Debugger d’UAE) : il est vraiment extra et détaille super bien la façon dont l’Amiga utilise les cycles DMA.
Le DF0 et l’audio arrivent en premier, de mémoire, et sont incompressibles (normal :), et ensuite c’est une alternance de datafetch des bit plans (l’Amiga décode les bitplans, également incompressible et donc prioritaire), de blitter et de cpu qui s’arrangent tout deux avec les cycles DMA restants sur le bus.
les sprites hard sont qqpart la dedans, avant le bitplane fetch, je crois.
Il faut juste penser à mettre UAE en mode cycle-exact sinon c’est open bar sur l’accès DMA et l’émulation n’est pas fiable 🙂
——————
Pour activer le DMA Debugger :
– lancer WInuae
– charger/lancer le programme à analyser
– Shift F12
– entrer ‘v -4’ (sans les guillemets). Les options vont de 1 (qui n’affiche rien?) à 4 qui occupe quasiment tout l’écran
– entrer ‘g’ pour relancer le CPU
– Enjoy!Le debugger affiche chaque cylce DMA/CPU ligne par ligne, à lire de gauche à droite.
Les codes couleurs (tirés du source de WinUAE) sont les suivants :
La façon dont sont attribuées les priorités entre les differents chips et le 68000 est très bien détaillée ici :
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html.. et ici :
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.htmlJ’ai du m’y reprendre à plusieurs fois pour vraiment comprendre, et le DMA Debugger m’a vraiment bien aidé à visualiser le fonctionnement des priorités DMA.
– Disk DMA, audio DMA, display DMA, and sprite DMA all have the highest priority level
– 4 cycles for memory refresh
– 3 cycles for disk DMA
– 4 cycles for audio DMA (2 bytes per channel)
– 16 cycles for sprite DMA (2 words per channel)
– 80 cycles for bitplane DMA
– The lowest priorities are assigned to the blitter and the 68000, in that order. The blitter is given the higher priority because it performs (..) much faster than the 68000En gros, plus il y’a de bitplanes à décoder, moins il y’a de cycles disponibles par ligne pour le blitter et le CPU. L’overscan occupe ainsi un peu plus le DMA (le nombre de pixels par ligne à décoder est plus important) et à partir du 5eme bitplan (en 32 couleurs, donc), le CPU commence à rater des cycles au profit du DMA.
« If the display contains four or fewer low resolution bitplanes, the 68000 can be granted alternate memory cycles (if it is ready to ask for the cycle and is the highest priority item at the time). »
Le pire étant en Hires :
» If you specify four high resolution bitplanes (640 pixels wide), bitplane DMA needs all of the available memory time slots during the display time (..). This effectively locks out the 68000 (as well as the blitter or Copper) from any memory access during the display »ça se voit hyper bien sur Project-X qui a son écran titre en Hires. Le bitplane fetch (en bleu) occupe la quasi totalité de l’écran (et donc des cycles DMA).
———————–
Quand à la question de combien de BOBs on peut tracer dans la frame, la question revient souvent dans les discussions sur le chipset OCS, et j’avais trouvé un élément de réponse ici (à prendre avec des pincettes) :
http://www.atari-forum.com/viewtopic.php?f=15&t=23530&start=25#p211848
Si je lis bien, le blitter peut transférer 70Kb par frame, en 16 couleurs, dans le meilleur des cas : soit presque l’équivalent d’un bloc de 128×128 (corrigez moi si je me trompe).
Dans le cas d’un jeu, qui réalise 5 ou 6 blits successifs (voire le double pour nettoyer la frame précédente), je suppose qu’on est en dessous de ces performances, puisqu’il faut prendre en compte les cycles d’inits du blitter.
Wait & see, j’attends avec impatience l’épisode 2 🙂
———————–
Désolé pour le pavé, Gibs ^^
Je profite de ta question sur les perfs brutes du blitter pour faire une synthèse de ce que j’ai compris sur le fonctionnement du DMA.
- Vous devez être connecté pour répondre à ce sujet.
