Orion_ Posted January 12, 2006 Report Share Posted January 12, 2006 bon, déja un grand merci a GT Turbo pour toute ces explications, et ces bases de code qui m'ont permis de commencer ^^ helas je suis pas aller bien loins, je bloque déja sur le GPU a mon avis c'est pas bien méchant mais je trouve pas le probleme ... en effet, avant de me remettre au 68k je voudrais tester un peu l'assembleur GPU ^^ alors y'a mon code GPU qui ressemble betement a ça: .long .GPU .org $f03000 GpuCode: movei #GpuCode, r29 nop nop jump (r29) .long GpuEnd: .68000 (j'ai pas trouvé d'autre manière d'utiliser Jump, de toute façon ça fait pareil avec jr GpuCode) visiblement sur l'émulateur (project tempest), le gpu fait soit un jump en mémoire, soit avance a toute vitesse pour arriver en 0xE00000 ou quelque chose le fait visiblement tourner en rond pour charger mon code j'utilise ça: [code] jsr GpuInit jsr GpuStart ;**************************** ; Init GPU GpuInit: move.l #0,G_CTRL ;arreter le GPU move.l #0,G_FLAGS ;initialiser les FLAGS du GPU move.l #$00070007,G_END ;GPU en mode BigEndian (mode compatible 68000) move.w #%11010111001100,MEMCON2 ;memoire en mode BigEndian move.l #GpuCode,a0 move.l #$f03000,a1 move.l #GpuEnd,d7 sub.l a0,d7 lsr.l #2,d7 copygpucode: move.l (a0)+,(a1)+ dbra d7,copygpucode rts ;************* GpuStart: move.l #$f03000,G_PC lea G_CTRL,a0 move.l #1,(a0) ;waitgpu: ; move.l (a0),d0 ; btst #0,d0 ; bne.s waitgpu rts ;************** the question is, what is the problem ? :/ Quote Link to comment Share on other sites More sharing options...
cts Posted January 12, 2006 Report Share Posted January 12, 2006 Pas de nop après le jump ? L'instruction à l'adresse mémoire juste après le jump est préchargée/executée. Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 12, 2006 Author Report Share Posted January 12, 2006 mmh même avec ça, ça fait pareil :/ Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 13, 2006 Author Report Share Posted January 13, 2006 les bizarrerie de la jag ... en mode RGB16, mes couleurs sont dans l'ordre Rouge BLEU Vert Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 13, 2006 Report Share Posted January 13, 2006 Je pense en parti car il manque le nop après le jump dans le code GPU. Je pense surtout qu'il y a une erreur dans le code 68000 : tu fais : move.l #GpuCode,a0 move.l #$f03000,a1 move.l #GpuEnd,d7 Or d'après le code GPU, GpuCode serais egal a $F03000. Donc tu copies du code a l'adresse $F03000 a l'adresse $F03000 (donc resultat imprevisible lors de l'execution du code GPU) Pour que tu puisses faire un truc de ce genre, il faut ecrire : [code] .long GpuCode: .GPU .org $f03000 Main: movei #Main, r29 nop nop jump (r29) nop .long .68000 GpuEnd: C'est ce que je fais et ca fonctionne (sauf si j'ai fais une erreur en recopiant ). Quote Link to comment Share on other sites More sharing options...
GT Turbo Posted January 13, 2006 Report Share Posted January 13, 2006 les bizarrerie de la jag ... en mode RGB16, mes couleurs sont dans l'ordre Rouge BLEU Vert Les notres aussi je te rassures !! [english] Don't panic !! Mine too !! GT Dans le mauvais ordre Quote Link to comment Share on other sites More sharing options...
cts Posted January 13, 2006 Report Share Posted January 13, 2006 Je pense surtout qu'il y a une erreur dans le code 68000 : tu fais : Code: move.l #GpuCode,a0 move.l #$f03000,a1 move.l #GpuEnd,d7 Or d'après le code GPU, GpuCode serais egal a $F03000. nonon, c'est correct. GpuCode est 'ORGé' à $F03000 mais pas encore recopié à cette adresse... Tu t'es couché tard non ? Par contre, je me rapelle avoir eu quelque souscis en sautant direct à une adresse contenant un movei... GpuCode: nop movei #GpuCode,r0 nop jump (r0) nop GpuEnd: Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 13, 2006 Report Share Posted January 13, 2006 ben oui justement, vue que GpuCode est 'orgé' a $F03000, il vaut donc $F03000. Et donc, le code 68000 copie ce qui est a l'adresse $F03000 a l'adresse $F03000 qui n'est pas ce que l'on veut faire... Donc il faut faire comme je l'ai expliqué precedement. Sinon, j'ai jamais eu de problemes avec un saut directement suivit pas un movei.. Peut-être qu'il pourait y avoir un probleme lorsque le movei n'est pas aligné sur un long et que par chance je n'ai jamais eu ce cas... Quote Link to comment Share on other sites More sharing options...
cts Posted January 13, 2006 Report Share Posted January 13, 2006 bien vu, c'est moi qui ai besoin de sommeil ! :/ Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 13, 2006 Author Report Share Posted January 13, 2006 c'etait bien ça, merci ^^ Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 19, 2006 Author Report Share Posted January 19, 2006 pfff, j'ai commencer a coder au GPU et je pensais que ça ne fonctionnais pas (parcequ'evidement ça ne fonctionne pas pour changer ...) parceque ma routine (pourtant simple) etait mauvaise, bon ben perso j'ai pas trouvé, apres quelques test j'en suis presque arrivé a la conclusion que mon stop de gpu ne fonctionnais même pas ... et j'arrive a un resultat super bizarre a l'ecran (en utilisant BG) si quelqu'un pouvais m'eclairer, je suis au bord de la depression la :/ jsr GpuInit loop: move.w #$AAAA,BG jsr GpuStart movea.l curscreen,a0 ; swap screen buffers movea.l nxtscreen,a1 move.l a1,curscreen move.l a0,nxtscreen jsr Wait_vbl(pc) ; attends la VBL jsr Build_list ; Reconstruit la liste move.w #0,BG bra loop ; et boucle ;**************************** ; Init GPU GpuInit: move.l #0,G_CTRL ;arreter le GPU move.l #0,D_CTRL ;arreter le DSP move.l #0,G_FLAGS ;initialiser les FLAGS du GPU move.l #0,D_FLAGS ;initialiser les FLAGS du DSP move.l #$00070007,G_END ;GPU en mode BigEndian (mode compatible 68000) move.l #$00070007,D_END ;DSP en mode BigEndian move.w #%11010111001100,MEMCON2 ;memoire en mode BigEndian ; move.w #$ffff,BORD1 ; move.w #$ffff,BORD2 move.l #GpuCode,a0 move.l #$f03000,a1 move.l #GpuEnd,d7 sub.l a0,d7 lsr.l #2,d7 copygpucode: move.l (a0)+,(a1)+ dbra d7,copygpucode rts ;************* GpuStart: move.l #$f03000,G_PC lea G_CTRL,a0 move.l #1,(a0) waitgpu: move.l (a0),d0 asr #1,d0 bcs waitgpu rts ;************** .GPU .long GpuCode: .org $f03000 nop nop movei #nxtscreen,r0 ; on veut recuperer le contenu de nxtscreen, donc d'abord on precharge son adresse movei #newflare,r1 ; on interlace le temps que la fonction d'en haut s'execute, adresse du sprite load (r0),r0 ; charge l'adresse du screen suivant (double buffering) movei #128*128,r3 ; nombre de pixel a copier gpuloop: nop ; nop de suretée load (r1),r2 nop addq #4,r1 ; avance d'un pixel (et atten que r2 soit traité) store r2,(r0) nop addq #4,r2 ; avance d'un pixel subq #1,r3 ; nombre de pixel-- or r3,r3 ; fini ? jr ne,gpuloop ; si non, on strop nop nop moveq #0,r0 movei #G_CTRL,r1 nop ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ... store r0,(r1) nop nop .long GpuEnd: .68000 Quote Link to comment Share on other sites More sharing options...
GT Turbo Posted January 20, 2006 Report Share Posted January 20, 2006 Plusieurs choses, tu est en train de tout faire en TC 24 bits ? Laisse tomber ce mode, le bus en prend plein la gueule et au niveau des sprites tu est super limité (Pas de zoom, etc...) Attention que ton code 68000 viennent pas en conflit avec les procs, des mesures de Vbl que j'ai faites on été plombés a cause du //. Fait une boucle d'attente du 68000 jusqu'a que le Gpu est fini, ceci juste pour faire des essais, je vais pas te conseiller d'oublier d'utiliser le 'full //'. subq #1,r3 ; nombre de pixel-- or r3,r3 ; fini ? jr ne,gpuloop; si non, on strop Tu peux dégager ton 'or r3,r3', tous mes codes tournent sans ce bricolage, mefie toi car beaucoup des conseils d'Atari que j'ai appliquer a la lettre ne change rien du tout. le Subq avant le jr fonctionne sans rajout. moveq #0,r0 movei #G_CTRL,r1 nop ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ... store r0,(r1) nop nop Le Nop avant le store change rien, jai essayé, par contre ce après il les faut. C'est quoi le résultat a l'écran ? Pourquoi tu veux faire de la copie de sprite ? A premire vue ton code est correcte vérifie peut etre tes adresses en r0 et r1 et n'oublies pas que celle ci doit etre aligné sur la taille des données lu / écrites, donc ici des longs. Car ce genre de blague j'ai assez donnée, résultats bizzares et le code est bon ! [english] Some questions, are you working in TC 24 bits ? Forget this mode, the bus are too much used and with the sprites a lot of operations are non-working (Zoom, etc...) Beware than our 68000 code doesn't make a colision with the procs, some Vbl measurements i have done was false because parallel working. Make a 'wait boucle' until Gpu has ended, just for some trys, i don't want to say forget parallel working. subq #1,r3 ; nombre de pixel-- or r3,r3 ; fini ? jr ne,gpuloop; si non, on strop You can kill 'or r3,r3', all my codes run without it. Some atari documentations that i have used do anything in more or less... 'Subq' can work alone moveq #0,r0 movei #G_CTRL,r1 nop ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ... store r0,(r1) nop nop Nop before Store doesn't change anything, i have yet tried, but after you need it. What can you see on screen ? Why do you want to do sprite copy ? A first sight, our code is right, just verify our adress in r0 and r1 and don't forget they must we aligned on data length, so here it must be long word aligned, if you don't align them, that will give some special effects !! GT Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 mon code sera plus lent en 16bits qu'en 24 pour l'instant je fait juste une recopie de sprite, mais c'est juste un debut, le but final est tout autre ^^ comme tu peu le voir dans mon code 68000 j'attend le GPU le resultat a l'écran est .. noir c'est ça qui est super frustrant parcequ'on ne sais pas d'ou ça viens ! vu que y'a aucun debugger rien :/ Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 a tiens je viens de m'apercevoir que le BJL faisait debugger quand ça plantait, pratique par contre c'est possible de le planter expres pour voir les valeurs de registre a un certain moment ? (je crois déja que mon loader GPU ne fonctionnais pas bien, parceque sur l'emulateur j'avais un PC de GPU faux, la ça a l'air de mieux fonctionner, mais toujours écran noir enfin je debug, je debug ^^) au passage j'ai fait quelque test, sur ma télé pour avoir un fullscreen il faut que je place le sprite (qui est mon framebuffer en fait) en: X=44, Y=35 pour etre au coin haut-gauche de mon écran et j'ai une resolution d'environ 320x268 Quote Link to comment Share on other sites More sharing options...
GT Turbo Posted January 20, 2006 Report Share Posted January 20, 2006 Tu fais un illegal pour planter le code, cela permet d'arreter ton code ou tu veux, et tu peut lire les vals des registres. Tes adresses sont alignés ? [english] Just do an 'illegal', that stop the code and you can read registers on Bjl main screen. Word aligned the adress ? GT Planté Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 bon, voila mon code GPU fonctionne ! et oui, on oublie trop souvent les NOP apres un JR !!!! .long GpuCode: .GPU .org $f03000 movei #nxtscreen,r2 movei #newflare,r1 load (r2),r0 movei #768,r5 movei #128,r3 ; Y gpuloopY: movei #128,r4 ; X gpuloopX: load (r1),r2 store r2,(r0) addq #4,r1 ; avance d'un pixel addq #4,r0 subq #1,r4 ; X-- jr ne,gpuloopX nop add r5,r0 ; next screen line subq #1,r3 ; Y-- jr ne,gpuloopY nop moveq #0,r0 movei #G_CTRL,r1 store r0,(r1) nop nop .long .68000 GpuEnd: le probleme, c'est que ce code ne tiens pas dans la VBL !!! j'suis déçu la ou est donc la rapiditée du GPU ... Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 bon laissez tomber ce que j'ai dit, ça tiens dans la VBL simplement le 68000 attendais que le GPU est fini et ensuite recontruisait la liste, la j'attend plus et la liste je la construit une fois, apres je la recopie avec 2 movem.l a chaque frame Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 20, 2006 Report Share Posted January 20, 2006 je me disais bien que ct bizarre que ca ne rentrée pas dans la VBL. Vue qu'il y a des codes au GPU qui sont bien plus compliqué (native) qui rentre dans la VBL... Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 bon ça y est, maintenant que je commence a mieux comprendre le GPU ça commence a me plaire je trouve que le GPU est génial, parceque on a l'avantage d'un RISC ! et contrairement aux processeur ARM, on peut charger des valeurs .long sans probleme ! (movei) alors qu'avec un arm non :/ (faut faire des décalages et autre parceque les instructions ARM faisant 32 bits on peut evidement pas caser uen valeur longue + un code d'instruction dedans ) et y'a une instructions que j'adore particulièrement et que j'ai jamais vu autre part, c'est SAT ! ça me permet de faire un petit effet pour pas un rond de temps CPU ! alors que sur n'importe kel autre processeur faut ce taper un cmp puis un jump conditionnel :/ Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 j'emet une hypothése sur le prechargement du GPU. on part du fait qu'il est 64bits il charge donc ces instructions par 64bits, chaque instruction faisant 32bits c'est pour ça qu'il en charge 2 a chaque fois mais ça pose un probleme pour les instructions genre movei qui font elle 64bits (32bits pour l'instruction et 32bits pour la valeur a charger) voila pourquoi: movei #5,r5 loop: subq #1,r5 jr ne,loop addq #1,r5 fait une boucle infinie, et si on remplace addq par movei #5,r5, le compilateur nous insert automatiquement un nop entre jr et movei, vu que movei ne sera chargé qu'a moitier Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted January 20, 2006 Report Share Posted January 20, 2006 Orion_ : contrairement aux processeur ARM, on peut charger des valeurs .long sans probleme ! (movei) alors qu'avec un arm non :/ (faut faire des décalages et autre parceque les instructions ARM faisant 32 bits on peut evidement pas caser uen valeur longue + un code d'instruction dedans ) Déjà vécu aussi, et ce que ça peut être c...Orion_ : y'a une instructions que j'adore particulièrement et que j'ai jamais vu autre part, c'est SAT !ça me permet de faire un petit effet pour pas un rond de temps CPU ! alors que sur n'importe kel autre processeur faut ce taper un cmp puis un jump conditionnel :/ Je proteste, ça existe aussi dans les instructions MMX (et tu peux même en faire 2 ou 4 en parallèle) (Bon, avant que GT Turbo ne s'énerve, je ne pense pas que le Pentium le fasse en un cycle non plus )Au passage, Orion_, tu fais de l'assembleur x86 aussi ? Parce que si oui il ne va plus rien me rester Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 heu oui un tout petit peu d'arm sur GP32 et pocketstation, du x86 sur pc et 186 sur wonderswan, du 68000 sur TI/atari st et jag, du GPU maintenant et de l'assembleur 8bits inconnu sur pokemon mini Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 20, 2006 Author Report Share Posted January 20, 2006 bon et au passage je confirme, le code si dessus est limite, je l'ai converti pour qu'il copie chaque R G et B separement, en faisant un peu de traitement dessus, et mon truc tiens en 1.3 VBL sans compter qu'il faut que je rajoute le blitter pour effacer mon écran a chaque fois :/ pas si rapide que ça le gpu ... Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 20, 2006 Report Share Posted January 20, 2006 Orion_ : j'emet une hypothése sur le prechargement du GPU. on part du fait qu'il est 64bitsil charge donc ces instructions par 64bits, chaque instruction faisant 32bits c'est pour ça qu'il en charge 2 a chaque fois mais ça pose un probleme pour les instructions genre movei qui font elle 64bits (32bits pour l'instruction et 32bits pour la valeur a charger)voila pourquoi:movei #5,r5loop:subq #1,r5jr ne,loopaddq #1,r5fait une boucle infinie, et si on remplace addq par movei #5,r5, le compilateur nous insert automatiquement un nop entre jr et movei, vu que movei ne sera chargé qu'a moitier En fait, les instructions GPU sont en 16bits.et le bus des instructions du GPU est en 32bits.Le bus des datas (le bus externe) est quand a lui en 64-bits. (simple non )Et donc lorsque tu executes une instructions GPU, le GPU en charge 2 par cycles en général (prefetch) sauf pour l'instruction movei qui est une instruction sur 48bits. donc qui est chargé en 2 fois avec l'instruction qui suit ou qui precede selon l'alignement de movei sur une adresse 32bit ou 16bit.Citation bon et au passage je confirme, le code si dessus est limite, je l'ai converti pour qu'il copie chaque R G et B separement, en faisant un peu de traitement dessus, et mon truc tiens en 1.3 VBL sans compter qu'il faut que je rajoute le blitter pour effacer mon écran a chaque fois :/pas si rapide que ça le gpu ... en fait, c'est pas le GPU qui est lent c'est le bus qui est plombé par le 68000.en plus, si tu utilises des accés a la ram sans arret avec des loadb,w et storeb,w ca ralenti a mort les accés car l'attente pour la lecture d'une valeur sur le bus (même si il est 64bit) est très long comparé a la mémoire interne : en interne c'est entre 3 et 4 cycles, en externe c'est bien plus long (tout depend de l'utilisation du bus par les autres processeurs)En plus, les GPU/DSP ne sont pas concu pour faire des transferts de données mais pour calculer et faire des accés de temps a autre.C'est pourquoi, il est bien plus interressant de faire des copies par le Blitter qui lui est concu pour la copie des données. Quote Link to comment Share on other sites More sharing options...
SCPCD Posted January 20, 2006 Report Share Posted January 20, 2006 Orion_ : movei #5,r5loop:subq #1,r5jr ne,loopaddq #1,r5fait une boucle infinie [...] En fait, dans ce cas, je pense qu'il y a peut être 2 sources d'erreur :- il y a peut être un bug lors de la resynchro des instructions dans le cas où l'instruction de retour n'est pas aligné sur une adresse 32bit- il ne faut pas oublié que le GPU/DSP execute toujours l'instruction qui suit un jump/jr donc dans ce cas, je ne sais plus trop comment il gere les flags pour le saut. Quote Link to comment Share on other sites More sharing options...
Recommended Posts