Orion_

je compile pas avec devpac, je compile avec mac sous dos

et c'est bien le routine vbl qui bloque, des que je la desactive ça fonctionne.

j'ai l'impression qu'il n'execute jamais la routine de la VBL en fait (donc que le flag n'est jamais a 1) ou alors y'a un probleme de synchro, peut etre les move.w #$101,INT1

move.w #0,INT2

je sais pas ...

j'utilise la méthode de GT, qui met une petite fonction en $100 aussi, qui met un flag a 1 pour dire que la vbl est passé et apres j'ai une fonction waitvbl qui attend que le flag soit a 1

Init:    move.l    d0,-(a7)

    move.l    #Vbl_rout,LEVEL0

    move.w    a_vde,d0
    ori.w    #1,d0
    move.w    d0,VI

    ori.w    #1,INT1

    and.w    #$f8ff,sr

    move.l    (a7)+,d0
    rts

Vbl_rout:
    st    Vbl_flag
    move.w    #$101,INT1
    move.w    #0,INT2
    rte

Wait_vbl:
    lea    Vbl_flag,a0
    sf    (a0)
Wait_une_vbl:
    tst.b    (a0)
    beq.s    Wait_une_vbl
    rts

j'ai tester sur l'emulateur, effectivement ça marche, sauf que les bouton ne fonctionne pas, donc on peu pas passer l'intro pour commencer le jeu :/

au passage j'aurais une question pour Seb, comment fait tu pour te synchroniser avec la VBL ? la routine que j'ai fonctionne sur jaguar mais pas sur l'emulateur, si j'en met pas sur emulateur ça fonctionne mais du coup sur jaguar c'est plus du tout synchro

..

toc toc toc

(mais vite fait alors)

vraiment du beau boulot, bravo RaZ

ok je comprend

le probleme c'est qu'il me faudrait soit un cache de 48Ko

soit un blitter qui est capable de faire des operations d'addition et saturation par octets :/

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 ...

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

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

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 :/

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

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 ...

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

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 :/

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

ah c bon, j'ai lu la doc, en fait c'etait VERT ROUGE RIEN BLEU

bon j'attaque au gpu ! parcequ'au 68k une copie d'un sprite 128x128 même optimisé a coup de movem.l, ça rentre pas dans la VBL

une question, j'ai vu que dans une routine startgpu, y'avais un waitgpu qui verifiait le G_CTRL.

comment on fait coté GPU pour le stopper ? on doit mettre G_CTRL a 0 nous même ? (le gpu ce stop lui même dans ce cas )

en fait c'est parceque mon sprite n'etait pas en mode 32bits dans la liste de construction ^^

bon par contre même en mettant les couleurs dans le bon ordre j'ai un sprite violet

graaaaaaaaa, decidement, va falloir que je mis fasse a ces bizarrerie

merci !

oui j'ai vu cette difference entre vos 2 code

mais LEVEL2 = LEVEL0 = $100

je viens de tester le mode RGB24, je comprend rien

visiblement chaque couleur est coder sur un .long et ce presente sous la forme $00BBGGRR

bon, ça c'est dans la pratique en testant couleur par couleur, apres quand j'essaye d'afficher une image

(heu bon, en écrivant cette phrase je viens de me rendre compte que mon image est en RGB et non BGR d'ou l'erreur des couleurs que j'avais)

bref, par contre j'ai des saut de ligne, comme si j'etait en entrelacé mais avec une image sur 2 :/

non non, l'emulateur fonctionne parfaitement avec VOS liste de sprite, c'est la routine VBL qu'il n'execute pas (celle dans LEVEL0)

heu non rgb16, je suis en train d'essaye rgb24 la ^^

bon !

probleme résolu

alors déja mon init de double buffer etait faite apres la première construction de la liste, donc déja ...

et ensuite, dans la boucle principale, la construction de la liste etait faite avant la synchro vbl, resultat l'image etait pas stable, donc maintenant je fait plutôt ça:

loop:

move.w #$AAAA, BG ; mesure vbl visuel

; traitement graphique etc...

; // ..

movea.l curscreen,a0 ; swap screen buffers

movea.l nxtscreen,a1

move.l a1,curscreen

move.l a0,nxtscreen

move.w #0, BG ; fin de mesure vbl visuel

jsr Wait_vbl(pc)

jsr Build_list

bra loop

bon apres avoir mis des qphrase partout ça change rien

apres j'ai soupçonner la routine d'attente VBL, la je la desactive et ça marche ...

je la reactive ça marche plus ... je rajoute 4 nop dans la routine d'interuption vbl ça marche

a devenir fou je vous dit

faut dire que en desactivant l'attente VBL j'ai vu que question execution dans la VBL j'etait vraiment short, il me restait a peine un quart d'HBL (j'utilise move.w #AAAA,BG | move.w #0,BG pour voir les temps d'execution à l'écran)

d'ailleurs c'est étrange car la routine d'attente VBL de GT Turbo ne fonctionne pas sur l'emulateur :/ (alors que d'autre rom fonctionne)

et sur jag j'ai l'impression que si le code tiens dans la vbl, on a un écran noir si il depasse la vbl ça s'affiche

comme je le disait a GT Turbo en msg privé, j'ai un écran noir quand j'ai un petit code, et j'ai un affichage correcte quand mon code est trop long a s'executer

en gros, avec un test d'affichage de polygone:

40 poly par frame -> écran noir

49 poly par frame -> affichage des poly mais avec des saut (je pense que ça rentre pas dans la vbl visiblement)

ma construction de liste doit pas être synchro

en fait le code de construction de liste est made in GT Turbo, et en 68000, le plus bizarre c'est que le premier test qu'il m'a donné fonctionnais et ne prennait que peu de temps a s'executer.

le coup des phrases j'y ai pas penser, j'vais voir ça ! (vu que j'utilise un double buffering, un des buffers est aligné, l'autre pas je crois )