forum.system-cfg.com

Bonjour 6502man

J'ai pas très bien compris ces histoires d'adresses logiques et physiques… je te ré-interrogerai là dessus plus tard.
Je me suis construit quelques routines pour faciliter les test
J'ai fais un peu de ménage sur ma carte d'une part pour ne conserver que ce qui marche mais aussi pour pouvoir intervenir sur le positionnement et la durée des pusles /CSW et /CSR.

Par exemple j'ai constaté qu'en rajoutant un retard de 100ns sur le pusle /CSW je parviens à charger ton programme systématiquement ce qui n'était pas le cas auparavant.
Le même genre de manip sur le pusle /CSR semble améliorer la lecture des registres de status, je dis semble car je n'est pas de référence…
La data sheet du V9938 précise aussi des choses concernant la succession des pusles, il y a peut-être des pièges à ce niveau...

Une question : avec ton programme peux-tu me dire ce que devrais lire sur ces registres de status ?

A plus
Michel

Salut, Michel,

Avec le programme en Graphic 2 je sait pas ce que les registres de status doivent contenir hormis celui qui indique la VBL !!!

Il me semble que les registres de status sont plutôt utilisé dans les mode Graphic 3,4,5.... il faut que je regarde la doc je m'en rappelle plus

Bonjour 6502man

J'ai refais des essais en décalant les pulses /CSW et /CSR et/ou en modifiant leur durée…
Par rapport au dernier schéma que j'ai diffusé, je reste pour l'instant sur le retard de 85ns introduit sur les deux pulses.

Avec cette configuration :
les écritures semblent fonctionner correctement
ton programme se charge bien
je peux écrire des points en VRAM (même si je n'est pas un mode 7 correct)
Je réussi à écrire des points en mémoire et à les relire

Finalement la lecture des registres de status reste problématique, mais sans repère….

Je me bricole des routines logiciel pour me faciliter les manipulations pour essayer les commandes, donc je progresse lentement

A plus
Michel

Pour le mode 7 je peux t'aider en te faisant un programme, mais je n'aurais peut être pas le temps aujourd'hui ...

Bon remettons-nous en tête la signification de /CSR :

* /CSR : le CPU souhaite lire un registre, donc le VDP va exposer une donnée dans les 100 ns typiquement avec un max de 200 ns. Au vu du chronogramme, ça veut dire que que l'on est sûr d'avoir une donnée à partir de 200 ns après le front descendant de /CSR ? j'ai toujours autant de difficulté à lire son chronogramme car après on a changement de MODE puis de DATA qui semblent indiquer une invalidation de la donnée (hein !?) AVANT le front montant de /CSR. Si quelqu'un comprend, je suis preneur de ses explications.

Sinon, il y a des temps relativement long à observer/respecter entre lectures, entre écritures, entre lecture-écriture et entre écriture-lecture de l'ordre de quelques µS (2 ou . Est-ce déjà le cas ?

Bonjour hlide,

Ci-dessous le rapprochement des chronogrammes du 6809 et du V9938. Pour les cycles écriture et lecture.
Moi aussi j'ai un peu de mal à décrypter la datasheet du V9938
Je crois comprendre que le V9938 nécessite de respecter au moins 2 µs entre des opérations de lecture/écriture. A priori je respecte cela sur mon montage….
Si un spécialiste peut nous aider ce serait sympa.
Michel

Attention c'est 2 µs ou 8 µs selon le rang de l'octet dans la séquence de lecture/écriture.

Je présume que la période active de /CSR est de 250 µs ou 500 µs. Je suppose que la donnée affichée par le VDP est disponible après 150 ns max. Ce qui me perd c'est le changement de MODE et DATA au "milieu" de cette période dont on n'a aucune idée à quel moment ça peut se passer. Bref, ce chronogramme (celui de la doc Yamaha) est incapable de nous expliquer quelle est la partie de donnée valide à lire (avant ou après le changement ?). Et je peine à trouver une autre documentation plus explicite.

Bonjour 6502man, Bonjour hlide

Pour ce soir juste une image pour illustrer le fait que je parviens parfaitement à initialiser la VRAM, à y écrire ou lire des points.
La commande LINE fonctionne sans problème

Cordialement
Michel

Bravo, même si je ne participe pas activement à ce topic, je suis très admiratif de ta persévérance et des résultats

Bravo Michel

Je vois que tu maîtrise les commandes du VDP
Tu as réussi à lire correctement les registres de status ?

Car c'est nécessaire si tu dois exécuter plusieurs commandes à la suite pour être sûr que le VDP ait fini la précédente commande

Bonjour fneck

Merci beaucoup pour tes encouragements…
C'est vrai qu'il faut un peu de patience pour mettre en oeuvre ce processeur utilisé dans le monde du MSX que je découvre…
Ces vieilles machines qui permettent de se faire plaisir au niveau création et l'aide apportée par plusieurs acteurs du forum rendent l'affaire passionnante
Merci à tous
Michel

Bonjour 6502man

Non je ne maîtrise pas encore tous les registres du VDP !
Je me suis confectionné quelques routines logiciel pour sonder les fonctions liées à ces registres
Je ne sais pas encore si j'arrive à lire ces registres de status
Leur lecture pour enchainer les commandes est sans doute nécessaire si on vise la performance
En testant les différentes commandes, il est peut-être possible de prédire ce que les registres de status doivent contenir et de le vérifier par leur lecture. Ce n'est sans doute pas très rationnel comme démarche...mais cela me donnera peut-être une piste !
Michel

Bonjour,
Un petit pas de plus avec la commande PSET (dessin d'un point) qui fonctionne bien
Par contre la commande POINT (lecture d'un point) bute à cause du problème de lecture des registres de status
Point positif ces deux commandes me permettent de faire un test de lecture sur un registre en sachant ce que dois y trouver

A plus
Michel

Bonjour 6502man

Une remarque sur mon problème de lecture
La lecture des registres de status ne se fait pas , je pensais que cela venait du pulse /CSR mal calé….
Hors l'écriture et la relecture de points en VRAM elle, se fait correctement. Dans ce cas c'est bien le pulse /CSR qui est utilisé
Mon problème vient peut-être d'ailleurs…
A plus
Michel

Bonjour 6502man

Bonne nouvelle !!!
J'ai compris d'où venait mon problème de lecture des registres de status
En fait cela résulte d'une bourde de ma part sur la programmation du registre R#15 avec le numéro de registre de status S#n
Depuis le début je trainais cette erreur : LDA #REG15 au lieu de LDA #REG15+$80
J'ai vérifié ceci avec les commandes PSET et POINT

A plus
Michel