SCPCD

Je ne connais pas grand chose sur ce genre de truc mais c'est vrai que le site Cafzone rend vraiment bien.

 

Plein d'options en plus (est-ce que l'on les utiliseras toutes ? : un jours sans doute ...), avec sans doute moins de limites au niveaux possibilités et tout et tout

 

donc pkoi pas ?

load (r7),r4 ; Charge le X1

load (r6),r3 ; Pareil mais pour le X2



Boucle :

sub r3,r4

puis une dizaine de ligne et :



addq #4,r7

addq #4,r6

load (r7),r4 ; recharge X1



Puis vint une boucle de synchro et après on reboucle a 'boucle'



Ca donne le meme résultat que celui au dessus (mais la on a une instruction en moins dans la boucle !!) 



GT Perdu !! 



Je ne sais pas ce que tu fais dans les lignes non données mais si tu ne modifi pas le r3, alors ca parait logique qu'il n'est pas necessaire de mettre le load (r6),r3. 



Par contre, je n'ai pas encore trouvé l'explication de l'erreur sur le premier code...

A moins qu'il y est un bug dans le GPU sur les sauts qui en fait ce tromperais dans le calcul de la position du PC dans certains cas mais je ne me rappelle pas que ca a été decrit dans la liste des bugs.

Une autre possibilité serais qu'il y est un bug dans l'assembleur MADMAC dans le calcul de l'adresse de retour dans certaines combinaisons.....

J'ai essayé ton prog

 

Je n'arrivais pas à le lancé mais en fait, c'est moi qui n'envoyé pas le prog avec la bonne commande

 

 

 

J'ai remarqué qu'il y avait un(ou 2) pixel(s) qui restait figé au milieu de l'ecran je sais pas si c'est normal ou pas...

 

 

 

Sinon, OUAOU !!! la fluidité !!! en 68000 en plus !!

 

 

 

Vivement la version face pleine !

 

Bon boulot !!

HHAAA...

 

Les joies du debuggage du GPU !!!

 

 

 

 

 

Que du bonheur !!

 

En tout cas tu fais un sacret boulot !!

 

 

J'ai hate d'avoir la demo sur une CF

Bienvenue à toi !

 

 

 

Pour les codes conditions, madmac ne les possedent pas tous...

 

il faut donc les declarer soit même dans le programme DSP/GPU

 

 

 

voila ce qu'il faut écrire par exemple dans la section GPU/DSP:

 

 

 

Plus_petit_ou_egal .ccdef %11000

 

 

 

la liste des codes conditions implémenté par MadMac est :

 

 

CC %00100

 

CS %01000

 

EQ %00010

 

MI %11000

 

NE %00001

 

PL %10100

 

HI %00101

 

T %00000

 

 

et voici tous codes conditions :

 

 

 

 

 

Que direz vous d'un Metal Slug !!! (version compilation des 5 episodes )

Ben en fait, ca depend.

Le system d'interruption sera plus rapide je pense que dans le cas où l'on met en veille le 68000 en attendant une interruption.

Parceque dans les autres cas, on spam le bus pour ne rien faire :

lorsque l'on accede aux registres, le bus est ralentit par la lecture du 68000

mais dans le cas où l'on veut faire des interruptions sans le mette en veille, c vrai que ca risque même d'être plus lent vu que lorsque le 68000 a une interruption, son niveau de priorité d'execution est plus élevé que normalement donc ralentit tout...



(Mais pkoi ils ont mis un 68000 !!! et pas un autre DSP !!!)

lea G_CTRL,a0

move.l #1,(a0)

Wait : move.l (a0),d0

bne.s Wait







je comprends pourquoi ca ne marche pas !!

car lorsque tu lit G_CTRL, tu ne lis pas exactement la valeur de CTRL ecrit par le GPU !!!

Car lorsque tu lis, il y a la version du processeur dans les bits le plus haut, et les latchs interruptions qui ne sont egal a 0 que si tu as ecrit un 1 dedans !



il faut donc juste tester le bit 0 de ce registre.

Cela viens peut-être du 68000 :

 

Comment tu fais pour tester le GPUGO ?

 

Parcequ'il y a un bug dans la jag pour certaines instructions 68000 lors de l'accés a des registres GPU/Blitter...etc....

 

c'est indiqué dans la liste des bugs pour l'ecriture mais pour la lecture je sais pas si c pareil (je pense que oui)

 

 

 

Ensuite, sinon tu as plusieurs autres possibilité :

 

- générer une interruptions sur le 68000

 

- utiliser une adresse dans la RAM GPU pour indiquer qu'il a fini et tu lis au 68000 cette adresse en permanance.

 

 

 

La premiere est celle qui donnera plus de peche au GPU mais la deuxieme est la plus simple a ecrire.

 

 

 

Je me rappelle que j'avais aussi des trucs bizarre avec le GPU lorsque je voulais verifier qu'il etait arreté.

 

Du coup je faisait comme Native c'est a dire la seconde solution ecrite au dessus.

 

 

wait_for_gpu:

 

move.l All_Done,d0

 

cmpi.l #$12345678,d0

 

bne.s wait_for_gpu

 

move.l #0,All_Done

 

 

un truc de ce genre

 

Et normalement, en faisant :

 

[code]

 

moveq #$12345678,r30

 

movei #All_Done, r31

 

store r30, (r31)

 

; GPU stoppen

 

moveq #0,r30

 

movei #G_CTRL,r31

 

store r30,(r31)

 

 

ca devrais fonctionner puisque je l'ai deja fait et dans Native aussi c pareil...

 

 

 

mais peut-être que en ne faisant que

 

[code]

 

wait_for_gpu:

 

move.l G_CTRL,d0

 

btst.l #0,d0

 

bne.s wait_for_gpu

 

 

ca fonctionnerais... (si tu ne fais pas deja ca )

A non je me suis trompé

 

J'ai verifié dans un de mes codes et j'ai bien fait comme toi...

Pour le GPUGO (Start/Stop du GPU), tu le fais comment ?

 

Parceque, seul le GPU peut le remettre a Zero et il faut le faire en soft : c'est a dire en lisant le G_CTRL et en mettant a 0 le bit 0 puis de reecrire le resultat dans le registre.

 

Mais du fait du pipeline, le GPU ne stop pas immediatement, il peux executer plusieurs instructions après si elles peuvent rentrer dans le pipeline avant la demande d'arret du GPU.

 

 

 

Multiplié par au moins 3 !! rien qu'en reecrivant au GPU !!

 

et sans optimisation, je suis sur !!

 

 

 

GPU PPPPPPOOOOOOOOOWWWWWEEEERRRRRRR

OK

 

Merci.

Salut !

 

 

 

Je voulais savoir :

 

qu'elles sont les données modifiées par le OP exactement ?

Je pense qu'ils veulent dire qu'il est possible de faire du remplissage de polygone en un passage....

 

Mais je ne sais pas comment on fais le remplissage de polygone normalement alors...voila quoi...

Oui, et il serais même possible en theorie d'atteindre 200sprites/lignes*256lignes=51200 sprites par vbl.

 

mais là je pense qu'il n'y aurais pas assez de place mémoire dans la RAM pour stocker la liste

Ben en fait, , j'utilise aussi make.ttp.

du coup je fais un 'makefile' qui contient les 2 lignes precedentes et il suffit juste ensuite de lancer make.ttp sans parametre et il fait tout tout seul. (bien sur, il faut que make.ttp soit a coté du makefile)

sinon, pour lancer un makefile qui n'est pas dans le dossier ou il y a make.ttp, il faut lui donner comme parametre -f addr/nom_file



bien sur, le makefile est structuré d'une certaine facon :

ex: (il faut metre une tabulation devant aln et mac)

J'utilise les compilateurs ATARI

 

je sais pas pkoi je n'ai pas indiqué avant la procedure que j'utilise...

 

 

 

pour compiler :

 

mac.ttp -fb -u -iincludes/ main.s -s

 

-fb je sais plus il faut que je relise la doc

 

-u permet la globalisation automatique des symboles non definis

 

-s c'est pour qu'il t'indique les branchs 68000 que tu peux optimiser (en faisant bra.s ce genre de truc)

 

-i suivi du nom de dossier a inclure si tu utilise des includes sans l'adresse complet (ex : .include "jaguar.inc" et que 'jaguar.inc' est dans le dossier 'includes') (le nom du dossier doit être collé au '-i')

 

tu dois optenir un 'main.o'

 

 

 

pour linker :

 

aln.ttp -o test.bin -n -w -rq -a 4000 x x main.o

 

 

 

-n pas de file header

 

-w activation des warnings

 

-rq c pour aligner chaque segment (text, data, bss) sur une quad phrase (32octets)

 

tu peux ou bien metre :

 

-rw -> word

 

-rl -> long

 

-rp -> phrase

 

-rd -> double phrase

 

-a text data bss : c pour choisir l'adresse de l'organisation des différentes sections :

 

ex:

 

4000 -> adresse de debut du segment TEXT : le code 68000

 

x -> adresse des datas, si ce n'est pas une valeur mais 'x', c'est automatiquement mis a la suite du segment TEXT

 

x -> adresse de la section BSS idem que precedement sauf que ce sera mis a la suite des DATAS

OK

 

Tu devrais voir aussi pour utiliser les 'Branchs'.

 

Comme ca, tu pourras, par exemple, decouper ton ecran par paquets de 200 sprites toutes les 16 lignes. -> 200sprites/paquets*(256lignes/VBL)/(16lignes/paquets) = 3200 sprites/VBL

 

mais ca complique un peu la creation.

Juste une question :

 

Comment tu fais pour que la liste fonctionne sans devoir remettre a jours la liste a chaque VBL ?

 

vue que le OP, si je ne me trompe pas, modifie des champs dans la liste ???

J'ai dejà eu ce probleme de parasitage voir d'erreur de superposition des sprites :

 

le sprite qui est au dessus ce retrouve a moitié coupé en diagonal par le sprite qui est en dessous....

 

 

 

je pense que ce probleme peut être causé par différents cas :

 

- il y a trop de sprites et le processeur d'objet n'arrive pas a lire suffisament vite dans la RAM pour les gérer. (ca depend aussi de la largeur des sprites)

 

Je pense que c'est ton cas GT : la bande passante de la Jag doit être saturée lors du chargement de la ligne par le OP.

 

ex : j'arrivais a faire 7 plans en 640*250 et 16bits en 1VBL plus 1 en 640*30

 

ce qui correspond a charger 640*8*2= 10240octets par lignes

 

pour toi GT : 200*37*2 = 14800octets par lignes a charger.

 

Donc a mon avis on touche a la limite de l'OP par ligne.

 

(sauf si on stop le 68000 )

 

 

 

- le code de génération de la liste d'objet prend trop de temps sur le bus et le OP n'a pas assez de temps pour tout lire en 1 VBL

 

 

 

 

 

Le fais d'utiliser le même sprite, je ne pense pas que ca change quelque chose, vu que l'OP accedera exactement de la même facon a la mémoire independament du sprite suivant. (sinon, il faudrais qu'il precharge les valeurs du sprite suivant et qu'il fasse un pre traitement ce qui n'est pas indiqué dans la doc)

Je ne sais pas du tout quelle emulateur ATARI peu utiliser les port //

 

Mais sinon, il serait possible de recoder ce qu'a fais GT pour windows.

 

(dès que l'on connait le principe c'est du tout cuit, il reste a faire l'interface windows et recoder en C/C++ pour pas ce faire chier sous win et voila)

 

Dans un premier temps il faut voir ce qui existe :

 

Madmac et ALN linker existe sur PC aussi mais je crois qu'ils bugguent sous XP.

 

Donc il faut Dosbox ou equivalent qui permet d'emuler un PC DOS sous win.

 

donc pour la compilation ca devrais aller.

 

et ensuite, il faut utiliser le loader bjl.

 

 

 

Dès que j'ai fini le CF, je pourrais convertir les outils de GT sur Windaube.