1

bonjour,

je sais que le GPU accède bien plus vite à sa ram que à la ram centrale.
idem pour le DSP
mais est ce que le GPU accède plus vite à la ram du DSP qu'à la ram centrale ? ( bus différent ? mémoire physiquement différente ? )
avatar

2

Ça c'est une question pour SCPCD smile
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

3

J'ai jamais fait de mesures sur ce cas de figure, mais j'aurais tendance à dire que c'est plus lent d'accéder à la RAM du DSP à partir du GPU qu'à la DRAM.

Je peux essayer de faire un test avec analyseur logique ce weekend.
avatar

4

oui ça serait intéressant, c'est toujours une bonne chose de clarifier définitivement les choses.
et puis je suis vraiment à l'étroit dans 4 ko smile
avatar

5

je viens de faire le test et finalement ça change pas grand chose : les accès DRAM sont plus rapide, mais de pas grand chose.

programme de test :
.include "includes/include.inc" .text .68000 m68k_start:: move.w #$2700, sr move.l #INITSTACK, sp move.w #$FF00, INT1 move.w #$FFFF, INT2 lea gpu_code_start, a0 lea G_RAM, a1 move.l #gpu_code_end-gpu_code_start, d0 .copy: move.l (a0)+, (a1)+ dbra d0, .copy ; start GPU move.l #gpu_init, G_PC move.l #1, G_CTRL stop #$2700 .long gpu_code_start:: .gpu .org G_RAM gpu_init: movei #.readmem, r30 movei #$4000, r14 movei #D_RAM, r15 .readmem: load (r14), r0 load (r14+1), r1 load (r14+2), r2 load (r14+3), r3 load (r14+4), r4 load (r14+5), r5 load (r14+6), r6 load (r14+7), r7 load (r15), r20 load (r15+1), r21 load (r15+2), r22 load (r15+3), r23 load (r15+4), r24 load (r15+5), r25 load (r15+6), r26 load (r15+7), r27 jump T, (r30) nop .68000 gpu_code_end:: dc.l 0
Le résultat à l'analyseur logique :

lKTq

Au final :
- les accès GPU => DSP mettent 95 cycles GPU pour faire 8 accès consécutif lw
- les accès GPU => DRAM mettent 87 cycles GPU pour faire 8 accès consécutif lw

Ça prend donc qu'1 cycle de plus par accès par rapport à la DRAM.
avatar

6

super, merci de l'analyse
donc c'est une mauvaise idée, autant stocker en DRAM quand on atteint les 4 kos du GPU
avatar

7

Tiens y a une instruction stop sur le 68k ?
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

8

Bien sûr ! Il a le droit a une petite pause de temps en temps, quand il a bien bossé smile
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

hello

en prolongement de ces histoires de vitesse de mémoire un petit compte rendu amusant
j'ai codé un replay hively sur la jaguar
au lieu d'utiliser des tables précalculées comme sur AHX ( étendu ensuite à hively sous windows ) , je calcule en temps réel les waves, y compris filtrage et ring modulation
tout est stocké dans la ram locale du DSP sauf le streaming du replay hively ( ça ressemble un peu à du VGM dans le principe)
donc je lis de la ram centrale, au maximum , a peu près 590 bits + 160 bits si le RM est activé sur toutes les voies. le tout 32 bits par 32 bits avec un cache dans un registre et la mémoire du dsp ( c'est bien des bits, pas des bytes ), à 50 Hz / 50 fois par seconde
performance du replay pour 10 voies : 30 Khz sans problème avec un affichage de texte pour voir ce qui se passe
le même code, inséré avec affichage graphique en 640 pixels, sur 2 plans, un logo etc : 20 KHz

ça me surprend beaucoup car je pensais que quand un risc tourne dans sa ram locale il n'était pas dépendant ou ralenti par ce qui se passe dans la ram centrale.
visiblement il y a d'autres sources de collisions entre 68000, GPU et DSP
avatar

10

Bon après ça ne fait que 4.5 ko/sec que tu accès depuis le DSP, c'est beaucoup pour la Jag ?
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

11

non c'est rien du tout
donc je pense qu'il y a un autre goulet d’étranglement dans la jaguar que la mémoire centrale et le bus vers la mémoire centrale.

mais je ne suis pas assez calé sur la jaguar pour savoir exactement ce qui se passe au niveau électronique et qui explique ces faits
avatar

12

Et si tu faisais un test en samplant un truc où ton programme ne nécessite pas d'accéder à la DRAM (exemple tout est déjà placé dans le cache, tout le long, et tu joues donc le même sample). Pour voir si ce sont les accès qui dérangent, ou si la vitesse du DSP est juste ralentie simplement par le fait que Tom travaille et accède à la RAM.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

13

Les RISC ne sont pas impactés par ce qui se passe dans la RAM centrale si ils ne font pas d'accès mémoire externe.
Sinon F.Act.S n'aurait pas d'audio vu l’utilisation énorme de la bande passante RAM par le rendu vidéo. wink

De ce que je comprends, tu ne fais uniquement que des burst de ~24 accès longword par frame ?
Je présume que t'es obligé d'avoir l'ensemble des datas pour continuer/généré ton flux audio par rapport à une approche stream ou les paquets peuvent arriver au fil de l'eau avec un jitter pas trop gênant vu qu'il y a un peu de marge.


Si la charge de l'utilisation de la RAM principal influs, c'est que je pense que tes accès se font par mal chance pendant que l'OP fait les accès RAM pour afficher ton écran, ce dernier étant le plus prioritaire, les accès RAM du DSP seront repoussés à plus tard, ce qui bloque tout tes traitements et donc impose de réduire la fréquence d’échantillonnage.
Si tes plans sont en 16-bit, 640px * 2plans en 16-bit c'est comme si tu affichais 4 objets plein écran (en résolution standard) ce qui commence à prendre pas mal de bande passante.

Dans ton cas, je dirais de tester en "synchronisant" le démarrage de tes accès à la VBL pour que le DSP fasse son burst durant la période ou l'OP ne fait rien.
avatar

14

Pas bête, la synchro avec la VBL smile

Vérifie aussi que tu fais les accès à la RAM depuis le programme principal, pas depuis l'interruption I²S. Et que les données de tes objets graphiques sont en RAM plutôt qu'en ROM (dans le second cas, ça bloque le bus plus longtemps, à cause des wait states).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

15

hello

le code qui lit le peu de données venant de la ram tourne en programme principal effectivement, tout simplement pour avoir tous les registres.
et je n'utilise jamais rien en rom, tout est en ram. les objets graphiques en rom sur jaguar c'est la mort

ce qui me semble quand meme bien etrange c'est que le code principal genere des buffers en ram dsp qui sont lus par l'I2S. si le code principal est en retard, il ne recalcule pas les buffers assez vite mais l'I2S peut continuer à faire du replay des buffers deja dispos ( ça boucle en permanence sur maximum 128 octets par voie). si je monte a 40 KHz j'entends très bien que c'est ce qui se produit. mais avec l'ajout de la charge graphique la déformation du son n'est pas la même.
je dois avouer que je ne vais pas non plus y passer un temps fou, car vraiment sincèrement tout le monde s'en fout en fait, y a vraiment peu de codeurs jaguar et les utilisateurs/joueurs ne font pas vraiment la différence entre du module 4 voies et du hively 10 voies.
avatar

16

et à propos de la vbl, le replay étant en 50 Hz, pas facile à caler sur de l'affichage 50 et 60 hz wink
avatar

17

@SCPCD : j'ai repensé à ce ta comparaison avec facts. mais dans facts tu a 2000 sprites de 4*4 = 16 pixels. ça fait 32000 pixels en CRY = 64000 octets en plus de la table de l'object list bien sur
alors moi dans mon menu j'ai 1 plan en 640*240 + 1 logo en 640*33 + 1 menu en texte de 640*160 : ca fait 554240 octets lus pour l'affichage
avatar

18

ericde45 (./15) :
je dois avouer que je ne vais pas non plus y passer un temps fou, car vraiment sincèrement tout le monde s'en fout en fait, y a vraiment peu de codeurs jaguar
Il faut prendre aussi un peu de recul et se dire que l'on fait les choses aussi pour soit même, la satisfaction d'y arriver ou d'avoir essayer et partager ses trouvailles.

19

tout à fait, mais partager avec qui ? a part CJ, il n'y a aucun codeur sur jaguar, les autres utilisent raptor sans faire de dev de bas niveau. ( sans parler de ceux qui utilisent raptor sans le dire...)
et puis si tu fais une routine de musique, il faut des musiciens qui composent, et sur jaguar c'est pas la foule. la plupart voir tous se contentent de faire du module amiga 4 voies, la console est quand meme capable de plus que cela.

sinon il reste le dev haut niveau en C, mais va donc faire un bon player audio en C sur Jag...
avatar

20

Je te comprends, je ne sais pas s'il existe une solution.
Tu peux essayer de créer un groupe, genre Reboots, et tenter d'y faire rentrer des développeurs / créateurs curieux par la console et autour d'un projet.

21

ericde45 (./19) :
tout à fait, mais partager avec qui ? a part CJ, il n'y a aucun codeur sur jaguar, les autres utilisent raptor sans faire de dev de bas niveau. ( sans parler de ceux qui utilisent raptor sans le dire...)
et puis si tu fais une routine de musique, il faut des musiciens qui composent, et sur jaguar c'est pas la foule. la plupart voir tous se contentent de faire du module amiga 4 voies, la console est quand meme capable de plus que cela.

sinon il reste le dev haut niveau en C, mais va donc faire un bon player audio en C sur Jag...

Salut,

Oh si rassure toi il y a des dev bas niveau sur Jaguar, j'ai toujours tout fait a la main la dessus. J'utilises même un Falcon pour dev sur Jaguar wink SCPCD et Zerosquare connaise mieux la Jaguar que ces créateurs boing

Pour l'instant je finis des projets sur STE / Falcon mais c'est vrai qu'un bon jeu comme metal slug sur Jaguar, des vrais jeux ca serait bien sympa.

Pour la musique suivant le type de musique (soundtrack) par exemple je te peux te trouver des musiciens sans soucis wink On est Atariste, c'est d'abord une grande famille, donc le soucis est pas de trouver quelqu'un , on te trouvera quelqu'un.

Je vais juste te faire une petite démonstration Matmook qui a dev Do The Same sur Jaguar avait besoin d'un graphiste, un email après la il l'avait smile Des numéros de téléphone de musiciens j'en ai plusieurs dans mon répertoire et pour taquiner Fadest wink je laisserai pas un jeu Jaguar sortir sans musique

GT De la famille
avatar
Accrochez vous ca va être Cerebral !!

22

je ne dis pas qu'il n'y a pas eu de grands codeurs sur Jaguar, je dis juste que depuis 2 ans c'est plutot moribond
coté musique, je bosse avec dma-sc, mais de ce qu'il me dit, 4 voies c'est faisable, une musique sur 10 voies c'est une autre paire de manche ( ce que je comprends tout à fait, on passe des beatles à la musique de chambre)

les jeux comme metal slug c'est mort, ou alors peut etre sur Jaguar CD ? la cartouche est trop petite et la neo geo utilise la rom en direct, tu ne peux pas faire ça sur jaguar en 60 fps ( peut etre meme pas en 30), si tu colles tes graphs en rom ça ralentit tout

petit PS : et c'est pas la folie du partage du Jag, perso je mets beaucoup de chose sur github mais on est que 2 à faire ça avec 42Bastian
avatar

23

Tu feras un bisous a Dma smile

La Jaguar c'est un peu a monde a part, car il y a peu de développeurs en europe, et les américains ont un certain caractères.

Sur github tu auras surement peut de personnes. Etant de retour on va peut ère commencer a ressortir le site Jagware de la poussière, ca pourra surement aider.

Je te dirais cartouche trop petite ?

Le premier truc que je ferais c'est de demander a SCPCD et Zerosquare, c'est quoi la taille maxi d'une cartouche que vous pourriez dev ?

Dis toi juste qu'il y a tous les outils, toutes les personnes. C'est juste qu'il faut savoir a qui demander.

On fait tourner metal slug a 50 images par seconde sur un STE :



une Jag est bien plus puissante donc c'est tout a fait jouable.

Surtout hésite pas, coté code je suis coincé sur des projets, mais si il te faut quoique ce soit hésite surtout pas.

David / GT De retour
avatar
Accrochez vous ca va être Cerebral !!

24

oui je connais ce prototype
mais si tu creuses + le sujet tu vois qu'il y a des Mo de graphismes sur neo geo
la jaguar c'est 2 mo de ram et 6 mo de rom
on peut peut être faire des cartouches customs avec bank switching un peu comme la gamedrive par exemple, juste de la rom sans SD, mais il faut aussi voir le cout final

l'idée qui flotte en permanence dans l'air de la scène jaguar comme quoi elle serait capable de faire tourner des jeux neogeo, ça ne vient souvent que de personnes qui n'ont jamais vraiment creusé le sujet. ou des graphistes aussi wink
avatar

25

Coucou GT <3
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

26

il n'y a aucun codeur sur jaguar, les autres utilisent raptor sans faire de dev de bas niveau

C'est un peu réducteur quand même confus

27

ericde45 (./24) :
oui je connais ce prototype
mais si tu creuses + le sujet tu vois qu'il y a des Mo de graphismes sur neo geo
la jaguar c'est 2 mo de ram et 6 mo de rom
on peut peut être faire des cartouches customs avec bank switching un peu comme la gamedrive par exemple, juste de la rom sans SD, mais il faut aussi voir le cout final

l'idée qui flotte en permanence dans l'air de la scène jaguar comme quoi elle serait capable de faire tourner des jeux neogeo, ça ne vient souvent que de personnes qui n'ont jamais vraiment creusé le sujet. ou des graphistes aussi wink
Ouais mais la Neo Geo se programme de façon un peu particulière. Il y a des effets qu'elle ne peut pas vraiment faire, et à la place te remplace des tilesets entiers juste pour faire une animation de l'arrière-plan (car le hardware supporte la rotation dynamique de tileset, et sans ça c'est juste l'adresse à changer), alors que quand on code pour une console plus classique on va animer de plus petites parties du décor, là où ça a un impact ; on animera éventuellement via des sprites plutôt que des tilesets entiers, ce qui permet aussi en compensation d'avoir des animations plus fluides et plus longues. Bref ça nécessite un peu d'engineering, tu ne portes pas directement un jeu comme ça. Dans l'ensemble, c'est vrai que la Jaguar ne peut probablement pas "faire tourner un jeu Neo Geo comme Metal Slug", mais elle peut faire tourner des jeux qui pètent sans doute autant, juste adapté à ses qualités.
D'ailleurs si tu as un mixeur 10 voies à 30 KHz, techniquement tu fais déjà un peu mieux que la Neo Geo (suivant ce que tu cherches à faire).
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

28

La c'est 'juste' un problème de place
Godzil (./25) :
Coucou GT <3

Salut Toi comment va tu ?


David / Yete de retour
avatar
Accrochez vous ca va être Cerebral !!

29

Brunni (./27) :
ericde45 (./24) :
oui je connais ce prototype
mais si tu creuses + le sujet tu vois qu'il y a des Mo de graphismes sur neo geo
la jaguar c'est 2 mo de ram et 6 mo de rom
on peut peut être faire des cartouches customs avec bank switching un peu comme la gamedrive par exemple, juste de la rom sans SD, mais il faut aussi voir le cout final

l'idée qui flotte en permanence dans l'air de la scène jaguar comme quoi elle serait capable de faire tourner des jeux neogeo, ça ne vient souvent que de personnes qui n'ont jamais vraiment creusé le sujet. ou des graphistes aussi wink
Ouais mais la Neo Geo se programme de façon un peu particulière. Il y a des effets qu'elle ne peut pas vraiment faire, et à la place te remplace des tilesets entiers juste pour faire une animation de l'arrière-plan (car le hardware supporte la rotation dynamique de tileset, et sans ça c'est juste l'adresse à changer), alors que quand on code pour une console plus classique on va animer de plus petites parties du décor, là où ça a un impact ; on animera éventuellement via des sprites plutôt que des tilesets entiers, ce qui permet aussi en compensation d'avoir des animations plus fluides et plus longues. Bref ça nécessite un peu d'engineering, tu ne portes pas directement un jeu comme ça. Dans l'ensemble, c'est vrai que la Jaguar ne peut probablement pas "faire tourner un jeu Neo Geo comme Metal Slug", mais elle peut faire tourner des jeux qui pètent sans doute autant, juste adapté à ses qualités.
D'ailleurs si tu as un mixeur 10 voies à 30 KHz, techniquement tu fais déjà un peu mieux que la Neo Geo (suivant ce que tu cherches à faire).

Pour la partie technique, faut pas trop s'inquieter, Eric fait partie du groupe Dune (demomaker Atari ST). Le seul vrai problème qu'il a bien souligné c'est le manque de place pour les graphes.

GT De la démo
avatar
Accrochez vous ca va être Cerebral !!

30

C'est pas s'inquiéter, je dis qu'il n'y a pas besoin de forcément TANT de mémoire, si c'est pas une conversion directe tongue
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741