tranZPUter^FusionX

Le tranZPUter^FusionX est un concept derive de la serie tranZPUter. Il partage le meme objectif : remplacer le Z80 physique dans un systeme Sharp ou similaire et lui fournir des fonctionnalites telles qu'un processeur plus rapide, davantage de memoire, des peripheriques virtuels, un chargement rapide des applications depuis une carte SD et, grace a une carte fille, de meilleurs graphismes et un meilleur son. La carte FusionX peut egalement etre utilisee pour alimenter des processeurs alternatifs sur l'hote a des fins de test, de developpement et pour fournir une plateforme logicielle et des applications completement differentes. Elle peut utiliser le clavier, le moniteur et les E/S de l'hote sous-jacent, ainsi que les graphismes et le son ameliores fournis par le FusionX. Elle partage des similitudes avec le tranZPUter^Fusion mais au lieu de le realiser materiellement via un FPGA, elle le realise logiciellement en tant qu'application. Ceci est rendu possible par un SOM (System On a Module), pas beaucoup plus grand qu'un composant FPGA mais offrant une abondance de fonctionnalites : processeur ARM Cortex-A7 double coeur a 1,2 GHz, 128 Mo de RAM, 256 Mo de FlashRAM, WiFi, video HD, carte SD, port USB et le systeme d'exploitation Linux. Utilisant la meme conception de base que le tranZPUter^Fusion, il integre un CPLD pour interfacer l'hote Z80 avec le SOM et fournir une synchronisation Z80 precise au cycle pres. Le SOM s'interface au CPLD via un canal SPI a 72 MHz et un bus 8 bits pour interroger l'etat des signaux et initier des transactions Z80. En configuration Z80, un pilote de noyau Linux instancie une emulation Z80 qui realise un processeur Z80 en logiciel, lequel peut a son tour commander et controler le systeme hote. Le pilote de noyau, accompagne d'une application de controle, peut fournir une multitude de fonctionnalites a l'hote grace a ce mecanisme. Le SOM est egalement connecte a un lecteur SD et un port USB 2.0, il n'y a donc aucune limite aux fonctionnalites pouvant etre fournies. Comme le tranZPUter^Fusion, le tranZPUter^FusionX peut fournir une video et un son ameliores a l'hote. Le SOM integre un double DAC audio et un GPU 2D avec des resolutions configurables, commutees sur les sorties video et audio de l'hote sous controle logiciel. La carte FusionX est ideale pour tout developpeur souhaitant programmer physiquement et interagir avec du materiel retro en utilisant une plateforme Linux avec une connectivite WiFi et USB/port serie. Pour la plupart des utilisateurs retro, dans les premiers stades du developpement du FusionX, la carte n'aura pas beaucoup d'utilite. Au fur et a mesure que le projet muri, une carte peut etre obtenue et installee dans le socle Z80 de leur systeme Sharp ou similaire a base de Z80 (a condition qu'il y ait suffisamment de place pour accueillir cette carte) et utiliser les fonctionnalites ameliorees, telles que :

• Specifications originales de l'hote
  - la machine se comporte comme si elle avait un Z80 physique a l'interieur. Il peut y avoir de legeres differences dans la fonctionnalite Z80 car elle est implementee en logiciel, mais la synchronisation materielle du Z80 est precise.
• Accelerateur
  - le Z80 peut fonctionner a des vitesses beaucoup plus elevees grace a l'abondance de memoire et au processeur double coeur de 1,2 GHz, ce qui permettrait typiquement d'atteindre des performances equivalentes a un Z80 a 500 MHz.
• Emulation
  - emulation de toutes les machines de la serie Sharp MZ, en les experimentant a travers le clavier, le moniteur et les E/S du systeme hote.
• Graphismes
  - tous les modes graphiques originaux Sharp MZ, quel que soit l'hote, y compris des resolutions supplementaires jusqu'a la HD, sont disponibles via la configuration du GPU et peuvent etre selectionnes et programmes sur l'hote dans des langages tels que Basic.
• Son
  - l'hote aura acces aux convertisseurs DAC stereo, qui peuvent lire du son de qualite CD a 48 KHz ou emuler le SN76489 ou le son basique bit/timer de la serie Sharp. L'enregistrement sonore est egalement possible via l'entree microphone.
• Processeurs
  - il existe de nombreuses implementations logicielles de processeurs qui peuvent etre portees pour fonctionner sur cette plateforme, par exemple les emulations de processeurs ARM de la plateforme BBC PiCoPro peuvent etre facilement portees. Cela permet potentiellement a d'autres machines, en utilisant les graphismes et le son avances du SOM selon les besoins, de faire fonctionner des emulations de machines telles que le BBC sur cet hote Sharp.
• Linux
  - en utilisant le clavier, le haut-parleur, le moniteur etc. de l'hote, une version complete de Linux, incluant le WiFi, peut etre utilisee sur la console de l'hote.

La version 1.0 est la premiere publication officielle de la conception du tranZPUter^FusionX. La carte FusionX s'appuie sur une interface hote Z80 eprouvee utilisant le composant CPLD Altera 7000A MAX. Le CPLD interface non seulement les signaux hotes Z80 5V aux signaux 3,3V des composants plus recents, il integre egalement la logique necessaire pour effectuer une synchronisation Z80 precise en utilisant une horloge de 50 MHz pour echantillonner l'horloge hote Z80 et activer les signaux conformement aux diagrammes d'etats publies du Z80. De plus, le FusionX comprend un System-On-a-Module SigmaStar, un petit composant de type timbre de 29mm x 29mm qui integre un processeur Cortex-A7 double coeur, 128 Mo de DRAM, 256 Mo de FlashNAND et un emetteur-recepteur WiFi. Le SOM SigmaStar est capable de produire des graphismes 2D au format RGB 888 avec une resolution selectionnable jusqu'au format HD. Il est egalement capable d'une sortie audio DAC stereo a 48 KHz. Cliquez pour consulter la fiche produit complete du SigmaStar. En s'appuyant sur l'experience acquise avec le tranZPUter SW-700, un DAC video 30 bits a ete choisi pour le rendu video du SOM SigmaStar plutot qu'une echelle R-2R, et un DAC 8 bits supplementaire est inclus pour le rendu des niveaux de contraste du moniteur monochrome afin de prendre en charge les nuances de couleur sur les moniteurs CRT monochromes que l'on trouve dans le MZ-80A/MZ-2000. La conception materielle est centree sur une carte de circuit principal qui contient tous les circuits primaires et un certain nombre de cartes filles, chaque carte fille etant dediee a un hote (par ex. MZ-700, MZ-80A, MZ-2000). La carte fille intercepte le sous-systeme video/audio de l'hote et prend en charge la commutation de la video/audio de l'hote et de la carte principale vers le moniteur/haut-parleur de l'hote. La carte principale peut etre utilisee sans cartes filles ; ces dernieres ne sont utilisees que lorsque la video/audio du SOM est requise. Cette section presente les schemas et la conception du circuit imprime de la carte principale du tranZPUter^FusionX.

Le schema interface le Z80 au CPLD. Le CPLD est tolerant 5V et fonctionne en interne a 3,3V. Les sorties sont selectionnees en TTL basse tension, ce qui signifie qu'un '1' est represente par 3,3V au lieu de 5V dans le systeme hote. Les specifications du TTL 5V situent le seuil de commutation a environ 2,4V, le CPLD est donc capable de piloter des circuits 5V avec un courant de commande suffisant de 25 mA par broche. Les machines d'etats internes du CPLD sont cadencees par un oscillateur externe de 50 MHz, ce qui permet un echantillonnage et un changement d'etat adequats pour un hote Z80 typique de 1 MHz a 6 MHz.

Le SOM est riche en peripheriques et ce circuit en interface certains pour une utilisation dans le FusionX, notamment :

• Entree microphone audio stereo
  - une entree microphone numerique est egalement disponible mais les broches sont utilisees dans l'interface CPLD.
• Sortie DAC audio stereo
  - double convertisseur numerique-analogique pour la sortie sonore pouvant etre cadence a 48 KHz.
• Antenne WiFi
  - un emetteur-recepteur WiFi SSW101B 20/40 MHz IEEE 802.11 b/g/n/e/l/n/w fonctionnant dans la bande 2,4 GHz avec une portee de 500 m. Le SOM comprend egalement un PHY ETH 100 MHz mais celui-ci n'est pas utilise dans cette conception car l'Ethernet filaire n'est pas pratique pour une carte situee a l'interieur d'une machine retro.
• USB Serie
  - lorsque Linux fonctionne, la console est presentee sur un peripherique serie UART. Ce peripherique serie est converti en USB pour faciliter la visualisation et la connexion avec la console Linux.
• USB
  - un port USB connecte a Linux permettant l'extension de peripheriques, tels que du stockage supplementaire, des souris, etc.
• UART rapide
  - UART full duplex haute vitesse avec controle de flux materiel.
• UART
  - UART standard a 2 broches fonctionnant jusqu'a 500 KHz.
• Carte SD
  - le SOM dispose d'une FlashNAND integree et peut donc accueillir un systeme de fichiers Linux simple ; l'ajout d'une carte SD permet un plus grand stockage des applications hotes et des utilitaires Linux. Une carte SD facilite egalement les mises a jour car le SOM effectuera une mise a jour automatique lorsqu'une carte SD correctement preparee est presente au demarrage.

Le SOM produit un signal TTL RGB avec 8 bits par couleur. Celui-ci est interface a un VideoDAC 30 bits, les 2 bits les plus faibles par couleur etant controles par le CPLD. De plus, afin de piloter les moniteurs monochromes internes des Sharp MZ-80A/MZ-80B/MZ-2000, un VideoDAC 8 bits est ajoute qui produit un signal video dans la plage 4V-5V en utilisant une entree couleur RGB 332, l'entree couleur etant le MSB de la sortie TTL 888 du SOM. J'appelle cela le DAC de contraste, car il envoie le signal video avec des informations de couleur sous forme de signal de contraste controle en tension qui se presente sur le moniteur comme des niveaux de contraste differents, simulant ainsi la couleur en niveaux de gris. Afin d'obtenir un noir veritable, le CPLD cree un signal de suppression, MONO.BLANK, qui est couple a un clamp MUX 0V sur la carte fille qui pilote le moniteur monochrome ; le RGB332 est vu comme 0V lorsque 00000000 est present, puis varie entre 4,01V-5V lorsqu'il est non nul.

L'alimentation, pour le SOM et le CPLD, convertit le 5V present sur le socle Z80 en 3,3V en utilisant un convertisseur abaisseur a haute efficacite. Ceci est necessaire pour minimiser la chaleur et fournir un courant maximum au SOM/CPLD. De plus, un interrupteur d'alimentation USB controle par logiciel est installe pour activer (et reinitialiser si necessaire) l'alimentation +5V du port d'extension USB.

Le dernier schema est l'interface entre le SOM et le CPLD. A l'origine, il devait s'agir d'un bus bidirectionnel 16 bits avec des signaux de lecture/ecriture et de strobe, mais apres des tests, le temps de preparation d'un signal 16 bits avec commutation tri-etat etait beaucoup plus lent qu'une connexion SPI en raison de la disposition et du fonctionnement des registres GPIO dans le SOM et de la vitesse des operations d'E/S au sein du SOM. La solution utilisee est d'avoir un bus SPI bidirectionnel a 72 MHz entre le SOM et le CPLD pour transmettre les requetes de transactions Z80 et un bus parallele en lecture seule de 8 bits pour une lecture plus rapide des donnees Z80 et des informations d'etat Z80 separees.

Le PCB a ete concu avec la taille minimale comme exigence principale pour les differentes machines dans lesquelles il serait installe. Il devait egalement etre compatible avec le tranZPUter^Fusion pour l'interchangeabilite. Une preoccupation majeure etait la dissipation thermique car le PCB, lorsqu'il est installe dans un MZ-700, est tres proche des composants existants de la carte mere qui degagent beaucoup de chaleur sans circulation d'air dans un boitier compact scelle. Cela signifiait que les composants actifs ne pouvaient pas etre places sur la face inferieure du PCB car la generation de chaleur conduirait a l'instabilite et a la defaillance, ce qui a conduit a une augmentation de la taille finale du PCB. Les composants les plus petits pouvant etre assembles manuellement ont ete utilises, c'est-a-dire des composants passifs 0402/0603 et un espacement de pas de CI de 0,5 mm pour reduire la taille globale, et un empilement 4 couches selectionne pour accueillir tous les composants necessaires.

Cliquez ici pour visualiser un diagramme interactif de placement des composants et la nomenclature.

Le tranZPUter^FusionX utilise un CPLD Altera MAX7000AE — specifiquement le EPM7512AETC144-10 — comme interface centrale entre le SOM et le socle hote Z80. Il s'agit d'un composant a 512 macrocellules, boitier TQFP 144 broches, fonctionnant en LVTTL 3,3V sur ses sorties tout en acceptant des niveaux TTL 5V sur ses entrees, ce qui le rend directement compatible avec le materiel Sharp MZ vintage et autres systemes Z80 sans aucun changement de niveau supplementaire. La conception du CPLD est ecrite en VHDL et construite avec Altera Quartus II 13.0.1 SP1 (Web Edition). Comme chaque machine hote a des exigences de synchronisation de bus legerement differentes et des contraintes de carte memoire, une implementation VHDL separee est maintenue pour chaque hote supporte :

Le CPLD remplit plusieurs fonctions qui seraient impraticables ou impossibles a implementer directement en logiciel sur le SOM :

• Conversion de niveau de tension
  — Fait le pont entre le bus hote Z80 en TTL 5V et les signaux LVTTL 3,3V utilises par le SOM. Le MAX7000AE est tolerant 5V sur ses entrees et pilote ses sorties a 3,3V, ce qui depasse le seuil de commutation de 2,4V des recepteurs TTL 5V, offrant jusqu'a 25 mA de courant par broche.
• Synchronisation de bus Z80 precise au cycle pres
  — Le CPLD implemente une FSM materielle cadencee par un oscillateur externe de 50 MHz qui echantillonne l'horloge hote Z80 et reproduit la sequence precise des T-states pour chaque type de cycle de bus. Cela decharge le SOM de toute synchronisation critique, qui n'a qu'a repondre avec les donnees dans la fenetre definie par la FSM du CPLD.
• Pont d'interface SOM
  — Convertit entre le protocole de bus parallele Z80 et l'interface SPI + GPIO 8 bits utilisee par le module noyau du SOM, traduisant les evenements de bus dans un format que le SSD202 peut traiter efficacement depuis un thread de noyau Linux.
• Commutation video et audio
  — Controle les multiplexeurs qui selectionnent entre la sortie video/audio native de la machine hote et la video/audio du SOM pour le routage vers le moniteur et les haut-parleurs via les connecteurs de la carte fille. La commutation est commandee par le SOM via SPI.
• Generation de synchronisation et d'horloge video
  — Genere la synchronisation composite (VGA_CSYNCn) a partir des signaux VSync et HSync du SOM, detecte les intervalles de suppression, genere une horloge de pixels de 25 MHz pour le DAC monochrome (en divisant l'oscillateur de 50 MHz), et produit un signal de frequence de sous-porteuse couleur (VGA_COLR) pour la sortie video composite couleur.
• Gestion du reset
  — Surveille la ligne RESET Z80 de l'hote et implemente un protocole de reset a double pression : une simple pression de reset active un reset logiciel vers le SOM (permettant a l'application Z80 de se reinitialiser), tandis qu'une seconde pression dans la seconde qui suit active la ligne PM_RESET du SOM pour forcer un redemarrage complet du SOM.
• Controle de l'alimentation USB
  — Controle le signal d'activation de l'alimentation USB VBUS sous commande du SOM.

Le coeur de la conception du CPLD est une machine a etats finis (SOMFSMState) qui suit et reproduit l'etat du cycle de bus Z80 avec une resolution de 50 MHz. La FSM surveille les fronts de l'horloge hote Z80 et les signaux de controle du bus (MREQ, IORQ, RD, WR, M1, RFSH, BUSRQ, HALT, WAIT) pour classifier chaque cycle de bus et parcourir la sequence correcte de T-states :

Chaque etat possede des sous-etats numerotes (par ex. FetchCycle_11, FetchCycle_20) correspondant aux demi-cycles individuels au sein du T-state, permettant au CPLD d'activer ou de desactiver les signaux de controle avec une precision inferieure au cycle d'horloge par rapport aux fronts de CLK de l'hote. Une FSM secondaire CTRLFSMState gere le traitement des commandes SPI (CTRLCMD_Idle → CTRLCMD_ReadIOWrite) independamment de la FSM principale du cycle de bus, de sorte que les transactions SPI du SOM ne bloquent pas le traitement des cycles de bus Z80.

Le CPLD presente deux interfaces distinctes au SOM :

• SPI esclave (chemin d'ecriture)
  — Un SPI esclave a 4 fils (VSOM_SPI_CLK, VSOM_SPI_MOSI, VSOM_SPI_MISO, VSOM_SPI_CSn) recoit les commandes et les donnees du SOM. Jusqu'a 4 octets par trame sont decales via un registre a decalage serie et decodes en commandes de controle de bus (donnees d'ecriture memoire, donnees d'ecriture E/S, selection de source video/audio, controle d'alimentation USB). La polarite de l'horloge SPI est parametree (SPI_CLK_POLARITY) pour s'adapter aux differentes configurations SPI du SOM.
• Bus parallele 8 bits (chemin de lecture)
  — Un bus de sortie 8 bits (VSOM_DATA_OUT[7:0]) avec une ligne de selection VSOM_HBYTE presente soit l'octet inferieur soit l'octet superieur du mot adresse/donnees Z80 courant aux entrees GPIO du SOM. Des lignes d'etat supplementaires a bit unique signalent : VSOM_READY (FSM inactive), VSOM_LTSTATE (dernier T-state du cycle courant), VSOM_BUSRQ, VSOM_BUSACK, VSOM_INT, VSOM_NMI, VSOM_WAIT et VSOM_RESET.

Cette architecture divisee — SPI pour les ecritures, bus parallele GPIO pour les lectures — correspond aux caracteristiques de performance relatives du SSD202 : le SPI est cadence et fiable pour les ecritures multi-octets, tandis que l'acces direct aux registres GPIO offre la latence de lecture la plus faible possible pour echantillonner l'etat du bus dans une fenetre de T-state Z80.

Le bitstream du CPLD est produit en utilisant Altera Quartus II 13.0.1 SP1 Web Edition, disponible en telechargement gratuit sur le site web Intel FPGA (anciennement Altera). La Web Edition prend en charge tous les composants MAX7000AE et est suffisante pour ce projet. Ouverture du projet
Chaque variante de machine hote possede son propre projet Quartus dans le sous-repertoire correspondant. Pour construire la variante MZ-80A, par exemple :

# Ouvrir dans l'interface Quartus II :
File -> Open Project -> CPLD/v1.0/MZ80A/build/tzpuFusionX_MZ80A.qpf

# Ou lancer depuis la ligne de commande via le shell Quartus :
quartus_sh --flow compile tzpuFusionX_MZ80A

Le projet reference trois fichiers source VHDL (chemins relatifs au repertoire build/ du projet) :

• ../tzpuFusionX_Toplevel.vhd — instanciation de l'entite de niveau superieur et definitions des broches d'E/S
• ../tzpuFusionX_pkg.vhd — package partage (types, constantes)
• ../tzpuFusionX.vhd — architecture RTL principale (FSMs, SPI, interface de bus, controle video/audio)

Compilation
Dans l'interface Quartus, selectionnez Processing → Start Compilation (ou appuyez sur Ctrl+L). L'outil execute l'analyse et synthese, le placement-routage, l'assembleur et l'analyse de timing en sequence. Une construction reussie produit :

build/output_files/tzpuFusionX_MZ80A.pof   # Fichier Programmer Object (programmation JTAG)
build/output_files/tzpuFusionX_MZ80A.fit.rpt  # Rapport de placement (utilisation des ressources)
build/output_files/tzpuFusionX_MZ80A.sta.rpt  # Rapport d'analyse de timing

Le fichier .pof est l'image binaire utilisee pour programmer le composant CPLD physique. Programmation du CPLD
La programmation est effectuee via JTAG en utilisant un Altera USB-Blaster ou un adaptateur JTAG compatible connecte au connecteur JTAG 10 broches de la carte FusionX :

1. Connectez le USB-Blaster au connecteur JTAG du FusionX et au PC hote.
2. Alimentez la carte FusionX (le CPLD doit etre alimente pendant la programmation).
3. Dans Quartus II, ouvrez Tools → Programmer.
4. Chargez le fichier de description de chaine : build/output_files/tzpuFusionX_MZ80A.cdf.
5. Verifiez que le USB-Blaster est detecte dans la liste du materiel, puis cliquez sur Start.
6. La programmation se termine en quelques secondes ; le CPLD devient actif immediatement apres l'achevement.

Le CPLD conserve sa logique programmee indefiniment sans alimentation (le MAX7000AE utilise des cellules de configuration basees sur EEPROM), le composant n'a donc besoin d'etre programme qu'une seule fois par construction ou lors de la mise a jour vers un nouveau bitstream.

La pile logicielle du FusionX s'etend du systeme d'exploitation Linux aux modules noyau dedies et aux utilitaires espace utilisateur. L'ensemble logiciel complet est construit a l'aide d'un environnement de construction SigmaStar personnalise et charge sur la flash SPI NAND du SOM. Au demarrage, U-boot initialise le SOM et passe la main au noyau Linux, qui charge le systeme de fichiers racine Buildroot. Le script de demarrage du FusionX configure ensuite le systeme et met l'emulateur Z80 en ligne. Les composants logiciels sont :

• Linux OS
  — Noyau 4.9-rt (PREEMPT_RT) avec systeme de fichiers racine Buildroot fonctionnant sur le SigmaStar SSD202 double coeur Cortex-A7.
• z80drv.ko
  — Module noyau Linux implementant l'emulateur de processeur Z80 et l'interface materielle hote. Execute la boucle d'emulation Z80 sur un coeur processeur dedie.
• ttymzdrv.ko
  — Module noyau TTY Linux qui presente le clavier et l'ecran Sharp MZ comme un peripherique terminal Linux standard (/dev/ttymz0).
• z80ctrl
  — Utilitaire en ligne de commande espace utilisateur pour controler le module noyau z80drv : charger des images ROM, ajouter des peripheriques materiels virtuels, demarrer/arreter l'emulation et inspecter la memoire emulee.
• k64fcpu
  — Daemon espace utilisateur emulant un processeur virtuel K64F. Utilise en mode TZFS pour gerer le chargement des ROM et la communication inter-processeur avec l'emulateur Z80.
• sharpbiter
  — Daemon arbitre Sharp MZ, coordonnant l'acces aux ressources materielles partagees du Sharp MZ entre l'emulateur Z80 et le pilote TTY Linux.

Le demarrage est gere par start_FusionX.sh, qui charge ttymzdrv.ko, demarre une session de connexion getty sur /dev/ttymz0, assigne tous les processus Linux et les IRQ au CPU0, charge z80drv.ko sur le CPU1 isole, puis lance les daemons k64fcpu et sharpbiter. Deux modes de demarrage preconstruits sont fournis :

• Mode RFS
  (startZ80_RFS.sh) — charge le peripherique materiel virtuel ROM Filing System et demarre l'emulateur MZ-80A avec des images ROM 40 ou 80 colonnes.
• Mode TZFS
  (startZ80_TZFS.sh) — charge le peripherique materiel virtuel tranZPUter SW et demarre le daemon k64fcpu K64F qui gere le chargement des images ROM Monitor et TZFS.

L'architecture logicielle du FusionX est stratifiee, chaque couche gerant une responsabilite distincte. Du point de vue de la machine hote, le flux est entierement transparent — le socle Z80 se comporte comme un processeur Z80 normal tandis que le SOM intercepte et emule silencieusement chaque cycle de bus.

 Sharp MZ Host
 +------------------------------------------+
 |  Z80 DIP-40 Socket                       |
 +--------------+---------------------------+
                |  Z80 bus (address, data, control)
 +--------------v---------------------------+
 |  CPLD (Altera MAX 7000A)                 |
 |  . 5V <-> 3.3V level translation        |
 |  . Cycle-accurate Z80 bus timing         |
 |  . 50 MHz internal clock                 |
 +--------------+---------------------------+
                |  SPI (50 MHz) + 8-bit GPIO bus
 +--------------v---------------------------+
 |  SSD202 SOM -- CPU1 (dedicated)          |
 |  +--------------------------------------+|
 |  |  z80drv.ko kernel module             ||
 |  |  +----------------------------------+||
 |  |  |  z80io.c  (GPIO/SPI HAL)         |||
 |  |  +----------------------------------+||
 |  |  |  Zeta Z80 CPU emulator core      |||
 |  |  +----------------------------------+||
 |  |  |  Virtual hardware modules        |||
 |  |  |  (z80vhw_*.c, inline)            |||
 |  |  +----------------------------------+||
 |  +--------------------------------------+|
 |                                          |
 |  SSD202 SOM -- CPU0 (Linux)              |
 |  +--------------------------------------+|
 |  |  Linux 4.9-rt  /  Buildroot rootfs  ||
 |  |  ttymzdrv.ko  -->  /dev/ttymz0      ||
 |  |  z80ctrl  (control utility)          ||
 |  |  k64fcpu  (K64F daemon)              ||
 |  |  sharpbiter  (MZ arbiter)            ||
 |  +--------------------------------------+|
 +------------------------------------------+

Les deux coeurs Cortex-A7 du SSD202 fonctionnent sous une stricte separation des responsabilites. Au demarrage, tous les processus Linux et toutes les affinites d'IRQ materielles sont migres vers le CPU0, laissant le CPU1 exclusivement disponible pour le thread noyau d'emulation Z80. Le gouverneur de frequence du processeur est mis en mode performance (1,2 GHz fixe) apres le demarrage de l'emulateur pour empecher les transitions de mise a l'echelle de frequence d'introduire des variations de timing dans la boucle d'emulation. CPU0 — Linux et services espace utilisateur
Execute le systeme d'exploitation Linux 4.9-rt complet, tous les daemons espace utilisateur et gere toutes les interruptions materielles. Les responsabilites cles sur le CPU0 incluent :

• ttymzdrv.ko
  — Module noyau TTY Linux qui mappe le clavier et l'ecran Sharp MZ sur /dev/ttymz0. Supporte la suspension et la reprise, permettant a l'utilisateur de basculer de maniere transparente entre une session Z80 et une console Linux sur la machine hote sans perdre l'etat dans l'une ou l'autre.
• Utilitaire z80ctrl
  — Outil en ligne de commande pour le controle a l'execution de l'emulateur Z80 : chargement d'images ROM, enregistrement de peripheriques materiels virtuels, demarrage et arret de la boucle d'emulation, et inspection de la memoire emulee. Communique avec z80drv.ko via un peripherique caractere du noyau.
• Daemon k64fcpu
  — Daemon espace utilisateur qui emule un processeur virtuel K64F. Actif en mode TZFS ; il gere le chargement des images ROM Monitor et TZFS dans l'espace memoire de l'emulateur et relaie les commandes inter-processeur vers z80drv.ko.
• Daemon sharpbiter
  — Arbitre Sharp MZ ; coordonne l'acces au clavier et a l'ecran partages du Sharp MZ entre le pilote TTY et l'emulateur Z80 afin que les deux puissent fonctionner sans conflit sur les registres d'E/S sous-jacents.
• WiFi et serveur web
  — L'emetteur-recepteur 802.11 b/g/n integre du SOM (SSW101B) fournit une connectivite reseau. Un serveur web leger sur le CPU0 peut servir des pages de configuration et d'etat, et la pile WiFi gere la livraison de firmware OTA via la mise a jour automatique par carte SD au demarrage.

CPU1 — Emulateur Z80 (dedie)
Execute exclusivement le thread noyau kthread_z80 lance par z80drv.ko. Aucun autre processus ou interruption n'est jamais planifie sur le CPU1 apres l'initialisation. La boucle d'emulation sur le CPU1 :

• Appelle le coeur Z80 Zeta pour chaque etape d'execution d'instruction
• Distribue chaque acces memoire ou E/S resultant vers le gestionnaire correct — materiel hote physique, image RAM residente en noyau, ou fonction de module materiel virtuel
• Pilote le materiel GPIO et SPI via z80io.c pour activer ou echantillonner les signaux de bus Z80 a travers le CPLD
• Fonctionne a 1,2 GHz avec le noyau PREEMPT_RT garantissant une gigue d'interruption minimale meme due a l'activite du CPU0

Le chemin materiel du SOM au socle hote Z80 passe par un CPLD Altera MAX 7000A. Ce composant remplit deux roles essentiels :

• Conversion de niveau de tension
  — Le CPLD est tolerant 5V sur ses entrees et pilote ses sorties en niveaux LVTTL 3,3V. Comme le seuil de commutation TTL 5V est d'environ 2,4V, le CPLD peut piloter directement la logique hote 5V avec jusqu'a 25 mA par broche, rendant la carte compatible avec le materiel Z80 vintage non modifie.
• Synchronisation de bus Z80 precise au cycle pres
  — Le CPLD integre des machines a etats cadencees par un oscillateur externe de 50 MHz. Ces machines a etats echantillonnent l'horloge hote Z80 et reproduisent la sequence precise de T-states pour chaque cycle de bus (fetch, lecture/ecriture memoire, lecture/ecriture E/S) comme defini dans les diagrammes d'etat du Z80. Cela signifie que le module noyau du SOM n'a pas besoin de reproduire la synchronisation Z80 submicroseconde en logiciel — le CPLD la gere en materiel.

Le SOM communique avec le CPLD via deux canaux paralleles :

• Canal SPI (50 MHz)
  — utilise pour ecrire des donnees et des commandes au CPLD. L'ecriture SPI est utilisee de preference au GPIO pour les ecritures sur le bus hote car elle est cadencee et donc plus fiable pour les transferts multi-octets a grande vitesse.
• Bus GPIO 8 bits
  — utilise par z80io.c pour lire l'etat du bus et les valeurs d'adresse/donnees depuis le CPLD. L'acces direct aux registres est utilise (contournant l'API HAL SigmaStar apres l'initialisation) pour minimiser la latence de lecture. Le debit de lecture maximal atteignable via la structure GPIO du SSD202 est d'environ 2 Mo/s pour un octet 8 bits — suffisamment rapide pour traiter les cycles de bus Z80 aux vitesses d'horloge hotes typiques (1 MHz-6 MHz) lorsque combine avec la mise en tampon du CPLD.

Comme le debit de lecture GPIO fixe une limite superieure au taux de transactions de bus, les programmes Z80 s'executent a partir d'images memoire residentes en noyau plutot que d'etre lus depuis la memoire physique hote sur le bus a chaque acces. Les images ROM sont chargees en memoire noyau au demarrage, et tous les acces memoire par le Z80 emule sont traites a partir de la — le bus hote physique n'est sollicite que lorsqu'un bloc de type PHYSICAL est rencontre (par ex. pour la RAM video de l'hote ou les registres materiels qui doivent etre accedes sur le vrai materiel).

Les 128 Mo de DRAM du SOM SSD202 sont partages entre le systeme d'exploitation Linux et le module noyau Z80. Le module noyau alloue une region contigue de memoire noyau physiquement adressee pour contenir les images ROM et RAM du Z80 emule. Cette region est accedee directement par le kthread_z80 fonctionnant sur le CPU1, sans surcharge de traduction de memoire virtuelle dans la boucle d'emulation interne. Le Z80 emule voit une carte memoire configurable sur l'espace d'adressage standard de 64 Ko (0x0000-0xFFFF). Chaque region se voit attribuer l'un des types d'acces suivants :

Les images ROM sont chargees en memoire noyau au demarrage par z80ctrl --loadrom (ou automatiquement par le module materiel virtuel actif ou le daemon k64fcpu en mode TZFS). Plusieurs ensembles de pages ROM peuvent etre residentes simultanement — le module materiel virtuel RFS, par exemple, maintient jusqu'a quatre pages ROM commutables (MROM, User ROM I/II/III) pour les configurations 40 colonnes et 80 colonnes. Les constantes de timing machine pour chaque hote supporte (MZ-80A, MZ-700, MZ-2000, PCW-8256) sont definies dans z80driver.h et utilisees par la boucle d'emulation pour cadencer les cycles de bus au bon rythme par rapport a l'horloge hote, garantissant que les logiciels sensibles au timing (controle du moteur de cassette, E/S serie, boucles de temporisation) se comportent comme sur le materiel d'origine.

Les modules materiels virtuels sont des fichiers source C (z80vhw_*.c) qui definissent le comportement d'une machine hote ou d'un ensemble de peripheriques specifique. Plutot que d'etre compiles comme des objets lies separement, ils sont directement inclus par #include dans z80driver.c, de sorte que leurs fonctions gestionnaires sont inlineees dans le chemin de distribution de l'emulation sans surcharge d'appel de fonction. Jusqu'a cinq peripheriques materiels virtuels peuvent etre actifs simultanement (MAX_VIRTUAL_DEVICES 5). Les peripheriques sont enregistres a l'execution avant le demarrage de l'emulateur en utilisant z80ctrl --adddev --device <name>. Chaque peripherique enregistre recoit des callbacks de lecture memoire, ecriture memoire, lecture E/S et ecriture E/S pour les plages d'adresses qu'il revendique, et peut optionnellement installer ses propres images ROM et configurer la carte memoire lors de l'initialisation. Les modules disponibles et les machines hotes qu'ils prennent en charge sont :

Le module TZPU (z80vhw_tzpu.c) est architecturalement distinct des autres. Le comportement du coprocesseur K64F etant complexe et a etats, il est reparti entre deux composants : le stub cote noyau z80vhw_tzpu.c gere la distribution rapide des cycles de bus tandis que le daemon espace utilisateur k64fcpu sur le CPU0 gere le chargement des ROM, la selection des banques memoire et le traitement des commandes K64F de niveau superieur. Les deux parties communiquent via une region de memoire partagee dans le module noyau.

Le moyen le plus rapide de construire chaque composant du FusionX — les ROMs en assembleur Z80, TZFS et CP/M, les modules noyau Linux et les outils SPI, les bit streams du CPLD et l'image SD Linux complete SigmaStar SSD202 — est le script d'installation fourni pour votre plateforme. Chaque script est autonome : copiez simplement ce seul fichier et executez-le. Il installe les outils requis, clone le depot avec ses sous-modules (dans ~/FusionX par defaut), recupere le bundle de contenu SharpSoft (TZFS_Files.zip, ~110 Mo), prepare la chaine d'outils et propose de lancer la premiere construction. Les etapes manuelles, composant par composant, plus bas restent disponibles pour les utilisateurs avances et les reconstructions partielles.

chmod +x setup_FusionX.sh
./setup_FusionX.sh

Windows 10/11 — double-cliquez sur setup_FusionX_windows.cmd, ou depuis une invite PowerShell :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_FusionX_windows_native.ps1

La construction elle-meme est pilotee par build.sh, qui choisit une chaine d'outils native, une image Docker ou une distribution WSL1 par composant selon l'hote (Linux : tout natif ; macOS : tout Docker ; Windows : ROMs/CPLD natifs + WSL1 pour les parties uniquement Linux). Construisez tout, ou passez un ou plusieurs indicateurs pour un seul composant :

./build.sh                 # tous les composants
./build.sh --cpld          # uniquement les bit streams du CPLD
./build.sh --help          # lister toutes les options

Surcharges d'environnement pratiques (toutes optionnelles) :

Pour les details de construction manuelle, composant par composant — y compris la construction d'image bas niveau Build_FusionX.sh — voir Construction ci-dessous.

L'ensemble complet du systeme d'exploitation et des applications du FusionX est construit a l'aide du script Build_FusionX.sh, qui encapsule le systeme de construction du SDK SigmaStar et produit une image NAND prete a flasher. La construction necessite un hote Linux avec la chaine d'outils de compilation croisee ARM installee. Prerequis

• Compilateur croise ARM : arm-linux-gnueabihf-gcc (par ex. du paquet gcc-arm-linux-gnueabihf)
• Arbre source du SDK SigmaStar (noyau, U-boot, Buildroot) dans la structure de repertoires parente attendue par Build_FusionX.sh
• Source de l'application FusionX dans le repertoire ../FusionX relatif au repertoire de construction Linux
• Outils de construction standard : make, cmake, bc, libssl-dev

Construction de l'image systeme complete La construction est lancee depuis le repertoire software/linux/ :

# Construire l'image complete pour FusionX (projet 2D06, SPI NAND, SSD202, flash 256 Mo)
./Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256

Ceci construit en sequence : le bootloader U-boot, le noyau Linux (utilisant le defconfig personnalise FusionX infinity2m_spinand_fusionx_defconfig), le systeme de fichiers racine Buildroot et l'ensemble applicatif FusionX. Les images de sortie sont ecrites dans project/image/output/images/. Pour la configuration de reference standard SigmaStar, utilisez le projet 2D07 a la place. Construction des modules noyau uniquement Les modules noyau peuvent etre reconstruits independamment contre un arbre noyau deja construit, ce qui est utile pendant le developpement :

# Construire le module noyau z80drv
cd software/FusionX/src/z80drv/src.mz80a
make

# Construire le module noyau ttymzdrv
cd software/FusionX/src/ttymz
make

Les fichiers z80drv.ko et ttymzdrv.ko resultants peuvent etre copies directement dans le repertoire /apps/FusionX/modules/ du SOM en cours d'execution (via SSH ou carte SD) et charges avec insmod. Flashage et mises a jour L'image flash produite par le script de construction est programmee sur le SPI NAND du SOM via l'outil ISP SigmaStar par USB. Une fois l'image initiale installee, les mises a jour suivantes peuvent etre livrees via carte SD — lorsque le SOM demarre avec une carte SD correctement preparee presente, il mettra automatiquement a jour l'image NAND sans necessiter de connexion USB.

La plateforme Linux fonctionne sur le SOM SigmaStar SSD202 (Infinity2M) — un module de type timbre de 29 mm x 29 mm contenant un double coeur ARM Cortex-A7 a 1,2 GHz, 128 Mo de DRAM, 256 Mo de flash SPI NAND et un emetteur-recepteur WiFi 802.11 b/g/n integre. Le noyau est Linux 4.9 avec le correctif temps reel PREEMPT_RT applique pour minimiser la latence de planification, ce qui est essentiel pour une emulation Z80 reactive. L'image systeme complete — bootloader U-boot, noyau Linux, systeme de fichiers racine Buildroot et ensemble applicatif FusionX — est assemblee en utilisant le script Build_FusionX.sh, une version personnalisee du systeme de construction du SDK SigmaStar. Deux cibles de projet sont definies :

• 2D06
  — Configuration personnalisee FusionX utilisant le defconfig noyau infinity2m_spinand_fusionx_defconfig.
• 2D07
  — Configuration de reference standard SigmaStar utilisant infinity2m_spinand_ssc011a_s01a_minigui_defconfig.

Le script de construction est invoque comme suit : Build_FusionX.sh -f nand -p ssd202 -o 2D06 -m 256 et produit une image flash complete prete a etre programmee sur le NAND du SOM. Un aspect cle de la configuration Linux est l'isolation des processeurs. Au demarrage, tous les processus Linux et les IRQ materielles sont migres vers le CPU0. Le CPU1 est ensuite dedie exclusivement au thread noyau kthread_z80 qui execute la boucle d'emulation Z80. Cette separation d'affinite CPU, combinee avec le noyau PREEMPT_RT, donne a l'emulateur Z80 l'acces le plus coherent et la latence la plus faible a l'interface materielle hote. Le gouverneur de performance du processeur est egalement regle a la frequence maximale (1,2 GHz) apres le demarrage de l'emulateur Z80 pour eviter que la mise a l'echelle de frequence ne cause des variations de timing dans la boucle d'emulation. Le systeme de fichiers racine est un environnement Linux minimal base sur Buildroot stocke dans la flash NAND du SOM. Une carte SD optionnelle peut etendre le stockage pour les logiciels d'application Sharp MZ, les images ROM et les utilitaires Linux supplementaires. Lorsqu'une carte SD correctement preparee est presente au demarrage, le SOM effectuera automatiquement une mise a jour a partir de celle-ci, simplifiant les mises a jour de firmware.

L'emulateur Z80 est implemente en tant que module noyau Linux, z80drv.ko (v1.4, avril 2023). Il utilise la bibliotheque d'emulation Z80 Zeta par Manuel Sainz de Baranda y Goni comme coeur de jeu d'instructions Z80, encapsule dans un pilote espace noyau qui s'interface avec le materiel GPIO du SSD202 et l'interface hote Z80 du CPLD. Le chemin materiel du SOM au socle hote Z80 est : SSD202 GPIO / SPI → CPLD → socle Z80 DIP-40. Le CPLD gere la synchronisation precise du bus Z80 en utilisant une horloge de 50 MHz, le module noyau n'a donc pas besoin de reproduire lui-meme la synchronisation precise des T-states. L'interface GPIO est geree par z80io.c, qui appelle le HAL SigmaStar pour l'initialisation mais accede directement aux registres pour les operations de lecture/ecriture au niveau bit afin de minimiser la latence. Le debit de lecture pratique de la structure GPIO du SSD202 est d'environ 2 Mo/s pour un octet 8 bits, ce qui signifie que les programmes s'executent depuis la memoire emulee (noyau) plutot que depuis la memoire hote physique via le bus. L'emulateur prend en charge les machines hotes suivantes, chacune avec son propre module materiel virtuel :

Virtual Hardware Module	Host Machine	Description
z80vhw_mz80a.c	Sharp MZ-80A	Comportement MZ-80A d'origine, aucun ajout
z80vhw_mz700.c	Sharp MZ-700	Comportement MZ-700 d'origine, aucun ajout
z80vhw_mz2000.c	Sharp MZ-2000	Emulation MZ-2000
z80vhw_pcw.c	Amstrad PCW-8256	Emulation PCW-8256
z80vhw_rfs.c	MZ-80A + RFS	Materiel virtuel ROM Filing System pour MZ-80A
z80vhw_tzpu.c	MZ-80A + tranZPUter SW	Materiel virtuel tranZPUter SW ; combine le pilote noyau avec le daemon espace utilisateur k64fcpu

Les modules materiels virtuels sont compiles en ligne dans z80drv.ko plutot que lies comme des objets separes, ce qui elimine la surcharge d'appel de fonction dans le chemin critique de l'emulation. Jusqu'a cinq peripheriques materiels virtuels peuvent etre actifs simultanement (MAX_VIRTUAL_DEVICES 5). Les peripheriques sont ajoutes a l'execution en utilisant z80ctrl --adddev --device <name> avant de demarrer l'emulateur. L'utilitaire z80ctrl fournit un controle complet de l'emulateur a l'execution depuis la ligne de commande Linux :

• --adddev --device <name> — ajouter un peripherique materiel virtuel (rfs, tzpu, mz700, mz80a, mz2000, pcw)
• --start / --stop — demarrer ou arreter la boucle d'emulation Z80
• --loadrom --file <path> --addr <hex> --type <n> — charger une image ROM binaire en memoire emulee
• --mem --addr <hex> --len <n> — inspecter le contenu de la memoire emulee
• --cmd <hex> — envoyer un octet de commande directement a la passerelle CPLD/Z80

Le module ttymzdrv.ko (ttymz.c, v1.2, juillet 2023) fournit une interface TTY Linux standard sur /dev/ttymz0 soutenue par le clavier et l'ecran du Sharp MZ. Cela permet d'utiliser la console de la machine hote comme terminal Linux — en executant une session de connexion getty — tout en supportant la suspension et la reprise pour basculer l'affichage entre Linux et la session d'emulation Z80 sans perdre l'etat. Les hotes supportes sont MZ-80A, MZ-700 et MZ-2000.

La serie tranZPUter a ete initialement developpee dans le Sharp MZ-80A et etait principalement un remplacement du Z80. Au fur et a mesure que le concept evoluait et que le tranZPUter SW-700 etait developpe pour le MZ-700, il est devenu un composant plus integral de la machine, offrant des capacites video et audio originales et ameliorees en interceptant et en routant les signaux existants. Apres des developpements significatifs sur le tranZPUter SW-700, il est devenu souhaitable de le porter sur le MZ-80A et le MZ-2000, mais ces machines avaient une orientation CPU et des exigences de signaux differentes, notamment pour piloter un moniteur interne et externe. Cette exigence a conduit au concept de cartes filles, ou une carte specifique serait concue et developpee pour l'hote cible et se brancherait sur la carte tranZPUter SW-700. Idealement, je voulais porter le SW-700 sur un MZ-800/MZ-1500 et X1 mais la taille de la carte et l'orientation du Z80 etaient une limitation. Lors de la conception du tranZPUter^FusionX, l'une des principales exigences etait de rendre la carte petite, l'orientation du Z80 modifiable et egalement compatible avec le tranZPUter^Fusion afin qu'elle puisse s'adapter a de nombreuses machines et etre interchangeable. Comme le SW-700 s'interfacait egalement avec la video et l'audio des machines et que chacune etait assez differente, il est devenu evident que le tranZPUter^FusionX devait inclure un concept pour permettre differentes interfaces video/audio selon l'hote cible. Ce concept a ete realise via des cartes filles. Deux connecteurs relieraient le tranZPUter^FusionX a une carte fille qui serait specifiquement concue pour l'hote prevu. Les cartes filles seraient responsables de la commutation et du melange des signaux video/audio et de piloter les moniteurs internes et de fournir les connecteurs d'entree et de sortie corrects pour faciliter l'installation. Actuellement, trois cartes filles ont ete developpees, pour le MZ-700, le MZ-80A et le MZ-2000, et d'autres suivront au fur et a mesure de la progression de la conception.

L'objectif de la carte fille MZ-700 est d'interfacer les circuits video/audio de la carte FusionX avec ceux du MZ-700. Elle est concue pour etre inseree dans la sortie modulateur de la carte mere et le connecteur du modulateur est a son tour connecte a la carte fille. Cela permet d'utiliser le MZ-700 avec un moniteur standard et la sortie video est commutee entre le MZ-700 et le FusionX sous le controle du FusionX. Le circuit sonore original du MZ-700 pilote directement un haut-parleur et afin d'injecter l'audio du FusionX dans le haut-parleur du MZ-700, la sortie haut-parleur de la carte mere est routee vers la carte fille, convertie en niveau et commutee sous le controle du FusionX. Le FusionX offre un son stereo, celui-ci est selectivement commute/melange avec le son original du MZ-700 et alimente un amplificateur de classe D qui pilote ensuite le haut-parleur interne. Une sortie stereo de niveau ligne est obtenue via un connecteur supplementaire a 4 broches et utilisee selon les besoins. Cette configuration permet a Linux ou aux machines emulees, lorsqu'elles fonctionnent comme application sur le FusionX, d'envoyer leur son au haut-parleur interne.

La carte fille MZ-700 est composee de trois commutateurs analogiques SPDT 4 voies pour router les signaux video et audio sous controle du FusionX et d'un amplificateur de puissance de classe D.

Le PCB de la carte fille MZ-700 est petit et compact en raison des restrictions d'espace. Il doit s'adapter au connecteur du modulateur existant et dans l'espace libre disponible.

L'objectif de la carte fille MZ-2000 est d'interfacer les circuits video/audio/reset de la carte FusionX avec ceux du MZ-2000. Le MZ-2000 possede un CRT monochrome interne, une sortie video RGB externe et un audio interne avec un amplificateur sur la carte de controle du CRT monochrome. La carte fille est concue pour etre inseree simultanement dans les connecteurs moniteur et IPL de la carte mere. Elle presente tous les connecteurs necessaires pour connecter les interrupteurs IPL/RESET, le moniteur interne et le moniteur externe sur la meme carte. Les entrees IPL et RESET sont interceptees sur la carte fille et envoyees au FusionX car le MZ-2000 fonctionne dans differents modes selon la touche RESET enfoncee pendant un Reset Z80. Les signaux video de la carte mere sont commutes avec les signaux video monochromes du FusionX et envoyes au moniteur CRT interne. Cela permet une sortie video d'origine sur le moniteur CRT ou du texte et des graphismes avances du FusionX, la resolution etant soumise aux contraintes de timing du moniteur. La sortie RGB du FusionX est routee vers la prise video RGB externe du MZ-2000 permettant un affichage video couleur externe jusqu'a la full HD. Le circuit sonore du MZ-2000 est envoye a un amplificateur audio sur le moniteur CRT. Ce signal est intercepte et commute avec l'audio du FusionX qui pilote ensuite l'amplificateur du moniteur CRT. Une sortie stereo de niveau ligne est obtenue via un connecteur supplementaire a 4 broches et utilisee selon les besoins.

La carte fille MZ-2000 est composee de deux commutateurs analogiques SPDT 4 voies pour router les signaux video et audio sous controle du FusionX. Un commutateur SPDT est utilise pour creer un noir pur dans le signal video modifie genere sur la carte FusionX.

Le PCB de la carte fille MZ-2000 est petit et compact en raison des restrictions d'espace et du nombre de connecteurs qu'il doit porter. Il se branche dans les connecteurs males moniteur/IPL de la carte mere et presente ensuite de nouveaux connecteurs pour le moniteur CRT, la video externe et les interrupteurs IPL/RESET pour tout le cablage interne existant.

L'objectif de la carte fille MZ-80A est d'interfacer les circuits video/audio/reset de la carte FusionX avec ceux du MZ-80A. Le MZ-80A possede un CRT monochrome interne, des decoupes pour une prise video RGB externe et un audio interne avec un amplificateur sur la carte de controle du CRT monochrome. La carte fille est concue pour se brancher dans le connecteur video CRT vertical de la carte mere avec un espace permettant la connexion simultanee du connecteur du lecteur de cassette. L'espace est necessaire car le connecteur video CRT est situe pres de la paroi laterale arriere, la carte fille doit donc s'etendre vers l'avant en direction du clavier. Elle presente tous les connecteurs necessaires pour connecter l'interrupteur RESET (entree et sortie), le moniteur interne et le moniteur externe sur la meme carte. L'entree RESET est interceptee sur la carte fille et envoyee au FusionX. Techniquement, ce n'est pas necessaire car le FusionX echantillonne le Reset Z80 qui est base sur cette entree, mais cela peut etre utile, par exemple, pour detecter les demandes de redemarrage du SOM (double pression) plutot que du circuit du MZ-80A. Les signaux video de la carte mere sont commutes avec les signaux video monochromes du FusionX et envoyes au moniteur CRT interne. Cela permet une sortie video d'origine sur le moniteur CRT ou du texte et des graphismes avances du FusionX, la resolution etant soumise aux contraintes de timing du moniteur. La sortie RGB du FusionX est routee vers la prise video RGB externe du MZ-80A (si installee) permettant un affichage video couleur externe jusqu'a la full HD. Le circuit sonore du MZ-80A est envoye a un amplificateur audio sur le moniteur CRT. Ce signal est intercepte et commute avec l'audio du FusionX qui pilote ensuite l'amplificateur du moniteur CRT. Une sortie stereo de niveau ligne est obtenue via un connecteur supplementaire a 4 broches et utilisee selon les besoins.

La carte fille MZ-80A est composee de deux commutateurs analogiques SPDT 4 voies pour router les signaux video et audio sous controle du FusionX. Un commutateur SPDT est utilise pour creer un noir pur dans le signal video modifie genere sur la carte FusionX.

Le PCB de la carte fille MZ-80A est petit et compact avec une grande decoupe pour permettre la connexion avec le connecteur CRT de la carte mere et la connexion traversante du connecteur de signal du lecteur de cassette. Il se branche dans le connecteur moniteur CRT de la carte mere et presente ensuite de nouveaux connecteurs pour le moniteur CRT, la video externe et les interrupteurs RESET entree/sortie a utiliser avec tout le cablage interne existant.

Le tableau ci-dessous contient tous les sites references dans la conception et la programmation du tranZPUter^FusionX

Site	Langue	Description
Z80 Emulation	Anglais	Une emulation Z80 tres precise ecrite en C, le coeur du FusionX.
WhyCan Forum	Chinois	Forum inestimable avec des fils de discussion sur les produits SigmaStar.
SSD20X System Development Manual	Chinois	Manuel de developpement systeme pour le processeur SSD20X.
SigmaStarDocs	Chinois	Manuel de developpement SDK et API.
SOM2D0X Beginners Guide	Chinois	Guide du debutant pour le SOM2D0X.
CivetWeb Users Manual	Anglais	Manuel utilisateur pour le serveur web embarque CivetWeb.

Le tableau ci-dessous contient toutes les fiches techniques et manuels references dans la conception et la programmation du tranZPUter^FusionX

Fiche technique	Langue	Description
ADV7123	Anglais	VideoDAC 30 bits 5V d'origine (discontinue)
GM7123	Chinois	Version chinoise 3,3V du convertisseur VideoDAC 30 bits ADV7123.
CH340E	Chinois	Convertisseur USB vers UART serie.
EPM7512AEQFP144	Anglais	CPLD Altera 512 macrocellules tolerant 5V.
HXJ8002	Anglais	Amplificateur de puissance classe D.
SOM2D01	Anglais	Fiche technique du SOM SigmaStar (modele d'origine).
REF3040	Anglais	Generateur de tension de reference precise 4V.
SY6280	Anglais	Commutateur de distribution d'alimentation, utilise pour activer et fournir l'alimentation du bus USB.
TLC5602C	Anglais	Convertisseur VideoDAC 8 bits.
TLV62569	Anglais	Convertisseur abaisseur haute efficacite.
TMUX1134	Anglais	Commutateur analogique SPDT de precision (Mux).
VCUT0714BHD1	Anglais	Diode de protection ESD.
USB Programmer	Anglais	Programmateur USB SigmaStar pour processeur SSD202.
SSD201 HW Checklist v10	Anglais	Liste de controle materielle SigmaStar SSD201.
SSD202D Reference v04	Anglais	Manuel de reference du processeur SigmaStar SSD202.
SOM2D02_Pinout	Anglais	Brochage du SigmaStar SOM2D02.
Z80 UserManual	Anglais	Manuel utilisateur du Z80.
SSD202D Product Brief	Anglais	Fiche produit du processeur SigmaStar SSD202.
SOM2D01 Datasheet	Anglais	Fiche technique du SigmaStar SOM2D01.

L'avancement du developpement du tranZPUter^FusionX a ete partage sur X (anciennement Twitter) a chaque etape cle atteinte. Les publications ci-dessous documentent les etapes cles de la premiere mise en route materielle jusqu'a l'execution de l'emulation RFS, MZ-700 et MZ-2000 : https://x.com/engineerswork1/status/1579209688495054849
https://x.com/engineerswork1/status/1583918702415577089
https://x.com/engineerswork1/status/1596925535787286528
https://x.com/engineerswork1/status/1616571495957909510
https://x.com/engineerswork1/status/1630985022604804109

L'emulation Z80 utilisee dans le FusionX est (c) 1999-2022 Manuel Sainz de Baranda y Goni, licenciee sous la licence LGPL v3, le code source peut etre trouve sur Gitea. Le systeme de construction SSD202/SOM2D0X est base sur Linux avec des extensions par SigmaStar et Industio, les licences peuvent etre trouvees dans leurs fichiers source mis a jour.

Cette conception, materiel et logiciel (composants attribuables excluant les logiciels licencies separement) est licenciee sous la Licence Publique Generale GNU v3 et libre d'utilisation, d'adaptation et de modification par des individus, des groupes et des instituts educatifs. Aucune utilisation commerciale ne doit etre faite de cette conception ou de tout composant materiel/firmware sans l'autorisation expresse de l'auteur.

Les fichiers source et binaires de ce projet marques comme GPL v3 sont des logiciels libres : vous pouvez les redistribuer et/ou les modifier selon les termes de la Licence Publique Generale GNU telle que publiee par la Free Software Foundation, soit la version 3 de la Licence, soit (a votre choix) toute version ulterieure.

Les fichiers source sont distribues dans l'espoir qu'ils seront utiles, mais SANS AUCUNE GARANTIE ; sans meme la garantie implicite de QUALITE MARCHANDE ou D'ADEQUATION A UN USAGE PARTICULIER. Voir la Licence Publique Generale GNU pour plus de details.

Vous devriez avoir recu une copie de la Licence Publique Generale GNU avec ce programme. Si ce n'est pas le cas, voir http://www.gnu.org/licenses/.

Cet appareil integre un emetteur-recepteur sans fil SSW101B 2,4 GHz IEEE 802.11 b/g/n (integre dans le SOM SigmaStar SSD202), ce qui en fait un emetteur intentionnel au regard des reglementations radiofrequences mondiales (y compris la FCC Part 15 Subpart C aux Etats-Unis et la Directive sur les equipements radioelectriques 2014/53/EU dans l'Union europeenne). Bien que le module SOM porte des certifications reglementaires preexistantes, ces certifications au niveau du module ne s'etendent pas automatiquement a un produit fini qui incorpore le module. L'exemption de module pre-certifie permet aux hobbyistes individuels de construire un nombre limite d'appareils a des fins personnelles, experimentales ou educatives sans obtenir une autorisation d'equipement separee. Limitations importantes

• Les appareils assembles ne doivent pas etre vendus, proposes a la vente, offerts ou autrement distribues a des tiers a moins que le produit fini n'ait ete teste independamment et n'ait obtenu sa propre autorisation d'equipement (par ex. FCC ID, marquage CE avec evaluation par un organisme notifie) dans la juridiction concernee.
• La construction de ce projet a des fins personnelles en quantites limitees est generalement autorisee en vertu des dispositions pour hobbyistes et usage experimental (par ex. FCC § 15.23), a condition que l'appareil ne cause pas d'interference nuisible.
• Les exigences reglementaires varient selon les pays. Les constructeurs en dehors des Etats-Unis doivent consulter leur autorite nationale de radiofrequences pour les regles applicables.

Responsabilite du constructeur
Il est de la seule responsabilite du constructeur de s'assurer que tout appareil construit a partir de ces conceptions est conforme a toutes les reglementations radiofrequences applicables dans sa juridiction. L'auteur fournit ces conceptions a des fins personnelles, educatives et de loisir et ne fait aucune declaration indiquant qu'un appareil construit a partir de celles-ci satisfait aux exigences reglementaires pour la distribution commerciale.