OURAGAN version 2012 - Page 5

J'ai pas essayé, mais j'ai cherché dans les librairies, je n'ai pas trouvé la trace de loadexec ou équivalent...

J'avais testé le nouveau CC65 mais j'ai pas réussi à comprendre comment coller mes bitmaps (alors qu'avec l'ancienne version, ça roule)...

vince (./121) :
J'ai pas essayé, mais j'ai cherché dans les librairies, je n'ai pas trouvé la trace de loadexec ou équivalent...

Bah en gros il y a ca : https://github.com/oliverschmidt/cc65/blob/master/libsrc/lynx/load.s
Mais comme tu vois cela ne fait rien de special, tout le travail d'adressage est fait a la compilation.

Mais bon si tu te sens la motivation pour passer au nouveau cc65 je peux te filer un coup de main, ca serait quand meme dommage de s'arreter en si bon chemin.

Bah déjà, il faudrait un sample pour loader un binaire depuis la rom et l'exécuter et un sample pour intégrer une bitmap...

vince (./125) :
Bah déjà, il faudrait un sample pour loader un binaire depuis la rom et l'exécuter et un sample pour intégrer une bitmap...

Grave !!!!

Voila, il suffit de demander, un peu moche mais assez simple je pense.
a() et b() sont constamment recharges de la cart, affichent un bitmap, et occupent le meme espace memoire apres chargement.
Compile avec cc65 2.13.9 rev 5944 venant de svn://svn.cc65.org/cc65/trunk (revisions au dessus de 5944 sont bugges...)
Fichier joint : vincetest.zip

Comment tu gères les potentielles collisions en RAM ?

Zerosquare (./128) :

Comment tu gères les potentielles collisions en RAM ?

C'est à toi de gérer manuellement la répartition des tes segment suivant tes besoins.
Ca se fait a partir du fichier lynxcart.cfg ici

Par exemple pour les segments A et B (taille : 200, debut en RAM : 500) :
__ASIZE__: type = weak, value = $0200; __BSIZE__: type = weak, value = $0200;
A: file = %O, define = yes, start = $0500, size = __ASIZE__; B: file = %O, define = yes, start = $0500, size = __BSIZE__;

A_CODE: load = A, type = ro, define = yes; A_DATA: load = A, type = rw, define = yes; A_RODATA: load = A, type = ro, define = yes; A_BSS: load = A, type = bss, optional = yes; B_CODE: load = B, type = ro, define = yes; B_RODATA: load = B, type = ro, define = yes; B_DATA: load = B, type = rw, define = yes; B_BSS: load = B, type = bss, optional = yes;

Gaspement intéressant ! Merci Maeel !

Idem, faut que je regarde ça

Et donc on commande où la cartouche de Ouragan Lynx ?

Maeel (./127) :
Compile avec cc65 2.13.9 rev 5944 venant de svn://svn.cc65.org/cc65/trunk (revisions au dessus de 5944 sont bugges...)

J'ai pas trouvé de version "Windows" plus récente que la 2.13.3.

Je crois que je comprendrais jamais pourquoi "open source" doit forcément aller de pair avec "surtout que les sources, si c'est pour une version binaire allez vous pendre"...

(oui, parceque load.s est absent de la 2.13.3 en fait)

Bon, je viens de tenter de remplacer le bitmap de la partie "a" par un de 160x102.
Je compile, LD65 me braille dessus "memory area overflow" in 'A', segment A_RODATA...
J'ai augmenté la taille correspondante du segment dans lynxcart.cfg (jusqu'à ce que ça passe : $1000), ça compile mais ça gauffre la lynx...
ça fait plus de 4h que je tente de capter le truc et je ne vois pas...

Je précise que j'ai fait le test avec un sprite généré par sp65.exe ainsi qu'avec un sprite "incbiné" généré par sprpck (que j'utilise déjà avec le vieux compilo).

Messieurs, si l'un de vous à une idée avant que j'aille me pendre avec un jagpad ...

C'est toujours mieux que moi, je ne parviens même pas à le compiler (nmake avec VS2010)...

vince (./135) :
C'est toujours mieux que moi, je ne parviens même pas à le compiler (nmake avec VS2010)...

Normalement, ce que je t'ai balancé suffit, t'as juste à faire make dans le dossier (quoique, j'ai pas du coller make.exe dedans ... oups... il te faut télécharger http://unxutils.sourceforge.net/ pour windows, tu as tout ce qu'il faut dedans).

matmook (./134) :
Bon, je viens de tenter de remplacer le bitmap de la partie "a" par un de 160x102.
Je compile, LD65 me braille dessus "memory area overflow" in 'A', segment A_RODATA...
J'ai augmenté la taille correspondante du segment dans lynxcart.cfg (jusqu'à ce que ça passe : $1000), ça compile mais ça gauffre la lynx...
ça fait plus de 4h que je tente de capter le truc et je ne vois pas...

Je précise que j'ai fait le test avec un sprite généré par sp65.exe ainsi qu'avec un sprite "incbiné" généré par sprpck (que j'utilise déjà avec le vieux compilo).

Messieurs, si l'un de vous à une idée avant que j'aille me pendre avec un jagpad ...

Vérifie ou ce trouve ton segment "RAM", tu dois sûrement l'écraser avec A.

matmook (./136) :

vince (./135) :
C'est toujours mieux que moi, je ne parviens même pas à le compiler (nmake avec VS2010)...

Normalement, ce que je t'ai balancé suffit, t'as juste à faire make dans le dossier (quoique, j'ai pas du coller make.exe dedans ... oups... il te faut télécharger http://unxutils.sourceforge.net/ pour windows, tu as tout ce qu'il faut dedans).

Avec unixtools, ça a l'air de marcher

Fichier joint : cart.lnx

(il rale juste qu'il lui manque "rm", il suffit d'éditer les Makefile pour remplacer "rm -f" par "del /F")

Cool ! \o/
Bon, pour ma part, je n'ai pas eu le temps de régler ce problème de RAM ... logiquement j'ai juste à augmenter __ASIZE__ et ça doit rouler ou alors il y a un autre truc à modifier ??
Il faut que je refasse quelques tests, j'ai du louper un schmurtzzz !

mon prochain objectif est de faire un projet séparé (donc pas de copier coller) pour lequel ça marcherait...

vince (./140) :
mon prochain objectif est de faire un projet séparé (donc pas de copier coller) pour lequel ça marcherait...

Je n'ai pas fait de copier/coller, j'ai juste changé l'image A par une plus grosse qui prend tout l'écran...

Ahh, j'ai une piste, je dois décaler également le segment RAM ...bon, mon image est toute pérave mais au moins ça ne gauffre plus..

Edit : en fait c'est bon, j'ai maintenant l'image \o/

Bon, j'ai réussi à faire un autre programme (je pense que j'ai compris le truc) et déjà, je me demande comment on peut définir une variable commune à tout le monde... pour le moment, je la passe en paramètre de mes fonctions externes par indirection...

vince (./143) :
Bon, j'ai réussi à faire un autre programme (je pense que j'ai compris le truc) et déjà, je me demande comment on peut définir une variable commune à tout le monde... pour le moment, je la passe en paramètre de mes fonctions externes par indirection...

La partie "resident" est chargée en $0200 alors que les autres parties sont chargées en $500, tu dois avoir de la place dans le résident pour y coller de la variable...enfin si j'ai bien compris le concept