28Fermer30
RodolpheLe 17/01/2012 à 21:11
Merci GT Turbo pour les encouragements.
Je suis en train d'optimiser les accès IDE.
Ensuite je verrai pour finir le BURST du PLX DMA en lecture depuis SDRAM.
Le BURST dans l'autre sens ne peut pas donctionner du fait que le PLX est 2 fois moins rapide que la SDRAM et il aurait fallu 2 bus data séparés et bien plus de logique pour faire cette conversion de transfert.

Pour info, les accès actuels du CPU vers la RADEON se font en SINGLE (Long) access aloirs que le BURST avec des MOVE16 est possible et je recommande à fond aux dev d'utiliser le MOVE16.
Car le move 16 est le seul moyen de BURST en R & W sur le PCI (Radeon) avec le 060 puisque la zone PCI MEM de la CTPCI est declarée dans la PMMU du 060 comme NON CACHABLE.
Ces modes en BURST avec le move16 fonctionnent depuis le début.

J'ai vu la différence sur l'analyseur : c'est juste de la folie...
Dans la doc PLX c'est bien dit que si le MPC (060 pour nous) fait un accès single alors ce sera single sur le PCI
Si il fait un accès burst alors ce sera burst sur PCI.
J'ai demandé à Didier si y a pas des routines d'affichage qui pourraient se servir du move16 quand c'est pas déjà fait au DMA du PLX?
Regardez les copies écran jointes :
Entre B & C = 105ns pour 1 long (10 cycles)
Entre B & D = 545ns pour 4 longs (54 cycles ) en single donc.
Si on fait un move16 ça fait 155ns (15 cycles ).
--> gain de *3.6 !
Comme tu disais GT Turbo ? Ca décoiffe ?
Avis aux codeurs de jeux !tromb Fichier joint : X65q (Radeon accesses + NEC Master.jpg)tromb Fichier joint : YHTF (move16W.jpg)