Archiv der Kategorie: Allgemeines & Neues

Hier poste ich alles, das keiner speziellen Kategorie entspricht

Die Wärmepumpe (NEURA) in das Smarthome einbinden

Ein Smarthome ist heute keine Seltenheit mehr und sehr weit verbreitet. Es gibt unzählige Systeme am Markt, die das eigene Zuhause „Smart“ machen. Die digitalen Sprachassistenten von Google, Amazon und co. in Verbindung mit Smarten Glühlampen zählen zu den einfach und schnell zu installierenden Systemen. Aber es gibt auch komplexe Smart Home Systeme, bei denen in den Hausverteilern Aktoren für jede Lampe und Steckdosen verbaut sind. Die Fenster und Türen sind mit Meldekontakten ausgestattet und sichern das Eigenheim oder melden, wenn einmal auf das Schließen der Fenster nach dem Stoßlüften vergessen wird. Das diese Systeme bei vernünftiger Programmierung auch zur Energieoptimierung beitragen ist selbstverständlich. Auch ich betreibe Smarthome Komponenten unterschiedlichster Hersteller.

Dazu gehört seit Jahren das HomeMatic System, das sowohl kabelgebunden als auch über das Bidcos-Protokoll mit seinen Aktoren und Sensoren kommuniziert. Das HUE – System von Phillips spricht dabei über ZigBee mit seinen smarten Lampen und Steckdosen. Die Gateways dieser Systeme sind an ein LAN Netzwerk angeschlossen und jedes System bringt seinen eigenen Webserver mit, über den es dann zu steuern und einzustellen ist. Ein Wechselrichter von Photovoltaikanlagen kann seine Daten über unterschiedlichste Schnittstellen (RS485, CAN, RS232) zur Verfügung stellen. Um alle auf eine zentrale Darstellungsebene zu bringen, habe ich mich für das NodeRed System entschieden. Der Dazu notwendige NodeRed Server läuft auf einem Raspberry PI. (Auf der CCU3 mit dem Raspbian Image ist noch genug Platz um den NodeRed Server laufen zu lassen – der ist sogar als eigenes Plugin für die CCU verfügbar und wird „RedMatic“ genannt).  Mit dieser Konfiguration lässt sich fast alles im Bereich Homeautomation „erschlagen“. Mit ESP32 und Raspberry lassen sich über MQTT (Message Queueing Telemetry Transport) bequem Statusinformationen übertragen. Dies wende ich beispielsweise bei den kleinen Einspeise Wechselrichtern einer Balkon PV-Anlage an, als auch bei den PV-Wechselrichtern einer Offgrid-Anlage. Hier werden die Daten über unterschiedliche Bussysteme im Raspberry oder ESP32 empfangen und in das MQTT-Protokoll umgesetzt. Der MQTT Broker sammelt die Daten der einzelnen Geräte und über NodeRed lassen sie sich dann in eine Datenbank schreiben, im Browser oder am Smartphone visualisieren und auch einfach, je nach Bedarf, im HomeMatic System verarbeiten.

Beispiel eines Smarthomenetzwerks

Somit ist es möglich, nahezu alle Systeme miteinander Smart zu vernetzen und, für mich wichtig auf EINER Plattform zu visualisieren. Ein einziges System fehlte bisher noch. Das ist meine alte Neura Heizungswärmpepumpe. Die Firma Neura ist schon seit einigen Jahren nicht mehr existent und der von „b.i.t.“ entwickelte auf Webserver „webidalog“ wurde nie mehr aktualisiert. Die Wärmepumpe hat also einen Webserver auf einem kleinen mit Linux-Rechner onboard und baut die Webapplikation mit einer uralten Java Version. Für die Bedienung muss am PC eine Java Runtime installiert sein, die nur mit einigen Tricks auf einem aktuellen Windows Rechner läuft (Stichwort: Virtualisierung). Für die Bedienung über ein Smartphone ist eine html – Version mit eingeschränkter Funktionalität verfügbar. Mein Plan war es nun, eine Schnittstelle zu finden, mit der ich die Daten der Wärmepumpe zumindest einmal auslesen kann, um Vorlauf- Rücklauftemperaturen der Fußbodenheizung, Kesseltemperatur, etc. auch in meinem NodeRed System zur Verfügung habe. Da zu dem System aber so gut wie keine Dokumentation zu finden ist und ein Reverse-Engineering ein wenig kritisch ist, wenn das System weiter laufen soll, kam mir folgende Idee:

Mit einem „headles browser“ sollte es ja möglich sein, die html-Version der Neura WebDialog Website zu parsen und die relevanten Daten zu finden und über Variablen in MQTT-Topics zu verwandeln. Und hier muss ich einen besonderen Dank an meinen Kollegen Mario Wehr aussprechen, der mir die Softwarestrukur zum parsen der Website gebaut hat. Die Software ist in PHP geschrieben und läuft schlussendlich auf einem Raspberry PI. Hier sind lediglich eine php8-cli runtime und ein paar Module notwendig. Die Software funktioniert so, dass bei jedem Aufruf ein Login auf der Wärmepumpenwebsite ausgeführt wird, danach werden die Daten geparsed und zu MQTT-Broker gesendet. Das kontinuierliche Aufrufen des php-Skriptes habe ich dann einfach mit einem cronjob gelöst, der jede Minute ausgeführt wird.

 

>sudo crontab -e

und der job sieht dann so aus:

* * * * * sudo php /home/neura2mqtt/neura2mqtt.php -c

(wenn man sich die files  ins  /home/ verzeichnis legt…). Das Projekt habe ich auf github unter:  https://github.com/ingmarsretro/neura2mqtt veröffentlicht.

Neura Daten am NodeRed Dashboard

 

 

 

 

MIDI DB50XG – ein Interface für das Daughter Board

Beim Stöbern in einer Kiste mit meinen alten Bastelarbeiten ist das folgende Kästchen zum Vorschein gekommen.  Es stammt aus der Zeit als ich noch mit Amgia, aber auch schon mit PCs zu tun hatte – ich schätze so ca.  um 1996. Das Kästchen beschriftete ich mit „DB50XG MIDI – Wavetableprozessor“.

Das Fundstück aus der Kiste

Darin befindet sich eine Platine von Yamaha, die sich eben DB50XG nennt. Diese Platine war als Tochterplatine für PC-Soundkarten mit „Waveblaster“ Erweiterungsport konzipiert. Sie erweiterte die Soundkarten um einem polyphonen MIDI – Wavetable – Sampler. So konnte der General Midi Standard und der Yamaha XG Standard wiedergegen werden.  Heute macht sich darüber niemand mehr Gedanken. Wenn man damals mit einem PC aus Midi – Daten Sounds erzeugen wollte, dann war entweder eine externe Hardware notwendig, oder eben eine Soundkarte mit einem OnBoard Midi Synthesizer oder Wavetable Chipsatz. Der PC übernahm dann die Steuerung, das Senden und Empfangen der Midi Daten über eine Sequenzer Software. Heute werden die Midi Sounds direkt am PC generiert und die Samples und Tonmodelle in die Software eingebunden. Damals reichte die Leistung der PC-Hardware dazu nicht aus. Wenn sich jetzt jemand gerade fragt, worüber ich hier palavere – was ist Midi und wofür benötigt man das? – dann sei hier kurz gesagt: Midi ist die Abkürzung für „Musical Instrument Digital Interface“ – also eine digitale Schnittstelle – ein Datenprotokoll für Musikinstrumente. Es dient – grob erklärt – dazu, elektronische Musikinstrumente untereinander zu vernetzen und zu steuern. So kann zum Beispiel über ein einziges Keyboard eine Vielzahl von klangerzeugenden Geräten gesteuert werden. Wie der Midi Standard funktioniert, wie die Datenpakete aussehen und das elektrisch aussieht, werde ich hier nicht erläutern. Dazu findet man, wie immer, reichlich Informationen im Netz.

Im Inneren des Kästchens

Zurück zum selber gebastelten Kästchen. In die Plastikbox habe ich damals das DB50XG gepackt und vom „Waveblaster“-Port, einer 26poligen Buchsenleiste, die notwendigen Leitungen zur Inbetriebnahme der Midi Platine nach Außen geführt. Und das war ziemlich simpel. Die Platine benötigt eine Spannungsversorgung von +/-12V und +5V. Es gibt einen Midi-IN und einen Midi-OUT (Through) Pin, einen Reset-Pin und zwei Analog Audio Out Pins – je einen pro Kanal. Die untenstehende Tabelle zeigt die Pinzuordnung des Steckers:

Pin Nummer Zuordnung
1 Digital Masse
2 nicht verbunden
3 Digital Masse
4 nicht verbunden
5 Digital Masse
6 Versorgung +5V
7 Digital Masse
8 nicht verbunden
9 Digital Masse
10 Versorgung +5V
11 Digital Masse
12 nicht verbunden
13 nicht verbunden
14 Versorgung +5V
15 Analog Masse
16 nicht verbunden
17 Analog Masse
18 Versorgung + 12V
19 Analog Masse
20 Audio out rechts
21 Analog Masse
22 Versorgung -12V
23 Analog Masse
24 Audio out links
25 Analog Masse
26 Reset

Der ganze Aufbau war damals eher sehr spartanisch gestaltet. Die Stromversorgung musste über ein, oder mehrere externe Netzteile hergestellt werden. Es gab keine galvanische Signaltrennung mittels Optokoppler. Da musste ich mich auf den ordentlichen Aufbau des Midi-IO-Controller verlassen, den ich an den Amiga angeschlossen hatte. So durfte das natürlich nicht bleiben. Und das schöne DB50XG Board nicht mehr zu verwenden, oder dem Elektronikschrott zuzuführen, bringe ich nicht über´s Herz. Der Plan der daraus entstand, war, ein neues Interfaceboard zu entwickeln – oder basteln, das möglichst universell einsetzbar werden sollte. 

DB50XG

Diese Idee ist nun schon wieder einige Jahre her und immer wieder einmal habe ich ein wenig daran gearbeitet. Folgende Punkte, so habe ich mir ausgedacht, sollte das Interfaceboard erfüllen:

  • eine einfache Spannungsversorgung soll das Yamaha Board mit Energie versorgen. Idealer Weise soll ein USB-Port und optional ein Anschluss für ein Universalnetzteil vorhanden sein. Alle benötigten Spannungen sollen auf dem Interfaceboard aus den 5VDC generiert werden.
  • Das DB50XG soll, wie seinerzeit, auch als „Huckepack“ Platine aufgesteckt werden können
  • Das Midi-in Signal soll über die 5polige DIN Buchse und auch über einen Pinheader eingespeist werden können – natürlich schön entkoppelt (Damit kann auch ein Microcontroller wie Arduino und co. ganz ohne Aufwand angeschlossen werden)
  • Der Ton, also das Audiosignal soll pro Kanal über je eine Chinch-Buchse und auch als 3.5mm Klinkenbuchse und über einen Pinheader zur Abnahme bereitstehen.
  • Wortwiederholungen SOLLTEN vermieden werden, ist mir aber egal 🙂

Daraus entstand schlussendlich der folgende Schaltplan. Die 5VDC Versorgung der USB Quelle wird direkt zur 5V Versorgung des Midi Boards geführt. Die ebenfalls benötigten +12V/-12V erzeugt ein DC/DC Converter (TMR0522). Dieser wird eingangsseitig vom 5V Netz versorgt. Der optionale „Externe“ Spannungseingang gelangt an einen LM2596ADJ. Das ist ein Step-Down Voltage-Regulator der mit Eingangsspannungen bis zu 40V arbeiten kann. Die geregelte Ausgangsseite ist in vielen Bereichen verfügbar. Ich habe hier den ADJ (Adjustable) Typ in die Schaltung integriert, da ich davon einige Stück im Sortiment Kasten habe. Durch einen Jumper am Board ist, die Spannungsquelle wählbar.

Auf Basis dieses Schaltplanes habe ich ein Layout erstellt und es vorerst einmal im eigenen Ätzbad hergestellt. Heraus kam die folgende Platine, die als Testaufbau diente. Technisch funktionierte das Board einwandfrei, jedoch die Anordnung der Komponenten hat mir nicht gefallen. Den Step-Down Converter samt Spule hatte ich auf der Rückseite platziert. Auch war mir der Abstand zwischen den Anschlussbuchsen zu eng beieinander. Und wie man das als PCB Layouter so macht – man macht immer ein zweites Design. So auch dieses Mal.

Der Testaufbau mit bestücktem Midiboard ist im nachfolgenden Bild zu sehen. Das Midi-Signal als Testquelle kommt vom PC und wird durch einen USB-Midi Adapter aus Fernost generiert.

Also noch einmal vor den Rechner gesetzt und das Layout umgezeichnet. Heraus gekommen ist dann die folgende Version. Diese Ausführung habe ich dann bei einem Leiterplattenhersteller bestellt.

Die schlussendlich gefertigte Platine in bestücktem Zustand sieht dann so aus. Darunter ist sie  mit dem aufgesteckten DB50XG Board zu sehen.

 

Die Wetterkugel – oder das Goethe-Glas

Immer wieder halte ich Ausschau nach einfachen, interessanten Dingen. Dieses Mal hat mich ein Messgerät- oder eher „Anzeigegerät“ fasziniert, dessen Funktionsprinzip äußert einfach und doch sehr effektiv ist. Zudem ist es aus meiner Sicht auch noch ein Hingucker – Es handelt sich um das so genannte Goethe-Barometer. Die bekannteste Form ist wohl das an der Wand hängende, bauchige Glas mit einem Schnabel, ähnlich einer Gießkanne, in dem der Wasserstand den Luftdruck anzeigt. Eine etwas anders konstruierte Version dieses Glases habe ich im Netz gefunden…

Ein wenig zur Geschichte dieses Aufbaues:

Einem Herrn namens Evangelista Toricelli (1608-1647), einem italienischen Physiker und Mathematiker verdanken wir die Erkenntnis und den Nachweis, dass der Luftdruck Schwankungen unterliegt. Er baute 1643 das erste nach ihm benannte Barometer. 1644 entwickelte er das Quecksilberthermometer.

Ein kleiner Ausgleichsbereich im Anzeigerohr schützt vor Überlauf

Der deutsche Dichter Johann Wolfgang Göthe, beschäftigte sich auch mit den Naturwissenschaften. Er machte selbst viele naturwissenschaftliche Experimente und entwickelte später ein einfaches, aber wirkungsvolles Barometer auf den Grundlagen des Toricelli.

Die Funktionsweise:

Das Barometer zeigt schnell und präzise Luftveränderungen an. Bei steigendem Luftdruck fällt die Wassersäule im Anzeigerohr und bei fallendem Luftdruck steigt sie. Möglich ist dies durch die im Glas eingeschlossene Luft. Das Volumen der Luft bleibt bei gleichbleibender Temperatur immer gleich. Steigt oder sinkt der äußere Luftdruck, so wird die eingeschlossene Luft über die Wassersäule zusammengedrückt oder eben ausgedehnt. Da sich das Wasser nicht komprimieren lässt, ist es das ideale Medium um die Druckunterschiede sichtbar zu machen. Die Höhe der Wassersäule zeigt somit den Luftdruck an. Ist der Luftdruck bei schönem Wetter hoch, so ist der Außendruck gegenüber dem Druck der eingeschlossenen Luft höher und die Wassersäule sinkt, da die eingeschlossene Luft verdichtet wird. Bei niedrigem Luftdruck kann sie sich ausdehnen und der Stand der Wassersäule steigt.

die Höhe des Wasserstandes im Rohr zeigt den Luftdruck an

Dieses kurze Zeitraffervideo zeigt die Änderung des Wasserstandes bei Luftdruckänderung:

Geigerzähler – Bausatz aus Fernost

Immer wieder fasziniert mich das Thema Radioaktivität. Genauer gesagt ist es das Messen oder Detektieren dieser ionisierenden Strahlung, die durch den Zerfall und von Atomkernen unter Abgabe von Energie entsteht. Dabei unterscheidet man prinzipiell die aus der Bewegung der zerfallenden Teilchen (also Teilchenstrahlung) ausgesandte Energie (Alpha- und Beta- Teilchen) und der Strahlungsenergie, die als elektromagnetische Welle transportiert wird (Gammastrahlung und auch Röntgenstrahlung). Diese Strahlungsarten haben unterschiedliche Energiedichten und Reichweiten. Je nach Art sind sie mehr oder weniger einfach abzuschirmen. Alphastrahlung ist eine Teilchenstrahlung, die von Materie (Luft, Wasser) stark abgebremst wird und ein Blatt Papier gar nicht mehr durchdringt. Allerdings geben diese Teilchen auf ihrer sehr kurzen Distanz die Energie ab. Das ist besonders gefährlich, wenn diese Partikel eingeatmet werden, oder an den oberen Hautschichten strahlen. Gammastrahlung wiederum durchdringt wie eine Funkwelle Materie sehr leicht und lässt sich am wirkungsvollsten mit Blei abschirmen. Das auch diese Strahlungsart alles andere als ungefährlich ist, braucht man wohl nicht zu erwähnen.

Diese Strahlung kann man nicht sehen, riechen, schmecken oder sonst irgendwie direkt wahrnehmen, aber die Gefährlichkeit ist trotzdem vorhanden. Mit relativ einfachen Techniken kann man diese Zerfallsprozesse aber sichtbar, bzw. hörbar machen und zählen. 

Das bewerkstelligt man schon seit langem mit einem sogenannten Zählrohr oder dank der modernen Technik auch mittels Halbleiter. Ein P-N-Übergang wird in Sperrrichtung betrieben und unter Ausschluss von Licht (also abgedunkelt) der ganz kleine Sperrstrom gemessen. Trifft nun energiereiche Strahlung auf diesen P-N-Übergang dann wird der Stromfluss kurzzeitig erhöht und kann detektiert werden.

Immer wenn sich die Möglichkeit ergibt, sehr günstig zu einem Detektor zu kommen, greife ich natürlich zu. So auch dieses Mal. Einen einfachen Bausatz, basierend auf der Detektion mittels Zählrohrs musste ich mir ansehen. Der Bausatz stammt aus Fernost und besteht aus einer Basisplatine, einem aufgesteckten Arduino Nano und einem ebenfalls aufgesteckten LC-Display.

Alle für die Detektion notwendigen Komponenten befinden sich auf dem Mainboard. Dazu zählt unter anderem die Hochspannungserzeugung für das Zählrohr, die mittels einfacher Boost-Konverterschaltung, angetrieben von einem 555er, realisiert wird. Um das Zählrohr auf dem Mainboard zu befestigen hat der Designer dieses Boards einfache Glasrohrsicherungshalter gewählt. Die passen zwar nicht ganz exakt, lassen sich aber soweit ausdehnen, dass sie das Zählrohr gut festhalten. Das Zählrohr ist übrigens ein J305. Es ist ca. 90mm lang und hat einen Durchmesser von knapp einem Zentimeter.

Das Zählrohr arbeitet bei einer Anodenspannung von 350V bis 480V. Nachstehend habe ich die Spezifikationen aus dem Datenblatt aufgelistet:

  • Anodenspannung: 350 v bis 480 V
  • Typ: J305 Geiger-Zählrohr
  • Kathodenmaterial: Zinnoxid
  • Wandungsdichte: 50 ± 10 cg/cm²
  • Betriebstemperaturbereich: -40 °C bis 50 °C
  • Durchmesser: 10 mm (±0,5 mm)
  • Länge: 90 mm (±2 mm)
  • Eigenhintergrundstrahlung: 0,2 Impulse/s
  • Empfindlichkeit gegenüber γ-Strahlung: 0,1 MeV
  • Stromaufnahme: 0,015 mA bis 0,02 mA
  • Arbeitsspannung: 380 V bis 450 V
  • γ-Strahlung: 20mR/h ~ 120mR/h
  • β-Strahlung: 100 ~ 1800 Pulse/min.
  •  100 ~ 1800 Pulse/min.

Die Signaldetektion sowie die Aufbereitung des Signals erfolgt auch auf dem Mainboard. Die erkannten Impulse werden über einen kleinen Piezolautsprecher wiedergegeben. Um sie auch zählen zu können, muss man nicht mit einer Stoppuhr vorm Lautsprecher sitzen und im Minutenabstand die Pieptöne zählen – nein – das übernimmt ein Microcontroller, der wie heute üblich, aus einem fertigen Board besteht. Hier hat der Designer einen Arduino Nano (oder auch Nanonachbau) gewählt. Auf dem wiederum läuft ein Programmchen, dass das Zählen der Impulse übernimmt und auch gleich schön auf einem zweizeiligen LC-Display anzeigt und idealerweise auch noch in µSievert/h umrechnet. Um die Pulse dem Arduino zu übergeben, wird der Pegel des Signals auf TTL-Level gebracht und an den Interrupt-Eingang des Arduino geschaltet. Das LC-Display benutzt den I2C Ausgang des Arduino. Die Leitungen dafür werden lediglich von der Buchsenleiste, in die der Arduino gesteckt wird, über das Mainboard zur Buchsenleiste für das Display geführt. Um das ganze System mit Spannung zu versorgen, werden direkt die 5V vom USB-Anschluss des Arduino verwendet. Optional kann man die 5V auch über eine Steckerleiste am Mainboard anschließen.

Ist alles zusammengebaut und die USB-Versorgung angesteckt, dann gibt es zuerst einmal eine kurze Wartezeit in der die Hochspannung aufgebaut wird. Hier hat sich der Programmierer eine Animation ausgedacht, die am Display „Boot…“ anzeigt.

Und dann geht es auch schon los. Der Geigerzähler ist betriebsbereit und beginnt zu zählen. Als Test habe ich lediglich eine alte Uhr, deren Zeiger mit Radiumfarbe bemalt sind, zur Verfügung. Hier ist zumindest eine deutliche Änderung der Anzahl der detektierten Zählimpulse festzustellen, wenn man die Uhr in die Nähe des Zählrohrs bringt.

LEGO Mindstorms EV3 mit Matlab und Simulink

Wer mit Matlab und Simulink arbeitet oder lernt und einen LEGO EV3 Brick samt Sensoren und Aktoren besitzt, kann diese Systeme miteinander verknüpfen. Rund um den EV3 Brick gibt es natürlich eine Community und etliche Plattformen, über die man mit dem Brick kommunizieren kann. Doch dazu später.

Der Lego EV3 Brick ist im Wesentlichen ein Einplatinencomputer der mit einem LC-Display und vier Input- sowie vier Output-Ports (Schnittstellen für Sensoren und Aktoren) ausgestattet ist. Als Datenschnittstellen gibt es einen USB Port als HOST und einen MiniUSB Port als Interface zum PC und den diversen Softwaretools.

Will man mit dem Brick wireless kommunizieren, so ist dies über WiFi, beziehungsweise über Bluetooth möglich. Allerdings ist die Hardware zur Funkübertragung nicht im Brick verbaut und muss als USB Dongle in den Host-Port gesteckt werden.

Folgende USB Wifi Sticks sind lt. Internetrecherche mit dem EV3 und der originalen Legofirmware ab 1.08 kompatibel: (Quelle: Internet)

  • tp-link WL0084E
  • EDIMAX EW-7811Un mit dem Chipsatz RTL8188CUS
  • LogiLink WL0084W auf der Vertriebsseite (Conrad) angeblich mit dem Chipsatz Railink RT5370 jedoch das Herstellerdatenblatt gibt den Chipsatz RTL8188EUS an.

Im Test hat sich gezeigt, dass lediglich Dongles mit dem Realtek RTL8188CUS Chip im embedded Linux des EV3 Driver mäßig implementiert sind. Der Nachfolger von Realtek der RTL8188EUS funktioniert hier nicht.  Und die meisten Hersteller von Wifi USB Dongles (Stand 2021) vertreiben ihre Sticks mit dem 8188EUS Chip, sei dies TPLink, Edimax, LogiLink und wie sie alle heißen. Erkennbar ist das bei manchen an der Typenbezeichnung V2, oder 7811UN V2 (bei Edimax) oder V.02, V.03 bei TPLink. Ist diese Kennzeichnung beim Stick oder dessen Verpackung dabei dann wird das nix. Zumindest nicht, wenn mit der originalen Legofirmware gearbeitet werden will.

Vergleich edimax 7811un und 7811un v2
edimax 7188un mit RTL8188CUS chip
edimax 7188un V2 mit RTL8188EUS chip

Nun weiter zum EV3 Brick:

Auf diesem Einplatinencomputer läuft ein auf Linux basierendes embedded Betriebssystem das auf einem internen Flash- Speicher abgelegt ist. Dieses Betriebssystem wird in Form einer Firmware von LEGO zur Verfügung gestellt und ist zur Zeit in der Version 1.10 verfügbar. Diese Firmware ist beinhaltet sämtliche Partitionen der Laufwerke und deren Inhalt und wird im Rahmen eines Updates in einem „.bin“ File verpackt in den Flash geladen. Mit den Softwaretools „binwalk“ ist es unter Linux möglich, die Struktur der Partitionen aus dem Firmware File wiederherzustellen, zu ändern und wieder als „.bin“ Firmware Image auf die Hardware hochzuladen.

Es gibt aber auch Custom Firmware und Betriebssysteme die per SD-Card gebootet werden können. Welche Treiber hier mitgeliefert werden ist auf den Seiten der entsprechenden Custom OS Hersteller nachzulesen.

Folgende Betriebssysteme habe ich für den EV3 auf die Schnelle gefunden:

  • ev3dev (https://www.ev3dev.org/)
  • leJOS (https://sourceforge.net/projects/lejos/files/lejos-EV3/)

Man kann den EV3 mit folgenden (und ich nenne hier auch nur die gängigen die auch mir eingefallen sind) Tools bzw. Programmiersprachen programmieren:

  • LEGO EV3 Originalsoftware
  • NI Labview bist Labview Fall2016 ? (Unterstützt bzw. EV3 Plugins implementiert)
  • Matlab und Simulink (Harware Supportpackage für EV3 notwendig) link
  • MicroPython EV3 link

Fakt ist jedoch: der in die originale Lego EV3 Firmware (1.08H , 1.09D) integrierte Treiber für WLAN-Sticks unterstützt nur den Chipsatz RTL8188CUS. Und den benötigt man, wenn man über SIMULINK im „Monitor und Tune“ Modus mit dem Brick arbeiten will. Denn interessanter Weise klappt das NUR über eine WiFi Verbindung und NICHT über einen direkten USB Link zwischen PC und EV3.

Es ist auch NUR mit der Firmware 1.08H möglich mit Simulink zu kommunizieren da hier TELNET und SSH als Kommunikationsprotokoll genutzt werden. Und nur in der 1.08H ist eine ungeschützte Verbindung der Weg zum Erfolg. Ab der Version 1.09D ist ein Login notwendig.

Da die Firmware Versionen mittlerweile schwer zu finden sind, stelle ich hier einen Link zum Download herein.

Download EV3 Firmware 1.08H
Download EV3 Firmware 1.09D

Was benötigt man nun, um über Simulink mit dem EV3 sprechen zu können ?

  • zunächst muß Matlab und Simulink installiert sein
  • dann muss man das Support Package EV3 für Matlab und EV3 für Simulink herunterladen und installieren
  • auf dem EV3 Brick solltedie originale Firmware 1.08H vorhanden sein. Ist dies nicht der Fall kann die Version über den Firmwaredownloader in der orginalen EV3 PC Software auf das Gerät übertragen werden.
  • im EV3 Brick muß ein USB Wifi Dongle mit dem „CUS“ Chipsatz stecken
  • der PC muß idealerweise im selben Netz hängen wie auch das Wifi-Funknetz mit dem sich der Brick verbindet. Ein DHCP Server muß die IP Adressen für die Funkgeräte verteilen
  • jetzt kann der Brick gestartet werden. Danach muß er mit dem WLAN Netz verbunden werden (es sollten WPA2 Passwörter ohne Sonderzeichen festgelegt sein, da der EV3 Brick diese nicht zur Verfügung stellt)
  • ist der EV3 mit dem Netz verbunden, dann ist unter dem Menu „Brick Info“ die aktuelle IP Adresse des Bricks und die Brick ID zu notieren. Diese Infos werden gleich im Simulink Setup benötigt
  • nun zu Simulink: dort ist im Menu „configuration Parameters“ unter „Hardware Implementation -> Hardware board“ Mindstorms EV3 zu wählen 
  • das Setup wird im selben Menu unter „Hardware board settings“ -> Target hardware resources -> Groups -> Host to Target Connection festgelegt. Hier ist „Ethernet“ als Connection Type einzustellen. Die vorher ermittele IP Adresse und ID des Brick sind hier auch einzugeben.Das war´s dann auch schon. Nun sollte es möglich sein eure Simulink Modelle mit der EV3 Hardware zu nutzen und auch die Tune Infos während der Simulation am PC zu sehen …

 

 

 

Das zweite Buch zum Blog

Nach dem großen Erfolg meines ersten Buches zum Retroblog, habe ich mich nun durchgerungen und ein zweites Buch verfasst – NEIN SPASS – es gab gar keinen Erfolg. Das Buch habe ich damals verfasst, um für mich selber ein in Papier gedrucktes Werk meiner (Un)taten dieser Website in Händen zu halten. Denn erstens ist es wesentlich praktischer, einmal schnell was nachsehen zu können – ohne immer ein Internet zu Verfügung zu haben und zweitens: was wenn der/die Server nicht mehr erreichbar sind, oder gelöscht werden, oder gar abbrennen? Oder noch schlimmer, wenn jemand das Internet löscht… 😀

Ich dachte mir damals zwar, es über eine „Druck on Demand“ Option aufzulegen, aber wer weiß ob das irgendjemanden interessiert und ob ich das überhaupt so einfach darf. Und wer würde dafür auch so viel Geld ausgeben. Denn die Einzeldrucke sind auch ganz schon kostenintensiv. Also sind die hier Vorgestellten, gedruckten Exemplare quasi Unikate. Und ich bin auch ein bisschen stolz darauf, denn es steckt doch einiges an Arbeit drinnen.

Also nun gibt es das Retrobuch Nr.2 mit der Fortsetzung der Blogeinträge vom Ende der ersten Version bis zum Eintrag „Schukosteckdose mit USB (reparieren)“ vom 19.Dezember 2020 und das sind immerhin wieder 96 „Geschichten“ die diesmal 498 Seiten belegen. Auch für diesen Druck habe ich wieder „epubli“ gewählt und dort bestellt. Das hat den Vorteil, dass ich, sollte ich noch einen Druck eines der bestehenden Bücher haben wollen, einfach nur wieder auf „bestellen“ klicken muss, da ja alle Produktionsdaten bereits vorhanden sind.

Ich habe auch einiges dazu gelernt, was die Formatierung der Texte, Fonts, Schrittgrößen und Verzeichnisse betrifft. Die Bilder sind jetzt mit einer höheren Auflösung gedruckt und es sieht alles in allem besser aus.

So bleibe ich dran und werde in ein paar Jahren, wenn wieder genug Content verfasst ist, wieder an einer Ausgabe basteln.

Aufräumen und Archivieren

Hinter dem, in der Beitragsüberschrift genannten Titel versteckt sich meine Idee, in dem „ingmarsretro“ Blog einmal etwas Ordnung zu machen und ein wenig aufzuräumen. Mit „Aufräumen“ meine ich, die einzelnen Beiträge wieder mal auf Rechtschreibfehler zu prüfen, vielleicht auch den einen oder anderen Beitrag neu zu formatieren und ihn auch zu ergänzen. Darum wird es im Jänner 2021 auch keinen anderen Beitrag geben.

Es haben sich auch reichlich neue Beiträge angesammelt, die zwar digital auf dem Server gesichert sind, jedoch eine Papierform davon gibt es noch nicht. So will ich alle Posts, die seit der letzten Sicherung entstanden sind, wieder in Form eines Buches zu Papier bringen. Und das ist leider nicht ruck-zuck gemacht, sondern bedarf einiges an Arbeit. Der Beruf und die „Familienzeit“ mit meinem kleinen Sohn erlauben es nur, meistens nachts an den Beiträgen zu arbeiten. Und zwischen den Beiträgen bastle ich ja auch an den Projekten (Projekt’chen), über die ich dann ja schreibe. Davon habe ich auch noch viele im Kopf, die vielleicht einmal realisiert werden. Und dann gibts noch einige, an denen ich arbeite und die noch fertiggestellt, oder zumindest daran weitergearbeitet werden soll.

So bastle ich seit den letzten Monaten an einer Nixie-Uhr, die ziemlich diskret aufgebaut werden soll. Die Uhr hat mittlerweile auch einen vernünftigen Status erreicht, so dass hier Platinen vom selber geätzten Prototyp bis zum vernünftigen, industriell gefertigten Zustand, entstanden sind.

der NixieUhr Prototyp

Auch der „Röhrenradioempfänger“ mit dem ich vor einigen Jahren begonnen habe, wartet darauf, dass daran weitergebastelt wird.

Das Thema Retro Computer lässt mich natürlich auch nicht los. Hier sind ein paar Geräte noch zu restaurieren und warten darauf, wieder zum Leben erweckt zu werden. (Hier fällt mich gleich ein: ich suche eine RUN/STOP Taste für einen Commodore Plus 4 – würde mich freuen, wenn irgendein Leser da helfen könnte…)

auf der Suche nach einer RUN/STOP Taste

Das Projekt mit der MOS8501 CPU als Lattice – FPGA – Miniplatine steht auch in der „Weitermach-Warteschlange“ hier gibts noch einiges zu tun (Die Levelshifter tun noch nicht so, wie sie sollen, der VHDL Code muss noch weiter angepasst werden, die Prototypen Platinen müssen auf ein Board zusammengefasst werden und dann auch noch miniaturisiert werden…) ist also auch noch genug zu tun.

Dann gibt´s auch noch alte Geräte, die ich hier im Blog vorstellen möchte und noch etliche Reparaturen, die mir immer wieder in die Hände fallen… Auch das eine oder andere HomeMatic-Gebastel steht noch an.

Auch habe ich mit dem Gedanken gespielt, Content hier aus dem Blog in Form von Videos auf YouTube zu veröffentlichen. Aber ich kann zum einen nicht abschätzen, ob das jemanden interessiert und ob ich mir das antun möchte, meine Visage vor der Kamera zu präsentieren. Wahrscheinlich wäre es sinnvoller, es mit einem didaktisch begabteren Menschen als Protagonisten zu machen. Und das natürlich für Lau, als Spaß an der Sache. Andererseits gibt es hier ja etliche Youtuber, die hier sehr erfahren (z. Bsp.: Dave Jones mit seinem EEVblog, NoelsRetroLab, Adrians Digital Basement, GreatScott, ZeroBrain, JanBeta, etc.)  sind und das schon lange betreiben. Auch nicht zu vernachlässigen ist der immense Aufwand, solche Filmchen zu Produzieren. Wenn ich hier meine Aufbauvideos betrachte: So geht fast ein Tag für das Aufnehmen des Rohmaterials beim Zusammenlöten des jeweiligen Bausatzes drauf und zusammengerechnet fast drei Tage für den Schnitt und Nachbearbeitung. Mal sehen ob daraus einmal etwas werden kann…

 

 

 

HomeMatic Rauchmelder HM-SEC-SD Schnellreparatur

Auch dieses Mal wieder ein schneller Beitrag zum Thema „Alterung und Homematic Smart Home“. Es geht um folgendes Gerät: Den Homematic Rauchmelder HM-SEC-SD, also die ältere Version der Rauchmelder aus dem Hause eq3.

Eines gleich vorweg: Dieser Beitrag zeigt lediglich, wie ich dieses Gerät wieder in Betrieb gesetzt habe. Da es sich um ein sicherheitsrelevantes Gerät handelt, müsste nach der Reparatur wieder eine Abnahme durch ein zertifiziertes Prüfunternehmen stattfinden um es weiter verwenden zu dürfen. Der Beitrag stellt also nur das, was in dem Gerät kaputt geworden ist.

Worum geht es also?  Der Funkrauchmelder HM-SEC-SD zeigte im Rahmen des monatlichen Tests (ja man sollte einmal im Monat die Prüftaste drücken) folgendes Symptom:

Ein kurzer Druck auf die Taste und es kam kein akustisches Signal – dafür blinkt die rote Signal-Led mehrfach im ca. 0.5s Takt. Ein Erneuern der Batterien ändert nichts, das Verhalten bleibt. Das Funkmodul des Melders verhält sich normal. Man kann es Rücksetzen und auch wieder anlernen. Ein Blick in die Bedienungsanleitung sagt in diesem Fall (unter Punkt 9.2 Seite 24)

Beginnt nach dem Drücken der Taste nur die Leuchtdiode zu blinken, ist der Rauchmelder defekt und muss ausgetauscht werden
 
Also Zeit, den Melder zu öffnen und nachzusehen. Mein erster Verdacht fiel auf die Detektorkammer und dass hier eine Verunreinigung vorliegt oder sich ein Tierchen in der Kammer niedergelassen hat…
Rauchmelder geöffnet

Doch nach Entfernen des Deckels der Detektorkammer waren keine tierischen Eindringlinge zu entdecken. Jedoch an der Innenseite des Deckels war ein eigenartiges Muster zu erkennen:

Schlieren innen am Detektordeckel

Diese Schlieren, so dachte ich zuerst, sind im Rahmen des Spritzens des Kunststoffbauteils entstanden und müssen so sein. Doch bei näherer Betrachtung und einem „Darüberwischen“ mit dem Finger ließen sie sich entfernen. Kurz gesagt, diese Schlieren sind Staubpartikel. Und wenn sie am Deckel sind, dann auch in der gesamten Messkammer. Also mit Druckluft ausgeblasen, Deckel wieder draufgesteckt und getestet. -> selber Fehler wie zuvor. Also nochmal Deckel runter und etwas genauer mit einer Lupe hingesehen. Der gröbere Staub, wenn man von „grob“ sprechen kann war zwar weg, aber die Oberfläche der Photodioden hatte noch ganz feine und schwer erkennbare Schlieren. Also reinigte ich die Kammer und die Dioden mit ein wenig Alkohol an einem Wattestäbchen.

gründliche Reinigung erforderlich

Ein neuerlicher Funktionstest zeigte einen Erfolg – besser Teilerfolg. Nach Drücken des Prüftasters quäkte der Piezo – jedoch nur sehr, sehr leise – und damit meine ich kaum hörbar und die LED blitzte neun Mal im Abstand einer Sekunde. Also eigentlich so wie es sein soll. Nur eben viel zu leise. Also musste noch etwas kaputt sein. So untersuchte ich die Schaltung beginnend beim Piezo und wurde schnell fündig. Der Piezo wird von einem 40106 eine 6fach Schmitt-Trigger angesteuert. Um satt Strom zu treiben sind je drei „Schmitts“ parallelgeschaltet. Der Ausgang war niederohmig, was eigentlich nicht sein darf. Also den 40106 ausgelötet und noch einmal gemessen. Zwischen Pin 1,2 und 7 (Eingang und Ausgang des ersten Schmitt-Triggers und dem VSS-Pin) war ein satter Kurzschluss. Das bedeutet der IC-ist defekt.

6fach Schmitttrigger IC 40106

Nachdem der IC getauscht war, konnte der Rauchmelder endlich wieder wie gewohnt „schreien“.

Restauration / Umbau eines Arcadeautomaten

Zuerst einmal die Frage – was bedeutet eigentlich „Arcade“?  In Wikipedia findet man dazu folgendes:

Arcade-Spiel ist eine Bezeichnung für Videospiele, die seit den 1970er Jahren in öffentlichen Spielhäusern in den USA, so genannten Penny Arcades, bzw. in Europa in Spielhallen kostenpflichtig angeboten werden. In den frühen 1980er Jahren wurden Arcade-Automaten in Deutschland außer in Spielhallen auch in vielen Imbissbuden, Kiosken und Supermarktvorräumen aufgestellt, bis dies gesetzlich verboten wurde. An Arcade-Automaten kann der Nutzer gegen Geldeinwurf spielen. Der Spielpreis betrug in Deutschland in der Regel eine D-Mark, während er im Ausland meist geringer war. Erfolgreiche Spiele wurden später häufig für den PC sowie für verschiedene Videospielkonsolen umgesetzt. (wikipedia)

Aber das erklärt mir noch nicht warum dafür das Wort „Arcade“ verwendet wird. Als Begriffserklärung für „Arcade“ oder „Arkade“ ist zu finden:  die Arkade – der Säulengang oder „eine Arkade ist eine Abfolge von Bögen, von denen jeder gegen den nächsten stößt und der von Säulen oder Pfeilern oder einem überdachten Gang getragen wird.“ Darin würde sich für mich eher der Sinn der Wortwahl ergeben, da die Spielautomaten in den Hallen dicht an dicht aufgestellt wurden und so das Bild eines Ganges ergeben – und so nannte man dann die Spielautomaten einfach Arcade-Automaten… so meine Idee. Wenn jemand die Herkunft genauer oder richtig erklären kann – bitte darum.

Nun aber zu meinem kleinen Projekt. Mein Kollege hat einen alten Scheunenfund – einen Arcade Spielautomaten – mit der Jamma – Spielplatine „COMBAT SCHOOL“  bei Räumungsarbeiten gefunden und vorbeigebracht. JAMMA (Japan Amusement Machinery Manufacturers Association) bezeichnet auch eine 56-polige Schnittstelle, die das Automatenkabinett mit der Spielplatine verbindet. Bevor mit der technischen Inspektion begonnen werden konnte, musste einmal reichlich Schmutz entfernt werden. Nach einigem Staubsaugen und Wischen im Inneren des Kabinetts kam die Elektronik wieder zum Vorschein.  Augenscheinlich sah auch alles sehr vollständig aus. Die Bildröhre war auch nicht gebrochen und es fehlten keine Kabel und es war auch nichts abgeschnitten worden. Also wurde die Kiste mutig ans Netz gesteckt und der Hauptschalter betätigt. Ich erwartete alles, vom Knall und Rauch, bis hin zum Zischen der überspringenden Anodenhochspannung der Bildröhre. Doch es verhielt sich ziemlich normal. Der Entmagnetisierungsvorgang der Röhre war kurz zu hören und wenige Augenblicke später war am Monitor ein komplett farbfleckiges, verzerrtes Bild zu sehen. Mit etwas Fantasie konnte man den Schriftzug „Combat School“ erkennen. Und das Erfreuliche daran – trotz dass der Automat einige Minuten eingeschaltet ist, blieb der Zustand stabil. Es gab keine Rauchzeichen, noch irgendwelche Gerüche oder andere Veränderungen. Ausgenommen der modrige Geruch, alter in Kellern gelagerter Geräte. Also alles in allem, ein Projekt mit Erfolgsaussicht. Die folgende Aufzählung zeigt die Schritte, in denen ich die Reparatur bzw. Restaurierung durchführen möchte bzw.  auch durchgeführt habe:

(1) … Gerät reinigen und auf Vollständigkeit prüfen
(2) … kurzer Funktionstest
(3) … Monitor reparieren
(4) … kurzer Funktionstest um die Spielplatine zu testen
(5) … parallel zur Spielplatine einen auf Raspberry PI basierenden Emulator einbauen. Der Emulator soll über ein kleine Jamma Platine wahlweise an das Kabinett angeschlossen werden können.
(5.1) … Jamma Steckerplatine Ätzen
(5.2) … RGB Videoplatine für Raspberry PI zeichnen und ätzen (auf Basis eines R2R Widerstandsnetzwerkes zur D-A-Wandlung)
(5.3) … Raspberry Pi auf Trägerplatte montieren, mit Audioverstärker und Joystickinterface ausstatten und ein geeignetes Emulator-Image installieren
(6.0) … Funktionstest mit dem Raspberry PI Emulator

Zur originalen Spieleplatine vorab: Diese funktioniert nur teilweise. Es wurden einige Sprites nicht korrekt dargestellt. Die Fehlersuche und Reparatur des „Gatterfriedhofs“ habe ich bisher noch nicht durchgeführt. Der Schwerpunkt der Restauration lag vorerst auf der Raspberry Emulator Plattform, die anstelle der Originalplatine das Kabinett versorgen soll.

Monitor Platine mit 50Hz Videomonitor mit RGB Eingang

Im ersten Schritt wurde der Monitor, bzw. die Monitorplatine repariert. Hier waren in erster Linie im Bereich der Kissenentzerrung ein paar kleine Fehler durch defekte Kondensatoren und eine thermisch ausgelötete (kalte Lötstelle) Induktivität das Problem der fehlerhaften Bildgeometrie. Nach einer gründlichen Reinigung, und einem neu justieren der Bildgeometrie mit einem Bildmustergenerator konnte das Board dann wieder an seinen Platz.

Monitor Platine wieder an ihrem Platz

Ein weiteres Problem war die Bildröhre. Sie wies in den Ecken eine Falschfarbendarstellung auf. So wurde eine rote Farbfläche teilweise violett dargestellt. Dieser Effekt ist auf ein Problem mit der, in der Röhre vorhandenen Lochmaske zurückzuführen. Diese wurde entweder lange Zeit stark magnetisiert, oder noch schlimmer, durch eine raue Handhabe des Gerätes verbogen. Jedenfalls treffen die Elektronenstrahlen nicht an jeder Position auf die vorgesehene Leuchtschicht. Dieses Problem konnte ich zum größten Teil durch Entmagnetisieren mit einem mit Wechselstrom betriebenen Elektromagneten realisieren. (Ähnlich, wie es auch die ohnehin vorhandene Degausspule an der Röhre nach dem Einschaltvorgang macht – nur gezielter und wesentlich stärker)

Nachdem der Monitor wieder seinen Dienst verrichtet, ging es an den Bau eines Jamma – Steckverbinders. Dazu übernahm ich einfach die Abmessungen des originalen Steckverbinders in das Layout Tool und zeichnete ein neue Steckerplatine.

der originale Jamma Platinensteckverbinder mit 44 Polen
der gebastelte neue Steckverbinder

Jetzt ging es daran, auf einer kleinen, ca. 20 x 25cm großen Trägerplatte die Komponenten für die neue Hardware aufzubauen. Das Herzstück ist der viel geliebte Raspberry Pi 3, den ich mit Abstandhaltern auf der Platte befestigte. Für die Eingabe, also alle Joysticks, Buttons, Münzzähler etc. kamen fertige USB-Joystickplatinen zum Einsatz. Diese wurden ebenfalls auf der Platte montiert.

Raspberry PI auf Trägerplatte mit Joystickinterface

Erweitert wurde das Arrangement um einen Audioverstärker, der ebenfalls auf der Platte seinen Platz fand. Alle Leitungen zum und vom Raspberry bzw. auch zu den Joystickinterfaces führen zur Jamma Steckerplatine. Diese wird dann einfach anstelle der originalen Platine angesteckt und der Automat soll dann zur Schonung der alten Hardware mit dem Raspberry Image laufen.

im Bild links, das Raspberry Board, rechts die originale Spieleplatine

Das Bild oben zeigt das Raspberry Board montiert neben der alten Spieleplatine. Die Joysticks sind bereits auch alle funktionstüchtig. Hier ist nur zu erwähnen, dass die originalen Joys und Buttons high-aktiv sind und das USB-Joystickboard low-aktiv. (oder war es umgekehrt?) Dieses Problem ließ sich einfach mit einem Potentialumschalter der Summenleitung der Bedienkonsole des Kabinetts lösen…

Was jetzt noch fehlt, ist die Videoausgabe des Raspberry auf dem originalen 50Hz Röhrenmonitor. Dies könnte man mit einem HDMI – CVBS Converter und einem CVBS – RGB Komponentenkonverter lösen. Aber es ist doch viel cooler, die Möglichkeiten des Raspberry zu nutzen.

Hierzu habe ich eine kleine Platine gebastelt, die über ein R2R Netzwerk aus fünf Widerständen je R G B Kanal aus den Raspberry GPIOs die analoge Ansteuerung des Monitors erzeugt.

Infos und Anregungen dazu findet man auch auf GitHub unter vga666. Um den Raspberry zu motivieren, den HDMI Ausgang abzuschalten um über die GPIOs das Videosignal zu senden, muss lediglich die config.txt im root Verzeichnis der SD-Karte angepasst werden.

 

Das „Hineinhorchen“ mit der Osziprobe in einen der drei Kanäle zeigt ein sauberes Sync- und Videosignal. Also die drei Ausgänge und die Synchronisation über Elkos entkoppelt und über den Jamma Stecker an den originalen alten Monitor geschaltet:

Das Ergebnis ist doch ganz zufriedenstellend… Jetzt ist nur mehr der Fehler an der originalen Platine zu beheben und einige kleinere Schönheitsarbeiten am Holzgehäuse des Kabinetts durchzuführen. Aber das ist eine andere Geschichte…

 

 

 

FPGA CPU für Commodore 16

Meine erste Begegnung mit Computern hatte ich in den frühen 80iger Jahren, als meine Kollegen im Gymnasium ihren ersten VC20 und C64 von Commodore bekamen. Das war damals eine völlig neue Welt für mich – ein Computer – ein Gerät mit Tasten, wie bei einer Schreibmaschine, das man am Fernsehgerät anschließt. Und man kann in einer Sprache, die sich „Basic“ diesem Computer Befehle erteilen, die er dann ausführt.  Man konnte sogar ganze Programme schreiben und diese dann mit dem Befehl „RUN“ starten. Und dieser Computer arbeitete diese Programme dann ab. Das war faszinierend und eröffnete uns damals neue Welten. Erst recht als ich Kassetten bekam, die wie Musikkassetten aussahen, jedoch für den Computer gedacht waren. Darauf befand sich, spielte man sie in einem Kassettenspieler ab, ein Gepiepe, das man später von Faxgeräten oder der Einwahlsequenz von Modems kannte.

Stöpselte man den Kassettenplayer jedoch mit einem Klinkenkabel in den Computer und gab dort den Befehl „LOAD“ ein, so wurde aus dem Gepiepe ein Spiel oder ein Musikprogramm, oder was auch immer auf der Kassette gespeichert war. Jedenfalls war das das Tollste was man als Kind besitzen konnte. Und den jugendlichen Adrenalinschub bekam ich, als unter dem Weihnachtsbaum mein eigener Commodore C16 mit zugehöriger Datasette und der Spielekassette BigMac lag. Der Commodore C16 war also mein erster richtiger Computer. Es dauerte nicht lange, da waren die 16kB (KiloByte) Ram, die der C16 hatte zu wenig für die selbst gebastelten Basic Programme. Und was noch schlimmer war, es gab auch tolle Spiele, die mit 16k nicht liefen. Dazu gehörte der Kampfflugsimulator „ACE“ und das Vector-Grafikgame „MERCENARY“. Also musste der Computer aufgerüstet werden. Das war aus heutiger Sicht sehr einfach – es mussten lediglich zwei DRram Bausteine ausgelötet und gegen andere ersetzt werden. Damals jedoch, im Alter von – ich denke 11-12 Jahren, war das mangels geeignetem Lötwerkzeug und Erfahrung eine Herausforderung. Doch irgendwie hat es geklappt und der C16 meldete sich mit folgender Statuszeile:

COMMODORE BASIC V3.5 60671 BYTES FREE

READY

Das war im Vergleich zum originalen Speicher, von dem für den Basic Interpreter gerade einmal 12277 Byte frei verfügbar waren, ein Paradies an neuen Möglichkeiten. Leider war die Lebensdauer des Commodore 16 im Dauerbetrieb nicht sehr lange. Ich denke, es hat nicht mal ein Jahr gedauert, da zeigte der Rechner erste Probleme. Entweder reagierte der Cursor nicht mehr, es kamen wirre Zeichen am Bildschirm, oder er startete erst nach häufigem Aus- und wieder Einschalten. Irgendwann blieb der Bildschirm dann ganz schwarz.  Schuld daran war, zumindest vermute ich das heute, der Hitze Tod der CPU und/oder des TED IC´s. Damals konnte man diese Chips in den einschlägigen Elektronikläden noch für kleines Geld bestellen. Heute sieht das aber anders aus. Eine MOS7501 oder MOS8501 CPU findet man, wenn überhaupt, dann nur bei eBay und co. und das für Preise von 50 Euro und mehr für gebrauchte Chips.

MOS7501 (MOS8501) CPU der Commodore 264er Reihe

In meiner Sammlung besitze ich einige wenige Exemplare der 264er Serie von Commodore, die mehr oder weniger alle in einem originalen, einwandfreien Zustand sind (C16, C116, Plus4). Aber eben nicht alle. So habe ich mir in den Kopf gesetzt, die 8501 CPU in einen FPGA zu implementieren, eine kleine Platine zu entwerfen, die die Größe eines DIL40 IC´s hat und direkt in den CPU-Sockel des C16 bzw. Plus4 passt. Es existieren ja bereits einige erfolgreiche Projekte, die sich mit der Implementierung eines 8Bit CPU Core in einen modernen FPGA befassen.  Hier die Links:

Sellmy Retro: https://www.sellmyretro.com/offer/details/mos–7501~~8501-cpu-replacement-for-c16~~116~~%2B4-30475

oder ein universal konfigurierbarer CPU – FPGA Ersatz: https://hackaday.io/project/165624-mocka65xx-universal-650285xx-cpu-replacement

Ich habe mich aus Kostengründen und auf Empfehlung entschlossen, mit einem Lattice MACHXO FPGA zu arbeiten. Ein Evaluation Board ist für unter 30 Euro zu bekommen und für die Entwicklungsumgebung bekommt man bei Lattice eine gratis Lizenz. Einziger Nachteil – ich hatte bis dato keine Erfahrung mit Lattice Produkten. In meinen beruflichen Projekten wird hauptsächlich mit XILINX gearbeitet. Aber nach der Installation der Lattice-Software und ein bisschen Übung war schnell klar, damit sollte ich zurechtkommen.

LATTICE MACH XO Evaluationboard

 

Ich habe mir also vorgenommen, diesen Beitrag als dynamischen Beitrag zu gestalten und immer wieder zu erweitern. Da meine letzten FPGA Projekte wieder einige Zeit zurückliegen und ich mich auch wieder in die FPGA-Welt eingewöhnen muss, wird es wohl einige Zeit dauern bis (falls) ein brauchbares Ergebnis zustande kommt. Zu Beginn steht die Analyse des Datenblattes des MOS8501 IC und dessen Pins zur Außenwelt. Der 8501 ist eine abgeänderte Version des 6502 (die CPU aus dem Jahr 1975 die in vielen Rechnern eingesetzt wurde). Dazu zählen unter anderem der VC20, der Atari800, auch der APPLE 1 usw. arbeiteten mit dem 6502 Prozessor. Der 6502 ist auch schon als Verilog und VHDL Modell verfügbar… Diese Cores mit den Anpassungen für den 8501 will ich in den MachXO reinquetschen und mit entsprechender Anpassung der Signallevels direkt statt dem originalen MOS-Chip in das C16 Mainboard stecken…