Leonardo XL ISDN PCI

Sie werden den älteren Mac-Benutzern wohl bekannt sein: die Leonardo-ISDN-Karten der (inzwischen insolventen) Firma Hermstedt.

Durch Zufall entdeckte ich in einer eBay-Auktion eine Leonardo XL-PCI V1.3, die augenscheinlich einen 68000er enthielt. Das musste sofort untersucht werden!

Also flugs das Teil für ein paar Euro zusammen mit einer Pentium I-PC-Compatibility-Card für PowerMacs geordert und analysiert:

Leonardo XL-PCI V1.3

In diesem Bild sind die ISDN-Übertrager bereits heruntergelötet, um die Sub-D-Buchsen für andere Zwecke verwenden zu können. Ebenfalls wurde bereits ein Stück Präzisionssockel für J7 eingelötet, um das Config-EEPROM auslesen zu können und man kann das grüne Kabel sehen, dass den ehemals unbelegten Pin am Erweiterungsport mit dem Pin A23 des 68HC001 verbindet, um den gesamten Addressraum von 16MB am Erweiterungsport zur Verfügung zu haben.

Es handelt sich dabei um ein komplettes 68k-System mit folgenden Komponenten:

KomponenteFunktionBezeichnung auf der Karte
HAL-9001-MW-95FPGA für PCI-InterfaceIC1
AT17C65I²C-EEPROM (24Cxx-komp.) für FPGA-ConfigIC2
MC68HC001FN1616MHz-68000er mit 8/16-Bit BusIC3
KM681000BLG-72 Stk: 128kx16 SRAMIC4(ODD), IC5(EVEN)
MC68681FNDUART mit Quarz 3.686MHzIC6
PEB2086NISAC (ISDN-Controller)IC7, IC9
SAB82525NHSCX (SCC)IC8, IC10
grüne LEDeine grüne LED am Pin OP6 von IC6D25

Des weiteren verfügt die Karte über einen Erweiterungsbus, der dem PDS der älteren Macs ähnelt.

Soweit ich ihn ausgemessen habe, hat er die im folgenden Calc-Dokument hinterlegte Belegung:
Infos zur Leonardo XL-PCI V1.3

Dann hat sich mittels einer Sitzung mit PonyProg und einem fliegenden Aufbau der SI-Prog-Hardware das Config-EEPROM geöffnet und folgende Konfigurationsdatei ausgespuckt:

FPGA-Config-EEPROM als Binary
FPGA-Config-EEPROM als Textzeile

SI-Prog-Setup

Leider ist mir völlig unklar, um was für ein FPGA es sich hierbei handeln könnte und meine diesbezüglichen Anfragen an die Firma GAFICON, die in DE den Vertrieb für die Firma Pro2Col, den Aufkäufer von Hermstedt, übernimmt, blieben noch unbeantwortet.

Dann war es an der Zeit, mal ein bisschen mit der Software herumzuspielen. Die Originaltreiber bekommt man immer noch mittels der Wayback Machine von einem Backup der Hermstedt-Seite. Ich habe mir dann den Windows 95-Treiber heruntergeladen und mal entpackt. Es finden sich ein paar unwichtige Dateien, aber auch ein paar Binaries, z.B. die Dateien HermWAN.sys und LeoFW.bin.

Insbesondere der Name der letzten Datei hat bei mir heftigste Assoziationen hervorgerufen :-). Also mal im Hex-Editor angeschaut: In den ersten beiden 32-Bit-Worten stehen die Werte 0x400 und 0x4AC, wobei in der Datei ab 0x400 der Code losgeht. Wie man aus dem 68000-User-Manual weiß, sind das der Initial Program Counter und Supervisor Stack Pointer! Damit ist schon mal klar, dass diese Datei offensichtlich "unten" in das On-Board-RAM geladen und von dort direkt gestartet wird.

Ausserdem ist bekannt, dass an den Adressen von 0x8 bis 0x3FC die Exception Table steht. Sie liegt somit vollständig im RAM und kann daher bei Verwendung eigener Firmware beliebig verändert werden! Sehr praktisch...

Also habe ich die Firmware mal durch IDA Pro gejagt, und siehe da, man hat vor dem Hochladen des Treiber vergessen, die Debug-Symbole in der Firmware zu entfernen :-). Also ist es ein leichtes, die Funktionen zuzuordnen und ein kommentiertes Listing zu erstellen: Firmware-Disassembly

Ebenfalls der Windows-Treiber HermWAN.sys wurde nicht von den Debug-Symbolen bereinigt, sodass dieser ebenfalls gegenüber IDA Pro machtlos ist. Da es sich hierbei um x86-Code handelt, funktioniert sogar HexRays Decompiler, um Pseudocode zu erstellen :-).

Das Interessanteste an dem Windows-Treiber ist die Möglichkeit, mittels SoftICE, einem Windows-Debugger, sich dann beim Laden des Treibers beim Rechnerstart einzuklinken und mit einem Oszilloskop am Reset-Pin des 68HC001 zu schauen, was in welche Register geschrieben werden muss, um den Reset zu deaktivieren und den 68HC001 zu starten. Da der Reset-Pin auf den Erweiterungsport geführt ist, muss man dazu nicht mal an der Karte selbst rumlöten :-).

Reset-Untersuchung

So und mittels lspci von Linux findet man dann raus, dass die Karte 1MByte des PCI-Adressraums belegt und die Control-Register in den oberen 512kByte, genauer ab 0x80000 im Karten-Adressraum, liegen.

Damit lässt sich schon mal ein leodrv-Modul für den Linux-Kernel schreiben, dass beim Laden den Reset deaktiviert und beim Entladen ihn wieder aktiviert. Im Quellcode finden sich auch Angaben zu der genauen Position der Register.

Das ist im Moment der Stand der Dinge; weiteres folgt sobald wieder Zeit für dieses interessante Projekt vorhanden ist.