Gepard (Computer)
# Gepard (Computer)

Der Gepard ist ein von der Firma Gepard Computer produzierter Steckkarten-Rechner auf Basis der Motorola-68000-Prozessoren, eines selbst entwickelten Betriebssystems und Modula-2-Compilers. Die Namensgebung erfolgte aufgrund des Leistungsabstands des Rechners gegenüber anderen für den Privatanwender verfügbaren Maschinen Anfang der 1980er Jahre.

## Geschichte

Die Entwicklung beginnt in einer Zeit, in der
* der Adressraum von 8-Bit-Rechnern durch Fortschritte in der Speichertechnik (64 kiBit-DRAM) mit wenigen Chips ausgereizt war
* mit der Motorola 68000-CPU ein 16/32-Bit-Prozessor ohne die Einschränkungen der 8-Bit-Welt verfügbar war
* die verfügbaren Geräte mit dieser CPU (u. a. Apple Lisa, TRS-80 Model 16, HP 9826A, Fortune 32:16) für europäischen Interessenten schwer erhältlich und meist außerhalb der (privaten) finanziellen Möglichkeiten lagen
* viele Anwender einen Nachfolger für 8-Bit-Rechner wie den Apple II in Form eines offenen, modular ausbaubaren und komplett dokumentierten Systems suchten
* populäre 16/32-Bit-Rechner wie Amiga und Atari ST noch in weiter Ferne lagen
Nachdem mit der Entwicklung des Gepard-Rechners 1983 begonnen wurde, gründete sich 1984 die Gepard Computer GmbH & Co. KG mit Sitz in Oldenburg.
In der Vermarktung wurde hauptsächlich die Modularität und Schnelligkeit des Systems hervorgehoben, bei dem jeder Anwender in der Lage sein sollte, sich selbst den passenden Systemausbau zusammenstellen zu können.
Das Konzept des Steckkartenrechners war schon vorher bei 8-Bit-Rechnern verbreitet, hauptsächlich mit Z80-Prozessoren. Die etwa zeitgleich mit Gepard gegründeten Computermagazine mc und c’t stellten um 1984 eigene Steckkartenrechner mit 68000-CPU vor (MC68000 und c't68000), auch der NDR-Klein-Computer folgte diesem Trend.

## Hardware

Der Rechner besteht aus einzelnen Modulen im Format einer Europakarte, die auf einem passiven Bus mit bis zu 16 Steckplätzen zusammengesteckt werden. Als Busstecker wird ein dreireihiger 96-poliger Stecker nach DIN 41612 ("VG-Leiste") verwendet, dessen Belegung an den zur Entwicklungszeit verbreiteten ECB-Bus angelehnt, im Detail aber proprietär war. Lange Buskarten erforderten eine Terminierung der Daten- und Adressleitungen, wodurch ein Bussteckplatz belegt wurde.
Die Entwicklung der Hardware lässt sich in drei Phasen unterteilen:
* 1. Phase (ab 1983): Unselbstständiges 16-Bit-Subsystem für den Apple II. Der Gepard besteht neben dem Bus und Netzteil minimal aus Karten mit CPU 68000, RAM 128 kiB, ROM und Apple-Link ohne eigene IO. Als Host-Rechner ist ein für UCSD-Pascal ausgerüsteter Apple II (d. h. 48 kiB RAM + 16 kiB Zusatz-RAM, mindestens ein Diskettenlaufwerk) notwendig, der auch die Link-Karte zum Gepard aufnimmt. Gegen Ende der Phase wurde auch ein C64 als Host-Rechner unterstützt.
* 2. Phase (ab 1985): Selbstständiges 16-Bit-Kartenrechnersystem. Der Gepard arbeitet vollständig mit eigener Peripherie und besteht neben Bus und Netzteil minimal aus Karten mit CPU 68000/68010, RAM 256 kiB, ROM, Floppy-Controller, Multifunktionskarte und einer Video-Karte. In diese Phase fällt auch die Entwicklung vieler weiterer Steckkarten.
* 3. Phase (ab 1987): Host für 32-Bit-Subsystem: Mit Verfügbarkeit der Nachfolge-CPU 68020 wurden die Grenzen des 16-Bit-Busses deutlich überschritten, so dass die Fähigkeiten der CPU nur dadurch genutzt werden konnten, dass ein Kernrechner mit CPU und RAM auf eine gemeinsame Steckkarte gelegt wurde. Der Kartenrechner entwickelte sich in Richtung eines 32-Bit-Rechnerkerns mit umgebender 16-Bit-Peripherie.

### Steckkarten

| Karte | Beschreibung |
| CPU | CPU 68000 oder 68010 mit einstellbaren Takt 8..12 MHz |
| CPU32 | CPU 68020 mit RAM bis 4 MByte |
| ROM/Applelink | EPROM mit Bootloader und 8-Bit-Parallelbus zu Apple II |
| RAM | DRAM-Karte 128 kiB (16 × 64 kiBit) |
| RAM | DRAM-Karte 512 kiB (16 × 256 kiBit) |
| RAM | DRAM-Karte 1 MiB (32 × 256 kiBit) |
| RAM | DRAM-Karte 8 MiB (8xSIP 1Mx8) |
| SRAM/EPROM | Statisches RAM oder EPROM bis 512 kiB, bei reiner RAM-Bestückung Datenerhalt mit Akku möglich |
| Multifunktion | Tastatureingang (seriell), Timer (CTC), Echtzeituhr (RTC) mit Akku, 2× Gameport-Anschluss, 2× Digital-Analog-Umsetzer (DAC) 8 Bit mit Multiplexer für Audioausgänge und Tiefpassfiltersteuerung, 1× Analogkomparator für Audioeingang (Spannungsmessung mit sukzessiver Approximation in Verbindung mit einem der DAC), einkanaliger Audioverstärker für Lautsprecher |
| Seriell/Parallel | 2× Seriellport (jeweils zwischen Spannungs- und 20 mA-Stromschnittstelle umbaubar), 2× Ausgang Parallelport (Centronics) Varianten: Baudrateneinstellung per Jumper (bis Anfang Phase 2) Baudrateneinstellung per Software |
| Floppy-Controller | Anschluss von bis zu vier 5,25"- und 3,5"-Diskettenlaufwerken über den Shugart-Bus, Datenraten 128/256/512 kiBit/s, Unterstützung von Laufwerken mit Klappenschalter/Auswurfmechanik |
| Text-Video | 4 kiB RAM für Bilddaten (pro Zeichen 9 Bit Zeichenkode + 2 Bit Attribute) 8 kiB RAM als Zeichengenerator für 512 Zeichen Anzeigemodi bei Standardauflösung mit Fernseh-BAS-Signal: Textmodus 80 × 25 Zeichen mit 8 × 11 Pixel/Zeichen, Attribute high/low, normal/invers Grafikmodus 320 × 192 Pixel Pseudografikmodus über Zeichengenenerator: 640 × 275 Pixel |
| Grafik-Video | Grafik-Subsystem aus Basiskarte + GDP-Karten (siehe Beschreibung unten) |
| HD-Controller | Für MFM-Festplatten mit ST506-Schnittstelle |
| SCSI-Controller | Für SCSI-Festplatten, Scanner, u. a. |
| Maus/Trackball | Eingänge für zweiphasige Inkrementalgeber. Anschluss auch an den Gameport-Eingängen der Multifunktionskarte möglich, dort aber ohne Interrupt-Unterstützung. |
| Prototyp | Anschlussadapter für eigene Entwicklungen, enthält die Buslogik und Dekodierung von Adressbereichen |

### CPU

Aufgrund des asynchronen Datenbusses des 68000 ist der CPU-Takt zwar ein Bus-Signal, aber nicht relevant für andere Steckkarten. Jede Steckkarte steuert das Timing der Speicherzugriffe in eigener Zuständigkeit über Handshake-Signale und funktioniert so ohne Anpassung mit verschiedenen CPU-Takten.

### RAM

Mit fortschreitender Softwareentwicklung vergrößerte sich der Speicherbedarf für ein funktionales System auf etwa 1 MiB. Neben dem Einsatz als Hauptspeicher konnten RAM- und ROM-Karten auch als resetfeste RAM-Disk (unter GDOS) oder als Speicher für Codemodule (OS-9) verwendet werden. Letzteres unterstützt den direkten Start von Code aus einem ROM-Speicher, d. h. beim Start eines abgelegten Programms wird im Hauptspeicher nur Platz für die Datensegmente und den Stack benötigt, aber kein Platz für den Programmcode. Das ermöglicht auch einen Betrieb ohne Massenspeicher.
Zu klein gewordene RAM-Karten mit DIL-ICs konnten auf einfachem Weg in ihrer Kapazität verdoppelt und weiter sinnvoll eingesetzt werden, indem auf jedes RAM-IC ein baugleiches IC huckepack gelötet wurde. Dabei wurden alle Pins bis auf den Chip-Select-Eingang (CS) 1:1 verbunden, und die CS-Pins fliegend mit einer modifizierten Adressdekodierung verdrahtet. Ähnliche Umbauten gab es bei fast allen Rechnern dieser Zeit.

### Massenspeicher

Festplatten (MFM und SCSI) gehörten erst mit Phase 3 zur üblichen Ausstattung, in der Anfangszeit waren sie für den hauptsächlich privaten Anwenderkeis außerhalb der finanziellen Möglichkeiten. Daher bestand die Standardausstattung des Rechners ab Phase 2 aus mindestens einem Diskettenlaufwerk der Größe 3,5" von Sony.
Dabei kamen Laufwerke mit zwei Besonderheiten zum Einsatz:
* die doppelseitige Version mit 2 × 80 Spuren (im Gegensatz etwa zu Ein-Seiten-Laufwerken des späteren Apple-Mac) ergab zusammen mit einer Sektorgröße von 1 kByte und 5 Sektoren/Spur eine Kapazität von 800 kiB, was deutlich über allen bis dahin gängigen Diskettenformaten lag.
* die bis heute sehr seltene Variante des Diskettenlaufwerks mit doppelter Spindeldrehzahl (600/min anstatt 300/min) ermöglichte das Lesen und Schreiben von DD-Disketten mit 500 kiBit/s anstatt den üblichen 250 kiBit/s. Die damit erreichbare Netto-Datenrate von 30 kiB/s beim Lesen zusammenhängender Daten war bis zur Ablösung durch Festplatten ohne Konkurrenz.
Die Datenrate von Festplatten überstieg die mit der CPU realisierbare Transferrate zwischen HD-Controller und Hauptspeicher, die Prozessoren waren nicht schnell genug, um die Daten eines Sektors aus dem Controller abzuholen, bevor die Daten des nächsten Sektors bereitstanden, und den Controllern fehlten große Pufferspeicher, um die Daten einer kompletten Spur zwischenzuspeichern. Es war daher nicht möglich, alle Sektoren einer Spur wie bei Disketten innerhalb einer einzigen Spindelumdrehung in aufsteigender Reihenfolge zu lesen. Stattdessen wurden die Sektoren verschachtelt angeordnet -> siehe Interleave. Beim Gepard war ein Interleave-Faktor von 3 erforderlich.

### Grafik-Subsystem

Das Grafik-Subsystem ist ein Stapel aus Steckkarten, bestehend aus einer Basiskarte und 1 bis 8 darauf aufgesteckten Karten mit einem Grafik-Display-Prozessor (GDP).
Die Basiskarte stellt die Busverbindung her, steuert das Timing, enthält das Paletten-RAM (max. 256 aus einer Palette von 4096 Farben) und analoge und digitale Videoausgänge. Auf den GDP-Karten befinden sich jeweils 128 kiB RAM für die Bilddaten. Als GDP kommt der NEC µPD7220 zum Einsatz.
Auf der Basiskarte wird die Farbtiefe der Anzeige mit 1, 2, 4 oder 8 Farbbits pro Pixel eingestellt. Die GDP-Karten teilen sich die Erzeugung und Bearbeitung dieser Farbbits, d. h. jeder GDP trägt zur Farbinformation bei jedem Pixel mit 1, 2, 4 oder 8 Bit bei, wobei jeder GDP die gleiche Bitanzahl haben muss und die Gesamtanzahl der Bits die Einstellung auf der Basiskarte nicht überschreiten kann. Da das in 16 Bit organisierte RAM jedes GDPs zyklisch mit maximal 6 MiB/s ausgelesen werden kann, bestimmt die Anzahl der Farbbits pro GDP den maximal erreichbaren Pixeltakt. Die Höchstgrenze von 48 MHz Pixeltakt bei vollen 8 Bit Farbtiefe ist damit erst beim Vollausbau mit acht GDPs erreichbar (dann bearbeitet jeder GDP eine der planaren Bitplanes). Bei einer einzigen GDP-Karte ist der Pixeltakt von 48 MHz nur mit zwei Farben möglich und sinkt mit zunehmender Farbtiefe auf 6 MHz bei 256 Farben ab.
Die 128 kiB Bildschirmspeicher pro GDP reichen aus, so dass in keinem Modus eine Begrenzung der Auflösung aufgrund von Speichermangel notwendig wird. In vielen Modi wird weniger als die Hälfte der Speichergröße für die Anzeige benutzt, so dass es möglich ist, mehr als eine Bildschirmseite im Speicher der Videokarte zu halten.
Über die Basiskarte kann die CPU die GDPs einzeln ansprechen oder in beliebiger Kombination mehrere GDPs mit einem Zugriff gleichzeitig mit Kommandos versorgen. Die CPU hat keinen direkten Zugriff auf den Bildspeicher, alle Schreib- und Lesezugriffe auf die Bilddaten müssen durch oder über den jeweiligen GDP erfolgen. Nachteilig ist dabei die auf 8 Bit begrenzte Zugriffsbreite der CPU auf die GDPs, allerdings sorgt ein FIFO im Datenweg dafür, dass die CPU nicht auf die Ausführung jedes Kommandos warten muss.
Abhängig von der Bildschirmgeometrie können mit diesem Grafiksystem Videosignale bis zu einer maximalen Auflösung von etwa 1000 × 800 Punkten bei 35 kHz Zeilenfrequenz erzeugt werden.
Zu einer Zeit, in der Computer üblicherweise nur die Fernsehnorm zur Darstellung auf dem Bildschirm verwendeten und es das Produkt "Farb-Computermonitor mit hoher Auflösung" noch nicht gab, war es ein erheblicher Aufwand, ein zu diesem Subsystem adäquates Anzeigegerät zu finden. Erst mit der Verbreitung der EGA-Grafik für den IBM PC AT wurden entsprechende Monitore auch preislich erreichbar.

## Software

Richtungweisend für die Entwicklung des Gepard-Betriebssystems GDOS waren das auf dem Apple II verfügbare UCSD-Pascal sowie die zwischenzeitlich von Niklaus Wirth vorgestellte Neuentwicklung der Sprache Modula-2. Schwerpunkt der Entwicklung war dabei der Bau des Modula-2-Compilers, der in Assembler entwickelt wurde.

### Standard-Betriebssystem

Die Oberfläche des selbst entwickelten Betriebssystems war sehr eng an UCSD-Pascal angelehnt. Typisch ist dabei eine Systemmenüzeile am oberen Bildschirmrand und ein als "Filer" bezeichneter Dateimanager. Neu hinzu kam ein "Monitor" zur Bearbeitung von Speicherbereichen. Das als "GDOS" bezeichnete Betriebssystem wurde nach dem Konkurs der Firma Gepard Computer von mehreren Anwendergruppen, denen die Quelltexte zur Verfügung gestellt wurden, in divergierenden Richtungen weiterentwickelt. Diese Versionen wurden als "GDOS" oder "OS/Science" teilweise noch über Jahre weiter gepflegt.
Nur wenigen Programmen gelang eine weite Verbreitung, z. B. wurde das Spiel BOLO von Meinolf Schneider ursprünglich auf dem Gepard entwickelt.

### Alternatives Betriebssystem

Von dritter Seite wurde OS-9/68000 auf den Rechner portiert. Durch dieses unix-ähnliche Multiuser-Betriebssystem wurden Standardprogramme verfügbar, neben vielen auch heute noch üblichen Systemprogrammen auch Editoren wie Emacs und C-Compiler.
OS-9 war über Descriptoren sehr flexibel auf viele Diskettenformate einstellbar, auch das Lesen und Schreiben von FAT12-Disketten der aufkommenden MS-DOS-Rechner war mit geringem Aufwand möglich. Das OS-9-Standardformat (DD-Disketten mit einer SD-formatierten ersten Spur) wurde dagegen nicht unterstützt, was den Austausch mit anderen Systemen deutlich erschwerte. Solche gemischt formatierten Disketten sind auch heute nur mit Aufwand und historischer Hardware lesbar. Die Firma Cumana, die OS-9 auf den Atari ST portierte, wurde Namensgeber eines Diskettenformats mit 800 kiB, welches optimal auch zu den Laufwerken des Gepard passte.

### Anwendungen

Der Gepard-Computer wurde auch in der Forschung eingesetzt.

## Stückzahlen

Der Hersteller gab Ende 1985 eine verkaufte Stückzahl von 300 Systemen an.

## Benutzerunterstützung

Die Firma Gepard Computer verschickte in loser Folge einen Newsletter, in dem über den aktuellen Stand der Entwicklung informiert wurde. Käufer erhielten eine Adressliste von anderen Usern zum Erfahrungsaustausch, das wurde 1985 organisatorisch gefördert durch einen monatlichen Diskettenversand, bei dem sich jeder mit und ohne eigene Text- oder Programmbeiträge beteiligen konnte (Gepard Forum).
Eine ähnliche Einrichtung gab es für OS-9-Anwender (EFFO). Zeitschriftenartikel über das System erschienen z. B. in der 68000er, waren aber generell selten und wenig hilfreich.

## Schwächen und Produktionseinstellung

Der Leistungsabstand zu anderen Rechnern war am Anfang der Entwicklung noch gewaltig, schrumpfte aber im Zuge der technischen Entwicklung bereits bei Beginn der Phase 2 zusammen.
Als Vorsprung zu den aufkommenden Konkurrenzrechnern blieben länger erhalten:
* Hoher CPU-Takt
* Schneller Diskettenzugriff
* Modularität aller Systemkomponenten
* Sehr flexible Speicherkonfigurationen und konsequente Trennung von System- und Videospeicher
* Leistungsfähiges Grafiksystem
* Unter OS-9 multiuserfähig
Aber auch die Nachteile fielen zunehmend stärker ins Gewicht:
* Verwendung preiswerter 68xx-Peripheriebausteine (nur 8 Bit, 1 MHz Zugriffstakt, nur ein Auto-Interruptvektor für eine ganze Karte)
* Serielle Schnittstellen ohne FIFO, Baudrateneinstellung nicht durch Software, sondern nur durch Jumper
* Keine DMA, Audio-Prozessor und andere CPU-Unterstützungen für Audio und Video, obwohl Bus-seitig vorgesehen
* Die Hochfrequenzeigenschaften der Busplatine waren grenzwertig (nur zweiseitiges Layout, kein Multilayer). Nicht jede beliebige Kartenkombination war in jedem Steckplatz lauffähig, RAM-Karten funktionierten nur nahe der CPU stabil.
* Mitgeliefertes Betriebssystem ohne Multiuser- und Multitasking-Eigenschaften und ohne grafische Oberfläche
* Sehr teures Farbgrafiksystem
Die für das System maßgebliche Eigenschaft der kompletten Modularität wurde nur für einen relativ kurzen Zeitraum in der Phase 2 tatsächlich realisiert. In den späteren Phasen boten andere Rechner eine vergleichbare Ausbaufähigkeit und das System wurde für rein private Anwender gegenüber grafisch orientierten Rechnern und der aufkommenden IBM-Rechnerwelt zunehmend uninteressant; die Anwenderforen zerfielen.
Der Hersteller ging Ende 1986 in Konkurs.