Fin de confinement, et fin des tests du convertisseur CV/GATE

ou, comme l'aurait dit Claude Nougaro "Un nouveau départ, solide comme un roc"...

Rappel : après avoir développé une petite application windows pour me permettre de relever automatiquement les valeurs précises à envoyer au DAC en fonction des notes reçues par le port MIDI, j'ai pu finaliser le fonctionnement basic du logiciel de ce convertisseur et relever non seulement les tensions générées mais aussi les mesures effectuées sur de vrais modules VCO.

Pour se faire, j'ai utilisé un générateur de signal fraîchement acquis, qui possède aussi une entrée de comptage, le FY6900 dont j'ai détaillé la modification de l'alimentation pour de meilleurs performances de l'appareil :

Les deux modules VCO utilisés sont tout d'abord le Pico VCO2 de Erica Synths :

ainsi que le module ElectroSmith 3340 :

Afin de piloter le tout, j'ai utilisé un convertisseur USB/MIDI-MERGE que j'ai aussi créé  :

Équipé de tout ces appareil, j'ai d'abord relevé les tensions générées par le convertisseur MIDI/CV. Pour se faire j'ai utilisé un petit utilitaire de clavier virtuel sous windows :

La première chose à faire fût de relever les différentes tensions obtenues en 'envoyant' les notes DO des 5 octaves. Le relevé des mesure s'est avéré excellent :

Fort de ces résultats je me suis donc attelé au test 'in situe' avec les deux modules VCOs. Je dois dire qu'avant de m'appliquer à relever les valeurs des fréquences produites par ces deux VCOs, j'avais quelques difficultés à déterminer les octaves avec le module d'ElectroSmith. Il me semblait totalement désaccordé alors que le module PICO VCO lui, semblait réagir correctement.

Passage aux mesures donc :

Et le verdict est tombé :

J'avoue ne pas comprendre réellement le fonctionnement du module ElectroSmith. Le pourcentage d'erreur max relevé est totalement délirant, et correspond (hélas) à ce que j'entendais au casque.

Si le module Erica reste précis avec une erreur maximale inférieur à 2% même après 24h de fonctionnement, le module ElectroSmith délire complètement et semble présenter une échelle plus logarithmique que linéaire!

J'ai respecté la procédure de calibration comme indiqué dans la documentation du sous-module ES-3340 :

Bien que possédant un potentiomètre interne de réglage du 1V/oct je n'ai jamais été en mesure de rendre le module 3340 un tant soit peu linéaire. Pire, il arrive parfois que le résultat des mesures ne corresponde pas au sens auquel je tourne les potentiomètres de la face avant du 3340. Incompréhensible, en tournant à fond à droite les potentiomètres du 3340, j'obtiens en sortie une fréquence de plus de 98kHz!!! Oui oui, presque 100kHz! Je me demande à quoi cela peut bien servir même cela semble correct à la vue des spec. du fabriquant :

Alors évidemment, j'ai acquis le 3340 d'ElectroSmith sous forme de kit. Peut-être ais-je 'raté' quelque chose? En fait il n'y a que les connecteurs à souder soi-même. Toute l'électronique est fournie sous la forme d'un module en cms pré-assemblé. Je n'ai donc rien 'bricolé' autour de la partie analogique :

Après plusieurs vérifications, je n'ai pas vu d'erreur de ma part. Le module semble fonctionner correctement. J'ai donc de forts doutes sur la conception de ce module. En tout cas, le résultat est trop aberrant pour que ce soit mon convertisseur MIDI/CV-Gate qui soit en cause, surtout si je considère que l'ensemble fonctionne parfaitement avec le module PICO VCO2.

Si 'certains d'entre vous' avez constaté ce type de comportement avec le module ElectroSmith, n'hésitez pas à m'en faire part!

Pour l'heure, je considère mon système fiable et vais pouvoir continuer le développement du logiciel afin de rendre le montage le plus versatile possible. Quatre switchs vont permettre de sélectionner les modes de fonctionnement de ce convertisseur MIDI/CV-Gate....

[UPDATE 02 JUIN 2020] Je me suis penché sur le cas de ce VCO 3340 d'Electrosmyth pour finir par me rendre compte qu'il y avait un problème au niveau de l'embase de commande V/OCT. Après avoir identifié et corrigé le problème, le module s'est mis à fonctionner normalement. Cela m'a permis d'effectuer de nouveaux tests de précision, après avoir respecté la procédure d'étalonnage. J'arrive aux résultats suivants :

Ce qui correspond tout de même à des valeurs plus crédibles que précédemment. Malgré plusieurs itérations de la procédure d'étalonnage, je ne suis pas parvenu à améliorer la précision qui a tendance à se dégrader dans les fréquences graves, mais tout en restant cependant dans des marges acceptables.
Ce module est un peu moins précis que le VCO2 d'Erica Synth mais offre plus de possibilités de modulation.

Une petite démo du sujet peut se trouver sur Youtube :

CV/GATE : procédure détalonnage.

Après un certain nombre d'heures de programmation et de tests, me voici arrivé à une application fonctionnelle et fiable :

Il s'agit donc de la version je pense définitive (avec le multimètre utilisé) de ma petite application de calibration du DAC utilisé dans mon convertisseur midi vers CV/GATE. J'ai décrit les outils utilisés pour le développement de cet utilitaire dans mon article précédent.

Le fichier créé par cet utilitaire contient simplement une variable de type tableau, directement intégrable dans le source de l'application de gestion de ce convertisseur et correspondant aux codes nécessaires pour générer les 61 notes d'un clavier standard au format 1V/Octave avec la meilleur précision possible, typiquement aux alentours de 0,3% max, hors dérive due à la température ambiante :

Arriver à ce résultat n'a pas été particulièrement simple parce que, même si le multimètre envoi automatiquement ses données et que donc cela pourrait être perçu de prime abord comme un avantage, sous windows cela n'en est pas un. Tout simplement parce que cela signifie de l'asynchronisme. Et l'asynchronisme n'est pas trivial à gérer dans un environnement multitâche comme windows sans utiliser l'artillerie lourde (je ne détaille pas, ça n'est pas le sujet).

Je pense être en mesure d'améliorer le fonctionnement de cet utilitaire grâce à l'utilisation du multimètre Fluke 289 qui lui, renvoi sa mesure suite à une demande. Pour cela, j'ai passé commande de l'adaptateur série 'qui va bien' :

Avec ce Fluke, il me sera alors possible de gérer l'ensemble de la procédure dans la même fonction et non pas de devoir passer par une variable de transfert, avec tous les problèmes que cela suppose d'accès à un objet unique par deux processus!

Je comprends mieux maintenant la raison pour laquelle il arrive parfois qu'avec tel ou tel petit outil, l'utilitaire de configuration semble aussi archaïque, mal commode et parfois plante. Si l'on ne veut pas perdre tous les bénéfices financiers de la vente d'un petit appareil générant une marge faible, et que donc il faut impérativement produire l'utilitaire en question en 15 jours par le stagiaire n'y connaissant pas grand chose à la base, et bien on aboutit irrémédiablement à ce type d'outil.

windows n'est tout simplement pas fait pour ça.
Ce 'système' impose un nombre d'heures de développement largement trop élevé par rapport aux besoins 'amateurs' ou semi-pro.
Dans ce contexte, comme pourrait le dire Feydeau, 'windows c'est beau, ça semble puissant, ça fait plein de choses, mais ça ne sert à rien!'

Hélas bill gates n'a jamais eu l'humour inoffensif d'un Monsieur Bouzin!

Corona : activités d'éveil n°7, progression sur le convertisseur CV/GATE

Allez, on y croit : dernière semaine de confinement généralisé. Serait-ce le bout du tunnel?

En attendant, la semaine passée a été consacrée à la mise en place d'une procédure d’étalonnage du convertisseur CV/GATE 8 voies développé durant l'année 2019 :

L'image ci-dessus représente la dernière version de la carte développée. Je ne l'ai pas encore montée. Elle fait suite à deux autres prototypes dont celui qui sert actuellement de test pour la mise en place de la procédure d'étalonnage. La première version ressemblait à ceci :

J'ai développé une deuxième version de cette carte pour corriger une petite erreur de câblage au niveau d'un des régulateurs de tension. C'est cette deuxième version que j'ai utilisé cette dernière semaine pour développer le banc de test et d'étalonnage :

La dernière version du convertisseur CV/GATE propose un circuit imprimé plus petit, une amélioration  du schéma général pour une meilleur stabilité, et une rationalisation du fonctionnement.

Bien que les deux prototypes fonctionnent correctement, avec une linéarité tout à fait satisfaisante, la stratégie mise en place pour la calibration, elle, ne l'est pas. J'ai utilisé le principe de la fonction mathématique pour produire la valeur numérique à destination du DAC, correspondant à la note reçue par le biais de l'interface MIDI.

Le problème, est que d'une part la recherche de la bonne fonction a été très laborieuse puisque qu'à chaque fois il me fallait modifier le programme du processeur du montage, relever à la main les valeurs retournées par le DAC et vérifier la linéarité sur une feuille excel. D'un point de vue amateur, cela peut s'accepter, mais de façon plus sérieuse, cela fait quand même bricolage et surtout est trop laborieusement reproductible.

D'autre part le convertisseur utilisé ne propose pas une fonction de transfert stable sur l'étendue de sa conversion et je soupçonne que certaines caractéristiques de cette fonction dépendent aussi de chaque DAC.

J'ai donc décidé de modifier d'approche par l'utilisation d'une méthode plus 'brute force'. A savoir tout simplement l'envoi au DAC de toutes les valeurs possibles et sélectionner celles correspondant aux tensions voulues. Après tout, un clavier de piano ne comporte 'que' 81 touches donc au maximum 81 valeurs à retenir. En mettant en place une procédure automatique et rapide cela me permettra de calibrer chaque carte au mieux.

Le principe  : l'utilisation d'un PC pour gérer l'envoi des données au DAC et récupérer les tensions correspondantes. Le programme PC sélectionne automatiquement les valeurs correspondant aux notes d'un clavier standard et fabrique un fichier de correspondance à intégrer au source qui sera transféré dans le processeur de la carte. Avec de la 'chance', il ne sera peut-être pas nécessaire de répéter l'opération pour chaque carte si la dispersion du DAC n'est pas trop importante.

Le matériel :  pour l'envoi des données au DAC, et sachant que celui-ci fonctionne en bus SPI, le plus simple a été l'utilisation du Bus Pirate développé par Ian Lesnet (http://dangerousprototypes.com/). Connecté en USB sur le PC, il présente un port série standard et une configuration par simple protocole texte. J'utilise la version 3.6 :

La réception des valeurs de mesure se fait par l'intermédiaire d'un multimètre 22000 points classique et 'assez' précis de type UNI-T UT61E :

Publicité gratuite.

Ce multimètre possède l'énorme avantage de posséder une interface série opto-isolée disponible sur prise RS232C, un adaptateur USB s'avère donc nécessaire. J'utilise ceci :

Ça n'est pas l'adaptateur le moins cher, mais au moins il est correctement construit, possède les bons connecteurs ainsi que des LEDs d'indication pour l'émission et la réception.

Le multimètre utilisé envoi de façon automatique une chaîne de caractères dans un format spécifique qui ne pose aucun problème de décodage. Inutile donc de lui demander l'envoi d'une valeur, il le fait tout seul. Ce qui n'est visiblement pas le cas du FLUKE 289 que je possède par ailleurs :

Publicité gratuite.

Ce multimètre est très précis et possède aussi une interface série au protocole de type texte. Je suis bien tenté de commander son interface série pour l'utiliser dans mon banc d'étalonnage.

Le logiciel : avant toute chose, notez que je ressent une ABSOLUE AVERSION envers l'entreprise microsoft. Tant d'un point de vue technique que philosophique. Mon avis ne sera donc pas objectif. Ceci écrit, j'ai donc (à contre cœur vous l'aurez compris) décidé de développer une petite application sous windows (je ne mets jamais de majuscules aux produits microsoft).

Heureusement, j'avais développé une petite application de ce type il y a une vingtaine d'années, à l'époque ou il fallait tester le système d'exploitation parce que la simple ouverture de port se faisait différemment selon que l'on était sous windows 98, NT ou XP !!! Je m'attendais donc à ce que cela ne soit pas simple, même pour une toute petite application.

J'ai une fois de plus tenté 'visual studio' dernière version. Après avoir téléchargé 2Go correspondant à 8Go installés sur le disque, j'ai de nouveau constaté l’absolu archaïsme de ce système de développement (je me place au niveau d'une personne attendant un réel 'service' de la part de l'outil et non pas au niveau d'un développeur qui ne connaîtra que cette médiocrité de développement durant toute sa vie de développeur et qui donc y sera habitué, le trouvera hyper adapté et considérera que tout le reste n'est que distraction). J'ai donc opté pour une solution beaucoup plus adaptée mais totalement obsolète : WxDev-C++, 550Mo sur le disque, WxWidget compris. Au moins cette solution me permet de développer simplement une application de type boîte de dialogue comme ceci :

Je n'ai pas encore totalement terminé cet utilitaire. La sélection des bonnes valeurs correspondant aux notes d'un clavier n'est pas encore implémentée mais le plus difficile est fait : je récupère la tension générée par toutes les valeurs envoyées au DAC.

L'utilisation des ports de com n'est évidemment pas aisée sous windows. Rien n'a changé depuis mes développements précédents il y a presque 20 ans. Je n'avais pas envie d'utiliser les pthreads pour gérer la réception des trames séries : trop galère et compliqué à utiliser et bien trop consommateur de temps pour une si petite application. J'ai donc utilisé le déclenchement par timers pour lire à intervalle régulier la disponibilité, ou pas, de caractères reçus sur les ports. Et de toute façon cela tombe bien, WxDev-C++ ne possède pas de façon native la gestion des pthreads.

A noter que j'ai aussi tenté Code::Block et les WxWidgets dernière version et ai rapidement laissé tomber l'affaire. les aides à la création des fenêtres sont archaïques, incommodes et, la cerise qui fait le bonheur, plantent systématiquement : inutilisable pour ce besoin. Par contre, j'ai dernièrement utilisé Code::Block pour du développement sur Z80, cela fonctionne très bien.

Je me suis souvent dit que je passerais moins de temps à développer un petit ordinateur adapté à mes besoins plutôt qu'à essayer de faire faire quelque chose à windows. C'est d'ailleurs depuis toujours la politique de microsoft, fournir un outil de développement qui n'en est pas un et imposer des méthodes les plus éloignées possibles des besoins et capacité des gens 'normaux' pour les évincer de facto de la course à la concurrence.

C'est sur ce principe que ce sont construits les empires informatiques américains d'aujourd'hui, microsoft, google et autres : développer à outrance une technologie archaïque et improductive qui impose une organisation sociétale adaptée, propre à fournir une très grande quantité de personnes stupidement intelligentes et bien formées au sujet. Hormis la Chine dont le système de direction à permis d'imposer le changement sociétal nécessaire, pour le reste de la planète, c'est l'échec et la course perpétuelle et destructrice à l’échalote de la "startup nation" !

Bon, ça n'est pas le tout de divaguer en propos philosophiques, mais il me faut maintenant terminer cette application!

DYNACORD ADS PSU.

Pour faire suite à la réalisation de l'alimentation hybride que j'évoquais dans les deux posts précédents ici et ici, j'ai finalisé son installation dans l'échantillonneur Dynacord ADS :

Cette machine est dite obsolète à la vue des ses caractéristiques. Certes. En ce qui me concerne je n'aime pas vraiment ce terme d’obsolescence pour des machines qui, même si elles ont bien évidemment été réalisées avec les moyens de l'époque, ont souvent été très bien pensées, contrairement à certaines machines d'aujourd'hui aux caractéristiques impressionnantes, mais réalisées (à la va-vite) avec les technos du moment.

Et puis cet ADS, c'est du pur vintage, et du Dynacord de surcroît!

Cet échantillonneur est côté 50€ sur Audiofanzine, autrement dit : presque rien. A ce prix, cela représente à peine une heure de dépannage (version TTC). Y mettre une nouvelle alimentation n'a donc aucun intérêt financier.

Alors j'ai poussé le 'vice' jusqu'au bout. J'y ai aussi rajouté un émulateur de lecteur de disquettes HxC.

Le gros point noir du montage de l'alimentation à bien évidemment été le montage physique. J'ai du créer une plaque d'adaptation sur laquelle fixer le sandwich composé par l'alimentation SDG, plus l'ancien interrupteur marche/arrêt qui est une version déportée, commandé depuis un poussoir mécanique en face avant. Pour le câblage du 220V, j'ai utilisé des chutes de fils déjà équipées de connecteurs de type 230V. Du coup, les couleurs des fils ne sont pas standards.

Après quelques ajustements mécaniques dus à la nouvelle prise secteur, à l'origine montée sur la carte d'alimentation, j'ai pu (enfin) refermer le boîtier. Cela faisait certainement plus de dix ans que la machine était stockée 'le ventre à l'air', avec les vis du boitier en sac plastique sur la carte mère. Certains connaissent bien ce phénomène ;-)

Les LEDs placées sur l'alimentation permettent un contrôle rapide en cas de problème :

Le boitier est bien ventilé. Même si elle chauffe légèrement, la nouvelle alimentation ne transpirera pas trop!

Et enfin, la machine prête à expérimenter ses premiers échantillons sonores depuis peut-être une vingtaine d'années :

Parce que j'ai trouvé récemment sur le Net, des ressources en échantillons au format HxC. De plus il existe une application Atari ST pour gérer cette machine. Et comme je possède un clone récent d'Atari ST, un M.I.S.T. de Lotharek dont j'ai décrit la mise en fonction ici, j'ai bien envie de tester le tout...

Pour info, Lotharek propose toujours son M.I.S.T. à cet endroit sur son site au prix de 198,56€ (22/04/2020) soit une vingtaine d'Euros de moins qu'à l'époque ou j'avais acheté le mien (04/2016).

A noter aussi qu'il existe une autre alternative que je n'ai pas testé, qui est le MISTER. Même principe de re-création d'un ST sur FPGA mais cette fois, basé sur une carte du commerce DE10-nano fabriquée par TerasIC sur FPGA Altera, pardon, Intel maintenant :

Publicité gratuite pour TerasIC!

Il existe tout un environnement de développement de Cores logiciels et de cartes additionnelles pour ce kit DE10-nano, permettant d'implémenter un grand nombre de rétro-ordinateurs et rétro-consoles.

Au final, il ne me restera plus qu'à remplacer le processeur de cet ADS pour un modèle faible consommation, à rajouter une carte d'extension mémoire et la machine sera au top!

Corona : activités d'éveil n°5, DPS-V77 bloquée, retour à la vie d'un Dynacord ADS.

Garder la forme!

Et donc, continuer à maintenir à un haut niveau son élasticité intellectuelle ;-)

1 - Retour sur une carte de développement à base de processeur Z80, le Wichit Sirichote Z80 MICROPROCESSOR KIT  : 

Il y a un peu plus de trois ans maintenant, j'avais acquis ce kit et l'avais monté. Je trouvais l'idée générale de ce produit plutôt bonne et pertinante. Après avoir réalisé quelques programmes fonctionnels, j'ai quelque peu remisé cette carte après l'avoir passée en mode compatible uPF1 :

https://www.worthpoint.com

Entre temps, j'ai retrouvé une carte imprimante que j'avais récupérée il y à fort longtemps (1987), suite à quelques études en informatique et expérimentations sur µPF1 Plus, et ai acquis une carte d'extension proposant des entrées/sorties parallèles, séries, ainsi que la disponibilité de timers, le tout fourni par des circuits intégrés de marque exclusivement Zilog :

J'ai donc eu dans l'idée de tenter de faire fonctionner ces deux cartes d’extension avec le kit Z80, sachant que Wichit Sirichote a bien fait attention, lors de la conception de son kit, à respecter le brochage du connecteur d'extension. Avant toute chose, il m'a fallu retrouver les outils nécessaires à l'écriture de code pour ce type d'ancien matériel. A l'époque, j'avais utilisé l'IDE Code::Block et le compilateur SDCC. Le compilateur est toujours très activement maintenu. Cela n'a donc posé aucun problème pour le ré-installer. Par contre, Code::Block ne semblait plus proposer de grosse activité de développement depuis au moins deux ans. Et en retournant sur la page de cet IDE, j'ai constaté avec plaisir qu'une nouvelle version avait été publiée en mars de cette année. J'ai donc installé également cet IDE et n'ai pas eu le moindre problème à générer du code pour la carte processeur.

C'est par la suite que tout s'est compliqué. Le code d'exemple de la calculatrice ne voulait absolument pas fonctionner de nouveau sur la carte. Pourtant cet exemple fonctionnait après avoir passé le moniteur en version compatible µPF1.

Oui mais....

En fait j'avais téléchargé, à l'époque, le code de la calculatrice dans cette carte équipée d'un système de mémoire sauvegardée de ma conception :

SRAM auto-sauvegardée.

Puis, j'avais changé le programme moniteur du kit. Je n'avais donc pas téléchargé le programme d'exemple à l'aide du dernier moniteur. Au démarrage de la carte, j'avais pu relancer sans problème l'exemple de la calculatrice. Les segments CODE et DATAS initialisés étant compatibles avec les segments du nouveau moniteur µPF1.

Or entre temps, je me suis servi de cette SRAM sauvegardée dans un synthétiseur et ai donc remis en place une SRAM standard. Ce faisant, j'ai donc perdu le code de la calculatrice qu'il m'a fallu recharger par liaison série. A partir de ce moment, je n'ai plus réussi à faire fonctionner cette calculatrice.

Comme j'avais installé un nouveau compilateur, j'ai décortiqué le code assembleur produit et ai vérifié la conformité avec le code hexa produit. Petit travail que je n'avais pas effectué depuis le début des années 90. Rien à faire, tout semblait correct.

Un code très simple, genre clignotement d'une LED fonctionnait cependant. J'ai alors suspecté la routine de réception par la liaison série. Ce qui m'a permis de constater qu'effectivement un dump du code hexa de la mémoire de la carte ne correspondait pas à celui envoyé depuis le PC.

Pour être plus exact, le dump mémoire présentait un code erroné à intervalle régulier, environ un code erroné tous les 150 codes. J'ai alors étudié le source du moniteur pour me rendre compte que la réception des codes série se fait grâce à l'utilisation de temporisations ponctuelles (des boucles vides ajustées au NOP). Après un certain nombre de tentatives de corrections du moniteur, je me suis assez vite rendu compte que tout ce que j'arrivais à faire était de modifier la fréquence d’occurrence des codes erronés. Partant, je n'ai jamais réussi à télécharger plus d'un koctets dans la carte sans erreur de réception.

Pour modifier le moniteur sur la carte, j'ai utilisé ce très bon émulateur de ROM Memsim2 de Momik : 

Son seul 'petit défaut' est qu'il ne propose pas de fonctionnement en mode SRAM. C'est à dire qu'il ne gère pas le mode écriture. C'est un peu dommage, mais pour le prix ce matériel est parfait.

Pour faire court : le concepteur de la carte Z80 a utilisé un bit d'entrée/sortie, matérialisé sous la forme du bit de donnée D7 pour générer de façon logicielle par le processeur Z80, le codage et le décodage des trames séries : 

Le tout synchronisé par de la quantité de NOP nécessaire. Bien que la détection du bit de start soit correctement effectuée par le moniteur, rien n'y a fait. Malgré mes ajustement de temporisations, le téléversement d'un fichier hexa a toujours présenté un problème. Je retrouvais toujours quelques codes erronés dans le dump mémoire de la carte. J'ai testé le câble série que j'avais réalisé pour l'occasion, ainsi que deux interfaces USB/série sans détecter quelque problème que ce soit.

Las, j'ai fini par stopper mes investigations. La raison principale est que d'une part cette façon de faire pour le codage/décodage des trames série offre une fiabilité toute relative, et surtout impose un débit faible de 2400 Bauds pour laisser le temps au Z80 d'effectuer le travail de codage/décodage. Même sur un fichier relativement court, cela prend du temps. A l'utilisation, c'est vraiment pénible. De plus, cela n'est pas spécialement une bonne idée que d'avoir implémenté un port série à la norme RS232.
Cela impose aujourd'hui l'utilisation d'un convertisseur USB. Or, même en ayant à l'esprit la notion de Kit facile à assembler, il existe des modules convertisseurs faciles à souder, permettant de ne pas avoir à tenter la soudure d'un composant cms :

Exemple de convertisseur USB/Série disponible pour quelques Euros/

Il n'est pas non plus possible d'utiliser un émulateur d'EPROM comme celui présenté plus haut pour charger directement la RAM avec du code. Le moniteur utilisant des variables dans la même RAM et ne pouvant écrire ses données puisque l'émulateur d'EPROM n'est pas pourvu de la fonction write, il ne démarre plus!

Et pour finir sur ce kit, l'idée d'avoir connecté le buzer sur la sortie d'émission série est assez 'mauvaise'. Un petit interrupteur aurait pu être intéressant pour stopper ce bruit pénible lors des dumps mémoire. Enfin, une solution de sauvegarde de la mémoire statique aurait pu aussi être intéressante, histoire de retrouver son travail après arrêt de la carte, ou mieux, implémenter un auto-démarrage sur le moniteur afin de pouvoir s'en servir d'automate, à la façon d'un Arduino par exemple.

Au final, malgré de bonnes idées, ce kit n'est pas vraiment exploitable de façon sérieuse. Il est vrai que Wichit Sirichote l'à proposé en 2017, année représentant peut-être l'apogée de l'engouement pour le rétro-computing. Depuis, l'attrait pour ce type de produit semble un tantinet retombé, la simple présence de ce type de kit ne suffit plus. Le service rendu doit aussi être considéré. Et surtout il n'est pratiquement rien apparu de nouveau ces vingt dernières années en terme de remplaçant à l'Amiga et l'Atari. Je 'dis' bien remplaçant. Je ne parle pas des upgrades ou clônes disponibles depuis longtemps.

Pour l'heure, il semblerait que le processeur 65C816, un compatible 6502 de chez Western Design Center rencontre un certain intérêt. Il propose un fonctionnement en 16 bits avec ALU 16 bits et 16Mo d'adressage mémoire :

Une vitesse de 14MHz n'est pas transcendante mais n'oublions pas ce qu'étaient capable de faire les premiers Macintosh avec un 68000 à seulement 8MHz!

2 - 'Petit' dépannage d'un rack d'effet Sony DPS-V77 :

Il s'agit d'un rack d'effets standard, mais de qualité professionnelle fabriqué par Sony. C'est une très très bonne machine. 

Après avoir été remisée un long moment, et à la faveur d'une longue période de présence forcée chez soi, il est temps d'en vérifier le fonctionnement.

A sa mise sous tension, je me suis retrouvé avec un affichage LCD figé sur l'écran de démarrage et des segments allumés de façon erratique sur le double digit rouge et sur le vu-mètre :

De façon aléatoire, il arrivait cependant qu'un chiffre 'réel' soit affiché sur les deux digits rouges, mais la machine restait ostensiblement bloquée sur l'autruche du LCD. Et pourtant, la dernière fois qu'elle fût allumée, elle fonctionnait parfaitement.

Seule différence, la pile de sauvegarde était bien évidemment vide. Je l'ai donc retirée. Tout laissait à penser qu'un problème électronique empêchait le processus de démarrage d'aller à son terme. J'ai donc passé une paire d'heures à tester les alimentations, puis à l'aide de l'oscilloscope, à vérifier la présence des signaux importants. De fait, rien ne me semblait poser problème.

Alors avant d'aller plus loin, j'ai lancé les diagnostiques présents dans la machine. Quelques touches appuyées à l'allumage permettent de basculer le système en mode diag. Je pus constater avec presque 'désespoir' que tous les diags passaient sans problème.

Alors j'ai envisagé le pire de la bêtise : la ram de sauvegarde corrompue et aucune fonction de tests d'intégrité, que ce soit en mode diag ou en mode normal, ayant pour effet d'envoyer tout simplement le programme dans 'les choux' au démarrage. Après tout, ça ne serait pas la première machine sur laquelle je constaterais ce problème, et je n'ai vu aucun message de pile de sauvegarde faible sur l'écran.

La documentation indique comment effectuer une initialisation au démarrage. La encore, quelques touches du clavier appuyées lors de la mise sous tension permettent de basculer dans le mode INIT. Il suffit de lire les instructions à l'écran, d'accepter, et c'est fait.

Et miracle, la machine redémarre normalement : 

N'importe quoi vous ne trouvez pas? Aucun message d'erreur de pile faible et une machine qui donne tous les signes d'une panne assez féroce, juste pour une pile de sauvegarde vide!!!

Et ce n'est pas tout! l'afficheur présente des lignes et colonnes manquantes. Et c'est normal, hélas. De la façon dont est conçu cet afficheur, ce problème est inéluctable : 

Contrairement à TOUS les afficheurs de ce type ou la plaque de verre se trouve du côté des contacts dorés véhiculant les signaux des circuits intégrés d'affichage, ici, c'est l'inverse. Se faisant, il est nécessaire de transférer ces signaux à l'aide d'un film plastique contenant moult connexions microscopiques vers l'autre face du circuit imprimé. Et le pire est que l'extrémité de ce film est juste collé à l'aide d'une colle spéciale sur les contacts dorés. Et oui, pas soudé mais collé!

Au bout d'un certain temps, cette colle se désagrège et des pertes de contacts entre le circuit imprimé et le film plastique apparaissent, d'ou les lignes ou colonnes manquantes. Et comme il s'agit d'un afficheur spécial, introuvable dans le commerce, et bien c'est irréparable. La seule solution consiste à trouver une machine de ce genre en panne mais avec l'afficheur totalement fonctionnel. Autant dire mission impossible!

Et pourtant, que ce soit la plaque de verre contenant les cristaux liquides ou les circuits intégrés de l'afficheur, tout est parfaitement fonctionnel. Conception stupide, vous ne trouvez pas?

Au final, cette machine fonctionne parfaitement mais quand même, de la part de Sony!!!

J'ai mis le mot-clé DPS-V77 dans le titre de cet article afin que ces informations de dépannages soient indexées par les moteurs de recherche. Cela pourrait rendre service à d'autres que moi et éviter la perte de quelques heures de diags inutiles!

3 - Alimentation d'un JX10P :

Cela fait un moment que j'ai récupéré ce 10P. Je possède son petit frère le 8P depuis un peu plus d'un an. Ces deux synthés génèrent des textures que je trouve très professionnelles. Le 3P et le MKS-30 sont à mon avis un cran en dessous. Le 10P est en fait un double 8P puisqu'il possède deux cartes de synthèse 8P gérées par une carte centrale appelée Assigner Board.

Ce Super JX était dans un état déplorable. D'ailleurs la carcasse est constellée de points de rouille. N'empêche, j'ai résolu tous les problèmes électroniques de voix manquantes, et autres défauts. Par contre, à l'époque je n'avais pas constaté de bruit de 50Hz sur les signaux audio.

Au redémarrage de la machine, cette fois une 'ronflette' était fortement présente. J'ai donc remplacé les condensateurs 'auxiliaires' de l'alimentation, opération de routine s'il en est :

Cette image est reprise de l'excellent site : http://llamamusic.com/super-jx/info.html

En ce qui me concerne, je n'ai pas remplacé les trois gros condensateurs. Je les ai vérifié, ils étaient en bon état. Par contre j'ai remplacé les autres : 

Cette simple intervention à considérablement réduit les bruits parasites. Il faut pousser le gain de la table à fond pour entendre non plus du 50Hz, mais le bruit intrinsèque des AOP de sortie. Je me demande d'ailleurs si une partie de ce bruit ne provient pas de parasites générés par la carte de contrôle.

Ceci écrit, la conception de cette alimentation est un peu baroque puisque l'instabilité d'une des tensions de sorties peut avoir pour effet de rendre instable les autres sorties, voir d'amplifier le problème! Le régulateur employé pour les alimentations symétriques me semble assez sensible. J'ai d'ailleurs remplacé le condensateur de 'stabilisation' de sa sortie par un modèle spécifique non chimique.

Sur le site https://supersynthprojects.com/ vous trouverez la description d'une alimentation  moderne spécialement étudiée pour ce synthé : 

Sur ce Super JX, et puisqu'il est de nouveau démonté, je vais en profiter pour remplacer les switchs tactiles avant de le remonter. Ceux de sélection de patchs sont notoirement oxydés et ne répondent plus bien du tout. Cela rend la manipulation du synthé beaucoup moins confortable :

Enfin, comme la manipulation du panneau de commande de ce type de synthé des années 80 est très malaisée, et comme je possède aussi un 8P, j'ai acquis il y a quelques semaines de cela un module de commande externe MPG-8 de Retroaktiv testé à cet endroit :

Publicité gratuite.

Cet instrument de musique 'aurait' pu être une très bonne machine. Je suis convaincu que son développement a été réalisé à l'économie. Cela se ressent sur le châssis métallique, sur la disposition de cartes internes, sur les bugs de l'Assigner Board etc etc... D’où les multiples améliorations développées au fil du temps pour le rendre plus fiable et plus performant.

4 - Alimentation +12V / -12V 1,5A et 5V 3A :

J'ai décrit cette alimentation il y a une semaine à cet endroit. Voici ce à quoi elle ressemble : 

Cette alimentation intègre le meilleur des mondes du découpage et du linéaire. Elle propose une bonne compacité, une bonne sécurité puisqu'il n'y a pas de 300V à se promener au primaire de l'alimentation, un rendement assez élevé par rapport à du tout linéaire, un échauffement moindre et une poste régulation linéaire de la tension symétrique pour un bruit parasite plus faible.

A l'origine, j'ai 'récupéré' cette alimentation d'un développement disponible sur Internet à cet endroit et librement copiable. C'est ce que j'ai fait car j'ai acquis ce 'fameux' générateur de signal FY6900. Je ne possédais pas ce type d'instrument mais à la suite de mes dépannages sur deux SP12 EMU, je me suis rendu compte que ce type d'appareil m'aurait été bien utile : 

Ce générateur est assez populaire car plutôt performant et disponible à prix bas sur Banggood au prix de 80,37€ hors frais de port le 20 avril 2020, grâce bien évidemment à la 'mondialisation heureuse'. Le pendant d'un tel prix est, en ce qui concerne cet appareil, une qualité de signal quelque peu entachée par la piètre qualité de l'alimentation. Une alimentation à découpage de base et de petite puissance : 

https://sdgelectronics.co.uk/fy6900-signal-generator-power-supply-modifications/

Fonctionnelle, mais sans plus. D’où l'intérêt du développement de cette nouvelle alimentation. Voici ce à quoi elle ressemble une fois montée : 

Il y a une semaine, j'indiquais ne pas posséder le régulateur linéaire pour le -13.6V en boitier adéquat. Hors j'en possède en version TO220 dont la seule différence est de posséder une semelle métallique plus grande que celles des boîtiers préconisés. Cependant, le dessin du circuit imprimé peut tout à fait accepter des boitiers TO220, le dessin des pistes fait qu'une semelle plus grande n'a aucun chance de rentrer en contact avec une piste différente. 

J'ai donc placé un LM337 en boitier TO220. A la mise sous tension, toutes les alimentations étaient présentes et correctes. J'ai donc pu implémenter cette nouvelle alimentation dans l'appareil de mesure :

Boitier démonté.

Alimentation d'origine retirée et remplacée par celle de 24V DC.

Test de l'alimentation 24V DC.

Mise en place, câblage et test de la partie 5V et +/- 13,6V.

Vue de dessus.

Voilà, rien de plus à commenter. Le générateur de signal fonctionne parfaitement. Sur le site de Steve Gardner (SDG), il est indiqué l'ajout de refroidisseurs et d'un ventilateur pour évacuer la chaleur dissipée par les régulateurs de l'alimentation et par l'électronique de l'appareil. 

Après avoir laissé ce générateur de signal alimenté durant plus de 24h, boitier remonté, je n'ai pas constaté de dégagement de température élevée. L'appareil reste légèrement tiède ainsi que les régulateurs de l'alimentation. Je n'ai pas testé le courant consommé mais à la vue des fils d'alimentation, cela ne doit pas dépasser les 500mA.

4 - Alimentation d'un échantillonneur Dynacord ADS, du pur vintage :

Je possède cette machine depuis fort longtemps, depuis 2003 je pense puisque j'ai retrouvé une facture concernant l'achat de deux cartes mémoires additionnelles datée d'octobre 2003. Je les avais achetées quelques mois après l'achat de cet ADS : 

http://www.deepsonic.ch

A l'époque, ce qui m'avait décidé à acquérir cette machine était le souvenir d'un son vraiment percutant, incisif. D'ailleurs Dynacord en avait une version spécialement dédiée aux sons de batterie, l'ADD TWO. Je l'avais entendu plus de 10 ans plus tôt au feu salon de la musique de la Villette, fin 80. 

Je n'ai jamais pu réellement tester cette machine car l'alimentation à découpage d'origine à cessée de fonctionner assez rapidement après son achat. Cette alimentation manque de fiabilité et 'plante' dans presque tous les ADS s'ils ont été un peu sollicités. Il s'agit d'une alimentation spécifique, au format lui aussi spécifique. Donc, très difficile à remplacer.

Malgré plusieurs tentatives de dépannages, je n'ai jamais réussi à faire fonctionner cette alimentation. Elle possède un module situé à côté du transformateur haute tension qui n'est pas dépannable : mauvais point pour Dynacord.

http://www.deepsonic.ch

En fait c'est cette machine qui m'a incité il y a quelques mois déjà à envisager la création d'une alimentation de remplacement. Raison pour laquelle j'ai sauté sur l'occasion de la description d'une alimentation telle que celle ci-dessus présentée pour envisager de m'en servir dans cet ADS. Réaliser une alimentation à découpage n'est pas simple mais pourrait tenir dans le boitier. En réaliser une totalement linéaire impose d'utiliser de bons radiateurs de refroidissement et prend donc bien plus de place.

Place au test de l'alimentation (SDG) sur cet ADS:

Comme l'on peut s'en douter sur cette image, cela fonctionne. Cela faisait très longtemps que je n'avais pas vu quoi que ce soit d'affiché sur cet afficheur : 

Cela fait bien plaisir!

A noter que pour cette application, j'ai modifié la sortie en tension des régulateurs analogiques pour fournir +/- 12,6V au lieu des +/- 13.6V d'origine. Les régulateurs n'ont qu'un volt supplémentaire à faire chuter ce qui n'augmente pas significativement la quantité de chaleur produite puisque la consommation reste très limitée sur cette partie de l'alimentation. Pour bien faire j'aurais aussi du baisser d'un volt les sorties des pré-régulateurs à découpage. Cela aurait augmenté le rendement global de l'alimentation. Je ne l'ai pas fait.

Maintenant la question posée est : est-ce que cela peut convenir à cette alimentation.

Dans le principe oui. Dans les faits... pas trop!

Pourquoi? La partie 5V consomme de trop. Avec l'ADS équipé de ses trois cartes d'extensions mémoire, donc poussé au maximum de ce qu'il est possible, la consommation sur le 5V atteint 2,6A.

Le régulateur à découpage utilisé est donné pour 3A, donc tout va bien. La consommation sur le 5V est de 13W. Le convertisseur 230V AC vers 24V DC peut fournir 26W et la consommation sur l'alimentation symétrique est bien inférieur à celle de 5V. Donc à ce niveau, tout va bien aussi.

N'empêche, la régulation 5V chauffe. Cela reste inférieur à 45°C mais la petite diode de commutation qui ne possède pas un gros boitier de dissipation chauffe plus. Cela peut poser quelques problèmes à la longue.

La solution consiste simplement à retirer tout ou partie des cartes d'extensions mémoire. A raison de 300 mA  de consommation par carte, j'en ai retiré deux :

Ce qui divise le temps d'échantillonnage par deux mais laisse quand même plus de 22 secondes de capacité en stéréo à 44,100 KHz. Ceci présente donc un bon compromis :

A environ deux Ampères de consommation sur le 5V, l'ensemble des composants de l'alimentation chauffent légèrement. C'est un peu plus chaud que tiède mais reste très raisonnable. 24 heures d'alimentation continue ne génère aucun problème.

Pour l'heure, la machine est équipée d'un processeur HMOS 68000P8 de base qui consomme environ 1,35W soit quelques 270mA, autrement dit, la consommation d'une carte mémoire. La version CMOS consomme, elle, 0,13W à 8MHz, soit environ 26mA.

Avec un tel processeur CMOS et une extension mémoire supplémentaire j'arriverais théoriquement à une consommation de 1,988A sur le 5V, toujours inférieur à 2A, mais pour cette fois 34s de temps d'échantillonnage en stéréo et carrément plus de la minute en mono. Cela me paraît être un bon upgrade à prévoir.

Il ne me reste plus qu'à installer cette alimentation dans cet ADS. Je mettrai peut-être en place un petit transformateur toroïdal à la place du module à découpage de 24V. Je n'ai pas encore décidé...

Voilà, c'est tout pour le moment. Les quelques semaines de confinement à venir vont me permettre d'avancer encore un peu sur quelques sujets. Comme quoi, il est possible de tirer profit de cette situation pas nécessairement agréable!