Je commence à faire les premiers tests de D.A.M.S v1.1 :
- La commande P3 fonctionne bien, sympatique. (j'ai pas testé toutes les nouvelles commandes ou fonctionnalités, ça viendra)
- L'Editeur a une petite différence : Pour entrer une nouvelle ligne, il faut appuyer SHIFT+ flèche gauche au lieu de simplement flèche gauche dans DAMS1.0 (On s'y habitue très vite)
- SHIFT+ flèche gauche ou droite déplace bien le curseur de 5 caractères.
- La commande "A" (Assembler) est évidemment toujours bugguée puisque Pascal ne s'en était jamais aperçu. (faut arrêter de boire Pascalou ^^)
Des générations de codeurs ont été embétés par ce bug alors qu'il suffisait d'assembler par exemple à partir du fichier source : A,monprog.s puis P2,monprog car la commande "A" n'est pas bugguée dans ce cas. On peut maintenant appliquer le patch que Longshot et moi-même avons mis à votre disposition. Sinon comme Hitch le préconise, on peut se contenter de sauver le source et d'exécuter en RAM.
Petit screenshot pour montrer que D.A.M.S 1.1 souffre aussi de ce bug avec la fausse valeur &FFF6 qui vient se coller à la place du &2131. On patchera aussi ne vous inquiétez pas.
La commande P2 n'écrit pas le fichier sur la disquette dans la version 1.0 mais sans afficher de message d'erreur. Alors que la v1.1 affiche le message d'erreur 8 : "Bad memory error"...
*les plus attentifs noteront le décalage d'un octet entre la v1.0 et la v1.1
** faudra me virer ce saut de ligne entre Pass 1 et Pass 2 : c'est moche. ^^ *** et remettre le point avant DAMS, c'était mieux aligné. :) **** Je propose : .DAMS 1.1 Pascal Séguy
Dernière édition par sPOKE le 11 Mars 2015, 09:59, édité 3 fois.
Non. J'ai commencé à utiliser D.A.M.S il y a 30 ans, et je le connais comme ma poche (malgré 28 ans d'arrêt) donc je changerai jamais. Il me suffit amplement.
La plupart les codeurs qui retrouvent leur CPC après des années d'absence se disent : "Où est ce bon vieux DAMS ?". Orgams est sûrement un très bon logiciel, mais D.A.M.S est une légende.
Petit screenshot pour montrer que D.A.M.S 1.1 souffre aussi de ce bug avec la fausse valeur &FFF6 qui vient se coller à la place du &2131. On patchera aussi ne vous inquiétez pas.
humm... ces 2 screenshots on l'air de montrer 2 sections de code tout a fait différentes. Je doute de la pertinence d'appliquer un patch similaire. D'autant que si t'a chargé DAMS a &4000, a &4020 y'a pas du code.
J'ai repris le code en main, je sais générer DAMS et je peux le corriger et le faire évoluer à volonté.
Toutefois mon objectif premier est de finir de le commenter tel qu'il est, sans le modifier, de façon à "figer" quelque chose qui à existé pendant 30 ans et dont j'avais perdu la compréhension. Si j'avais du temps, j'aimerais désassembler la 1.0 dont je n'ai pas les sources, afin de les recréer en m'aidant de la 1.1 (je pense qu'il y a peu de différences entre les 2 versions).
Ensuite je vais changer la bannière et corriger des gros bugs si j'en trouve (si vous pouvez m'expliquer les patchs que vous avez conçu), et je vais lâcher le tout sous la version 1.2, en source, dans les semaines qui suivent.
Il me tardera alors de voir vos améliorations et corrections, (pavé numériques, etc...), et vos commentaires de code sur les parties spécifiques CPC dont je vais faire abstraction.
Ensuite il se pourrait que je le fasse évoluer pour le rendre plus propre, plus fiable, romable, et selon ma façon de voir les choses aujourd'hui.
humm... ces 2 screenshots on l'air de montrer 2 sections de code tout a fait différentes.
C'est normal car il s'agit de DAMS 1.0 et de DAMS 1.1 : pas strictement identiques donc. Mais le pointeur de début est bien là, bien visible : nn+47 et nn+48 (décalé de 1 octet dans DAMS 1.1)
PSy a écrit :
Je doute de la pertinence d'appliquer un patch similaire.
Tu mets ma parole en doute? Je viens à l'instant de patcher D.A.M.S 1.1
Il fonctionne à présent très bien (la commande "A" suivie de la commande "P2" et m'écrit bien le programme objet .BIN sur la disquette à présent. Il n'y a plus de message d'erreur 8 : "Bad memory Error".
J'ai utilisé la même technique. Sauf que bien-sûr l'adresse mémoire a changé : &5B26-&5B27 au lieu de &56D4-&56D5
Il m'a suffit de désassembler D.A.M.S 1.1 pour trouver l'emplacement.
PSy a écrit :
D'autant que si t'a chargé DAMS a &4000, a &4020 y'a pas du code.
Mais si! Bien sûr qu'il y a du code! Mais pas tout de suite au chargement. Seulement après l'exécution de DAMS. Car DAMS s'auto-modifie alors immédiatement. Et place en nn+47 et nn+48 les pointeurs de debut. (effaçant "Aglae et Sidonie" ou bien "Written by Pascal Séguy")
Relis-bien mon topic que j'ai écrit sous le nom d'Horos (moi-même donc) pour comprendre ce bug.
Je tiens une version corrigée de D.A.M.S 1.1 à ta disposition si tu le souhaites. Je vais afficher ici les screenshots de l'opération. (Réalisée tout en matant une bonne série (Person of Interest) comme d'hab. Haha
Je commence par charger D.A.M.S 1.1 en mémoire, en &4000, sans le lancer, et je POKE le patch : (J'ai desassemblé DAMS 1.1 pour trouver la routine buguée quelques minutes auparavant)
J'écris ce simple bout de code pour le test. Ca affiche un simple "Z" (qui veut dire Zorro )
J'assemble le code source (commande "A") puis je sauvegarde le code objet MONPROG.BIN (commande P2)
Ca marche. Plus aucune erreur 8 : "Bad memory Error" ne s'affiche désormais.
On retourne sous BASIC avec la commande "B" et on affiche le catalogue :
Le programme en langage machine "MONPROG.BIN" a bien été sauvegardé sur la disquette.
On va le charger et le lancer pour être sûr qu'il fonctionne bien :
Voilà, D.A.M.S 1.1 pour sa commande "A"ssembler et P2 fonctionne correctement.
D'autant que si t'a chargé DAMS a &4000, a &4020 y'a pas du code.
Mais si! Bien sûr qu'il y a du code! Mais pas tout de suite au chargement. Seulement après l'exécution de DAMS. Car DAMS s'auto-modifie alors immédiatement. Et place en nn+47 et nn+48 les pointeurs de debut. (effaçant "Aglae et Sidonie" ou bien "Written by Pascal Séguy")
Mille quenouilles, je sais bien ce que DAMS fait dans cette zone là: c'est des variables, pas du code. nn+47 correspond bien a une variable qui peut avoir un impact sur la sauvegarde, mais volatile.
Question: avec quelle option tu assembles ? as-tu essayé avec A2,monprog, puis P2
Mille quenouilles, je sais bien ce que DAMS fait dans cette zone là: c'est des variables, pas du code.
Oui, je sais que ce sont des variables et des vecteurs. Moi j'appelle ça du code. Je veux dire par là que ce n'est pas vide ni une zone non utilisée.
PSy a écrit :
nn+47 correspond bien a une variable qui peut avoir un impact sur la sauvegarde, mais volatile.
C'est ce vecteur (ou variable) qui m'a permis de comprendre d'où venait le bug de la commande "A", la première fois que j'ai desassemblé D.A.M.S 1.0 pour le patcher. La commande "A" mets une fausse valeur à nn+47/nn48 lorsque D.A.M.S est placé plus haut que le code source.
J'avais donc écrit ce patch en quelques lignes de BASIC pour faire le boulot de "A" avant qu'on trouve la routine défaillante :
Code :
1 KEY DEF 68,1,159:KEY 159,"GOTO 1000"+CHR$(13) 1000 a$="":b$="":ad=nn+10485+1:IF PEEK(ad)=35 THEN b$="&":ad=ad+1 1010 IF PEEK(ad)<>13 THEN a$=a$+CHR$(PEEK(ad)):ad=ad+1:GOTO 1010 1020 ORG=val(b$+a$):IF ORG<0 THEN ORG=ORG+65536 1030 IF nn<ORG THEN CALL nn ELSE highbyte=int(ORG/256):POKE nn+47,ORG-(256*highbyte):POKE nn+48,highbyte:CALL nn
PSy a écrit :
Question: avec quelle option tu assembles ?
Comme tu peux le voir sur les screenshots, avec la commande "A", sans option, vu qu'elle fonctionne dans tous les cas à présent et ne fausse plus le vecteur.
Salut Pascal. Je vais coller ta réponse ici car si on se parle sur 2 topics différents, on ne pourra pas suivre la discussion.
PSy a écrit :
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 ?
Bravo et merci TotO !
En fait, le bug est que faire P2 après un A0, devrait produire un message d'erreur comme le fait DAMS 1.1 il me semble.
A force de parler de cette histoire, je crois que la philosophie du truc commence à me remonter: Faire A0, c'est pour générer du code à exécuter tout de suite, à mettre au point. Les variables (defw...) ne seraient alors plus dans leur état initial, donc faire un P2 après cela sauvegarderait non pas le code objet, mais son image mémoire à l'instant T où le code objet a été stoppé.
Quand on veut écrire le code objet sur disque, on fait A2 qui est moins prise de tête en tant que mémoire dispo, et P2, et on est sûr de ce qu'on a mis sur disque.
Bravo sPOKE pour tes investigations, j'espère avoir répondu a tes interrogations, désolé d'avoir attendu si longtemps
Bon, je pense que tu n'as pas compris comment fonctionne le bug, tout simplement.
- La commande P2 n'oblige absolument pas d'être utilisée avec A2.
- A2 fonctionnne car il n'a pas besoin d'aller chercher le "ORG"
- A est buggée car elle foire au moment d'aller chercher le "ORG" et insère une fausse valeur. Je me répète là...
Etonné par la réponse de Pascal ci-dessus, je lui ai envoyé une question par e-mail, et j'ai donc la confirmation qu'il ne comprend pas le bug ni le patch... C'est pas grave Pascal, on va t'expliquer.
Quand on veut écrire le code objet sur disque, on fait A2 qui est moins prise de tête en tant que mémoire dispo, et P2, et on est sûr de ce qu'on a mis sur disque.
Les numéros de fonction ne marchent pas par "paire" A0, A1, A2 concerne la méthode d'assemblage (adresse du ORG pour A0, A1 (écran pour loger les symboles)) ou en relatif. P0, P1, P2 concerne la sauvegarde de source (pour P0, P1) et de code pour P2 Seul P2 permet de sauver le code binaire sans distinction de la méthode d'assemblage. Si on suit le raisonnement de A0/P0, A1/P1, on ne va pas très loin... Pourquoi n'en faire qu'un lorsqu'on peut faire les deux...
Entièrement d'accord avec sir Longshot.
Quand une routine est buguée, on la corrige. On ne propose pas d'en utiliser une autre à la place. CQFD.
Dernière édition par sPOKE le 13 Mars 2015, 04:03, édité 1 fois.
Questions posées par e-mail car j'étais surpris de l'explication un peu "fumeuse" de Pascal
sPOKE a écrit :
Salut Pascal,
Tu as l'air de dire sur le forum qu'il n'y a aucun bug dans ta commande "A" et que c'est moi qui me suis trompé en utilisant "A" au lieu de "A2". Tu dis que le bug est d'utiliser A avec P2.
Si c'était vrai, notre patch aurait été impossible à réaliser. Et ne pourrait pas fonctionner. Dans ce cas comment explique-tu que le patch fonctionne si bien ? As-tu analysé le bug au moins ? L'as tu compris au moins ?
PSy a écrit :
Salut Olivier, Oui, je comprend que si tu renseignes à la main l'adresse du code objet pour la routine de sauvegarde, alors P2 fonctionne. Mais tu devra faire ce patch pour chaque ORG utilisée.
Ben non, t'as pas compris justement. Je n'aurai pas à faire ce patch pour chaque ORG utilisée. Ce serait une galère pas possible. DAMS 1.1 est vraiment corrigé. Il fournit à chaque fois lui-même la bonne valeur maintenant. Dire que je renseigne la valeur à la main pour que P2 fonctionne montre que tu n'as pas compris ce que je POKE pendant le patch. Ce n'est pas la valeur du "ORG"... Ce ne serait pas un patch sinon.
PSy a écrit :
Faudra que je regarde cette partie de code en détail et que je fixe cela. En tout cas, c'est sur y'a bug car ca ne met même pas de warning.
On l'a déjà fixée, c'est ça que tu ne comprends pas.
PSy a écrit :
Et comme workaround je préfère dire d'utiliser A2/P2 plutot que de dire d'utiliser A0 et de renseigner 'BORG' (c'est le nom de la variable) a la mano par un poke avant chaque P2 avec un nouvel ORG.
Non, non et non, je ne renseigne pas "A la mano" par un POKE avant chaque P2 avec un nouvel ORG.
Tu crois que je me fatigue à POKER la valeur du ORG à chaque assemblage/sauvegarde ?? Cela montre que tu n'as pas compris. Ce serait un travail fastidieux! LOL. J'ai déjà tout expliqué en long et en large.
D.A.M.S 1.1 est patché, et même lorsqu'il se trouve placé plus bas que le code, il sauvegarde correctement le programme objet (.BIN) à chaque fois. Je ne POKE plus rien, puis qu'il est fixé. Je ne peux pas être plus clair.
J'étais intrigué par ton message bizarre, maintenant j'ai compris que tu n'as même pas compris que DAMS est fixé.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Dans mon souvenir c'était un problème de test de valeur. La valeur du ORG est comparée à la zone ou se trouve DAMS pour faire un "Bad org" (ou un message du genre) le cas échéant. Dans cette comparaison il y avait un petit bug pour tester sil le ORG est après la fin de DAMS. Le mieux, c'est de désassembler la partie patchée avant et après, et de l'indiquer sur le forum. Ce sera plus clair, notamment si Pascal veut corriger le source.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 78 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum