Bug dans dcvg5k?

Couvre tous les domaines de l'émulation ou de la virtualisation ainsi que les discussions sur les divers outils associés.

Modérateurs : Papy.G, fneck, Carl

Répondre
joaopa
Messages : 369
Enregistré le : 14 sept. 2013 12:17

Bug dans dcvg5k?

Message par joaopa » 02 mai 2017 08:28

Bonjour,

je fais face à un problème étrange avec dcvg5k.
Le même programme suivant que je le place en ROM à 0000H ou en Ram (à 4A20H) ne donne pas le même résultat. Avec le programme placé en Ram, j'obtiens le résultat souhaité.
Est-ce un problème de dcvg5k. 6802Man, peux-tu le tester sur une vraie rom dans un VG5000? Merci d'avance

programme pour ROM

Code : Tout sélectionner

	ORG 0H

	LD SP,4100H
	DI
	LD HL,config_ef9345
	CALL seq_ef
	JP efface_ecran


seq_ef:
	LD B,(HL)
	INC HL
seq1:
	CALL EFRDY
	LD C,8FH
	OUTI
	LD C,0CFH
	OUTI
	JR NZ,seq1
	RET

ef9345:
	PUSH BC
	PUSH AF
	LD	C,8FH
	OUT	(C),D
	LD	C,0CFH
	OUT	(C),E
	CALL EFRDY
	POP AF
	POP BC
	RET
	
EFRDY:
	PUSH	AF
	LD	A,20H
	OUT	(8FH),A
EFRD1:
	IN	A,(0CFH)
	OR	A
	JP	M,EFRD1
	POP	AF
	RET

config_ef9345:
	DB 20, 33,0,40,129, 33,127,40,131, 33,0,40,130, 33,35,40,132, 35,0, 34,1

compteur: DB "0", 0FFH, "8", 0FFH, "9", 0FFH, "1", "0", 0FFH, "1", "1", 0FFH, "1", "2", 0FFH
	DB "1", "3", 0FFH, "1", "4", 0FFH, "1", "5", 0FFH, "1", "6", 0FFH, 
	DB "1", "7", 0FFH, "1", "8", 0FFH, "1", "9", 0FFH
	DB "2", "0", 0FFH, "2", "1", 0FFH, "2", "2", 0FFH, "2", "3", 0FFH, 
	DB "2", "4", 0FFH, "2", "5", 0FFH, "2", "6", 0FFH
	DB  "2", "7", 0FFH, "2", "8", 0FFH, "2", "9", 0FFH, "3", "0", 0FFH, "3", "1", 0FFH

efface_ligne:
	LD B,40
	LD D,38
	LD E,H
	CALL ef9345
	LD C,0
boucle_efface_ligne:
	CALL ef9345
	LD D,40
	LD E,1
	CALL ef9345
	INC C
	DJNZ boucle_efface_ligne
	RET

efface_ecran:
	LD H,0
	CALL efface_ligne
	LD H,1
boucle_ligne:
	CALL efface_ligne
	INC H
	LD B,H
	LD A,32
	CP B
	JP NZ,boucle_ligne
	LD D,22H
	LD E,1
	CALL ef9345
	LD D,23H
	LD E,30H
	CALL ef9345
	LD B,0
	LD HL,compteur-1
bcle:
	LD A,B
    OR A
	JR Z,affiche
	CP 8
	JP M,non_affiche
affiche:
	LD D,26H
	LD E,A
	CALL ef9345
	LD D,27H
	LD E,0
	CALL ef9345
blce1:
	INC HL
	LD A,(HL)
	CP 0FFH
	JR Z,non_affiche
	LD D,21H
	LD E,A
	CALL ef9345
	LD D,28H
	LD E,1
	CALL ef9345
	JR blce1
non_affiche:
	INC B
	LD A,B
	CP 32
	JR NZ,bcle

pipi: jp pipi
Programme pour RAM

Code : Tout sélectionner

	ORG 4A20H

	LD SP,4100H
	DI
	LD HL,config_ef9345
	CALL seq_ef
	JP efface_ecran


seq_ef:
	LD B,(HL)
	INC HL
seq1:
	CALL EFRDY
	LD C,8FH
	OUTI
	LD C,0CFH
	OUTI
	JR NZ,seq1
	RET

ef9345:
	PUSH BC
	PUSH AF
	LD	C,8FH
	OUT	(C),D
	LD	C,0CFH
	OUT	(C),E
	CALL EFRDY
	POP AF
	POP BC
	RET
	
EFRDY:
	PUSH	AF
	LD	A,20H
	OUT	(8FH),A
EFRD1:
	IN	A,(0CFH)
	OR	A
	JP	M,EFRD1
	POP	AF
	RET

config_ef9345:
	DB 20, 33,0,40,129, 33,127,40,131, 33,0,40,130, 33,35,40,132, 35,0, 34,1

compteur: DB "0", 0FFH, "8", 0FFH, "9", 0FFH, "1", "0", 0FFH, "1", "1", 0FFH, "1", "2", 0FFH
	DB "1", "3", 0FFH, "1", "4", 0FFH, "1", "5", 0FFH, "1", "6", 0FFH, 
	DB "1", "7", 0FFH, "1", "8", 0FFH, "1", "9", 0FFH
	DB "2", "0", 0FFH, "2", "1", 0FFH, "2", "2", 0FFH, "2", "3", 0FFH, 
	DB "2", "4", 0FFH, "2", "5", 0FFH, "2", "6", 0FFH
	DB  "2", "7", 0FFH, "2", "8", 0FFH, "2", "9", 0FFH, "3", "0", 0FFH, "3", "1", 0FFH

efface_ligne:
	LD B,40
	LD D,38
	LD E,H
	CALL ef9345
	LD C,0
boucle_efface_ligne:
	CALL ef9345
	LD D,40
	LD E,1
	CALL ef9345
	INC C
	DJNZ boucle_efface_ligne
	RET

efface_ecran:
	LD H,0
	CALL efface_ligne
	LD H,1
boucle_ligne:
	CALL efface_ligne
	INC H
	LD B,H
	LD A,32
	CP B
	JP NZ,boucle_ligne
	LD D,22H
	LD E,1
	CALL ef9345
	LD D,23H
	LD E,30H
	CALL ef9345
	LD B,0
	LD HL,compteur-1
bcle:
	LD A,B
    OR A
	JR Z,affiche
	CP 8
	JP M,non_affiche
affiche:
	LD D,26H
	LD E,A
	CALL ef9345
	LD D,27H
	LD E,0
	CALL ef9345
blce1:
	INC HL
	LD A,(HL)
	CP 0FFH
	JR Z,non_affiche
	LD D,21H
	LD E,A
	CALL ef9345
	LD D,28H
	LD E,1
	CALL ef9345
	JR blce1
non_affiche:
	INC B
	LD A,B
	CP 32
	JR NZ,bcle

pipi: jp pipi
Screenshot_20170501_202033.png
Programme dans le ROM
Screenshot_20170501_202033.png (17.26 Kio) Vu 642 fois
Fichiers joints
TEST2.COM.zip
Binaire pour ROM
(397 Octets) Téléchargé 18 fois
Screenshot_20170501_202102.png
Programme dans la RAM
Screenshot_20170501_202102.png (17.61 Kio) Vu 641 fois

Daniel
Messages : 9736
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Bug dans dcvg5k?

Message par Daniel » 02 mai 2017 10:19

Les premiers octets de la mémoire du VG5000 sont utilisés par les ports d'entrée/sortie du Z80, et aussi par les routines de traitement des interruptions. Si un programme utilisateur est chargé dans cette zone, c'est peut-être la cause du problème ?
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Mokona
Messages : 224
Enregistré le : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Bug dans dcvg5k?

Message par Mokona » 02 mai 2017 12:13

J'y pensais aussi, mais le programme commence par DI. Du coup, à part la NMI, qui arrivera effectivement au milieu de nulle part, ça aurait du être ok ? L'IRQ devrait être ignorée. Sinon, si l'IRQ se produit est qu'on en en IM 1, alors c'est un bon candidat pour expliquer le problème.

D'ailleurs, je me demande ce qu'il se passe pour le Z80 lorsqu'aucun mode d'interruption n'est précisé. Le VG5000 passe en IM 1 assez rapidement. Le code ici ne précise rien. Du coup, en quel mode est le Z80 ?

Avatar du membre
6502man
Messages : 8512
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Bug dans dcvg5k?

Message par 6502man » 02 mai 2017 15:46

J'ai testé la version ROM et ca donne ceci :
P1180655.JPG
P1180655.JPG (79.12 Kio) Vu 611 fois
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

Daniel
Messages : 9736
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Bug dans dcvg5k?

Message par Daniel » 02 mai 2017 17:38

Mokona a écrit :J'y pensais aussi, mais le programme commence par DI.
Le DI peut éviter les problèmes liés aux interruptions. Par contre si le programme, comme je le suppose, recouvre des ports d'entrées/sorties, il n'y a aucune chance qu'il fonctionne, car à ces adresses la ROM n'est pas accessible en lecture.
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Mokona
Messages : 224
Enregistré le : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Bug dans dcvg5k?

Message par Mokona » 02 mai 2017 17:53

Il me semblait que sur z80, les I/O n'étaient pas mappées en mémoire mais passaient exclusivement par les instructions adéquats.

Est-ce qu'en ajoutant IM 1 avant DI, ça ne fonctionne pas mieux ?

Daniel
Messages : 9736
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Bug dans dcvg5k?

Message par Daniel » 02 mai 2017 18:59

Je me trompe peut-être, ai-je mal lu, pages 70-71 de Clefs pour VG5000 ?

Code : Tout sélectionner

00-7F : Réservé au périphérique en extension.
80-88 : Scrutation du clavier.
89-8E : Inutilisés.
8F    : Validation adresse : EF9345.
90-AE : Inutilisés.
AF    : Magnétophone à cassette et générateur musical.
B0-CE : Inutilisés.
CF    : Validation données : EF9345.
D0-FF : Inutilisés.
Et ci-dessous les routines d'entrées/sorties dans dcvg5k :

Code : Tout sélectionner

// IO output //////////////////////////////////////////////////////////////////
void OutZ80(word w, byte c)
{
 w &= 0xff;
 ioport[w] = c;
 if(w == 0x11) {Imprime(c); return;} //ecriture imprimante
 if(w == 0xcf) {EF9345_write(ioport[0x8f], c); return;} //ecriture EF9345
 if(w == 0xaf) {buzzer = (c & 9) ? 1 : 0; return;} //sortie son et cassette
 if(w == 0xef) {return;} //?????
}

// IO input ///////////////////////////////////////////////////////////////////
byte InZ80(word w)
{
 w &= 0xff;
 if(w == 0xcf) return EF9345_read(ioport[0x8f]); //lecture EF9345
 if((w > 0x7f) && (w < 0x88)) return ioport[w]; //lecture clavier
 if((w == 0) || (w == 1)) return ioport[8 - w]; //joysticks ports 1 et 0
 if((w == 7) || (w == 8)) return ioport[w];     //joysticks ports 7 et 8
 return 0;
}
Alors, bien évidemment, s'il y a un programme à ces adresses, il ne peut pas fonctionner.
Daniel
L'obstacle augmente mon ardeur.

joaopa
Messages : 369
Enregistré le : 14 sept. 2013 12:17

Re: Bug dans dcvg5k?

Message par joaopa » 02 mai 2017 19:34

TEST2.COM.zip
Programme à tester en ROM
(404 Octets) Téléchargé 16 fois
Merci Daniel pour tes explications. Je suis convaincu. Même CP/M pour les machines sur Z80 impose de commencer les programmes à 100H, les 256 premiers octets étant réservés pour les entrées sorties.

6502Man, peux-tu essayer ce programme modifié en ROM?

Code : Tout sélectionner

	ORG 0000H

	JP commence

	ORG 100H

commence:
	IM 0
	LD SP,4100H
	DI
	LD HL,config_ef9345
	CALL seq_ef
	JP efface_ecran


seq_ef:
	LD B,(HL)
	INC HL
seq1:
	CALL EFRDY
	LD C,8FH
	OUTI
	LD C,0CFH
	OUTI
	JR NZ,seq1
	RET

ef9345:
	PUSH BC
	PUSH AF
	LD	C,8FH
	OUT	(C),D
	LD	C,0CFH
	OUT	(C),E
	CALL EFRDY
	POP AF
	POP BC
	RET
	
EFRDY:
	PUSH	AF
	LD	A,20H
	OUT	(8FH),A
EFRD1:
	IN	A,(0CFH)
	OR	A
	JP	M,EFRD1
	POP	AF
	RET

config_ef9345:
	DB 20, 33,0,40,129, 33,127,40,131, 33,0,40,130, 33,35,40,132, 35,0, 34,1

compteur: DB "0", 0FFH, "8", 0FFH, "9", 0FFH, "1", "0", 0FFH, "1", "1", 0FFH, "1", "2", 0FFH
	DB "1", "3", 0FFH, "1", "4", 0FFH, "1", "5", 0FFH, "1", "6", 0FFH, 
	DB "1", "7", 0FFH, "1", "8", 0FFH, "1", "9", 0FFH
	DB "2", "0", 0FFH, "2", "1", 0FFH, "2", "2", 0FFH, "2", "3", 0FFH, 
	DB "2", "4", 0FFH, "2", "5", 0FFH, "2", "6", 0FFH
	DB  "2", "7", 0FFH, "2", "8", 0FFH, "2", "9", 0FFH, "3", "0", 0FFH, "3", "1", 0FFH

efface_ligne:
	LD B,40
	LD D,38
	LD E,H
	CALL ef9345
	LD C,0
boucle_efface_ligne:
	CALL ef9345
	LD D,40
	LD E,1
	CALL ef9345
	INC C
	DJNZ boucle_efface_ligne
	RET

efface_ecran:
	LD H,0
	CALL efface_ligne
	LD H,1
boucle_ligne:
	CALL efface_ligne
	INC H
	LD B,H
	LD A,32
	CP B
	JP NZ,boucle_ligne
	LD D,22H
	LD E,1
	CALL ef9345
	LD D,23H
	LD E,30H
	CALL ef9345
	LD B,0
	LD HL,compteur-1
bcle:
	LD A,B
    OR A
	JR Z,affiche
	CP 8
	JP M,non_affiche
affiche:
	LD D,26H
	LD E,A
	CALL ef9345
	LD D,27H
	LD E,0
	CALL ef9345
blce1:
	INC HL
	LD A,(HL)
	CP 0FFH
	JR Z,non_affiche
	LD D,21H
	LD E,A
	CALL ef9345
	LD D,28H
	LD E,1
	CALL ef9345
	JR blce1
non_affiche:
	INC B
	LD A,B
	CP 32
	JR NZ,bcle

pipi: jp pipi

joaopa
Messages : 369
Enregistré le : 14 sept. 2013 12:17

Re: Bug dans dcvg5k?

Message par joaopa » 02 mai 2017 19:56

En y réfléchissant bien, je suis moins convaincu. Les adresses correspondent aux ports du Z80, et non pas aux adresses ROM ou RAM accessibles par le Z80. La preuve: entre 0000H et 00FFh, dans la ROM originale, il y a du code.
Modifié en dernier par joaopa le 02 mai 2017 20:20, modifié 1 fois.

Daniel
Messages : 9736
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Bug dans dcvg5k?

Message par Daniel » 02 mai 2017 20:11

Oui, tu as raison, c'est troublant. Il faudrait qu'un spécialiste du Z80 nous explique...
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Mokona
Messages : 224
Enregistré le : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Bug dans dcvg5k?

Message par Mokona » 02 mai 2017 20:47

Les adresses de 0 à 255 mentionnés par le livre sont des adresses de ports I/O.

Les ports I/O sur un Z80 sont gérées par les instructions du groupe correspondant, contenant les IN, INI, INIR,... OUT, OUTI, OUTD,...

Ces instructions utilisent la partie basse du bus d'adresse pour sélectionner le "port" I/O.

Mais contrairement à une lecture mémoire, qui active MREQ (conjointement à RD ou WR), les instruction d'I/O activent IORQ (conjointement à RD ou WR).

On peut voir cela en action dans la ROM par exemple en 00dc, qui utilise le port 8F pour communiquer sur le port de l'EF9345. Mais ce sont bien des adresses de port, la mémoire (ROM ou RAM) n'est pas touchée pendant ces cycles.

C'est bien ce qu'indique le code de dcvg5k, dont les fonctions j'imagine sont branchées aux demandes d'I/O de l'émulation Z80 (fonctions IN/OUT), pas sur les fonctions mémoire (LD, PUSH, POP,...)

Ce qu'il faut retenir en résumé, c'est que les adresses I/O sur un Z80 n'ont pas de relation avec les adresses mémoire.

Le jump du début de la ROM est pour une autre raison. Le Z80 a une fonction "call" simplifiée, appelée RST, qui est un peu comme un call, mais qui ne prend qu'un seul octet et branche à 8 positions uniquement (00h, 08h, 10h,... 38h). Forcément, cette instruction est utile pour brancher à des routines souvent appelées, qui sont donc situées à ces adresses (plus exactement, à ces adresses, la ROM contient un jump vers l'adresse réelle de la routine, ou de quoi commencer la routine, puis un jump ; parfois, il y a aussi de choses qui n'ont rien à voir entre ces adresses, comme le numéro de version de la ROM VG5000 juste après le jp 1000h en RST 0h).

L'adresse 38h, appelée donc par RST 38h, est aussi l'adresse qui est appelée par IRQ, mais uniquement en mode 1 d'interruption (le z80 gère les IRQ selon trois mode, mis en place par les instruction IM 0, IM 1 et IM 2). La ROM du VG5000 utilise le mode IM 1 et IRQ est appelée à chaque VBLANK.

Un peu plus loin, en 0066h se trouve l'adresse de branchement de la NMI, qui est branchée sur le VG5000 sur la combinaison de touches Ctrl+Delta.

Voilà pourquoi le début de la ROM est généralement réservée.

Sur le VG5000, il y a ensuite (0080h... 00b9h) une série d'indirections pour les routines systèmes. D'après moi, c'est uniquement une précaution pour avoir des points d'entrée fixes permettant de changer le contenu de la ROM en restant compatible. Il n'y a pas d'obligation de faire ça.

Avatar du membre
Papy.G
Modérateur
Messages : 1649
Enregistré le : 10 juin 2014 13:40
Localisation : Nantes/La Roche sur Yon

Re: Bug dans dcvg5k?

Message par Papy.G » 02 mai 2017 21:13

Si c'est comme sur le 8051, comme tu le laisses entendre, ce sont des adresses de vecteurs d'interruptions laissant la place à de très courtes routines, ou à des renvois vers des routines plus longues en Rom ou modifiables en Ram (sauf que le 8051, lui, n'est pas censé exécuter du code en Ram). :wink:
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

joaopa
Messages : 369
Enregistré le : 14 sept. 2013 12:17

Re: Bug dans dcvg5k?

Message par joaopa » 03 mai 2017 07:45

Bon, problème résolu. Ca m'a pris des plombes pour trouver le problème. Je suis trop con. J'avais oublié de configurer le registre ROR de l'EF9345. Il se trouvait donc par défaut (au moins sur dcv5K) à 0. Pour que tout colle, il fallait le mettre à 8.

Avatar du membre
Mokona
Messages : 224
Enregistré le : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Bug dans dcvg5k?

Message par Mokona » 03 mai 2017 10:47

Un bug en moins :)

Répondre