Réunions & Conventions Qu'est ce qu'un MSX0? C'est quoi et comment ça marche?
Bonsoir,
Si vous avez assisté aux présentations de Dr NISHI, ou si vous avez visionné les vidéos de ses présentations au GOTO40 (Hollande/ Pays Bas) et/ou présentations lors des journées J'MSX24 (Paris 11eme).
J'aimerai qu'on se partage ce qu'on en a compris.
Je n'ai pas posé de question à Mr NISHI principalement parce que j'avais beaucoup de questions sur des points techniques et que je ne voulais pas:
1/ Noyer les autres auditeurs avec des détails techniques qu'ils ne jugeraient pas pertinents d'avoir à ce stade du projet.
2/ Ne pas monopoliser le micro et encore moins notre invité.
Je vais donc vous partager ce que j'ai compris ou deviné via les informations et mots clé techniques placées de ci, de là, par Mr NISHI dans ses présentations et les questions que cela soulève dans mon cerveau.
1/ En synthèse , le MSX0 sous toutes ses formes est selon moi une couche logiciel d'émulation compatible logiciellement d'un MSX/MSX2 et peut-être d'un MSX2+.
2/ En plus lui ajoute deux nouvelles ressources matérielles (hardware) qui sont: un contrôleur I2C Master, et une interface WiFi (2.4GHz- non précisée explicitement, mais c'est implicite, vous comprendrez plus loin).
3/ Le contrôleur I2C Master nous donne accès à un bus I2C qui prend la forme d'un connecteur à 4 broches au standard "GROVE" entre autre pour les carte "ARDUINO" et créé par la société "SEEED Studio" (société qui développe et commercialise tout un tas de base de développement pour électroniciens et développeur logiciel)
En français (magasin LEXTRONIC en region parisienne): https://www.lextronic.fr/modules-grove-10529
Le site de SEEED Studio (en anglais): https://www.seeedstudio.com/category/Grove-c-1003.html
le kit du débutant chez SEED: https://wiki.seeedstudio.com/Grove-Beginner-Kit-For-Arduino/
Houlala!!! c'est déjà trop compliqué pour pour un utilisateur lambda !
Aller zou séance de vulgarisation pour qu'il n'y ait pas que le deux génies sur miles élèves qui pigent de quoi on parle. (je paraphrase légèrement une réponse ou un exemple de Mr NISHI lors d'un des "talk" du dimanche)
Alors, pour ceux qui ne sont pas plongés dans le Do It Yourself = DIY (Fait Le Toi-même). Les cartes au standard Arduino et la galaxie des modules "GROVE" de SEEED ou compatible "GROVE" par d'autres sociétés que SEEED, c'est l'équivalent des LEGO appliqué à l'électronique. Mais nous pouvons aussi faire un parallèle avec le monde du MSX...
Et Pour faire simple le concept des cartes Arduino, ce sont différents modèles de carte de base avec un micro-contrôleurs plus ou moins puissants en terme de mémoires et périphérique de bases, un peut comme les si on avait des MSX, MSX2, MSX2+, MSX Turbo-R ST, MSX Turbo-R GT.
Et des modules "GROVE", qui dans le monde MSX prendraient la forme de cartouches MSX MUSIC, FM-PAC, MSX AUDIO, PHILIPS MUSIC MODULE, OPL4, V9990, V9958(pour upgrade MSX vers MSX2+), FUN-RICE, MEGA-SRAM, CANIVORE-2, etc...
Elles ont toutes un point commun: un bus port cartouche au standard MSX.
Elles ont toutes un but: ajouter une ou des ressources (fonctionnalité non disponible sur la configuration initiale).
On peut donc résumer MSX0 comme étant votre configuration de base qui sait déjà dès le départ faire des trucs (liste non exhaustive des principales que j'ai retenu et dans ma mémoire sans consulter la version papier des présentations de Mr NISHI):
- Affichage comme sur un MSX via le petit écran couleur intégré (fonction de la version de MSX0, il y a des version faible consommation sans écran voir juste après)
- Affichage déporté dans une console à distance sur un smartphone, tablette, ou une fenêtre d'application sous Windows/Linux
- Accès à une couche TCP/PI (TCP+UDP), permet de communiquer avec le monde extérieur.
- Accès à un bus I2C via un connecteur "GROVE".
- Un langage MSX BASIC avec de nouvelles fonction pour accéder au mode extérieur à distance (WiFi et la couche de protocole TCP/IP), et au mode extérieur local via le bus I2C.
Explications des petits point de vocabulaire techniques qui reviennent souvent depuis le début de cet article et qui mérites des explications pour ceux qui aiment bien mettre le nez sous la capot pour comprendre comment ça marche...
Alors depuis le début je vous balance du bus I2C, mais sans vous dire ce que c'est que ce machin là.
Plusieurs d'entre vous se contenterons de l'information de base et pourrons se couchez avec juste cette information:
Et la dessus il va aller se coucher et passer sa meilleure nuit
Et puis il y a le petit curieux qui à compris le finalité du bus I2C comme son camarade le "pragmatique", mais lui il est curieux et le pourquoi ça suffit pas, il lui faut savoir le comment et même parfois le comment du comment...
2024-06-25 La suite....C'est bien beau l'I²C, mais quoi comme composant le MSX0?
(Va y père castor mets toi dans ton fauteuil et raconte nous!
spécial dédicace à aoineko )
Vous l'aurez peut-être remarqué sur une des diapo présentée par Mr NISHI, on pouvait voir un ESP32 S3.
Alors pourquoi l'ESP32 S3?
Réponse: tout simplement parce que Mr NISHI nous a expliqué que un MSX doit répondre à certains critères qui sont l'ADN du MSX:
- Une machine bon marché.
- Un système simple à utiliser et sur lequel on peut programmer en BASIC à minima.
- Un MSX c'est une machine pour apprendre ce que c'est un ordinateur, apprendre à programmer, créer ses propre objet IOT.
- Dans un ESP32 il y a un processeur rapide parce que de nos jours il faut allé vite...
Et aussi comme expliqué par Mr NISHI, 40 ans après la création du MSX, les bases matériel du MSX (Z80, VDP, PSG, BASIC) sont toujours une bonne et pertinente base pour:
- Un système simple à comprendre.
- Un système qui permet de comprendre ce que c'est qu'un ordinateur.
- Un système facile à programmer avec son BASIC intégré.
Mais en 2024:
- Il faut un moyen de communiquer avec le reste du monde.
- Il faut un moyen de branché des capteurs et des actionneurs pour créer des IOT.
Et c'est pour toutes ces raisons que l'équipe de Mr NISHI s'est tourné vers un SoC de la société Expressif (société Chinoise).
Je vous colle un petite fiche résumée de la famille ESP32 de chez Expressif
Pour information le système de développement fourni par Expressif c'est une suite logiciel pour programmer en C/C++ avec un noyau temps réel RTOS (Real Time OS).
ESP-IDF (Official IoT development framework)
ESP-Matter SDK (Simplified API and the required tools for building Matter-compatible devices)
ESP-Arduino (Arduino IDE and development support for ESP32)
ESP-AT(AT commands to interface with ESP products)
ESP-HOSTED (Use ESP SoCs as communication co-processors)
ESP-ADF (Official audio development framework)
ESP-Mesh-Lite (Mesh networking solution based on the Wi-Fi protocol)
ESP HomeKit SDK (Apple HomeKit-certified accessory development)
Je ne sais vous dire sur lequel est partie l'équipe de Mr NISHI, je pense que c'est certainement la première.
Bon une fois qu'on a un ESP32 et son SDK (Software Developement Kit), pour info le lien vers leur GITHUB:
https://github.com/espressif
Une fois qu'on a le SDK disais-je, on a accès au ressources de l'ESP32: WiFi, GPIOs (General Purpose IO), SPI, I2S (pour le son), I2C, PWM(pour faire varier l'intensité d'une LED par exemple), ADC and UART, SD/MMC host (port pour carte SD) and TWAI (bus CAN, utiliser en automobile par exemple).
Mais bon c'est toujours pas un MSX ce machin.
Donc ce que je pense que:
Mr NISHI et son équipe, fort de leur expérience passée sur le MSX Player, on fait les choses suivantes (et c'est une des question que je voulais poser):
- Porter MSX Player sur la plateforme de Expressif.
- Ajouter au MSX BASIC les fonctions pour ouvrir une ou des connexions avec le WiFi.
- Ajouter au MSX BASIC les fonctions pour communiquer sur bus I2C.
- Créer un driver pour que la sortie vidéo du MSX se fasse sur un écran LCD relier au bus SPI de l'ESP32.
Précision l'ESP32 c'est un SoC dont le processeurs principal est un processeur RISC: Xtensa® 32-bit LX7 dual-core opérant jusqu'à 240 MHz.
Plus bas je vais poster une suite avec des exemples de ce que j'imagine qu'on pourrais faire avec des MSX0.
Ces exemples sont sur la base de modules de la même famille que l'ESP32 du MSX0 STACK présenté par Mr NISHI. Edité par z80 Le 25/06/2024 à 19h26
Si vous avez assisté aux présentations de Dr NISHI, ou si vous avez visionné les vidéos de ses présentations au GOTO40 (Hollande/ Pays Bas) et/ou présentations lors des journées J'MSX24 (Paris 11eme).
J'aimerai qu'on se partage ce qu'on en a compris.
Je n'ai pas posé de question à Mr NISHI principalement parce que j'avais beaucoup de questions sur des points techniques et que je ne voulais pas:
1/ Noyer les autres auditeurs avec des détails techniques qu'ils ne jugeraient pas pertinents d'avoir à ce stade du projet.
2/ Ne pas monopoliser le micro et encore moins notre invité.
Je vais donc vous partager ce que j'ai compris ou deviné via les informations et mots clé techniques placées de ci, de là, par Mr NISHI dans ses présentations et les questions que cela soulève dans mon cerveau.
1/ En synthèse , le MSX0 sous toutes ses formes est selon moi une couche logiciel d'émulation compatible logiciellement d'un MSX/MSX2 et peut-être d'un MSX2+.
2/ En plus lui ajoute deux nouvelles ressources matérielles (hardware) qui sont: un contrôleur I2C Master, et une interface WiFi (2.4GHz- non précisée explicitement, mais c'est implicite, vous comprendrez plus loin).
3/ Le contrôleur I2C Master nous donne accès à un bus I2C qui prend la forme d'un connecteur à 4 broches au standard "GROVE" entre autre pour les carte "ARDUINO" et créé par la société "SEEED Studio" (société qui développe et commercialise tout un tas de base de développement pour électroniciens et développeur logiciel)
En français (magasin LEXTRONIC en region parisienne): https://www.lextronic.fr/modules-grove-10529
Le site de SEEED Studio (en anglais): https://www.seeedstudio.com/category/Grove-c-1003.html
le kit du débutant chez SEED: https://wiki.seeedstudio.com/Grove-Beginner-Kit-For-Arduino/
Houlala!!! c'est déjà trop compliqué pour pour un utilisateur lambda !
Aller zou séance de vulgarisation pour qu'il n'y ait pas que le deux génies sur miles élèves qui pigent de quoi on parle. (je paraphrase légèrement une réponse ou un exemple de Mr NISHI lors d'un des "talk" du dimanche)
Alors, pour ceux qui ne sont pas plongés dans le Do It Yourself = DIY (Fait Le Toi-même). Les cartes au standard Arduino et la galaxie des modules "GROVE" de SEEED ou compatible "GROVE" par d'autres sociétés que SEEED, c'est l'équivalent des LEGO appliqué à l'électronique. Mais nous pouvons aussi faire un parallèle avec le monde du MSX...
Et Pour faire simple le concept des cartes Arduino, ce sont différents modèles de carte de base avec un micro-contrôleurs plus ou moins puissants en terme de mémoires et périphérique de bases, un peut comme les si on avait des MSX, MSX2, MSX2+, MSX Turbo-R ST, MSX Turbo-R GT.
Et des modules "GROVE", qui dans le monde MSX prendraient la forme de cartouches MSX MUSIC, FM-PAC, MSX AUDIO, PHILIPS MUSIC MODULE, OPL4, V9990, V9958(pour upgrade MSX vers MSX2+), FUN-RICE, MEGA-SRAM, CANIVORE-2, etc...
Elles ont toutes un point commun: un bus port cartouche au standard MSX.
Elles ont toutes un but: ajouter une ou des ressources (fonctionnalité non disponible sur la configuration initiale).
On peut donc résumer MSX0 comme étant votre configuration de base qui sait déjà dès le départ faire des trucs (liste non exhaustive des principales que j'ai retenu et dans ma mémoire sans consulter la version papier des présentations de Mr NISHI):
- Affichage comme sur un MSX via le petit écran couleur intégré (fonction de la version de MSX0, il y a des version faible consommation sans écran voir juste après)
- Affichage déporté dans une console à distance sur un smartphone, tablette, ou une fenêtre d'application sous Windows/Linux
- Accès à une couche TCP/PI (TCP+UDP), permet de communiquer avec le monde extérieur.
- Accès à un bus I2C via un connecteur "GROVE".
- Un langage MSX BASIC avec de nouvelles fonction pour accéder au mode extérieur à distance (WiFi et la couche de protocole TCP/IP), et au mode extérieur local via le bus I2C.
Explications des petits point de vocabulaire techniques qui reviennent souvent depuis le début de cet article et qui mérites des explications pour ceux qui aiment bien mettre le nez sous la capot pour comprendre comment ça marche...
Alors depuis le début je vous balance du bus I2C, mais sans vous dire ce que c'est que ce machin là.
Plusieurs d'entre vous se contenterons de l'information de base et pourrons se couchez avec juste cette information:
L'info pour pragmatique :
Le MSX0 possède un bus "I2C" et comme pour notre bon vieux MSX, ce bus I2C nous permet de lui ajouter des modules avec un connecteur standard "GROVE" comme nos bonne vieille cartouches sur MSX
Et la dessus il va aller se coucher et passer sa meilleure nuit
Et puis il y a le petit curieux qui à compris le finalité du bus I2C comme son camarade le "pragmatique", mais lui il est curieux et le pourquoi ça suffit pas, il lui faut savoir le comment et même parfois le comment du comment...
Le curieux :
Alors pour toi amis curieux, le bus I2C à été créer par PHILIPS Semi conducteurs qui autour de l'an 2000 c'est transformé en NXP et qui aujourd'hui à encore changé de nom et n'appartient plus à PHILIPS. (C'est pour cette raison que Mr NISHI à dit dans une de ses réponses suite à une question sur les éventuels soutient des partenaires historique du MSX, il a dit que PHILIPS n'était plus un acteur dans le monde des semi-conducteurs).
Bref, fin de parenthèse "la petite histoire dans l'histoire du bus I2C
Je disais donc avant d'être interrompu par moi même, dans les années 80 l’électronique dite "discrète" à base transistor cède de plus en plus la place à des circuits intégrés (le puces électroniques).
Bâh oui, parce que en miniaturisant les transistors pour les regrouper dans des puces, les circuits imprimés on réduits en tailles, mais en contrepartie on à ajouté des fonctions en ajoutant de nouvelles puces.
Ces puces elles mêmes de plus en plus petites sont donc regroupées pour former d'autres puces qui forme des micro processeurs. Mais un micro processeur il lui faut de la ROM et de la RAM donc d'autres puces qui on besoin de bus d'adresse, de bus de donnée, de bus de contrôle.
Tous ces bus c'est de la places en plus sur les circuit imprimés! et ça coute cher les circuit imprimés...
Donc on invente les micro-contrôleurs (une puce avec dans un même boîtier un processeur, la ROM, la RAM,et des interfaces et autre fonctions dédiées, mais tout ne peu pas encore être intégré dans une seule puce.
A cette époque PHILIPS fait c'est puces mais il fait aussi des produit finis comme par exemple des TV, chaine HiFI, lecteur radio K7, puis radio K7 et CD etc...
Exemple de fonctions dédiées autour du micro-contrôleur:
circuit syntoniseur de fréquence (on envoie la fréquence de la chaîne TV sur l'I2C et le synthoniseur se cale sur la bonne fréquence), circuit intégré audio avec correction de grave, médium, aïgue, balance droite/gauche, effet son 3D spatial, etc... via l'I2C on règle le volume et les préférences de tonalité...)
Relier toutes c'est puces entre elles demande beaucoup trop de fils ou plutôt de piste de cuivre sur des circuits imprimés. On a des bus de données, des bus de contrôle, et 1, 2 3 ou 4 bit d'adresses pour sélectionner les registres des puces autour du micro-contrôleur principal.
Et c'est nouvelles puces devaient être pilotées par un microcontrôleur
C'est là que les ingénieurs de PHILIPS (sous la contrainte de la réduction des coûts de fabrication des circuits imprimés en réduisant leurs tailles)
Ils aboutissent à la même conclusion que les ingénieurs du concurrent Américain MOTOROLA: il nous faut un bus série pour transporter les données que nous voulons lire ou envoyer à nos puces de fonctions annexes.
Donc chez MOTOROLA ils vont créer le bus SPI qui signifie "Serial Peripheral Interface bus" (bus d'interface série périphérique).
Et chez PHILIPS ils vont créer le bus IIC ou I²C (qu'on note aussi I2C) qui signifie "Inter IC Communication" (Communication Entre Circuit-Intégré).
Les topologies
SPI = 4 fils (CLK, MISO, MOSI, CS)
I2C = 2 fils (SCL, SDA)
Les signaux:
SCK = horloge, ce signale cadence l'envoie/réception des bits
MISO: Master In Slave Out (donnée Esclave vers Maître)
MOSI: Master Out Salve IN (donnée Maître vers Esclave)
CS: Chip Select (Sélection du composant) pour lui dire: "c'est à toi que je parle".
SCL = horloge, ce signale cadence l'envoie/réception des bits
SDA = bit de données/d'adresse selon l'étape dans le protocole I2C
Les différences:
SPI est full duplexe = on envoi et on reçoit en même temps. besoin d'un signal CS dédié à chaque esclave pour lui que c'est à lui qu'on "parle".
I2C est half duplexe = on envoi puis on reçoit. plus une séquence de START, de STOP et de ACKNOLEDGE, normalement un seul Maître mais possible en Multi Maître. Pas de CS comme sur SPI, alors les premiers bit envoyés sur le bus sont les 7 bits d'adresse et le bit R/W (lecture/écriture).
Les vitesses:
SPI: 1, 2 MHz puis jusqu'à 25MHZ et plus sur les dernières définitions.
I2C: standard 100KHz, fast 400KHz, et plus récemment 1MHz.
Bref, fin de parenthèse "la petite histoire dans l'histoire du bus I2C
Je disais donc avant d'être interrompu par moi même, dans les années 80 l’électronique dite "discrète" à base transistor cède de plus en plus la place à des circuits intégrés (le puces électroniques).
Bâh oui, parce que en miniaturisant les transistors pour les regrouper dans des puces, les circuits imprimés on réduits en tailles, mais en contrepartie on à ajouté des fonctions en ajoutant de nouvelles puces.
Ces puces elles mêmes de plus en plus petites sont donc regroupées pour former d'autres puces qui forme des micro processeurs. Mais un micro processeur il lui faut de la ROM et de la RAM donc d'autres puces qui on besoin de bus d'adresse, de bus de donnée, de bus de contrôle.
Tous ces bus c'est de la places en plus sur les circuit imprimés! et ça coute cher les circuit imprimés...
Donc on invente les micro-contrôleurs (une puce avec dans un même boîtier un processeur, la ROM, la RAM,et des interfaces et autre fonctions dédiées, mais tout ne peu pas encore être intégré dans une seule puce.
A cette époque PHILIPS fait c'est puces mais il fait aussi des produit finis comme par exemple des TV, chaine HiFI, lecteur radio K7, puis radio K7 et CD etc...
Exemple de fonctions dédiées autour du micro-contrôleur:
circuit syntoniseur de fréquence (on envoie la fréquence de la chaîne TV sur l'I2C et le synthoniseur se cale sur la bonne fréquence), circuit intégré audio avec correction de grave, médium, aïgue, balance droite/gauche, effet son 3D spatial, etc... via l'I2C on règle le volume et les préférences de tonalité...)
Relier toutes c'est puces entre elles demande beaucoup trop de fils ou plutôt de piste de cuivre sur des circuits imprimés. On a des bus de données, des bus de contrôle, et 1, 2 3 ou 4 bit d'adresses pour sélectionner les registres des puces autour du micro-contrôleur principal.
Et c'est nouvelles puces devaient être pilotées par un microcontrôleur
C'est là que les ingénieurs de PHILIPS (sous la contrainte de la réduction des coûts de fabrication des circuits imprimés en réduisant leurs tailles)
Ils aboutissent à la même conclusion que les ingénieurs du concurrent Américain MOTOROLA: il nous faut un bus série pour transporter les données que nous voulons lire ou envoyer à nos puces de fonctions annexes.
Donc chez MOTOROLA ils vont créer le bus SPI qui signifie "Serial Peripheral Interface bus" (bus d'interface série périphérique).
Et chez PHILIPS ils vont créer le bus IIC ou I²C (qu'on note aussi I2C) qui signifie "Inter IC Communication" (Communication Entre Circuit-Intégré).
Les topologies
SPI = 4 fils (CLK, MISO, MOSI, CS)
I2C = 2 fils (SCL, SDA)
Les signaux:
SCK = horloge, ce signale cadence l'envoie/réception des bits
MISO: Master In Slave Out (donnée Esclave vers Maître)
MOSI: Master Out Salve IN (donnée Maître vers Esclave)
CS: Chip Select (Sélection du composant) pour lui dire: "c'est à toi que je parle".
SCL = horloge, ce signale cadence l'envoie/réception des bits
SDA = bit de données/d'adresse selon l'étape dans le protocole I2C
Les différences:
SPI est full duplexe = on envoi et on reçoit en même temps. besoin d'un signal CS dédié à chaque esclave pour lui que c'est à lui qu'on "parle".
I2C est half duplexe = on envoi puis on reçoit. plus une séquence de START, de STOP et de ACKNOLEDGE, normalement un seul Maître mais possible en Multi Maître. Pas de CS comme sur SPI, alors les premiers bit envoyés sur le bus sont les 7 bits d'adresse et le bit R/W (lecture/écriture).
Les vitesses:
SPI: 1, 2 MHz puis jusqu'à 25MHZ et plus sur les dernières définitions.
I2C: standard 100KHz, fast 400KHz, et plus récemment 1MHz.
2024-06-25 La suite....C'est bien beau l'I²C, mais quoi comme composant le MSX0?
(Va y père castor mets toi dans ton fauteuil et raconte nous!
spécial dédicace à aoineko )Vous l'aurez peut-être remarqué sur une des diapo présentée par Mr NISHI, on pouvait voir un ESP32 S3.
Alors pourquoi l'ESP32 S3?
Réponse: tout simplement parce que Mr NISHI nous a expliqué que un MSX doit répondre à certains critères qui sont l'ADN du MSX:
- Une machine bon marché.
- Un système simple à utiliser et sur lequel on peut programmer en BASIC à minima.
- Un MSX c'est une machine pour apprendre ce que c'est un ordinateur, apprendre à programmer, créer ses propre objet IOT.
- Dans un ESP32 il y a un processeur rapide parce que de nos jours il faut allé vite...
Et aussi comme expliqué par Mr NISHI, 40 ans après la création du MSX, les bases matériel du MSX (Z80, VDP, PSG, BASIC) sont toujours une bonne et pertinente base pour:
- Un système simple à comprendre.
- Un système qui permet de comprendre ce que c'est qu'un ordinateur.
- Un système facile à programmer avec son BASIC intégré.
Mais en 2024:
- Il faut un moyen de communiquer avec le reste du monde.
- Il faut un moyen de branché des capteurs et des actionneurs pour créer des IOT.
Et c'est pour toutes ces raisons que l'équipe de Mr NISHI s'est tourné vers un SoC de la société Expressif (société Chinoise).
Je vous colle un petite fiche résumée de la famille ESP32 de chez Expressif
Pour information le système de développement fourni par Expressif c'est une suite logiciel pour programmer en C/C++ avec un noyau temps réel RTOS (Real Time OS).
ESP-IDF (Official IoT development framework)
ESP-Matter SDK (Simplified API and the required tools for building Matter-compatible devices)
ESP-Arduino (Arduino IDE and development support for ESP32)
ESP-AT(AT commands to interface with ESP products)
ESP-HOSTED (Use ESP SoCs as communication co-processors)
ESP-ADF (Official audio development framework)
ESP-Mesh-Lite (Mesh networking solution based on the Wi-Fi protocol)
ESP HomeKit SDK (Apple HomeKit-certified accessory development)
Je ne sais vous dire sur lequel est partie l'équipe de Mr NISHI, je pense que c'est certainement la première.
Bon une fois qu'on a un ESP32 et son SDK (Software Developement Kit), pour info le lien vers leur GITHUB:
https://github.com/espressif
Une fois qu'on a le SDK disais-je, on a accès au ressources de l'ESP32: WiFi, GPIOs (General Purpose IO), SPI, I2S (pour le son), I2C, PWM(pour faire varier l'intensité d'une LED par exemple), ADC and UART, SD/MMC host (port pour carte SD) and TWAI (bus CAN, utiliser en automobile par exemple).
Mais bon c'est toujours pas un MSX ce machin.
Donc ce que je pense que:
Mr NISHI et son équipe, fort de leur expérience passée sur le MSX Player, on fait les choses suivantes (et c'est une des question que je voulais poser):
- Porter MSX Player sur la plateforme de Expressif.
- Ajouter au MSX BASIC les fonctions pour ouvrir une ou des connexions avec le WiFi.
- Ajouter au MSX BASIC les fonctions pour communiquer sur bus I2C.
- Créer un driver pour que la sortie vidéo du MSX se fasse sur un écran LCD relier au bus SPI de l'ESP32.
Précision l'ESP32 c'est un SoC dont le processeurs principal est un processeur RISC: Xtensa® 32-bit LX7 dual-core opérant jusqu'à 240 MHz.
Plus bas je vais poster une suite avec des exemples de ce que j'imagine qu'on pourrais faire avec des MSX0.
Ces exemples sont sur la base de modules de la même famille que l'ESP32 du MSX0 STACK présenté par Mr NISHI. Edité par z80 Le 25/06/2024 à 19h26
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
aoineko :
Merci père z80 pour tes belles histoires (et je pense avoir à peu près tout compris 
). 
). A propos, je tiens à te présenter quelques excuses pour t'avoir dégradé la présentation avec mes commentaires techniques sur les couches sous-jacentes du MSX0...
"Père z80, ça me fait penser à:
Citation :
père castor.... raconte nous une histoire, père castor....
Bon journée à toutes et tous.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
z80 :
"Père z80, ça me fait penser à:
Citation :
père castor.... raconte nous une histoire, père castor....
C'est bien la réf.
On est toujours ignorant avant de savoir.
Premier Tests du MSX0 sans documentation 
réussi a lancer les 2 jeux fournis avec Zanac et Pai Panic
le petit écran à une bonne définition et est bien lisible
je me suis perdu dans le fonctionnemet du menu avec l'écran tactile
j'ai trouvé un site avec une doc
j'étudie et je reviens ......
réussi a lancer les 2 jeux fournis avec Zanac et Pai Panic
le petit écran à une bonne définition et est bien lisible
je me suis perdu dans le fonctionnemet du menu avec l'écran tactile
j'ai trouvé un site avec une doc
j'étudie et je reviens ......
Jipe :
j'étudie et je reviens ......
J'aimerai beaucoup des infos techniques sur le support des capteurs Grove.
En tant que développeur de jeu (et de librairie de jeu), c'est clairement la fonctionnalité qui m'intéresse le plus.
Pouvoir faire un jeu qui utilise un gyroscope, un accéléromètre, un potentiomètre, un capteur de pression, etc., ça ouvre un nombre infini d'expériences de jeu !!
D'ailleurs, ne le dite pas à Nishi, mais perso ce que j’achèterai les yeux fermés, c'est pas tant ses MSX0/3, mais plutôt une cartouche pour nos bons vieux MSX qui permet de connecter des capteurs Grove dessus.
J'avais espéré que ça puisse être le cas avec la cartouche MSX0 pour MSX, mais de ce que j'ai compris, toute la logique sera dans la cartouche MSX0 et le MSX ne servira que de driver pour le clavier et d'alim.
Peut-être qu'en la mettant dans le port 2, on pourrait avoir des jeux cartouches qui puisse accéder aux capteurs Grove de la cartouche MSX0, mais si Nishi n'a pas prévu de porte d'entrée dans ce sens, j'imagine que c'est mort. Edité par aoineko Le 25/06/2024 à 14h01
On est toujours ignorant avant de savoir.
les docs en PDF sont dans la micro-sd fournie avec mais bien sur tout est en japonais
c'est pas du pensé pour le marché international au départ
le lien que j'ai trouvé sur le net : https://qiita.com/ht_deko/items/cdb1594e9879a5e9e660
c'est pas du pensé pour le marché international au départ
le lien que j'ai trouvé sur le net : https://qiita.com/ht_deko/items/cdb1594e9879a5e9e660
Je vais vous présenter ci-dessous quelques exemples d'IOT que vous pourriez certainement développer avec des MSX0 STACK.
Du moins que je pense pouvoir être développées, vu que comme vous je n'ai pas les spécifications complètes du MSX0.
Ce premier exemple n'utilise pas un ESP32, mais son frère aînée en quelque sorte
c'est un ESP8266, il est encore utilisé de nos jours, on le trouve dans une version "one chip" (en lieu et place d'un module), vous le trouverez dans des multiprises compatible Alexa et Google Home sur Amazon.fr ou au shop en ligne.
Voici donc un petit montage fait par bibi, une version WiFi et compatible Linky, j'en avais fait un pour les ancien compteur EDF blanc avec afficheur LCD et les deux boutons bleu...
Celui-ci ne fait pas tourner un micro contrôleur dsPIC avec du code assembleur pour communiquer sur port série et n'est pas connecter à un micro serveur Linux répondant au nom de R2D2...
Non, cette version modernisé, fait tourné du code écrit en C développé dans un environnement Arduino et fait appel à la librairie "PubSubClient" pour se connecter à un serveur MQTT.
Bon, j’ vous en ai mis plein la tête avec des terme qui font (ou peuvent) faire peur, mais pas d’inquiétude, je vousdédramatise ça explique plus tard
Autre exemple:
Mesurer des températures d'entrée et sortie de la VMC double flux....
Là aussi, le principe est simple:
1 - se faire réveiller par le réveil.
2 - faire l’acquisition de données physique à intervalles réguliers.
3 - envoyer les données au serveur MQTT..
4 - régler son réveil.
5 - tout éteindre et dormir.
Vous avez une piscine et voulez surveiller quelques paramètres en restant dans le canapé sans vous rendre dans la cabane de filtration, pouvoir activer la pompe selon certains paramètres, mais aussi en plus mettre tout ça avoir un afficheur quand vous êtes dehors près de la piscine.
C'est possible aussi... Cette fois ci c'est sur base d'un ESP32 WROOM 32U... Le tout dans un boitier en ABS avec couvercle transparent (sinon on peut pas voir l'afficheur )
Vous noterez que la spécificité de la version avec un "U" à la fin c'est parce qu'il est équipé d'un connecteur miniature pour relier une antenne extérieure, les versions plus rependues/courantes sont celles avec un "S" à la fin.
Ce système prototype est pour le moment en cours de modification suite à une mauvaise conception de la carte par nous amis électroniciens chinois.
En effet ils ont omis un circuit de RESET digne de ce nom, résultat des courses:
Si tu te chauffe un peut trop sur les énergie renouvelables et que tu décide que ton système va fonctionner avec un panneau solaire et une batterie Lithium pour la nuit et les journées pluvieuses, il va arriver un moment ou si ta tension descend sous les 2,45V, ton système va faire des RESET et surtout faire n'importe quoi entre le CPU RISC et la mémoire FLASH sur bus QSPI qui contient ton code ARDUINO. Et tu fini par planter ton module...
Une autre application sympathique: faire un petit machin qui reçoit les capteurs météo des station sans fil et envoie les données ainsi reçues sur un serveur MQTT.
Edité par z80 Le 25/06/2024 à 19h24
Du moins que je pense pouvoir être développées, vu que comme vous je n'ai pas les spécifications complètes du MSX0.
Ce premier exemple n'utilise pas un ESP32, mais son frère aînée en quelque sorte
c'est un ESP8266, il est encore utilisé de nos jours, on le trouve dans une version "one chip" (en lieu et place d'un module), vous le trouverez dans des multiprises compatible Alexa et Google Home sur Amazon.fr ou au shop en ligne.Voici donc un petit montage fait par bibi, une version WiFi et compatible Linky, j'en avais fait un pour les ancien compteur EDF blanc avec afficheur LCD et les deux boutons bleu...
Celui-ci ne fait pas tourner un micro contrôleur dsPIC avec du code assembleur pour communiquer sur port série et n'est pas connecter à un micro serveur Linux répondant au nom de R2D2...
Non, cette version modernisé, fait tourné du code écrit en C développé dans un environnement Arduino et fait appel à la librairie "PubSubClient" pour se connecter à un serveur MQTT.
Bon, j’ vous en ai mis plein la tête avec des terme qui font (ou peuvent) faire peur, mais pas d’inquiétude, je vous
Autre exemple:
Mesurer des températures d'entrée et sortie de la VMC double flux....
Là aussi, le principe est simple:
1 - se faire réveiller par le réveil.
2 - faire l’acquisition de données physique à intervalles réguliers.
3 - envoyer les données au serveur MQTT..
4 - régler son réveil.
5 - tout éteindre et dormir.
Vous avez une piscine et voulez surveiller quelques paramètres en restant dans le canapé sans vous rendre dans la cabane de filtration, pouvoir activer la pompe selon certains paramètres, mais aussi en plus mettre tout ça avoir un afficheur quand vous êtes dehors près de la piscine.
C'est possible aussi... Cette fois ci c'est sur base d'un ESP32 WROOM 32U... Le tout dans un boitier en ABS avec couvercle transparent (sinon on peut pas voir l'afficheur
)Vous noterez que la spécificité de la version avec un "U" à la fin c'est parce qu'il est équipé d'un connecteur miniature pour relier une antenne extérieure, les versions plus rependues/courantes sont celles avec un "S" à la fin.
Ce système prototype est pour le moment en cours de modification suite à une mauvaise conception de la carte par nous amis électroniciens chinois.
En effet ils ont omis un circuit de RESET digne de ce nom, résultat des courses:
Si tu te chauffe un peut trop sur les énergie renouvelables et que tu décide que ton système va fonctionner avec un panneau solaire et une batterie Lithium pour la nuit et les journées pluvieuses, il va arriver un moment ou si ta tension descend sous les 2,45V, ton système va faire des RESET et surtout faire n'importe quoi entre le CPU RISC et la mémoire FLASH sur bus QSPI qui contient ton code ARDUINO. Et tu fini par planter ton module...
Une autre application sympathique: faire un petit machin qui reçoit les capteurs météo des station sans fil et envoie les données ainsi reçues sur un serveur MQTT.
Edité par z80 Le 25/06/2024 à 19h24
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Qu'est que MQTT:
(source Wikipédia):
MQTT (initialement Message Queuing Telemetry Transport) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP.
Maintenant je vais tenter de vous le résumer simplement:
1 - Imaginez que vos capteurs sur base de MSX0 / MSX0 STACK sont des reporters de presse.
2 - L'agence de presse collecte tous les articles publiés par ses reporters et les envoie à ses abonnés selon les sujets auxquels ceux-ci on souscrits.
3 - Vous êtes un lecteur abonné à l'agence de presse et vous êtes intéressé uniquement par certains sujets uniquement parmi tous ceux proposés par l'agence de presse.
Un serveur MQTT c'est pas plus compliqué que ça. C'est une des implémentations possibles de ce que Mr NISHI à qualifié de "Cloud" lors de ses présentations.
Il peut y avoir d'autres façons de faire mais c'est la plus légère à ma connaissance et elle offre aussi la possibilité d'avoir un serveur privé chez vous.
Vos données restent donc à votre main.
Petite subtilité du protocole MQTT: dans mon exemple ci-dessus j'ai parlé de reporter et de lecteur abonné, dans le protocole MQTT ils portent tous les deux le nom de client.
Encore plus fort, en tant que client on à la fois être "reporter" et "lecteur abonné".
Exemple:
Dans un article précédent sur les exemples de projet IOT sur base d'ESP32, je vous est montré un projet de relevé de température à distance de la température d'eau de la piscine.
Le rôle de "reporter" est utilisé pour transmettre à intervalles réguliers les températures d'eau, d'air ambiant du local filtration et air entrée du puits canadien.
Mais rien ne m'interdit d'ajouter un rôle de "lecteur abonné" à fin de recevoir l'ordre de piloter l'activation/désactivation de la pompe de la piscine.
Illustrations:
A titre personnel, j'utilise une version libre et ouverte: Mosquitto-MQTT
Info complémentaires sur l'historique (Wiki) et les termes de vocabulaire pour briller dans les diners
Historique
Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom, Eurotech et Cirrus Link) sont les auteurs de la première version du protocole en 1999 qui a servi à surveiller un oléoduc dans le désert. L'objectif était d'avoir un protocole efficace en bande passante, léger et utilisant peu d'énergie de batterie, car la liaison satellite qu'ils utilisaient était très coûteuse à cette époque.(source Wiki)
Vocabulaire:
Agents MQTT:
Les agents MQTT sont des logiciels ou des composants qui fonctionnent en tant que clients MQTT ou brokers MQTT dans une architecture MQTT.
Les deux types d'agents MQTT :
Client MQTT : Un client MQTT est un agent qui se connecte à un broker MQTT pour publier des messages, s'abonner à des sujets et recevoir des messages publiés par d'autres clients. Les clients MQTT peuvent être des dispositifs IoT, des applications web, des applications mobiles ou tout autre logiciel capable de communiquer via le protocole MQTT. Ils sont souvent déployés dans des environnements où la communication à faible bande passante et la fiabilité sont essentielles, tels que les réseaux IoT.
Broker MQTT : Un broker MQTT est un agent qui reçoit les messages publiés par les clients MQTT et les transmet aux clients abonnés aux sujets correspondants. Il agit comme un serveur centralisé qui facilite la communication entre les clients MQTT. Les brokers MQTT peuvent être déployés dans le cloud, sur des serveurs locaux ou sur des dispositifs IoT eux-mêmes. Ils sont responsables de la gestion des connexions des clients, de la distribution des messages et de la mise en œuvre des politiques de sécurité.
Il est important de noter que dans une architecture MQTT typique, il peut y avoir plusieurs clients MQTT et un ou plusieurs brokers MQTT. Les clients peuvent publier des messages sur différents sujets, et les brokers sont responsables de la distribution de ces messages aux clients abonnés aux sujets correspondants. Cette architecture distribuée et légère fait de MQTT un choix populaire pour les applications IoT et les systèmes de messagerie en temps réel.
Les principaux agents open-source sont :
ActiveMQ (en)
ejabberd
JoramMQ, OW2 JORAM
Mosquitto
Edité par z80 Le 25/06/2024 à 22h24
(source Wikipédia):
MQTT (initialement Message Queuing Telemetry Transport) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP.
Maintenant je vais tenter de vous le résumer simplement:
1 - Imaginez que vos capteurs sur base de MSX0 / MSX0 STACK sont des reporters de presse.
2 - L'agence de presse collecte tous les articles publiés par ses reporters et les envoie à ses abonnés selon les sujets auxquels ceux-ci on souscrits.
3 - Vous êtes un lecteur abonné à l'agence de presse et vous êtes intéressé uniquement par certains sujets uniquement parmi tous ceux proposés par l'agence de presse.
Un serveur MQTT c'est pas plus compliqué que ça. C'est une des implémentations possibles de ce que Mr NISHI à qualifié de "Cloud" lors de ses présentations.
Il peut y avoir d'autres façons de faire mais c'est la plus légère à ma connaissance et elle offre aussi la possibilité d'avoir un serveur privé chez vous.
Vos données restent donc à votre main.
Petite subtilité du protocole MQTT: dans mon exemple ci-dessus j'ai parlé de reporter et de lecteur abonné, dans le protocole MQTT ils portent tous les deux le nom de client.
Encore plus fort, en tant que client on à la fois être "reporter" et "lecteur abonné".
Exemple:
Dans un article précédent sur les exemples de projet IOT sur base d'ESP32, je vous est montré un projet de relevé de température à distance de la température d'eau de la piscine.
Le rôle de "reporter" est utilisé pour transmettre à intervalles réguliers les températures d'eau, d'air ambiant du local filtration et air entrée du puits canadien.
Mais rien ne m'interdit d'ajouter un rôle de "lecteur abonné" à fin de recevoir l'ordre de piloter l'activation/désactivation de la pompe de la piscine.
Illustrations:
A titre personnel, j'utilise une version libre et ouverte: Mosquitto-MQTT
Info complémentaires sur l'historique (Wiki) et les termes de vocabulaire pour briller dans les diners
Historique
Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom, Eurotech et Cirrus Link) sont les auteurs de la première version du protocole en 1999 qui a servi à surveiller un oléoduc dans le désert. L'objectif était d'avoir un protocole efficace en bande passante, léger et utilisant peu d'énergie de batterie, car la liaison satellite qu'ils utilisaient était très coûteuse à cette époque.(source Wiki)
Vocabulaire:
Agents MQTT:
Les agents MQTT sont des logiciels ou des composants qui fonctionnent en tant que clients MQTT ou brokers MQTT dans une architecture MQTT.
Les deux types d'agents MQTT :
Client MQTT : Un client MQTT est un agent qui se connecte à un broker MQTT pour publier des messages, s'abonner à des sujets et recevoir des messages publiés par d'autres clients. Les clients MQTT peuvent être des dispositifs IoT, des applications web, des applications mobiles ou tout autre logiciel capable de communiquer via le protocole MQTT. Ils sont souvent déployés dans des environnements où la communication à faible bande passante et la fiabilité sont essentielles, tels que les réseaux IoT.
Broker MQTT : Un broker MQTT est un agent qui reçoit les messages publiés par les clients MQTT et les transmet aux clients abonnés aux sujets correspondants. Il agit comme un serveur centralisé qui facilite la communication entre les clients MQTT. Les brokers MQTT peuvent être déployés dans le cloud, sur des serveurs locaux ou sur des dispositifs IoT eux-mêmes. Ils sont responsables de la gestion des connexions des clients, de la distribution des messages et de la mise en œuvre des politiques de sécurité.
Il est important de noter que dans une architecture MQTT typique, il peut y avoir plusieurs clients MQTT et un ou plusieurs brokers MQTT. Les clients peuvent publier des messages sur différents sujets, et les brokers sont responsables de la distribution de ces messages aux clients abonnés aux sujets correspondants. Cette architecture distribuée et légère fait de MQTT un choix populaire pour les applications IoT et les systèmes de messagerie en temps réel.
Les principaux agents open-source sont :
ActiveMQ (en)
ejabberd
JoramMQ, OW2 JORAM
Mosquitto
Edité par z80 Le 25/06/2024 à 22h24
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie