Omega MSX: un ordinateur au standard MSX2 from scratch ūüĒó

Posted by M√©d√©ric Ribreux 🗓 In projects/retro/

Introduction

Dans les ann√©es 80, mon p√®re a achet√© une b√©cane qui m'a toujours impressionn√©e: un MSX1 Yashica YC-64. Impressionnante dans sa livr√©e bordeau, ce qui √©tait plus os√© assur√©ment que le noir des Spectrums ou le gris des Commodore 64/Amiga/Atari ST et IBM PC. En plus le clavier √©tait plut√īt d'un bon niveau (enfin compar√© au clavier √† membrane du ZX81, assur√©ment). Dessus, on avait un √† peu pr√®s seul jeu en cartouche: Nemesis 2 de Konami. C'√©tait un putain de jeu hyper dur et carr√©ment au dessus de tout ce qui se faisait sur 8bits √† l'√©poque. Que de bons souvenirs avec cette machine un peu atypique par rapport aux Amstrad CPC/Thomson MO5 et Sinclair Spectrum de l'√©poque.

J'ai toujours été impressioné par les pubs pour MSX. Il y avait des modèles super stylés comme les Sony HBF-75F ou les Philips VG avec leur clavier si bizarre, pour les touches de direction.

Il n'y a pas si longtemps, en voulant rejouer à Nemesis 2, je me suis aperçu que la communauté MSX était encore vraiment très active, au point d'organiser un tournoi de développement de jeux chaque année.

En 2022, à 40 ans, fabriquer une telle bécane serait pour moi le moyen de boucler la boucle et de mesurer à quel point je suis devenu à peu près aussi compétent que les ingénieurs en électronique et informatique des années 80. Et ça, j'en serais super fier.

Donc, cette page retrace mes tentatives de refabriquer un MSX from scratch (enfin à peu près).

De l'importance des standards

Ok, il existe plein de projets de refabrication de bécanes 8 bits. Mais l'intérêt du standard MSX, c'est qu'il n'y avait aucune puce interne propriétaire obligatoire à utiliser pour fabriquer un ordinateur au standard. Et ça, ça change tout.

Par exemple, refaire un Commodore 64 ou un Amstrad CPC 6128 implique de récupérer des puces spécifiques de l'époque fabriquées exclusivement pour Commodore et pour Amstrad et qui ne sont plus disponibles aujourd'hui autrement qu'en occasion.

Pour le MSX, il n'y a pas cette contrainte: on peut commander pratiquement tout chez Mouser et le tour est joué.

Les sources

Les composants

Introduction

Moi, j'aime bien comprendre comment ça marche. Et en électronique, j'ai un vrai niveau de débutant amateur fasciné par cette magie. Alors, dans cette partie je vais indiquer ce que j'ai compris des composants présents sur l'Omega MSX.

U1: CPU Z80

Bon, celui-là, je ne vais pas le présenter, ça prendrait trop de temps.

U2: 82C55A Programmable Peripheral Interface

A la base, c'est une puce cr√©√©e par Intel: le 8255. Aujourd'hui elle reste fabriqu√©e par Renesas mais en version CMOS, d'o√Ļ le C dans le nom. Sans rentrer dans les d√©tails, la technologie CMOS utilise un certain type de transistors internes (MOSFET) ce qui lui permet de moins consommer de courant que le TTL.

Globalement, d'àprès ce que j'ai compris, cette puce permet au CPU de disposer de ports physiques d'entrée/sortie (3 en tout si je compte bien). Ce sont des ports parallèles: Il y a 8 lignes de sorties par port, chaque ligne correspond à 1 bit. Le CPU accède au PPI via un bus de données lui aussi sur 8 bits et il existe également des pattes pour sélectionner les ports et indiquer si on veut écrire ou lire sur les ports.

D'après le schéma de la carte, le 82C55 sert à controler le clavier, le port cassette ainsi qu'à un multiplexer (U30) qui permet d'accéder à U13, un progammeur logique de périphérique qui semble connecté à la ROM et à la RAM.

La documentation est disponible sur le site de Renesas.

U3: V9958 ou V9938 VDP

Cette puce est le processeur vidéo du MSX. Ça a l'air d'être une puce spécifique de chez Yamaha, même si je crois qu'elle a pu être utilisée dans d'autres machines de l'époque. VDP signifie: Video Display Processor.

Bon, c'est une puce complexe et je ne vais pas me lancer dans son étude, d'autres ont fait ça bien mieux que moi, notamment msx.org.

Par contre, ce qui m'intéresse ici, c'est de présenter ce que j'ai compris des entrées/sorties de cette puce.

Alors, cette puce dispose de 64 pattes qui sont connectées sur le MSX de la manière qui suit:

Voilà, globalement et pour résumer, on a:

Enfin, au niveau de la RAM vid√©o, U3 utilise la techno des DRAMs. Il peut acc√©der √† 16Ko/64Kb/128Kb/192Kb de DRAM. Sur l'omega, on a 128Kb de disponible sur 4 puces (U8 √† U11) contr√īll√©es directement par le VDP. 128Ko de RAM vid√©o permet d'avoir tous les modes graphiques du MSX2 disponibles. Le VDP g√®re bien entendu le rafra√ģchissement en interne, donc, on n'a pas √ßa √† g√©rer (et c'est bien).

U4: YM2149 PSG

C'est la puce de son. Elle gère également les ports joysticks. Je ne vais pas m'intéresser ici à la partie logicielle interne de la puce mais à ses connections dans la carte mère.

Les 40 pattes sont réparties de la manière suivante:

Le bus de données est bi-directionnel et sert également de mode d'adressage en coordination avec les deux pattes spéciales A7 et A8. DA0 à DA3 sont utilisées pour les adresses de registres internes (donc au max 4bits soit 16 possibilités). DA4 à DA7 sont utilisées avec A8 et A9 pour les adresses supérieures (donc au max 6 bits soit 64 possibilités).

Le bus est géré par les 3 pattes BDIR/BC1 et BC2. Globalement, BDIR gère la direction entrée ou sortie: on écrit dans le PSG quand BDIR est Low, on lit quand BDIR est High. BC1 et BC2 gère l'adressage et ou l'envoi de données.

Il y a effectivement 16 registres qui permettent de configurer les différents éléments de gestion du son, notamment les fréquences des 3 canaux A, B et C qui peuvent avoir aussi un niveau de volume spécifique ainsi qu'une forme: carrée, bruit ou enveloppe paramétrée.

Au niveau de l'Omega, la partie son se trouve dans la feuille PSG. On y constate que SEL n'est pas branchée et que la puce se comporte alors en mode de compatibilité AY-3-8910.

Le signal d'horloge qui parvient à CLOCK est généré par U35B qui semble le récupérer depuis le signal CLK général.

Les 3 canaux sonores analogiques sont regroupés en un seul et partent dans PSG_SND qui lui même repasse dans U48 avant d'être routé dans le connecteur audio J3.

Au niveau du contr√īle de bus, BC2 est toujours High (car reli√© √† VCC). √áa ne pose aucun probl√®me en g√©n√©ral car m√™me avec BC2 √† High tout le temps, on a quand m√™me acc√®s √† tous les modes de programmation du PSG. BDIR et BC1 sont issus de deux sorties de U44 en composition avec une s√©ries de puces (U44/U39/U36/U42) logiques. Il faudrait que j'analyse la logique pr√©sente pour en d√©duire le fonctionnement. Pour l'instant, savoir que la gestion du bus existe et qu'elle tourne avec BDIR et BC1 est suffisant.

Les deux pattes d'adresse A8 et A9 sont respectivement toujours à High et à Low, ce qui empêche d'avoir accès aux adresses hautes.

Les 8 bits de données entrées/sortie sont connectées au bus de données CPU (enfin, je crois).

Enfin, il reste les deux ports joysticks. En fait, seul le premier port IOA gère les deux joysticks en même temps. 6 des pattes de IOA sont connectés au joystick pour récupérer les 4 directions et le deux boutons. IOA6 est connecté à un jumper JP2 qui gère le type de clavier KBD_TYPE. IOA7 est connecté à l'entrée numérique cassette (CAS_IN).

Le deuxième port IOB gère d'autres éléments:

Pour résumer, le PSG est assez simple d'un point de vue électronique même s'il fait beaucoup avec finalement peu de pattes. Les port I/O gèrent aussi la lecture cassette ainsi que les joysticks qui semblent un peu plus complexes que les seuls 6 boutons de facade. Par ailleurs, l'analyse du PSG dans son ensemble devra être faite dans une partie dédiée car il y a beaucoup de composants logiques pour la gestion du signal.

U5: RP5C01 RTC

C'est une horloge temps réel. Elle dispose de 18 pattes:

Bon, une horloge temps réel (RTC), c'est assez simple en termes de fonctionnement: ça permet de lire l'heure, de programmer l'heure. Dans le cas de la RTC, on peut aussi gérer une alarme (et donc la programmer) et également de stocker 26 mots de 4 bits (y avait de la place dans la RAM alors...). Donc, avec 4 bits d'adresse et 4 bits de données in/out, on peut "programmer" la RTC pour lire des données.

En termes d'implémentation dans la carte mère du MSX Omega, on peut voir que la tension d'arrivée RTC_VCC passe avant par U46, qui dispose d'une entrée batterie (VBAT) sur sa patte 1 connectée à une pile CR2032. Donc, notre RTC va conserver l'heure entre deux arrêts de machine. D'ailleurs, toujours sur ce registre, on peut constater que CS est relié aussi à RTC_VCC mais que INVCS est relié à U46 via RTC_CS_B, lui même relié à U12. Il doit donc y avoir ici un mécanisme qui informe la RTC que le processeur s'éteint pour qu'elle puisse avoir l'information comme décrit dans la documentation sur CS et INVCS.

Les 4 pattes de bus d'adresse de la RTC sont reliées à U27 qui lui balance les 4 bits d'adresse. RD et WR semblent directement connectées au CPU sur les mêmes ports. Je ne parle pas de OSCIN et OSCOUT qui sont connectés comme dans la doc. ADJ est reliée à GND (via une résistance de 100kOhms) pour désactiver le mode ajustement des minutes.

Enfin, on a les 4 bits de bus qui semblent connectés au bus de données du CPU.

U6: SST39SF040 Flash ROM

C'est une mémoire flash de 4Mbit soit 512 Ko (on divise par 8) de type CMOS (forcément).

Elle dispose de 32 pattes:

L'effacement de la mémoire flash se fait secteurs de 4Ko. On peut donc effacer rapidement et avec moins de pins qu'en mode lecture. A vrai dire, ici, on s'en fout: cette mémoire Flash est destinée à remplacer la ROM du BIOS du MSX. Donc on aura soin de l'effacer sur un programmeur.

D'ailleurs, sur ce plan, les modes de programmation de la puce sont plus complexe que d'activer le mode écriture: il y a des séquences à émettre à certaines adresses pour autoriser l'écriture. C'est une mesure d'empêchement d'écriture à l'arrache. Dans notre cas, on s'en fout un peu.

Dans le cas de l'Omega MSX, cette ROM est découpée en 2 blocs de 256Ko. Ça se voit car il y a un jumper (J1) branché sur le port A18 qui gère le dernier bit d'adresse. Suivant l position du jumper, on va accéder aux premiers ou aux derniers 256Ko de la ROM. Comme c'est mécanique (un jumper), c'est au choix de l'utilisateur.

La puce est est activée via la patte CE qui est reliée à la partie PPI du MSX, sur U13 dont il faudra lire le code assembleur pour savoir ce qui se trame derrière la patte I/O6 (U13 est une puce dont le comportement est programmé). C'est aussi sur U13 qu'on retrouve les pins d'adresse A16 et A17 qui permettent d'attaquer tout ce qui se trouve au delà de 16Ko. U13 doit donc gérer les accès à tel ou tel "secteur de la ROM".

Ensuite, les sorties D0 √† D7 de la puce sont branch√©es sur le bus B du bus transceiver U26. Ce dernier est reli√© au bus de donn√©es (D0 √† D7 sur le circuit) par le bus A. C'est U13 qui indique le sens de direction des donn√©es. U26 est r√©li√©e √©galement √† la RAM, d'o√Ļ le sens des donn√©es. Pour la ROM, il semble qu'on doit pouvoir √©crire dedans mais je n'en suis pas s√Ľr.

U7: 512KB AS6C4008 SRAM

Cette puce sur 32 pins est une SRAM CMOS. Globalement, la SRAM a besoin de moins de courant pour fonctionner, compar√©e √† une DRAM qui n√©c√©ssite d'avoir un courant pour rafra√ģchir le contenu de la m√©moire p√©riodiquement.

Bon, ce que je comprends d'une RAM, c'est qu'il y a des pins qui gèrent l'adressage. Ici, on a 19 pins pour ça. Ça veut dire que théoriquement, on peut demander des données situées à une adresse codée sur 19 bits. 19 puissance 2, ça fait exactement 512Ko (524288 octets/ 1024). Comme on parle en octets, ce qui sort quand on fait une demande d'adresse, c'est un octet soit 8 bits. C'est pour ça qu'il y a 8 pins de données.

Tout ça, c'est très bien, mais dans une SRAM, on peut certes lire mais aussi écrire. On a donc 2 pins pour dire si on veut écrire ou si on veut lire.

Mais, dans une machine, on peut avoir aussi plusieurs puces de RAM. Donc, il existe un pin dédié pour activer ou pas la puce. Tout les états sont donnés dans une table de vérité décrite dans la doc mais globalement, suivant l'état du voltage (haut ou bas) sur les 3 pins sus-mentionnés, on peut:

Et bien s√Ľr, il faut alimenter la puce (entre 2.7 et 5.5V) donc une patte g√®re l'alimentation et l'autre reste la masse. 19 pins d'adresse + 8 pins de data + 3 pins de contr√īles + 2 pins d'alim = 32 pins.

Je vous passe les diagrammes de temps pour activer la lecture et l'écriture, c'est dans la doc.

Pour le reste, l'accès à la RAM ne se fait pas directement depuis le CPU, car un Z80, ça ne gère que 16 bits d'adresse. Il y a donc tout un tas de puces logiques qui permettent de gérer la pagination probablement. C'est un des points clefs que je dois comprendre pour savoir comment ça marche.

La documentation est disponible sur le site de Alliance Memory, le constructeur.

U8-U11: D41464 DRAM

Ce sont 4 puces de Dynamic RAM. Globalement, une DRAM a besoin de rafra√ģchir son contenu r√©guli√®rement sinon les donn√©es finissent par se dissiper. En revanche, les DRAM coutent g√©n√©ralement moins cher √† produire.

Dans notre cas, les D41464 sont des DRAM d'une contenance de 65535 mots de 4 bits, soit 32Ko par puce. Comme on en a 4, ça monte à 128Ko de contenance. Globalement, l'adressage est séparé en colonnes et lignes. 8 bits de colonne * 8 bits de lignes = 65535 adresses possibles.

La répartition des 18 pattes est la suivante:

Ce qui est intéressant sur ces puces, c'est qu'il n'y a rien d'apparent pour gérer le rafraichissement. D'après la documentation, celui-ci est caché et automatique, même si je note qu'il semble possible de déclencher des rafraichissements, en fonction de ce qui se passe sur CAS et RAS.

L'analyse (rapide, je ne suis pas un spécialiste), des diagrammes de temps sur un cycle de lecture montre que le protocole de lecture est le suivant:

  1. RAS est High, pour WE et OE, ils peuvent avoir les deux états.
  2. CAS monte à High.
  3. On balance les 8 bits d'adresse de ligne.
  4. RAS passe à Low mais CAS reste à High. WE doit être à High.
  5. On balance les 8 bits d'adresse de colonne.
  6. CAS passe à Low. OE doit être à Low (ce qu'il est toujours sur le MSX).
  7. Les données sont disponibles sur les entrées/sorties.
  8. Jusqu'à ce que l'état de CAS et de RAS changent.

Il existe une palanquée de mode de fonctionnement:

Ces puces forment la m√©moire vid√©o (ou du moins une partie) car elles sont reli√©es au VDP V9958 (U3) directement au niveau des entr√©es/sorties mais aussi des adresses. U3 semble donc lire (ou √©crire, les pattes des DRAMs peuvent travailler dans les deux sens) directement les entr√©es/sorties des DRAMS. Et U3 peut aussi g√©rer l'adressage des DRAMs, directement. Il en est de m√™me des pattes de contr√īle:

Pour r√©sumer, le VDP g√®re directement le rafra√ģchissement de la m√©moire et les modes d'acc√®s.

Bon, à part ça, ce sont des technos anciennes: les puces bouffent quand même pas loin de 500mW par puce en activité, rien qu'à elles seulent, elles bouffent 2W, on est loin des standards de la SRAM par exemple. Mais je pense que les utiliser semble imposé par le VDP qui ne doit savoir que gérer ça. A noter qu'il existe plusieurs versions de ces puces en ce qui concerne la rapidité d'accès aux lignes de données, les temps variant de 80ns à 120ns.

U12-U14 ATF16V8B SPLD

Ces 3 puces sont des Electrically-Erasable Programmable Logic Device. On doit pouvoir les programmer car elles ont une mémoire Flash embarquée.

Elles disposent de 20 pins:

De ce que j'ai compris, c'est une sorte de puce programmable dont on peut √† peu pr√®s faire ce qu'on veut. C'est dans la lign√©e des PAL (Programmable Array Logic) et des GAL (General Array Logic). On doit pouvoir faire comme avec un micro-contr√īleur. Par contre, je ne sais pas si la programmation de ces SPLD est sp√©cifique (pas trouv√© le code pour √ßa).

En plus, les stocks sur Mouser sont un peu bas. √áa co√Ľte 1.17‚ā¨. Pas cher mais pas si donn√© que √ßa.

En termes de place dans la carte-mère, il y a U12 qui est reliée directement au CPU sur les ports d'entrée I1 à I8. Apparamment, ça sert à gérer les accès en RAM paginée, la RTC, l'accès au VDP.

U14 semble gérer les accès aux 2 slots. Je vois qu'il a des pins de sortie qui semblent couper les accès au VDP, au clavier. Ça semble aussi gérer le sens d'entrée ou de sortie du slot (SLT_DIR).

U13 semble travailler aussi sur les slots mais également pour les accès ROM. C'est le schéma de la PPI: Programmable Parallel Interface.

Le projet Open Omega dispose [des sources pour programmer les SPLD(https://github.com/skiselev/omega/tree/master/Mainboard/SPLDs). Mais pour ça, il me faut un matos en plus: un programmateur.

Les remplacer par un microcontrolleur s'av√®re tricky: la fr√©quence en sortie de ces puces va de 45 √† 62MHz, pas √©vident √† atteindre avec un ¬Ķcontrolleur de base. A moins que √ßa soit suffisant car au final, le CPU ne va pas plus loin qu'une dizaine de MHz.

U15-U18 74HC670 4-by-4 register File

On a 4 de ces puces qui sont des registres de 16 bits découpés en 4 mots de 4 bits. Ces 4 puces semblent gérer l'accès à la mémoire, la SRAM présentée en U7.

La puce dispose de 16 pins:

De ce que j'ai compris, on écrit 4 bits dans le registre de son choix, puis on passe en mode lecture et les 4 bits écrits qu'on a écrit dans un registre sont exportés vers la sortie.

Si on met la patte de lecture et la patte d'écriture sur l'état haut en même temps, ce qu'on écrit est directement visible sur la sortie.

Sur le schéma de la carte mère de l'Omega, 2 des puces ont leur patte 11 mise à la terre.

La documentation est disponible sur le site de Texas Instruments.

U19-U21 74F541 Octal 3 state buffer

Cette puce dispose de 20 pattes. Elle permet de disposer d'un tampon de 8 bits à 3 états mais, contrairement à U22, les bits ne sont pas inversés en état.

Globalement, elles semblent √™tre utilis√©es pour la gestion des 2 slots cartouches (pour d√©finir l'adresse de lecture de la ROM cartouche je pense avec U19 et U20 et pour g√©rer les demandes de lecture avec U21 qui semble se focaliser sur le contr√īle des slots plut√īt que sur l'adresse).

La documentation est disponible sur le site de Texas Instruments.

U22 74HCT540 Octal 3-state buffer

Cette puce permet de disposer d'un tampon de 8 bits à 3 états. Globalement, il y a 20 pins:

Attention, ce tampon est constitué par des portes NON donc les sorties sont inversées par rapport aux entrées.

La documentation est disponible sur le site de Texas Instruments.

U23 et U24 74HCT273 Flip-flop

Ces puces sont des flip-flops. Apparemment, un flip flop est un truc qui une fois que tu as activé un état, il le garde en continu sur la sortie jusqu'à ce qu'une commande de clear arrive. Ça peut servir de mémoire sur 8 bits.

Dans le cas de cette puce, il y a aussi une entr√©e pour une horloge qui permet de ne lire les entr√©es qu'au moment o√Ļ le cycle de l'horloge est haut. √áa doit √™tre pour synchroniser les sorties ou les changements d'√©tats avec un moment donn√©, en fonction de ce que fait le CPU ou autre. La fr√©quence d'horloge recommand√©e pour √ßa est entre 20 et 23 Mhz.

Pour les pattes, c'est assez simple, il y en a 20:

U24 est connectée au port imprimante au niveau des sorties Q, sans doute pour piloter ou envoyer des commandes à l'imprimante.

Les sorties de U23 sont reliées aux pins d'entrées du tampon U22 ainsi qu'aux 8 pins 1C (4 pins) et 2C (4 pins) de U31.

La documentation est disponible sur le site de Texas Instruments.

Quelques explications sont disponibles ici.

U25 et U26 74F245

Ces puces sont des tranceivers de bus 8 bits. Globalement, elles permettent de faire passer des lignes d'un bus A vers un bus B et réciproquement selon l'état d'une patte qui indique la direction. La puce peut également être désactivée si l'on souhaite véhiculer des données vers une autre sortie en se repiquant sur les entrées du bus A (ou celles du bus B).

La puce dispose de 20 pins:

Pour la direction, quand la valeur sur DIR est haute, le sens est de A vers B. Quand la valeur de DIR est basse, le sens est de B vers A. Pour que les sorties soient actives, il faut que OE soit à l'état bas.

U25 est utilis√©e pour acc√©der aux 8 bits des ports cartouche BD0 √† BD7, sur le bus B, via un resistance array de 10k Ohms, sans doute pour le pull-up. Le bus A semble √™tre li√© au bus de donn√©es du CPU (√† confirmer). Dans cette configuration, on doit pouvoir envoyer des donn√©es √† la cartouche et aussi en recevoir suivant le sens indiqu√© par DIR qui est connect√© √† SLT_DIR. SLT_DIR est contr√īl√© par U14. OE est sur ground donc la puce est tout le temps active. Par contre, il y a une seule puce pour les deux slots donc il doit y avoir autre chose qui pilote le fait que √ßa aille sur un des deux slots.

U26 est utilisée dans la partie gestion de la RAM et de la ROM. Elle est aussi reliée à J12 qui sert à accéder à une SRAM externe. Ici aussi, OE est sur ground, donc la puce est tout le temps active. La direction est donnée par MEM_RD qui provient de la sortie de U13. J12 semble clairement en option (sur la photo de la carte assemblée, le connecteur n'est même pas installé).

La documentation est disponible sur le site de Texas Instruments.

U27: 74HCT175E

C'est une puce de 4 flip-flops de type D utilisant la technologie CMOS (donc c'est censé bouffer moins de jus).

Elle dispose de 16 pins:

Le reset est indépendant de l'horloge et se déclenche lorsque MR passe à l'état bas. Après le reset, les sorties Q normales sont au niveau bas (0) et les sorties Q inversées sont toutes à 1 (niveau haut).

Les sorties Q de U27 sont connectées sur les pins d'adresse de U5 qui est le circuit de RTC (Real Time Clock). Les sorties inversées ne sont pas utilisées. MR semble connecté au signal de reset inversé qui semble généré par U46. Les entrées D semblent reliées au bus de données. Le signal d'horloge CP semble généré par U12.

De ce que je comprends, U27 semble servir à accéder à la partie adressage de la RTC. Cette partie sert à programmer la RTC au niveau des adresses qui peuvent prendre 16 valeurs différentes sous forme de "registres".

La documentation est disponible sur le site de Texas Instruments.

U28 et U29: 74HCT157

Ces puces sont des multiplexeurs de 4 bits à partir de 2 entrées. Globalement, elles permettent de choisir d'exporter 4 bits d'une entrée ou de l'autre.

Elles disposent de 16 pattes:

De ce que j'ai compris et d'après la documentation, quand G est High, toutes les sorties Y sont Low. Ça permet de tout remettre à zéro.

Ensuite, quand G est Low et que A/B est à Low, alors les sorties Y reflètent l'état des entrées A (si une patte est à Low, alors la sortie est à Low, inversement si une patte de A est à High). Si A/B est à High, les sorties Y reflètent l'état des entrées B. Ça permet de sortir uniquement les 4 bits qui nous intéressent avec 2 fils de commande.

Dans notre cas, elles servent à la gestion des joysticks. G est toujours sur GND donc toujours Low. A/B est connecté à JOY_SEL.

U28 gère les accès au pavé directionnel des deux joysticks. Suivant ce qui est sélectionné sur JOY_SEL, on utilise le port A ou B. Donc U28, suivant ce qui est indiqué sur A/B renvoie la sortie du joystick A ou B (ils sont appelés comme ça), mais uniquement la partie directionnelle. Ainsi, les entrées A sont reliées physiquement aux ports du joystick A et les entrées B au joystick B. U29 gère uniquement les deux boutons de chaque joystick et donc 2 des sorties ne sont reliées à rien et 4 des entrées également.

Les ports Y de sortie de U28 et U29 sont reliés aux entrées de U4, la puce "multimédia" qui gère le son et les joysticks aussi visiblement. U4 gère également directement JOY_SEL ainsi que chaque port 8 de chaque joystick.

Pour information, voici la description des pins d'un joystick de MSX sur ses 9 ports, tels que représentés sur une prise DB9 classique:

  1. Direction Forward (en haut).
  2. Direction Back (en bas).
  3. Direction Left (gauche).
  4. Direction Right (droite).
  5. VCC alimentation 5V/750mA.
  6. Bouton 1.
  7. Bouton 2.
  8. Indique que le joystick est actif ?
  9. GND

U30 et U31: 74HCT153

Ces deux puces ressemblent à U28 et U29 mais cette fois, on a un multiplexeur qui transforme 4 entrées en 1 sortie avec une logique de sélection également différente.

Elles disposent de 16 pattes:

De ce que j'ai compris, suivant la valeur en S0 et S1, on active tel ou tel bit d'entrée pour qu'il soit exposé sur sa sortie respective. Par exemple, quand S0 et S1 sont à Low (tous à 0 donc 00 en binaire, soit 0), on prend le bit d'entrée 0 et on le sort sur la sortie respective (si on est sur l'entrée 1, ce sera la sortie 1). Si S0 et S1 sont tous à High (tous à 1 donc 11 en binaire, soit 3), on prend le bit d'entrée 3 et on le sort sur la sortie respective.

S0 et S1 sont communs aux deux entrées/sorties, ce qui indique qu'on peut tout à fait sélectionner les mêmes bits d'entrées sur les 2 entrées en même temps. Encore une fois, la sortie dépend de l'état de son bit d'entrée.

1E et 2E permettent d'activer l'une ou l'autre des sorties. Si 1E ou 2E sont à l'état High, les sorties sont toutes à Low.

Par rapport à la carte mère, U30 est connectée entre U2 (entrées de U30) et U13 (les deux sorties de U30). Globalement, suivant ce qui arrive sur U2, est renvoyé, soit sur SLT_A ou SLT_B. Les pattes d'activation semblent suivre ce qui se passe sur le port RESET.

U31 est également reliée en sortie à U13. Par contre, ses entrées proviennent de U23. Toute la logique est stockée dans U13 donc, à ce stade, je ne sais toujours pas en détail ce que fait U30 et U31.

U42: Ti SN74LS07N

Ce circuit permet de mettre des tensions du niveau TTL vers des tensions de niveau MOS qui sont bien plus élevées. On lui donne du 7V max en entrée et il peut ressortir du 30V max en sortie.

Il comporte 6 entrées et 6 sorties et 1 patte sur la masse et une autre sur la tension d'alimentation. D'après ce que j'ai compris, c'est un circuit qui est placé entre les connecteurs vidéo de sortie (S-Vidéo et RGB) et le circuit de génération vidéo.

La documentation est disponible sur le site de Texas Instruments.