|
DCMOTO - Emulateur universel Thomson 8 bits : Forum - Programmation - patcher la mémoire dans dcmoto
|
|
|
Orion_
Visiteur
|
Date : 13/05/2005 à 00h07
Bonjour,
voila, je me suis mis a la programmation assembleur sur mo5 recement et j'utilise l'emulateur dcmoto qui est vraiment excellent :)
seul petite remarque, j'aurais voulu savoir si il etait possible de faire une option pour charger un binaire dans la mémoire du mo5 a une adresse precise ?
ça serais quand même super pratique pour tester sont programme sans le taper a la main avec un loader en basic :/
parcequ'en fait j'utilise un assembleur sur pc qui me produit un fichier binaire (ce qui est quand même plus pratique que de programmer directement sur l'emulateur mo5, point de vue edition du programme ^^)
pour l'instant je patch un fichier .mrx a la main a l'editeur hexa pour y inclure mon programme puis je charge le mrx
dans dcmoto, mais c'est pas super pratique :/
merci d'avance !
|
| en haut - en bas |
|
|
|
Orion_
Visiteur
|
Date : 13/05/2005 à 00h14
ou sinon j'etait en train de penser, si y'a moyen de charger ça avec l'option "charger cartouche" ?
qu'elle est l'adresse mémoire ou est chargé une cartouche ?
faut-il faire quelque chose de spécial ou le code est-il directement executé a l'adresse 0 de la cartouche ?
|
| en haut - en bas |
|
|
|
Fool-DupleX
Visiteur
|
Date : 13/05/2005 à 09h17
Bonjour Orion_ , qui es-tu, que fais-tu dans la vie, etc. ... (question de politesse quoi)
L'adresse de base de la cartouche sur MO5 est 0xB000 et l'espace fait 16 Ko. Les deux dernieres addresses, 0xEFFE-0xEFFF, doivent contenir le point d'entree de ton programme.
Sinon tu peux aussi utiliser la cartouche assembleur pour mo5 pour tes developpements, ce sera surement au final plus rapide...
Daniel, on ne peut pas charger directement en memoire ? Quand je pense que Emul5 le fait depuis le tout debut, y compris en appliquant des masques et des operations logiques sur le contenu ... 
Fool
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 13/05/2005 à 10h01
J'ai essaye de developpe en externe avec des compilateurs, mais j'ai laisse tombe au final. Je compile directement sous emulateur (en boostant la vitesse).
Mais c'est clair que les editeurs sous Thomson n'offre pas 1/10 de la facilite d'un notepad Faudrait que je re-essaye, ca me ferait gagner des heures de saisie en faisant des copier/coller (quand tu fais de la demo, ca y va les copier/coller  )
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 13/05/2005 à 11h42
Le chargement direct en mémoire est déjà utilisé par Jacques Brigaud pour la mise au point du système OS/9 sur MO6.
Il faut utiliser les fonctions "Sauver .mrx" et "Charger .mrx" du debugger.
Un fichier .mrx contient l'état complet de la machine : ram + rom + registres du processeur + palette de couleur + ports d'entrées/sorties. On peut le modifier avec un éditeur hexadécimal, par exemple pour changer la rom système ou la rom Basic. Et en particulier pour la remplacer par OS/9.
Cette méthode est pratique pour tester de nouvelles roms, cependant, je ne la conseille pas pour charger un fichier binaire en ram, car il y a beaucoup plus simple. Voici comment je fais :
Soit un fichier binaire TOTO.BIN de &H800 octets, à charger en &H9000 et à exécuter en &H903A.
Avec un éditeur hexadécimal, on ajoute au début &H0008009000 et à la fin &HFF0000903A
Ce fichier est mis seul dans un sous-dossier, ce qui permet de créer un fichier .fd avec DCFDUTIL à partir du contenu du sous-dossier.
Dans dcmoto il suffit de charger ce fichier .fd, et en Basic la commande LOADM"TOTO" charge le fichier binaire en mémoire.
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 13/05/2005 à 12h11
Pour travailler dans l'espace cartouche, on peut effectivement reconstituer un fichier memo5 ou memo7, mais il faut respecter sa structure, et comprendre le système de commutation des banques pour les cartouches de plus de 16K. Les memo7 et les memo5 diffèrent largement sur l'un et l'autre point.
En émulation TO8, une autre solution est de passer par un fichier .CHG
C'est pratiquement semblable à un fichier memo7, mais il faut le mettre dans un fichier .fd (avec dcfdutil) et le charger avec la fonction adéquate du TO8.
Les memo7 ont un système de contrôle du nom par une checksum, stockée à l'adresse 0x1A. Les .chg ont également un contrôle par checksum, stockée dans le répertoire de la disquette, avec un code déterminant le nombre de banques de 16K. Si toutes ces données ne sont pas correcte, il n'est pas possible de lancer le programme.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 13/05/2005 à 12h29
Et pour eviter de devoir t'emmerder avec un editeur hexa pour transformer l'executable en binaire thomson, tu peux passer par TOCONV de Prehisto qui transforme les binaires PC en binaire Hexa. Attention ceci dit, car l'adresse d'implementation et d'execution est par defaut a 0000
donc quand tu charges ton fichier, tu le decales et du fait un EXEC a la main. Je pense que ce n'est pas un probleme lors du developpement, et je n'utilise d'ailleur que TOCONV quand je fais des binaires sur PC.
|
| en haut - en bas |
|
|
|
Orion_
Visiteur
|
Date : 13/05/2005 à 16h55
merci pour toute ces reponses :)
désolé j'ai oublié de me presenté :D
j'ai 20ans j'habite Paris pour mes etudes et je suis en école d'informatique première année (epitech)
j'ai tester en utilisant une cartouche et ça marche vraiment nikel :)
merci ^^
c'est plus pratique qu'avec le mrx ou de créer un fichier .fd a chaque fois
(si faut faire ça a chaque fois pour debugger le programme ça deviens vite lourd :/ )
y'a juste le points d'entré a la fin du fichier que mon assembleur supporte pas.
j'aurais voulu faire un
Fin:
REPEAT (16*1024)-2-Fin
FCB 0
FCW Start
mais ça marche pas :(
j'vais devoir quand même me faire un utilitaire pour ça ...
enfin ça tombe bien parceque j'avais comme projet de tenter de mettre mon programme sur cartouche memo5
a votre avis est-ce que c'est possible ? je suis pas super fort en electronique mais j'ai lu quelque part sur le forum que quelqu'un avais réussi a brancher une cartouche memo5 directement sur le port // d'un pc pour faire un dump, ça doit pas trop etre compliquer alors je pense au niveau des branchements. (enfin je suppose :D)
sinon j'ai remarqué que lorsque mon programme etait executé le curseur clignotait toujours.
je pense donc que des interuptions sont active, comment faire pour les desactivers ?
existe t'il une interuption VBL sur le mo5 ? (ou encore mieux HBL ?)
plus generalement y aurait-il des doc sur toute les adresse du mo5 qui ce trouve vers A700 ou quelque part par la,
par exemple comment changer la couleur du background general, etc...
merci d'avance :)
(apres avoir vu les capacitée de la palette du mo6 je me demande si j'aurais pas du choisir celui çi plutôt )
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 13/05/2005 à 18h02
Pour commencer, tu devrais lire le Manuel Technique du MO5, à la page Documentation du site dcmoto.
Il y a l'essentiel, et pour le reste tu peux poser des questions précises dans le forum.
21 ans après la sortie du MO5, nous ne savons pas encore tout sur lui, mais presque
Plus précisément :
- ORCC #$50 pour désactiver les interruptions
- Pas d'interruptions VBL ni HBL, mais des compteurs que l'on peut tester. Comme c'est un peu long, beaucoup de programmeurs préfèrent se synchroniser une fois sur la VBL, puis comptent les cycles du processeur pour rester synchrone. Mais c'est du sport de haut niveau
Daniel
|
| en haut - en bas |
|
|
|
Orion_
Visiteur
|
Date : 13/05/2005 à 18h58
merci :)
pour les interuptions tant pis, mais j'essayerais de me renseigner sur ces compteurs, voir ce qu'on peut faire.
actuellement j'essaye d'afficher un tableau de case de 8x8 (une map de jeu quoi)
mais c'est lent  (enfin je trouve que c'est lent pour moi  )
malgré les optimisations que j'ai fait.
ça doit etre du au fait que j'ecrit directement dans la mémoire ecran donc on vois l'affichage ce faire.
je suppose que sur mo5 y'a pas de double buffering ^^
donc a la limite, faire un rendu du tableau dans un buffer extern et ensuite recopier le buffer dans la mémoire ecran
suffisement rapidement pour pas voir de changement.
(le truc qui m'enerve le plus c'est histoire de mémoire de forme et de couleur, qu'on est obliger de changer avec un LDA,ORA/ANDA,STA ... je le fait actuellement pour chaque case de mon tableau)
la au moins je le ferais qu'une fois déja, et si je fait des boucles un peu deroulée ça devrait etre bon je pense :)
la question est au niveau des cycles, j'ai pas encore trouver de table de cycle mais avec dcmoto qui indique ou en est l'affichage (ligne/colone)
je peut peut etre me referer a ça pour compter.
j'hesite en ce moment, j'ai remplacer des LDA ,Y+ par des suites de LDA 0..1..2..3...,Y et des LDB #9 MUL, par 4 LSLA (en alignant les données sur 16) mais je sais pas vraiment si ça a un impact.
je pense que MUL est lent, mais le temps de charger 4 instructions LSLA dans le pipeline du processeur doit du temps quand même.
faudrat que je test au niveau des cycles :)
sinon vous me conseillez des trucs ou astuces a ce niveau ?
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 13/05/2005 à 20h53
Pour pouvoir optimiser, il faut connaître le nombre de cycles de chaque instruction. L'ouvrage de référence est le MC6809 programming manual, ou à défaut la datasheet du 6809. Le guide pratique PSI intitulé "Assembleur et Périphériques des MO5 et TO7/70" donne aussi des informations spécifiques aux machines Thomson. Tous ces ouvrages sont à la page Documentation de dcmoto.
Pour faire des transferts rapides en mémoire, il y a quelques exemples dans des jeux Infogrames qui utilisent l'empilage et le dépilage de registres PSHS et PULS. On peut, avec une seule instruction, charger D, X, Y, et U, et avec une deuxième les stocker en mémoire. On peut presque dire que le MO5 travaille en 64 bits (pas mal pour l'époque).
On peut aussi faire LDD ,X++ puis STD ,Y++ ou les instructions équivalentes avec d'autres registres. Il faut éviter les instructions avec préoctet (LDY, STY, LDS, STS) : le code est plus long, mais surtout beaucoup plus lent. MUL doit aussi être évité : il consomme 11 cycles, alors qu'un décalage en consomme 2. On gagne toujours à transférer un registre 16 bits plutôt que deux registres 8 bits.
En mémoire écran, il vaut mieux éviter de commuter les banques video à chaque octet. En général, on affiche toute la forme, puis toute la couleur (ou l'inverse) pour ne faire qu'une commutation.
Pour un affichage rapide, il faut la deuxième génération de machines (MO6 et TO8) où on dispose de deux techniques :
- la palette de couleurs : on met toutes les couleurs noires pendant l'affichage, puis on modifie la palette pour faire apparaitre l'image.
- le recouvrement de la mémoire video par la ram : on dessine en ram, puis on mappe l'espace écran sur la ram. C'est instantané.
Le MO5, comme le TO7 et le TO7/70, n'a pas ces dispositifs, ce qui augmente la difficulté, et ne permet pas l'animation rapide.
Daniel
|
| en haut - en bas |
|
|
|
FoolDupleX
Visiteur
|
Date : 14/05/2005 à 10h48
Ce sont juste des astuces pour masquer ce qui se passe pendant que tu prepares l'image. Ne parle pas de vitesse d'affichage Daniel, stp, la bande passante de la memoire est la meme sur toutes les machines... (evidemment, je ne parle pas de frames pre-enregistrees a l'avance qui bourrent bien les 512 Ko d'un TO8 gonfle, mais d'images calculees en temps reel).
Tout depend de la taille de l'image a afficher, mais on peut aussi se debrouiller sur mo5/to7 en synchronisant correctement la commutation forme/couleur avec le raffraichissement, et charger l'ecran dans l'overscan, et ce ne sera pas visible.
Orion_, tu trouveras plein de doc technique sur mon site ftp ftp://forler.ch/pub ainsi que chez Ghislain Fournier, http://www.fournier-family.com, il y a notamment chez moi le livre dans le repertoire BASASM qui te sera tres utile.
Oublie les histoires de double buffering et de pipeline de processeur. On parle d'une architecture qui date de la fin des annees 70, y'a absolument rien de tout cela. le nb de cycles depend directement de la complexite de l'instruction a executer et tout est bien synchrone. Tu trouveras ici et la des tables de cycles (tape 6809 dans google...).
Si le truc de memoire forme / couleur t'agace, essaye un peu de coder en CGA sur PC ou sur un sinclair spectrum ... tu trouveras probablement le mo5 sympa a cote !
Personnellement, je privilegie les arrangements astucieux en memoire et le code auto-modifiant pour faire des routines rapides. Une petite pincee d'instructions non-documentees peut aussi parfois faire l'affaire, bien qu'elles soient plus rares sur 6809 que sur Z80 !
Fool
|
| en haut - en bas |
|
|
|
|
|
|
Orion_
Visiteur
|
Date : 15/05/2005 à 11h40
ça depend si j'ai mon stage a paris ou non.
(je doit faire un stage entre septembre a decembre)
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 16/05/2005 à 17h07
| FoolDuplex a écrit : | | Ne parle pas de vitesse d'affichage Daniel, stp |
Si le terme "affichage" te choque, remplace par "apparition de l'image".
Evidemment je ne parlais pas du temps d'écriture en mémoire
Daniel
|
| en haut - en bas |
|
|
|
Orion_
Visiteur
|
Date : 24/05/2005 à 23h22
bonjour,
c'est re moi ^^
les opcodes du 6809 vont me rendre fou, quand je par sur une idée pour faire un truc je me rend compte a la compilation que tel ou tel opcode n'existe pas ou ne s'adresse pas de cette manière, raaaaah
actuellement j'essaye en vain de faire une multiplication d'un nombre (<256) par 320 :(
j'avais penser décomposer en (n*256)+(n*64) mais je rencontre encore des problemes
quelqu'un aurait une idée svp ?
|
| en haut - en bas |
|
|
|
Orion_
Visiteur
|
Date : 24/05/2005 à 23h24
pareil, pour faire un decalage de bit vers la gauche d'un nombre 16bits, j'ai réussi a faire une routine mais avec du self modifying code, et manque de bol, ça marche evidement pas sur une cartouche (0xB000->0xF000) because read only
:'(
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 25/05/2005 à 07h45
Voici quelques pistes, à défaut de réponses précises :
- La multiplication des entiers (et aussi des nombres en virgule flottante) est programmée dans la rom Basic. Le plus simple est de s'en inspirer, ou même d'utiliser directement les routines existantes.
- Les programmes sur cartouche en &HB000-&HEFFF peuvent être copiés dans l'extension mémoire, qui occupe les mêmes adresses. Un bit de l'octet &HA7CB permet d'activer ou de désactiver la protection écriture.
- Les programmes sur cartouche utilisent habituellement des zones de travail en mémoire conventionnelle. Si une routine est automodifiable, on peut la copier entièrement en ram avant de l'exécuter.
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 25/05/2005 à 08h43
Pour illustrer le dernier point, j'ai retrouvé un de mes programme, glouton-memo5, écrit il y a une vingtaine d'années. Il se recopie intégralement en ram avant de s'exécuter.
Une autre idée pour la multiplication par 320 : multiplier par 160, puis faire un décalage à gauche. Ou décaler à gauche de 2, ajouter le nombre de départ, décaler à gauche de 6. Dans les deux cas, attention aux dépassements de capacité !
Il est aussi possible de remplacer la multiplication par une boucle d'additions. Par exemple, pour calculer 3 * 320, additionner 320 + 320 + 320. En règle générale, on peut éviter les multiplications dans une boucle d'affichage. Et on y gagne toujours en performance.
Daniel
|
| en haut - en bas |
|
|
|
Fool-DupleX
Visiteur
|
Date : 25/05/2005 à 13h03
Si c'est sur 16 bits, de toute maniere, n<=204. Je propose donc de mettre n dans A, decaler a droite de deux, puis readditionner n a A. (je suppose que D est a 0 avant bien sur).
Fool
|
| en haut - en bas |
|
|
|