SharpKey Multi-HID-Schnittstelle Firmware-Leitfaden

Ueberblick


Ein grosses Problem bei spaeteren Vintage-Sharp-Computern sind die Tastaturen. Aus verschiedenen Gruenden -- verloren, eingelagert oder von Sammlern gekauft -- wird eine grosse Mehrheit der MZ-2500/2800/3500/X1/X68000-Maschinen heute ohne Tastatur verkauft. Abgesehen vom X68000, den man noch einigermassen mit einem Joystick verwenden kann, ist die Maschine ohne Tastatur nur ein Briefbeschwerer. Verkaeufer wissen dies und solche, die zum Verkauf kommen, koennen GBP100-200 oder mehr kosten.

Einige einfallsreiche japanische Entwickler (classicpc.org, oder Youkan) und Martin bei 8bity.cz haben Schnittstellen entwickelt, um gaengige PS/2- oder USB-PC-Tastaturen fuer diese tastaturlosen Sharp-Maschinen zu konvertieren. Fuer den X1 und X68000 funktionieren diese Schnittstellen insgesamt einwandfrei. Das MZ-2500-Interface hat jedoch einige Probleme, nicht zuletzt basiert das verfuegbare Design auf einem ST-Entwicklungsboard und die Firmware ist Closed Source. Da ich eine zuverlaessig funktionsfaehige Einheit benoetigt habe, um meine MZ-2500/MZ-2800-Maschinen unter Renovierung fertigzustellen, musste ich andere Optionen in Betracht ziehen.

Der MZ-2500 verwendet eine nahezu identische Tastaturmatrix wie der MZ-80B, jedoch erweitert um zwei Zeilen und serialisiert ueber einen 4-Bit-Bus zwischen Haupteinheit und Tastatur. Die Haupteinheit sendet eine Zeile in 600nS und die Tastatur gibt die Tastendaten in 2 Nibbles zurueck, 300nS voneinander entfernt. So dauert 1 Zeile der Tastaturmatrix 1,2uS von der Tastatur zur Haupteinheit, wiederholt fuer 14 Zeilen in einer engen Schleife. Man muss also in der Lage sein, das Senden der Zeile durch die Haupteinheit (RTSN) zu erkennen, sie zu lesen und den Matrixwert fuer diese Zeile in weniger als 600nS nachzuschlagen.

Um die Anforderungen der Schnittstellenanbindung an einen MZ-2500/MZ-2800 zu verstehen, beschreibt der folgende Abschnitt die Hardware und ihr Protokoll im Detail.

MZ-2500 Tastaturprotokoll

Die Hardware-Schnittstelle umfasst 7 Signale, 5V und GND, unter Verwendung einer geschirmten 8-poligen Mini-DIN-Buchse und eines Steckers.

KeyboardPinout

RTSN, KD4, MPX sind Ausgangssignale der Haupteinheit. KD [3:0] ist ein bidirektionaler Bus zwischen Haupteinheit und Tastatur, Richtung unter Kontrolle der Haupteinheit mittels RTSN.
Signal Richtung Logikzustand Beschreibung
RTSN
Row Strobe
Main Unit -> Keyboard HIGH (‘1’) Eine Zeilenadresse wird von der Haupteinheit zur Tastatur uebertragen.
    LOW (‘0’) Die Tastatur uebertraegt angeforderte Daten ueber den 4-Bit bidirektionalen Bus KD[3:0].
KD4
Type Strobe
Main Unit -> Keyboard HIGH (‘1’) Die Tastatur muss die tatsaechlichen Matrixdaten zurueckgeben.
    LOW (‘0’) Die Tastatur muss ein logisches AND aller Tasten zurueckgeben.
MPX
Nibble MUX Strobe
Main Unit -> Keyboard HIGH (‘1’) Das obere Nibble wird von der Tastatur zur Haupteinheit gesendet.
    LOW (‘0’) Das untere Nibble wird gesendet.
KD[3:0]
Bi-dir bus
Main Unit -> Keyboard   Aktiv wenn RTSN = HIGH, uebertraegt die 4-Bit Zeilennummer.
  Keyboard -> Main Unit   Aktiv wenn RTSN = LOW, uebertraegt 4 Bits der 8-Bit Spaltendaten.


Es gibt zwei Hauptbetriebsmodi: einen Alle-Tasten-Test-Modus (STROBEALL), der wartet, bis eine Taste gedrueckt wird, gefolgt von einem manuellen Scan aller Zeilen, um die gedrueckte Taste zu lokalisieren.

Fuer den Datenabruf der Tasten ist das Protokoll wie folgt:

  1. RTSN geht auf aktiv HIGH und bleibt fuer 1,08us aktiv. Die anfaengliche RTSN-Periode ist 1,08us aktiv HIGH und 660ns inaktiv LOW. Danach ist die Periode einheitlich 660ns aktiv HIGH und 680ns inaktiv LOW.
  2. Die Hauptplatine sendet eine Scan-Zeile an die Tastatur, die 160ns nach der steigenden Flanke von RTSN gueltig wird.
  3. Die Scan-Zeile wird von der Tastatur in den verbleibenden 920ns von KD[3:0] gelesen. KD4-Zustand geht der steigenden Flanke von RTSN voraus.
  4. KD4 wird abgetastet; bei LOW wird das logische AND aller Tasten pro Spalte gesetzt, bei HIGH werden die tatsaechlichen Spaltendaten der ausgewaehlten Zeile gesetzt.
  5. Bei der fallenden RTSN-Flanke geht MPX fuer 320ns auf HIGH und das obere Nibble wird ausgegeben. Wenn MPX auf LOW geht, wird das untere Nibble ausgegeben.
  6. Das Obige wiederholt sich waehrend eine Taste gedrueckt wird.

Fuer den STROBEALL-Modus:

  1. KD4 wird LOW gehalten.
  2. RTSN hat eine gleichmaessige Periode, 660ns aktiv HIGH, 660ns aktiv LOW. 3-5. Wie oben, aber die Zeile wird ignoriert.

Die Signale koennen in den folgenden Logikanalysator-Diagrammen visualisiert werden:

MZ2500 Keyboard Protocol 1

Waehrend der Inaktivitaet sendet das Gatearray auf der Hauptplatine einen STROBEALL-Befehl.

MZ2500 Keyboard Protocol 2

Wenn eine Taste gedrueckt wird, wechselt KD4 auf HIGH und die Hauptplatine beginnt die Tastatur abzufragen, um die gedrueckte Taste zu ermitteln. Zuerst wird Zeile 11 abgefragt (Sondertasten: CTRL, SHIFT, LOCK, KANA, GRAPH).

MZ2500 Keyboard Protocol 3 MZ2500 Keyboard Protocol 5

Nach Zeile 11 wird Zeile 12 (japanische Transform-Tasten) gescannt, dann beginnt ein sequentieller Scan aller Zeilen ab Zeile 0.

MZ2500 Keyboard Protocol 6 MZ2500 Keyboard Protocol 4

Der sequentielle Scan wird fortgesetzt, bis die gedrueckte Taste gefunden wird (in diesem Fall ‘C’ auf Zeile 4, Spalte 3). Die Zeile wird ueber 600us gescannt, um Prellen zu erkennen.

Die vom MZ-2500 verwendete Hardware:

KeyboardHardware

Dieser Schaltplan zeigt die Tastaturschaltung mit einem Gate Array und einem bidirektionalen Puffer.

MainUnitKeyboardHardware

Dieser Schaltplan zeigt die Schaltung der Haupteinheit mit einem Gate Array, verbunden mit dem Z-80B PIO.

MZ-2800 Tastaturprotokoll

Der MZ-2800 ist der Nachfolger des MZ-2500. Sein Design enthaelt einen 8-Bit Z80-basierten MZ-2500-Modus und einen 16-Bit 80286-Modus. Er verwendet dieselbe Hardware-Schnittstelle aber ein anderes Protokoll mit unterschiedlichem Timing.

Signal Richtung Logikzustand Beschreibung
RTSN
Row Strobe
Main Unit -> Keyboard HIGH (‘1’) Zeilenadresse wird uebertragen.
    LOW (‘0’) Tastatur uebertraegt Daten.
KD4
Type Strobe
Main Unit -> Keyboard HIGH (‘1’) Tatsaechliche Matrixdaten.
    LOW (‘0’) Logisches AND aller Tasten.
MPX
Nibble MUX Strobe
Main Unit -> Keyboard HIGH (‘1’) Oberes Nibble.
    LOW (‘0’) Unteres Nibble.
KD[3:0]
Bi-dir bus
Main Unit -> Keyboard   4-Bit Zeilennummer.
  Keyboard -> Main Unit   4 Bits der Spaltendaten.

Das Protokoll ist aehnlich dem MZ-2500, mit Unterschieden im Timing und in der Art, wie Tasten abgefragt werden.

MZ2800 Keyboard Protocol 2 MZ2800 Keyboard Protocol 10 Timing Key Read MZ2800 Keyboard Protocol 9 MZ2800 Keyboard Protocol 1 MZ2800 Keyboard Protocol 7 MZ2800 Keyboard Protocol 6 MZ2800 Keyboard Protocol 4

Ein Unterschied zum MZ-2500 ist die Hinzufuegung einer 14. Zeile. Im MZ-2500-Modus wird Zeile 14 nicht gescannt.

Die Hardware des MZ-2800:

KeyboardHardware MainUnitKeyboardHardware


ESP-32S AI Thinker

Nach eingehender Analyse der Anforderungen wurde die Entscheidung getroffen, das Interface auf einem ESP-32S Dual-Core SoC mit FreeRTOS unter dem Espressif-Entwicklungssystem zu basieren. Ein Kern wurde von FreeRTOS abgekoppelt und laeuft in einer permanenten Endlosschleife zur Verwaltung der MZ-2500-Schnittstelle, waehrend der andere Kern PS/2-Codes liest und eine virtuelle Matrix aufbaut.

Das Interface verwendet ein KM-24-Gehaeuse, klein, kompakt und ordentlich.

Schaltplan

Das Design basiert auf dem ESP-32S WROOM, einem Dual-Core 240MHz WiFi/BT-faehigen SoC mit minimalen Stuetzkomponenten.

Schematic

Leiterplatte

PCB PCB Top View PCB Bottom View

Zusammengebautes Interface

Die Bilder unten zeigen das fertiggestellte, zusammengebaute und funktionsfaehige Interface.

1 1 1 1 1 1 1 1 1

Zusammengebautes MZ-2800 Interface

1 1 2 3 4 5 6 7 8

Firmware

Die Firmware ist unter dem Espressif IDF Build-System geschrieben, bestehend aus gcc(++), git, CMake und Ninja. Die Firmware ist in einer Mischung aus C und C++ geschrieben, wobei C++ die primaere Sprache ist.

Automatisiertes Setup und Build (empfohlen)

Der empfohlene Weg, die SharpKey-Firmware zu bauen, ist das in sich geschlossene Setup-Skript fuer Ihre Plattform. Es installiert die Toolchain (ESP-IDF v4.4), klont das Repository (mit Submodulen) und kann die Firmware bauen — alles interaktiv, mit sinnvollen Standardwerten, die Sie durch Druecken von Enter uebernehmen koennen. Jedes Skript ist in sich geschlossen: Kopieren Sie einfach die einzelne Datei fuer Ihre Plattform und fuehren Sie sie aus.

macOS / Linux / WSL — setup_SharpKey.sh

chmod +x setup_SharpKey.sh
./setup_SharpKey.sh
Das Skript erkennt das Betriebssystem automatisch und bevorzugt einen Docker-Build mit dem festgelegten espressif/idf:v4.4-Image (~3 GB einmaliger Download) — keine Host-Toolchain, ueberall identisch. Ist Docker nicht verfuegbar, faellt es auf eine native ESP-IDF v4.4-Installation zurueck (Python 3.8–3.11, CMake, Ninja usw. ueber apt/dnf/pacman oder Homebrew unter macOS). Unter Linux/WSL kann es Docker Engine fuer Sie installieren.

Windows 10 / 11 — setup_SharpKey_windows.ps1 (nativ — kein WSL, kein Docker). In einer PowerShell-Eingabeaufforderung (eine normale Benutzer-Eingabeaufforderung genuegt; winget fragt evtl. nach Erhoehung):

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_SharpKey_windows.ps1
Das Windows-Skript verwendet winget, um Git und — falls Ihr Standard-Python 3.12+ ist oder fehlt — Python 3.10 in einer isolierten venv zu installieren (Ihr eigenes Python bleibt unangetastet). Anschliessend klont und installiert es Espressifs native ESP-IDF v4.4-Windows-Toolchain und baut die Firmware. Erfordert den Microsoft App Installer (der winget bereitstellt).

Fragen, die das Setup stellt, und was zu tun ist. Jede Eingabeaufforderung hat einen sicheren Standardwert in Klammern — der Grossbuchstabe ist der Standard, sodass Druecken von Enter ihn uebernimmt.

macOS / Linux / WSL (setup_SharpKey.sh):

Eingabeaufforderung Standard Was zu tun ist
Install Docker Engine now? [Y/n] (nur Linux/WSL, falls Docker fehlt) Ja Enter, um Docker zu installieren (benoetigt evtl. sudo), oder n, um stattdessen die native ESP-IDF-Toolchain zu verwenden.
Install now? [Y/n] (fuer fehlende OS-Pakete / ESP-IDF) Ja Enter — installiert die fehlenden Werkzeuge ueber apt/dnf/pacman oder Homebrew; fragt evtl. nach sudo.
Repo URL [https://git.eaw.app/eaw/SharpKey.git] oeffentliches Repo Enter fuer das oeffentliche Repo oder eine andere URL einfuegen (z. B. ein privates Entwicklungs-Repo).
Install directory [~/SharpKey] (beim Klonen) ~/SharpKey Enter fuer ~/SharpKey oder einen Pfad eingeben.
Remove <dir> and re-clone? [y/N] (nur wenn dieses Verzeichnis ein anderes oder unvollstaendiges Repo enthaelt) Nein y nur, wenn Sie sicher sind; andernfalls N und ein anderes Verzeichnis waehlen.
Build the SharpKey firmware now? [Y/n] Ja Enter, um sofort zu bauen (verifiziert die Umgebung).

Windows (setup_SharpKey_windows.ps1):

Eingabeaufforderung Standard Was zu tun ist
Repo URL [https://git.eaw.app/eaw/SharpKey.git] oeffentliches Repo Enter fuer das oeffentliche Repo oder eine andere URL einfuegen.
SharpKey checkout directory [%USERPROFILE%\SharpKey] %USERPROFILE%\SharpKey Enter fuer den Standard oder einen Pfad eingeben.
Build the SharpKey firmware now? [Y/n] Ja Enter, um sofort zu bauen.
Fuer unbeaufsichtigte Laeufe respektieren beide Skripte Umgebungsvariablen-Ueberschreibungen: Setzen Sie SHARPKEY_REPO_URL, um das Repository ohne Nachfrage auszuwaehlen, und (macOS/Linux/WSL) setzen Sie SHARPKEY_BUILD auf docker oder native, um die Build-Methode zu erzwingen.

Ausgabe und Neu-Bauen. Ein erfolgreicher Build schreibt die Firmware nach build/main.bin (mit einer versionierten Kopie unter release/ unter macOS/Linux). Um spaeter neu zu bauen, ohne das Setup-Skript erneut auszufuehren:

# Docker (macOS / Linux / WSL)
docker run --rm -it -v "$PWD":/project -w /project espressif/idf:v4.4 idf.py build

# Native ESP-IDF (macOS / Linux)
. "$IDF_PATH/export.sh" && idf.py build

# Windows (native ESP-IDF, from a new PowerShell)
& "$HOME\esp\esp-idf-v4.4\export.ps1"; idf.py build

Build mit Docker

Eine Alternative zur nativen ESP-IDF-Toolchain-Installation ist das offizielle Docker-Image von Espressif. Dies erfordert nur die Docker-Installation -- die gesamte Toolchain laeuft im Container.
# Docker installieren
sudo apt update && sudo apt install -y docker.io
sudo systemctl enable docker && sudo systemctl start docker

# Repository klonen
git clone https://git.eaw.app/eaw/SharpKey.git
cd SharpKey
git submodule update --init --recursive

# Web-Dateisystem bauen
chmod +x build_webfs.sh && ./build_webfs.sh

# Firmware mit Docker bauen
docker run --rm -v $PWD:/project -w /project espressif/idf:v4.4 idf.py build
# Flashen und ueberwachen
docker run --rm --privileged \
    --volume /dev:/dev --volume /sys:/sys:ro --volume /dev/bus/usb:/dev/bus/usb \
    -v $PWD:/project -w /project \
    espressif/idf:v4.4 \
    idf.py -p /dev/ttyUSB0 build flash monitor

Kontinuierliche Integration (Jenkins)

Das SharpKey-Projekt verwendet Jenkins auf einem VPS, um die ESP32-Firmware bei jedem Push zum master-Branch automatisch zu bauen. Siehe die FusionX Entwicklerhandbuch Sektion fuer die vollstaendige Jenkins-Installationsanleitung.

Verwendung

Eine Tastatur ist eine Tastatur, richtig? Nun, nicht ganz, besonders wenn eine Tastatur eine andere imitiert!

MZ-2500 Keyboard MZ-2800 Keyboard Wyse KB-3926 Keyboard

Zuordnungstabelle – siehe englische Version fuer vollstaendige Tabelle.

Hot Key Modus
ALT+F1 MZ-2500 Tastaturzuordnung
ALT+F2 MZ-2000 Tastaturzuordnung
ALT+F3 MZ-80B Tastaturzuordnung

Beim Einschalten ist die Standardzuordnung auf MZ-2500 eingestellt.

Preise

Die Preistabellen finden Sie in der englischen Version – Stuecklistenpreise sind international einheitlich in GBP angegeben.


Danksagungen

Die Espressif IDF-Entwicklungsumgebung und ESP-32S-Referenzmaterialien wurden bei der Entwicklung dieses Tastatur-Interfaces verwendet.

Lizenzen

Dieses Design, Hardware und Software, ist unter der GNU Public Licence v3 lizenziert.

Ohne ausdrueckliche Genehmigung des Autors darf keine kommerzielle Nutzung erfolgen.

Hinweis zur Funkregulierung

Dieses Geraet enthaelt ein vorzertifiziertes ESP32-S Funkmodul (AI Thinker) im 2,4 GHz ISM-Band. Zertifizierungen auf Modulebene erstrecken sich nicht automatisch auf das Fertigprodukt. Es liegt in der Verantwortung des Erbauers, die Einhaltung aller geltenden Vorschriften sicherzustellen.