Préambule : cliquez éventuellement sur les photos pour les voir en meilleure qualité.

Voici la liste chronologique des réparations faites en 2019.

**************************

* Mardi 19 novembre 2019 *

**************************

-1- Recherche visuelle des anciennes interventions

On voit très bien les interventions manuelles suivantes (dessoudage et ressoudage)

a) Circuits IC74 et IC75, les deux RAMs statiques de la pile système

IC74 et IC75

IC74 et IC75 ont été dessoudées et remises sur support (sheet 1).

b) Circuit IC83 74LS241

IC46

IC46 = 74LS241 = buffer de bus d'adresse a été dessoudé et ressoudé (sheet1).

c) Circuit IC46 TBP18S030N = PROM bleue

IC46

IC46 = TBP18S030N = PROM bleue a été dessoudée et mise sur support.

d) Circuit IC52 TBP18S030N = PROM Rouge

IC52

IC52 = TBP18S030N = PROM rouge a été dessoudée et mise sur support (sheet 5) Remarques concernant la recherche visuelle : ce DAI a déjà été "opéré".
Les bonnes nouvelles sont que :

celui qui est intervenu n'était pas un débutant (les opération de dessoudage et soudage sont correctes).

qu'il savait où regarder (investigation des PROM et du bus d'adresses).

La (peut-être) mauvaise nouvelle c'est que celui qui est intervenu et qui n'était pas un débutant n'a pas trouvé la panne... A moins qu'il l'ait trouvée et réparée et que le DAI soit de nouveau... Dans le cas contraire ça s'annonce difficile. A suivre...

-2- Réparation de la sortie cassette

Dessoudage, vérificatio, ressoudage de CH2 (sortie cassette).

Dessoudage complet de CH2 (inductance de 4,7 mH = 4700 µH cf sheet 5 en bas à droite) patte déssoudée repérée par Michel Meyer ;
Vérification à l'inductancemètre 5,13 mH < x < 5,4 mH ==> Ok car c'est une inductance possédant une précision de 10% ;
Amincissement + égalisation des pattes de l'inductance trop épaisses pour les trous du PCB ;
Ressoudage de l'inductance CH2 ;

L'enregistrement de cassettes est désormais possible car le débranchement de l'inductance CH2 rendait impossible le moindre signal sur la sortie "OUTPUT CASSETTE" cf en bas à droite de sheet 5 ;

-3- Vérification des niveaux d'alimentation en isolant le DAI

Dessoudage de J4 (reliant la sortie alimentation +12V au reste du DAI) ;
Dessoudage de J5 (reliant la sortie alimentation -5V au reste du DAI) ;
Dépose du fusible F1 (reliant la sortie alimentation +5V au reste du DAI) ;
Mesure du "-5V" ==> -5,2 V ==> OK en sortie d'alimentation ;
Mesure du "+12V" ==> 9,80 V ==> ALIMENTATION +12V KO en sortie d'alimentation
Mesure du "+5V" ==> 4,98V ==> OK en sortie d'alimentation ;

*****************************

* Mercredi 20 novembre 2019 *

*****************************

Petite disgression

Avant le contrôle de l'alimentation, un petit tour avec l'endoscope sous le coin droit en bas du clavier, pour vérifier que nous avons bien une révision 7 entre les mains.

Comment trouver la marque de révision du DAI.

C'est donc bien une REV.7 !

Contrôle de l'alimentation

Voici le pont de diode dessoudé, notez les quatres lettres que j'ai rajoutées en rouge sur la photo juste sous le pont de diode.
Notez également le petit schéma de fonction du pont redresseur (incarné ici par le composant B4003700/2200) que j'ai consciencieusement posé sur le dessus du transformateur torique.

Le pont redresseur.

Mesures effectuées par rapport à la masse :

VA = 7,4V alternatif Pas normal d'avoir une composante alternative sur la sortie + du pont de diodes ! ;
VA = 16,5V continu Selon le schéma REV 5, la tension devrait être de 22V continu en ce point ! ;
VB = 18,6V alternatif ;
VC = 18,6V alternatif ;
VD = -25V continu ; Selon le schéma REV 5, la tension devrait être de -22V continu en ce point ;
VB-VC = 37V alternatif.

On voit que nous avons 16,5V continu au point A, si vous jetez un oeil sur le schéma PSU sheet 10 de la REV.5 (la sheet 10 de la REV.7.1 n'indique rien du tout), vous constaterez que nous devrions avoir +22V et ceci pour une tension d'entrée de 220V sur le secteur ! Or chez moi je suis en 240V tout rond ! Autrement dit je devrais avoir en ce point environ 24 V et j'ai donc 7,5V de moins... Le point VD indique quant à lui -25V ce qui n'est pas -22V mais qui est proche de -24V compte tenu de la tension de mon secteur !
La tension alternative aux points VB et VC est de 18,6V c'est proche de 25 divisé par racine de 2 ==> OK.
La tension en sortie + du pont redresseur n'est pas bonne.

Mesures de vérification sur le pont de diodes avec le mutimètre (position diode)

Suivre sur le schéma ajouté sur la photo

Dans un sens VB-VA = 0,540V et dans l'autre la diode est bloquée ==> normal ;
Dans un sens VC-VA = 0,527V et dans l'autre la diode est bloquée ==> normal ;
Dans un sens VD-VB = 0,527V et dans l'autre la diode est bloquée ==> normal ;
Dans un sens VD-VC = 0,550V et dans l'autre la diode est bloquée ==> normal ;

Le multimètre ne fait pas apparaitre de défaut sur le pont de diodes.

Mesures à vide sur le secondaire du tranformateur torique

Suivre encore sur le schéma ajouté sur la photo

VB-VC = 37V alternatif ==> normal ;
VB par rapport à la masse = 18,6V ==> normal ;
VC par rapport à la masse = 18,4V ==> normal ;

Le transformateur est en bon état.

Mesures de la résistance R157

A noter que la partie {R157 (3,3 ohms 2W) + transistor T15 = TIP34 + condensateur C144 10 µF 35V au tantale} a été rajoutée après la révision 5 et a été modifiée en révision 7.1, or ici le DAI est en révision 7 !!! Voyons voir ce que cela signifie...
D'abord la résistance : elle mesure 3,2 ohms au multimètre, elle est donnée pour 3,3 ohms sur le schéma ==> OK !

Dessoudage de T15 = TIP34 et du condensateur C144

TIP34, le soin apporté... Pas de commentaire !

Il y a beaucoup à redire sur le soin apporté par ceux qui sont à l'origine de ce design et de cette implémentation, la modification apportée après la REV.5 n'a pas donné lieu à un nouveau circuit imprimé correct, le condensateur C144 était soudé directement sur le collecteur de T15 et il semblerait que ces modifications aient été faites au "gros fer à souder", regardez l'état du boitier du TIP 34 que j'ai dessoudé par le dessous du PCB ! Surprise après avoir commencé à sortir le transistor, il tenait toujours du fait de C144 et une fois libéré, on voit qule le boitier a morflé lors de sa mise en place !

Bref, vérifions ce transistor :

C'est un PNP de puissance ;
patte de gauche = base ;
patte du milieu = collecteur ;
patte de droite = emetteur ;
Courant de collecteur pour le test = 2,5 mA ;
Courant de base pour le test = 4,66 mA ;
Gain = 205 ;
Courant de fuite nul ;
Vbe = 0,63V ;
Test d'oscillation ==> il oscille correctement.

RAS, malgré sa tête ce tansistor fonctionne correctement.

Test du condensateur C144

Surprise, sa valeur est de 1,03 µF et son ESR de 17 ohms
La modification apportée par la version 7.1 (cf note en bas de sheet10) a été de changer ce condensateur par un condensateur de 10 µF 35V au tantale ! Ce n'est probablement pas sans raison, ce condensateur est donc potentiellement à l'origine de la panne sur la partie 12V, nous avons un condensateur de 1 µF en lieu et place d'un condensateur de 10µF ! Son ESR (résistance équivalente série) est de 17 ohms environ ce qui est classique pour cette capacité.
Mais je doute que ce soit lui et donc je continue l'investigation sur le régulateur 7812 et non pas LM340 comme spécifié sur les divers schémas..

Test du régulateur 7812

Test du régulateur 12V

Il y a des intuitions comme ça... On ne sait pas pourquoi... Depuis le début et sans vraiment savoir pourquoi je pensais que le régulateur 12V etait en bonne santé. Pour en avoir le coeur net, je l'ai dessoudé et testé à part. Comme vous pouvez le voir sur la photo, une fois qu'on lui injecte une tension continue de 16,5V, il régule parfaitement et nous sort du 12V. Donc lui aussi semble être en bonne santé.
Néanmoins, je ne l'ai pas testé avec cette composante alternative de 7,4V que j'ai trouvée sur la sortie + du pont redesseur (et donc l'entrée IN du 7812) !
Etant donné que Michel Meyer a décidé d'investir dans une alimentation du 21ème siècle, je ne perdrai pas plus de temps dans cette investigation, d'autant qu'il reste encore 3 condensateurs à suspecter et qu'après tout c'est peut-être le pont de diodes qui ne se comporte pas de façon correcte une fois branché sur la sortie alternative du secondaire du transfo torique.
On en restera là pour cette alimentation que je vais entièrement démonter (inutile de garder ce poids mort sur la carte du DAI)
Mais avant, voici quelques piste alternatives de remplacement suggérées par Pascal Janin qui a eu la gentillesse de nous envoyer ceci :

Suggestion de Pascal Janin

Pourquoi ne pas utiliser un bloc d'alim 5V/12V comme çelle-ci RD65-A (cliquez pour le datasheet) et vendue notamment par gotronic ?

Le problème de faire du -5V qui peut être résolu simplement comme ça (cliquez pour le datasheet) : en utilisant ce montage buck-boost décrit en page 19 (exemple avec -12V, mais avec le modèle 5V ça marcherait aussi), qui inverse l'alimentation, tout simplement !

Une alternative

Suite des travaux : branchement sur une alimentation de laboratoire

C'est décidé, je vais supprimer totalement cette alimentation pour en mettre une neuve mais il faut d'abord que je sache si ce DAI va fonctionner, les travaux prévus pour demain 21/11/2019 : faire une prise externe pour brancher +5V, +12V et -5V et essayer de démarrer ce DAI en espérant que le défaut d'alimentation n'aura rien endommagé.

**************************

* Jeudi 21 novembre 2019 *

**************************

Configuration de l'alimentation pour générer le -5V, +5V et +12

Exemple de réalisation des 3 sources de tensions avec une alimentation de laboratoire.

Voici le principe de ce qu'il faut faire sur ce type d'alimentation de labo avec sorties flottantes disposant de 2 sorties variables et d'une sortie fixe +5V. On pourrait faire la même chose avec 3 alimentations indépendantes.

Position de l'alimentation sur "IND" = sorties indépendantes
Relier comme indiqué sur le schéma intégré à la photo
Régler avec une source de consommation appropriée la consommation maxi à 300 mA sur le +12 V et 300 mA sur le -5V

Sur la photo :

fil vert = -5V ;
fil noir = 0V = masse ;
fil rouge = +5V ;
fil bleu = +12V ;

Après vérification des tensions au multimètre entre chacun des fils de couleur et la masse (fil noir), il faut procéder à la création du fil qui ira se brancher sur le DAI.

Création d'un câble pour amener le -5V, +5V et +12V au DAI

Ce câble me servira pour d'autres dépannages, il est donc conçu pour pouvoir se brancher sur des DAI normaux (dont l'alimentation n'aura pas été démontée).

Bout qui va dans l'alimentation

Tout d'abord comme je n'avais plus de fiches bananes pour faire la connexion à l'alimentation de laboratoire, j'ai limé 4 fiches de prises de terre récupérées sur de vieilles prises 220V cassées.
Puis j'ai soudé 4 fils sur chacune de ces fiches de fortune.
Fils que j'ai munis de gaines thermorétractables et maquillés de scotch vert (-5V), rouge (+5V), bleu (+12V), noir (commun) pour éviter les erreurs de branchement.

Bout qui va dans le DAI

J'ai récupéré un fusible grillé dont j'ai cassé le verre et récupéré un des embouts dans lequel j'ai soudé le fil rouge (+5V) ceci me permet de connecter le +5V directement sur le support de fusible F1 (cf sheet 10).

Pour la prise 0V noire, j'y ai soudé une cosse pour profiter de la vis qui supporte une grosse diode sur le boitier métallique de l'alimentation.

Enfin pour les fils -5V (vert) et +12V (bleu), ils seront soudés côté DAI à l'endroit où il y avait les cavaliers J4 (+12V) et J5 (-5V) Cf sheet 10.

Voici la photo montrant le résultat de cette prise improvisée pour repiquage sur le support de fusible.

Adaptateur pour repiquage dans le support de fusible.

Voici la photo montrant le câble terminé.

Câble pour branchement sur une alimentation de laboratoire

Câble pour branchement du DAI sur une alimentation de laboratoire.

Voici la photo montrant les soudures des fils vert (-5V) et bleu (+12V) à l'endroit des cavaliers J5 et J4 respectivement.
La soudure est au moins aussi belle que celles faites par INDATA', non ?
A droite des soudures vous voyez deux trous correspondant au côté "alimentation" des cavalier J5 et J4. C'est là qu'il ne faut pas être distrait et bien choisir de souder sur les pastilles qui vont sur les circuits du DAI et non pas vers l'ancienne alimentation.

Zoom sur l'endroit où souder les câbles vert et bleu.

Et enfin voici le DAI entièrement branché et attendant le moment fatidique.

Cliquez sur la photo et zoomez pour voir comment le +5V a été branché sur le support de fusible. Là encore il faut faire attention à mettre le connecteur improvisé sur le côté du support le plus proche de la prise RS232.

Le câble branché sur le DAI.

La première mise sous tension

Après avoir vérifié plusieurs fois que le branchement était conforme au schéma intégré à la photo du chapitre "Configuration de l'alimentation pour générer le -5V, +5V et +12", le grand moment est arrivé.

Premiers résultats

Après avoir vérifié les tensions à différents endroits du DAI (et notamment sur les boîtiers mémoires 4116 qui font usage des trois tensions) j'ai constaté que la carte vidéo ne faisait pas de vidéo mais un horrible bruit.
Le premier test a été réalisé avec la carte vidéo du DAI de Michel ainsi que le câble qui l'accompagnait.
Devant ce résultat, j'ai substitué la carte de mon DAI à celle de Michel.
Pareil pour le câble : j'ai pris celui de mon DAI.

La réparation de cette carte vidéo s'inscrit donc au programme !!!

Seconds résultats

Là c'est beaucoup mieux ! j'ai obtenu un son normal et une image stable !

Avec l'alimentation du DAI, Michel avait observé une vidéo qui était très instable, ceci s'explique très bien par le fait que le +12V atteignait à peine 9V, ce qui occasionnait une perte de tout contenu mémoire. Le circuit vidéo voyant un contenu sans cesse changeant affichait une image totalement aléatoire et instable.

Avec l'alimentation de laboratoire, on observe des images stables, ce qui semble attester de la bonne santé de la partie vidéo.
Voyez quelques exemples de ce que j'ai pu observer.

Le DAI semble nous dire que ça va coûter cher !

1ère image stable.

Un écran bariolé mais stable !

2ème exemple d'image stable.

Un écran stable composé de barres jaunes sur fond bleu ! La photo est trompeuse, mon appareil a surpris des choses invisibles à l'oeil. On ne voyait que le fond bleu (bien bleu) et les barres verticales jaunes.

3ème exemple d'image stable.

Troisième série de résultats

Après avoir fait plusieurs fois "RESET" j'ai pu constater divers messages rassurants.
J'ai vu s'afficher "DAI PERSONAL COMPUTER" et même BASIC V1.2 !!! Pas longtemps mais quand-même !

Test de la mémoire statique 2111 (pile système)

Pour ce test, j'ai fait au plus simple, j'ai monté les deux 2111 sur mon propre DAI qui a démarré et exécuté un programme BASIC avec les deux 2111 de Michel.

Test simple et efficace qui valide le fonctionnement de cette partie

La suite des travaux

Là il faut réfléchir un peu, pour le moment ça ressemble beaucoup à une panne mémoire. Je vais tenter de la prouver sans démonter la mémoire mais ce n'est pas gagné !

Je vais probablement attendre de recevoir la nouvelle alimentation officielle du DAI car le fonctionnement avec l'alimentation de laboratoire est plus risqué.

Dans l'attente j'en profiterai pour démonter l'alimentation en place.

Il y a aussi la carte vidéo de Michel à remettre en état.

***************************

* Samedi 23 novembre 2019 *

***************************

Relecture des ROMs

Cette journée a été passée à la relecture des ROMS présentes sur le DAI en panne et à essayer le code assembleur que Michel a conçu pour tester l'ensemble de la mémoire.
==> Les ROMs testées sont celles avec le BASIC V1.2, CF le tableau, les ROMs de Michel sont indiquées par une croix.

Les différentes versions de ROMs DAI que j'ai vu passer.

Spécifications d'un programme de test

Etant donné que je suspecte un problème mémoire et que je souhaite limiter au maximum les dessoudages, souhaité disposer d'une ROM qui viendrait se subsituer à la ROM non switchée (C000-DFFF) et qui booterait directement sur un programme de test de la mémoire.
Après avoir partagé cette idée avec Michel, nous sommes convenus qu'il écrirait ce programme, ce qu'il a fait avec brio et sans moyen de tester son code avant de me l'envoyer !!!

Les spécifications envoyées

Ce programme doit servir à éviter de dessouder les mémoires au hasard avant de trouver celles qui sont en défaut.

Que le programme soit le moins bavard possible et qu’il indique directement le ou les boitiers en défaut en envoyant les messages sur la sortie RS232.

J'avais déjà fait un programme de test mémoire (présent sur ce site) mail il devait tenir dans un tout petit morceau de la pile système et être facile à saisir sous UT... De plus il supposait déjà un certain "bon" fonctionnement de la machine !

Préambule : Pour éventuellement pouvoir réutiliser les primitives déjà présentes en ROM et écrire sur la sortie RS232 l’idée est de repérer dans la bank de ROM non switchée tout un pan de code inutile et d’utiliser cet emplacement pour y mettre le programme de test (qui doit prendre la main dès le boot) en clair on devra trouver en C000, un jmp vers cette adresse.
Mais ceci n'est possible que si les dites primitives ne font pas usage de la mémoire !!! Car le programme à réaliser va écrire dans la mémoire sur toute la plage d’adresse de 0000 à BFFF.
Si les primitives font usage de la mémoire, il faudra écrire tout le code et dans ce cas inutile de chercher un pan de code à écraser (C'est ce que Michel décidera in fine).

comment identifier le ou les boitiers en cause :

Mon programme initial faisait plusieurs cycles d’écriture et de relecture de la mémoire, mais s'arrêtait dès la première erreur rencontrée. Dans ce nouveau programme, il faudra indiquer toutes les erreurs. Le principe est d’écrire dans toute la mémoire puis de ne relire qu’après avoir tout écrit, ce qui laisse le temps aux bits de changer ! Une écriture suivie d’une relecture immédiate risque de ne pas laisser le temps à l’erreur d’apparaitre ! Les mémoires dynamiques 4116 sont constituées de condensateurs qui prennent (quand tout va bien) un tout petit peu plus de 2 ms pour se décharger. Bref il faut laisser du temps à l’erreur pour qu’elle apparaisse !

Pour identifier quels sont les boitiers mémoire en cause, il faudra identifier pour chaque octet écrit, le ou les bits qui sont différents après relecture. J'ai réalisé un tableau spécialement pour cette identification des boitiers mémoire (cliquer pour agrandir) :

Identification des mémoires défaillantes

Comment identifier les mémoires défaillantes par programme.

Exemple : après avoir écrit « F5 » partout entre 0000 et BFFF dans la mémoire, on s'attend à relire « F5 » partout mais au moment de relire on trouve « D7 » à l’adresse 4010. Dans ces condition il faut identifier les bits en différence. Pour l’exemple les bits 1 et 5 sont différents. Donc en regardant le tableau :

4010 c’est une adresse paire qui se trouve dans la bank B ==> ligne rose ;
==> Bit 1 en erreur ==> IC61 en erreur ;
==> Bit 5 en erreur ==> IC87 en erreur.

Si l’erreur avait été dans la plage 0000, 3FFF il aurait été inutile de tester la parité de l’adresse, mais pour une lecture plus facile du tableau j’ai dupliqué la ligne bleue.

*****************************

* Dimanche 24 novembre 2019 *

*****************************

Analyse du boot

Voici comment j'ai connecté les 16 lignes d'adresse + le signal d'échantillonnage récupéré sur Phi2 ainsi que la masse commune ! Tout a été pris sur le bien pratique X-Bus !

Brancheent de l'analyseur logique sur le X-Bus.

Voici 3 écrans issus de l'analyseur logique. Le commentaire vient après le troisième écran.

1er écran analyseur au boot.

2ème écran analyseur au boot.

3ème écran analyseur au boot.

Commentaires de ce que l'on voit avec l'analyseur

Tout d'abord, en cliquant et agrandissant les captures d'écran on peut voir sur la gauche l'indication des 16 lignes d'adresse de A10 à A15. Ces lignes ont été groupées en BUS (merci au logiciel accompagnant mon analyseur, tous ne permettent pas de le faire...).

On voit ainsi et en hexadécimal, la valeur du mot de 16 bits inscrit sur la ligne "Bus1", ce qui est bien pratique !

On peut voir dans la colonne "Trigger" sur la ligne "Bus1", que j'ai positionné la valeur "0xC000". Ca me permet de demander à l'analyseur de se déclencher quand il verra passer la valeur "0xC00" sur le bus d'adresses. Là encore, merci à ce logiciel qui fait la différence !

Par ailleurs j'ai pris la décision d'échantillonner les signaux en utilisant une horloge externe (Phi2 du DAI) ce qui permet d'éviter l'apparition de valeurs erratiques dues à la non stabilisation du bus d'adresses.
Comme je n'ai que 16 lignes possibles sur mon analyseur (j'aurais dû en acheter 2), j'ai décidé de ne visualiser que le bus d'adresses et vous allez voir qu'on peut déjà comprendre beaucoup de choses sans même visualiser ce qui passe sur le bus de données.

Enfin, on peut voir qu'avant l'apparition de "0xC000" le DAI était depuis un petit moment (au moins supérieur à 25,375µs) dans un état de stupeur avec un bus d'adresse figé à "0x3FFF". Je l'ai sorti de cet état par un appui sur le bouton reset.

Un analyseur enregistre en permanence ce qui se passe, de ce fait lorsque je lui demande de se déclencher lorsqu'il voit passer "0xC00" sur le bus d'adresses, je peux aussi lui demander de m'afficher ce qui se passait un peu avant et c'est ce que l'on voit ici dans les 25,375 µs précédent le déclenchement.

Que voyons nous ?

Pour comprendre, ouvrez les "scans" du firmware manual de H.J. Boerrigter.

Il y a 0xC000 sur le bus d'adresses, donc le processeur y va pour lire le premier octet de l'instruction "JMP :C719" qui en comporte 3. Ce premier octet est "0xC3" mais on ne le voit pas sur l'écran (je vous ai déjà dit que je n'avais que 16 lignes à ma disposition, donc je suppose qu'il lit "OxC3"...).
Quand le 8080 lit "C3", il décode que c'est une instruction "JMP" et qu'il lui faut 2 octets de plus, par conséquent, il faut s'attendre à ce que le 8080 présente les deux adresses suivantes sur le bus, à savoir "0xC001" et "0xC002".
C'est ce qu'on voit dans les deux adresses qui suivent ! Parfait le 8080 semble commencer à fonctionner !
D'après le firmware manual, ces deux octets sont "0x19" et "0xC7", et si c'est bien ce qui est lu à ces adresses, alors le 8080 va comprendre maintenant qu'il doit aller en "0xC719" sans se poser d'autres questions.
C'est bien ce que l'on voit sur la ligne "Bus 1" ! Yeah !
Avançons dans le FM (firmware manual), que voyons-nous en 0xC719 ?
Ah ! Nous entrons dans la routine de "RESET". Le processeur va lire l'octet "0x31" et il comprend qu'il s'agit de l'instruction "LXI SP" et qu'il lui faut encore deux octets de plus !
Il présente donc "0xC71A" et "0xC71B" sur le bus d'adresse où il va récupérer successivement "0x00" et "0xF9".
Le 8080 a donc tout ce qu'il faut pour initialiser le registe pointeur de pile avec "0xF900" ;
Une fois cette instruction exécutée, le PC augmente de 1, on doit donc trouver 0xC71C sur le bus d'adresses où le 8080 va trouver l'octet "0x3E".
C'est bien ce que l'on voit sur l'écran."0x3E" c'est "MVI A" et le 8080 comprend qu'il lui manque la valeur à mettre dans le registre A, il va donc la chercher à l'adresse "0xC71D" où il va trouver "0x30". A l'issue de cette instruction il y aura donc "0x30" dans A, c'est à dire "00110000" en binaire.
Le 8080 va à l'instuction suivante en "0xC71E" où il trouve "0x32" qui est l'instruction "STA" qui demande au processeur de mettre la valeur du registre A dans une adresse spécifiée sur 2 octets après le code de l'instruction. On s'attend donc à trouver maintenant 2 adresses successives sur le bus, à savoir "0xC71F" et "0xC720" pour y lire "0x00" puis "0x40".
On voit bien la présentation de ces deux adresses, tout va bien et maintenant le processeur sait qu'il doit aller mettre le contenu de A à l'adresse "0x0040" !
C'est ce qu'il va faire, insconscient qu'il est de l'état de la RAM dynamique, car "0x0040" est compris dans la plage de RAM "0x0000"-"0xBFFF" ! A partir du moment où le code commence à s'appuyer sur la RAM qui n'est probablement pas solide, il faut s'attendre à un effondrement... Mais tant qu'il ne la relit pas pour prendre des décisions, continuons...
On voit ici que le DAI est un menteur, car en "0x0040" il doit y avoir le reflet de la dernière écriture sur le port "0xFD06" et nous venons de tracer à la culotte ce qu'il vient de faire depuis le démarrage et il n'a encore rien envoyé sur ce port ! Progressons...
Le processeur vient d'exécuter l'instruction de 3 octets "STA :0040" en "0xC71E" Son PC est désormais positionné en "0xC721", c'est bien ce que l'on voit toujours sur le premier écran de capture.
Maintenant le processeur trouve encore le code "0x32", je ne vous la refais pas, il s'agit encore d'une instruction "STA", le processeur va donc générer les deux adresses "0xC722" et "0xC723" pour aller chercher les valeurs "06" puis "FD" pour comprendre qu'il doit donc aller mettre le contenu de A qui n'a pas changé à l'adresse "0xFD06".
On voit bien la génération de l'adresse "0xFD06" sur le bus, c'est donc à ce moment précis que l'écriture sur le port FD06 a lieu ! Ca se passe 1,25µs après avoir dit qu'il l'avait fait ! Il peut s'en passer des choses pendant cet intervalle !
Marquons une petite pause...

Qu'avons-nous déjà appris au cours de ces 6,8 µs ?

D'abord que le DAI boot bien en "0xC00" après appui sur le bouton reset ;
Que le 8080 lit et décode correctement les instructions
Que les données lues sur le bus de données sont bonnes sinon le 8080 serait incapable de lire correctement la moindre instruction. Nous le savons car les codes lus sont visiblement identiques à ce qui est écrit dans le FM.
Que le bus d'adresse fonctionne bien également puisque nous arrivons là où l'on doit arriver, c'est la progression correspondant à ce qui est écrit dans le FM qui nous l'indique !
Que la progression du "PC" (vous aviez déjà compris qu'il s'agissait du program counter je suppose) fonctionne bien !
Que le DAI peut mentir quelques instants.
Que la pile fonctionne ? Non, nous le savons pas encore car nous n'avons pas eu l'occasion de subir un seul "RET", mais ça viendra ;

Ben... Ce n'est déjà pas si mal, nous pouvons continuer l'analyse.

Après avoir écrit "00110000" en "0xFD06" les bit 6 et 7 du port sont donc à zéro ce qui valide la ROM IC71 donc le segment ROM bank 0 et si vous voulez savoir pourquoi, allez ici.
Au passage, lorsque les bits 4 et 5 de ce même port sont à 1, ça arrête les moteurs des lecteurs de cassettes quant aux bits 1 et 2, ils invalident les paddles lorsque qu'ils sont mis à zéro... Ca c'est juste pour reprendre notre souffle avant de poursuivre l'analyse...
Nous voici donc arrivés en "0xC724" où le processeur trouve le code "0xCD", il reconnait une instruction de type "CALL" et il sait donc qu'il va falloir aller chercher l'adresse de débranchement dans les deux octets suivants, et c'est repartit, le processeur génère donc les adresses "0xC725" et "0xC726" sur le bus d'adresse, ce qui va enfin nous donner l'occasion de passer à la deuxième capture d'écran !
Le temps passe vite, il est déjà 8,5µs sur le deuxième écran. Et si l'on en croit M. Boerrigter, le processeur devrait trouver successivement "0xFB" puis "0xD8" et comprendre qu'il va falloir faire un "CALL :D8FB"
C'est pas tout de faire un call, il faut pouvoir revenir !. Le processeur doit donc mémoriser la prochaine instruction à exécuter après avoir fait une disgression en "0xD8FB", or à l'heure qu'il est au moment de cette exécution, l'instruction suivante se situe 3 octets plus loin que "0xC724", soit en "0xC727"
Et où le processeur va t-il stocker cette adresse de retour ? A l'endroit prévu pour, c'est à dire sur le haut de la pile. C'est la première fois que le processeur se sert de la pile depuis le reset et si vous vous souvenez (c'était il y a 8,5 µs) le pointeur de pile SP a été initialisé avec "0xF900".
Le processeur doit donc décrémenter de 1 le pointeur de pile afin d'y stocker les bits de poids forts de son PC, c'est ce qu'on voit sur le bus d'adresse où il présente "0xF8FF" au moment l'on suppose qu'il s'apprête à écrire "0xC7"
Suite à quoi il décrémentera encore de 1 le pointeur de pile afin d'y stocker les bits de poids faibles de son PC, c'est ce qu'on voit sur le bus d'adresse où il présente "0xF8FE" au moment l'on suppose qu'il s'apprête à écrire "0x24"
Voilà, c'est seulement maintenant qu'il peut partir le coeur léger en "0xD8FB" car il sait pouvoir revenir tant que la pile ne lui jouera pas de mauvais tours.
Vous n'en croyez pas vos yeux, mais on voit bien "0xD8FB" à 9,8057 µs du moment où la pointe de mon stylo s'est abattue sur le bouton reset !
Avançons dans le FM, en "0xD8FB", qu'est que M. Boerrigter nous dit ? Ben que ça ne rigole plus, on rentre dans le gestionnaire d'interruptions. Le processeur commence par lire l'octet "0x21"... C'est quoi encore ce code ? C'est "LXI H quelque chose", je vois ce que c'est, on me demande de charger mon registre HL avec une valeur, il faut donc que j'aille récupérer cette valeur sur les deux octets suivants... C'est lassant à force, donc je vais générer "0xD8FC" et "0xD8FD" pour faire deux accès... Ca va je suis toujours dans la ROM et je trouve "0xF8" et "0xFF"
C'est bon, j'ai mis "0xFFF8" dans HL, Je vais aller voir en "0xD8FE" ce qu'il faut faire...
Vous avez compris maintenant, alors j'abrège, je génère "0xD8FF" pour trouver la veleur "0x04" qu'on me demande de mettre dans le registre A
Je génère "0xD900"", c'est un "MOV M,A"", ça veut dire au final que je dois mettre A à l'adresse contenue dans HL, je vais donc générer "0xFFF8"" pour y coller A
Voilà c'est fait, et je vais voir en "0xD901"" la suite du programme, facile c'est encore un STA, il va me falloir deux accès, donc "0xD902"" et "0xD903"" où je trouve successivement "0x5F"" et "0x00""... Ah zut il va falloir encore écrire dans cette mémoire RAM ?
Soyons fous, je génère "0x005F"" sur le bus et je stocke le contenu de A c'est à dire "0x04"".
Ce coup-ci je ne ments pas, j'ai déjà mis "0x04"" dans "0xFFF8"", je mets à l'adresse "0x005F"" le duplicat de ce que j'ai mis en "0xFFF8"", c'est bien ce qui est prévu dans la memory map.
J'en suis à l'adresse "0xD904", c'est un code sur 2 octets, je vais donc générer "0xD905" pour récupérer la valeur "0xF4" etc

Vous avez compris, on peut continuer longtemps comme ça, je vous laisse (si ça vous amuse), le soin de traduire la fin de cette deuxième copie d'écran et même le troisième.

Je ne continue pas car regardez le FM, nous allons encore enchainer des "CALL" et le prochain "CALL" vous allez le repérer en fin du 3ème écran !

Donc, je vais de ce pas aller voir ce qu'il y a après pour tomber sur un RET qui nous ferait revenir après le dernier CALL... Et je l'ai trouvé pas loin, voici la 4ème copie d'écran :

4ème écran analyseur au boot, un CALL et un RET.

Regardez le FM en "0xD915"", on y trouve un "CALL 0xD9A3""... Et regardez le 4ème écran.

On voit le dépot de l'adresse "0xD9A3"" sur le bus, là il récupère l'octet "0x3E"" (selon le FM) puis on voit le processeur aller chercher l'octet suivant en "0xD9A4"" où il récupère "0x50"".
Ca correspond à l'instruction "MVI A,:50"" du FM.
On voit le dépot des adresses "0xD9A5"", "0xD9A6"" et "0xD9A7""
Ca correspond à l'instruction "STA :FFFB"" du FM.
On voit donc apparaitre l'adresse "0xFFFB"" sur le bus d'adresse, le temps d'y déverser le contenu du registe A.
Enfin, et c'est l'instruction que nous attendions, nous allons rencontrer un "RET" à l'adresse "0xD9A8"" que l'on voit très bien entre 30,1 et 30,8 µs après le reset sur la copie d'écran N°4.
Le processeur place donc le contenu du pointeur de pile sur le bus d'adresse, c'est ce qu'on voit "0xF8FC"" pour y récupérer les poids faibles de l'adresse de retour (normalement "0x18"")puis l'incrémente de 1 "0xF8FD"" pour y récupérer les poids forts (normalement "0xD9""). Suite à quoi il incrémente encore de 1 (ce que l'on ne voit pas)
Enfin, il place l'adresse reconstituée "0xD918"" dans le PC, ce qui le ramène bien 3 octets après l'adresse du dernier CALL qui était (cf ci-dessus) en "0xD915"".
Nous venons de voir le bon fonctionnement de la pile ! Ca ne signifie pas que c'est comme ça pour les 256 octets, mais c'est un bon signe !

Qu'avons-nous déjà appris au bout de ces 32 µs ?

Que beaucoup de choses fonctionnent sur ce DAI ! Que les programmes s'exécutent et que les retours de CALL se font bien !

Saurons-nous détecter ce qui ne va pas en continuant beaucoup plus loin cette analyse ?

Oui ! Mais il aura fallu beaucoup de patience car j'ai pu détecter un départ sans retour en "0xC743"" comme part hasard dans la routine "Init. screen RAM" que je vous laisse consulter dans le FM.

Une sérieuse piste de panne !

En "0xC743"" le processeur trouve l'octet "0xEF"", c'est à dire "11101111"" en binaire. Il reconnait une instruction de type "RST"". Une instruction de type RST a toujours le format suivant "11xxx111"".

Quand le processeur rencontre ce type d'instruction, il stocke l'adresse de retour en (SP-1) et (SP-2) puis il décrémente le pointeur de pile de 2 unités. Ensuite il effectue un branchement à une adresse qui est égale à huit fois la valeur de "xxx".

Ici "xxx"" vaut "101"", c'est à dire 5 en décimal, c'est donc une instruction "RST 5" et le processeur va donc se débrancher en 8*5 = 40 = "0x28"" !

L'on voit tout ça sur la 5ème copie d'écran ci-dessous !

5ème écran d'analyse avec un départ sans retour dans la fonction "Init. screen RAM".

Et là c'est la grande aventure qui commence, on voit que le processeur est parti (sans se méfier) dans la RAM dynamique (si l'on veut bien car ça faisait quand même une quarantaine d'années qu'elle était statique)... Bref, ici nous pénétrons sans l'inconnue et le processeur n'étant pas revenu en "0xC745"" comme il aurait dû le faire, je présume qu'il s'est perdu dans la RAM !

Plus que jamais, j'ai des doutes étayés quant à la santé de cette RAM et plus que jamais j'ai besoin d'un programme de test qui me crache ses résultats sur la RS232 ou me donne des indications autrement sans sortir de la ROM, cf la nouvelle idée ci-dessous.

Autre idée au cas où nous aurions des difficultés avec la RS232 pour debugging

Nous pourrions convenir de faire passer le code à certaines adresses précises de la ROM de dépannage lorsqu'un CI particulier est concerné par une défaillance. Il suffirait de regarder l'adresse présentée sur le bus pour en déduire le N° de CI défaillant !


*************************************************

* Lundi 25 novembre à mercredi 27 novembre 2019 *

*************************************************

Conception d'un nouvel outil : adapteur MK36000-D2364C/2764/M2F256

Pour disposer d'un programme en ROM permettant d'identifier les RAMs défaillantes, plusieurs versions devront être développées avant d'arriver au programme ad'hoc... Pour éviter de brancher et débrancher une 2764 avec son adaptateur sur le support des ROMs qui n'est pas fait être autant manipulé, il vaut mieux disposer d'un montage externe que l'on brancherait une seule fois sur le support DIP 24 de la ROM concernée, c'est l'objet de ce nouvel outil.

Pour éviter les séances d'UV pour réinitialiser les 2764 à chaque nouvelle version, j'ai décidé d'utiliser une M28F256 que j'avais sous la main. Au final j'ai réalisé un adaptateur externe me permettant d'utiliser au choix :

Une D2364C = MK36000 = Le type de CI utilisé pour les ROM initiales du DAI (DIP24) ;
Une 2764 (DIP28) ;
Une M28F256 = mémoire flash programmable et effaçable électriquement.

De plus, averc une M28F256 nous allons pouvoir utiliser 4 versions de ROM "511" dans le même boîtier.
Enfin, n'ayant pas de support ZIF 32 broches, j'ai utilisé un support ZIF 40 dont 8 broches sont inutilisées.

Cliquez sur le schéma et sa notice pour les visualiser confortablement.

Cliquez pour agrandir le schéma

Cliquez pour agrandir le résumé des connexions à réaliser et le mode d'emploi

Le texte qui suit se réfère à la fois au schéma ci-dessus (que vous pouvez agrandir à volonté) et au montage réalisé (photos ci-après). Les notations suivantes sont utilisées : ; LI = Levier d'interrupterur double ON-ON.

DS-G-B = DIP-Switche Gauche vers le Bas = DSW1 du schéma sur OFF ;
DS-G-H = DIP-Switche Gauche vers le Haut = DSW1 du schéma sur ON ;
DS-D-B = DIP-Switche Droit vers le Bas = DSW2 du schéma sur OFF ;
DS-D-H = DIP-Switche Droit vers le Haut = DSW2 du schéma sur ON ;
LI vers le haut = Levier Interrupteur double vers le haut = Interrupteur double S1 du schéma en position 1 ;
LI vers le bas = Levier Interrupteur double vers le bas = Interrupteur double S1 du schéma en position 2.

Le montage réalisé ci-dessous permet de choisir :

Une ROM d'origine (MK36000) ==> LI vers le bas (S1 en position 2=, DS-G-B, DS-D-H ;
Une 2764 ==> LI vers le haut = S1 en position 1, DS-G-H, DS-D-B ;
Une 28F256 Segment 0 ==> LI vers le haut (S1 en position 1), DS-D-B (DSW2 sur OFF), DS-G-B (DSW1 sur OFF) ;
Une 28F256 Segment 1 ==> LI vers le haut (S1 en position 1), DS-D-B (DSW2 sur OFF), DS-G-H (DSW1 sur ON) ;
Une 28F256 Segment 2 ==> LI vers le haut (S1 en position 1), DS-D-H (DSW2 sur ON), DS-G-B (DSW1 sur OFF) ;
Une 28F256 Segment 3 ==> LI vers le haut (S1 en position 1), DS-D-H (DSW2 sur ON), DS-G-H (DSW1 sur ON) ;

Dessus de l'adapteur pour remplacement MK36000 (ROM), 1 ZIF, 2 résistances, 2 DIP-Switches, 1 interrupteur double ON-ON".

Dessous de l'adapteur pour remplacement MK36000 (ROM), les diverses liaisons.

Adaptateur avec la ROM d'origine (MK36000 = D2364C).

Adapteur pour remplacement MK36000 (ROM) avec une UVPROM 2764

Adaptateur avec une UVPROM 2764.

Adaptateur avec une mémoire Flash M28F256.

Déclinaison de l'adaptateur avec une M27C512 : adapteur MK36000-D2364C/2764/M27C512

Cliquez sur le schéma et sa notice pour les visualiser confortablement.

Cliquez pour agrandir le schéma

Cliquez pour agrandir le résumé des connexions à réaliser et le mode d'emploi

Remplacement de l'alimentation du DAI par une alimentation du commerce

Avant le test sur le DAI, j'ai eu quelques difficultés à tester cette alimentation qui ne dispose d'aucune tension stable dès lors que la consommation est nulle ! Pour la tester il a fallu se procurer des résistances de puissance pour estimer la consommation minimum à fournir !
En clair :

Lorsqu'elle ne comporte aucune charge La sortie "-5V" atteint -4,1V quand les autres sorties sont stabilisées aux alentours de +12V et +5V avec plus ou moins de précision ;
Pour stabiliser la sortie +5V sans charge, il faut charger la sortie +12V au minimum à 140 mA ;
Pour stabiliser la sortie +12V sans charge, il faut charger la sortie +5V au minimum à 300 mA

Test avec le DAI

Maintenant que je sais que les sorties sont inférieures ou égales à ce qui est souhaité, je peux tenter le test en direct sur le DAI.La photo ci-dessous montre la réalisation rapide de 4 connecteurs pour brancher le câble réalisé plus haut et qui est déjà connecté au DAI.

Création de 4 bornes provisoires pour tester la nouvelle alimentation DAI.

Test de la nouvelles alimentation !

Le test est concluant, le DAI affiche les erreurs coutumières dues aux défaillances mémoires dont nous devrons nous occuper !
La mesure des tensions sur le DAI donne (tensions prises sur les RAMs 4116) : -5V pin 1, +4,9V pin 9, +12,1V pin 8. C'est très bon, ce qui me permet de dévoiler le visage de cette alimentation (néanmoins obsolète).

La nouvelle alimentation DAI.


*****************************

* Vendredi 29 novembre 2019 *

*****************************

Test de la mémoire sans dessoudage

Rappel des préparations précédentes :

Création d'un adpateur permettant de remplacer une des ROMs par de la mémoire FLASH ;
Spécifications du programme de test mémoire + écriture programme de test.

Pour générer un fichier ".bin" digéré par mon programmateur qui ne voulait savoir du ".hex" généré par le site "https://www.asm80.com/" j'ai du recompiler le programme C "hex2bin" dont le source est ici "https://sourceforge.net/projects/intelhex2bin/".

Résultat des tests

Le DAI de Michel a eu du mal à booter et se maintenir dans le programme de boot. Je ne rentrerai pas dans les détails des manipulations tortueuses effectuées pour le forcer à exécuter le code en C000 une fois le DAI sous tension. Au bout du compte, le DAI a exécuté le test 14 fois pendant 3h56' au total.
Le programme ne s'est jamais planté durant ces 4h.
Aucune mémoire 4116 n'a été prise en défaut !!! (avec cette première version du programme). .

Bilan de santé arrivé à cette étape

Sortie cassette réparée ;
Alimentation réparée ;
Test de la pile (2 x 2111) = OK ;
Test de la mémoire = OK ;
Machine n'arrive pas à booter correctement.

Prochains tests envisagés par ordre de priorité

Trouver un moyen de tester la quasi totalité des instructions du 8080.

A concevoir et implémenter.

Démarrage ROM 511, un peu de sorcellerie

Spécifications :

dans la M28F256 j’ai 3 segments remplis avec la ROM 511 (elle est en trois exemplaires, une dans le segment 1, une dans le segment 2, une dans le segment 3) et dans le segment 0 j’y mets le code du programme de test mémoire écrit par Michel.

Pour faire démarrer le programme de test mémoire, je fais les manipulation suivantes :

1) Couper le courant alors que les 2 DIP-Switches sont en bas ;
2) Allumer le courant alors que les 2 DIP-Switches sont toujours en bas ;
3) Compter jusque 3 ;
4) Positionner le DIP-Switch de droite en haut ;
5) Compter jusque 10 ;
6) Positionner le DIP-Switch de droite en bas.

Une fois cette manœuvre effectuée, je vois le programme de test mémoire qui démarre.

Si je mets le code de la 511 à la place de du programme de test mémoire, la même manipulation échoue !

Ne me demandez pas pourquoi car je n’en sais rien du tout. J’imagine que c’est parce que la ROM 511 sollicite beaucoup de CI et que l’un d’entre-eux dysfonctionne, mais peu importe, je dois rester concentré sur mon objectif initial…

Le programme de test ne démarre pas directement au boot, c’est pourquoi je fais cette manipulation qui le « force » à repartir en C000 mais un peu après l’allumage....

Je souhaite m’appuyer sur ce comportement curieux pour essayer de booter la ROM 511 « un peu plus tard après l’allumage ».

Le but du programme à réaliser est de me laisser le temps de manipuler les DIP-Switches afin de changer le segment qui sera à lancer en C000.

Voici ce que je prévois :

A) Je vais refaire la manipulation ci-dessus pour lancer le programme demandé.

B) Ce programme devra envoyer une dizaine de messages espacés de 4 secondes pour montrer qu’il est vivant.

C) Au dixième message de vie, il devra m'envoyer un « GO » et à partir de ce moment ce programme devra continuer à s'exécuter en dehors de la ROM pendant une trentaine de secondes puis faire un jump en C000. Pendant cette trentaine de seconde, je manipulerai les DIP-Swiches pour qu'au moment du jmp C000, le code exécuté soit celui de la ROM 511 ! C’est simple à faire, il faut copier dans la pile un morceau de code qui fait une boucle d’une trentaine de secondes puis qui se termine par un saut en C000.

Le test intitulé « RAM TIMING ».

C.F. manuel de service page 127/149.

Le test intitulé « BANK SWITCHING CHECK ».

C.F. manuel de service page 126/149.

Le test intitulé « BANK SWITCHING WITH SCOPE».

C.F. manuel de service page 126/149.

Le test intitulé « GENERAL TIMING CHECK ».

C.F. manuel de service page 127/149.

Le test intitulé « P.C. PICTURE ADRESS TEST ».

C.F. manuel de service page 127/149.

Tests complémentaires

Pages 137/149 à voir s’ils peuvent aussi être implémentés (Input port check) ; (Keyboard check) ; (8255 Test).

Autres programmes de test à prévoir

Programme qui initialise la mémoire vidéo pour la configurer en mode 0 comme celui qu’on à l’invite du BASIC ;
Programme qui teste la pile sans s’y appuyer.


***************************

* Samedi 30 novembre 2019 *

***************************

Suppression de l'ancienne alimentation du DAI

Surface à louer pour extension 14541 mm2.

Ancienne alimentation DAI :

Poids = 1214 g.
Dim = 142mm x 105mm = 14910 mm2

Nouvelle alimentation DAI :

Poids = 514 g (-660 g).
Dim = 97mm x 159mm = 15423 mm2 (+513 mm2).


*****************************

* Dimanche 01 décembre 2019 *

*****************************

Documentation des branchements effectués relativement à la nouvelle alimentation

Après pas mal de temps passé à rechercher des connecteurs, voici le branchement "officiel" réalisé.

J'ai décidé deux choses :

Ne pas diminuer la surface libérée par la dépose de l'ancienne alimentation afin de laisser le maximum de place possible pour de futures extensions. Par conséquent je n'ai soudé aucun bornier sur le dessus du PCB. J'ai soudé 4 fils et un connecteur femelle qui viendra se connecter dans un connecteur mâle côté alimentation.
Réutiliser le seul et unique fusible qui était présent sur le DAI. Il pourrait être utile de protéger également les autres alimentations, je laisserai le soin à MIchel de le faire le cas échéant en intercalant des fusibles ad'hoc sur les lignes d'alimentation (-5V et +12V).

Comme on le voit ci-dessous, j'ai réutilisé les trous de fixation de l'ancienne carcasse de l'alimentation pour maintenir les fils en place et éviter les contraintes mécaniques sur les soudures.

Le code couleur final mis en place est légèrement différent du premier que j'ai utilisé et ne dépend que de mon propre stock de fils.

VERT = -5V ;

JAUNE = 0V ;

ROUGE = +5V ;

BLEU = +12V ;

Comme on le verra dans le commentaire des prochaines photos, j'ai fait en sorte qu'il soit impossible de brancher à l'envers les connecteurs, sauf au moment du branchement sur le bornier de l'alimentation !

Connexions d'alimentation sous le PCB du DAI.

Connexions d'alimentation sur le dessus du PCB du DAI.

Prise mâle côté alimentation.

Connexion du DAI à l'alimentation.

DAI prêts pour un nouveau test.

Evidemment le DAI a été testé avec ce nouveau branchement et la dépose de l'alimentation, tout va bien je retrouve bien la panne de départ !

Mesures de consommation sur les 4 fils

Mesures de consommation sur les 4 fils.


*****************************

* Mercredi 04 décembre 2019 *

*****************************

Depuis le jeudi 21 novembre, la réparation de la carte vidéo était en suspens. J'ai décidé de m'y atteler aujourd'hui.

Etat de la carte avant l'intervention

Dessus de la carte RGB

Cette carte a été modifiée par le précédent propriétaire.

Vue globale du dessus du PCB :ce à quoi il ressemblait...

Cette carte a fait l'objet de pas moins de 12 interventions (changements, suppressions de composants) et par ailleurs la prise DIN était "bancale, le nez en l'air".

Je ne sais pas ce que le précédent propriétaire a voulu faire, ni si sa modification a un jour fonctionné, quoiqu'il en soit j'ai restauré la carte conformément au schéma de la révision 1 de la carte RGB.

En zoomant sur la photo ci-dessus, on peut s'apercevoir à proximité de la prise DIN que les 3 résistances 1/4W qui cohabitent avec 3 résistance 1/2W ne sont pas de la bonne valeur (180 ohms au lieu de 150 ohms).

En bas, à l'extrême gauche, il manque une résistance de 1 kilohms.

En bas, à l'extrême droite :

la première résistance fait 1 kilohms alors qu'elle devrait faire 10 kilohms ;
la deuxième résistance est infinie alors qu'elle devrait faire 1 kilohms ;
la quatrième résistance fait 180 ohms alors qu'elle devrait faire 100 ohms ;

A droite du 74LS374 (8 bascules D), il y a 2 résistances en série (120 ohms + 330 ohms) en lieu et place d'une simple résistance de 100 ohms.

Cliquez sur l'image ci-dessous, on voit mieux les détails ici :

Détails de quelques modifications sur le dessus de la carte RGB.

Dessous de la carte : plat de résistances

Comme on peut le voir, il y a eu de la bidouille à cet endroit. Une seule solution : démontage et retour à la normale.

Plat de résistances... Comment peut-on ?

En plus de ce fouillis, on voit la prise posée de travers.

Allez hop ! On démonte ce bazard

Début du retour aux sources, on démonte les fantaisies.

On voit sur la droite tout ce qui a été démonté. Je vais réutiliser 2 résistances et changer le reste par les bonnes valeurs.

Réparation de la carte vidéo

Redressage de la DIN ;
Ajout des résistances manquantes ;
Remplacement des résistances qui n'avaient pas la correcte valeur ;

Vue de dessus de la carte RGB réparée

Vue de dessus de la carte RGB réparée.

Vue de dessous de la carte RGB réparée

Vue de dessous de la carte RGB réparée.

Test de la nouvelle carte vidéo RGB avec son câble

J'ai fait le test avec le câble muni de la prise PERITEL dorée, le test mémoire effectué une fois de plus m'a permis de constater que j'ai exactement les mêmes résultats qu'avec ma carte et mon câble.

Mission réparation carte RGB terminée.

Je ne ferai rien sur l'autre câble vidéo, je conseille à Michel de le ranger en l'étiquetant "Attention ce câble n'a pas été testé avec la carte RGB réparée, ce câble était fourni avec le DAI en panne !"

Bilan de santé arrivé à cette étape

Sortie cassette réparée ;
Alimentation réparée ;
Test de la pile (2 x 2111) = OK ;
Test de la mémoire = OK ;
Machine n'arrive pas à booter correctement.
Câbles d'alimentation branchés sur le DAI
Prises d'alimentation avec détrompeurs réalisés
Nouveaux tests d'alimentation effectués et positifs
Analyse de la carte RGB défaillante
Démontage des composants suspects sur la carte RGB
Restauration de la carte RGB
Tests de la carte vidéo réparée + câble prise dorée Michel ==> OK


**************************

* Jeudi 05 décembre 2019 *

**************************

Test du circuit de reset

Lors de l'analyse des adresses présentées sur le BUS par le programme de test mémoire V0.5.1 écrit par Michel, voici ce que j'observais juste après le boot en C0.

Début du programme de test mémoire.

Important à savoir, pour cette analyse, j'ai pris une horloge externe constituée par le front descendant du signal SYNC.
Ce signal SYNC intervient (front montant) au milieu du state 1 de chaque instruction du 8080 et se termine (front descendant) au milieur du state 2 de chaque instruction.
Autrement dit, le signal est échantillonné au mieux tous les 3 cycles d'horloge = 1,5µs puisqu'une instruction dure à minima 3 cycles d'horloge.

Et pourtant que voyons-nous sur cette capture d'écran !!! Une instruction DI qui certes ne dure qu'un cycle machine mais prend 4 states c'est à dire 4 fois 500 ns = 2µs !!! Impossible donc de croire cet écran qui semble nous indiquer que le début de l'instruction suivante démarre 100 ns plus tard !

Le mystère est certainement du côté des développeurs de mon analyseur, car si j'ai demandé une horloge externe c'est précisément pour me caler sur une fréquence d'échantillonnage liée à cette horloge externe !!! Or, la configuration du logiciel m'impose de rentrer manuellement une fréquence (dont je ne comprends pas l'utilité).
Si je rentre 10 MHz (c'est le cas ici) le programme m'affichera 100 ns = 1/10 000 000 !
Si j'avais rentré 100 kHz, il m'aurait affiché 100 µs entre la présentation des adresses 0xC001 et 0xC002, ce qui aurait fait du 8080A, le processeur le plus lent de la planète !!!
Tout ceci est évidemment fait pour nous rendre de bonne humeur et pour nous inciter à abandonner cette synchronisation externe qui pourtant évite d'afficher des états intermédiaires dont nous n'avons rien à faire !

Je n'ai pas vu tout de suite ce problème car sur l'écran global il y a bien d'autres informations qui monopolisent notre attention.

En revanche ce que j'avais remarqué tout de suite et qui m'intriguait, c'était la présence de 0x005 après OxC004 et c'est ce dont nous allons discuter...

Pour expliquer ce que nous voyons, nous devont connaître le début du programme de test V0.5.1 :


DI					; interruptions désactivées

LXI		SP,0F900H	; initialisation du pointeur de pile en #F900

CALL	0C359H		; le port série RS232 est initialisé :

Voici comment interpréter les séquences d'adresse trouvées sur le bus au démarrage :

Adresse 0xC000 ==> Le 8080 récupère le code "0xF3" correspondant au code opération "DI"
Adresse 0xC001 ==> Le 8080 récupère le code "0x31" correspondant au code opération "LXI SP"
Adresse 0xC002 ==> Le 8080 récupère la donnée "0x00" correspondant aux poids faibles de l'adresse "0xF900"
Adresse 0xC003 ==> Le 8080 récupère la donnée "0xF9" correspondant aux poids forts de l'adresse "0xF900"
Adresse 0xC004 ==> Le 8080 récupère le code "0xCD" correspondant au code opération "CALL"
Adresses 0x005 et 0x006 ==> Le 8080 devrait présenter ici l'adresse 0xC005 et présente l'adresse 0x0005 !!!!

Voici ce que j'ai crû : étant donné que nous sommes juste après le reset de la machine et que nous n'avons pas encore fait le moindre saut (jmp) le processeur croit toujours être en début de mémoire... En effet, lorsque le 8080 est initialisé, il met systématiquement son compteur programme à zéro ! Et il présente bien l'adresse 0x0000 sur son bus d'adresse !
Si nous voyons s'afficher "OxC000" au début de la séquence d'initialisation, c'est qu'il y a un circuit servant à gruger le processeur, quand ce dernier demande C000, ce circuit grugeur construit deux nouveaux bits A14 et A15 qu'il positionne à 1 et qu'il présente sur le bus d'adresse... Le 8080 n'affiche pas directement ses adresses sur le bus d'adresse, mais passe par un buffer constitué de deux circuits 74LS241 dont la fonction est d'isoler et d'amplifier les signaux d'adresse générés par le 8080.

Isoler et amplifier oui ! Mais en plus il y a un circuit grugeur qui remplace A14 et A15 par deux bits à 1 !
Et combien de temps ça dure cette mascarade ?

En jetant un coup d'oeil rapide (trop rapide d'ailleurs) au circuit qui fait cela, je vois une résistance de 390 ohms et un condensateur de 470 pF qui se charge à partir du signal RESET (qui passe à l'état haut au moment du reset). Dès que le signal de RESET disparait, le processeur démarre et le condensateur se décharge. Un petit calcul rapide me montre que la constante de temps de ce circuit RC est de 183 ns et qu'il ne va pas rester longtemps chargé...
Or en regardant la copie d'écran ci-dessus, j'ai stupidement additionné les temps que me présentait le schéma, j'arrivais à 500 ns et je me suis dit qu'au bout de 183 ns le condensateur n'aurait plus que la moitié de sa charge, puis qu'au bout de 366 ns il n'aurait plus que 1/4 de sa charge et qu'enfin à 500 ns c'était sûr, il était complètement déchargé et que le circuit grugeur cesserait sa fonction...

Tant et si bien que j'ai demandé à Michel d'inclure tout de suite un jump en début du programme de test !
Le lendemain, quelque chose m'a poussé à analyser plus en détail la constitution du circuit grugeur et je me suis aperçu qu'il était bien mieux conçu que ce que j'avais imaginé avant ! En réalité un programme en ROM pourrait fonctionner pendant des heures avec ce circuit grugeur en fonction ! Comme nous allons le voir maintenant il ne suffit pas que ce circuit RC se décharge pour que le circuit grugeur s'arrête enfin de gruger ! (Et donc Michel n'avait pas besoin de mettre un jmp en début de son code).

Tout sur le circuit grugeur

Voici à quoi le schéma ressemble :

Comment le DAI démarre t-il en C000 ?

Faisons d'abord connaissance avec le circuit XOR qui joue un rôle très important

Le voici :

Circuit XOR ?

Ce circuit rend beaucoup de services en électronique !

Vous voyez deux entrées a et b et une sortie s. Un circuit XOR est un circuit "OU EXCLUSIF" (en français) !

C'est un circuit qui délivre un niveau 1 en sortie à la seule condition qu'une seule de ses entrées soit à 1 !

C'est le "OU" de la vie courante. Illustration : vous êtes dans une soirée et la maitresse de maison vous présente un plateau avec un éclair au chocolat et une religieuse... Vous demandez "que puis-je prendre ?" et la maitresse de maison vous répond "prenez l'éclair OU la religieuse".

Dans telle circonstance, si vous vous avisiez de prendre les deux à la fois, vous feriez certainement mauvais effet auprès des invités... On s'attend naturellement à ce que vous preniez soit la religieuse mais pas l'éclair, soit l'éclair mais pas la religieuse...

Vous voyez que le symbole ci-dessus correspond bien au "OU" de la vie courante...

Retenez donc ceci : "la sortie est à 1 si une seule des deux entrée est à 1".
Lorqu'on associe 1 à VRAI et 0 à Faux, on peut le retenir sous cette forme : "la sortie est vraie si une seule des deux entrée est vraie."
En électronique positive, on associe 0 à un niveau électrique bas et 1 à un niveau électrique haut. Par exemple 0V = 0 et 5V =1.

Table de vérite du circuit XOR


a=0 et b=0 ==> s=0

a=1 et b=0 ==> s=1

a=0 et b=1 ==> s=1

a=1 et b=1 ==> s=0

Utilisation intéressante du circuit XOR

Lorsque vous avez besoin d'un circuit "NOT" = "NON" = circuit qui inverse un niveau logique et que de plus vous avez besoin qu'il soit programmable, c'est à dire qu'il inverse un signal ou pas sur votre commande... Alors utilisez un circuit XOR, c'est parfait pour cela... Voici comment faire.

Un NOT programmable avec un XOR

Imaginons que le signal à inverser (ou pas) soit présent sur l'entrée a de votre circuit XOR.

1) Mettez un niveau 1 sur l'entrée b
==> si un 1 se présente sur l'entrée a ==> a=1 et b=1 ==> s=0
==> si un 0 se présente sur l'entrée a ==> a=0 et b=1 ==> s=1

==> Vous voyez que dans ce cas, la sortie s représente l'entrée a inversée !

2) Mettez un niveau 0 sur l'entrée b
==> si un 1 se présente sur l'entrée a ==> a=1 et b=0 ==> s=1
==> si un 0 se présente sur l'entrée a ==> a=0 et b=0 ==> s=0

==> Vous voyez que dans ce cas, la sortie s représente l'entrée a NON inversée !

Avec ce circuit élémentaire vous venez de réaliser un INVERSEUR PROGRAMMABLE via l'entrée b.

Fonctionnement du circuit grugeur

Vous voyez sur l'avant dernier schéma qu'il y a un circuit nommé IC107, c'est une bascule D (74LS74) son fontionnement est assez simple. La sortie Q (non représentée ici) recopie l'entrée D lorsque se présente un front montant sur l'entrée CK (dite entrée d'horloge).

Entre deux fronts montants sur CK, la sortie Q reste mémorisée (verrouillée).

Ceci n'est vrai que si l'entrée CLR (CLEAR = remise à zéro) est au niveau haut ET que l'entrée PR (PRESET) est également au niveau haut.

Pour l'entrée PR, tout va bien car elle est figée au +5V donc remplit la moitié de la condition si-dessus.
Pour l'entrée CLR, elle se trouve au niveau bas pendant environ 200 ns (cf les explications du chapitre précédent sur le circuit RC).

Lors de l'initialisation, l'entrée CLR passe au niveau bas du fait du niveau 1 (+5V) sur l'une des entrées du circuit XOR en haut du schéma et du fait du niveau 1 (condensateur chargé) qui dure environ 200 ns sur la deuxième entrée de ce XOR (si vous avez suivi 1 et 1 ça fait 0).

Une fois le condensateur déchargé, la sortie du XOR en haut du schéma passe à 1 et la sortie Q n'est plus maintenue à zéro, elle prendra la valeur de l'entrée D lors du prochain front montant sur CK.

Puisque l'intitialisation a pour effet de placer Q à 0, elle place la sortie NON Q = /Q que l'on voit sur ce schéma au niveau 1 !

Donc juste après l'initialisation, chacun des deux XOR en bas du schéma dispose d'une de ses deux entrées à 1 !
Si vous avez suivi l'explication du circuit NON programmable, vous voyez donc que les sorties notées A15' et A14' vont être les sorties inversées des entrées A15 et A14 venant du CPU (gauche du schéma) !

Tant qu'il n'y a aucun front montant qui arrive sur l'entrée CK de IC107, les sorties restent dans l'état où elles étaient, c'est à dire à 0 pour Q et 1 pour /Q et donc les sorties A14 et A15 sont inversées.

Vous commencez donc à comprendre que les entrées A14 et A15 sur la gauche sont les adresses A14 et A15 qui sortent directement de la puce 8080 et que les sorties A14' et A15' sur la droite sont les adresses "grugées" qui entrent et sortent du buffer de bus d'adresse (IC83) !

Mais alors quand ce circuit grugeur finira-t-i de gruger ? C'est simple au prochain front montant sur CK !

Et ce front montant arrivera dès qu'une opération au sein du processeur, positionnera le bit d'adresse A14 à 1. Par exemple un JMP en 0xC003 aura pour effet de faire passer à 1 le bit A15 qui est relié à l'entrée CK ! Ceci créera un front montant (passage de 0 à 1) sur l'entrée CK et comme l'entrée D est figée à 1 (+5V) la sortie Q passera à 1 et la sortie /Q à zéro !
De ce fait les circuits XOR qui reçoivent la sortie /Q n'inverseront plus les signaux et les adresses A14 et A15 ne seront plus inversées !

Voici donc pourquoi le 8080 démarre en C000 et comment cesse l'action du circuit grugeur ! Si ce dernier ne cessait pas de gruger via ce montage, alors le 8080 ne pourrait jamais aller se brancher sur aucune des adresses qui vont de 0 à 3FFF !

Mesure à l'oscillo du délai au delà duquel cesse le signal CLR sur IC107

CLR sur IC107

N'ayant pas ma clé USB sous la main, j'ai pris une photo un peu floue de l'écran. Il montre le signal CLR qui remonte au niveau haut 332ns après la fin du signal RESET sur le 8080. C'est tout à fait conforme à ce que j'avais calcule (environ 2 fois la constante de temps du circuit RC).
En bleu un signal RESET qui s'arrête et en jaune signal CLR sur IC107 qui remonte. Le temps est mesuré entre les deux curseurs verticaux jaunes.

Mesure à l'oscillo du délai au bout duquel le circuit grugeur cesse de fonctionner avec une ROM 511

Fin du grugeur avec ROM 511

On voit ici que le circuit grugeur cesse ses fonctions imperturbablement au bout de 6,04 µs après le démarrage du 8080. Ceci est évidemment dépendant de la ROM utiisée, ici c'etait une ROM 511 qui fait un jump dès le début. Pour rappel, un jump dure 5µs. Ce qui permet de conclure que le 8080 met 1,04µs avant de démarrer après la fin du RESET.


*********************************************************

* Vendredi 06 décembre 2019 au dimanche 8 décembre 2019 *

*********************************************************

Nombreux tests relatifs à la "PROM test"

Pour une raison qui était encore inconnue pendant ces 3 jours, la "PROM test" refusait de démarrer avec la technique habituelle décrite plus haut dans le chapitre "Démarrage ROM 511, un peu de sorcellerie". Et quant elle démarrait après bien des manipulations, elle se bloquait.

Quoi qu'il en soit ceci m'a conduit à multiplier les analyses yc à mettre à l'épreuve mon adaptateur M28F256/2764/MK36000. Ceci n'étant pas une mauvaise chose en-soi, cela a permis de le qualifier complètement !
La description de ces 3 jours de tests serait longue et sans grand intérêt, c'est donc tout ce que je tracerai pour ces 3 jours.


**************************

* Lundi 09 décembre 2019 *

**************************

En attendant la prochaine livraison du programme de test (par Michel), je peux toujours passer à la vérification des ROMs qui sont déjà sur support.

Les ROM du bios

Elles ont été testées dès le départ et j'ai visiblement oublié de le noter à la journée du mardi 19 novembre 2019 !!! La vérification a été faite grâce à un adaptateur que j'avais réalisé spécialement pour !
Voici à quoi ça ressemble ! On met la MK36000 dessus, on dit à son programmateur de PROM préféré que c'est une 2764 et qu'on ne veut pas qu'il essaye de contrôler si s'en est vraiment bien une, tout ce qu'on lui demande c'est de la relire comme si c'était une 2764... Non mais qui c'est qui commande ?

Pour relire MK36000 sur un programmateur.

On obtient un fichier binaire sur lequel on fait un calcul de checksum MD5 ou un SHA1 pour vérifier avec le tableau suivant que c'est bien un checksum connu :

MD5 SHA1 des ROMs.

Les ROMs de Michel sont OK et connues (enfin presque).

Relecture des TBP18S030N (ou 74S288) du DAI de Michel

Contrôle de la PROM bleue IC46

Ce coup-ci j'ai innové (ras le bol de construire des adaptateurs).

Relecture des TBP18S030N ou 74S288.

La PROM bleue étant une TBP18S030N = 74S288, j'ai réalisé avec un montage avec fils volants et la plus petite plaque d'expérimentation du monde ! (Vous la trouverez chez Lextronic).
On voit ici la PROM rouge car j'ai pris la photo après le chapitre suivant (la PROM rouge est aussi une TBP18S030N).

Si vous voulez savoir comment j'ai fait, voici un brouillon correct mais moche.

Relecture des TBP18S030N ou 74S288, le schéma..

Ne reliez pas les broches 1, 2, 3, 19, 20, 21,22 et 23, il faut laisser le programmateur faire son boulot, il s'attend à lire une 2716, il va donc lire 2 KiO alors qu'il n'y a que 32 octets dans la PROM. Qu'à cela ne tienne, il vous renverra 64 fois le contenu de la PROM et vous n'aurez qu'à vérifier les 32 premiers octets !

Que voici de 0x00 à 0x1F...


***********************************************

CB CB CF CF EB EB EF EF DA DA CA CA DE DE CE CE

FA FA EA EA FE FE EE EE 88 88 88 88 48 48 C9 C0 

***********************************************

C'est bien le contenu attendu (du moins c'est celui d'autres DAI qui fonctionnent), la PROM bleue est OK !

Il était important de vérifier cette "bleue" car c'est elle qui, entre autres, génère - grâce à ses sorties D7 et D8 - les signaux /LP = "NOT Lower PROM" et /UP = "NOT Upper PROM". Autrement dit, c'est avec ces deux signaux que l'on sélectionne soit le segment C000-DFFF des ROMs soit un des quatres segments de E000 à EFFF (en collaboration avec FD06<6> et FD06<7>)

Autrement dit, une "bleue KO" impliquerait la mauvaise sélection des ROMs.

Contrôle de la PROM rouge IC52

Tout a été expliqué pour la PROM bleue, il me reste juste à afficher le contenu relu :


***********************************************

12 12 12 12 1A 16 13 12 10 02 12 12 12 12 12 12 

12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12  

***********************************************

C'est bien le contenu attendu (du moins c'est celui d'autres DAI qui fonctionnent), la PROM rouge est OK !

Il était important de vérifier cette "rouge" car elle pilote les ports FD04, FD05 et FD06.

Le port FD06 pilote le switching des ROMs BIOS. Autrement dit, une "rouge" KO et c'est potentiellement 2/3 des ROM qui deviennent innaccessibles !

Autres adaptateurs pour contrôler ou remplacer les PROMs du DAI

Adaptateur 74S287 vers 2716 pour relire une PROM blanche par exemple

Adaptateur 74S287 vers 2716.

Adaptateur 2716 vers 74S287 pour remplacer une PROM blanche

J'ai osé le faire, ce n'était pas gagné du fait du temps d'accès des 2716 (bien plus long que celui des 74S287) mais ça a fonctionné.

Remplacer une PROM blanche par une 2716.


*****************************

* Mercredi 11 décembre 2019 *

*****************************

Où l'on reparle sérieusement de la mémoire !!!

Souvenez-vous, lors des tests de la journée du 29 novembre, le programme d'analyse de la mémoire nous indiquait que tout était OK !

J'étais passé à d'autres tests et j'avais demandé à Michel de bien vouloir inclure dans le programme de test, une fonctionnalité permettant de simuler le MODE 0 du DAI afin de vérifier que la partie vidéo était parfaitement saine...

Pour rappel, Michel ne disposant pas de DAI fonctionnel (et pour cause), il développe tout "en aveugle" et je teste !

Michel a donc développé une fonction qui me permet de copier un modèle d'écran dans la mémoire (de 0xB360 à 0xBFFF).
Après avoir confectionné un modèle d'écran permettant de repérer les octets correspondant aux caractères affichés, j'ai pu tester "la simulation du MODE 0".

Au cours de cette simulation, nous nous sommes aperçus que certains caractères affichés étaient différents du modèle, ce qui nous a donné l'occasion de remettre en cause le verdict apporté par le programme de test mémoire. En effet, comment expliquer par exemple qu'un 0 se transforme en "w" et seulement à certains endroits bien particuliers de l'écran... Ca sent bien les problèmes mémoire... Donc le programme aurait dû les trouver.

En effet il existait quelques erreurs qui ont été rapidement corrigées par Michel.

Et...La conclusion est... Qu'il existe plusieurs mémoires défaillantes ! Ce qui est une bonne nouvelle ! Cela peut expliquer le comportement erratique du DAI lorsqu'il s'aventurait en mémoire programme (cf les explications du dimanche 24 novembre).


********************************************

* Jeudi et vendredi 12 et 13 décembre 2019 *

********************************************

Le changement des mémoires

Après de multiples séquences de tests avec le programme de Michel, je peux enfin procéder à un remplacement intelligent sans avoir à dessouder l'ensemble des mémoires. En alliant preuves logicielles et contrôles à la sonde logique, le verdict est tombé. Néanmoins il n'est pas encore exhaustif : IC57, IC64, IC77, IC102 sont 4 mémoires DRAM 4116 présentant des anomalies de fonctionnement. L'une d'entre-elles (IC102) était d'ailleurs totalement hors-service.

Etant donné le verdict, j'ai d'abord pensé à innover en laissant les moignons des RAMs HS pour y souder des supports, ainsi j'étais sûr de n'occasionner aucun dommage au circuit imprimé. Mais après avoir coupé les pattes à l'un des CI, il m'est apparu encore plus facile de procéder au dessoudage des moignons, opération très simple à réaliser et n'occasionnant aucun dommage au circuit imprimé. C'est finalement ce que j'ai décidé de faire.

N'hésitez pas cliquer sur les photos pour voir les détails.

IC102 est HS... Quand on est certain qu'un circuit est hors-service, lui couper les pattes simplifie grandement le dessoudage.

Il reste des moignons, éventuellement j'aurais pu y souder des supports DIP...

IC102 dessoudage sur l'envers

Pour IC102 et les autres 4116, j'ai finalement fait à la manière traditionnelle : dessoudage complet.

Mea culpa, j'ai donné de mauvaises spécifications à Michle, cela s'est soldé par une mauvaise identification et IC56 a été déssoudée par erreur.

Mea culpa, j'ai donné de mauvaises spécifications à Michel, cela s'est soldé par une mauvaise identification et IC56 a été déssoudée par erreur.

La mémoire IC56 a été dessoudée par erreur, mais proprement.

Elle a été dessoudée par erreur, mais proprement.

Elle a gagné un support et c'est propre...

Support de IC56 soudé proprement.

IC57... C'était elle qui était HS... Voici donc un nouveau support DIP16 soudé pour IC57.

IC64 étant HS également : même traitement ! On peut voir sur la gauche IC56 et IC57 sur support. N'ayant pas encore reçu les 4116 de Michle j'ai gracieusement dépouillé mon DAI qui fait la g...

Petite astuce pour maintenir en place et souder.

Parmi ces 5 CI, il y en a 2 que j'ai dessoudés et remplacés par des supports DIP16, vous les voyez ?

Toujours la même méthode, on coupe les pattes, on dessoude les moignons, on nettoye proprement à la tresse à dessouder ou au ZD-915

IC77 comme les autres, dessoudage propre le circuit imprimé est comme neuf !

SMURF4

Le bloc opératoire pour IC56

Je n'ai pas eu le coeur d'envoyer au cimetière IC56 qui était encore parfaitement fonctionnelle. J'ai donc décidé de lui greffer 16 nouvelles pattes que j'ai récupérées sur une autre mémoire totalement HS. Voici 3 photos de cette intervention spéciale.

Après le réveil, je l'ai installée à la place qu'elle n'aurait jamais dû quitter et figurez vous qu'elle fonctionne encore à merveille malgré toutes ces tortures ! Quand un composant met autant de bonne volonté, il faut le garder.

Début de l'intervention chirurgicale, j'en suis déjà à la 3ème patte greffée... Tout un art !

IC56 en salle de réveil.

La puce IC56 marche de nouveau !

Et la suite ?

Il reste encore IC96 qui a été détectée comme HS grâce à un pattern vidéo MODE 0. Mais j'attends une prochaine révision du programme de test pour confirmation.

Enfin, il me reste à vous dire qu'une fois changé l'ensemble des DRAMs incriminées, plus aucune erreur n'a été détectée par le programme de test !

Par ailleurs, en regardant les divers écrans générés (involontairement) par le programme de test, plus aucun écran n'avait d'anomalie, tous étaient parfaitement homogènes et stables... Bref le DAI ne fait que s'améliorer, espérons que cela va continuer.


***************************

* Samedi 14 décembre 2019 *

***************************

Le motif "Ecran Mode0" ayant servi à détecter des erreurs non trouvées par le programme de test initial, a été recopié à divers endroits de la mémoire.

La pêche a été bonne. D'autres adresses sont sorties en erreur ce qui m'a permis de confirmer que IC96 est une 4116 défaillante et cela a surtout permis d'identifier une mémoire de plus en erreur : IC58 !!!

La c'est très intéressant, cela peut largement expliquer la sortie dans les décors dès que le DAI quitte le programme d'initialisation en ROM.

Prochaines étapes : changement de IC58 et IC96.


*****************************

* Dimanche 15 décembre 2019 *

*****************************

Relache !!! Aujourd'hui je fais ma playlist de Noël.


**************************

* Lundi 16 décembre 2019 *

**************************

Changement de la mémoire IC58

Dessoudage classique de IC58, je veux garder cette 4116 défaillante pour mettre au point un protocole de test de mémoires.

Dessoudage classique de IC58, je veux garder cette 4116 défaillante pour mettre au point un protocole de test des mémoires 4116.

IC58 sous le PCB...

Soudage d'un nouveau support pour la remplaçant de IC58.

Soudage d'un nouveau support pour la remplaçante de IC58.

Le remplacement de IC58 a permis un grand progrès !

La fin du dépannage approche !

Comme on peut le voir ci-dessus, le remplacement de IC58 a fait un bien fou à ce DAI qui cumulait les pannes !
On arrive désormais jusqu'au prompt... On voit un affichage sympathique, mais c'est normal IC96 n'a pas encore été remplacée.

Changement de la mémoire IC96

Dessoudage classique de IC96, je veux également garder cette 4116 défaillante pour mettre au point un protocole de test de mémoires.

Dessoudage classique de IC96, je veux également garder cette 4116 défaillante pour mettre au point un protocole de test des 4116.

Et un support de plus en place pour la mémoire (IC96)

Ecran de démarrage parfait.

Et voici le prompt du BASIC V1.1 dans toute sa splendeur !

Le DAI de Michel Meyer est de nouveau vivant, il est capable d'exécuter un programme.

Il est temps de faire des tests plus complets pour trouver le reste des pannes !

Mon modèle d'écran Mode 0 est rendu de manière impeccable.

Il reste des erreurs !!! Le programme de Pascal Janin me sert de test. Regardez les écritures en bas d'écran.

Ces points en haut de l'écran ne devraient pas être là.

On charge le programme de Michel : PACMAN. C'est le chargeur de DAINAMIC qui va mettre en mémoire le reste du programme.

Le premier démarrage n'est pas concluant...

Cela commence à ressembler à ce que connaissais, mais nous sommes loin du compte...

Cela commence à ressembler à ce que je connaissais, mais nous sommes loin du compte...

C'est pas ça...

On reconnait le nom de l'auteur.

En ce qui concerne PACMAN, c'est tout ce que l'on pourra voir pour aujourd'hui.

Comme on peut le voir ci-dessus, le DAI continue à progresser vers la guérison, et pas qu'un peu !

Ce que vous ne voyez pas sur ces images mais que j'ai testé aujourd'hui, c'est que le DAI de Michel Meyer est maintenant capable de piloter un MEMOCOM, donc le X-Bus est parfaitement fonctionnel, de même que le DCE-BUS.

Il arrive parfaitement à relire les mini-cassettes DCR et à exécuter les programmes qui s'y trouvent... Avec plus ou moins de bonheur en fonction de l'utilisation de la mémoire graphique.

Le générateur de son fonctionne parfaitement, j'ai envoyé le morceau de musique "RAGTIME" à Michel en guise de preuve !

La preuve de la réparation de l'interface cassette a été faite, j'ai pu écrire un programme via l'interface cassette en sortie et j'ai pu le relire via l'interface cassette en entrée.

Détection du reste des problèmes mémoire

Ecran en mode 2. J'utilise ce petit programme qui constuit les mêmes courbes en mode 2, 4 ou 6. Ici c'est le mode 2 et l'écran est parfaitement normal

Ici c'est la version Mode 4. Ce sont les mêmes courbes avec simplement une meilleure définition.

Détail de construction de l'écran en mode 6

Voici l'écran en mode 6 alors qu'il est en cours de réalisation. Il est anormal ! D'abord nous devrions observer deux diagonales et nous voyons deux lignes brisées. Nous voyons aussi des traits et des points verts sur un fond jaune, ceci n'a rien à faire ici ! IL RESTE DES MEMOIRES DEFAILLANTES DANS LA PARTIE GRAPHIQUE !

Détail de construction de l'écran en mode 6, l'écran est presque réalisé et l'on voit bien les deux lignes brisées en lieu et place des diagonales.

Le même en rose, là il est totalement réalisé et l'on voit encore la ligne brisée ainsi que le motif méconnaissable.

Malheureusement, il reste encore du boulot ! Oui, il reste des mémoires défaillantes à débusquer.

Le DAI est à 99,9% fonctionnel, mais il ne fait pas bon utiliser le mode 6 pour le moment.

Un test encore plus simple consistant uniquement à passer en mode 6 juste après le démarrage, montre des points orange dont certains clignotent.

Suite au prochain numéro. Il faut continuer à améliore le programme de test mémoire.


**************************

* Mardi 17 décembre 2019 *

**************************

Tous les moyens sont bons pour traquer la DRAM défaillante

Souvenez-vous, hier tout allait de travers en mode6 et en mode5, les diagonales étaient presqu'autant brisées que le moral de Michel ! Et les RAMs capricieuses commençaient aussi à me fatiguer...

Cette journée a été passée à tendre des pièges dans tous les sens, commençons par le début en regardant les deux photos pas très nettes ci-dessous :

L'écran était légèrement parsemé de pixels "pas noirs" lors du passage en mode6. Lorsque l'on passe directment en mode6 après un démarrage à froid l'écran devrait être totalement noir.Or vous constatez qu'il y a de "fins" points roses vers le bas de l'écran et de gros points roses vers le haut de l'écran. Pour le point blanc lisez l'explication sous ces images.

Et ici vous constatez que le gros point rose en haut à gauche est devenu tout blanc ! Lisez l'explication ci-dessous.

Sur la photo de gauche j'ai moi-même placé le point blanc en procédant par dichotomie avec l'instruction DOT du BASIC, mon idée était de me rapprocher au maximum de ce point pour l'identifier.

Sur la photo de droite ci-dessus, j'ai simplement mis mon point blanc une ligne plus haut pour atteindre la zone touchée par le défaut. Et là surprise !!! La zone est passée entièrement blanche alors que visiblement cette zone est faite de plusieurs points verticaux !!! J'aurais normalement dû faire plusieurs instructions DOT pour arriver à ce résultat !

Ce comportement m'a immédiatement fait comprendre que la zone épaisse et rose que je voyais avant était bel et bien un unique point sur une unique ligne et si on voit ce point et celui de droite épais, c'est que le circuit vidéo réalise plus de 2 scans (balayage horizontal du faisceau d'électrons) pour cette même ligne ==> ceci ne peut arriver que si l'octet de "MODE" présent en début de cette ligne est dans un état anormal !!!

Le contrôle des octets de MODE

Après ce constat, j'ai donc écrit un petit programme BASIC (maintenant tout fonctionne bien sur le DAI à part ce gros défaut sur les modes 5 et 6) récupérant tous les octets de MODE espacés de 90 octets entre #BFEF et #6649 dans un tableau à 256 positions (pour ne pas perturber l'affichage) tableau que j'ai ensuite affiché en mode 0.

Résultats : tous les octets étaient à 32 sauf deux qui étaient à 36.

36 signifie donc que les 4 bits de droite ont la valeur 2 ce qui implique 6 lignes de scan à la place de 2 lignes de scan pour une seule ligne de points. Ceci explique très bien ce que l'on voit à l'écran, une ligne avec 4 lignes de scan en trop.

Comme sur cet écran en mode 6 il y avait 2 octets ayant la valeur 36, cela signifiait donc que mon écran avait 8 lignes de SCAN en trop et que donc le DAI ne pouvait afficher la totalité des informations prévues au bon endroit.

Ce décalage impliquait qu'en mode 6A, une partie des caractères de la zone de texte de 4 lignes devait s'afficher en début d'écran graphique et les erreurs que l'on voyait était en effet le reflet des caractères présents dans la zone textuelle. Il suffisait d'écrire dans la zone de texte pour voir évoluer les points roses dans la partie graphique.

Par ailleurs le clignotement du curseur avait pour effet de faire clignoter deux des points roses sur l'écran !

Avant de comprendre tout ceci il m'a fallu un bon moment de réflexion et revenir aux sources du fonctionnement vidéo du DAI !!!


********************************************************

* Mercredi 18 décembre 2019 jour de la victoire finale *

********************************************************

Les suspects étant repérés il restait donc à les confondre

Puisque les octets de MODE en #A5EB et #7FF3 comportaient une mauvaise valeur, il me suffisait d'écrire un programme qui lise et relise des valeurs différentes à ces adresses...

Que nenni ! Impossible de mettre en défaut ces deux adresses aussi simplement, seul le passage en MODE6 avait pour effet de remettre l'erreur "36" à ces deux adresses !!!

Et oui ! Ces erreurs n'apparaissent que dans des configurations particulières de mémoire 4116. Comprendre ici que le seul et unique bit en sortie d'une mémoire 4116 peut être bon ou mauvais en fonction des bits qui l'entourent ! Par exemple il se pourrait que le bit à l'adresse mémoire #A5EB se comporte bien si le bit présent à l'adresse #A56B est à 1 et le bit présent à l'adresse #A66B est à 1 et qu'elle se comporte mal si l'une des deux autres adresses comporte un 0 !!!

Ceci complique beaucoup les protocoles de test !

Et lors de la réparation de ce DAI, nous avons pu constater avec Michel et à plusieurs reprises, qu'il fallait parfois user de motifs très particuliers pour détecter les bits en erreur !!! Ecrire des 1 ou des 0 partout puis les relire pour prouver le fonctionnement est très très très loin de la vérité ! Disons simplement qu'un aussi simple programme de test peut débusquer des erreurs mais qu'il a aussi toutes les chances de passer à côté de beaucoup d'autres !

Alors quoi ??? Que faire ?

Avec les deux adresses qui étaient visiblement en défaut mais qui ne se laissaient jamais mettre en défaut (sinon lors du passage en mode 6 ou 5), j'ai pu identifier que le circuit concerné était IC63, mais j'étais loins d'être totalement convaincu !

J'avais en effet d'autres explications plausibles, par exemple peut-être que l'algorithme de passage en MODE6 prenait parfois une mauvaise décision du fait d'une autre RAM en erreur qui aurait comme effet de le conduire à écrire 36 en lieu et place de 32 dans certains cas !!! C'est parfairement possible !

Comme je n'avais aucune autre erreur à me mettre sous le fer à dessouder, j'ai finalement décidé de mettre en garde à vue le suspect... Ca ne fait pas encore 48h qu'il est enfermé dans une petite boite d'allumette...

Remplacement de IC63 : la victoire finale

IC63 : une garde à vue qui va se transformer en prison ferme.

Oh les belles courbes de Lissajous en mode6.

IC63 cesse de nous les briser. Les diagonales sont rectilignes.

La courbe est normale !!!

Victoire !!! Un test de PACMAN pour son auteur Michel Meyer

IC63 ne sera pas remise en liberté avant un loooong moment !

La ligne ci-dessus date de décembre 2019, nous sommes maintenant en 2023. IC63 vient de bénéficier d'une liberté conditionnelle : elle a été envoyée à VincentS pour qu'il puisse tester son testeur de DRAMs ! Je savais bien que j'avais raison de garder des composants défectueux, il peuvent servir pour tester les testeurs ! S'étant révélée défectueuse sur son appareil, j'ai acheté le même que VincentS qui m'a donc renvoyé IC63 pour une nouvelle opération de vérification... Cette pauvre DRAM aura été jugée 3 fois défaillantes et retournera donc dans sa petite boîte.