Bug dans emulation CLR 6809e

[gilles]

Pour automatiser tu dois pouvoir jouer avec un teo.ini qui est complet (y compris tes breakpoint).
Pour la gestion des repertoires hote nativement, une version l'a intégré. Mais cela devient complexe avec une emulation réelle du controleur de disquette. Puisque tu es dans un makefile le plus simple pour packager est d'utiliser sapfs dans ton makefile et demarrer sur l'image disquette.
Teo patche de moins en moins la rom, c'est l'un des buts des evolutions.

[__sam__]

Pour automatiser tu dois pouvoir jouer avec un teo.ini qui est complet (y compris tes breakpoint).

Le contenu d'un fichier n'est pas forcément facile à modifier avec un makefile. Et ensuite il faut "dire" à TEO d'utiliser non pas son teo.ini standard, mais un autre pour des problèmes d'exécution concurrentielle par exemple.

[Daniel]

Pour un développeur il est important que l'émulateur puisse se lancer avec toutes les options (MEMO7, K7, D7, vitesse, taille écran, etc) depuis la ligne de commande.

Le fichier .ini de dcmoto contient les informations suivantes :

Code : Tout sélectionner

- Langue
- Ordinateur émulé
- Contrôleur externe
- Présence manettes
- Présence crayon optique
- Présence souris
- Présence LEP
- Présence lecteur disquette
- Fréquence du processeur
- Arrêt sur instruction invalide
- Présence interface sdmo
- Présence interface sdmoto
- Présence interface cfmo
- Présence interface cfmoto
- Zoom horizontal
- Zoom vertical
- Protection cassette
- Protection disquette
- Taille des copies d'ecran
- Emulation des manettes par le clavier
- Emulation du pavé numérique
- Type d'extension mémoire
- Volume du son
- Correction gamma
- Adresse du break point
- Adresse du désassemblage
- Adresse de chargement fichier binaire
- Adresse maxi du fichier binaire
- Répertoire et nom fichier .k7
- Répertoire et nom fichier .fd
- Répertoire et nom fichier .rom (cartouche)
- Répertoire et nom fichier .sd
- Répertoire et nom fichier .cf

Supposons qu'il existe un programme en ligne de commande avec ces options en paramètres, capable de créer le fichier dcmoto.ini et de lancer l'émulateur. Est-ce que ça répond à la demande ?

[gilles]

On est sur un modele d'un fichier par utilisateur sous linux. Selon le mode de compilation (package debian ou non) ce sera soit dans le repertoire des binaires soit dans $home/.config/teo/teo.ini
Tu peux garder un teo.ini.ref dans ton projet et le pousser lors du makefile sans condition. Le cas de double lancement est rarement problematique, il faudrait que l'arret d'une instance coincide avec le lancement d'une autre. Dans ce cas rare, perdre un .ini n'est pas tres grave.
Sous windows le .ini doit être dans le repertoire du programme je crois

[__sam__]

@Daniel, @Gilles, si les emuls cherchent leur fichier "ini" respectif dans le dossier de lancement, alors oui il doit être possible de faire un truc automatisable en ligne de commande.

Je vais regarder cette option de plus près...

[Daniel]

dcmoto.exe cherche un fichier dcmoto.ini dans le même répertoire que l'exe. S'il ne le trouve pas il le crée avec les options par défaut.

Rien n'empêche d'avoir plusieurs répertoires, contenant chacun dcmoto.exe et dcmoto.ini. Chaque fichier ini est indépendant. Il suffit de choisir un répertoire et d'exécuter dcmoto.exe dans ce répertoire. On peut ainsi lancer plusieurs occurrences de l'émulateur avec des fichiers .ini différents.

[__sam__]

Je viens de regarder le contenu du dernier dcmoto.ini. Ca ne ressemble pas à de l'ascii, mais à du binaire impossible à générer par makefile

Sinon je viens de tester l'instruction non documentée $3E qui est équivalent à un JMP [$FFFE] (reset) (http://permalink.gmane.org/gmane.comp.h ... coco/63145 ou http://mdfs.net/Docs/Comp/6809/OpList). Apparement le dernier DCMOTO ne l'émule pas. Est-ce normal ? Il me semblait par le passé que c'était supporté.

[Daniel]

Ca ne ressemble pas à de l'ascii, mais à du binaire impossible à générer par makefile

C'est pour cela que je proposais d'écrire un programme capable de générer le fichier .ini à partir des paramètres de la ligne de commande, et de lancer ensuite dcmoto.exe.

Une autre solution est de préparer des fichiers .ini avec dcmoto lui-même, et de les appeler par exemple dcmoto.001, dcmoto.002, etc.
Pour lancer la version nnn on copie dcmoto.nnn en dcmoto.ini et on lance dcmoto.exe.

Sinon je viens de tester l'instruction non documentée $3E qui est équivalent à un JMP [$FFFE] (reset) (http://permalink.gmane.org/gmane.comp.h ... coco/63145 ou http://mdfs.net/Docs/Comp/6809/OpList). Apparement le dernier DCMOTO ne l'émule pas. Est-ce normal ? Il me semblait par le passé que c'était supporté.

Dcmoto émule quelques instructions non documentées, en particulier celles utilisées par Infogrames pour la protection des programmes. Mais les autres ne sont pas programmées. Je l'ai prévu, mais je n'ai jamais pris le temps de le faire. Au début je voulais les tester une par une sur le MO5, mais j'ai reculé devant la difficulté de la tâche. Je vais faire confiance aux informations données sur internet. Ci-dessous la liste que j'avais trouvée à l'époque. Est-elle exacte ? Y-a-t'il d'autres sources d'information ?

6809_undefined_opcodes_behavior.png (88.58 Kio) Consulté 4395 fois

[__sam__]

Ca ne ressemble pas à de l'ascii, mais à du binaire impossible à générer par makefile

C'est pour cela que je proposais d'écrire un programme capable de générer le fichier .ini à partir des paramètres de la ligne de commande, et de lancer ensuite dcmoto.exe.

Ah ok. Oui ca doit pouvoir marcher. C'est pas très courant des fichiers INI en binaire et il n'aime pas spécialement le passage par un éditeur texte.

Une autre solution est de préparer des fichiers .ini avec dcmoto lui-même, et de les appeler par exemple dcmoto.001, dcmoto.002, etc.
Pour lancer la version nnn on copie dcmoto.nnn en dcmoto.ini et on lance dcmoto.exe.

Ca fera beaucoup de dcmoto.nnn car il y a plein de params différents à tester. Au niveau maintenance ce ne sera pas facile non plus car si on déplace l'emplacement des fichiers disk, il faut refaire tous les dcmoto.nnn, et là lien entre un dcmoto.nnn et les params qu'il y a dedans ne sera pas simple. Ca me semble pas pratique. Générer un fichier INI unique construit à partir des params courants me semble préférable.

(opcodes non documentés) Je l'ai prévu, mais je n'ai jamais pris le temps de le faire. Au début je voulais les tester une par une sur le MO5, mais j'ai reculé devant la difficulté de la tâche. Je vais faire confiance aux informations données sur internet. Ci-dessous la liste que j'avais trouvée à l'époque. Est-elle exacte ? Y-a-t'il d'autres sources d'information ?

Oui ca ressemble à ce que j'avais mis comme lien dans le message supra. En pratique à part pour les protections, je n'ai trouvé utile que le $3E seul qui fait un RESET en 1 octets au lieu de 4 pour JMP [$FFFE] (quand on joue dans les micro-progs de moins de 256 octets, la différence entre 1 et 4 se fait vite sentir)

[gilles]

sur teo le fichier .ini est en mode texte, si tu copies un exécutable dans un autre répertoire il faudra les roms au moins (car elles sont dans un fichier séparé sur teo) et probablement des dll sur windows.

Sous linux, pour tester ton exemple (compiler le source assembleur, créer une image et la lancer) j'utilise un makefile comme celui ci:

all:
../../c6809/c6809 test.asm TEST.BIN
../../sap/sapfs -create TEST.SAP
../../sap/sapfs -add TEST.SAP TEST.BIN
teo --disk0=./TEST.SAP

Pour le moment le seul outil qui me manque un peu est un "tokenizer" pour pouvoir faire du basic (pour pouvoir faire un AUTO.BAT par exemple, dans la pratique j'utilise un AUTO.BAT qui a été créé avec teo, puis extrait de l'image SAP.)

sur un projet avec C et assembleur c'est plutôt comme cela:
all:
../../mc09/mc main.c > main.asm
../../c6809/c6809 main.asm AUTO.BIN
../../sap/sapfs -create UNDEADSCENERS.SAP
../../sap/sapfs -add UNDEADSCENERS.SAP AUTO.BIN AUTO.BAT
../../sap/sapfs -add UNDEADSCENERS.SAP DRUIDC.BIN DRUIDP.BIN
../../sap/sapfs -add UNDEADSCENERS.SAP DRIVEC.BIN DRIVEP.BIN

(on retrouve d'ailleurs le AUTO.BAT qui fait un LOADM"AUTO.BIN",,R pour faire de l'autorun simplement)

[__sam__]

all:
../../c6809/c6809 test.asm TEST.BIN
../../sap/sapfs -create TEST.SAP
../../sap/sapfs -add TEST.SAP TEST.BIN
teo --disk0=./TEST.SAP

C'est +/- ce que j'ai mais en plus complexe (car générique pour tous les projets).

Code : Tout sélectionner

ALL=$(wildcard *.ass)
DISK=diskette.sap
K7=$(DISK:.sap=.k7)
IMAGES=

all: compile fill_sapdir w

compile: $(IMAGES) $(ALL:.ass=.BIN) $(ALL:.ass=.EXO) 

list:	compile
	less codes.lst

clean: 
	rm *.BIN

%.EXO: %.BIN
	tools/exobin -x5A00 $<
	
%.BIN: %.ass
	tools/c6809.exe -c -bh -am -oOP $< `echo $@|tr a-z A-Z`
	
$(DISK): fill_sapdir
	tools/sapfs -c $@
	tools/sapfs -a $@ sapdir
	
$(K7): 
	echo >$@ -n
	
x%.gif: %.gif
	-perl img_to7_9exp.pl $*.gif
	
fill_sapdir: compile
	-mkdir sapdir
	-rm *.fd *.FD
	-cp *.EXO sapdir
	-cp *.BAS sapdir
	-cp *.BAT sapdir
	-cp *.ASM sapdir
	-cp *.BIN sapdir
	-cp *.mp* sapdir
	-cp *.dat sapdir

w:	$(DISK) $(K7)
	../teo/teow.exe -window -m MASS6809.M7 -disk0 `cygpath -w -s "$(PWD)/$(DISK)"`
	cd sapdir && ../tools/sapfs.exe --extract-all ../$(DISK)

Je le place dans tous mes projets. Pour compiler je fais "make w" (pour make world, en référence à openbsd). Il me compile tous les fichiers ASS, génère les ASM, les BIN, les binaires compressés (EXO), converti les eventuelles images en map thomson, copie les fichiers produits dans le dossier local sapdir/, lance sapfs pour packer le tout ensemble, puis lance TEO avec un disk monté, et à la sortie dépacke la diskette dans le dossier sapdir/ pour pouvoir récupérer les modifs faites dans l'emulateur.

Evidemment comme j'ai plusieurs fichier ASS et images dans un même project (plusieurs version du truc), le makefile ne recompile que les fichiers réellement modifiés. C'est bien plus rapide et moins b*rdellique que de tout recompiler à chaque fois et où on ne sait plus ce qui a vraiment changé.

Pour le moment le seul outil qui me manque un peu est un "tokenizer" pour pouvoir faire du basic (pour pouvoir faire un AUTO.BAT par exemple, dans la pratique j'utilise un AUTO.BAT qui a été créé avec teo, puis extrait de l'image SAP.)

Tu n'as pas essayé de mettre les fichiers basic en ASCII pur comme lorsqu'il sont sauvés avec un save "nom",A ? Ca devrait marcher, mais je ne sais pas si sapfs met les bons attribut au fichier pour que le BASIC le reconnaisse correctement (je crois que les fichiers sont systématiquement marqués comme binaires, même s'il contiennent de l'ascii).

[gilles]

j'aime bien ton makefile, le mien est effectivement totalement fait à l'arrache et se comporte plus comme un shell qu'un makefile. Mais pour produire 320Ko sur une machine récente, qu'il contrôle les dépendances ou pas... ça prend toujours plus de temps pour taper make que pour compiler
si je me lance dans de plus gros projets je garde la structure de ton makefile sous le coude, je m'en inspirerai.
il me semble que sapfs se base sur l'extension pour le type, du coup il ne doit pas pouvoir mettre le bon flag Basic/ascii, mais je n'ai pas tellement exploré, j'ai créé mon fichier AUTO.BAT qui va toujours chercher un AUTO.BIN et là j'ai la main sur le code source donc je fais ce que je veux avec.

[Daniel]

Sinon je viens de tester l'instruction non documentée $3E qui est équivalent à un JMP [$FFFE] (reset) (http://permalink.gmane.org/gmane.comp.h ... coco/63145 ou http://mdfs.net/Docs/Comp/6809/OpList). Apparement le dernier DCMOTO ne l'émule pas.

Du coup, ça m'a motivé pour programmer toutes les instructions non documentées. Pour le code $3E (RESET), le document 6809 Undefined Opcode Behavior cité un peu plus haut dit ceci :

This opcode uses the same number of MPU cycles as SWI (15)

Par contre le MC6809-MC6809E Microprocessor Programming Manual donne 19 cycles pour le SWI (annexe D-4).
Alors pour le RESET, je mets 15 ou 19 ?
Evidemment, ça n'a pas une très grosse importance, mais s'il faut pinailler allons jusqu'au bout

[__sam__]

Oui ca n'a pas grosse influence car on part en reset et qu'on ne peut pas l'utilisé pour ses propriétés de temporisations. Pour être sur il faudrait prendre un analyseur logique ou un oscillo et faire une mesure en vrai je suppose.

[Daniel]

La nouvelle version ci-dessous émule les instructions non documentées "simples" (sans préfixe $10 ou $11).
http://dcmoto.free.fr/emulateur/dcmoto_nouveau.zip
En attendant mieux le RESET $3E est programmé avec 19 cycles.
L'instruction HCF (Halt and Catch Fire) de codes $14, $15 ou $CD n'est pas émulée.

En plus de cette nouveauté, un gros bug de la version précédente a été corrigé : dans certains cas les fichiers images (cassettes, disquettes ou cartes SD) étaient enregistrés sous un mauvais nom, et pouvaient écraser malencontreusement un autre fichier image.
Il est donc conseillé de détruire les versions dcmoto 2015.05.28 et dcmoto 2015.05.29, et de les remplacer par dcmoto 2015.05.30

Il reste une petite amélioration à faire : les instructions à préfixe $10 et $11 sont exécutées avec le même nombre de cycles si elles sont précédées de plusieurs $10 ou plusieurs $11. En toute rigueur il faut ajouter 1 cycle de plus par octet superflu.