Jump to content
Jagware

Orion_

Level1
  • Content count

    1,073
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Orion_

  1. Génération de nombres aléatoires

    un petit truc que j'avais converti en 68000 d'une routine en C trouvé je sais plus ou ça marchais asser bien ^^ resultat dans d0, par contre ça donne un resultat 8bits ; Un VRAI random :) (pas comme celui du XBios ...) myrand: move.w seed8_1(pc),d1 move.b 0(a0,d1.w),d0 move.w seed8_2(pc),d2 add.b 0(a0,d2.w),d0 move.b d0,0(a0,d2.w) addq.b #1,d1 addq.b #1,d2 andi.b #63,d1 andi.b #63,d2 move.w d1,seed8_1 move.w d2,seed8_2 rts seed8_1: dc.w 29 seed8_2: dc.w 63 random8: dc.b 215,25,169,8,231,201,91,15,156,5,152,30,159,50,22,49 dc.b 28,148,157,123,58,3,156,236,46,78,50,157,186,170,233,138 dc.b 49,98,215,231,0,249,233,254,194,12,110,115,122,166,15,2,163 dc.b 237,143,30,54,5,45,199,201,106,184,136,44,175,197,11
  2. Atomix, Jag Version

    merci ! je viens de regarder et c'est effectivement le même code que j'utilise, c'est vraiment très étrange !
  3. Atomix, Jag Version

    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 ...
  4. Atomix, Jag Version

    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
  5. Atomix, Jag Version

    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
  6. Liste de possibilité de jeux :

    toc toc toc (mais vite fait alors)
  7. Et Voilà Le Nouveau Jagware !

    vraiment du beau boulot, bravo RaZ
  8. le GPU

    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 :/
  9. le GPU

    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 ...
  10. 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
  11. le GPU

    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
  12. le GPU

    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 :/
  13. le GPU

    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
  14. le GPU

    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 ...
  15. le 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
  16. le GPU

    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 :/
  17. le GPU

    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
  18. modification de la jag pour kit bjl

    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 )
  19. modification de la jag pour kit bjl

    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
  20. modification de la jag pour kit bjl

    graaaaaaaaa, decidement, va falloir que je mis fasse a ces bizarrerie merci !
  21. modification de la jag pour kit bjl

    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 :/
  22. modification de la jag pour kit bjl

    non non, l'emulateur fonctionne parfaitement avec VOS liste de sprite, c'est la routine VBL qu'il n'execute pas (celle dans LEVEL0)
  23. modification de la jag pour kit bjl

    heu non rgb16, je suis en train d'essaye rgb24 la ^^
  24. modification de la jag pour kit bjl

    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
×