forum.system-cfg.com

Forum des collectionneurs et utilisateurs d'ordinateurs anciens
http://forum.system-cfg.com/

Bug dans dcvg5k?

http://forum.system-cfg.com/viewtopic.php?f=24&t=8020

Page 1 sur 1

Bug dans dcvg5k?

Publié : 02 mai 2017 08:28
par joaopa
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
Programme dans le ROM
Programme dans le ROM
Screenshot_20170501_202033.png (17.26 Kio) Consulté 5982 fois

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 10:19
par Daniel
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 ?

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 12:13
par Mokona
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 ?

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 15:46
par 6502man
J'ai testé la version ROM et ca donne ceci :
P1180655.JPG
P1180655.JPG (79.12 Kio) Consulté 5951 fois

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 17:38
par Daniel
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.

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 17:53
par Mokona
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 ?

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 18:59
par Daniel
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.

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 19:34
par joaopa
TEST2.COM.zip
Programme à tester en ROM
(404 octets) Téléchargé 154 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

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 19:56
par joaopa
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.

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 20:11
par Daniel
Oui, tu as raison, c'est troublant. Il faudrait qu'un spécialiste du Z80 nous explique...

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 20:47
par Mokona
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.

Re: Bug dans dcvg5k?

Publié : 02 mai 2017 21:13
par Papy.G
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:

Re: Bug dans dcvg5k?

Publié : 03 mai 2017 07:45
par joaopa
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.

Re: Bug dans dcvg5k?

Publié : 03 mai 2017 10:47
par Mokona
Un bug en moins :)
Fuseau horaire sur UTC+02:00
Page 1 sur 1

Développé par phpBB® Forum Software © phpBB Limited

Traduction française officielle © Qiaeru