Affichage des articles dont le libellé est D-EMU Drumulator. Afficher tous les articles
Affichage des articles dont le libellé est D-EMU Drumulator. Afficher tous les articles

jeudi 20 février 2025

EMU : STOP!

Since my last post about trying to repair the EMU1, I've done a whole bunch of new tests. I also replaced a few integrated circuits. The result is that I haven't progressed one bit.

I still can't load the loading utility from the floppy disk. Whether it's from the actual floppy drive, or whether it's using the HxC emulator.

I now believe that I have carried out all the tests that I could. The problem in this story is that I absolutely don't know the loading program written in the boot EPROM.

It is not impossible, for example, that the motherboard must be correctly mounted in the machine so that information coming, either from the digital/analog conversion boards, or from the control panel, allows the program to exit a loop in order to actually process the data read from the floppy disk.

From what I have done as tests on the motherboard, I know that all the logic for shaping the signals coming from the floppy drive works. As well as serial reception by the SIO/2. Selection by a few PIO output ports also works. Finally, I know that the RAM does not have defective memory.

So I was finally able to test the signals concerning the triggering of DMA when reading floppy disks. And here too, everything seems correct to me. However, the machine obviously tells me that the data coming from the floppy drive is not reliable. I don't understand the reason.

However, the fact remains that the data bus signals are horrible! I also worked on this aspect, managing to obtain very square signals. However that wasn't enough, I always get into a loop trying to read the data without ever getting out.

So, given the time spent doing all these tests and the results obtained, it is high time to stop wasting it like this.

I reassembled the machine. I'm now opting to throw it into scrap metal because in its current state, it's worth absolutely nothing.

No final decision yet...

Regarding the FPGA of a Drumulator, I'll stop there too.

I twice managed to integrate the Drumulator's processor core into two different brands of FPGA. I have been trying the same thing on TRION type FPGAs from Efinix for months now without achieving anything usable.

In fact, right now I know the heart is starting well. It shows me the message 'bAd.' at startup, but immediately, by displaying anything.

This is all the more strange as the interrupt system works well since the message is displayed correctly. But afterwards, the processor seems to go 'I don't know where'. And this is not very easy to test with a standard logic analyzer due to the difficulties in triggering signal sampling.

In addition, I must add that the development software is a bit 'boring': not flexible and above all really very slow. This thing is a real pain, even with a powerful PC. So as in addition, the development tool tends to annoy me a little, and the pseudo-integrated simulation system is not helping the matter, and given the time I have already spent trying to integrate the heart of the Drumulator into this FPGA, I will stop.

Also, I don't know the intricacies of the system of this machine. In fact, it is extremely difficult to move forward when something goes wrong. Indeed, there is virtually no way to know for sure where the problem is coming from. After a while, this type of situation is simply no longer bearable.

The idea was to build a hardware environment compatible with the Drumulator in order to be able to run the machine system there. It seemed 'easier' to do. Observations made, I now say to myself that it would undoubtedly be less complicated to develop everything using equipment that is more practical to use.

I've been working a lot lately on small RISC-V microcontrollers. The development software, which was not very practical a few years ago, has been superbly improved in recent months. And above all, working in this way allows you to carry out debugging in real time. And that’s super interesting.

And as these small microcontrollers operate internally at 144MHz, this provides quite acceptable processing power for this type of machine. And after all, I did this to recreate a programmable clock whose behavior is identical to that proposed in the Texas Instruments TMS1122 of the time!

So I'm still a little sorry for this situation because these two projects made me consume a lot of time without achieving any result. Not to mention the psychological aspect of it, because it is not easy to persevere when there is no sign of improvement. It's even more difficult to abandon a whole job to start again with another method.

But hey, to move forward, you still have to make choices, at some point...

The positive point of all this was to realize that I have lost a progression methodology that I had when I was very young. I know the reasons of this degradation...


jeudi 13 décembre 2018

Drumulator OS SWITCHER

Après quelques modifications mineures de la première version du circuit imprimé dédié au switch de l'OS, voici à quoi devrait ressembler le circuit final:



Je viens de lancer la fabrication du premier batch de cartes.

Pou rappel, cette carte apporte les fonctionnalités suivantes : 
  • Possibilité de switcher entre deux OS.
  • Commande le switch des Wave Rom associées.
  • Ajoute une banque supplémentaire de SRAM sauvegardée.
  • Remplace la pile de sauvegarde par une simple pile 20CR32 sur support.
  • Implémente l'interface M.I.D.I.
Il n'y a plus qu'à attendre les circuits et effectuer les tests fonctionnels...

mercredi 7 novembre 2018

Drumulator et FPGA

Dès lors que j'ai commencé à travailler sur la boite à rythme Drumulator achetée il y a deux ans en pas très bon état, je me suis dit que cela pourrait être 'sympa' de recréer la machine avec les technologies modernes. Il est vrai que le côté 'roots' et vintage de la machine plaide en sa faveur :


De plus, depuis quelques temps je travaille sur un adaptateur de WAVE ROMs pour rendre la mise en place de sets de batteries plus pratique. Il est vrai que ce genre de customisation est très en vogue aujourd'hui. Non sans raison d'ailleurs puisque cela permet de profiter du traitement sonore analogique avec d'autres sons de batterie. Il est vrai que le principe de codage utilisé dans les machines de cette époque, du huit bits non linéaires offrant une dynamique de 12 bits, donne un résultat très... percussif!

J'ai déjà traduit l'ensemble de la partie processeur de cette Drumulator en VHDL et implémenté le tout avec succès dans une carte de développement à base de FPGA Altera, Intel maintenant:


Forcément, d'une part cette implémentation n'est pas la plus compliquée à effectuer mais en plus, toute la partie analogique est absente. Hormis le message "bAd" au démarrage indiquant que le contenu de la mémoire sauvegardée est corrompu, et pour cause puisque sur cette carte la SRAM est totalement volatile, il ne se passe pas grand chose. Evidemment, c'est quand même un très bon début.

Pour continuer l'implémentation VHDL de la machine, le 'gros morceau' auquel il convient de s'attaquer est le séquenceur interne qui génère les adresses d'accès aux WAVE ROMs externe. Sur le papier, le schéma n'est pas très compliqué :



Ces deux schémas représentent le micro-séquenceur, en haut, qui gère tous les accès aux registres, en bas, déterminant au final les adresses en cours de tous les sons. L'ensemble est en mesure de traiter huit sons simultanés et un espace mémoire totale de 64Ko. Je ne rentrerai pas dans les détais du fonctionnement de ce système, il est assez simple à comprendre. La partie cachée, à savoir le contenu de la ROM du micro-séquenceur, peut être déduite. Mais j'ai préféré dessouder le circuit de la carte de la machine, puis le lire avec un petit montage Arduino. De sorte que j'ai pu récupérer le contenu des 32 octets utilisés par EMU.

Muni de toutes ces informations, il n'y a plus qu'à lancer le logiciel Quartus puis se remettre au VHDL. Finalement, à chaque fois que je m'y remets, je trouve ce langage de plus en plus facile et pratique :


Après quelques heures de 'dur' labeur, la compilation se passe correctement. Les 'warnings' reçus sont tout à fait normaux étant donné la configuration du système. Je n'ai pas du tout déclaré de signaux d'horloge, l’analyseur ne peut donc effectuer correctement son travail, et me le dit avec force messages. Bon, un circuit qui au final fonctionne à 833KHz ne devrait pas me poser trop de problèmes. L'étape suivante consiste maintenant à tenter d'interfacer une carte FPGA contenant ce programme dans l'environnement de la Drumulator que je possède. Je n'ai pas encore vraiment pensé au problème. J'attends le circuit imprimé du support de WAVE ROM que j'ai créé :



Une fois que j'aurai testé ce circuit, normalement implémenté dans la Drumulator, j'en utiliserai un autre que je raccorderai à la carte FPGA, ce qui devrait me permettre de générer les données numériques comme souhaité. Par contre il me faudra implémenter la partie accès du système par le processeur de la machine, ce qui représente un certain nombre de connexions à réaliser puisque'il faudra au moins le bus de donnée du Z80 plus les signaux de sélection fournis par la glue logique. Sans compter les obligatoires circuits d'adaptation des tensions parce que la carte FPGA accepte au maximum du 3,3V alors que l'ensemble de la logique de la Drumulator est en 5V, technologie de l'époque oblige.

Mais bon, chaque chose en son temps!

UPDATE [12-11-2018] Je viens de recevoir le circuit imprimé de l'extension de mémoire de sons. Monter le premier prototype ne m'a pris que quelques minutes étant donné le faible nombre de composants du circuit :


L'emplacement de gauche devrait recevoir un support à force d'insertion nulle plutôt qu'un support standard, ce qui devrait permettre un échange vraiment plus commode de sets de formes d'ondes dans cette Drumulator. Pour l'instant je ne l'ai pas monté. Je vais d'abord tester le montage de base en condition normale :


Cela n'est pas pour me lancer des fleurs, mais quand même, cette version est un peu plus 'pro' que tout ce que j'ai pu voir jusqu'à maintenant (sous réserve que cela fonctionne, bien évidemment).

Je n'ai pas encore testé le principe, mais je pense qu'il devrait être possible avec cette version, d'utiliser un émulateur de RAM inséré dans le support à force d'insertion nulle. Cela devrait permettre un test auditif de banques de sons faites à la demande sans avoir à programmer au préalable les quatre ROMs habituelles. Un gain te temps et une plus grande flexibilité du système est donc à attendre dans le processus de création de banques sonores.

UPDATE [13-11-2018] J'ai utilisé un émulateur de PROM que l'on peut trouver sur Ebay pour un prix tout à fait correct. Il est fabriqué par l'entreprise Polonaise Momik. Il émule sans difficulté une mémoire de type 27C512 d'une capacité de 64Ko, total de ce que peut adresser le générateur sonore interne de la boîte à rythmes :


Au démarrage du système, les pads A, B, C et D de la Drumulator ne génèrent aucun son. Une fois cet émulateur de PROM chargé avec le fichier concaténé des quatres ROMs de base, le fonctionnement de la machine redevient normal avec les sons attendus sur tous les pads. Je ferai peut-être une petite vidéo du sujet...

vendredi 5 octobre 2018

Drumulator : carte WAVE ROM

Faisant suite au petit dépannage récent d'une Drumulator, j'ai pu constater que l'échange d'EPROM de sons n'était pas une opération spécialement triviale à effectuer par une personne non habituée à ce genre de 'bricolage'. Avec comme inconvénient majeur un fort potentiel de détérioration des EPROM, notamment de patte cassée.

Situation réelle rencontrée.
Il existait bien à l'époque des cartes d'extensions prévues pour accueillir un certain nombre de set de ROM. Ces cartes ne sont plus fabriquées, et étaient souvent de grosses extensions pas obligatoirement faciles à installer.

Extention JLCOOPER de l'époque.

En prenant en compte le fait que les supports de circuits installés à l'origine dans la Drumulator ne sont pas prévus pour subir régulièrement des changements de composants, qu'avec le temps les contacts se sont dégradés, j'ai pensé qu'il pouvait être utile de proposer une solution un peu plus moderne.

Le concept est simple : je propose donc un petit circuit imprimé prenant la place de certains des supports d'origine. Ce circuit acceptera deux PROMs contenant chacune un set STANDARD de sons pouvant être sélectionnés par un interrupteur. Pour l'instant donc, pas de sons au format ésotérique susceptible de réclamer une version adaptée de la ROM programme. Cette option verra peut-être le jour plus tard.

Voici ce à quoi devrait ressembler le circuit imprimé de la nouvelle solution :


Les deux faces du support d'EPROMs
Avant de lancer la production de ce petit circuit imprimé, il me faut vérifier techniquement que mon calcul d'espace des connecteurs est le bon. La carte ne devrait prendre que la place de trois supports d'origine sur les quatre.

D'autre part, les quatre ROMs seront condensées en une seule ce qui diminuera donc par quatre le risque de détérioration des composants. J'ai aussi réservé un peu plus d'espace pour un des supports qui pourra être de type ZIF ;

Support ZIF

Ce support ZIF devrait grandement faciliter le changement de set de sons. Le deuxième support sera un simple support, mais de qualité, qui recevra par exemple une copie des sons de base de la Drumulator.

Les quatre ROM nécessaires pour chaque set de sons...


...seront remplacées par une seule ROM de type 27512 :



Je continuerai ce billet au fur et à mesure de la réalisation de ce montage.

N'hésitez pas à m'envoyer vos commentaires au sujet de cette réalisation :