Kategorie-Archiv: Hardware

4 Bit Prozessor, Teil 3 – Hardwaresimulation

Es wird immer noch kein Lötkolben heraus geholt. Ich beginne damit, einzelne Teile zu simulieren. Da ich nur wenig Erfahrung mit dem Entwurf digitaler Schaltungen habe, ist nicht klar, ob die Teile auch so funktionieren wie sie sollen. Fehlersuche und Korrektur sind in der Simulation wesentlich einfacher als bei der echten Hardware. Und wenn sich eine Vorgehensweise als nicht realisierbar herausstellt, hat man weniger Verluste.

Als erste Übung – insbesondere zur Einarbeitung in das Simulationsprogramm – habe ich mit der Addition/ Subtraktion angefangen. Es gibt zwar eine komplette ALU als TTL Baustein, die ist aber nur schwer zu bekommen und deckt nur 90% meines Bedarfs ab. Deshalb habe ich mich entschlossen die ALU komplett selber aufzubauen.

Die 4 Bit Addition ist einfach, es gibt hierzu mit dem 74LS83 einen fertigen Baustein. Und mit geringen Zusatzaufwand kann man daraus auch eine Subtraktion machen. Hierzu muss man nur das zweite Eingabewort negieren (nicht einfach invertieren). Invertieren ist einfach mit XOR Gattern zu erreichen. Zum negieren muss aber dann noch eins abgezogen werden. Das geht aber auch überraschend einfach indem man das carry in ebenfalls invertiert (in diesem Rahmen auch als borrow zu bezeichnen). Zudem muss bei der Subtraktion dann auch noch das carry out invertiert werden.

Das scheint soweit zu funktionieren. Bei der Addition wird die Summe bei aktiven carry in um eins erhöht und bei einer Summer größer als 15 (F Hexadezimal) wird das carry out aktiv. Bei der Subtraktion wird die Differenz bei einem carry in (oder borrow) um eins erniedrigt und sobald der Wert negativ wird, wird carry out aktiv. Die weiteren Funktionen der ALU werde ich in der kommenden Woche simulieren, diese sind jedoch noch einfacher und sollten keine Probleme verursachen.

Mein zweiter Test nimmt das vier Arbeitsregister ins Visier. Sie benötigen einen input port zusammen mit einer zwei Bit Adresse zur Auswahl des Registers welches beschrieben werden soll und einen output port ebenfalls mit einer zwei Bit Adresse zur Auswahl des Ausgabewerts. Hier setze ich auf ein 74LS173 – ein 4 Bit flankengesteuertes Latch. Zur Unterstützung der Simulation habe ich noch einen 4 Bit counter zur Erzeugung des Eingabewerts sowie zwei 2 Bit counter zur Auswahl des Schreib- und des Leseports eingefügt.

Zum Lesen wird die Adresse des Registers über SelOut angelegt und die Leitung OutEna(ble) aktiviert. Im inaktiven Zustand sind alle Ausgänge der vier Register hochohmig. Erst mit der Aktivierung wird über einen 2 nach 4 Demultiplexer das gewählte Register freigeschaltet und gibt seinen Inhalt aus.

Das Schreiben funktioniert ähnlich. Es wird die Schreibadresse über SelIn angelegt und die Leitung InLatch aktiviert. Mit der steigenden Flanke wird dann der aktuelle Wert von DataIn in das gewählte Register übernommen. Alle anderen Register bleiben unverändert. Leider wird bei der Bildschirmaufzeichnung die Mausbewegung nicht mit gespeichert, deshalb kann man nur schlecht verfolgen, was passiert. Es wird zuerst eine 1 in das Register 0, 2 in Register 1, 3 in Register 2 und 4 in Register 3 geschrieben. Danach werden die Inhalte der Register 0 bis 3 nacheinander angezeigt.

Als nächstes müssen die Ausgänge des Registerblocks und des Akkumulators auf die ALU geschaltet werden sowie das Ergebnis der ALU Operation wiederum in den Registerblock eingespeichert werden. Das wird die Aufgabe für die nächsten Tage werden.

4-Bit Prozessor, Teil 2 – Assembler und Simulator

Wenn man sofort anfängt seine Ideen in Hardware zu realisieren, hat man große Probleme, wenn sich Teile der Gedanken als nicht realisierbar oder unpraktisch erweisen. Deshalb habe ich als allererstes einen Simulator mit eingebauten Assembler geschrieben.

Mein Assembler ist offensichtlich stark vom Z80 beeinflusst. Das ist die CPU mit der ich als Jugendlicher zuerst in Berührung gekommen bin. Allerdings gibt es ein paar Vorgehensweisen die erheblich von normaler Assemblerprogrammierung abweichen.

  1. Ein Label für ein Sprungziel steht immer alleine (abgesehen von Kommentaren) und wird durch ein Doppelpunkt abgeschlossen. Funktionen, die per Call aufgerufen werden, haben ein Label welches durch ein fn (für function) eingeleitet werden. Nur solche Labels können von beliebiger Stelle aufgerufen werden. Normale Label werden automatisch „Funktions-lokal“. Das heißt, dass man nicht darauf achten muss, dass alle internen Sprungziele unterschiedliche Namen bekommen. Es ist also erlaubt, dass das Label „loop:“ in mehreren Funktionen verwendet wird und der Assembler verwendet dann jeweils die lokale Version.
  2. Da Label eindeutig durch einen Doppelpunkt gekennzeichnet werden, können OpCodes direkt in der ersten Spalte beginnen. Es ist nicht notwendig mit einem TAB anzufangen – aber es ist erlaubt.
  3. Alle Werte sind Hexadezimal.
  4. Da es keinen Linker gibt, wird auch unterschiedliche Code- und Datenbereiche verzichtet. Es gibt den Pseudobefehl org zur Festlegung des Startpunkts der nachfolgenden Befehle und eine data Anweisung welche nachfolgende Speicherinhalte kennzeichnet.
  5. Push und Pull Befehle gibt es nicht pro Register, sondern es gibt jeweils einen Befehl und dazu eine Registerliste mit den betroffenen Registern.

Der Simulator ist als JavaFX Anwendung realisiert. Er lädt direkt die Assemblerdatei und erzeugt daraus den Maschinencode, löst alle absoluten und relativen Sprungadressen auf und initialisiert den Speicher und die internen Register.

Load: öffnet einen Dateiauswahl Dialog welcher auf die Extension .zw4 voreingestellt ist. Es wird jeweils das zuletzt verwendete Verzeichnis voreingestellt. Falls es eine Funktion mit dem Label main: gibt, wird der PC im Simulator so voreingestellt, dass diese direkt ausgeführt wird.

Reload: lädt die aktuelle Datei neu. Es gibt keinen eingebauten Editor, zum Bearbeiten der Assemblerdatei muss ein externer Editor verwendet werden. Es reicht dann, nach einer Änderung, ein Speichern im Editor (er muss nicht geschlossen werden) und ein Klick auf Reload aus um den Simulator zu aktualisieren.

Quit: beendet den Simulator.

Step: liest den aktuellen PC und führt den nächsten Befehl aus. Der PC kann im User Interface zu beliebigen Zeiten geändert werden und der neue Wert wird beim nächsten Step verwendet. Das ist hilfreich, wenn man im Programm ein paar Schritte zurückspringen möchte, oder um sich aus einer toten Schleife zu befreien. Auch die übrigen Eingabefelder werden beim weiteren Programmablauf verwendet wenn sie manuell verändert wurden. Während des Programmablaufs wird das Textfenster mit dem Assemblercode automatisch aktualisiert, so dass der aktuelle Code sichtbar bleibt.

Run und Stop: führt das Programm aus bis es auf einen Breakpoint trifft oder mit Stop angehalten wurde. Einen Breakpoint kann man setzen indem man in der Programmliste auf die Adresse der jeweiligen Zeile klickt. Das Addressfeld wird dann in Folge rot angezeigt. Durch einen weiteren Klick wird der Breakpoint wieder gelöscht.

Funktions: diese Drop Down Box enthält eine Liste aller definierten Funktionen. Durch Anklicken wird der PC mit der jeweiligen Adresse initialisiert und die Assembleranzeige so gescrollt das diese Stelle sichtbar ist.

Registerliste: hier werden alle internen Registerwerte angezeigt. Die Registerwerte können auch manuell geändert werden und diese Werte werden dann beim nächsten Step verwendet. Umgekehrt werden die geänderten Werte nach dem Step angezeigt. Diese Liste wird auch im Run Modus aktualisiert, eine manuelle Änderung während des Programmlaufs ist deshalb praktisch unmöglich, da die Liste im Millisekunden Rahmen aktualisiert wird.

Speicheranzeige: der Simulator zeigt ein Speicherfenster von 256 Digits an. Die Startadresse kann frei eingestellt werden. Diese Anzeige wird auch während des Programmlaufs aktualisiert. Eine manuelle Änderung ist nicht vorgesehen.

Assembleranzeige: hier wird der Programmcode angezeigt. Die Stelle des aktuellen PCs wird markiert und bei Bedarf das Fenster so gescrollt, dass sie sichtbar ist. Die Anzeige wird auch während eines Programmlaufs mit Run aktualisiert. Falls der Assemblercode Fehler enthält, werden diese ebenfalls hier in der jeweiligen Codezeile angezeigt.

In einem ersten Schritt wird der Simulator dazu verwendet sich selber zu debuggen. Hierzu habe ich verschiedene kleine Assemblerfunktionen geschrieben, die die einzelnen Befehle aufrufen und prüfen, ob das gewünschte Ergebnis erzielt wurde. Im Augenblick habe ich ca. ein Viertel der Befehle getestet und dabei mehrere Abweichungen zwischen dem generierten Maschinencode und der simulierten CPU gefunden. An dieser Stelle sind Korrekturen jedoch viel einfacher als wenn sie erst auffallen nachdem die Hardware zusammengelötet wurde.

Aktuell umfasst der Simulator ca. 65 kB Programmcode. Es sind aber noch ein paar Erweiterungen geplant, wie z.B. die Unterstützung von Makros. Zudem wird der Assemblercode nur rudimentär auf Fehler geprüft. Hier muss auch noch weiterer Aufwand getrieben werden.

4-Bit Prozessor, Teil 1 – Projektbeschreibung

Wie viele aus meiner Generation habe ich oft darüber nachgedacht einen eigenen Prozessor zu implementieren. Das hat keinen praktischen Nutzen, es geht lediglich darum eine Vielzahl von Techniken zu erlernen. Man muss sich einen sinnvollen Befehlssatz überlegen, die notwendigen Entwicklungswerkzeuge implementieren, eine Prozessorarchitektur entwerfen und letztendlich das Teil auch tatsächlich realisieren. Die ersten Schritte sind für mich als Softwareentwickler relativ einfach. Der letzte Teil ist für mich die größte Herausforderung. Ich kann im Augenblick noch nicht absehen, wie weit ich tatsächlich komme und das Projekt wird sicherlich eine Weile dauern.

Ich habe mich für einen 4-Bit Prozessor entschieden damit die Hardware möglichst überschaubar bleibt. Da er am Ende ohnehin keinen sinnvollen Nutzen hat, ist es auch egal wie leistungsfähig er ist. Hauptsache ist, dass er läuft.

Der Befehlssatz ist an eine RISC Architektur angelehnt. Das heißt, es gibt logische und arithmetische Funktionen nur auf den Registern, keine direkte Speichermanipulation. Es ist aber kein echter RISC Befehlssatz, da ich variable lange Befehlssequenzen habe. Um die Codewörter möglichst kurz zu halten, habe ich zwei Beschränkungen gewählt. Zum einen gibt es nur vier Register (zwei Bit für die Registercodierung) und zum anderen wird mit einem Akkumulator gearbeitet, der bei Zwei-Operanden Befehlen implizit verwendet wird. Die meisten (alle?) Ein-Operanden Befehle können aber auch auf den Registern ausgeführt werden.

Im Überblick eine bullet point Liste mit den geplanten Eigenschaften:

  • 4 Bit Operationen (im Wesentlichen)
  • Von Neumann Architektur
  • 4 Register plus Akkumulator
  • 2 Indexregister
  • 1 Stackpointer
  • 12 Bit Adressen für PC, SP, Indexregister
  • 1 8 Bit Zero Page Register, analog zum Direct Page Register im 6809, 4 Bit Offset bei Verwendung
  • Befehlslänge 2 bis 5 Digits, jeweils 4 Bit
  • …

Die Anzahl der Adressierungsarten ist aus Gründen der einfachen Hardware beschränkt.

  • Immediate – nur für Ladevorgänge
  • Absolute – Laden, Speichern und Sprünge (Jump und Call)
  • PC Relative – nur für Branch, mit Condition Code, 8 Bit signed offset
  • ZP Relative – Laden und Speichern, 4 Bit lower digit (ZP liefert die oberen 8 Bit)
  • Indexregister – nur Laden und Speichern
  • Register – Register Transfer

In einem ersten Schritt wird ein Assembler für den geplanten Befehlssatz und ein Simulator zur Ausführung entwickelt. Die Ausführung im Simulator hat den Vorteil, dass man viel schneller prüfen kann, ob der Befehlssatz sinnvoll eingesetzt werden kann. Zudem sind Testdurchläufe viel schneller auszuführen und ein debugging des Verhaltens wesentlich einfacher.

Der Befehlssatz sieht vorläufig so aus:


00rr 0000 o1        ld R1..4 zero page 4 bit offset
00ix 0001 o1        ld IX1 IX2 A ZP 4 bit offset
00rr 0010           ld A from R1..4
0000 0011 v1 v2     ld ZP imme 8 bit value
0001 0011 v1        ld A imme 4 bit
0010 0011           ld ZP low digit from accu
0011 0011           ld ZP high digit from accu
00rr 0100 v1 v2 v3  ld R1..4 from abs address
00ix 0101 v1 v2 v3  ld IX1 IX2 A SP from abs address
00rr 0110 v1        ld R1..4 imme 4 bit value
00ix 0111 v1 v2 v3  ld IX1 IX2 SP ZP 12 / 8 bit imme value
00rr 1000           ld R1..4 from [IX1]
00rr 1001           ld R1..4 from [Ix2]
00rr 1010
00rr 1011

01rr 0000 o1        st R1..4 zero page 4 bit offset
01ix 0001 o1        st SP IX1 IX2 zero page 4 bit offset
01rr 0010           st A to R1..4
01?? 0011
01rr 0100 v1 v2 v3  st R1..4 to abs address
01ix 0101 v1 v2 v3  st IX1 IX2 A SP to abs address
01?? 0010
01?? 0011
01rr 1000           st R1..4 to [IX1]
01rr 1001           st R1..4 to [Ix2]
01rr 1010
01rr 1011

1000 d1 d2 d3       jmp 12 bit address
1001 d1 d2 d3       call 12 bit address
1010 cc d1 d2       bra 8 bit signed offset
1011 ????

11rr 0000           add
11rr 0001           sub
11rr 0010           addc
11rr 0011           subb
11rr 0100           and
11rr 0101           or
11rr 0110           xor
11rr 0111           inc R1..4
11rr 1000           dec R1..4
11ix 1001           inc IX1 IX2 A ZP
11ix 1010           dec IX1 IX2 A ZP
1100 1011           not A
1101 1011           neg A
1110 1011           stc set carry
1111 1011           clc clear carry
11rr 1100           cmp
11?? 1101
1100 1110 m1 m2     push m1 mask R1..4, m2 mask IX1 IX2 A ZP
1101 1110 m1 m2     pull
1100 1111           clr A
1101 1111           
1110 1111           ret
1111 1111           nop

Im Augenblick sind ca. 200 von den 256 möglichen Codewörtern belegt. Aber es werden vermutlich noch ein paar Befehle hinzu kommen. Da geplant ist, die Ausführung über einen Microcode Sequenzer zu steuern, ist es aus technischen Gründen nicht besonders wichtig, dass der Code möglichst symmetrisch ist – das ist eher eine Frage der Ästhetik. Die Befehle werden alle durch die beiden ersten Digits bestimmt, die nachfolgenden 0 bis 3 Digits sind dann nur noch Parameter, wie z.B. Adressen oder Offset Werte. Das Microcode ROM wird einfach 256 Einsprungpunkte erhalten. Die beiden letzten Aktionen einer Sequenz bestehen darin, die beiden Codeteile für den nächsten Befehl in das Code Register zu laden.

Nach einem Reset wird das Code Register mit dem jmp Befehl (1000 1101) und der Program Counter mit ffe initialisiert. Der Microcode dazu lädt dadurch den Startpunkt für das Programm aus der Adresse ffd aus (die letzten drei Digits) und springt an diese Adresse.

Vermutlich wird es im Laufe des Projekts hier noch die eine oder andere Änderung geben. Es ist halt ein Lern- und Forschungsprojekt welches nicht vorab vollständig geplant werden kann.

Ein 6809 Minimalsystem

Als der 6809 veröffentlicht wurde, war die Begeisterung groß, auch bei mir. Da ich mit dem Eurocom 1 ein 6802 (nicht 6502) System hatte, war ohnehin eine gewisse Nähe gegeben. Ich wollte unbedingt so ein System haben.

Allerdings waren sie in der Anfangszeit kaum zu bekommen und wenn doch, dann viel zu teuer. Als Student habe ich mir dann Anfang der 80er eine 6809 CPU gekauft und wollte damit ein System analog zum 6809 aufbauen. Allerdings hatte ich konkurrierend auch ein Z80 CP/M System aus Fertigplatinen aufgebaut und auch viel Software dazu, die ich für den 6809 nicht bekommen hätte (oder eben auch wieder viel zu teuer). Deshalb ist das Projekt eingeschlafen und hat mehr als 40 Jahre in der Bastelkiste geschlummert.

Anfang des Jahres ist mir die CPU beim Aufräumen wieder in die Finger gefallen und ich habe beschlossen, dieses Projekt endlich mal anzugehen. Nicht als dauerhaftes System, sondern als ein einfacher Breadboard Computer um mal ein wenig mit dem 6809 zu spielen.

Glücklicherweise ist das heute viel einfacher als vor 40 Jahren. Man muss nicht für jeden Versuch ein EPROM brennen und in das System einstecken. Ich habe einen Arduino Nano verwendet, der bei Bedarf die 6809 CPU in den Halt Zustand versetzt und dann direkt auf einen RAM Baustein zugreift. Das ganze System besteht (abgesehen vom Arduino) und aus der CPU, einem 32k RAM Baustein, einem Adressdekoder und einem Multiplexer. Dieser wurde notwendig, da der 6809 das E Signal, welches für den Speicherzugriff benötigt wird, im Halt Zustand nicht hochohmig macht. Der Arduino ist über eine serielle Verbindung mit dem PC verbunden auf dem ein spezielles Terminalprogramm läuft welches den RAM Bereich schreiben und lesen kann. Allerdings wäre der Zyklus Edit – Assemble – Upload – Test immer noch recht aufwändig wenn man die ersten Schritte auf einem neuen System macht. Der Test auf dem Breadboard wäre auch umständlich, da man kaum Logging- oder andere Ausgabemöglichkeiten hat.

Aus diesem Grund habe ich mir auch einen 6809 Simulator besorgt. Hier kann man die ersten Programme im Single Step oder mit Breakpoints ausprobieren, die Registerinhalte untersuchen oder Speicherbereiche anzeigen lassen. Wenn eine Funktion dann lief, habe ich sie auf den 6809 übertragen und geprüft, ob sie auf der realen Hardware auch noch korrekt ausgeführt wird.

Ich habe so ein rudimentäres Monitor System entwickelt, welches über eine Software-Interrupt Schnittstelle Funktionen wie Textausgabe, Texteingabe, Datei öffnen, lesen, schreiben und schließen zur Verfügung stellt. Kein komplettes Betriebssystem, aber mit zusätzlichen Aufwand hätte ich dorthin kommen können. Da es aber ohnehin kein dauerhaftes Projekt sein sollte, wollte ich auch die Zeit dafür in Grenzen halten.

Auch hier stellt sich die Frage: wohin führt das Projekt. Und wieder die Antwort: nirgendwo hin. Es macht mir Spaß, mal mit einem System zu arbeiten bei dem man jedes Bit unter Kontrolle hat und das man bis in den letzten Winkel verstanden hat. Aber im praktischen Einsatz ist es mir dann doch zu reduziert. Zudem – ich bin in der Z80 Assembler Welt groß geworden. Damit ist mir der extrem reduzierte Registersatz einfach zu wenig. Die Zero Page (oder Direct Page beim 6809) ist ein kleiner Trost, löst letztendlich aber eine Vielzahl von Memory read/ write Zugriffen aus. Beim 6809 kann man relativ gut mit lokalen Variablen auf dem Stack arbeiten, aber auch diese lösen Memory Zugriffe aus. Für seine Zeit war der 6809 sicherlich ein gutes System. Allerdings kam er viel zu spät – zu diesem Zeitpunkt waren die bereits die ersten 16 Bit CPUs auf den Sprung in den Massenmarkt – und er war leider auch nicht besonders schnell. Gut im Vergleich mit anderen 8 Bit CPUs aber deutlich langsamer als die 16 Bitter.

Mein Eurocom 1 lebt wieder

Meine ersten Kontakte zu einem Computer waren in einem VHS Kurs. Der Kursleiter hatte einen Nascom 1. Im Rahmen des Kurses wurden grundlegende Programmierkonzepte gezeigt und der Z80 Befehlssatz erklärt. Wenn man etwas Glück hatte, konnte man auch einmal ein Programm mit dem Hex Monitor eintippen.

Für mich als Schüler war der Nascom zum teuer, aber einen Eurocom 1 für 350 DM konnte ich mir leisten.

Das Netzteil musste selber zusammen gelötet werden, es kam als ein Bausatz. Die CPU Platine mit Hex Tastatur und 7-Segment Display kam fertig aufgebaut an.

In den kommenden Wochen habe ich das Handbuch x-mal durchgelesen. Zu diesem Zeitpunkt kam das Monitorprogramm noch mit einem ausführlich kommentierten Listening. Ich habe mich so intensiv damit beschäftigt, dass das Handbuch im Laufe der Zeit komplett auseinander gefallen ist und die Hex Tastatur so ausgeleiert war, dass man kaum noch damit arbeiten konnte.

So etwa 1980 hat mein Vater dann einen Nascom 2 als Familiencomputer angeschafft. Tatsächlich habe vorwiegend ich damit gearbeitet, mein nächst-jüngerer Bruder auch eine Zeit lang. Der Rest der Familie hat sich nicht so sehr dafür interessiert. Dieser Rechner mit ASCII Tastatur, Bildschirmausgabe und Basic war dann viel interessanter, der Eurocom 1 geriet in Vergessenheit. Das Netzteil habe ich für andere Projekte zweckentfremdet, die Eurocom 1 Platine aber zum Glück aufgehoben.

Sie lag in einer Bastelkiste bis sie mir vor ein paar Jahren mal wieder in den Sinn gekommen ist. Ich bin aber davon ausgegangen, dass nach über 40 Jahren die EPROMS keine Daten mehr enthalten und habe nichts weiter unternommen. In diesem Jahr habe ich ein 6809 Projekt gestartet, welches ich ähnlich wie den Eurocom 1 aufbauen wollte (es ist dann aber anders gekommen, ein richtiger Assembler ist schon angenehmer als eine Hex Eingabe von Maschinensprachbefehlen). Das hat dann den Anreiz gegeben, einen Versuch zu starten, den alten Computer wiederzubeleben.

Als erstes benötigte ich ein neues Netzteil. Der Eurocom 1 verwendet 2708 EPROMs, die brauchen 3 Versorgungsspannungen (+5V, +12V und -5V) und diese müssen auch in einer bestimmten Reihenfolge anliegen. Zum Glück gibt es im Handbuch einen Schaltplan zum Originalnetzteil und dort habe ich gesehen, dass sich Eltec nicht viele Sorgen um diese Reihenfolge gemacht hat. Es reicht offensichtlich, dass sie ungefähr gleichzeitig anliegen.

Interessanterweise habe ich in meiner Sammlung auch noch den alten Original-Trafo gefunden. Die -12V werden vermutlich nur für die RS 232 Schnittstelle benötigt, der Vollständigkeit halber habe ich aber alle 4 Spannungen, wie im Original, aufgebaut.

Nächster Schritt: Eurocom 1 Platine anschließen und sehen, ob er noch etwas sagt. Das war zuerst enttäuschend, das Display blieb dunkel. Aber ein wenig Rumdrücken auf der Platine hat gezeigt, dass es sich nur um einen Wackelkontakt handelt. Also auf alle Sockel etwas Kontaktreiniger gesprüht und anschließend die gesamte Platine mit Isopropanol gereinigt. Jetzt kam zumindest schon mal die „Eurocon Control“ Meldung (ein m ist mit einem 7 Segment Display nicht darstellbar).

Weiter ging es mit der Tastatur. Sie ist ein den 40 Jahren nicht besser geworden. Viele Tasten hatten gar keine Funktion mehr und die verbleibenden haben so stark geprellt, dass man sie auch nicht mehr verwenden konnte. Zudem hat sich die Kombination von Kleber und Hautfett über die Jahre zu einer dunklen Masse entwickelt. Mein erster Plan war, die Tasten gegen neue zu ersetzen. Allerdings hatte ich keine mit einem identischen foot print. Also mussten die vorhandenen wieder Instand gesetzt werden.

Zum Glück konnte man die Tasten relativ leicht öffnen. Der Kontakt war ein einfacher Neusilber-Draht und eine winzige Tellerfeder. Beides konnte ich mit etwas Geduld wieder reinigen und die Tasten wieder zusammensetzen. Das größte Problem bestand darin, die noch winzigere Feder richtig zu platzieren ohne, dass sie wegspringt. Eine ist entkommen, jetzt ist die Taste „Y“ ohne Funktion.

Die alte Beschriftung war einfach eine Folie mit Laser-Drucker Beschriftung. Diese habe ich entfernt, die Tastenkappen gereinigt und eine neue Beschriftung ausgedruckt.

Wie geht es weiter: ich fürchte – erst mal gar nicht. So viel Spaß die Erinnerung an alte Zeiten bringt, ich möchte so reduziert nicht mehr arbeiten. Der Eurocom 1 wird wieder in einer Bastelkiste verschwinden – diesmal aber mit Netzteil – und darauf warten, dass ich irgendwann doch wieder Lust darauf bekomme.

Test eines einfachen Ultraschall Sensors für 80 Cent

In diesem Video teste ich einen einfachen Ultraschallsensor, der bei Aliexpress gerade mal 80 Cent kostet. Die Ansteuerung ist sehr einfach und schnell (wenn man keine unnötigen Fehler macht) und die Ergebnisse sind erstaunlich gut.

#include <Arduino.h>

const int TRIG_PIN = 12;
const int ECHO_PIN = 13;
const int ITEM_COUNT = 50;

long simpleMultiMeasure();

void setup() {
  Serial.begin(9600);
  pinMode(TRIG_PIN,OUTPUT);
  digitalWrite(TRIG_PIN, LOW);

  pinMode(ECHO_PIN,INPUT);
}

void loop() {
  long duration = simpleMultiMeasure();
  long distanceMm;
 
  // convert the time into a distance
  distanceMm = duration * 100l / 582l;
 
  if (distanceMm <= 0)
  {
    Serial.println("Out of range");
  }
  else 
  {
    Serial.print(duration);
    Serial.print(" ticks, ");
    Serial.print(distanceMm);
    Serial.print(" mm");
    Serial.println();
  }
  
  delay(500);
}

long simpleMultiMeasure() {
  long sum = 0;

  for (int i = 0; i < ITEM_COUNT; i++) {
    digitalWrite(TRIG_PIN, HIGH);
    delayMicroseconds(20);
    digitalWrite(TRIG_PIN, LOW);
    sum += pulseIn(ECHO_PIN,HIGH);
    delayMicroseconds(20000);
  }

  return sum / ITEM_COUNT;
}

Ein computergesteuerter Messplatz mit einem ESP 32, Teil 2

In diesem zweiten Teil wird die Software zu dem Projekt beschrieben. Sie besteht aus drei Teilen.

  1. Ein Platform IO Projekt mit einem C++ Programm welches auf dem ESP32 läuft.
  2. Ein Netbeans Projekt in Java welches auf dem PC ein Framework zur Verwendung des Messplatzes zur Verfügung stellt. Weiterhin enthält es einen komfortablen Weg zur Erstellung von CSV (comma separated values) Dateien.
  3. Ein Netbeans Projekt welches die Verwendung der DataIO jar Datei zeigt.
DataIO-ESP32-ProjectHerunterladen
DataIO-NetbeansHerunterladen
ADDATest-JavaHerunterladen

Ein computergesteuerter Messplatz mit einem ESP 32, Teil 1

Wenn man umfangreiche Messreihen aufnehmen will, ist es kaum manuell durchführbar. Ich verwende einen ESP 32 und verschiedene I2C Module für diese Aufgabe. Der Messplatz verfügt über 4 Analogeingänge mit 15 Bit Auflösung, 4 Analogausgänge mit 12 Bit Auflösung und 32 Digital Ein- und Ausgänge.


Der erste Teil beschreibt die Hardware. In einem kommenden zweiten Teil wird die Software dazu gezeigt.

Vintage Computer der 70er und 80er Jahre

In diesem Video zeige ich die Computer mit denen ich in den 70er und 80er Jahren gearbeitet habe. Da ich zu alt für ZX80 und C64 bin, tauchen hier weniger bekannte Namen wie Eurocom 1 und Nascom 2 auf. Es endet mit dem Atari 520ST, den ich bis in die späten 80er verwendet habe.

Eine 1 Bit ALU aus Relais – Teil 1 bis 3

Ich wollte schon längere Zeit mal eine Schaltung aus Relais aufbauen. Im Internet gibt es viele Beispiele für unterschiedlich komplexe Projekte bis hin zu einer kompletten CPU.

So weit wollte ich nicht gehen, ich bin mit der ALU (der zentralen Recheneinheit) zufrieden. Und die ALU ist auch nur 1 Bit breit. Aber sie kann Addieren (mit Carry) und die logischen Operationen AND, OR und XOR ausführen. Ein externer Sequencer, der die ALU verwendet könnte mit zusätzlicher Logig weiterhin eine Subtraktion, Negation oder Inversbildung durchführen.

 

Aus den Funktionen der 1 Bit ALU lassen sich dann komplexere Funktionen aufbauen: 16 AND, OR, XOR und ADD sowie zusätzlich SUB (aus XOR und ADD) sowie MUL (aus ADD).

Die Steuereinheit wird nicht aus Relais aufgebaut – hier wird ein Arduino Nano eingesetzt.

Und zum Schluss noch ein Z8000 Simulator welcher die ALU für seine Rechenoperationen verwendet.