limites de l'object processor - Page 1

hello

avant de me compliquer la vie, j'essaye d'évaluer les limites de l'object processor.
si je veux afficher 400 sprites à l'écran, puis je simplement les lister et l'OP est assez puissant pour parcourir ma liste à chaque ligne et je ne gérer que les sprites qu'il doit afficher sur cette ligne là ?
ou faut il directement s'embarquer dans une arborescence en splittant en groupes de lignes en utilisant des branch, et donc générer une object list en dynamique en créant des objets bitmap dans chaque branche de ma liste suivant la position Y des sprites ?
( quel enfer ! )

Pas fait de tests de perf à proprement parler, mais Fadest surement avec son proto de smashTV. Sinon fais un test rapide avec jagstudio, c'est optimisé pour l'OP justement.

L'OP mange une simple liste chainée, donc pas sûr que ca fasse ce que tu as en tête.

j'ai commencé à faire des tests en utilisant l'assembleur OP de rmac
mais générer une OL toutes les VBL au GPU, parce que je dois en partie trier les sprites pour créer un arbre de décision en fonction du Y, c'est un sacré boulot

c'est super facile à faire dans rmac en dur :
branch VC > 128-1, obj_list_saut128
branch VC > 64-1, obj_list_saut64
branch VC > 32-1, obj_list_saut32
branch VC > 16-1, obj_list_saut16
branch VC > 8-1, obj_list_ligne08

obj_list_ligne00:
bitmap bob+512, 0, 00, 2, 2, 8,3 ,0,TRANS
bitmap bob+512, 32, 00, 2, 2, 8,3 ,0,TRANS

mais à créer en dynamique c'est chaud !

400sprites ça fait un peut plus de 1600cycles (400sprites*2phrases/sprites*2cycles/phrases) rien que pour parser la liste soit ~94% du temps d'une ligne (~64µs en 50Hz).
Donc je dirais que ce n'est pas faisable sans au moins découper la liste en 2 voir 4 selon la résolution horizontal de tes sprites.

ok
me voilà parti pour fabriquer des objets en GPU. et sans debugger.
bon je vais m'écrire un bout de C pour dessassembler les objets avant d'en fabriquer, pour pouvoir vérifier si ils sont OK

pour info la doc Jaguar V8 est fausse, les vraies valeurs de CC pour les branch sont :

Condition codes (CC):

Values Comparison/Branch
--------------------------------------------------
000 Branch on equal (VCnt==VC)
001 Branch on less than (VCnt>VC)
010 Branch on greater than (VCnt<VC)
011 Branch if OP flag is set

trouvées ici :
https://www.mulle-kybernetik.com/jagdox/op.html#BRANCH

Je ne vois pas la différence avec la tech_v8 (ormis qu'ils omettent des conditions [edit: elles sont marquées dans le texte par contre]) et la tech_v8 est bonne sur les branch_object.

Ce qui est faux dans la tech_v8 par contre, c'est la condition YPOS pour les GPU Object : ça n'est pas implémenté dans la jag (voir les doc plus récente de 95) et met en pause l'OP systématiquement (+envoi interruption au GPU)

en fait c'est l'assemble rmac qui est inversé,, dans les exemples:

branch VC < 69
branch VC > 241

alors que la tech V8 donne
1 Branch if YPOS > VC
2 Branch if YPOS < VC

le VC est de l'autre coté dans rmac

Intéressant, si tu veux tu peux rentrer le soucis dans leur bug tracker.
http://rmac.is-slick.com/contact/contact/

tiens puisque tu traines là, si je veux basculer de rmac a vasm, quid de rln ? et de la fabrication de fichier en .abs / absolute en $4000 ?
c'est possible ? ( je ne suis pas du tout un kador des .o etc )

ericde45 (./10) :
tiens puisque tu traines là, si je veux basculer de rmac a vasm, quid de rln ? et de la fabrication de fichier en .abs / absolute en $4000 ?
c'est possible ? ( je ne suis pas du tout un kador des .o etc )

A priori les fichiers .obj devraient être compatible entre eux pour rln. Un format elf, a.out ou coff devrait resté le même indépendamment de l'assembleur.
Le problème est plus pour Vasm, Rmac supporte de multiples instruction sets (.68000, .gpu & .dsp) dans le même fichier source alors que Vasm n'en supporte qu'un a chaque fois.

hello,

a t-on des outils pour debugger les object list ?
j'essaye d'utiliser le gpu object, il fonctionne une fois, il incremente un registre mais pas 2 fois, et sous phoenix j'ai : 003282d4 : OB->GPU out of limits
alors que sans le gpu object, dans l'object list, je n'ai pas cette erreur
après le gpu object j'ai 2 STOP
et j'ai lamentablement copier sur SCPCD qui expliquait son code d'interruption GPU ici :

une idée ?

bon mon code ne marche toujours pas mais je vois que l'emulateur phoenix permet de jolis debugs :

et on peut voir l'object list , super pratique aussi :

C'est vraiment bien qu'ils aient partager cette version.

je savais que j'allais te ferrer avec ces screenshots

Ouais, et j'ai mordu a l'hameçon avec une facilité déconcertante.
Est-ce que tu peux partager des Screenshot supplémentaire pour les autres processeurs? tel que le Blitter par exemple?
J'espère qu'un jour, je vais arriver a faire tourner leur version sur mon PC.

un screenshot d'un object list qui fonctionne ( le propriétaire se reconnaitra ) :

pour le blitter c'est juste la valeur des registres, screen shot ci dessous

ericde45 (./18) :
un screenshot d'un object list qui fonctionne ( le propriétaire se reconnaitra ) :

Dans ton code, je pense que le problème c'est que tu utilises le registre r30 :
j'ai l'impression que tu utilises r30 comme registre d'adresse pour les flags : attention car les registres r31 & r30 sont modifiées lors de l'entrée en interruption :
* r31 est la stack (donc modifié)
* r30 est détruit

En l'occurrence sur jag, r30 prent la valeur de l'adresse de l'interruption (attention car ce comportement n'est pas documenté => il faut prendre le partie que r30 = n'importe quoi), du coup avec ton code, cela va :
- lire l'adresse "F03030".l => initialement "D360 E400" {jump (r27) ; nop}
- activer le bit 12 => "D360 F400" {jump (r27) ; store r0, (r15+r0)}
- écrire le résultat à l'adresse "F03030".l
Du coup :
- les flags ne sont pas mis à jour => donc plus d'interruptions
- si exécution quand même de l'interruption => crash car l'instruction store va écrire n'importe quoi n'importe où

SCPCD (./19) :

C'est celle de FActS ? Je pensais que tu avais fait un arbre dichotomique plutôt qu'une liste linéaire.

hello

j'ai réécrit le code 'à ma façon' et maintenant ça fonctionne.
souvent quand je suis coincé sans possibilité de vrai debug, je ré-écris
en plus ça permet de mieux maitriser le sujet et de ne plus douter de tout.

l'émulateur phoenix est quand même un très chouette outil, dommage qu'il soit figé et pas dispo en open source.

Zerosquare (./20) :
C'est celle de FActS ? Je pensais que tu avais fait un arbre dichotomique plutôt qu'une liste linéaire.

C'est ce que j'aurais voulu faire, mais pas eu le temps, vu qu'il y avait un jalon.

et d'ailleurs, merci de vous pencher sur mes bêtises !

hello

ce week end j'ai croisé un ordi portable 'neutre' sans rien de spécial, j'ai donc testé la version debug de phoenix et elle a fonctionné sans soucis. ( pas de runtime etc déjà installés sur le PC )
juste un avertissement de sécurité microsoft à la première execution
donc Dilinger, peut etre as tu un problème avec un Windows pas européen donc sans support du russe de base ?

ericde45 (./24) :
donc Dilinger, peut etre as tu un problème avec un Windows pas européen donc sans support du russe de base ?

Je vis au Canada, j'ai un laptop HP Canadien, qui commence a dater d'ailleurs (si, si, alors envoyer vos dons en hardware :-) ); globalement c'est US avec un clavier US, de base mon Windows 10 supporte Eng/Fr.

hello

bon j'ai progressé avec phoenix, j'ai compris comment tracer et mettre des breakpoints, et ça fonctionne sur le 68000, le GPU et l'OP, j'ai pas testé sur le DSP
là ça devient vraiment super pratique !

Cool. Merci de ce partage. Les russes sont des plus brillants.

a propos d'émulateur, une lecture intéressante, en tout cas pour moi, qui ne savait pas exactement comment on peut faire un émulateur multi composants comme pour la Jaguar :

https://floooh.github.io/2019/12/13/cycle-stepped-6502.html

double post...

L'avantage de Phoenix par rapport à VJ RX c'est qu'il permet de voir l'état de tous les registres de tous les composants, (même ceux non accessibles) par contre chez moi il est MEGA lent et ne possède pas tous les outils de débub de VJ RX qui lui tourne relativement correctement