TT-Ram et Gem - Page 1

J'avais écris une routine de pop up, pour sauvegarder ce qu'il y a en dessous, j'utilisais le buffer du Gem, adresse obtenu par un Wind_Get 17 (Plus très sur du 17 mais bon !) vu que tout était bloqué (Wind update) je ne craignais rien venant d'une utilisation non désiré de ce buffer.

Depuis que j'ai ma CT63, la routine plantait, j'ai cherché un moment, vérifié si l'adresse était valide, sa taille (60300 octets) et pourtant cela plantait puis un doute, j'ai reservé de la ram a la main (Malloc) et cela ne plante plus. Le Gem aurait reserve la ram en TT-Ram ? Vu que cette ram n'est pas utilisable pour l'écran je penses que mon plantage vient de la. Mais alors le Gem n'utiliserait pas ce buffer pour sauver la partie sous les boites d'alertes, les selecteurs ?


GT Perdu !! Pour changer !! :d

Il vaut mieux réserver à la main, soi-même via Malloc une zone mémoire pour ses propres redraws et buffers écrans. L'utilisation du wind_get(17) est assez hazardeuse, la taille réservée correspond à 1/4 de l'écran. Et il vaut mieux ne pas l'utiliser, car le GEM l'utilise aussi pour ses redraws avec ses menus / pop-ups officiels ou autres choses GEM (mais pas le sélecteur interne : c'est un appel wind_dial avec demande de redraw, idem je crois pour les alertes).

Par contre, ça me parait bizarre que ça soit en TTRAM, d'après mon expérience, un vro_cpyfm s'en fout de tapper en STRAM ou TTRAM. A moins que le GEM utilise la ligne A pour ses bitblittings, le vilain ?
Avec ta CT63, tu as changé de format écran (nb bitplanes) et de résolution ? le buffer GEM est peut-être trop "short" pour la taille de ton pop-up, surtout si t'as calculé just.


RAJOUT : ah oui, une anecdote... si je faisais un vro_cpyfm et que mon pop-up dépassait le base de l'écran, en mode TV = non VGA (640*400-16c par exemple), ben ça plantait, alors qu'en mode VGA (640*480-16c, toujours en dépassant l'écran par le bas). Ce bug était propre au Falcon (sous TOS ou MagiC)

Rajah Lone
: Il vaut mieux réserver à la main, soi-même via Malloc une zone mémoire pour ses propres redraws et buffers écrans. L'utilisation du wind_get(17) est assez hazardeuse, la taille réservée correspond à 1/4 de l'écran. Et il vaut mieux ne pas l'utiliser, car le GEM l'utilise aussi pour ses redraws avec ses menus / pop-ups officiels ou autres choses GEM (mais pas le sélecteur interne : c'est un appel wind_dial avec demande de redraw, idem je crois pour les alertes).

Oui mais le Gem est bloqué, j'ai fait un wind update justement pour eviter des utilisations exterieures et qu'un menu me gribouille dessus.

Rajah Lone :
Par contre, ça me parait bizarre que ça soit en TTRAM, d'après mon expérience, un vro_cpyfm s'en fout de tapper en STRAM ou TTRAM. A moins que le GEM utilise la ligne A pour ses bitblittings, le vilain ?

Si mes souvenirs sont bon pas de vidéo ni de son dma en TT Ram c'est a proscrire, c'est pour cela que je me demandes si le Gem n'a pas fait sa demande en TT-Ram, cela est bizzare. Faut que j'essaies en mode 030 pour voir.

Rajah Lone :
Avec ta CT63, tu as changé de format écran (nb bitplanes) et de résolution ? le buffer GEM est peut-être trop "short" pour la taille de ton pop-up, surtout si t'as calculé just.

La résol est la meme et les bitplans pareils, j'ai calculé pour mon pop up il me faudrait meme pas 20 Kilos, la j'ai reservé a la main 32 Kilos et la le buffer est a 60. Et avant la CT63 cela marchait sans soucis.

Rajah Lone :
RAJOUT : ah oui, une anecdote... si je faisais un vro_cpyfm et que mon pop-up dépassait le base de l'écran, en mode TV = non VGA (640*400-16c par exemple), ben ça plantait, alors qu'en mode VGA (640*480-16c, toujours en dépassant l'écran par le bas). Ce bug était propre au Falcon (sous TOS ou MagiC)

Le pop up est clippé et ses coordonnées sont modifiés pour toujours etre dans l'écran, et pour l'instant je suis toujours en Vga.

Je vais essayer en mode 030 avec la meme résol pour voir cela.

GT En train de me battre contre des bugs de m...

GT Turbo
: Si mes souvenirs sont bon pas de vidéo ni de son dma en TT Ram c'est a proscrire, c'est pour cela que je me demandes si le Gem n'a pas fait sa demande en TT-Ram, cela est bizzare. Faut que j'essaies en mode 030 pour voir.

Non, c'est l'accès DMA des Blitter, Videl et chip sonore qui sont interdits en TTRAM. Tu peux stocker ce que tu veux dans la TTRAM, mais un chip avec des instructions XBIOS ou LineA ne pourront surtout pas taper inside. Par contre, un vro_cpyfm et le GEM, ça doit pouvoir le faire.
Enfin, c'est ce qu'il me semble...

Donc si on programme propre on peut utiliser de la TT-Ram ?

Ca serait la grande classe, histoire d'accélérer encore un peu la chose !!


GT

Ben oui, si c'est propre, ça marche

Pour DGEM, j'utilise la TTRAM pour stocker les images/sprites/masques, c'est plus rapide avec les transferts CPU : les vro_cpyfm se font en TTRAM pour construire la scène en offscreen et un vro_cpyfm est fait pour l'affichage vers l'écran. Je ne m'occupe de rien, c'est la VDI ou NVDI qui gère. Suffit de ne jamais s'occuper de la line A et du blitter (on n'y touche pas).
Avec la CT60, c'est bleuffant niveau rapidité : on peut même faire un zoom*2 (le *3 n'est pas possible car pas de résolution grande), avec plein de chutes d'eau/télétransporteurs en train de s'afficher : c'est toujours fluide.

Par contre, comme les sons doivent être joués par le SDMA directement, il faut impérativement qu'ils soient en STRAM, sinon il y aura problème.

Rajah Lone :
Ben oui, si c'est propre, ça marche

Fini les démos, le style demomaker est maintenant appliqué a la Jaguar sous la forme Gamemaker !!

Rajah Lone :
Avec la CT60, c'est bleuffant niveau rapidité : on peut même faire un zoom*2 (le *3 n'est pas possible car pas de résolution grande), avec plein de chutes d'eau/télétransporteurs en train de s'afficher : c'est toujours fluide.

C'est a cela que je pensais, aux possesseurs de TT-Ram, si dejà on en a autant en profiter, et cela demande pas grand chose de modif, j'ai juste a modifier la routine de Malloc, qui suivant la machine fait un Malloc ou un Mxalloc donc juste une dizaine de lignes maxi (en assembleur))

Rajah Lone :
Par contre, comme les sons doivent être joués par le SDMA directement, il faut impérativement qu'ils soient en STRAM, sinon il y aura problème.

Pas de soucis, j'ai pas de son, c'est pour faire des outils de devellopement donc No Sound (Fadest Powa !! T'as vu Fadest cela faisait longtemps qu'on te l'avait pas fait !! C'est la nostalgie, Kuk y est re-passé avec les durs qui revienne a l'attaque et maintenant toi !)


GT Sans son !!

Je pense que le grand Pockitto devrait déplacer ce topic en développement.

Rajah ca marche pas !!

Explications :

Devpac 3.10 permet d'assembler le programme dans un buffer soit St-ram soit TT-ram, je selectionne TT-Ram, tout fonctionne jusqu'au moment ou je dois recopier des blocs d'un buffer vers l'écran, plus de blocs !!

Ayant un doute j'ai réassemblé tout en St-ram, et la pas de soucis. Mettant peut etre Devpac en cause, j'essaie un autre truc. J'assemble sur disque et lance aucun soucis. Ensuite je modifies les bits d'entete du fichier :

- bit fasload placé
- bit tt-ram prg placé
- bit tt-ram memory placé

Dans ce cas pas de bloc !

- bit fasload placé
- bit tt-ram prg placé
- bit tt-ram non mis

Dans ce cas cela fonctionne, donc sauf erreur de ma part, l'utilisation de la TT-ram pour la vidéo est a oublier, je l'avais déjà lu quelque part mais cela confirme la chose.

GT En ST-Ram

Tu ne bosserais pas sans NVDI sur ta CT63 ?

frost :
Tu ne bosserais pas sans NVDI sur ta CT63 ?

Si, pourquoi NVDI modifie les allocations mémoire ? Ou plutot 'bricole' pour utiliser la TT-Ram pour la vidéo ?

GT

NVDI obligatoire sur TTRAM pour désactiver les transfert par Blitter, et faire ça en soft. Le Blitter est incompatible TTRAM.

D'accord mais je voulais savoir pour les montages de base, car j'utilises Nvdi que dans certains cas, j'ai toujours mon soucis de compatibilité avec Videl Inside, et vu que Centscreen apparement n'est pas trop prévu pour les CT63 cause je penses pas de boost du Videl.

Je ferais une détection de NVDI et ferait dans ce cas précis des allocations mémoires en TT-Ram, je ne vais pas forcer les gens a utiliser des progs qu'ils ont pas ou qu'il ne peuvent utiliser.

GT Sans NVDI

Il faut patcher Centscreen pour qu'il soit compatible CT60.. Cf l'archive du TOS. Enfin c'est bizarre pour Videl Inside, il me semble qu'il fonctionnait bien chez moi.. Enfin je vais tester ça dans 15 jours, je récupère mon Falcon à ce moment là

Tu trouveras des patchs ici: http://ct60.dhs.nu/download.php

frost :
Il faut patcher Centscreen pour qu'il soit compatible CT60.. Cf l'archive du TOS. Enfin c'est bizarre pour Videl Inside, il me semble qu'il fonctionnait bien chez moi.. Enfin je vais tester ça dans 15 jours, je récupère mon Falcon à ce moment là

Strider m'avait passé l'adresse de DHS, j'ai récup deux archives videl40 et videl50, je penses que c'est par rapport a la vitesse du Videl non ?

Quand je lances un prog ou l'autre, retour au bureau sans rien de plus sans rien de moins.

Videl Inside et NVDI ca fait des etincelles quand tu essaies de changer ou d'utiliser une résol pas origine, soit l'écran par en fleur soit ca plante tout court !!

GT

T'est sur de ton lien ? Bittorent pas très utilisé sur un Atari !!


GT

Oula... j'ai posté ça moi ??? Soit je perds la mémoire, soit je suis atteint d'Alzeimer !

J'ai règlé mon probleme en faisant une detection de NVDI et dans ce cas de figure en appelant Mxalloc au lieu de Malloc.

Par contre si quelqu'un entend parler d'un 'extenseur' de résol qui fonctionne avec NVDI sur un Falcon équippé d'une CT63, pensez a moi !!

GT En train de reserver de la ram !!