SYNTHELECTRO : synthesizers, electronic, retro-computing, etc...
mardi 28 novembre 2017
Changement d'adresse mail de contact.
Parce qu'à un moment il faut quand même se résoudre à quitter le service mail de Yahoo pour quelque chose d'un peu plus efficace, j'ai donc ouvert une nouvelle boîte mail chez netcourrier.com :
lundi 6 novembre 2017
JX10P, MKS70...
Ceci n'est pas un article à proprement parlé mais juste un petit 'pense bête' concernant le synthétiseur Roland JX10P :
J'ai eu l'occasion par le passé, de m'intéresser à cette machine lors de la remise en état de l'exemplaire que je possède, et force est de constater qu'il y a aujourd'hui un bon nombre de nouvelles améliorations disponibles. Elles sont assez bien résumées sur cette page, que je mets donc en référence http://super-jx.com :
 |
| http://super-jx.com |
ou ici pour les dernières nouveautés JX10P News.
RETROAKTIV PG-800 MINI Bare PCB & Overlay Kit for JX-8P & Super JX :
samedi 21 octobre 2017
Ecran tactile pour PLC. Episode 2
Après la réalisation matérielle de ce type de projet, et les inévitables séances de débogage, vient le temps de la programmation. A noter que ce montage simple n'a présenté aucun défaut de conception, si ce n'est un petit souci que j'évoquerai plus bas.
Je n'ai pas souhaité rendre ce montage compatible Arduino, c'est donc avec l'outil d'Atmel, Studio 7, et le programmateur AVR Dragon que j'ai effectué la totalité la programmation. Rien de bien compliqué ici sachant que son rôle consiste 'juste' à transmettre des données reçues en RS485 avec une vitesse de 2400 à 115200 Bauds, à un écran 'intelligent' réglé à une vitesse de communication de 115200 Bauds. Le gros principe de l'application étant juste la gestion de buffers circulaires de mise en tampon des donnés.
Les premiers test ce sont effectué en situation presque réelle :
Un écran intelligent est connecté sur le module de conversion de vitesse et de type d'interface, ce module étant relié en RS485 à un automate Controllino. L'automate est alimenté par son port USB directement sur le PC de développement. Le module de conversion et l'écran sont reliés à une alimentation de 12V.
Le bouton de droite 115200 permet de configurer la vitesse de communication de l'écran à 115200 Bauds. Le bouton Display... permet d'afficher la valeur en cours du Baud rate. Plusieurs informations en provenance de l'automate en 19200 Bauds sont retransmises à l'afficheur en 115200 Bauds. Il s'agit de l'heure et de la date qui sont transmises au début de l'application, puis de la valeur de comptage qui est simplement incrémentée dans la boucle principale du programme de l'automate :
#include <Controllino.h>
int ledPin = 13;
unsigned char Buffer[32];
unsigned char EndBuffer[] = {0xFF, 0xFF, 0xFF, 0x00};
unsigned char NumberBuffer[8];
unsigned int NumberTest = 0;
void setup() {
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
pinMode(ledPin, OUTPUT);
Serial.begin(19200);
Serial3.begin(19200);
strcpy(Buffer, "rtc3=17");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc4=36");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc5=00");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc2=21");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc1=10");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
}
void loop() {
delay(1000);
digitalWrite(ledPin, HIGH);
strcpy(Buffer, "n6.val=");
itoa(NumberTest++, NumberBuffer, 10);
strcat(Buffer, NumberBuffer);
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
Serial.print((char *)Buffer);
delay(1000);
digitalWrite(ledPin, LOW);
}
Programme de test réalisé sans aucune volonté de perfection...
Les instructions
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
servent 'juste' à configurer les pattes /RE et DE du tranceiver interne du Controllino afin que les données émises sur le port série n°3 partent bien en RS485.
La variable EndBuffer initialisée à {0xFF, 0xFF, 0xFF, 0x00} est obligatoire car toute instruction transmise à l'écran doit se terminer de la sorte. Les différentes variables rtcx correspondent à l'initialisation des différentes variables de l'heure et de la date qui sont mises à jour automatiquement par l'afficheur lui-même. Enfin n6, correspond à la variable affichée au milieu de l'écran, mise à jour toutes les secondes par l'automate.
Les premiers tests s'avèrent concluants. Même avec une communication RS485 en 2400 Bauds, l'écran répond correctement en 115200 Bauds. Ne connaissant pas la façon dont est effectué la gestion de la communication série au sein de l'écran, il était en effet possible qu'un time-out un peu trop 'serré' à la réception de caractères empêche ce dernier de considérer une trame correcte, valide. Mais il n'en est rien, à ma grande satisfaction.
Que reste-t-il à faire? D'un point de vue programmation, il reste à gérer la manipulation en temps réel du bloc de switchs afin de configurer le ports série du processeur qui gère le port série RS485 en temps réel.
D'un point de vue matériel, la partie alimentation à découpage implémentée sur cette carte d'interface est un peu trop juste pour l'écran de 7". La puissance demandée par les écrans de taille inférieur ne pose pas de problème au régulateur à découpage, mais le 7", avec ses 500mA de consommation, arrive en limite de ce qu'est capable de débiter l'alimentation. Dans ce cas, le régulateur ainsi que la self montent déjà un peu trop en température. Il faudra donc envisager une solution d'alimentation un peu plus cossue.
26 octobre 2017 : Après avoir implémenté la gestion des erreurs de communication, l'heure du bilan à sonné. Un peu de la même façon que ce qui est arrivé avec le switch MIDI (qu'il faut que je continue de développer d'ailleurs) et le processeur PIC utilisé au départ, puis remplacé par la suite par un processeur ARM de chez ST, je vais étudier une nouvelle version équipée elle aussi d'un processeur ARM de ST.
La raison principale de ce choix est, la aussi, un manque de flexibilité des processeurs de type ATmega. Sur ces derniers, il est difficile d'effectuer un débogage en temps réel. Or, avec le peu de temps dont je dispose pour mes développements, il m'arrive souvent de tester des petits bouts de code sur un montage laissé de côté depuis un certain temps. Ne me souvenant plus de tous les détails, il devient alors compliqué de comprendre la raison du non fonctionnement du code en test.
Pouvoir jeter un œil sur un registre devient alors primordial. Et puis l'IDE Atmel est lourd, vraiment trop lourd. Installer des centaines de méga pour du processeur 8 bits... Allez donc voir ce que propose Zilog depuis des décennies avec le ZDSII. Si seulement Zilog avait eu la bonne idée de rajouter un peu de RAM dans ses micro-contrôleurs. Mais ceci est une autre histoire.....
Je vais aussi en profiter pour améliorer un peu le concept de cette carte en y ajoutant quelques fonctionnalités qui me semblent intéressantes afin de la rendre un peu plus versatile que ce qu'elle est aujourd'hui. Un port RS232 me semble une option valable. Il y a en effet quantité de matériels 'anciens' qui fonctionnent avec ce type d'interface. Pouvoir les passer en 485 opto-isolé me semble être une bonne idée.
A suivre...
01 décembre 2017 : après avoir cherché des solutions d'alimentations à découpage qui ne soient pas trop complexes à implémenter sur une petite carte, d'un prix 'acceptable' et d'une capacité en courant suffisante, j'ai décidé de tester une solution à base de LM2596. Pour effectuer des tests sans avoir à développer quoi que ce soit, j'ai acquis sur eBay quelques modules de ce type pour quelques Euros :
Ce qui est intéressant avec ce type de module, c'est qu'en plus de la plage de tension d'entrée qui peut monter à 40V, la sortie réglable de quelques volts à plus de 30V sous 3A max permet de s'en servir en petite alimentation d'appoint pour effectuer quelques tests. A noter que ce type d'alimentation ne peut guère servir en alimentation définitive sur du long terme vu le type et la qualité des condensateurs chimiques.
Et à propose de test, j'ai pu vérifier le fonctionnement correct de l'écran tactile en version grand format de 7 pouces :
Après une petite heure de fonctionnement, les éléments du module d'alimentation sont à peine tiède pour un débit d'environ 500mA, ce qui me semble plus pertinent comme solution que celle adoptée en premier lieu sur ma carte de développement. Je vais quand même sortir l'oscilloscope pour vérifier à minima l'allure de l'alimentation ainsi que son bruit.
Je n'ai pas souhaité rendre ce montage compatible Arduino, c'est donc avec l'outil d'Atmel, Studio 7, et le programmateur AVR Dragon que j'ai effectué la totalité la programmation. Rien de bien compliqué ici sachant que son rôle consiste 'juste' à transmettre des données reçues en RS485 avec une vitesse de 2400 à 115200 Bauds, à un écran 'intelligent' réglé à une vitesse de communication de 115200 Bauds. Le gros principe de l'application étant juste la gestion de buffers circulaires de mise en tampon des donnés.
Les premiers test ce sont effectué en situation presque réelle :
Un écran intelligent est connecté sur le module de conversion de vitesse et de type d'interface, ce module étant relié en RS485 à un automate Controllino. L'automate est alimenté par son port USB directement sur le PC de développement. Le module de conversion et l'écran sont reliés à une alimentation de 12V.
Le bouton de droite 115200 permet de configurer la vitesse de communication de l'écran à 115200 Bauds. Le bouton Display... permet d'afficher la valeur en cours du Baud rate. Plusieurs informations en provenance de l'automate en 19200 Bauds sont retransmises à l'afficheur en 115200 Bauds. Il s'agit de l'heure et de la date qui sont transmises au début de l'application, puis de la valeur de comptage qui est simplement incrémentée dans la boucle principale du programme de l'automate :
#include <Controllino.h>
int ledPin = 13;
unsigned char Buffer[32];
unsigned char EndBuffer[] = {0xFF, 0xFF, 0xFF, 0x00};
unsigned char NumberBuffer[8];
unsigned int NumberTest = 0;
void setup() {
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
pinMode(ledPin, OUTPUT);
Serial.begin(19200);
Serial3.begin(19200);
strcpy(Buffer, "rtc3=17");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc4=36");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc5=00");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc2=21");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
strcpy(Buffer, "rtc1=10");
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
}
void loop() {
delay(1000);
digitalWrite(ledPin, HIGH);
strcpy(Buffer, "n6.val=");
itoa(NumberTest++, NumberBuffer, 10);
strcat(Buffer, NumberBuffer);
strcat(Buffer, EndBuffer);
Serial3.print((char *)Buffer);
Serial.print((char *)Buffer);
delay(1000);
digitalWrite(ledPin, LOW);
}
Programme de test réalisé sans aucune volonté de perfection...
Les instructions
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
servent 'juste' à configurer les pattes /RE et DE du tranceiver interne du Controllino afin que les données émises sur le port série n°3 partent bien en RS485.
La variable EndBuffer initialisée à {0xFF, 0xFF, 0xFF, 0x00} est obligatoire car toute instruction transmise à l'écran doit se terminer de la sorte. Les différentes variables rtcx correspondent à l'initialisation des différentes variables de l'heure et de la date qui sont mises à jour automatiquement par l'afficheur lui-même. Enfin n6, correspond à la variable affichée au milieu de l'écran, mise à jour toutes les secondes par l'automate.
Les premiers tests s'avèrent concluants. Même avec une communication RS485 en 2400 Bauds, l'écran répond correctement en 115200 Bauds. Ne connaissant pas la façon dont est effectué la gestion de la communication série au sein de l'écran, il était en effet possible qu'un time-out un peu trop 'serré' à la réception de caractères empêche ce dernier de considérer une trame correcte, valide. Mais il n'en est rien, à ma grande satisfaction.
Que reste-t-il à faire? D'un point de vue programmation, il reste à gérer la manipulation en temps réel du bloc de switchs afin de configurer le ports série du processeur qui gère le port série RS485 en temps réel.
D'un point de vue matériel, la partie alimentation à découpage implémentée sur cette carte d'interface est un peu trop juste pour l'écran de 7". La puissance demandée par les écrans de taille inférieur ne pose pas de problème au régulateur à découpage, mais le 7", avec ses 500mA de consommation, arrive en limite de ce qu'est capable de débiter l'alimentation. Dans ce cas, le régulateur ainsi que la self montent déjà un peu trop en température. Il faudra donc envisager une solution d'alimentation un peu plus cossue.
26 octobre 2017 : Après avoir implémenté la gestion des erreurs de communication, l'heure du bilan à sonné. Un peu de la même façon que ce qui est arrivé avec le switch MIDI (qu'il faut que je continue de développer d'ailleurs) et le processeur PIC utilisé au départ, puis remplacé par la suite par un processeur ARM de chez ST, je vais étudier une nouvelle version équipée elle aussi d'un processeur ARM de ST.
La raison principale de ce choix est, la aussi, un manque de flexibilité des processeurs de type ATmega. Sur ces derniers, il est difficile d'effectuer un débogage en temps réel. Or, avec le peu de temps dont je dispose pour mes développements, il m'arrive souvent de tester des petits bouts de code sur un montage laissé de côté depuis un certain temps. Ne me souvenant plus de tous les détails, il devient alors compliqué de comprendre la raison du non fonctionnement du code en test.
Pouvoir jeter un œil sur un registre devient alors primordial. Et puis l'IDE Atmel est lourd, vraiment trop lourd. Installer des centaines de méga pour du processeur 8 bits... Allez donc voir ce que propose Zilog depuis des décennies avec le ZDSII. Si seulement Zilog avait eu la bonne idée de rajouter un peu de RAM dans ses micro-contrôleurs. Mais ceci est une autre histoire.....
Je vais aussi en profiter pour améliorer un peu le concept de cette carte en y ajoutant quelques fonctionnalités qui me semblent intéressantes afin de la rendre un peu plus versatile que ce qu'elle est aujourd'hui. Un port RS232 me semble une option valable. Il y a en effet quantité de matériels 'anciens' qui fonctionnent avec ce type d'interface. Pouvoir les passer en 485 opto-isolé me semble être une bonne idée.
A suivre...
01 décembre 2017 : après avoir cherché des solutions d'alimentations à découpage qui ne soient pas trop complexes à implémenter sur une petite carte, d'un prix 'acceptable' et d'une capacité en courant suffisante, j'ai décidé de tester une solution à base de LM2596. Pour effectuer des tests sans avoir à développer quoi que ce soit, j'ai acquis sur eBay quelques modules de ce type pour quelques Euros :
Ce qui est intéressant avec ce type de module, c'est qu'en plus de la plage de tension d'entrée qui peut monter à 40V, la sortie réglable de quelques volts à plus de 30V sous 3A max permet de s'en servir en petite alimentation d'appoint pour effectuer quelques tests. A noter que ce type d'alimentation ne peut guère servir en alimentation définitive sur du long terme vu le type et la qualité des condensateurs chimiques.
Et à propose de test, j'ai pu vérifier le fonctionnement correct de l'écran tactile en version grand format de 7 pouces :
Après une petite heure de fonctionnement, les éléments du module d'alimentation sont à peine tiède pour un débit d'environ 500mA, ce qui me semble plus pertinent comme solution que celle adoptée en premier lieu sur ma carte de développement. Je vais quand même sortir l'oscilloscope pour vérifier à minima l'allure de l'alimentation ainsi que son bruit.
mercredi 11 octobre 2017
PC : les ventes baissent toujours.
Ah, il est vraiment fini le temps ou l'ordinateur représentait un potentiel de développement et de créativité personnel. Les machines à publicité qui nous sont vendues aujourd'hui, ne servent finalement qu'à faire du Minitel évolué ou à faire fonctionner des applications de gestion globalement mal développées. C'est sur, le PC n'a plus la côte!
Il y a quelques années encore, l'arrivée d'un Linux un peu plus ergonomique, notamment avec l'initiative Ubuntu (Canonical), aurait pu faire penser à du mieux. Hélas, depuis 10 ans, que dire de l'évolution de Linux pour PC. A se demander si des 'taupes' de Microsoft ne travaillent pas chez les contributeurs de Linux pour l'empêcher d'évoluer vers un 'vrai' système pour les utilisateurs.
C'est sans doute une des raisons de l'engouement actuel pour le rétro-computing. Elles étaient finalement sympa ces petites machines qui permettaient de créer plein d'applications, soi-même, sans grandes connaissances en programmation.
 |
| Je n'ai pas demandé l'autorisation à Reuters... |
C'est sans doute une des raisons de l'engouement actuel pour le rétro-computing. Elles étaient finalement sympa ces petites machines qui permettaient de créer plein d'applications, soi-même, sans grandes connaissances en programmation.
mardi 3 octobre 2017
Ecran tactile pour PLC.
Depuis presque deux ans maintenant, j'utilise des écrans tactiles fabriqués en Chine, qui ont l'avantage par rapport à d'autres solutions, d'être très facilement programmable. Cependant ce type d'écran présentait plusieurs problèmes. Les premières versions ne disposaient pas de l'heure sauvegardée. Le tactile était de type résistif, donc assez peu pratique à manipuler, ou en tout cas interdisant les objets affichés de petite taille. Récemment, le fabricant à amélioré le sujet en proposant plus spécialement un écran de 7 pouces, de type capacitif, avec heure temps réel sauvegardée, présenté dans un boitier qui n'est pas inélégant :
Reste quand même quelques caractéristiques techniques qui contraignent un peu l'utilisation de ce type d'écran. La première contrainte concerne l'interface de communication qui se trouve être exclusivement de type TTL 5V. Il est donc impossible de raccorder ce type d'écran directement à un PLC, notamment par l'intermédiaire d'une interface standard RS485.
Le deuxième problème vient de la façon dont réagit cet écran, et notamment du format des informations bidirectionnelles. Elles ne répondent à aucun format standard comme le protocole Modbus par exemple, et est totalement propriétaire.
Dans quel cas utiliser ce type d'écran alors? Dans un premier temps il est tout à fait possible d'envisager une connexion à un automate de type Controllino :
Ce type d'automate se laisse facilement programmer en langage 'C', et est donc tout à fait capable de gérer directement des chaines de caractères, dialecte utilisé par l'écran. Ce type de configuration est particulièrement adaptée à l'automatisation et/ou le contrôle d'habitations ou de petits bâtiments. Que manque-t-il alors pour connecter ces deux appareils? Tout simplement une interface de communication de type TTL/RS485.
Le problème étant posé, il est dès lors assez simple d'établir les besoins minimum pour l'interface à réaliser :
- Le premier sera de convertir la nature des signaux série TTL/RS485.
- Le deuxième consiste à en profiter pour permettre l'adaptation de la vitesse de communication.
- Le troisième : fournir une alimentation régulée et relativement généraliste pour permettre une alimentation sans véritable contrainte.
Les solutions adoptées :
- Utilisation d'un convertisseur dédié permettant l'isolation du bus RS485.
- Utilisation d'un processeur offrant une adaptation simple de la vitesse de communication par rapport aux contraintes du terrain, sans avoir à reprogrammer l'écran.
- Utilisation d'une alimentation à découpage interne (7 à 26V en entrée), en mesure de fournir l'alimentation à l'écran ainsi qu'à la carte d'adaptation.
Et cela se présente comment?
Comme ceci :
Il s'agit d'une carte prototype ou les composants sont soudés à la main, raison pour laquelle le design est très aéré. Un produit industrialisé devrait pouvoir occuper à peine la moitié de la surface actuelle.
Il y a un peu plus d'un an, j'avais réalisé le même type de carte, de plus compatible Arduino, dont l'avantage était d'être programmable, mais l'inconvénient, donc, de devoir être programmée par l'utilisateur :
Dans cette nouvelle version, le programme sera développé directement avec l'outil Atmel (Microchip maintenant), et gravé une fois pour toute dans la puce.
Il ne reste plus qu'à effectuer le travail de programmation de la nouvelle carte, et à tester le tout avec l'écran et l'automate Controllino.
A suivre...
Reste quand même quelques caractéristiques techniques qui contraignent un peu l'utilisation de ce type d'écran. La première contrainte concerne l'interface de communication qui se trouve être exclusivement de type TTL 5V. Il est donc impossible de raccorder ce type d'écran directement à un PLC, notamment par l'intermédiaire d'une interface standard RS485.
Le deuxième problème vient de la façon dont réagit cet écran, et notamment du format des informations bidirectionnelles. Elles ne répondent à aucun format standard comme le protocole Modbus par exemple, et est totalement propriétaire.
Dans quel cas utiliser ce type d'écran alors? Dans un premier temps il est tout à fait possible d'envisager une connexion à un automate de type Controllino :
Ce type d'automate se laisse facilement programmer en langage 'C', et est donc tout à fait capable de gérer directement des chaines de caractères, dialecte utilisé par l'écran. Ce type de configuration est particulièrement adaptée à l'automatisation et/ou le contrôle d'habitations ou de petits bâtiments. Que manque-t-il alors pour connecter ces deux appareils? Tout simplement une interface de communication de type TTL/RS485.
Le problème étant posé, il est dès lors assez simple d'établir les besoins minimum pour l'interface à réaliser :
- Le premier sera de convertir la nature des signaux série TTL/RS485.
- Le deuxième consiste à en profiter pour permettre l'adaptation de la vitesse de communication.
- Le troisième : fournir une alimentation régulée et relativement généraliste pour permettre une alimentation sans véritable contrainte.
Les solutions adoptées :
- Utilisation d'un convertisseur dédié permettant l'isolation du bus RS485.
- Utilisation d'un processeur offrant une adaptation simple de la vitesse de communication par rapport aux contraintes du terrain, sans avoir à reprogrammer l'écran.
- Utilisation d'une alimentation à découpage interne (7 à 26V en entrée), en mesure de fournir l'alimentation à l'écran ainsi qu'à la carte d'adaptation.
Et cela se présente comment?
Comme ceci :
 |
| Carte prototype |
Il y a un peu plus d'un an, j'avais réalisé le même type de carte, de plus compatible Arduino, dont l'avantage était d'être programmable, mais l'inconvénient, donc, de devoir être programmée par l'utilisateur :
Dans cette nouvelle version, le programme sera développé directement avec l'outil Atmel (Microchip maintenant), et gravé une fois pour toute dans la puce.
Il ne reste plus qu'à effectuer le travail de programmation de la nouvelle carte, et à tester le tout avec l'écran et l'automate Controllino.
A suivre...
jeudi 21 septembre 2017
AMIGA32
Le cas Amiga : je me souviens qu'au début des années 1990 il m'arrivait d'acheter une revue dont les sujets principaux étaient les systèmes informatiques dits 'alternatifs', qui avaient fait le bonheur de ma génération jusqu'à ce que le terrible PC écrase tout. Dans cette revue on y parlait de machines comme la série Next, de systèmes comme le BeOS, et évidemment des errements de la marque Amiga.
J'ai du cesser de rêver à ces machines accessibles vers 1993 lorsque que la saga Commodore fût définitivement morte. De toute ces belles (et parfois de vraiment moins belles) machines de la décennie 80, il ne reste plus aujourd'hui beaucoup de sujets actifs. Il existe bien quelques recréations de ZX80-ZX81, de Spectrum, de MSX le plus souvent en FPGA, mais pas grand chose de plus.
Des deux ordinateurs 13/32 bits de l'époque l'Atari ST eût sa petite heure de gloire à la fin des années 2000 avec la machine Suska, dont le firmware est toujours mis à jour :
Et plus actuellement le M.I.S.T. que je possède et qui fonctionne très bien, édité par LOTHAREK :
Ces deux machines fonctionnent avec des émulation du processeur d'origine, à savoir un 680x0 quelconque et la majorité des périphériques, à l'intérieur d'un FPGA. La compatibilité avec le matériel d'origine est alors très élevée.
Une autre voie a été prise par le projet FireBee, débuté en 2008, qui a consisté à créer une machine 'compatible' avec l'Atari d'origine, en partant d'un processeur ColdFire MCF5474 capable d'émuler les instructions du 68000 d'origine, mais en impliquant quand même de grosses modifications logicielles :
J'ai pu assister à une démonstration de cette machine grâce à Vincent Rivière, développeur logiciel de la machine, qui en possédait un exemplaire. J'avais été très impressionné par le travail effectué. La machine est relativement chère et la partie soft est toujours activement en cours de développement. Il s'agit donc plus d'une machine pour gros passionnés de la programmation que d'un matériel apte à rendre de suite quelques services.
Ce sont les trois machines que je considère comme actuelles, naviguant dans la sphère de l'ancien ATARI ST.
Et à propos de l'Amiga? J'ai bien entendu parler des machines crées dans les années 90 et début 2000, mais n'ai jamais vraiment porté attention à ces réalisations. Hormis le Minimig dont j'ai entendu parler il y a quelques années de cela, pas grand chose.
Hors il semblerait que les choses changent actuellement de façon très dynamique, particulièrement grâce à l'entreprise Applo Accelerators, fabriquant des cartes accélératrices Vampires :
Ces cartes accélératrices sont disponibles pour A600 et A500, avec une version A1200 prévue, et aussi et surtout, une version autonome qui rassemblerait tout le hard d'un Amiga sur une même carte, il s'agirait de la Vampire V4 :
Je n'ai pas tout suivi l'affaire Amiga mais il me semble que l'aspect logiciel n'est pas en reste non plus. Et vues les démos que sont capables d'effectuer ces cartes, il est légitime de penser que l'on se trouve en présence d'un vrai eco-système sur base Amiga.
Alors si vous souhaitez en savoir plus, il pourrait être intéressant de participer à l'évènement Amiga 32 qui se tiendra à Neuss en Allemagne le 28 octobre 2017 (j'ai déjà eu l'occasion dévoquer cet évènement ici ) :
Pour se procurer un billet, c'est ici : http://www.amiga32.de
Physiquement ca se trouve ici :
Cette fois, je me laisserais bien tenter ;-)
J'ai du cesser de rêver à ces machines accessibles vers 1993 lorsque que la saga Commodore fût définitivement morte. De toute ces belles (et parfois de vraiment moins belles) machines de la décennie 80, il ne reste plus aujourd'hui beaucoup de sujets actifs. Il existe bien quelques recréations de ZX80-ZX81, de Spectrum, de MSX le plus souvent en FPGA, mais pas grand chose de plus.
Des deux ordinateurs 13/32 bits de l'époque l'Atari ST eût sa petite heure de gloire à la fin des années 2000 avec la machine Suska, dont le firmware est toujours mis à jour :
 |
| https://www.experiment-s.de/en/boards/suska-iii-t/ |
Et plus actuellement le M.I.S.T. que je possède et qui fonctionne très bien, édité par LOTHAREK :
 |
| http://lotharek.pl/product.php?pid=186 |
Une autre voie a été prise par le projet FireBee, débuté en 2008, qui a consisté à créer une machine 'compatible' avec l'Atari d'origine, en partant d'un processeur ColdFire MCF5474 capable d'émuler les instructions du 68000 d'origine, mais en impliquant quand même de grosses modifications logicielles :
 |
| http://firebee.org/fb-bin/index?lng=FR |
J'ai pu assister à une démonstration de cette machine grâce à Vincent Rivière, développeur logiciel de la machine, qui en possédait un exemplaire. J'avais été très impressionné par le travail effectué. La machine est relativement chère et la partie soft est toujours activement en cours de développement. Il s'agit donc plus d'une machine pour gros passionnés de la programmation que d'un matériel apte à rendre de suite quelques services.
Ce sont les trois machines que je considère comme actuelles, naviguant dans la sphère de l'ancien ATARI ST.
Et à propos de l'Amiga? J'ai bien entendu parler des machines crées dans les années 90 et début 2000, mais n'ai jamais vraiment porté attention à ces réalisations. Hormis le Minimig dont j'ai entendu parler il y a quelques années de cela, pas grand chose.
Hors il semblerait que les choses changent actuellement de façon très dynamique, particulièrement grâce à l'entreprise Applo Accelerators, fabriquant des cartes accélératrices Vampires :
 |
| http://www.apollo-accelerators.com |
Je n'ai pas tout suivi l'affaire Amiga mais il me semble que l'aspect logiciel n'est pas en reste non plus. Et vues les démos que sont capables d'effectuer ces cartes, il est légitime de penser que l'on se trouve en présence d'un vrai eco-système sur base Amiga.
Alors si vous souhaitez en savoir plus, il pourrait être intéressant de participer à l'évènement Amiga 32 qui se tiendra à Neuss en Allemagne le 28 octobre 2017 (j'ai déjà eu l'occasion dévoquer cet évènement ici ) :
Pour se procurer un billet, c'est ici : http://www.amiga32.de
Physiquement ca se trouve ici :
Cette fois, je me laisserais bien tenter ;-)
mercredi 20 septembre 2017
Recreating the Sequential Circuits Prophet VS.
Comme le titre le laisse à penser, j'ouvre ici un billet dont le sujet est la recréation totale du synthétiseur de Sequential Circuits, le Prophet VS.
Pourquoi? Parce que le Prophet VS est une machine assez intéressante. Parce que j'ai toujours estimé qu'elle n'avait pas été très bien conçue et que le concept pouvait 'sonner' un peu mieux. Parce que j'ai étudié il y a quelques années la faisabilité de la mise en FPGA de l'ensemble de la carte mère du Prophet VS, et que le résultat obtenu était pertinent. Que finalement, cela peut aussi être bien de mener à terme un projet qui m'a déjà occupé un bon paquet d'heures. Quant à faire mieux que les développeurs de l'époque chez Sequential Circuits : a voir...
Le travail déjà effectué à consisté à implémenter dans une carte à base de FPGA, l'ensemble de la carte mère du VS :
Absolument tous les composants de cette carte sont émulés, sauf la gestion du clavier. Je n'ai d'ailleurs pas l'intention de m'attaquer à la gestion du clavier du VS sachant que je projette d'élaborer une version 'desktop' de ce synthétiseur.
Lors de mon étude précédente, je me suis arrêté à celle du circuit 'custom' responsable de la génération des formes d'ondes des oscillateurs. Je viens donc de m'attaquer à ce sujet important, car une fois ces quatre circuits 'décodés', il deviendra possible d'intégrer absolument toute la partie numérique de ce synthétiseur dans un gros circuit de type FPGA. Cela va encore demander un certain travail...
28/08/2017 : après avoir ressorti l'analyseur logique et effectué une série de tests afin de se faire une première idée de la façon dont fonctionnent les circuit custom de ce Prophet VS, il est temps de se préparer un circuit d'interface pour permettre le raccordement d'une carte FPGA sur la carte de synthèse du VS.
Parce que le gros problème de ce type de machine Vintage, c'est que tous les circuits numériques fonctionnent en 5V. Alors que les entrées/sorties des FPGA actuels sont, au mieux, en 3,3V. Cela peut poser des problèmes lorsqu'il s'agit de faire 'rentrer' un signal de 5V sur une entrée qui ne supporte QUE 3,3V max.
Le circuit étudié se contente de tamponner tous les signaux d'un circuit CUSTOM en 3,3V avec une connectivité facilitée pour le raccordement à une carte FPGA :
Ce circuit se positionnera directement à la place d'un des circuits CUSTOM sans avoir quoi que ce soit à modifier de la carte de synthèse, tout en conservant une bonne intégrité des signaux.
Et en attendant de recevoir ce circuit imprimé, il est temps de s'occuper du traitement audio qui suit directement ces circuits CUSTOM, à savoir la conversion numérique/analogique, les VCAs d'onde et le démultiplexage analogique final des signaux audio. J'ai quelques idées pour améliorer et simplifier toute cette partie avec des composants modernes. Il me faut tester la viabilité de ces idées...
Pourquoi? Parce que le Prophet VS est une machine assez intéressante. Parce que j'ai toujours estimé qu'elle n'avait pas été très bien conçue et que le concept pouvait 'sonner' un peu mieux. Parce que j'ai étudié il y a quelques années la faisabilité de la mise en FPGA de l'ensemble de la carte mère du Prophet VS, et que le résultat obtenu était pertinent. Que finalement, cela peut aussi être bien de mener à terme un projet qui m'a déjà occupé un bon paquet d'heures. Quant à faire mieux que les développeurs de l'époque chez Sequential Circuits : a voir...
 |
| 'THE' Prophet VS |
Le travail déjà effectué à consisté à implémenter dans une carte à base de FPGA, l'ensemble de la carte mère du VS :
 |
| La carte mère du Prophet VS. |
Lors de mon étude précédente, je me suis arrêté à celle du circuit 'custom' responsable de la génération des formes d'ondes des oscillateurs. Je viens donc de m'attaquer à ce sujet important, car une fois ces quatre circuits 'décodés', il deviendra possible d'intégrer absolument toute la partie numérique de ce synthétiseur dans un gros circuit de type FPGA. Cela va encore demander un certain travail...
28/08/2017 : après avoir ressorti l'analyseur logique et effectué une série de tests afin de se faire une première idée de la façon dont fonctionnent les circuit custom de ce Prophet VS, il est temps de se préparer un circuit d'interface pour permettre le raccordement d'une carte FPGA sur la carte de synthèse du VS.
Parce que le gros problème de ce type de machine Vintage, c'est que tous les circuits numériques fonctionnent en 5V. Alors que les entrées/sorties des FPGA actuels sont, au mieux, en 3,3V. Cela peut poser des problèmes lorsqu'il s'agit de faire 'rentrer' un signal de 5V sur une entrée qui ne supporte QUE 3,3V max.
Le circuit étudié se contente de tamponner tous les signaux d'un circuit CUSTOM en 3,3V avec une connectivité facilitée pour le raccordement à une carte FPGA :
Ce circuit se positionnera directement à la place d'un des circuits CUSTOM sans avoir quoi que ce soit à modifier de la carte de synthèse, tout en conservant une bonne intégrité des signaux.
Et en attendant de recevoir ce circuit imprimé, il est temps de s'occuper du traitement audio qui suit directement ces circuits CUSTOM, à savoir la conversion numérique/analogique, les VCAs d'onde et le démultiplexage analogique final des signaux audio. J'ai quelques idées pour améliorer et simplifier toute cette partie avec des composants modernes. Il me faut tester la viabilité de ces idées...
Inscription à :
Articles (Atom)