TAVERNIER 6809
Modérateurs : Papy.G, fneck, Carl
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Concernant le système de décodage je me suis inspiré de ce que j'avais mis en oeuvre
pour faire fonctionner un coprocesseur AM9511 sur mon Tavernier.
Le système utilise bien les signaux E et Q pour tenir compte de la validation des adresses et de la validité des datas.
En outre le coprocesseur nécessitait de latcher les données pour donner au coprocesseur le temps de les lire.
Tout cela fonctionnait correctement.
Concernant le projet de carte vidéo je suis appuyé sur un schéma d'extension MSX2 128K origine CT80 je crois
Je vous livre ci-dessous le schéma sur lequel je travaille actuellement.
Les écritures dans les registres ne semblent pas aboutir. Toutefois des modifications apparaissent sur les signaux vidéo
La lecture des 10 registres de status donne des choses du genre
9F 1F 1F 1F 1F 1F 1F 1F 1F 1F ou encore 85 05 05 05 05 05 05 05 05 05
J'ai effectué pas mal de vérifications sur ma carte, examiné les signaux de toutes les pins du V9938 et même dans le doute changé le V9938 sans succès… Bien sûr, je ne suis pas à l'abri d'une soudure sèche....
Si quelqu'un a une idée, qu'il n'hésite pas !
Cordialement
Michel
- Pièces jointes
-
- 2020-01-18 - VDP et Interface Video.jpg (684.41 Kio) Consulté 3422 fois
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour,
En complement de mon précédent post, voici une copie des chronogrammes relevé pour un cycle écriture
Les trois lignes du bas concerne l'effet du latch qui n'apparait pas sur le schéma
Cordialement
Michel
En complement de mon précédent post, voici une copie des chronogrammes relevé pour un cycle écriture
Les trois lignes du bas concerne l'effet du latch qui n'apparait pas sur le schéma
Cordialement
Michel
Re: TAVERNIER 6809
Je présume que l'on parle d'écrire dans un registre du VDP9938 : /CSW, MODE, DATA ?
/CSW devient 0 quand E devient 1 pendant que Q est à 1, il faut que le bus d'adresse soit valide 30 ns avant et le reste au minimum 50 ns après pour que l'adresse puisse être enregistrée. /CSW devient 1 quand E devient 0 pendant que Q est à 0, il faut que le bus de donnée soit présenté avant 30 ns et toujours présenté après 30 ns.
Le Q qui va dans le CLK du 74LS175... m'interpelle. D'après la doc : "Clock (Active HIGH Going Edge) Input". Donc /CSW n'est mis à jour qu'une fois au lieu de deux fois comme il faudrait (on aura toujours E' = 0 en sortie de ce LS) ? je lis peut-être mal le schéma.
EDIT: ok je vois que E est en-dehors de ce LS175. "nevermind"...
/CSW devient 0 quand E devient 1 pendant que Q est à 1, il faut que le bus d'adresse soit valide 30 ns avant et le reste au minimum 50 ns après pour que l'adresse puisse être enregistrée. /CSW devient 1 quand E devient 0 pendant que Q est à 0, il faut que le bus de donnée soit présenté avant 30 ns et toujours présenté après 30 ns.
Le Q qui va dans le CLK du 74LS175... m'interpelle. D'après la doc : "Clock (Active HIGH Going Edge) Input". Donc /CSW n'est mis à jour qu'une fois au lieu de deux fois comme il faudrait (on aura toujours E' = 0 en sortie de ce LS) ? je lis peut-être mal le schéma.
EDIT: ok je vois que E est en-dehors de ce LS175. "nevermind"...
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour hlide,
Je ne comprends pas bien ce qui te chagrine au niveau du 74LS175...
Les chronogrammes correspondent à ce que j'observe à l'oscillo et le signal /CSW me semble correct vis à vis de E et Q
Je vais cependant relire ce que tu me dis à tête reposée sur les timings….
Une remarque me viens à l'esprit:
La documentation du V9938 que je possède ne dit pas grand chose sur les contraintes de fréquence concernant les échanges avec le CPU.
L'horloge E du 6809 tourne à 1MHz.
Les micro MSX mettent en oeuvre un Z80 beaucoup plus véloces me semble-t-il… Trop rapide pour dialoguer avec le 6809 sans mécanisme d'interuption
C'est peut-être là que se tient mon problème…
A plus
Michel
…
Je ne comprends pas bien ce qui te chagrine au niveau du 74LS175...
Les chronogrammes correspondent à ce que j'observe à l'oscillo et le signal /CSW me semble correct vis à vis de E et Q
Je vais cependant relire ce que tu me dis à tête reposée sur les timings….
Une remarque me viens à l'esprit:
La documentation du V9938 que je possède ne dit pas grand chose sur les contraintes de fréquence concernant les échanges avec le CPU.
L'horloge E du 6809 tourne à 1MHz.
Les micro MSX mettent en oeuvre un Z80 beaucoup plus véloces me semble-t-il… Trop rapide pour dialoguer avec le 6809 sans mécanisme d'interuption
C'est peut-être là que se tient mon problème…
A plus
Michel
…
Re: TAVERNIER 6809
Je n'avais pas bien vu comment E participait à la création de /CSW et compris à quoi servait Q en clock sur le composant en question (récupération de R/W et du CS1). Concernant la valeur de CS1 qui ne semble pas "bufferisée" à sa création, le bus d'adresse est déjà valide à la phase montante de Q ?
La durée de l'état bas de /CSW doit être supérieure à 186 ns et inférieure à 2000 ns. On devrait être dans les clous, non ?
La durée de l'état bas de /CSW doit être supérieure à 186 ns et inférieure à 2000 ns. On devrait être dans les clous, non ?
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour hlide,
J'ai rapproché ci-après les chronogrammes du 6809 et du Vm9938
En recalant le pulse /CSW tel qu'il est généré, comme tu le dis je devrais être dans les clous , et pourtant je rencontre un problème…
Merci pour tes remarques
Je repart à la mine….
Michel
J'ai rapproché ci-après les chronogrammes du 6809 et du Vm9938
En recalant le pulse /CSW tel qu'il est généré, comme tu le dis je devrais être dans les clous , et pourtant je rencontre un problème…
Merci pour tes remarques
Je repart à la mine….
Michel
Re: TAVERNIER 6809
Concrètement, VDP9938 se sert de XA0 et XA1 issus de A0 et A1 qui ne sont pas "bufferisés" à un instant pour constituer MODE. Le bus d'adresse du 6809 est valide à la la phase montante de Q et invalide après la phase descendante de E, donc ça laisse suffisamment de temps au VDP d'enregistrer le MODE correctement juste après la phase montante de E. De même pour /CS1 sur la phase montante de Q.
Le signal /CSW dépend de R/W, de /CS1 et de E en phase montante. Le R/W est positionné avant la phase montante de Q par le 6809 donc on l'enregistre à ce moment-là via un tampon. Le /CS1 dépend également du bus d'adresse et il est également capturé à la phase montant de Q.
Donc oui, /CSW et MODE semblent bien constitués.
A l'écriture d'une donnée côté 6809 le bus de donnée et d'adresse sortent quasiment en même temps avec la même période or elles sont invalides après la phase descendante de E qui coïncide avec la phase montante de /CSW : si la période avant l'invalidation des données côté 6809 est plus courte que la période validation du VDP, ce n'est pas bon. Je ferrais en sorte que la phase montante de /CSW se passe à la phase descendante de Q : ça raccourcira le signal /CSW à 250 ns qui devrait être bon au niveau timing côté VDP et laisserait largement le temps de capturer une donnée valide.
Le signal /CSW dépend de R/W, de /CS1 et de E en phase montante. Le R/W est positionné avant la phase montante de Q par le 6809 donc on l'enregistre à ce moment-là via un tampon. Le /CS1 dépend également du bus d'adresse et il est également capturé à la phase montant de Q.
Donc oui, /CSW et MODE semblent bien constitués.
A l'écriture d'une donnée côté 6809 le bus de donnée et d'adresse sortent quasiment en même temps avec la même période or elles sont invalides après la phase descendante de E qui coïncide avec la phase montante de /CSW : si la période avant l'invalidation des données côté 6809 est plus courte que la période validation du VDP, ce n'est pas bon. Je ferrais en sorte que la phase montante de /CSW se passe à la phase descendante de Q : ça raccourcira le signal /CSW à 250 ns qui devrait être bon au niveau timing côté VDP et laisserait largement le temps de capturer une donnée valide.
Dernière modification par hlide le 31 janv. 2020 15:12, modifié 1 fois.
Re: TAVERNIER 6809
Les schémas de timing semble différer. Dans le cas du Vectrex, le read data est disponible avant la phase montante. Si ce n'est pas le cas, on va peut-être avoir un soucis. Il va falloir faire la pèche au timings par modèle de processeur... mais là je vais manger.
Re: TAVERNIER 6809
6809 écrit, V9938 lit : /CSW = 0. Le V9938 exige que la donnée valide soit maintenue pendant 30 ns après la phase montante de /CSW or le 6809 maintient la donnée valide que 30 ns après la phase descendante de E. Sachant qu'il pourrait y avoir une petit décalage entre /CSW = 0->1 et E = 1 -> 0, ça me semble très limite. Si on peut récupérer la donnée plus tôt en écourtant la période /CSW = 0 ce serait mieux.
Je laisse tomber pour le /CSR, ni le 6809 ni le V9938 sont clairs dans leur documentation.
Je laisse tomber pour le /CSR, ni le 6809 ni le V9938 sont clairs dans leur documentation.
Dernière modification par hlide le 01 févr. 2020 01:26, modifié 2 fois.
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour hlide
Le début de ton post "6809 écrit, V9938 lit" m'a un peu troublé.
J'ai craint un instant d'avoir inversé l'usage des signaux /CSW et /CSR
Sauf erreur Le mode Ecriture actionné par /CSW correspond bien à la situation "6809 écrit , V9938 lit"
Le V9938 exige que la donnée valide soit maintenu pendant 30 ns après la phase montante de /CSW
Le 6809 maintient la donnée valide que 30 ns après la phase descendante de E
Je suis d'accord sur ce constat et effectivement la situation est limite à ce niveau
Le système de latch que j'ai utilisé sur ma carte co-processeur consistait lui à maintenir la données valide plus longtemps
Tu suggères de récupérer la donnée plus tôt en écourtant le pulse /CSW, pourquoi pas
Je vais faire quelques essais
Merci encore pour tes remarques
Cordialement
Michel
Le début de ton post "6809 écrit, V9938 lit" m'a un peu troublé.
J'ai craint un instant d'avoir inversé l'usage des signaux /CSW et /CSR
Sauf erreur Le mode Ecriture actionné par /CSW correspond bien à la situation "6809 écrit , V9938 lit"
Le V9938 exige que la donnée valide soit maintenu pendant 30 ns après la phase montante de /CSW
Le 6809 maintient la donnée valide que 30 ns après la phase descendante de E
Je suis d'accord sur ce constat et effectivement la situation est limite à ce niveau
Le système de latch que j'ai utilisé sur ma carte co-processeur consistait lui à maintenir la données valide plus longtemps
Tu suggères de récupérer la donnée plus tôt en écourtant le pulse /CSW, pourquoi pas
Je vais faire quelques essais
Merci encore pour tes remarques
Cordialement
Michel
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour 6502man, Bonjour hlide
Les choses progressent pour moi. Comme évoqué précédemment j'ai modifié la génération des pulses /CSW et /CSR (Cf schéma ci-après)
Je parviens à écrire dans les registres.
Coté vidéo j'ai un souci. Je passe par la péritel d'un poste TV avec les signaux CSYNC et RGB
J'obtiens une image ou plutôt la trame d'une image
En écrivant dans certains registres, des modifications apparaissent sur cette trame…
Par contre les signaux RGB semblent comme désactivés (pas de niveau) sans doute un bit de registre mal positionné…
A plus
Michel
Les choses progressent pour moi. Comme évoqué précédemment j'ai modifié la génération des pulses /CSW et /CSR (Cf schéma ci-après)
Je parviens à écrire dans les registres.
Coté vidéo j'ai un souci. Je passe par la péritel d'un poste TV avec les signaux CSYNC et RGB
J'obtiens une image ou plutôt la trame d'une image
En écrivant dans certains registres, des modifications apparaissent sur cette trame…
Par contre les signaux RGB semblent comme désactivés (pas de niveau) sans doute un bit de registre mal positionné…
A plus
Michel
- Pièces jointes
-
- 2020-02-02 - Generation CSW et CSR.jpg (456.43 Kio) Consulté 3237 fois
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
un nouveau pas vers la lumière….!
Re: TAVERNIER 6809
Ca avance bien
On devine le damier noir et blanc il y à une desynchronisation de l'image non ?
On devine le damier noir et blanc il y à une desynchronisation de l'image non ?
- Papy.G
- Modérateur
- Messages : 3051
- Inscription : 10 juin 2014 13:40
- Localisation : Haute-Garonne/Gers
Re: TAVERNIER 6809
Es-ce que le bon mode vidéo a déjà été sélectionné à cette étape?
Pour le 9345, la notice indique que l'affichage n'est pas convenable à l'allumage tant que les registres nécessaires n'ont pas été réinitialisés (par des commandes externes).
Pour le 9345, la notice indique que l'affichage n'est pas convenable à l'allumage tant que les registres nécessaires n'ont pas été réinitialisés (par des commandes externes).
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Demandez-en plus, ou faites-le vous-même.
- michel guyot
- Messages : 616
- Inscription : 20 mars 2016 16:01
- Localisation : Pyrénées orientales
Re: TAVERNIER 6809
Bonjour à tous,
Je pense avoir régler mes problèmes de synchro et obtenu une configuration matériel à peu près correcte.
Je parviens à écrire en VRAM comme le montre l'image ci-dessous
A priori en mode GRAPHIC 7 mais peut-être pas encore aux bonnes adresses
C'est un début….je ne maîtrise pas ces nombreux registres du V9938
Il faut que je fasse le ménage après toutes mes modifications de schéma avant d'aller plus loin
A plus
Michel
Je pense avoir régler mes problèmes de synchro et obtenu une configuration matériel à peu près correcte.
Je parviens à écrire en VRAM comme le montre l'image ci-dessous
A priori en mode GRAPHIC 7 mais peut-être pas encore aux bonnes adresses
C'est un début….je ne maîtrise pas ces nombreux registres du V9938
Il faut que je fasse le ménage après toutes mes modifications de schéma avant d'aller plus loin
A plus
Michel