vendredi 23 octobre 2026

MG80: Préparation des tests

La réparation du codeur morse MG80 n'a guère avancée hors la réalisation de deux connecteurs pour un raccordement direct de la carte CPU. Je me suis posé la question de confier l'analyse de la conduite à tenir pour optimiser les tests au moteur 'Claude' couplé à Ghidra.

J'ai ainsi modifié l'approche en partant sur un contexte totalement décrit avec, dés le départ, la fourniture de toutes les informations disponibles dont des pointeurs vers les sites 'Cryptomuseum' et 'Robotron' ainsi que des fichiers au format 'pdf' et 'png' par ailleurs récupérés.

Deux demandes spécifiques ont été formulées consistant 1- à déterminer pourquoi mon équipement ne fonctionne pas et 2- à me fournir un code minimal pour une 2716 permettant de tester la carte seule avec un oscilloscope.  

Le résultat est ici encore impressionnant: non seulement l'analyse du fonctionnement du code est parfaite mais les documents ont été ingérés - les schémas en particulier - pour confirmer deux points: 1- l'utilisation des tensions de -5V et -12V n'est requise que pour les EPROM 2708 et 2- même si le code contient les fonctions de décodage morse, la carte d'entrée/sortie ne provisionne pas l'entrée audio requise.

Cerise sur le gâteau, un passage du manuel de dépannage en Allemand, est mis en exergue au regard de mon problème: l'alimentation SG81 n'intègre pas la tension de pilotage du réchauffage du boitier, un strap est donc requis sans lequel l'unité ne démarrera pas tant qu'une température de consigne n'est pas atteinte...

Ajoutons à cela l'écriture d'un code de test tenant dans la première page (1ko) de l'EPROM, code optimisé pour ne pas utiliser la RAM tant que celle-ci n'a pas été vérifiée. Les informations d'état sont transmises sur une sortie série à 9600bauds. Le fonctionnement de ce code a été testé par le moteur Claude dans un émulateur Z80 qu'il a codé pour cela. Le dossier du projet contient tout ce qui est attendu: code assembleur, binaire compilé, compilateur et émulateur python, données de test ...

Ci-dessous, un extrait de la documentation telle que fournie en format 'md'.


K2521TEST: standalone test ROM for the MG80 CPU board (K2521 / ZRE)

This ROM tests the CPU board on its own: CPU, data and address bus, the 8 × U202 RAM chips (reported per data bit), all four CTC channels, IM2 interrupts and the PIO outputs. Results appear as scope signals and as a readable serial report.

It was verified in a cycle-exact U880/CTC/PIO emulator, with injected faults (see the last section).

1. What you need

  • The K2521 board alone, out of the MG80.
  • +5 V only.
  • One single-supply 2716 (Intel 2716, U2716C, К573РФ2; not a TMS2716) programmed with K2521TEST_2716.bin, in socket ADR 0000.
    • This image holds the 1 KB program twice. The 2716's A10 (socket pin 19, which is +12 V VDD on a 2708) then makes no difference.
    • K2521TEST_1K.bin is the plain 1 KB image.
  • On a 2708-type socket, the 2716 also needs:
    • pin 21 (VPP) at +5 V. Strap the 5N rail (X1:A15/C15) to +5 V on the bench, or isolate the pin.
    • pin 19 never at +12 V.
  • Sockets 0400 / 0800: leave them empty, or fit 2716 copies of the MG80 ROM2/ROM3 (fitted the same way). The test identifies them.
  • An oscilloscope. A UART decoder or a USB-TTL serial adapter (9600 8N1) is useful but not essential.
CheckValue
K2521TEST_2716.bin CRC3202541AC7
K2521TEST_1K.bin CRC328BB943B1

2. Power pins (X1, system bus)

...




Un rapport complet sur l'analyse a été généré par "Claude" au format 'pdf' puis à ma demande dans un format 'html' compatible avec Blogger. Que dire de plus sur l'efficacité de cette approche et sur le gain de temps associé.

Une remarque cependant, le moteur 'Claude' répondra aux questions posées (les prompts) en recherchant si besoin des informations complémentaires (datasheets, schémas, ...) mais sans forcément vérifier la fiabilité de cette information. L'approche la plus efficace reste encore de préparer un dossier technique contenant toutes les données utiles quelque soit leur format puis à réorienter régulièrement la stratégie d'analyse. Ceci suppose (encore et heureusement) une bonne connaissance du domaine (ici assez vaste) devant être traiter.

A noter: j'ai pu conduire les deux analyses (MG80 et ETM1810) sur les crédits hebdomadaires de l'abonnement 'Claude Pro' avec encore 10% de marge. La première approche a coûté assez cher du fait de la fourniture au fur et à mesure d'informations qui, si elles avaient été fournies dés le départ,  auraient pu éviter de revenir corriger une analyse.


Summary

The MG80 firmware is intact. The most likely cause of a completely dead unit is the heating control holding the CPU in reset.

  • Firmware: the 3 KB image rom123.bin was fully disassembled and run in a cycle-exact emulator. Every function works: keyboard, Morse and telex transmit, the eight message memories, training and the receive modes. It is not the cause of the fault.
  • Prime suspect: the 0 °C thermistor R702 on the backplane, or its wiring. If it is open, the heating control keeps /RESET low for ever. The panel then stays in the reset pattern: BA and GT lit, plus one LED in each row. The repair manual itself allows bridging R702.
  • Other causes produce distinct symptoms (see Fault analysis). A RAM or ROM fault shows only as "no LED walk", because this firmware revision has no self-test.
  • Test the CPU board on its own first. A purpose-written test ROM, K2521TEST, needs one 2716 EPROM, +5 V and a scope. It reports the state of each RAM chip, the EPROMs, the CTC, interrupts and the PIO.

First actions: measure /RESET at X501/AC13 after power-on, and run K2521TEST on the bare CPU board.

Scope and method

The analysis set out to explain why an RFT MG80 Morse/telex keyer does not work at all. It combined the firmware with the original documentation and a simulation of the CPU board.

Step What was done
Disassembly rom123.bin (MD5 c4a5507776bc5d3f43248d7c128e8c93) disassembled in Ghidra. All 50 functions and 60 labels named and commented
Emulation A cycle-exact U880 (Z80) emulator with CTC and PIO models runs the real ROM, with the keyboard and outputs simulated
Fault injection Dead RAM chips, blank EPROMs, broken CTC channels, missing interrupts and reset faults were injected, and the symptoms recorded
Documents K2521 board description, MG 80 circuit documents (Schaltungsunterlagen) and the 1984 repair manual (Reparaturanleitung)
Test tooling A standalone diagnostic ROM for the CPU board, verified against the same injected faults

Not covered: the audio and relay boards beyond the interface schematic, and the physical position of each key.

The equipment

The MG80 is built around a Robotron K2521 (ZRE) CPU board running at 2.4576 MHz. All other boards hang off its PIO and CTC.

Board Role
ZRE K2521 U880 CPU, 3 × U555 EPROM (1 KB each), 8 × U202 RAM (1K × 1, one chip per data bit), CTC U857, PIO U855
Keyboard 62 keys in an 8 × 8 matrix; column latch on port 10h, rows on PIO-B
Display BA (mode) and GT (speed) LED rows, SP LED; tone and level controls
Interface Tone generator, Morse keying, double-current output, electronic contact, telex current loops; driven only by PA7 (Morse) and PA6 (telex)
Heating control Temperature sensing and heater relays; also drives /RESET
Backplane Carries NTC R702 and the CTC2 → CTC0 wire link (X2:A23 → C25)
Address / port Device Use
0000–03FF ROM1 Reset, vectors, character tables, Morse/telex bit routines
0400–07FF ROM2 Keyboard and command handling, CTC interrupts, transmit
0800–0BFF ROM3 Random groups, speed and baud, memories, training
0C00–0FFF RAM Messages, buffers, variables, stack
80–83 CTC Morse clock, telex clock, 2133 Hz timebase, key debounce
84–87 PIO A: LEDs and outputs; B: keyboard rows
10 Latch Keyboard column select

Firmware findings

The firmware is complete and runs every feature correctly in the emulator. It is a later revision than the one the 1984 repair manual describes.

Architecture. After start-up the CPU only executes EI / HALT; all work happens in Z80 mode 2 interrupts. The keyboard uses PIO-B, then CTC3 for a 17.4 ms debounce. Morse timing uses CTC0, clocked from CTC2's 2133 Hz output through the backplane link. Telex timing uses CTC1.

Start-up seen on the panel:

  1. Reset: BA, GT and one LED in each row, for under 1 s.
  2. LED walk: both rows step through 0, 1, 3–7 at 200 ms per step, about 1.4 s.
  3. Ready: BA5 and GT4 lit, within 3 s.
  4. If a key is held at power-up, the teleprinter prints ENDE / TASTE:x.

Features confirmed: Morse at 10–99 groups per minute, telex at 45.45–300 Bd, eight 128-byte message memories, a 16-character type-ahead buffer with SP LED warning, random training groups with an automatic check of the copy.

Revision difference. The repair manual describes a power-on self-test that reports RAM, EPROM and CTC errors as blink codes. This ROM has no such test. A memory fault therefore shows only as a missing LED walk, which is why a separate test ROM was written.

Receiving Morse. The firmware can decode Morse at 10–80 groups per minute without a speed setting, but only from an audio tone on PA4. On the MG 80 nothing drives PA4 or PA6 as inputs, so receiving needs the MG-80M hardware.

Fault analysis

Each failing part gives its own symptom, so the front panel narrows the fault before any probing.

Heating control and reset. Besides the K2521's own 300 ms power-on reset, open-collector gate G13 (D504) on the heating control pulls /RESET low at X501/AC13.

  • The 0 °C sensor T0 is NTC R702 (TNK-A10/100/10) on the backplane, pulled up by R506 (820 Ω). When warm, it pulls T0 low.
  • Latch G13/G14 with R505/C502 (10 kΩ / 470 µF) sets at power-on and releases /RESET once T0 goes low.
  • If R702, its wiring or connector X806 is open, T0 stays high and the CPU never starts. The same happens below 0 °C with an SV 81 supply, which provides no heater voltage.
  • Faults in D504, C502 or R512 have the same effect.

Symptoms and causes (from emulator fault injection, checked against the schematics and repair manual):

Symptom Likely cause Check
Stuck in reset pattern (BA + GT + one LED per row) /RESET held low: R702 or wiring open, D504, C502, R512 X501/AC13 must go high; T0 (X501/AC3) low when warm; bridge R702
No LEDs at all Power supply, E/A key, display cable X602 voltages; bridge X201/AC12–AC13
No LED walk, not in reset pattern Clock, ROM1, any single U202, PIO-A, /WAIT or /BUSRQ low 2133 Hz on X2:A23; run K2521TEST
LED walk repeats NMI pulses or supply dips /NMI (X1:A23) high; +5 V under load
Walk OK, keys do nothing ROM2 or ROM3, CTC3, PIO-B interrupts, jumper X14/X15, X12/X13 fitted K2521TEST INT line; keyboard test points
No Morse, telex OK CTC2/CTC0 or the A23 → C25 link 2133 Hz on both A23 and C25
No telex, Morse OK CTC1 Pulses on X2:A24
BA5 sends nothing, BA1 and BA4 work One CTC channel stalls the shared loader Test BA1 and BA4 separately
PA6/PA7 toggle, no output Interface board Hand-key test on X606
BA LED blinks at 5 Hz Over-temperature or T60 sensor fault X501/AC11

Tools produced

The analysis produced a CPU-board test ROM plus reusable files for further repair work.

K2521TEST ROM. A 1 KB diagnostic for socket ADR 0000, programmed into a single 2716 and run on the bare CPU board with +5 V only. It uses no RAM until the RAM has passed, so a dead U202 is reported instead of crashing the test. A healthy board prints this every 1.7 s on PA7 (X2:C13) at 9600 Bd 8N1:

K2521 TEST V1
ROM 0000 D91C OK
ROM 0400 C15D MG80
ROM 0800 DA05 MG80
RAM BITS 00 OK
CTC0123 PPPP
INT 0A OK
PB=FF OK
  • RAM BITS: each set bit names the faulty U202 (08 = the D3 chip).
  • CTC0123: P or F for each channel.
  • INT: interrupts counted in 100 ms; 00 means none reach the CPU.
  • PB0–PB7 show the same results as DC levels (high = pass), and PA0–PA6 output square waves from 25.6 kHz to 400 Hz.

In the emulator, it correctly reported each injected fault: a dead U202, missing RAM, a stuck address line, empty or wrong EPROMs, a dead CTC channel, no interrupts and NMI pulses.

File Content
K2521TEST.zip Test ROM image (2716 CRC32 02541AC7), source, assembler, emulator tests, guide
MG80_apply_all.py Ghidra script applying all names, labels and comments
MG80_annotated_full.asm Full symbolic listing that rebuilds the ROM byte for byte
MG80_simulator.zip Python emulator of the MG80 with behaviour and fault tests
MG80_2716_images.zip The three MG80 ROMs as 2716 images
MG80_firmware_analysis.md Detailed technical reference behind this report

Recommended procedure

Test the CPU board alone first, then let the front panel at power-on decide where to probe in the complete unit.

Power-on diagnosis: the front panel at power-on decides where to probe first

  1. Bench-test the CPU board with K2521TEST: +5 V only, test 2716 in socket ADR 0000. Look for 2133 Hz on X2:A23, then read the serial report on X2:C13.
  2. Read your unit's three EPROMs and compare them with the checksums in the appendix.
  3. Refit the board, power on after at least 10 s off, so C502 has discharged. Watch the panel for 3 s and follow the matching branch of the diagram.
  4. If the unit starts, check the outputs: PA7 (X2:C13) in BA4 and PA6 (X2:A13) in BA1 while typing. Then do the hand-key test on X606 for the interface board.
  5. For indoor use or an SV 81 supply, leave R702 bridged; the manufacturer uses this to block the heating control.

Appendix: EPROMs and sources

Compare your unit's three EPROMs against these checksums. A mismatch means a different revision or a corrupted chip.

Socket Range First bytes Sum16 CRC32
ROM1 / ADR 0000 0000–03FF ED 5E 21 00 10 7CDF 02E431DA
ROM2 / ADR 0400 0400–07FF 3E A7 D3 83 D3 C15D 5CA67DAE
ROM3 / ADR 0800 0800–0BFF D9 01 00 05 51 DA05 553C6D93

Replacing a U555 (2708) with a 2716. Use a single-supply 2716 (Intel 2716, U2716C, К573РФ2), not a TMS2716. Program the doubled 2 KB images so the 2716's A10 line doesn't matter.

Pin 2708 2716 Rule
18 PROGRAM (0 V) /CE Fine as is
19 +12 V A10 Must never see +12 V
20 /CS /OE Fine as is
21 −5 V VPP Must be +5 V

In the complete MG80 the supply puts +12 V and −5 V on pins 19 and 21, so those pins must be isolated with an adapter or bent-out pins.

Sources: Crypto Museum MG-80 · K2521 board description · MG 80 Schaltungsunterlagen · MG 80 Reparaturanleitung (Feb 1984) · cpushack U555C · retrocmp 2708

Report dated 23 October 2026.

mardi 20 octobre 2026

ETM1810: Couplage Ghidra/Claude à des fins de test

Réflexion personnelle d'il y a encore quelques jours: Oh jamais je n'utiliserai d'outils de raisonnement (cf. IA) car je suis encore capable d'étudier un code par moi-même. 

Certes. Mais à quel coût et pour quel investissement en temps, s'agissant d'une passion purement personnelle et qui ne me rapporte absolument rien. Cet investissement en temps impactant de plus en plus mes autres projets, je me suis finalement décidé à installer Claude Code pour le coupler à Ghidra mon outil de reverse via le GhidraMCP de LaurieWired (le plus simple). Puis, face aux résultats, à acquérir une licence Pro. Quelle honte mais quel gain de temps...

L'environnement de test est celui du firmware du modem ETM1810/M/A pour lequel je n'ai aucune documentation et dont je souhaite sauvegarder tout le code y compris celui stocké en Flash. J'ai donc simplement soumis le désassemblage effectué sous Ghidra à l'interface Claude en lui demandant d'analyser celui-ci. Ceci, je le précise bien, à des fins de test et de compréhension de l'architecture logicielle d'un matériel désormais obsolète et non maintenu.

Le résultat est réellement impressionnant.

Exemple d'une conversation où Claude détermine une fréquence de 1800Hz et infère que celle-ci est celle d'une porteuse puis mentionne le standard Stanag 4285.

Ici, Claude se propose d'écrire un désassembleur pour le TMS320C3x. Celui-ci est généré en python en quelques minutes et ne nécessite qu'une demande modification pour correctement construire les chaînes RCS présentes dans le code.

Ici encore, Claude infère un mode de fonctionnement, avec une réponse en Français à la suite d'une question posée en Français...


Ce premier test confirme l'intérêt de ce couplage s'agissant de codes anciens et complexes, difficiles à analyser avec les moyens traditionnels. Le raisonnement et les hypothèses sont identiques à celles que je fais habituellement mais avec une capacité d'analyse infiniment plus rapide et un retour arrière pour réajustement très performant.

Un guidage est nécessaire dans certains cas rares. Ici, je n'ai fourni que très peu d'informations au départ mais avec une précision croissante au fur et à mesure de l'analyse avec notamment l'identification et le datasheet des composants utilisés: ADC/DAC, DSP, UART externe, existence de cinq boutons poussoir. Cette absence d'information initiale sur le contexte a probablement fortement complexifié le processus d'analyse mais permettait un test bien plus représentatif. 

Le système a ainsi été capable de déterminer l'usage de l'équipement sur la seule analyse des informations RCS présentes dans les sections de code des DSP inclues dans le firmware. Un raisonnement identique à celui d'un analyste.

La vérification des hypothèses est extraordinaire, facilitée par l'accès à de multiples outils et la capacité de générer du code à la volée. Impressionnant d'efficacité pour confirme le rôle des routines embarquées dans les DSP. L'outil a été capable de vérifier qu'une partie du code effectue un traitement conforme à une recommandation Stanag qu'il a pu télécharger et étudier.

Je poursuivrai les tests sur d'autres configurations d'analyse dont celle du code du RFT MG80 que je n'arrive pas à redémarrer...

A ce niveau d'avancement, la conclusion est claire: le gain de temps est absolument phénoménal..

dimanche 18 octobre 2026

Divers: Chambre à ionisation Babyline31A

Une nouvelle chambre d'ionisation, une Babyline 31A, dans son coffret vient s'ajouter aux modèles 61A et 31 déjà dans la collection. Après tests celle-ci fonctionne parfaitement.

 

La Babyline 61A fonctionne de manière assez aléatoire avec une importante variation dans l'affichage quelque-soit la gamme, ceci après avoir parfaitement opéré pendant quelques jours. Il va me falloir y jeter un œil pour vérifier les tensions générées et l'état des condensateurs proche de l'ampli-opérationnel. La Babyline 31 - bien plus ancienne - va elle aussi nécessiter un travail de remise en état. Tous ces modèles utilisent la conception à base d'un double FET en entrée suivi d'un AOP 741.