CPC Rulez
https://cpcrulez.fr/forum/

utilisation et implantation de DAMS
https://cpcrulez.fr/forum/viewtopic.php?f=4&t=5075		 Page 3 sur 5
Auteur :  Horos [ 19 Juin 2013, 18:36 ]
Sujet du message :  DAMS : nouvelle astuce trouvée !!
Hello,
Je viens de trouver une astuce extrêmement simple pour faire fonctionner la commande P2 :

- Assemblez votre code source avec la commande A2 (au lieu de A)

- Puis faîtes p2 monprog
Voilà, ça marche très bien! :biere:

Explications : à la différence de la commande A, qui assemble à l'adresse que vous avez stipulé dans ORG,
la commande A2 elle, assemble en mémoire à la suite de la table des symboles.

L'intérêt, c'est que A2 n'est pas buggée, et dépose le point d'entrée (différent de ORG donc) en {nn+47/nn+48}
Grâce à ce point d'entrée, P2 sauvegarde votre binaire sans problème. Vous avez ainsi votre programme objet .BIN exécutable.

En fait, ce n'est pas la commande P2 qui est buggée...

C'est la commande A qui est buggée!!!!! Hé oui, car c'est ELLE qui n'écrit pas correctement le point d'entrée en mémoire à nn+47
lorsque DAMS est plus haut en mémoire que le programme!! :)

P2, elle, fait correctement son boulot. Ce n'est pas de sa faute si la commande A écrit un point d'entrée faussé. Voilà, avec A2, plus de souci.
Auteur :  TotO [ 19 Juin 2013, 20:24 ]
Sujet du message :  Re: utilisation et implantation de DAMS
En gros, P fonctionne avec A et P2 avec A2 ...
Il n'y a finalement peut-être pas de bug, mais juste des choses à ne pas mélanger ?
Auteur :  Horos [ 20 Juin 2013, 06:57 ]
Sujet du message :  Re: utilisation et implantation de DAMS
TotO a écrit :
En gros, P fonctionne avec A et P2 avec A2 ... Il n'y a finalement peut-être pas de bug, mais juste des choses à ne pas mélanger ?
Salut Tot0,

Ta remarque est très intéressante, car la ressemblance des noms pourrait effectivement le laisser penser. Mais non.
Il y a bien un bug dans DAMS et il est à présent identifié : c'est vérifiable à 100% désormais.

En fait, la commande P n'est pas affectée par le bug car elle ne sauvegarde pas le code assemblé, mais le code source.
Celui-ci étant toujours à la même place en nn+10485, elle ne se sert jamais du pointeur nn+47 et donc ce bug ne la touche pas.

Par contre, la commande P2, elle, ne sait pas où se trouve votre code assemblé en mémoire car c'est vous qui décidez
en écrivant l'adresse dans la directive ORG. La commande A écrit à son intention où commence et finit votre code assemblé,
respectivement en nn+47 et nn+76. Mais elle merdouille si DAMS est placé plus haut en mémoire que votre programme.

Il suffit d'assembler un programme avec la commande A (en plaçant DAMS en #4000 et le programme en #1000 par exemple)
pour voir que le pointeur en nn+47 est faussé (#402F dans cet exemple) et sera #F6#FF au lieu de #00#01 (#1000 à l'envers lowbyte-highbyte)

Assemblez ensuite avec la commande A2 pour comparer cette fois et allez regarder le pointeur à nn+47 : ce n'est pas votre ORG,
car votre programme a été placé en mémoire après la table des symboles. Mais l'adresse est correcte,
ce qui permet à P2 de connaître le début et la fin de votre programme assemblé en mémoire et d'aller le lire pour le sauvegarder sur disquette ou cassette.

P2 n'a donc aucun rapport avec A2. C'est juste la commande A qui écrit un pointeur faussé et P2 qui en a besoin.
Et d'ailleurs la commande P fonctionne très bien avec A2 vu qu'ils ne sont pas inter-dépendants.
La commande P n'a absolument pas besoin de A ou A2 et sauvegardera le code source sans ce préocupper de ce qui est assemblé en mémoire.

Fano te confirmera bien sûr tout cela, vu qu'il utilise DAMS aussi.

Merci à Tom&Jerry de m'avoir fait parvenir aujourd'hui l'original de DAMS : après vérification, il est bien buggé.
Merci à Fano, hERMOL, Hicks, Kawickboy, Longshot, Shap, et Syde (par ordre alphabétique) d'avoir répondu à mes 10.000 questions par MP et ici.
Seul je n'aurai rien pigé. :sweatingbullets:
Auteur :  Horos [ 20 Juin 2013, 07:27 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Je viens de m'amuser à tester la commande F, qui assemble et met en RAM un code source qui lui est enregistré dans un fichier sur casette ou disquette, en allant lire ce Fichier.

F test.s

DAMS demande alors "Object code address ?" c'est à dire : à quelle adresse voulez-vous assembler le code source ?
Bien qu'il y ait un ORG renseigné dans le code source, DAMS vous donne le choix d'assembler à une adresse différente.

J'ai chargé DAMS en &4000, puis le code source test.s en &1000 en répondant &1000 à la question :
nn+47/nn+48 (#402F dans cet exemple) contient bien #1000 (lowbyte-highbyte), ça fonctionne nickel.

Oui, mais c'est moi qui ait indiqué l'adresse à DAMS. Il n'est pas allé la chercher lui-même dans le code source,
(comme le fait mon patch par exemple)

Comme la commande A2 ne va pas non plus chercher l'adresse ORG dans le source pour assembler,
mais se sert de la table des symboles,

on peut dire aujourd'hui que la commande A de DAMS (quand celui-ci est en position plus haute que le programme)
n'arrive pas à aller chercher l'adresse du ORG dans le source et écrit par erreur #F6FF (lowbyte-highbyte).
En tous cas, peut-être parvient t-elle à la lire (?) mais elle l'écrit mal, ça c'est sûr : elle ne sait pas la transmettre.
Auteur :  remax [ 20 Juin 2013, 10:35 ]
Sujet du message :  Re: utilisation et implantation de DAMS
c'est passionnant de découvrir des trucs comme ça aussi longtemps après alors que ce bug a du fair ch*** des centaines de codeurs :D
Auteur :  shap [ 20 Juin 2013, 11:50 ]
Sujet du message :  Re: utilisation et implantation de DAMS
@Horos : la commande F sert en fait à assembler des gros sources que tu coupes en morceaux, je ne me souviens plus de la syntaxe, mais à la fin de chaque source, tu lui indique quel fichier assembler à la suite.
Auteur :  Horos [ 20 Juin 2013, 12:15 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Bien vu Shap! Tu as raison, c'est une commande puissante. Je vois qu'elle est détaillée chapitre 5.4 du manuel : "L'assemblage par blocs".
Citer :
Lorsque le fichier texte dépasse une dimension de 20 Ko, il devient nécessaire de le découper en blocs
pour l'assembler, sinon il n'y a plus assez de mémoire pour contenir le code objet et la table des symboles.
Notez qu'un lecteur de disquette est presque indispensable pour l'assemblage par blocs, car chaque bloc
doit être chargé 2 fois pour les 2 passes.
Chaque bloc à assembler doit se terminer par la commande d'assemblage *F,s la chaîne s étant le nom
du bloc suivant. Cette commande d'assemblage doit être frappée en zone label et doit être la seule
instruction de la ligne.
Le dernier bloc ne doit pas comporter cette commande d'assemblage.
Je vais tester en profondeur cette commande qui va vite se révéler indispensable. Il suffit donc d'écrire F monprog.s (nom du fichier suivant) dans le champ label (étiquette) à la dernière ligne, sauf dans le dernier fichier. Simple et puissant.
Auteur :  shap [ 20 Juin 2013, 13:34 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Commande puissante effectivement mais ça devient vite lourd, car pour avoir à une époque assemblé un source de demo avoisinant les 50ko je peux te dire que réitérer ça à chaque fois c'est très long, surtout si tu exécutes souvent pour tester telle ou telle implémentation.

Je préfère largement assembler les parties de code terminées et les charger directement à partir du source en cours.
Auteur :  Hicks [ 20 Juin 2013, 18:27 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Bravo pour tes recherches sur A2/P2, c'est très intéressant...
Même si en fait, A2, du fait qu'elle place le code objet après la table des symboles, qui elle même se trouve (souvent) après DAMS, n'est pas adaptée aux gros sources, car si DAMS est implanté après #4000, il restera moins de 16k pour le code source + le code objet... Et si DAMS est avant #4000, P2 fonctionne sans A2.

C'est un peu comme la commande F : alléchante sur le papier, mais en fait inutilisable en réalité car beaucoup trop lourde. Quand je pense au nombre de fois que je dois exécuter un source en une session de code, s'il faut jongler entre A/F (qui fait 2 passes donc relis 2 fois le disk)... La solution plus gérable reste comme le dit Shap d'isoler des parties de son code et de les sauvegarder une fois pour toute, puis de les appeler via le programme principal (typiquement : un player ou un décruncher).

Mais reste que DAMS avec 128k de RAM est limitatif. Je crois que le source de chaque effet de chaque demo m'a contraint à des contorsions finales pénibles car les codes dépassaient tous 20k (malgré la suppression de tous les commentaires). J'ai encore ce problème actuellement : obligé d'isoler l'intro, le code de tel effet, pour que tout rentre. Mais je n'ose même pas évoquer la possibilité d'un "nouvel assembleur sur CPC" :)

Enfin, bref, je ne veux pas te casser le moral Horos, alors encore bravo !
Auteur :  Horos [ 20 Juin 2013, 22:09 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Hicks a écrit :
Enfin, bref, je ne veux pas te casser le moral Horos, alors encore bravo !
Ne vous inquiétez pas les gars, impossible de me casser le moral. :)
Je n'ai pas votre expérience d'autant d'années avec DAMS ou le CPC,
donc c'est bien de m'indiquer aussi les inconvénients ou lourdeurs de certaines commandes.

Hicks a écrit :
Et si DAMS est avant #4000, P2 fonctionne sans A2
Ben non puisque DAMS est buggé justement. Si tu mets DAMS avant #4000, par exemple en #3E8, et ton code à assembler en #100,
tu verras que le point d'entrée est faux (#FFF6 lowbyte highbyte) et que P2 ne fonctionne pas. (P2 ne fonctionne QUE lorsque DAMS est plus bas que ton code)

*petite astuce pour aller voir le point d'entrée en nn+47 facilement:
D#3E8+47 et DAMS calcule à votre place (remplacer #3E8 par votre valeur)

Hicks a écrit :
Même si en fait, A2, du fait qu'elle place le code objet après la table des symboles, qui elle même se trouve (souvent) après DAMS, n'est pas adaptée aux gros sources...
Tout a fait, A2 n'est pas du tout faite pour assembler les gros sources. Je l'ai juste indiquée si l'on veut utiliser P2, car à ce moment là P2 fonctionne dans tous les cas (plus besoin de mon patch). Mais en dehors de ça, il faut utiliser la commande A, car A2 ne la remplace pas du tout.

La commande A1 elle par contre, est adaptée aux gros sources, car elle utilise la mémoire vidéo pour y placer la table des symboles :

Citer :
Documentation de DAMS :
5.1. Les options
L'argument n des commandes A et F définit les options choisies.
1. Indique à l'assembleur qu'il doit utiliser la mémoire écran de 16 Ko pour y loger la table des symboles.
Ceci est utile lorsque la taille du fichier texte est très importante ou lorsque DAMS est exécuté à une
adresse haute.

Hicks a écrit :
J'ai encore ce problème actuellement : obligé d'isoler l'intro, le code de tel effet, pour que tout rentre.
J'avais travaillé sur des fichiers remplissant la totalite de la mémoire disponible du CPC dans les années 80, mais j'ai oublié les astuces que j'utilisais à l'époque.
Mais une chose est sûre, je n'utilisais pas à fond les instructions méconnues de DAMS comme je m'y intéresse aujourd'hui.
On pourra certainement échanger quelques astuces lorsque j'aurai progressé.

Par exemple, j'ai découvert aujourd'hui que si on veut vraiment utiliser P2 avec A quand DAMS est plus haut en mémoire que ton code,
(même avec un DAMS en #6D60!) c'est possible :
P,monprog.s
A,monprog.s
p2,monprog

Ainsi, pas besoin d'utiliser A2 ni mon patch. :D
Auteur :  Plissken [ 20 Juin 2013, 22:11 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Ce serais interressant une espece de making of de demo.

Notament pour still rising,les difficultés rencontrées,d'ou te son venu tes idées.
Auteur :  hERMOL [ 21 Juin 2013, 10:53 ]
Sujet du message :  Re: utilisation et implantation de DAMS
je me pose une question... ca vaudrai le coup de sourcer pour le recompiler completement DAMS, un peu comme je l'ai fait avec OCP ??? quelqu'un serai intéressé ? Passage en ROM ajouter de commande custom ?
Auteur :  shap [ 21 Juin 2013, 11:23 ]
Sujet du message :  Re: utilisation et implantation de DAMS
hERMOL a écrit :
je me pose une question... ca vaudrai le coup de sourcer pour le recompiler completement DAMS, un peu comme je l'ai fait avec OCP ??? quelqu'un serai intéressé ? Passage en ROM ajouter de commande custom ?

Je ne pense pas que ce soit intéressant, dans ce cas autant se lancer dans la réalisation d'un nouvel assembleur, mais quant à la probabilité que ça arrive, je rejoint Hicks.....
Auteur :  hERMOL [ 21 Juin 2013, 12:03 ]
Sujet du message :  Re: utilisation et implantation de DAMS
shap a écrit :
hERMOL a écrit :
je me pose une question... ca vaudrai le coup de sourcer pour le recompiler completement DAMS, un peu comme je l'ai fait avec OCP ??? quelqu'un serai intéressé ? Passage en ROM ajouter de commande custom ?

Je ne pense pas que ce soit intéressant, dans ce cas autant se lancer dans la réalisation d'un nouvel assembleur, mais quant à la probabilité que ça arrive, je rejoint Hicks.....

Sourcer un prog de cette taille prends en gros 2/3 heures
Auteur :  Hicks [ 21 Juin 2013, 12:17 ]
Sujet du message :  Re: utilisation et implantation de DAMS
Je ne dis pas que ce serait inutile, mais le principal "problème" de DAMS, ou de tout assembleur natif actuellement, n'est pas qu'il ne réside pas en ROM mais qu'il impose des contraintes d'implémentation du source et ne permettent pas d'exploiter les 128k librement. Car rien n'empêche, à chaque retour à DAMS, de le recopier de la ROM à la RAM si on a pas pu le conserver dans les banks. Madram avait fait une RSX en ce sens dans les dernières versions de la ROM OVL.

Un nouvel assembleur consisterait à :
1) Résider en ROM
2) Permettre le stockage du source et de tout ce dont il a besoin dans une RAM d'extension (hors 128k)
3) Permettre l'implémentation du source partout (#0000, #B000, #C000) : ce qui implique soit de réécrire les routines fondamentales (à mettre en ROM) ou alors de faire un switch des 64k linéaires au moment de l'assemblage avec 64k d'extension.
4) On peut imaginer un assemblage via le réseau avec 2 CPCs : en cas de plantage, c'est le CPC de test qui reboot et non le CPC où se trouve le source. Car les reboot deviennent génant en phase de finition lorsqu'il y a 30/40k de datas à recharger (Mais cette fonctionalité est déjà moins indispensable et plus difficilement exploitable (2 CPCs, temps de transfert du source, etc.)).

Le confort serait alors bien meilleur : possibilité d'assembler un source partout, pas de restriction sur la taille du code source et du code objet, pas besoin de reboot quand ça plante. Il faut un support hardware derrière : Ramcard/Flash'Gordon et extension RAM (64/128k suffisent). Tout cela est dans ma pile de brouillons, et ne servirait probablement qu'à moi :)
Page 3 sur 5 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/