Amstrad CPC 6128 décodage i/o

[wawa.voun]

Bonjour à tous,

Je souhaite construire une floating point unit à base d'AM9511 ou C8231 pour le CPC 6128.

L'idée de base est ici :

fpu.jpg (32.84 Kio) Consulté 1129 fois

A priori il n'y a rien de méchant.
Tous les signaux sont sur le connecteur d'extension sauf le +12V pour le C8231.
Il y aura donc en plus un petit convertisseur 5V --> 12V.
Avec une clock à 4 MHz il faudra impérativement un C8231. Sinon un diviseur fera le 2 Mhz pour l'AM9511. A voir...

Par contre le décodage d'adresse ne va pas. Ici c'est fait pour des adresses d'i/o codée sur 8 bits mais sur le CPC les 16 lignes d'adresse sont impliquées dans le décodage d'adresses des i/o.

Avec CPC Wiki j'ai compris comment ça marche physiquement sur le CPC 6128 avec les lignes d'adresse Ax qui sélectionnent les périphériques.
Ce que je n'arrive pas à comprendre c'est comment on passe de l'électronique à l'adresse à mettre dans les instructions IN et OUT du Z80.
Et aussi finalement quelle configuration de décodage faut il retenir pour éviter les collisions avec les autres périphériques ?

Si quelqu'un avait un exemple de décodage d'adresse et des instructions assembleur IN et OUT qui vont avec ça m'aiderait beaucoup.

Merci pour le coup de main.
Philippe

PS : La ce sont mes premiers pas dans l'assembleur Z80. Soyez indulgents :!

[6502man]

Bonsoir,

Je ne suis pas un grand spécialiste du Z80, mais d'après le datasheet de Zilog
il est possible d'adresser les 16 bits d'adresses pour les instructions IN et OUT .

extrait du datasheet

Code : Tout sélectionner

In the IN A and OUT n, A instructions, the I/O device’s n address appears in the lower half
of the address bus (A7–A0), while the Accumulator content is transferred in the upper half
of the address bus. In all Register Indirect input output instructions, including block I/O
transfers, the contents of the C Register are transferred to the lower half of the address bus
(device address) while the contents of Register B are transferred to the upper half of the
address bus.

Donc pour décoder un IN ou OUT :

Code : Tout sélectionner

Pour IN => Si IORQ=0 and RD=0 alors on peut lire la donnée à l'adresse A15-A0
Pour OUT => si IORQ=0 and WR=0 alors on peut écrire la donnée à l'adresse A15-A0

Le code assembleur :

Code : Tout sélectionner

 LD BC,$8000
 IN A,(C)    ; lire la donnée A sur le port $80 ($8000)
 LD BC,$8100
 OUT (C),A   ; écrire la donnée A sur le port $81 ($8100)

Si on prendre comme adresse de port $80 et $81 pour décoder les adresses :

Code : Tout sélectionner

READ_PORT = !IORQ & !RD & A15 & !A14 & !A13 & !A12 & !A11 & !A10 & !A9 & !A8
WRITE_PORT = !IORQ & !RD &A15 & !A14 & !A13 & !A12 & !A11 & !A10 & !A9 & A8

Evidemment si tu doit décoder toutes les adresses il faut rajouter la condition des A15-A8

Voila j'espère avoir éclairé ta lanterne

[Notator]

Sur le Z80, il y a double cartographie :
- Mémoire (sélection par MREQ) sur 16 lignes d'adresses.
- I/O (sélection par IORQ) sur les 8 premières lignes d'adresses (A0 à A7).

Par ailleurs, je ne connais pas l'Amstrad, mais il semblerait qu'il y ait quelques petites particularités :

"Pour la petite anecdote, sur l'Amstrad CPC, les ingénieurs ont inversés les bits de poids fort avec les bits de poids faible du port d'entrée/sortie par économie, rendant inutilisables toutes les fonctions entrée/sortie de répétition qu'offre le Z80. Le processeur Z80 est conçu pour un design qui utilise le port pointé par le registre C alors qu'Amstrad a créé un design qui utilise le registre B pour pointer le port. Comme les instructions de répétition utilisent le registre B comme compteur, il faut pouvoir réajuster le registre B à chaque itération".

[wawa.voun]

Merci à vous deux.

Oui tout cela correspond bien à ce que j'ai trouvé jusque là.

Effectivement le truc de base à retenir sur l'Amstrad c'est que c'est les lignes A8-A15 donc le registre B qui permet principalement d'activer les i/o.
Il semblerait toutefois que pour certains périphériques les lignes A0-A7 soient aussi utilisées...
Donc en cas de décodage d'adresse incomplet (qui n'utilise pas tous les 16 bits d'adresse) sur une extension il est important de garder à 1 toutes les lignes non impliquées pour éviter d'activer par erreur et en même temps une autre i/o.

J'ai aussi eu de l'aide sur CPC Wiki et je pense tenir un truc qui tient la route.

Voir https://www.cpcwiki.eu/forum/hardware-r ... -decoding/

Je vais faire une première tentative et on verra. Le forum sera informé.

Bonne journée.
Philippe

[6502man]

Ah okay sur CPC il y à inversion des adresses hautes et basses pour les I/O

Donc dans les exemples précédant il faut corriger

[hlide]

Sur le Z80, il y a double cartographie :
- I/O (sélection par IORQ) sur les 8 premières lignes d'adresses (A0 à A7).

Non, c'est bien de A0 à A15 pour le Z80 (et le Z280) : adresse = B*256 + C ou A*256 + n. Et il n'y a pas que le CPC qui utilise ça. En fait, il suffit qu'un périphérique utilise toute la plage A0-A15 pour en bénéficier et inversement le périphérique peut ignorer A8-A15 (grosse majorité). Et je connais des cartes d'extension mémoire sur des SHARP MZ/X1 qui utilisent ça même si pour la majorité des devices on passe un A0-A7 seulement.

En revanche, ce n'est pas documenté comme tel à cause des conséquences d'utilisation mal "désignée" dès que l'on utilise INI/INIR/OUTI/OTIR.

[Notator]

Je ne sais pas, moi je me base toujours et uniquement sur la doc officielle...

Je sais bien qu'il y a des 'features' non officiellement documentés, mais s'en servir, c'est s'exposer au risque de rencontrer davantage de problèmes, parce que d'un constructeur de microprocesseurs à l'autre, ces possibilités 'cachées' peuvent ne pas avoir le même comportement...


En l'occurrence, 8 lignes d'adresses I/O, ça laisse quand même de la marge...

Et il me semble bien me souvenir (il faudrait que je vérifie sur mes docs) qu'il est préférable de loger un circuit périphérique dans le champ mémoire (MREQ) plutôt que dans le champ I/O (IORQ) car les instructions y sont plus rapides (moins de cycles)...

[hlide]

C'est documenté dans la documentation du Z80 MOSTEK

Un accès mémoire, c'est 3 cycles contre 4 cycles pour un accès I/O en effet.

[wawa.voun]

Bonjour,

Évidemment pour un copro mathématique la notion de vitesse prend tout son sens.

Décoder une adresse dans le champs mémoire n'est pas compliqué.
Ce qui l'est, sur un hardware existant (CPC 6128), c'est de désactiver la mémoire qui est au même endroit...

Je vais respecter l'esprit de la machine (même s'il détourne un peu l'idée initiale des concepteurs du Z80) et mettre ce copro en espace i/o.

Cordialement.
Philippe

[hlide]

"[...]les ingénieurs ont inversés les bits de poids fort avec les bits de poids faible du port d'entrée/sortie par économie[...]".

Je me suis gratté la tête : de quelle économie ils parlent ?

Je ne suis pas suffisamment expert en Amstrad CPC pour connaître par cœur l'association des bits d'adresse pour la sélection d'un device. Mais si on considère une nouvelle architecture, on peut décider de créer un bitmap de A15 à A4 pour pouvoir sélectionner jusqu'à 12 périphériques par un seul bit à 0, puis de de A3 à A0 pour une plage de 16 registres maximum par device. L'intérêt et de n'avoir plus besoin d'un démultiplexeur sur l'adresse embarqué dans la carte mère (et 12 signaux de sélections en sortie) puisqu'en c'est en quelque sorte embarqué dans le Z80 via cette logique. Mais je ne vois pas en quoi l'échange entre B et C est économique à moins que l'on parle de ça :

Code : Tout sélectionner

    LD BC,<reg>*256+<data>
    OUT (C),C

? c'est effectivement des choses qu'il m'a semblé avoir lu dans du code et discuté en discord. C'est assez perturbant au début de se dire que C va servir de donnée et non d'adresse de port I/O. Est-ce là l'économie liée à l'échange entre B et C ?

@wawa.voun : oui le gain à travers l'accès mémoire n'est absolument pas évident. Je dirais que l'intérêt aurait été de pouvoir d'utiliser des instructions comme CP (HL), AND/XOR/OR (HL) ou BIT/SET/RESET n,(HL) là où il est possible d'altérer une partie des bits d'un registre I/O (et ce n'est pas gagné car le fait d'accéder à une registre I/O peut avoir un effet de bord au-delà de cette partie altérée) mais dans ton cas je doute qu'il y ait un bénéfice à le faire pour ce copro. Puis il faudrait trouver un emplacement de mémoire vierge qui ne doit pas être le cas avec le CPC.