Inscription : 20 Août 2007, 18:21 Message(s) : 5103
yes ! du "remote debugging" avec deux CPCs par RS232 serai du luxe.. Dans un premier temps recompiler DAMS en ROM pourrait être jouable . puis automatiser la sauvegarde des sources/variables interne sur disk lors de l'exécution permettrais un gain de RAM ???
Dans un premier temps recompiler DAMS en ROM pourrait être jouable .
à mon avis tu n'as pas encore regardé DAMS pour dire ça, je ne dit pas que ce ne serait pas jouable, mais ce serait très compliqué.... DAMS est codé de manière très compacte et s'automodifie beaucoup, donc faire une version ROM demanderait de faire de très grosses modifications au code.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Hum ,je sens qu'il y en a au moins 2 sur le sujet qui vont me frapper mais pourquoi ne pas plutôt faire ça via une cpcbooster en compilant le code depuis un PC (attention j'ai bien dit sans passer par un émulateur hein), en se débrouillant bien , ça peut être quasi transparent =)
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
ca vaudrai le coup de sourcer pour le recompiler completement DAMS
ça veut dire quoi "recompiler" DAMS ? Je compile du C++, mais je ne vois pas comment on peut compiler du langage machine... tu t'y prends comment ? avec un PC ?
fano a écrit :
en compilant le code depuis un PC (attention j'ai bien dit sans passer par un émulateur hein)
Même question. Tu utilises un compilateur C sur PC qui recompile du langage machine Z80 pour le remettre sur le CPC ?
C'est quoi un cpcbooster ?
Désolé pour ces questions, mais je ne connais pas ces outils modernes.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Horos a écrit :
C'est quoi un cpcbooster ?
Désolé pour ces questions, mais je ne connais pas ces outils modernes.
La Cpcbooster ( http://www.cpcwiki.eu/index.php/CPC_Booster ) c'est une interface qui te permet , entre autres, d'avoir une liaison par le port série avec un PC , moyennant un module supplémentaire (10€ à Hong Kong) on peut l'utiliser en bluetooth.( http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/bluetooth-on-cpc/ ) En fait , je dis 'en compilant' par déformation (comme c'est usage dans les autres languages), c'est en assemblant avec un assembleur Z80 sur PC
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
En fait , je dis 'en compilant' par déformation (comme c'est usage dans les autres languages), c'est en assemblant avec un assembleur Z80 sur PC
Ah ok, tu as assemblé ton code avec un assembleur Z80 sur PC (lequel au fait ?) , tu ne compiles pas. Merci de penser à moi les gars et de dire "assembler" (au moins dans cette discussion) car là je ne comprenais plus rien du tout à votre conversation!
Moi je programme en C++ sur PC avec CodeBlocks, et là, oui, j'utilise un compilateur.
Il compile ou il assemble ? Je ne vois pas comment on peut "compiler" du code Z80. Ce truc est juste un logiciel assembleur-desassembleur, non ? c'est quoi ce terme "cross-compiler" ? comment ça fonctionne ? (rapidement, car je préfère qu'on parle de DAMS tout de même et qu'on reste sur le sujet. Mais vu que vous utilisez ce genre d'outils sur PC pour écrire des programmes pour CPC, on peut en parler un petit peu)
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
D'un point de vue pratique, la différence entre assembler et compiler est ténue et ne tient pas à grand chose, assembler sous entend juste que le langage est l'assembleur. Un cross assembler/compiler c'est juste un programme qui fonctionne sur une machine hôte (PC/ST/Amiga/etc) et qui te génère ton binaire au format natif pour une machine cible ou un processeur cible (Z80,ARM,ect...).
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Hum ,je sens qu'il y en a au moins 2 sur le sujet qui vont me frapper mais pourquoi ne pas plutôt faire ça via une cpcbooster en compilant le code depuis un PC (attention j'ai bien dit sans passer par un émulateur hein), en se débrouillant bien , ça peut être quasi transparent =)
"Le Cross-dev est à l'Amstrad ce que la poupée gonflable est à la femme" :)
Inscription : 28 Août 2008, 23:41 Message(s) : 270
@Horos : Pour corriger le bug de dams, il suffit de le patcher : Si il est chargé en &4000, poke &56D4,0 et poke &56D5,&A7 Et P2 fonctionnera dans tous les cas. Il y a un bug dans la routine située en #6140 qui teste que l’adresse d’assemblage n’empiète pas sur dams (bit C mal positionné). Le test en sortie de cette routine est superflu car le « bad org » est géré par une exception à la routine de test. On le remplace par un nop, suivi d'un and A pour ne pas fausser le calcul de l'adresse de début. Je n'ai pas tout testé, mais je ne crois pas qu'il y ait des effets de bord.
Suite à ta question 1 en MP: Pour trouver ça il suffit de rechercher dans le code "linké" de dams la chaine 2F 40, puisque c'est toi qui a donné l'adresse mal positionnée, et il est facile de tomber ainsi sur la routine qui suit l'appel de #6140. Suite à ta question 2 : Dams traite les chaines de commande via un buffer situé en #4053. La liste des commandes est interprété via un CPIR sur #496A permettant de router les différentes instructions.
Merci d'avoir patché DAMS, excellent! J'ai bien testé les pokes , ça marche très bien!
(Effectivement, je le sais depuis hier déjà, héhé. )
Je suis très content si j'ai pu modestement contribuer à cela, en apportant des idées, et si mes recherches sur p2 ont aidé, tant mieux, au moins à remettre la lumière sur DAMS.
Je vais tranquillement pouvoir désassembler la routine buggée maintenant. Presque 30 ans après, ce bug est corrigé!
Cette discussion apporte plein d'idées! Entre ceux qui veulent patcher DAMS, ceux qui veulent le mettre en Rom, et ceux qui veulent utiliser 100% de ses commandes méconnues comme moi.
Au sujet de disposer d'un assembleur en rom, c'est sûr que ça a l'avantage d'être confortable. Mais j'avais écrit un programme qui prenait toute la Ram du CPC dans les années 80 et DAMS ne m'avait pas gêné du tout. J'ai toujours été un adepte de la programmation modulaire, qui est toute à fait adaptée face à ce genre de problématique.
C'est intéressant pour moi de trouver des astuces pour découper un programme en plusieurs parties et d'assembler tous les blocs à la fin. Donc je vais rester sur DAMS 100% en Ram pour ma part. A l'ancienne aussi.
Ensuite, chacun, en fonction des projets sur lesquels il travaille, de leur ampleur, peut avoir besoin d'autres outils que moi.
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Dams était aussi fâché avec la touche ESC, qui décalait l'écran si on avait le malheur d'appuyer dessus par inadvertance Ca pouvait se contourner en redéfinissant la touche ESC en basic il me semble. Un autre bug était la mauvaise gestion du registre R dans le mode trace. Heureusement d'ailleurs pour les éditeurs car cela en aurait fait une arme de déplombage encore plus redoutable.
Concernant le problème de place que nous avons évoqué (dams+source+code), la solution passe en effet par la modularisation des sources, en créant des "obj", avec 2 tables de pointeurs par source créées pour chaque relation entre 2 sources. La première table déclare les dépendances du source A envers le source B, et la seconde les dépendances du source B envers le source A. Pour linker les 2 "obj" il suffit de parcourir chaque table pour affecter les dépendances de chaque code. Ainsi à chaque fois qu'un source est modifié, il crée sa table de dépendances internes et externes. L'idéal étant de la sauver sur disque. Mais il est également possible de garder les obj dans les banques afin de les relinker à chaque modification d'un source vis à vis de tous les autres sources pour lequel il a des dépendances. Cela permet de travailler sur des sources plus court et ne pas sabrer tous les commentaires pour gagner de la place.
Ainsi pour simplifier tu as par exemple une table dans S1 (source 1): TABLINK DW S1RELS2 DW S2RELS1 ... FONCTION1 S1MDCO1 LD HL,0000 S1MDCO2 LD DE,0000 FONCTION2 CP C
Pour linker les 2 obj, il faut : parcourir la table S1RELS2 du source A et pour chaque pointeur lu, y stocker les valeurs de S1RELS2 du source B parcourir la table S2RELS1 du source B et pour chaque pointeur lu, y stocker les valeurs de S2RELS2 du source A Ca suppose bien sûr de bien "modulariser" ses sources fonctionnellement pour diminuer les dépendances entre les objets. Et cela suppose de mettre en place une gestion plus complexe des tables de link lorsqu'on jongle avec plus de 2 sources Avec 3 sources A, B, C, chaque module peut avoir des dépendances avec 2 autres modules, et ainsi de suite.
Ô Longshot, Ô Horos, je m'incline devant votre grandeur ! :) Fonction p2 de DAMS patchée en 2 pokes, c'est du bon boulot. Le top aurait été de pouvoir faire un Wnn+#16D4,#A700 directement sous DAMS, mais il ne tolère aucun poke dans sa zone de travail pour éviter les mésaventures/plantages.
Ô Longshot, Ô Horos, je m'incline devant votre grandeur !
Tout le mérite revient à Longshot, j'aurais été bien incapable de patcher DAMS.
Hicks a écrit :
Le top aurait été de pouvoir faire un Wnn+#16D4,#A700 directement sous DAMS, mais il ne tolère aucun poke dans sa zone de travail pour éviter les mésaventures/plantages.
Oui, la commande W est la première chose que j'avais essayé avant d'écrire le patch BASIC, mais DAMS se protège lui-même. Une façon de hacker ça serait de trouver à quel endroit il stocke son adresse d'implantation et de la modifier pour lui faire croire qu'il est ailleurs, ou de chercher le test de protection mémoire. Pas vraiment indispensable dans l'absolu, mais toujours fun à essayer. J'ai bidouillé parmi ses 256 premiers octets, puis relancé DAMS par l'adresse moniteur (+2354) pour éviter qu'il ne remette à jour les valeurs, mais j'ai pas encore réussi ce trick.
Heureusement un petit SAVE "DAMS.BIN",B,nn,longueur depuis le Basic marche très bien et patche DAMS et sa commande p2 définitivement. (car même si Wnn+#16D4,#A700 avait fonctionné, la fonction P ne permet pas de sauvegarder une zone mémoire autre que le programme objet)
Mais bon, y a moyen de rajouter cette fonction "sauvegarder une zone mémoire" à DAMS en rusant... Vous vous souvenez de mon patch BASIC ? et de mon astuce de changer les pointeurs début et fin du programme objet en nn+47 et nn+76 ?
Nous allons nous servir de cette astuce pour faire croire à DAMS que le programme objet va de nn à nn+longueur de DAMS. Ainsi, DAMS va se sauvegarder lui-même entièrement !
Depuis le BASIC : (par exemple nn=&4000, longueur de DAMS=&2D77)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 45 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
Connexion
Inscription
FAQ
