J'ai déjà eu l'occasion de dépanner une telle boîte à rythme, c'était en juillet 2016. A l'époque, j'avais acheté cette machine qui présentait quelques petits défauts de fonctionnement, dont le 'fameux' BAD au démarrage. Pour l'occasion, j'avais décidé de développer un petit système de diagnostics se présentant sous la forme d'une carte processeur à base de circuit ATmega328, à enficher à la place d'un processeur Z80. Doté d'une programmation adéquate, cette carte de diag devait me permettre de prendre le contrôle de la Drumulator et d'en tester les différentes parties.
 |
| Première version à droite et version finale à gauche. |
Cette nouvelle Drumulator ne s'allume pas du tout donc de toute façon la ROM de diags EMU aurait été inutile. Le propriétaire de la machine m'a indiqué avoir eu des problèmes d'alimentation et avoir changé les condensateurs de filtrage de la partie analogique ainsi que que les régulateurs 15V positifs et négatifs. D'autre part je constate que la machine a sans doute subi plusieurs interventions puisque l'optocoupleur pour l'interface MIDI est présent, ainsi qu'un condensateur de filtrage 100nF remplacé sur un circuit logique.
Comme la machine ne donne aucun signe de vie, la première chose à vérifier a été les tensions d'alimentation. Rien à signaler de ce côté-là, si ce n'est une alimentation un peu élevée pour les RAM statiques, mais rien de dramatique : 5,4V. A l'oscilloscope par contre, la situation est plus alarmante. Si le signal d'horloge de 2,4MHz est bien présent, le bus d'adresse du Z80 'semble' bloqué à une même adresse haute (A15 = 1), sans évolution. Pas très engageant tout cela!
J'ai donc inséré mon système de diags en lieu et place du Z80 :
Puis j'ai tenté l'exécution du premier test, à savoir l'allumage séquentiel de tous les segments et LEDs de la machine :
Le résultat se soldant par absolument aucune réaction à l'affichage. Ce test est pourtant simple et met en jeu un minimum de composants de la partie processeur. J'ai donc retiré tous les circuits sur support, ainsi que les deux RAM 14J et 15J de type 2114 directement soudées sur le circuit imprimé, et pour lesquelles j'ai aussi prévu des supports. Le système de gestion des afficheurs/LEDs étant minimal, j'ai donc tenté d'allumer au moins un segment 'à la main' afin de vérifier le fonctionnement du système. Ce qui fût validé. Après examen approfondi, il s'est avéré que c'était le circuit 13J, un 74LS138, qui ne réalisait plus sa fonction de décodage d'adresse :
J'en ai profité pour mettre aussi ce circuit sur support, on ne sait jamais.
Confiant, j'ai donc inséré une RAM statique de type 6116 pour y effectuer le test de lecture/écriture. C'est à partir de ce moment que tout s'est réellement compliqué et que les heures de tests et de questionnements se sont accumulées.
En effet, le test ne se déroulant pas correctement avec un affichage de données vraiment étrange, il m'a fallu un certain temps pour constater que le système de sélection des différents circuits ne fonctionnait pas. Le sondage à l'oscilloscope m'a permis de découvrir que le circuit 15F, un quadruple portes OU ne générait plus les signaux MEMWR.D et MEMRD.D. De la même façon que précédemment, j'ai aussi placé un support de circuit avant de remplacer ce composant.
De plus, j'a pu constater que suite au remplacement de ce circuit, les signaux MREQ-RD-WR générés par mon circuit de diags étaient redevenus corrects alors que précédemment, ils semblaient rester au niveau logique '1', soit 5V. Cette constatation étant vraie alors qu'aucun circuit mémoire n'était installé, mais redevenait fausse dès lors qu'au moins une des deux 6116 était installée. Donc, les mémoires de 2Ko SRAM semblaient poser problème. La mise en place du seul exemplaire réputé fonctionnel en ma possession m'a donné le même résultat.
Donc, le problème semblait venir d'ailleurs. Après un certain temps passé à l'oscilloscope sur les signaux des RAM, j'ai décidé de contrôler leur alimentation. Et la, grosse surprise, la tension d'alimentation présentait une espèce de sinusoïde évoluant de 5V à... plus de 10V. Le piège absolu!!!
Non seulement la fréquence de cette 'sinusoïde' m'empêchait de constater de façon évidente le problème avec mon multimètre 'TRUE RMS' puisque le signal comportait une forte composant continue et que la fréquence d'oscillation était bien plus élevée que le 50Hz, mais de plus les mémoires statiques ne chauffaient pas puisqu'elles n'étaient pas constamment soumises au 10V d'alimentation. A noter aussi que la sinusoïde n'était pas non plus vraiment une sinusoïde....
Dès lors, quelques minutes d'examen de la partie alimentation, et quelques tests à l'oscilloscope m'on permis de trouver rapidement le problème :
Grand classique de l'alimentation sauvegardée...
Les RAM statiques sont alimentée par le +5M.P, en fait du 'presque' 5V. Deux diodes D1 et D3 sont placées pour aiguiller soit l'alimentation +3,2V de la batterie, soit le +5V fourni par le régulateur VR1 vers les mémoires. Le +5V fourni par l'alimentation générale (VR1) prenant automatiquement le dessus dès son apparition. La diode D2 de type 1N914 est placée dans la ligne de masse du régulateur VR1 pour ramener sa référence à +0,6V au dessus de la masse. De ce fait, VR1 délivre non pas 5V mais 5,6Vpar rapport à la 'vraie' masse. Les 0,6V supplémentaires étant 'supprimés' par la diode D1 (tension de seuil), de sorte que les RAM statiques sont alimentées à environ 5V en fonctionnement.
Tout cela semble magnifique, sauf que si la diode D2 qui référence la masse du régulateur à +0,6V au dessus de la masse commune disparaît, et bien le régulateur ne régule plus et fournit pratiquement la même tension que celle qu'il reçoit en entrée. Dans le cas de cette Drumulator, VR1 reçoit un peu plus de 11V et fourni donc un joli 10V. La petite 'gâterie' sur cette machine, est que cette diode 1N914 n'était pas franchement coupée mais oscillait entre un état coupé et fonctionnel selon une courbe périodique de forme sinusoïdale quasi aléatoire. ce qui rendait la détection de se problème pas franchement évidente.
 |
| La diode 1N914 défectueuse. |
Avant de continuer les tests des différents sous-systèmes de cette machine, il me semble imaginable de penser que, en faisant abstraction d'éventuels problèmes liés à des interventions techniques précédentes, cette diode 1N914, par son dysfonctionnement, a perturbé le fonctionnement du régulateur VR1 qui s'est mis à produire une tension trop élevée pour les deux circuits de RAM statique.
Ces circuits de RAM (j'en suis absolument sur pour au moins un d'entre eux) se sont mis à dysfonctionner eux aussi en plaçant de façon arbitraire les signaux des différents bus dans des états forcés (drivers d'entrées/sorties détruits). Dès lors, les impédances très faibles (pour ne pas dire nulles) des pattes de ces deux RAM ont fini par détruire les sorties d'autres composants et rendre le système de sélection totalement inopérant. Jolie réaction en chaîne...
Et ça n'est pas fini! Cette tension sauvegardée +5M.P alimente aussi le circuit de génération des signaux de sélection des SRAM. Ce circuit est censé être toujours alimenté, même lors de la coupure secteur, grâce à la sauvegarde par pile. Le rôle de ce circuit est d'empêcher la sélection accidentelle des RAM sauvegardée lors de la phase de démarrage et d'arrêt du processeur.
Ce circuit, référencé 13E sur le schéma est un circuit de type CMOS HEF4023. Les sortie n° 9, 10 et 6 ne réagissent plus du tout aux entrées et restent désespérément fixées à environ 2V. Ce HEF4023 devrait toujours fonctionner puisque, contrairement aux circuits TTL, sa plage de tension d'alimentation s'étend jusqu'à plus de 15V. Mais non, il est définitivement hors service. La aussi, il a fallu procéder à son remplacement, avec pose d'un support de circuit intégré au préalable, cela facilitera d'éventuelles nouvelles interventions. Ce circuit conditionne aussi l'accès aux deux RAM de type 2114 marqués 14J et 15J sur le schéma. Le test de ces RAM par mon outil de diagnostics m'indique que ces mémoires sont en erreur. J'espère donc régler aussi ce problème par le changement de ce HEF4023.
Progressons dans le dépannage de cette Drumulator... Le circuit HEF4023 a été changé, j'espère maintenant un tout autre comportement de mes tests par rapport à ce que j'obtenais précédemment :
Effectivement, cela se passe beaucoup mieux mais ça n'est pas encore ça! Les bits de donnée D4 et D5 restent à l'état logique '1' bien que D5 semble changer d'état de temps en temps. Il n'est encore pas possible de tester le fonctionnement de l'appareil, mais une 'sortie de crise' semble quand même se dessiner.
Après examen du schéma de cette Drumulator, il apparaît qu'un seul composant autre que l'outil de diags est en mesure de forcer l'état des bits du bus de données. Il s'agit du circuit 10J, un 14503 de type CMOS qui n'est plus fabriqué de nos jours. Ce circuit est utilisé en temps que buffer 3 états et, mis à part les bits de données D4 et D5, il transmet le code de retour des touches du panneau de commande sur le quartet de poids faible du bus de données. Après le test des touches avec l'outil de diags, ce circuit n'est visiblement pas à mettre en cause.
 |
| La partie du 14503 qui gère le bit de donnée D5. |
 |
| Et l'autre partie du 14503 qui gère le bit D4. |
Or, ce composant 14503 est sélectionné par un signal nommé CSRPB. Ce signal est généré par un simple circuit logique de type LS00 :
Et comme par hasard, la sortie n° 8 de ce 74LS00 reste la majorité du temps à l'état bas. Pas constamment, mais suffisamment pour sélectionner de façon périodique le circuit 14503 et ainsi perturber fortement les bits n° 4 et 5 du bus de données. Tout en générant, par le fait, un léger court-circuit pour le composant mémoire délivrant sa données sur le bus. Situation problématique. Les bits D0 à D3 ne sont pas perturbés parce que simplement reliés en pull-up de 10K par le circuit 14503. Et comme par hasard (encore), ce circuit 74LS00 référencé 13F est le circuit quelque peu modifié par l'ajout de l'entrée M.I.D.I. :
 |
| Le circuit 13F aurait-il subi quelques mauvais traitements? |
Cela ne se voit pas obligatoirement très bien, mais l'afficheur affiche bien le message bAd.
Quelques appuis sur les touches de la face avant de la machine m'indiquent que le système ne plante pas. Ouf, tout ça, pour juste ça! Il est vrai que la partie processeur de cette Drumulator souffrait de plusieurs maux simultanés qui a rendu très difficile la déterminations de la première bonne piste à suivre. Une fois trouvée, la suite s'est déroulée normalement. Je n'ai pas encore testé cette B.A.R. en audio. Je n'ose imaginer le dépannage de la partie numérique de la génération sonore. Il y en aurait encore peut-être pour des heures.
Pour l'instant, j'ai changé une diode petits signaux dans la partie alimentation, et quelques circuits intégrés logiques dans la partie processeur. Il serait aussi nécessaire de changer les supports de circuits intégrés d'origine par des modèles récents parce qu'ils génèrent parfois des faux contacts, ce qui rend le fonctionnement de la machine quelque peu problématique. Les deux SRAM 6116 sont évidemment défectueuses :
 |
| Définitivement H.S.! |
[Update 16/09/2018] J'ai procédé au remplacement de quelques supports de circuits intégrés. Les deux RAMs ainsi que le processeur sont passés sur supports de type lyre. Pour le plus grand bien de la machine. Bien que cette Drumulator semblait fonctionner correctement, il arrivait très régulièrement qu'elle reste plantée avec tous les segments et LEDs allumés. Le support du processeur Z80 ne procurait plus des contacts fiables. Après l'échange par un modèles récent et de bonne facture, la machine fonctionne dorénavant normalement :
Les supports de circuits d'origine sont munis d'une espèce de 'strip' dont je ne vois pas bien l'utilistési ce n'est lors de la phase de soudage à la vague, qui rendent leur retrait du circuit imprimé un peu plus compliqué. Les pins restant 'coincées' par ce strip de sorte qu'il faut presque avoir envie d'arracher la patte, plutôt que de la retirer délicatement, ce qui rend l'opération plus longue et délicate, évidemment :-(
Cependant, une fois l'opération terminée et la mise en place de deux RAMs statiques de 2Ko reçues neuves effectuée, la machine, après avoir démarré sur le message habituel 'bAd', à passé sans problème la phase de ré-initialisation.
La mise en place d'une pile neuve...
... a terminé le dépannage et la restauration de toute la partie processeur : ouf!
J'ai passé plus d'une dizaine d'heure en tout pour réussir à dépanner jusqu'au bout cette partie de la machine. La somme de pannes à répétition et en cascade à rendu le processus un peu plus difficile qu'à l'habitude. Certains problèmes étaient dus à la conception de la machine, d'autre, à de multiples interventions précédentes plus ou moins réussies.
Le test audio de la machine n'a pas été parfait non plus. Certes des sons sortent, ce qui est déjà un gros plus, mais pas tous. Heureusement, en retirant les UVPROM d'échantillons de leur support, je me suis assez vite rendu compte du problème :
Et me voilà maintenant à devoir recopier les ROMs d'origine parce que le set en place était un set spécifique installé par le propriétaire de la machine. La réparation d'une patte cassée est possible mais demande un certain temps. Il sera beaucoup plus facile dans un premier temps, de rendre la machine en état de fonctionnement au propriétaire. Charge à lui de retrouver des sets auprès d'un fournisseur 'sérieux' s'il le désir.
Les ROMs d'échantillons doivent être de type 27128. Ce sont là des versions de ROMs de 16Ko que l'on ne possède pas souvent. De 8Ko, on passe généralement au 32Ko, sachant que le brochage des 27256 est compatible avec celui des 27128. Si ce n'est que d'origine la broche 27 d'une 27128 est reliée au +5V. Ce qui correspond à la broche A14 d'une 27C256. Ne pas oublier de copier les données d'échantillon dans la deuxième partie des 32Ko d'une 27256 et non pas dans la première sinon la drumulator ne lira que des 0xFF, et donc ne fournira aucun son!
[Update 22/09/2018] Après toutes ces modifications et dépannages, j'ai enfin réussi à démarrer correctement la machine. Je pensais être arrivé au bout de mes peines mais en fait, non. D'une part je recevais, telle une injure', de façon très fréquente ce 'bAd' au démarrage, puis au fur et à mesure des tests, la machine s'est mise tout d'abord à rester plantée sur l'affichage total de tous les segments, puis de plus en plus fréquemment, à ne plus démarrer du tout!
En fait, et pour avoir discuté avec le propriétaire de la machine, sans le savoir j'avais certes règlé les problèmes les plus 'graves', ceux générés par des précédentes tentatives de dépannage, mais pas le problème de fond qui était qu'effectivement à la base, elle ne démarrait plus.
Quelques recherches m'ont permis de constater que le signal de RESET du processeur ressemblait fortement à un signal périodique. Comme signal de RESET, il y a mieux. En fait, le CA3086 qui gère le test de bon fonctionnement des alimentations était en cause :
J'ai donc changé aussi ce composant par un modèle équivalent, un CA3046 que j'avais sous la main.
Cela me permis évidemment de progresser dans la résolution du problème avec un démarrage normal à la mise sous tension. Démarrage normal ne survenant toutefois que de temps en temps, et de moins en moins souvent! Le problème était très simple : le signal de RESET, bien que de forme normale cette fois, arrivait bien trop rapidement au processeur. Comme tout processeur, le Z80 nécessite un certain nombre de cycles d'horloge avant de réellement être en mesure de démarrer. Durant tout ce temps d'initialisatoin interne du Z80, le signal de RESET DOIT être actif. L'ajout d'un petit condensateur entre la patte 1 et 3 de ce CA3046 a réglé ce problème.
Cette modification effectuée, la machine s'est mise à redémarrer de façon certaine à chaque mise sous tension. Et ceci, de façon fiable. Par contre subsiste le message 'bAd' au démarrage. Après mise en place de condensateurs de découplages sur la carte de la machine, la situation s'est améliorée, sans plus. Ce qui se passe est assez simple : à chaque allumage et démarrage, la tension de 5V fournie par le régulateur à la partie processeur connait de brefs et violents parasites. Ces parasites sont suffisamment important pour se propager à travers le système de sauvegarde par pile et donc désalimenter très brièvement les deux SRAM sauvegardée. Le résultat est imparable : 'bAd'!
Je n'ai hélas pas réussi à déterminer la cause de ce phénomène. Soit un problème en provenance du transformateur, ou alors une des diodes du pont de diodes qui laisserait passer un courant contraire etc etc... Etant donné le nombre d'heures passées à dépanner cette machine, je n'en ai pas rajouté et l'ai donc rendu en l'état à son propriétaire. Un indice cependant me laissait à penser que ça n'est pas parce que la machine affiche 'bAd' au démarrage, que le contenu des mémoires serait perdu. Et ce fût le cas. Quelques modifications de paramètres lors des essais, ont été conservés. Je pense donc que le problème vient réellement de l'alimentation, mais je ne sais pas ou.
Il n'y a pas à dire, elles sonne cette Drumulator, surtout branchée sur un ampli digne de ce nom!
What next?
J'en ai profité, lors de ce dépannage, pour dessouder la mémoire contenant les instructions du séquenceur qui génère les ondes audio. Le fonctionnement des registres, tel qu'expliqué dans la documentation technique n'est pas très difficile à appréhender. Mais la lecture du contenu de cette PROM (IC8D) m'a permis de valider le concept.
D'autre part, je me retrouve avec quelques sets d'EPROM d'échantillons dont le fonctionnement est altéré du fait de pattes de composants cassées. Le même syndrome que ci-dessus...
Je vais donc tenter de découvrir ou se situent les adresses en mémoire programme, contenant les informations de début et de durée de son. Cela me permettra de créer des sets complets. Ce 'service' se trouve déjà sur Internet, mais sous forme disons, 'pas zéro défauts'!
D'autre part, je viens de recevoir des exemplaires de filtres SSM2044, des SSI2144 :
Sachant d'autre part, que j'ai déjà il y a quelques mois, retranscris le fonctionnement de la partie processeur de la Drumulator dans un FPGA complexe, mais que j'ai pu valider récemment le fonctionnement de mon code dans un circuit de type Altera MAX10...
... je dirais que je possède pratiquement tout ce qu'il faut pour recréer totalement la machine!
Il 'semblerait' d'ailleurs que je ne sois pas le seul à être intéressé par une version plus fiable et un peu améliorée de la Drumulator!
A suivre...
[Update 22/09/2018]J'avais un doute sur le test des ram statiques avec mon outil de diagnostic. En effet, la mémoire numérotée 13K semblait toujours indiquer des erreurs de lectures. En fait, le bit d'adresse A11 de ma carte reste systématiquement à '0'. De sorte que je testais toujours le circuit de ram 15K, et jamais le 13K. M'en étant rendu compte, je testais donc les RAM sur le support 15K.
Je viens donc de tester mon outil de diag. Pour cela, j'ai créé une routine qui fait générer un signal carré d'à peu près 1KHz sur chaque port de sortie. Le bit A11 reste effectivement 'coincé' à '0'. Le circuit MCP23S17 semble donc devoir être remplacé. Comme ce circuit fonctionnait parfaitement sur ma propre Drumulator, je pense que le défaut a été généré par la Drumulator en dépannage : dommage collatéral, comme l'on dit!
