Micromite Companion : modification/mise à jour du firmware.

Tentative de passage au clavier Français.

Update 27 octobre 2014 : 

Tout d'abord une petite remarque concernant un des auteurs de ce petit système, Jeff Ledger.
Je lui ai bien posté une question concernant la compilation de l'archive compatible BST. Il n'a pas répondu à ma question, pas plus qu'à celle lui demandant la procédure utilisée pour la création du fichier umitecompanion.eeprom.

Par contre Jeff Ledger, ayant parcouru mon blog, est 'tombé' sur l'indication du problème concernant une des broches du processeur laissée en l'air. Il m'a demandé la permission d'afficher la photo que j'ai prise de ma modification, ce à quoi j'ai répondu favorablement sous réserve qu'il en indique la provenance. Il a contourné cet 'accord' en affichant sur le blog concerné une sortie graphique du logiciel de circuit imprimé, complétée par la correction à effectuer! Le monsieur n'est pas très fairplay!

Rappel : pour mettre à jour le firmware du système je n'utilise pas la méthode préconisée, à savoir un programmateur de processeur Propeller, mais une simple copie du fichier binaire en EEPROM à l'aide d'un programmateur d'EEPROM. Or, jusqu'à ce que je découvre la bonne configuration de la compilation, le système plantait systématiquement avec l' appui sur la touche F8 devant permettre l'affichage du contenu de la SDcard. Or donc, voici la bonne configuration :

Le fichier .eeprom est correctement généré avec ces paramètres.

Il suffit dès lors de demander la compilation "Compile and save EEPROM" pour obtenir le fichier adéquat.
 
Par ailleurs, j'ai modifié les codes 'premiers' des touches alphabétiques du clavier pour avoir l'équivalent du clavier Français. Et cette fois, cela fonctionne très bien. Je me contenterai de stickers pour indiquer les signes des autres touches, en particulier ceux des touches alphanumériques.

Ce système est maintenant prêt pour diverses expérimentations intéressantes avec quand même bien plus de puissance que mon Tandy TRS-80 PC2 d'origine, et la même facilité d'utilisation puisqu'il suffit d'un écran pour avoir une machine autonome. Plus besoin de PC!

Fin d'update


Mise en situation : le système fourni est tout à fait satisfaisant, mis à part le petit problème que j'ai soulevé dans mon billet précédent. Il concerne la mise en buffer des caractères en provenance du processeur MicroMite lorsque le débit de ceux-ci est rapide. Le système est livré avec la prise en compte du clavier 'qwerty'. A la longue, cela s'avère assez ennuyeux. L'idée vient donc tout naturellement de tenter la 'francisation' du système.

Avant toute chose, j'ai téléchargé le logiciel de développement adapté à l'opération visée. J'ai opté pour la suite d'outils gratuite BST que l'on peut trouver à cet endroit. Le site de développement du 'Micromite Companion' propose les sources du système directement au format BST. Le logiciel est bien fait, pratique et très facile à prendre en main : 

BST ne réclame aucune installation. Il est disponible dès son téléchargement effectué.

Les sources du système doivent aussi être récupérés à cet endroit. Une fois ces opérations effectuées, il ne reste plus qu'à étudier le code source pour juger de la faisabilité du changement de 'layout' du clavier. A priori cela ne semble pas très compliqué puisque l'ensemble des sources du système contient un fichier nommé 'Keyboard.spin'. L'extension 'spin' représentant un source assembleur spécifique au processeur Propeller. 

Une simple recherche à l'intérieur de ce fichier révèle la table des codes utilisés pour la translation des 'scan code' du clavier en code ASCII utilisables par le système : 

1:  table       word  $0000  '00  
2:              word  $00D8  '01       F9  
3:              word  $0000  '02  
4:              word  $00D4  '03       F5  
5:              word  $00D2  '04       F3  
6:              word  $00D0  '05       F1  
7:              word  $00D1  '06       F2  
8:              word  $00DB  '07       F12  
9:              word  $0000  '08  
10:             word  $00D9  '09       F10  
11:             word  $00D7  '0A       F8  
12:             word  $00D5  '0B       F6  
13:             word  $00D3  '0C       F4  
14:             word  $0009  '0D       Tab  
15:             word  $0060  '0E       `  
16:             word  $0000  '0F  
17:             word  $0000  '10  
18:             word  $F5F4  '11   Alt-R  Alt-L  
19:             word  $00F0  '12       Shift-L  
20:             word  $0000  '13  
21:             word  $F3F2  '14   Ctrl-R Ctrl-L  
22:             word  $0071  '15       q  
23:             word  $0031  '16       1  
24:             word  $0000  '17  
25:             word  $0000  '18  
26:             word  $0000  '19  
27:             word  $007A  '1A       z  
28:             word  $0073  '1B       s  
29:             word  $0061  '1C       a  
30:             word  $0077  '1D       w  
31:             word  $0032  '1E       2  
32:             word  $F600  '1F   Win-L  
33:             word  $0000  '20  
34:             word  $0063  '21       c  
35:             word  $0078  '22       x  
36:             word  $0064  '23       d  
37:             word  $0065  '24       e  
38:             word  $0034  '25       4  
39:             word  $0033  '26       3  
40:             word  $F700  '27   Win-R  
41:             word  $0000  '28  
42:             word  $0020  '29       Space  
43:             word  $0076  '2A       v  
44:             word  $0066  '2B       f  
45:             word  $0074  '2C       t  
46:             word  $0072  '2D       r  
47:             word  $0035  '2E       5  
48:             word  $CC00  '2F   Apps  
49:             word  $0000  '30  
50:             word  $006E  '31       n  
51:             word  $0062  '32       b  
52:             word  $0068  '33       h  
53:             word  $0067  '34       g  
54:             word  $0079  '35       y  
55:             word  $0036  '36       6  
56:             word  $CD00  '37   Power  
57:             word  $0000  '38  
58:             word  $0000  '39  
59:             word  $006D  '3A       m  
60:             word  $006A  '3B       j  
61:             word  $0075  '3C       u  
62:             word  $0037  '3D       7  
63:             word  $0038  '3E       8  
64:             word  $CE00  '3F   Sleep  
65:             word  $0000  '40  
66:             word  $002C  '41       ,  
67:             word  $006B  '42       k  
68:             word  $0069  '43       i  
69:             word  $006F  '44       o  
70:             word  $0030  '45       0  
71:             word  $0039  '46       9  
72:             word  $0000  '47  
73:             word  $0000  '48  
74:             word  $002E  '49       .  
75:             word  $EF2F  '4A   (/)   /  
76:             word  $006C  '4B       l  
77:             word  $003B  '4C       ;  
78:             word  $0070  '4D       p  
79:             word  $002D  '4E       -  
80:             word  $0000  '4F  
81:             word  $0000  '50  
82:             word  $0000  '51  
83:             word  $0027  '52       '  
84:             word  $0000  '53  
85:             word  $005B  '54       [  
86:             word  $003D  '55       =  
87:             word  $0000  '56  
88:             word  $0000  '57  
89:             word  $00DE  '58       CapsLock  
90:             word  $00F1  '59       Shift-R  
91:             word  $EB0D  '5A   (Enter) Enter  
92:             word  $005D  '5B       ]  
93:             word  $0000  '5C  
94:             word  $005C  '5D       \  
95:             word  $CF00  '5E   WakeUp  
96:             word  $0000  '5F  
97:             word  $0000  '60  
98:             word  $0000  '61  
99:             word  $0000  '62  
100:            word  $0000  '63  
101:            word  $0000  '64  
102:            word  $0000  '65  
103:            word  $00C8  '66       BackSpace  
104:            word  $0000  '67  
105:            word  $0000  '68  
106:            word  $C5E1  '69   End   (1)  
107:            word  $0000  '6A  
108:            Word  $C0E4  '6B   Left  (4)  
109:            word  $C4E7  '6C   Home  (7)  
110:            word  $0000  '6D  
111:            word  $0000  '6E  
112:            word  $0000  '6F  
113:            word  $CAE0  '70   Insert (0)  
114:            word  $C9EA  '71   Delete (.)  
115:            word  $C3E2  '72   Down  (2)  
116:            word  $00E5  '73       (5)  
117:            word  $C1E6  '74   Right  (6)  
118:            word  $C2E8  '75   Up   (8)  
119:            word  $00CB  '76       Esc  
120:            word  $00DF  '77       NumLock  
121:            word  $00DA  '78       F11  
122:            word  $00EC  '79       (+)  
123:            word  $C7E3  '7A   PageDn (3)  
124:            word  $00ED  '7B       (-)  
125:            word  $DCEE  '7C   PrScr  (*)  
126:            word  $C6E9  '7D   PageUp (9)  
127:            word  $00DD  '7E       ScrLock  
128:            word  $0000  '7F  
129:            word  $0000  '80  
130:            word  $0000  '81  
131:            word  $0000  '82  
132:            word  $00D6  '83       F7  
133:    
134:  keypad1   byte  $CA, $C5, $C3, $C7, $C0, 0, $C1, $C4, $C2, $C6, $C9, $0D, "+-*/"  
135:    
136:  keypad2   byte  "0123456789.", $0D, "+-*/"  
137:    
138:  shift1    byte  "{|}", 0, 0, "~"  
139:    
140:  shift2    byte  $22, 0, 0, 0, 0, "<_>?)!@#$%^&*(", 0, ":", 0, "+"  
141:  

Rien de bien renversant. Les codes présents jusqu'aux lignes 132 représentent 'à peu près' la translation des scan codes du clavier en code ASCII lorsque aucune touche d'altération n'est utilisée (MAJ, SHIFT etc...).

Les lignes Keypadx fournissent les codes ASCII particuliers du pavé numérique en mode verrouillage numérique et en mode sans verrouillage numérique.

Les lignes Shiftx fournissent les codes de certaines touches lorsqu'une des touches Shift est utilisée.
Shift2 fournit le code 'second' des touches numériques de la partie non pavé numérique, Shift1 fournit le code de certaines autres touches ne faisant pas parti des lettre standards de l'alphabet ni de la partie numérique du clavier de base.

L'opération consistant à modifier l'affectation des touches de base est très simple. Il suffit de placer le code voulu la ou se situe le code d'origine à remplacer dans la table par exemple :

22:             word  $0071  '15       q 

à remplacer par :

22:             word  $0061  '15       a 

et ainsi de suite pour tous les code 'premiers' devant être modifiés.

Concernant le traitement des touches shift, la translation ne peut se faire sans toucher au code du programme. En effet, l'auteur s'est appuyé sur la disposition des touches numériques du clavier Américain pour modifier par ajout d'un offset, l'index pointant sur la table afin de pointer réellement sur une des deux lignes Shift1 ou Shift2. La chose est rendue possible parce que les chiffres de 0 à 9 sont présents directement sur la ligne du haut du clavier, sans avoir à utiliser la touche Shift, comme cela doit se faire sur un clavier Français. De ce fait, en considérant le mode de fonctionnement du clavier Français, il n'est plus possible de modifier l'index de code ASCII par simple ajout d'une valeur aux codes de base des chiffres, qui se suivent fort opportunément de 0x30 à 0x39 dans le cas du clavier américain. Il devient alors nécessaire de reprogrammer une partie du code traitant la translation SCAN code vers code ASCII.

Pour contourner simplement le problème, il est possible de considérer que la ligne du haut fournit les codes des chiffres sans avoir recours à la touche Shift, et que l'appui sur la touche 'seconde' fournira les autres codes comme '&~"'(-`_^@)' par exemple. Il suffit de remplacer la ligne suivante :

140:  shift2    byte  $22, 0, 0, 0, 0, "<_>?)!@#$%^&*(", 0, ":", 0, "+"  

par celle-ci :

140:  shift2    byte  $22, 0, 0, 0, 0, "<_>?)&~"'(-`_^@", 0, ":", 0, "+"  

Quelques ajustement et choix de dispositions de touches s'avère quand même nécessaire puisqu'il y aura un problème avec la séquence '()' étant donné que le caractère ')' se trouve sur la touche '°' et que cette dernière n'est pas traitée par la ligne Shift2.

Le principe de base est donc relativement simple, et moyennant quelques agencements, il est possible de 'déclarer' assez facilement un clavier 'Français' beaucoup plus facile à utiliser.

La compilation : une fois le fichier Keyboard.spin enregistré, il est nécessaire de sélectionner le fichier nommé umitecompanion.spin dans l'outil BST et d'en demander la compilation qui devrait s'effectuer sans problème après avoir sélectionné les options suivantes dans le menu 'Tools/Compiler Préférences' :

Personnellement, je compile en utilisant la fonction 'Compile and save binary'. Ce qui a pour effet de générer un fichier binaire nommé umitecompanion.binary.

Intégrer ce nouveau fichier sur le système est assez simple. Le processeur Propeller à ceci de caractéristique de charger dans sa RAM interne, le contenu de l'EEPROM présente sur le montage. En fait le processeur commence par tenter de charger sa RAM à partir de sa ROM interne mais si cette ROM interne ne contient pas de données, alors le processeur passe au chargement depuis l'EEPROM externe. Cette fonctionnalité de boot est très pratique puisqu'il suffit de modifier le contenu de l'EEPROM pour modifier le système.

Je possède depuis quelques années un programmateur spécifiquement dédié à la programmation des EEPROM diverses et variées, le EZP2010 :

Cet appareil est disponible pour quelques Euros à différents endroits, sur eBay notamment. L'appareil que je possède était livré avec les drivers pour Windows Vista, au mieux. La première tentative d'installation sous Windows 7 en version 64 bits s'est donc soldée par un échec.

J'ai donc récupéré sur le Net, le package logiciel dénommé EZP2010_V3.0 et ai installé l'appareil avec le nouveau driver. Cette installation s'est correctement déroulée mais le logiciel, aussi fourni dans le package, ne reconnaissait toujours pas le programmateur. Il m'a donc fallu effectuer la mise à jour du firmware du programmateur par la version elle aussi disponible dans le package logiciel, sur un ordinateur équipé de Windows XP.

Recommandation : avant de ne plus avoir sous la main de PC fonctionnant sous Windows XP ou Vista, mettez votre programmateur EZP2010 à jour, sinon vous le perdrez en même temps que vous vous débarrasserez de votre ancienne version de Windows! On flirte ici avec l'obsolescence programmée...

Une fois le programmateur opérationnel, et le fichier binaire disponible, la programmation de l'EEPROM s'avère triviale :

Il suffit alors de remplacer l'EEPROM nouvellement programmée sur le support équipant la carte électronique pour qu'à la mise sous tension, les modifications soient disponibles.

Note : en y regardant de plus près, vous remarquerez que j'ai programmé l'EEPROM avec le fichier umitecompanion.eeprom. J'ai récupéré ce fichier du dépôt sur le site proposant le MicroMite Companion cité plus haut.

Parce que la compilation à partir des sources génère un binaire qui ne correspond pas au binaire directement récupéré. Un possible manque de mise à jour des sources peut expliquer ce phénomène. Ceci se traduit par un plantage du système lors de l'appui sur la touche F8, sensée lister le contenu de la SD card. Ce problème est fort ennuyeux car avec les quelques modifications simples effectuées précédemment sur le positionnement des touches du clavier, l'utilisation d'un système 'presque' Français était devenu bien plus agréable.

Bilan :  mon idée initiale ne fonctionne pas vraiment, ou pas encore, du fait de l'impossibilité de compiler un système stable avec les sources disponibles. Peut-être vais-je contacter les initiateurs de ce projet pour leur faire part de ce problème, ainsi que celui de la patte du processeur restée 'en l'air'. L'idée de ce projet est tout à fait intéressante, mais elle manque peut-être d'un peu plus de finalisation.

Ceci dit, de base, le système fonctionne très bien, et si le besoin s'en fait sentir, un environnement de développement simple et efficace est disponible pour compiler du code SPIN, la mise à jour du firmware est très facile en passant par un programmateur d'EEPROM. La rapidité d'exécution du code Basic par le processeur MicroMite est tout à fait impressionnante. Le tout pour un coût de quelques Euros.

Micro-contrôleurs ZILOG.

Ou le retour aux sources!

Je ne vais pas faire état dans ce billet de l'histoire d'un des plus fameux micro-processeurs que fût le Z80, et de toute sa lignée. Ce circuit n'intéresse plus aujourd'hui que les nostalgiques de la 'grande époque' et les 'rétro-gamers'.

http://en.wikipedia.org/wiki/Zilog_Z80

 
Bien que ce propos puisse quand même être tempéré puisque ce circuit, simple et rapide, peut trouver très avantageusement sa place au sein d'un FPGA, implémenté en tant que module IP. Il est très facile d'en insérer un certain nombre dans un même FPGA et ainsi, de créer des systèmes multi-tâches et très performants. Ceci est une autre histoire, peut-être une publication sur ce thème dans les prochains mois... Un petit exemple de ce qu'il est possible de faire à ce sujet : zx-spectrum-on-an-fpga

FPGA 128K Spectrum with ResiDOS, Altera DE1 from Mike on Vimeo.

Non, je vais faire ici état des micro-contrôleurs de la famille Z8F. Précisons de suite que ces micro-contrôleurs n'ont rien à voir avec la famille Z80. L'architecture est différente ainsi que le jeu d'instruction. Par contre, et c'est un avis personnel, je trouve que la philosophie Zilog reste présente dans ces circuits, à savoir la simplicité d'utilisation. Ce qui ne veut absolument pas signifier qu'ils sont 'trop' simples ou archaïques, bien que ce soit des circuits 8 bits, mais fonctionnant à 20MHz pour certains modèles.

Au début, exista les micro-contrôleurs Z8E et l'émulateur 'in-circuit' associé :

Illustration provenant du site de RS.

Ce système de développement date du début des années 90. Les trois supports vide du bas de la carte permettaient d'y connecter un câble plat en nappe dont l'autre bout s'enfichait à la place du futur processeur, sur la carte en cours de test. Le logiciel de développement, gratuit, permettait non seulement la programmation de toute la gamme de processeur, sans limitations, mais aussi le débogage en temps réel. Fonctionnalité très pratique lors du décodage d'une trame RC5 par exemple! Une fois finalisé, le programme pouvait être copié directement dans le processeur en le plaçant sur un des supports du haut de la carte.
L'ensemble de la communication entre le système de développement et le PC hébergeant la partie logicielle se faisait par l'intermédiaire d'un simple port série. J'ai longtemps utilisé cet outil qui, grâce à sa facilité d'utilisation et le très faible coût des processeurs Z8E, m'a permis de résoudre bien des problèmes avec élégance.

Le seul grief qu'il était possible d'émettre à propos de ce système de développement, concernait le fait que ces processeurs étaient des circuits OTP, autrement dit : One Time Programmale. Donc, tout changement de version de programme s'accompagnait d'une mise au rebut du circuit et de la programmation d'un nouveau spécimen.

Sont alors arrivé, vers la fin des années 90, les Z8F, 'F' pour Flash!

Derniers nés de la famille (pas encore disponible le 10/2014)

La philosophie de ces circuits reste exactement la même que les version Z8E, si ce n'est que, grâce à la flash intégrée au processeur, tout le système de programmation ET de débogage est intégré à la puce. Il n'est donc plus nécessaire de disposer d'un matériel 'conséquent' pour développer avec ces processeurs. De plus, l'ensemble de la communication avec l'outil de développement est réalisée par l'intermédiaire d'une seule connection sur le circuit, la patte DBG. Un adaptateur série, ou mieux USB, est alors requis pour relier simplement le processeur en cours de programmation à l'ensemble de l'application fournie par Zilog à savoir le logiciel 'Zilog Developer Studio II' ou ZDSII.

Interface opto-isolée de Zilog.

Le coût de développement avec ce type de micro-contrôleur est extrêmement faible puisque le logiciel de développement est toujours gratuit et qu'une interface Xtools de Zilog est facturée 24,86 € HT chez Mouser au 15 octobre 2014 (réclame gratuite), Farnell ne disposant pas d'autant de références...

Une version 'simple' de l'interface de programmation de Zilog fournie avec les premières versions du Kit de développement sur base de processeurs Z8F. L'interface proposée était alors le port RS232 :

Étant acquis qu'il est possible de développer à moindre coût avec ce type de circuit, voyons ce qu'ils proposent. Voici l'exemple du Z8F6423, gros circuit de la série Z8F :

Origine : Zilog

• 20MHz eZ8 microprocessor core
• 64KB Flash program memory
• 4KB register SRAM
• 12-channel 10-bit A/D converter
• Four 16-bit timers with PWMs, plus capture and compare capability
• 60 general-purpose I/Os, depending on package type
• 24 vectored interrupts
• Power-On Reset (POR) and Voltage Brown-Out (VBO)
• Full-duplex SPI and I2C, plus 2 UART ports with IrDA encoder/decoder 
• On-chip debug with break and trap capability
• 3.0V to 3.6V voltage range
• Standard (0°C to 70°C) and extended (-40°C to 105°C) temperature range
• Available in 80-pin QFP package

On pourra regretter l'absence de zone de mémoire EEPROM et d'horloge temps réel. Pour des circuits spécifiquement prévus pour des applications embarquées, ces ajouts auraient pu être utiles. Mais disponible à 6,03€ HT chez Farnell (pour ne léser personne!), le choix de l'absence de ces dispositifs semble justifié. Charge au développeur d'implémenter ces fonctions de façon externe et de les relier aux différents bus du micro-contrôleur!

Par opposition, voici les caractéristiques du plus petit processeur de la gamme, le Z8F0113 :

Origine : Zilog

• 5.5MHz eZ8 microprocessor core
• 1KB Flash program memory
• 1KB register SRAM
• 5.5MHz Internal Precision Oscillator
• Two 16-bit timers with PWMs and capture and compare capability
• Up to 24 general-purpose I/Os
• Power-On Reset (POR) and Voltage Brown-Out (VBO)
• UART port with IrDA encoder/decoder
• On-chip debug with break and trap capability
• 2.7V to 3.6V voltage range
• Standard (0°C to 70°C) and extended (-40°C to 105°C) temperature range
• Available in 8-pin QFN, 8, 28 and 20-pin SOIC, 20 and 28-pin SSOP and 8, 20 and 28-pin PDIP packages

Une fois passée la découverte...

Le kit de développement est toujours produit par Zilog et est disponible sur commande chez Mouser à 33,16€ HT, mais plus chez Farnell. Ce kit est donc proposé à prix tout à fait abordable. Et, si par hasard il se trouvait à ne plus être disponible, il est très facile d'en réaliser, avec peut-être plus de périphériques intéressants que celui créé par Zilog, à savoir une horloge temps réel et une FRAM série comme sur cet exemple :

Ne cherchez pas le site http://www.electrodiy.net, il n'existe plus.

Sur cette carte, toutes les broches du processeur sont disponibles sur les connecteurs, bien que certaines d'entre elles partagent leurs signaux de bus série avec l'horloge et la FRAM. C'est la carte idéale pour le test rapide.

Une fois les solutions techniques validées et définitivement adoptées, il devient aisé de passer à la pré-production, sachant que la connection à réaliser avec l'ordinateur de développement se résume au strict minimum, le signal série et la référence :

Carte pré-ampli haute qualité commandable par signal IR et codeur rotatif.

Le connecteur de programmation se situe à gauche du processeur. Ce dispositif suffit pour permettre la programmation du circuit et le débogage en temps réel. Comparé à d'autres systèmes, cette solution est gratuite, simple, performante et très facile à mettre en œuvre!

Bilan :

Cette série de micro-contrôleurs de chez Zilog n'a jamais trouvé sa place auprès des amateurs. Personnellement, je n'ai pas d'explications à ce fait. Certes, la fréquence de fonctionnement de 20Mhz peut paraître faible, mais au début des années 90, elle se situait dans la bonne moyenne. Ces circuits sont facilement maîtrisables, comparés aux ARM par exemple. Ils possèdent relativement peu de registres, la programmation C se fait sans difficulté et l'accès aux instructions en assembleur se fait 'au fil de l'eau' avec l'aide du logiciel de développement.
Au fil des recherches sur le 'net', il est même possible de trouver des ressources permettant de programmer plus facilement les registres les plus 'délicats' du processeurs , à savoir les timers :

La ressource se situe ici : timer-calculator. Le code généré devant être éventuellement adapté au processeur utilisé.

Évidemment, d'autres familles de micro-contrôleurs existent comme les très intéressants circuits de la famille MSP430 de Texas Instruments. Mais la politique commerciale de cette entreprise concernant les outils de développement est discutable. Je peux comprendre que Texas-Instruments ne veuille pas casser le marché des société tierces fournissant des outils de programmations, mais en tant qu'utilisateur de circuits programmables de ce genre, la seule chose qui m'intéresse est de pouvoir les programmer avec le moins de contraintes possibles.

D'autres fabricants limitent les fonctionnalités de leur logiciel en possibilités d'optimisation du code. Cela peut se comprendre. Après-tout, si le besoin s'en fait sentir, le développeur peut acquérir une licence et ainsi profiter de toute la puissance de l'outil. Limiter la taille du code est une pratique que je juge archaïque et indigne, s'agissant de la considération du client.

Or donc, après une longue période d’inutilisation des ces micro-contrôleurs Zilog, j'ai décidé de m'y remettre. Ils permettent de faire tellement, de façon tellement efficace et en tellement peu de temps, que dès lors que la production rapide de matériels divers se fait sentir, ils (re)deviennent irremplaçables!

Micromite Companion : construction du système.

Dans mon billet précédent traitant du système Maximite, j'ai détaillé la genèse du projet de Geoff Graham puis les différentes reprises du sujet par d'autres contributeurs, pour terminer sur une évolution intéressante qu'est le système Micromite accompagné d'une extension très pratique se présentant sous la forme du Micromite Companion. Avec au menu, le rajout d'une sortie VGA, d'une sortie audio, d'une entrée clavier type PS/2 et d'un lecteur de carte SD pour former le système suivant :

Du site http://propellerpowered.com

Mise en situation : pour quelle raison utiliser ce système plutôt que la version Maximite d'origine qui possède aussi toutes ces interfaces? J'y vois au moins une raison intéressante, le processeur PIC32 utilisé est très petit et très facile à souder avec son boîtier en version DIP. Cet ensemble devient dès lors une base de développement autonome très pratique. Une fois le programme Basic finalisé, il peut alors être implémenté dans le processeur d'application, lui même prenant place ne serait-ce que sur une carte d'expérimentation. Le développement de petits systèmes devient alors très facile.

Deuxième raison, les fonctionnalités offertes par le 'processeur graphique' permettent la créations d'application plus conviviales moyennant la programmation du bus I2C assurant le transfert de commande depuis le 'processeur central' vers le 'processeur graphique'.

Et peut-être, ou sans doute une troisième raison : comme le 'processeur graphique' est maintenant autonome, il peut se présenter sous différentes formes et offrir des modes graphique non supportés actuellement ouvrant ainsi de multiples possibilités tout en restant très simple à utiliser.
N'oublions pas d'autre part que Microchip, le fabricant du processeur PIC32 utilisé dans ce montage, à sorti en 2013 une version à 200Mhz référencé PIC32MZ et non plus seulement MX qui, outre une fréquence de fonctionnement bien plus élevée, semble être aussi plus performant dans l'exécution de ses instructions!

Mais avant de profiter de ce Micromite Companion, il est nécessaire de le construire parce qu'il est livré sous cette forme :

Avant de vous lancer dans un tel montage, si comme moi la curiosité vous pousse à essayer ce concept, notez que même si sa construction ne pose pas de problème pour une personne avertie, je le déconseille à ceux d'entre vous n'ayant jamais tenu un fer à souder en main. L'assemblage de la carte nécessite une petite pratique notamment en ce qui concerne le soudage du connecteur de carte SD, plus d'autres approximations du développeur nécessitant quelques acrobaties.

Ne pas perdre de vue qu'il s'agit d'un produit amateur et donc largement perfectible.
Le circuit imprimé n'est pas très bien réalisé :

Toutes les pistes ne sont pas au bon format, notamment certaines véhiculant non pas des signaux mais des tensions, qui devraient être plus larges.

Les résistances sont montées debout. C'est une très mauvaise idée, d'autant plus que celles fournies sont de type carbone (des type métal eussent été plus judicieuses) équipées de pattes très fines et très faciles à plier. Se faisant, il est relativement difficile de conserver l'alignement des séries de résistances qui ont, de plus, tendance à ce coucher sur le circuit imprimé si l'on n'y fait pas attention.
En agrandissant légèrement la taille du circuit et en agençant les composants de façon plus étudiée, il aurait été tout à fait possible de les implanter à l'horizontal.

Les résistances présentes face au connecteur du clavier doivent être implantées corps côté connecteur (comme conseillé pour celles face au connecteur VGA alors que ce dernier est en plastique) et non pas l'inverse comme présenté sur le circuit imprimé. En ce qui me concerne je les ai montées comme présenté sur le circuit alors que des commentaires d'amateurs ayant déjà réalisé ce montage conseillaient de faire l'inverse. Peu importe, je les ai placées correctement, les pattes ne touchent pas le connecteur métallique.

Le connecteur VGA possède un écartement des lignes de contact trop grand par rapport a celui fourni dans le kit. Heureusement, en forçant 'légèrement' il finit par se loger correctement.

Enfin, j'ai ôté à la scie à métaux les deux ergots présents sur la plaque d'expérimentation qui, même si l'auteur de ce système assure l'inverse, ne rentre pas facilement entre les rangées de connecteurs dédiés à cette plaque d'essais.

Malgré ces petit détails il est relativement aisé d'arriver au résultat final en suivant la procédure de montage, pour finalement obtenir ceci :

Quelques remarques utiles pour la première mise en service :

• Les deux processeurs sont fournis déjà programmés.
• La carte SD doit être formatée en FAT16 et être d'une capacité de 2Go max.
  
• Les fichiers nécessaires au 'boot' de l'appareil, ainsi que divers exemples sont hébergés sur DropBox. Je considère que l'emploi de ce service est une vraie bêtise. Il n'a pas été étudié pour ce genre d'utilisation. Ne soyez donc pas surpris de constater des lenteurs de navigation ni même des erreurs à la demande de téléchargement. Si tel est le cas, réitérez votre demande.

Tous ces préparatifs pour en arriver à :

Je le rappel, ce projet est un projet amateur. J'ai donc constaté quelques petits problèmes suite aux premiers tests.

Tout d'abord une broche du 'processeur graphique' est laissée en l'air. Il s'agit de la patte 10 notée BOEn du P8X32A (le 'processeur graphique' de type 'Propeller' du fabriquant Parallax).

 

Ceci à pour effet de redémarrer le P8X32A si l'on passe la main à proximité de cette patte. C'est plutôt gênant mais très facile à corriger en la connectant à la masse. En ce qui me concerne, j'ai effectué une connection directement sous le dessous du circuit imprimé à l'aide d'un bout de patte de résistance avec la patte 9 voisine notée VSS du processeur P8X32A comme vous pouvez le voir au centre le l'image :

Petite modification facile à réaliser.

Enfin, il semblerait que le 'processeur graphique' ne soit pas en mesure de soutenir la vitesse d'affichage des chaînes de caractères en provenance du processeur Micromite. En effet, ce simple programme devant afficher en continu un chiffre qui s'incrémente

BEGIN:
A = A + 1
PRINT A
GOTO BEGIN

génère des sauts d'incrément à l'écran ainsi qu'une aberration d'affichage à une fréquence régulière. D'après ce qu'il me semble avoir constaté, le buffer de réception du 'processeur graphique' déborde régulièrement et laisse donc passer un certain nombre de caractères. Ce problème sera donc à prendre en compte lors de l'affichage d'un grand nombre d'informations à l'écran, à moins qu'une prochaine version de firmware ne corrige ce problème.

Et puis il sera possible de regretter que ce système ne prenne en compte que le clavier anglais, même si l'on peut se douter que commencer à en gérer une multitude ne soit pas trivial.

LE MATCH

Le meilleur pour la fin : afin de me faire une idée plus précise de la 'puissance' de ce système, j'ai programmé un petit test qui consiste tout simplement à incrémenter une variable de 000 000 à 100 000 sans en afficher la valeur et à comparer le temps d'exécution avec le même programme exécuté sur mon antique TRS-80 PC-2. J'obtiens les résultats suivant :

Temps d'exécution de la boucle.

• 3 000 secondes pour le PC-2.
• 23 secondes pour le système Micromite Companion.

Soit un rapport de 130. Impressionnant, non? J'imagine mieux maintenant ce qu'il est possible de créer avec ce Micromite par rapport à ce que j'ai pu faire avec mon PC-2 qui était en sont temps, considéré comme une très bonne machine.

Neo computers : les Mites sont à l'œuvre!

Depuis quelques années, la 'révolution' Arduino est en marche... Vous en avez certainement entendu parlé tellement il est impossible d'y échapper. Dans le 'petit' monde de l'embarqué, ces systèmes sont devenus incontournables. A ce point que même de grands fondeurs de composants comme Intel, Texas Instruments, ST et bien d'autres, proposent diverses cartes de développement basées sur le même principe qui a fait le succès de la famille. A l'origine les cartes Arduino étaient, et le sont toujours pour la majorité, équipées de processeurs de type AVR du constructeur Atmel.

L'incontournable UNO, origine : du site officiel Arduino

Les cartes Arduino ou compatibles sont proposées à prix très bas en général inférieur à une centaine d'Euros, même équipées d'un puissant processeur ARM, et sont accompagnées d'un outil logiciel de développement gratuit qu'il suffit de télécharger. Ce logiciel produit du code binaire directement exécutable par le processeur à partir d'un langage 'C' 'simplifié' ou une grande partie des fonctionnalités disponibles est 'cachée' dans diverses librairies fournies. La puissance de ces petits systèmes est assez conséquente, même lorsque la carte est équipée d'un petit processeur AVR puisqu'ils exécutent du code non interprété, à la différence d'autres langages comme le Basic.

Ces systèmes souffrent tout de même d'un petit manque à mon sens, et ajoutent une contrainte que je trouve assez gênante. Tout d'abord, ils ne fournissent aucune possibilité native d'affichage. J'entends par la un affichage sur un écran standard de type VGA, même s'il est toujours possible d'y connecter des afficheurs LCD. De ce fait, certaines applications sont difficilement envisageables.

D'autre part, le principe 'Arduino' implique de disposer d'un ordinateur 'standard' sur lequel sera installée l'application de développement et de téléversement du code dans le processeur. Un PC sous Windows/Linux, ou un Macintosh est donc obligatoire.

Mise en situation : Sans obligatoirement aller chercher des cartes embarquées fonctionnant sous Linux, il existe depuis quelques temps (2011) un petit système autonome, programmable en Basic, et capable d'afficher des textes et des graphiques nativement sur un écran VGA : les 'trucs-mites'.

De quoi s'agit-il? A l'origine il s'agit d'un projet de Geoff Graham qui eût l'idée de porter le basic Microsoft MBASIC sur un processeur très puissant de la famille PIC32 de Microchip. L'idée fut publiée dans la revue Silicon Chip de mars à avril 2011 sous le titre "The Maximite", et se présente sous la forme d'une carte autonome comportant l'intégralité des fonctionnalités du système : la Maximite

Image provenant du site de Geoff Graham.

Et de base, le système est assez séduisant. Bien que reposant sur un interpréteur Basic qui, comme son nom l'indique interprète chaque ligne de texte du programme, la vitesse d'exécution de l'interpréteur associé à la rapidité du processeur de type RISC fonctionnant à 50Mhz, confère au système une rapidité d'exécution tout à fait surprenante. A titre indicatif, au début des années 80, je faisais mes premières armes avec un système de ce type doté d'un processeur de type CICS fonctionnant à moins d'un MHz :

Et revoici mon TRS80-PC2!

La comparaison n'a même plus de sens tellement il devient absurde de confronter un processeur de type Z80 avec un PIC32! Et pourtant, il m'est arrivé d'utiliser ce PC2 au travers de son connecteur d'entrées/sorties disponible sur le côté gauche de l'appareil pour commander un processus industriel assez complexe de gestion de moteurs de remplissage d'un château d'eau!

De base, le système Maximite offre la visualisation sur un moniteur VGA, dispose d'un éditeur en ligne pour le Basic intégré, d'un connecteur pour carte SD, d'une prise pour un clavier type PS/2, d'un port USB, et de différents signaux d'entrées/sorties, le tout très facilement accessible par le biais de commandes en Basic que Geoff Graham a eu la très bonne idée d'ajouter au langage d'origine.

En terme de performances et de flexibilité, le Maximite n'a plus rien à voir avec le PC2. Les capacités mémoires sont à l'avenant. Maximite dispose de 128K de RAM, le PC2 n'en disposait que de 1,8K!
Si l'on compare ces caractéristiques à ce que fût le PC d'origine, le contraste est tout aussi saisissant. Un processeur 16 bits (le PIC32 est un 32 bits) fonctionnant à moins de 5Mhz (4,77MHz), 64K de ram pour les premières versions, un lecteur de disquette poussif de 180K et un affichage monochrome non graphique!

Quelques exemples de produits compatibles Maximite de ce que j’appellerais 'la première vague', développés soit par Geoff Graham lui-même, ou disponibles chez d'autres éditeurs de cartes électroniques :

Le Maximite d'origine en sortie VGA monochrome :

http://archive.siliconchip.com.au/cms/A_112362/article.html

Le Maximite color :

Image provenant du site de Geoff Graham.

Un peu de la même façon que des cartes Arduino compatibles éditées par d'autres entités que les concepteurs originaux se sont vues affublées du terme 'duino' dans le titre, des 'quelques-choses-Mites' sont aussi apparues, éditées par Geoff Graham lui-même, ou par d'autres :

la Mini-maximite de Geoff Graham :

Image provenant du site de Geoff Graham.

La TFT-Maximite de Segor Electronics :

Image provenant du site de Segor Electronics.

La UBW32 de Brian Schmalz, qui ne comporte pas de 'mite' dans le titre :

Image provenant du site de Geoff Graham.

La CGMMSTICK1 - Maximite de CircuitGizmos : 

http://www.circuitgizmos.com.

La CGCOLORMAX2 - Color Maximite de CircuitGizmos :

http://www.circuitgizmos.com.

La DUINOMITE-MINI d'Olimex :

www.olimex.com.

La DUINOMITE-MEGA, toujours d'Olimex :

www.olimex.com.

Jusqu'à la Maximite BBX de Chuck Hellebuyck qui a récemment fait l'objet d'une campage de crowdfunding sur kickstarter :

Mais au fait, pourquoi s'intéresser à ce système simple programmable en langage Basic?

Outre les côtés très intéressants de la rapidité d'exécution des programmes et de la versatilité de la machine, ce système présente tout de l'ordinateur autonome et intuitif tels que le furent en leur temps les micros-ordinateurs de la fin des années 70 démocratisés par les fameux ZX80 et  ZX81, avant que tout ce microcosme bouillonnant d'idées et de ressources ne soit remis en cause par le très médiocre IBM PC (avis personnel qui est toujours le mien presque 30 ans plus tard).

Mais, pour être complet, cette base Maximite se doit d'évoluer vers une architecture générale plus complète. A mon sens, le coup de départ de la 'seconde vague' vient d'être donné par Bryan Cockfield par la création du 'Micromite Companion', le MMC :

http://propellerpowered.com

Quelle différence par rapport à la Maximite d'origine?

Sur ce système, le processeur principal n'est plus un circuit équipé d'une grande quantité de pattes d'entrées/sorties mais un processeur plus simple en terme d'interfaces extérieurs qui ne joue plus le rôle QUE de processeur central : le Micromite, toujours développé par Geoff Graham.

Dans le système Maximite  d'origine, c'est le processeur central qui gère l'interface vidéo. Cela ne pose pas vraiment de problème de ressources au processeur car elle à été développée pour effectuer sa fonction dans son coin en interférant le moins possible avec le cœur Basic du système.

Le circuit Micromite, lui, ne gère absolument pas la vidéo. Il ne peut être programmé que par l'intermédiaire de son interface série dédiée à la console. Or il existe plusieurs projets de réalisation d'un terminal type VT100 autonome, en mesure d'afficher les informations sur un écran VGA standard, dont celui de Geoff Graham lui-même : VT100. Son projet utilise toujours un PIC32 pour réaliser la fonction.

http://geoffg.net/terminal.html

Cependant il existe un autre type de processeur puissant et capable d'afficher sans problèmes, caractères et graphiques sur un écran VGA, le processeur Propeller de Parallax. Un bon exemple de ce type de réalisation est le terminal de Vince Briel de Brielcomputers, le PocketTerm :

Brielcomputer.

C'est justement ce type de processeur Propeller qui a été utilisé dans le projet MMC cité plus haut. Ce circuit joue dans ce cas, le rôle de co-processeur graphique avec des possibilités tout à fait étonnantes :

Il devient donc possible de considérer, avec cette nouvelle mouture de Micromite accompagné d'un co-processeur vidéo, que le système vient d'entrée dans une nouvelle phase d'améliorations substantielles, propres à procurer pour un coût réduit tant en terme d'achat de matériel que de temps de développement, des possibilités importantes dans divers domaines.

Pour l'instant, la définition vidéo peut paraître encore faible, mais d'une part la voie de l'amélioration est tracées, et d'autre part des systèmes bien plus complexes à programmer existent depuis longtemps pour afficher quantités d'informations statiques et dynamiques à l'écran.

Mais ce système Micromite offre aujourd'hui une alternative intéressante dans la réalisation rapide et efficace de certaines applications qui réclameraient à contrario de très gros investissements financiers en développement sur d'autres plates-formes.

La prochaine voie d'amélioration devrait sans conteste se focaliser sur la connectivité du système. Pour l'instant, seule une connection de type série est possible. Pour rendre Micromite visible depuis le net, une interface réseau semble être inévitable, qui décuplerait totalement les champs d'applications de ce petit ordinateur.

Perspectives :  Obtenir et tester ce système. Puis le déployer dans une véritable application... Et puis espérer qu'une communauté active naisse autour de ce projet, un peu de la même façon que ce qui s'est passé pour l'Arduino!

Sauvegarde des mémoires programme des synthétiseurs vintages et autres antiques Breloques électroniques...

Bien que le non de ce blog puisse le suggérer, force est de constater que je n'ai pas vraiment publié de sujet sur les synthétiseurs jusqu'à maintenant, mis à part ce billet de juin : Prophet VS et CEM5530

L'occasion donc d'évoquer ici un sujet récurent qui ne laissera, j'en suis (quasi) certain, pas grand monde indifférent.

Mise en situation : aux presque débuts de l'histoire des synthétiseurs, je fais ici référence à la période ou est apparu sur terre le règne des micro-processeurs dans les années mi-soixante-dix, ces machines et par extension beaucoup d'appareils électroniques se sont vus affublées du vocable 'programmable' ou 'full memories' ou que sais-je d'autre pour indiquer la merveilleuse nouvelle possibilité de sauvegarde des configurations. En d'autres termes, le progrès permettaient non seulement de programmer le son sur un synthétiseur mais aussi et surtout d'en conserver les paramètres même lors de son extinction.

Impossible de ne pas faire mention d'un des tout premiers synthétiseurs de ce type, le Prophet-5 de Séquential Circuit :

Image honteusement 'pompée' du web!

A cette époque, pas d'EEPROMs, flashs, SD-Cards clés USB, disques durs etc etc... Non, la plupart du temps il s'agissait d'une RAM statique communément appelée SRAM qui, alimentée par une source de tension de secours, conservait les précieuses données. Une SRAM étant statique, elle conserve d'elle-même ses données sans nécessité de rafraîchissement comme les DRAM (dynamique RAM), du moins tant qu'elle reste alimentée. La 6116 de 2K octets en est la digne et vénérable représentante :

Image honteusement 'pompée' du web! Mais estampillée MHS quand même

!

Et alors me direz-vous. Et bien ces SRAM, même si elles requièrent une très faible puissance pour retenir leur contenu, réclament tout de même une sauvegarde par pile ou batterie à même de palier l'arrêt d'alimentation générale. Et c'est la que se pose le vrai gros problème. Quand la pile ou la batterie est déchargée, outre le fait qu'à ce moment précis la SRAM et vous par la même occasion avez perdu toutes vos informations, elle a tendance à fuire, à couler et à oxyder les pattes des composants alentours ainsi que des pistes du circuit imprimé. Inutile de préciser qu'à ce petit jeux, il arrive un moment ou le synthétiseur peut présenter comme un léger dysfonctionnement. Un bon exemple provenant du site http://www.digplanet.com :

Joli travail!

Ne pourrais-t-on pas se passer de ces piles ou accus pour éviter ces problèmes?
Si, évidemment, on pourrait. Mais ça n'est pas si simple. Même s'il existe aujourd'hui d'autres composants capables de retenir l'information sans alimentation, ils requièrent tous un traitement algorithmique particulier pour mener à bien leur mission. Or, dans le cas qui nous intéresse, le circuit de remplacement doit fonctionner DE LA MÊME FAÇON que la SRAM d'origine. Ou en tout cas, en simuler parfaitement le comportement.

Il existe une solution viable : la FRAM. Initialement fabriqués par Ramtron, ces composants le sont depuis quelques mois par Cypress qui à apparemment acquis Ramtron. A noter que Cypress propose une autre solution de SRAM non volatile basée sur un autre principe : la sauvegarde pure et simple du contenu d'une SRAM classique dans une mémoire non volatile. L'opération s'effectuant sans la moindre intervention extérieur, à l'occasion de la disparition de la tension d'alimentation du composant.

Ces circuits FRAM se comportent exactement comme les SRAM mais, de technologie ferro-magnétique, ils ne perdent pas leur données même en cas de perte d'alimentation.
Et personne n'y a déjà pensé? Si, bien-sûr :

Ça se trouve ici : http://pinforge.com/6116.html

Tout va bien alors! Oui, c'est parfait, sauf que ce circuit FM1608 est obsolète (tiens j'aurais encore pu caser 'obsolescence programmée' dans le titre de ce billet) et de toute façon fonctionne (fonctionnait) en 5V.

Mais, Ramtron (Cypress) propose ce même type de circuit en technologie moderne, donc fonctionnant en 3,3V. Et la, ça ne va plus du tout. Inutile de tenter la connection d'un tel composant en environnement 5V, norme de toutes les machines dont il est question dans ce billet. Cela risque fort de ne pas plaire à la FRAM, pas plus qu'à Denis Bodor (des éditions Diamond).

Il faut donc adapter les signaux! Avant de présenter mon prototype sur la question, je tiens à préciser qu'il s'agit d'un prototype et que c'est en pleine conscience et possession de mes moyens que j'ai adopté les solutions présentées ici :

Tada!

Pour adapter les signaux du bus d'adresse, j'ai implémenté sur la face cachée du circuit ci-dessus, un ensemble de ponts diviseurs réalisés à partir de résistances cms en boîtier 603. Pour déterminer les valeurs des résistances, j'ai considéré la charge CMOS que cela pouvait présenter aux sorties du processeur, ainsi que la fréquence de coupure et donc la fréquence maximale atteignable par ce système en considérant la capacité d'entrée des signaux de la FRAM. Le tout pour obtenir quand même un rapport de division me permettant d'obtenir les 3,3V à partir du 5V. Petit jeux amusant mais digne du parfait hérétique!
Pour le bus de données, j'ai adopté un convertisseur standard de bus 3,3V <-> 5V.

La raison profonde de ce choix, en vrai, est qu'après avoir tenté la mise en place sur un circuit imprimé si petit, de composants logiques me permettant d'effectuer l'adaptation voulue de tous les signaux, je me retrouvais avec des caractéristiques de circuit imprimé difficilement réalisable par les fournisseurs standards, ou en tout cas, à un prix pas vraiment amateur!

J'ai donc tenté ma chance d'une autre façon. J'ai considéré que la plupart des synthétiseurs, enfin ceux que je possède, ne sont équipés que d'une très petite partie processeur. En général une RAM, une ROM et très peu de buffers de bus. D'autre part, ces systèmes fonctionnent à très faible vitesse et n'accèdent pas aux circuits à moins de 100ns. Ma solution devait donc convenir tant en terme de charge sur le bus d'adresses qu'en terme de fréquence de fonctionnement.

Et revoici le terminal Télémécanique XBT, dont j'ai en partie décodé le fonctionnement pour l'adapter à mes besoins, en l’occurrence tester mon prototype de FRAM. Ce terminal XBT ressemble très fortement à beaucoup de parties processeur des synthétiseurs 'de la belle époque', ça tombait bien...

La FRAM juste sous l'émulateur d'EPROM.

Le résultat est très probant. J'ai programmé le terminal pour écrire les 32K octets de la FRAM alternativement avec le code 0xAA et 0x55 avec lecture totale de la mémoire avant changement de code, et vérification de la donnée lue. Le tout en boucle continue. Cela fait quelques jours maintenant que le système fonctionne en permanence.

Je me contente d'afficher que le test est effectué lorsque je ne trouve aucune erreur à la suite d'une boucle complète d'écriture/lecture. Sinon, un message plus...laconique apparaît! Pour l'instant, j'obtiens plutôt ceci :

Avec un film plastique devant l'écran pour en améliorer le contraste

.

Perspectives : je laisse le système fonctionner de la sorte encore quelques jours et si tout se passe bien, je l'implémenterai dans un des synthétiseurs à ma disposition. Puis, si le fonctionnement s'avère concluant, j'étudierai un système plus 'orthodoxe' avec adaptateur de bus adéquate.

Update 18/10/2014

Les tests effectués à l'intérieur d'un JX3P n'ont pas été concluants. Après avoir retiré la RAM de la carte mère du synthétiseur, j'ai placé sur le circuit imprimé un support de circuit intégré pour y insérer le montage à FRAM, non sans avoir effectué les quelques adaptations de câblage nécessaires. La ram d'origine est une 6116 (ou équivalente) alors que le montage à FRAM possède le brochage d'une 62256. A la mise sous tension, le synthétiseur s'initialise correctement. Cependant par la suite, il ne réagit plus.

Testés à l'oscilloscope, les signaux de la carte mère semblent corrects mais pas obligatoirement aux bons niveaux. Comme le JX3P possède des bus d'adresses et de données plus étendus, avec beaucoup plus de composants que sur ma carte de test, la chute d'impédance du bus généré par les diviseurs de tension du montage FRAM perturbe la partie processeur.

C'est ce que je craignais. Je n'ai pas été déçu!
Une étude avec adaptation complète du bus d'adresse s'impose donc!

Pour la sauvegarde et la restauration des paramètres sonores de la machine, j'ai utilisé un enregistreur DAT portable Sony TCD-D8. Une fois les niveaux sonores réglés, le fonctionnement est parfait!

Update 04/02/2015

Nouvelle version fonctionnelle du projet NVSRAM.