Startseite » Homepage

Ohio Scientific C2

Der Ohio Scientific Challenger II, meist kurz C2 genannt, erschien zwischen 1977 und 1979 als konsequente Weiterentwicklung der populären Superboard-Serie des US-amerikanischen Herstellers Ohio Scientific Instruments (OSI). Das Unternehmen, gegründet 1975 im Bundesstaat Ohio durch den Ingenieur Michael Cheiky, seine Frau Charity Cheiky sowie den Techniker Dale A. Dreisbach, hatte sich zum Ziel gesetzt, erschwingliche, aber leistungsfähige Mikrocomputersysteme mit professionellem Anspruch zu entwickeln – eine Philosophie, die sich im C2 deutlich widerspiegelt.

Der C2 war kein typischer Heimcomputer, sondern vielmehr ein modulares, aufrüstbares System, das sich vor allem an Entwickler, Ingenieure, Bildungseinrichtungen und kleine Unternehmen richtete. Die Gerätefamilie umfasste unter anderem den C2-4P, ein kompaktes, tragbares System mit vier internen Steckplätzen, sowie den C2-8P, der über acht Erweiterungssteckplätze verfügte und in einem größeren Gehäuse untergebracht war. Beide Modelle basierten auf einer steckkartenbasierten Architektur, bei der CPU, Video-Einheit, RAM und I/O als separate Platinen in einen Busrahmen („Backplane“) eingebunden wurden. Dies erlaubte eine bemerkenswerte Flexibilität und Erweiterbarkeit – Merkmale, die zu dieser Zeit noch keineswegs selbstverständlich waren.

Als Prozessor kam der bewährte MOS Technology 6502 mit einem Takt von 1 MHz zum Einsatz. Die Taktfrequenz wurde allerdings nicht, wie bei den meisten Konkurrenten, durch einen Quarzoszillator erzeugt, sondern durch einen programmierbaren 74LS123-Monoflop-Schaltkreis, was eine gewisse Variabilität und Feinjustierung ermöglichte. Der 6502 war ein 8-Bit-Prozessor mit einem einfachen, aber effizienten Befehlssatz, der unter anderem durch seine indizierten Adressierungsmodi und seine niedrige Chip-Komplexität überzeugte. In Kombination mit dem leichtgewichtigen Systemdesign bot dies eine für die damalige Zeit bemerkenswert hohe Rechenleistung pro investiertem Dollar.

Das Betriebssystem bestand typischerweise aus einem im ROM untergebrachten Monitorprogramm und einem einfachen BASIC-Interpreter, der in einer auf 8 KB reduzierten Form implementiert war. Von Diskette konnte ein rudimentäres OSI-DOS oder ein erweitertes BASIC geladen werden. Der Zugriff erfolgte über einen simplen Konsolenmodus mit Cursorkontrolle und hexadezimalem Direktzugriff auf Speicheradressen. Auf dem Bildschirm konnten maximal 64 Zeichen pro Zeile bei 32 Zeilen dargestellt werden, wobei ausschließlich monochrome Textausgabe unterstützt wurde. Eine Bitmap-Grafikfähigkeit war serienmäßig nicht vorhanden, konnte aber theoretisch über Zusatzhardware realisiert werden. Farbdarstellung war nicht vorgesehen – der C2 blieb in dieser Hinsicht der kompromisslosen Funktionalität verpflichtet.

Auch in Sachen Klanggestaltung herrschte Sparsamkeit. Der C2 besaß keinen dedizierten Soundchip. Audioausgabe war nur indirekt über den Kansas City Standard möglich – einem Codierformat für Audiodaten, das auf Kassette gespeichert wurde. Manche Nutzer zweckentfremdeten das Kassetteninterface für primitive Tonausgabe, doch echte Musik- oder Effektfähigkeiten fehlten vollständig.
Der Massenspeicher bestand standardmäßig aus einem Kassettenrekorder-Anschluss, der mit 300 bis 1200 Baud arbeitete. Gegen Aufpreis konnte das System um ein Floppy-Interface (Model 470) ergänzt werden. Hier kamen wahlweise 5¼-Zoll- oder 8-Zoll-Laufwerke zum Einsatz. In seltenen Fällen wurde sogar ein Festplattenanschluss für Winchester-Laufwerke implementiert – eine für die späten 1970er geradezu futuristische Option. Der interne Arbeitsspeicher konnte von 4 KB (auf der CPU-Karte) auf bis zu 64 KB aufgerüstet werden, was für komplexe BASIC-Programme oder datenintensive Anwendungen absolut notwendig war.

In puncto Peripherie war der C2 ausgesprochen vielseitig. Neben parallelen und seriellen I/O-Karten bot OSI auch Druckerschnittstellen, einen Terminalanschluss, eine Mehrprozessor-Karte (Model 460Z) sowie diverse RAM-Erweiterungsplatinen an. Eine geplante Sprachsyntheseeinheit wurde angekündigt, aber nie über das Prototypstadium hinaus realisiert. Die Tastatur war separat im Gehäuse verbaut und erinnerte in Aufbau und Haptik eher an industrielle Terminals als an Heimcomputer-Tastaturen.

Die physische Größe variierte je nach Modell: Der C2-4P maß etwa 40 × 30 × 15 cm, der C2-8P war nochmals größer und erforderte einen separaten Monitor und häufig eine externe Stromversorgung. Das Design war funktional, industriell, kantig – und entsprach damit ganz dem technologischen Ethos der späten 1970er.

Die Preise für den Ohio Scientific C2 begannen 1978 bei 598 US-Dollar für das C2-4P-System. Das C2-8P schlug mit rund 799 US-Dollar zu Buche. Inflationsbereinigt entspricht dies im Jahr 2025 etwa 3.500 bis 4.700 Euro, je nach Modell und Ausstattung. Verglichen mit einem Apple II, der damals weit über 1.200 Dollar kostete, war der C2 also ein attraktives Angebot für technisch versierte Nutzer mit professionellen Ansprüchen. In der Fachpresse wurde der C2 teils wohlwollend, teils kritisch besprochen. Das Magazin Kilobaud lobte ihn als „beispiellose modulare Plattform für ernsthafte Computeranwender“, während Byte die Integration und Modularität herausstellte, jedoch die fehlende Farbgrafik bemängelte. Die Nachrichtenagentur UPI schrieb 1978: „Ein portabler Computer mit Fähigkeiten, die man sonst nur von Minis kennt.“

Die Verkaufszahlen lassen sich heute nur grob abschätzen. Bekannt ist, dass Ohio Scientific 1979 etwa 18 Millionen Dollar Umsatz erzielte und rund 300 Mitarbeiter beschäftigte. Der C2 war vor allem in Universitäten, Forschungseinrichtungen und kleinen Industriebetrieben zu finden – seltener im privaten Gebrauch. Sein modularer Aufbau, seine Erweiterbarkeit und seine offene Architektur machten ihn beliebt bei Bastlern, doch die lange Lieferzeiten und das Fehlen eines größeren Software-Ökosystems verhinderten eine breitere Marktdurchdringung. Im Vergleich zum Vorgänger, dem populären Superboard II, bot der C2 eine erheblich professionellere Bauweise, bessere Erweiterungsmöglichkeiten und eine robuste Backplane-Struktur. Gegenüber Konkurrenten wie dem Apple II, dem Commodore PET oder dem TRS-80 konnte er technisch mithalten, doch fehlten ihm ein attraktives Gehäuse, Farbfähigkeit und der Zugang zu einer großen Entwicklergemeinde – Punkte, die für Endanwender immer entscheidender wurden.

Trotzdem bleibt der Ohio Scientific C2 ein Meilenstein in der Entwicklungsgeschichte des Mikrocomputers. Er verkörpert jene Zwischenphase, in der sich die Heimcomputertechnik von der Garagenbastelei zur ernsthaften Computertechnik emanzipierte. Die Entwickler Michael und Charity Cheiky sowie Dale Dreisbach waren Pioniere, deren Beitrag zum frühen Mikrocomputermarkt in Fachkreisen heute mit Respekt betrachtet wird. Obwohl Ohio Scientific in den frühen 1980er Jahren schließlich von der Firma M/A-COM übernommen wurde und der Markenname verschwand, lebt der C2 in Sammlerkreisen fort – nicht zuletzt als Symbol für eine Ära, in der technische Eleganz und logisches Design noch mehr zählten als bunte Grafiken und Geräuschkulissen.

Franklin ACE 100

Wenn ich Dich, werter Leser, fragen würde, ob Du irgendwann einmal in Deinem Leben ein Programm ohne Zustimmung des Urhebers kopiert hast, würdest Du wahrscheinlich mit einem verlegenen Lächeln zustimmen, denn höchstwahrscheinlich hast Du die Zeit miterlebt und möglicherweise dank Programmen wie bspw. X-Copy auf dem Amiga ausgiebig davon Gebrauch gemacht (Nur zur Beruhigung: die Verjährungsfrist ist hier schon längst vorbei). Das nicht nur der private Heimanwender sich das Leben etwas vereinfachen wollte, ist daraus sicherlich erklärlich und beruhte auch auf der Tatsache, dass es noch bis Anfang der 1980er keine wirklichen Präzedenzfälle existierten. Dies sah auch der US-amerikanische Hersteller Franklin Computer Corporation so und präsentierte 1982 die ACE Modellreihe, die absolut Apple II kompatibel waren.

Technisch gesehen war der ACE 100 keine Nachbildung, sondern eine exakte Kopie des Apple II Plus: Franklin hatte den ROM-Inhalt von Apples System, inklusive BASIC-Interpreter, Monitorprogramm und Betriebssystem, Byte für Byte übernommen. Dies führte später zum wegweisenden Rechtsstreit Apple Computer, Inc. v. Franklin Computer Corp., der die Rechtsauffassung über Software-Urheberrecht nachhaltig prägte. Im Inneren arbeitete wie beim Original ein MOS Technology 6502 mit 1,023 MHz. Der 8-Bit-Prozessor war der zentrale Baustein zahlreicher Heimcomputer der Zeit, von der Atari-8-Bit-Serie bis zum Commodore 64. Er konnte direkt auf bis zu 64 KB RAM zugreifen, was dem ACE 100 voll zur Verfügung stand.

Die Grafikfunktionen entsprachen exakt dem Apple II Plus: Textmodus mit 40×24 Zeichen, Low-Resolution-Grafik mit 40×48 Bildpunkten bei 15 Farben plus schwarz, High-Res mit 280×192 bei bis zu sechs gleichzeitigen Farben, abhängig von den NTSC-Farbphasen. Für Ton sorgte wie beim Original ein 1-Bit-Speaker, der über Software getaktet wurde – komplexe Musik war nur durch gezieltes Pulsweitenmodulieren möglich.

Das ROM des ACE 100 enthielt eine 1:1-Kopie von Apples Integer BASIC (entwickelt von Steve Wozniak) sowie Apples Betriebssystem DOS 3.3. Der Computer unterstützte alle Apple-II-Platinen und Softwaretitel, da er vollständig signal- und softwarekompatibel war. Die Anschlussmöglichkeiten umfassten Composite-Video, Gameport, einen Erweiterungsbus mit acht Slots sowie Diskettenanschluss. Als Massenspeicher kamen externe 5,25-Zoll-Diskettenlaufwerke zum Einsatz – meist 140 KB pro Diskette –, häufig Apple-kompatible Nachbauten von Franklin selbst.

Ursprünglich wurde der ACE 100 als sogenannte „Bare Board“-Lösung vertrieben – ein vollständig bestücktes Mainboard ohne Gehäuse, Tastatur oder Netzteil. Zielgruppe waren technisch versierte Nutzer, Schulen und OEM-Kunden, die den Rechner in bestehende Apple-II-kompatible Gehäuse oder selbstgefertigte Lösungen einbauen wollten. Dennoch kam es im Handel bald zu Verwirrungen: Einige Dritthändler und Systemhäuser verkauften den ACE 100 auch als Komplettgerät, indem sie das Board mit Gehäuse, Tastatur und Netzteil kombinierten. Diese Varianten wurden teils noch unter dem Namen ACE 100 angeboten, obwohl der erste offiziell von Franklin vermarktete Komplettrechner auf Basis desselben Boards bereits ACE 1000 hieß.

Der Preis des ACE 100 als Mainboard lag bei rund 499 US-Dollar, was inflationsbereinigt ca. 1.475 Euro im Jahr 2025 entspricht – deutlich günstiger als der Apple II Plus mit etwa 1.195 Dollar (über 3.400 Euro heute). Diese Preisstrategie machte den ACE 100 besonders bei Bildungseinrichtungen beliebt. Presseberichte zur Veröffentlichung waren gespalten. Während Magazine wie Creative Computing das Gerät als „kostengünstigen Hoffnungsträger für Bildungseinrichtungen“ bezeichneten, schrieb BYTE Magazine im Oktober 1982: „Ein guter Computer, doch moralisch fragwürdiger Ursprung.“ Besonders Apple-Fans sahen in Franklin einen Trittbrettfahrer.

Etwa 20.000 Einheiten wurden laut interner Verkaufszahlen von Franklin bis Anfang 1983 ausgeliefert. Ein Lehrer aus Kalifornien baute mit Schülern Plexiglas-Gehäuse um ACE-Boards – ein Schulprojekt, das zum halblegalen Apple-Klonlabor wurde. „Ich hätte Apple lieber gekauft, aber mein Budget erlaubte das nicht. Der Franklin tat, was ich brauchte – Punkt“, sagte er rückblickend in einem Interview mit Popular Computing.

Apple war selbstredend kein allzu großer Freund der ACE Reihe und klagte bereits zur Veröffentlichung auf Urheberrechtsverletzung. Der Rechtsstreit Apple v. Franklin war ein historisches Verfahren in den USA, das maßgeblich die Rechtsgrundlage für den Schutz von Software festlegte. Franklin argumentierte, dass ROM-Code keine „literarischen Werke“ im Sinne des Urheberrechts seien und deshalb nicht geschützt werden könnten. Die Entscheidung des Berufungsgerichts (3rd Circuit) im Jahr 1983 war bahnbrechend: Das Gericht erklärte, dass auch Maschinencode in ROMs urheberrechtlich schützbar ist, selbst wenn dieser nicht direkt lesbar ist. Dies war das erste Mal, dass ein US-Gericht urheberrechtlichen Schutz für firmwarebasierte Software bestätigte.

Das Verfahren zog sich bis 1988 hin. Franklin verlor in allen wesentlichen Punkten. Die Firma musste den Vertrieb der betroffenen Produkte einstellen oder neu designen, was ihren Marktanteil stark schrumpfen ließ. Franklin bot später den ACE 500 mit neuem ROM und eigener Softwarearchitektur an – jedoch ohne die vollständige Kompatibilität, die den ACE 100 so erfolgreich gemacht hatte. Gegenüber direkten Konkurrenten wie dem Commodore PET oder dem Tandy TRS-80 war der Franklin ACE 100 grafisch unterlegen, aber durch seine Apple-Kompatibilität deutlich vielseitiger. Für Bastler war er eine kostengünstige Alternative – für Apple ein Dorn im Auge.

Der ACE 100 war also mehr als nur ein Plagiat. Er war ein politischer Computer, ein juristisches Exempel, ein Spiegel der frühen 80er-Jahre zwischen Innovation, Nachbau und der Suche nach Standards. Heute ist er ein Sammlerstück – gerade weil er als einziger Computer in US-Geschichte vor Gericht tatsächlich als urheberrechtswidrig verboten wurde, obwohl er technisch brillant umgesetzt war.

Wings of Fury – 1988 by Brøderbund

Wings of Fury, von Brøderbund im Dezember 1987 veröffentlicht, war ein ungewöhnlicher, stilisierter Mix aus Shoot-'em-up und Simulation, der sich in der Ästhetik eher an Spielhallenklassiker anlehnte, inhaltlich jedoch überraschend ernst war. Entwickelt wurde das Spiel ursprünglich von Steve Waldo, einem der weniger bekannten, aber technisch versierten Designer, der zuvor an Tools und internen Konvertern für Brøderbund mitgearbeitet hatte. Die Musik und Sounds wurden von Kris Hatlelid beigesteuert, wobei die PC-Version mangels Sound-Hardware auf einfache Effekt-Cues beschränkt blieb. Die Amiga- und Apple-II-Versionen nutzten einfache Sampleeffekte und systemnahe Töne, boten aber keine musikalische Untermalung im eigentlichen Sinne.

Die Entstehungsgeschichte von Wings of Fury begann laut einer internen Brøderbund-Mitteilung bereits 1986, als Steve Waldo erste Prototypen entwickelte, die sich an Side-Scrolling-Flugspielen wie Choplifter oder Defender orientierten, aber eine realistische Physik und ballistische Berechnung einführen wollten. In einem seltenen Interview aus der Zeitschrift Compute! (Ausgabe Juni 1989) sagte Waldo: „Ich wollte ein Spiel, das so einfach zu bedienen ist wie ein Arcade-Shooter, aber die Ernsthaftigkeit des Zweiten Weltkriegs mit sich trägt. Kein Fantasiekrieg, sondern realistisch, direkt, ohne Filter.“ Der Produktionsprozess war relativ schlank: Innerhalb von etwa acht Monaten wurde die Kernversion für den Apple II fertiggestellt, wobei viele der Sprites handgezeichnet und pixelweise optimiert wurden. Die Entwickler testeten die Wirkung von Bomben auf animierte Soldaten in verschiedenen Variationen – ein Detail, das später für Kritik sorgte.

Das Spiel versetzt den Spieler in die Rolle eines US Navy-Piloten im Pazifikkrieg 1944. Als Pilot eines F6F Hellcat jagt man von einem Flugzeugträger aus japanische Flakstellungen, Nachschubtruppen, Landungsboote, Radaranlagen und Flugplätze. Gesteuert wird dabei aus einer seitlichen 2D-Perspektive. Die Steuerung kombiniert Flugphysik mit direkter Arcade-Steuerung: Geschwindigkeit, Fluglage und Flughöhe müssen koordiniert werden, um präzise Bombenabwürfe, Torpedoeinsätze oder Bordmaschinenangriffe auszuführen. Landungen auf dem eigenen Flugzeugträger – der sich ebenfalls in Bewegung befindet – gehören zu den schwierigsten, aber auch eindrucksvollsten Momenten. Munition ist begrenzt, Nachladen und Reparaturen erfordern präzises Landen.

Die Kombination aus realer Militärgeschichte, schwarzhumoriger Gewalt und Arcade-Mechanik sorgte für eine geteilte Rezeption. Die US-Presse lobte das Spiel nahezu durchweg – Compute! sprach von einem „komplexen, aber unterhaltsamen Kriegsspiel, das gleichzeitig pädagogisch und fesselnd“ sei. In Deutschland fiel die Berichterstattung zurückhaltender aus. Die Zeitschrift 64'er lobte 1989 die technische Umsetzung, merkte aber kritisch an, dass „die Darstellung von explodierenden Menschen in einem Spiel dieser Art unnötig martialisch“ wirke. Besonders auf dem C64, dessen Version vom Studio Cascade Games konvertiert wurde, sorgten die teils expliziten Animationen der sterbenden Soldaten für Diskussionen. In Frankreich wurde das Spiel aufgrund seiner Thematik teilweise zensiert vertrieben.

Wings of Fury erschien ursprünglich auf dem Apple II undMS-DOS, später folgten offizielle Portierungen für Commodore 64, Amiga, sowie eine japanische Version für den Sharp X68000, die nicht nur technisch, sondern auch inhaltlich stark verändert wurde. In der exklusiven X68000-Version übernimmt der Spieler nicht die Rolle eines amerikanischen Piloten, sondern steuert eine japanische Mitsubishi A6M Zero und kämpft gegen amerikanische Streitkräfte. Die Level, Menüs, Sounds und Animationen wurden neu gestaltet, um der japanischen Perspektive auf den Krieg zu entsprechen – eine komplette kulturelle Umkehrung des ursprünglichen Spiels. Damit war die X68000-Version keine reine Portierung, sondern eine vollständig lokalisierte Neuinterpretation mit hoher grafischer Qualität und historisch angepasstem Narrativ. Technisch war sie zudem deutlich anspruchsvoller: flüssigere Parallax-Scrolling-Effekte, detailliertere Explosionen und eine ausgefeiltere Kollisionslogik machten sie zu einer der hochwertigsten Fassungen überhaupt.

Insgesamt wurden weltweit schätzungsweise über 250.000 Einheiten verkauft, was angesichts der ernsten Thematik bemerkenswert war. Das Spiel wurde nie offiziell fortgesetzt, obwohl ein Prototyp mit dem Titel Wings of Fury II 1992 bei Brøderbund kursierte, später aber eingestellt wurde. 2001 erschien ein inoffizielles Remake für Windows-PCs, das Gameplay und Grafik modernisierte, aber ohne Lizenz durch kleinere Entwickler realisiert wurde.

Trivia: Die Figur des Piloten blieb namenlos, doch in einem Mockup für das Handbuch der Amiga-Version wurde er „Lt. J. R. Hayes“ genannt – ein Hinweis auf einen echten US-Piloten, der 1944 über Iwo Jima abgeschossen wurde. Entwickler Waldo sagte dazu nur: „Ich wollte keine Heldenromantik. Das war ein Krieg, kein Abenteuerfilm.“ Ein weiterer interessanter Aspekt: Die Gravity-Engine von Wings of Fury wurde später von Brøderbund intern bei Prince of Persia inspiriert übernommen – insbesondere das ballistische Verhalten der Fallbewegungen. Entwickler Jordan Mechner bestätigte später in seinen Notizen von 1989, dass Wings of Fury als eines von drei physikbasierten Vorbildern diente.

Starflight I – 1986 by Binary Systems

Im Jahr 1986 erschien mit Starflight eines der ambitioniertesten und innovativsten Computerspiele seiner Zeit. Entwickelt wurde es von Binary Systems, einem kleinen Studio unter der Leitung von Rod McConnell, Greg Johnson und Tim Lee. Die Veröffentlichung übernahm Electronic Arts, das mit dem Titel ein Experiment wagte – ein Spiel, das Rollenspiel-, Weltraum-Erkundungs- und Wirtschaftssimulationselemente miteinander verband, basierend auf einer eigenen Engine und völlig neuen technischen Lösungen. Der Titel wurde ursprünglich für IBM-PC-kompatible Rechner mit MS-DOS entwickelt, in einer Zeit, als diese Plattform spielerisch noch hinter dem C64 und Apple II stand. Starflight änderte das.

Die Entwicklungszeit betrug über fünf Jahre – ungewöhnlich lang für damalige Verhältnisse. Tim Lee und Rod McConnell arbeiteten ursprünglich an einem einfachen Asteroiden-Management-Spiel. Doch das Projekt wuchs rasch zu einem komplexen Simulations- und Storyuniversum mit über 800 zu erforschenden Planeten. Greg Johnson, der später mit ToeJam & Earl berühmt wurde, war maßgeblich für die narrative Gestaltung verantwortlich. Er verfasste die meisten der interaktiven Alien-Dialoge und das Hintergrunduniversum. „Wir wollten kein Spiel machen, das man einfach spielt – wir wollten ein Universum schaffen, das man bewohnt,“ erinnerte sich Johnson 2001 in einem Interview mit GameSpot.

Eine der größten technischen Besonderheiten von Starflight war seine Programmierung in FORTH und x86-Assembler – eine für damalige Spieleproduktionen sehr ungewöhnliche Wahl. Die Entwickler nutzten FORTH als Metasprache, um die komplexen Verhaltensroutinen und Systemsimulationen effizient zu organisieren, während Performance-kritische Routinen – etwa für die Raumfahrt, Oberflächendarstellung der Planeten oder die Kampfsysteme – in Assemblersprache geschrieben wurden. „Wir haben FORTH verwendet, weil es uns erlaubte, Ideen unglaublich schnell zu testen und zu iterieren – etwas, das in C oder Pascal viel länger gedauert hätte,“ erklärte Greg Johnson. Tim Lee ergänzte später: „Mit FORTH konnten wir eine eigene Umgebung bauen, die genau das tat, was wir wollten – und nichts darüber hinaus.“ Die Kombination machte den Code zwar extrem effizient, aber auch schwer wartbar, was sich später bei Portierungen als Hindernis erwies.

Die größte technische Leistung war die sogenannte fractal terrain generation – ein System, das Planeten mit realistischen Oberflächen aus einem minimalen Datensatz erzeugte. Dadurch konnten die Entwickler ein ganzes Universum mit über 270 Sonnensystemen und rund 800 Planeten erschaffen, ohne die Hardware-Speichergrenzen der Zeit zu sprengen. In einem internen Entwicklungsdokument von 1985 heißt es: „Starflight nutzt ein rekursives Generatorverfahren, das aus 16 Kilobyte Planetendaten mehrere hundert Megabyte an simulierten Geländeinformationen synthetisiert.“

Die Hintergrundgeschichte von Starflight spielt im 47. Jahrhundert, auf dem Planeten Arth, einer einstigen Kolonie der Menschheit, deren Ursprünge weitgehend in Vergessenheit geraten sind. Die galaktische Zivilisation wurde vor Jahrhunderten durch eine Katastrophe ausgelöscht, von der man nur noch als die „Zerschlagung“ spricht. Nun liegt es am Spieler, im Auftrag der „Interstel Corporation“ ein neues Erkundungsprogramm zu starten. Das Ziel ist zunächst wirtschaftlicher Natur: den Wiederaufbau durch Rohstoffgewinnung zu sichern. Doch schon bald offenbart sich eine kosmische Bedrohung – eine mysteriöse Energie, die ganze Sterne kollabieren lässt. Im Verlauf des Spiels deckt man nach und nach die Wahrheit über die alte Zivilisation der „Ancients“ auf, die für das Gleichgewicht des Universums verantwortlich war – und erkennt, dass das eigene Volk selbst ein verlorener Teil dieser Zivilisation sein könnte. Die Bedrohung geht letztlich vom „Crystal Planet“ aus, einer künstlich geschaffenen Welt, die das galaktische Zentrum destabilisiert. Um das Universum zu retten, muss der Spieler Artefakte, Technologien und Allianzen finden und schließlich den Kristallplaneten vernichten – nicht mit Gewalt, sondern durch Wiederherstellung der Ordnung. Es ist eine tiefgründige Geschichte über Vergessen, Verantwortung und die Wiederentdeckung der eigenen Herkunft.

Spielerisch kombinierte Starflight Exploration, diplomatische Kommunikation mit außerirdischen Spezies, Ressourcenmanagement, Bergbau, Raumschiff-Upgrade und Echtzeit-Raumkämpfe. Die außerirdischen Rassen – darunter die humorvollen Spemin, die mysteriösen Thrynn, die kriegerischen Uhlek und die hochintelligenten Elowan – wurden per Textdialog beschrieben, deren Antworten sich je nach Spielverlauf und Sprachproben veränderten. Auch die Beziehung zwischen den Spezies – etwa der Konflikt zwischen Thrynn und Elowan – beeinflusste die diplomatischen Optionen des Spielers.

Die Musik im Spiel war spärlich, da die ursprüngliche PC-Version kaum Soundkarten nutzte. Dennoch wurde später eine Version für das Sega Mega Drive (Genesis) erstellt, in der Rob Hubbard, der legendäre Komponist von Monty on the Run und Sanxion, das Musikdesign übernahm. Diese Umsetzung erschien 1991, erhielt gute Kritiken und führte Starflight einem breiteren Publikum zu. Die Genesis-Version erhielt im Magazin GamePro 4 von 5 Sternen und wurde für ihre Tiefe und grafische Umsetzung gelobt.

Die internationale Rezeption der PC-Version war sehr positiv. Die Zeitschrift Computer Gaming World nannte es in ihrer März-Ausgabe 1987 ein „Meisterwerk interaktiven Worldbuildings“ und verlieh ihm eine seltene 5/5-Wertung. In Deutschland vergab die Zeitschrift ASM 11 von 12 Punkten und lobte vor allem die „tiefgreifende Spielmechanik, die sogar Elite in den Schatten stellt“. In Großbritannien wurde Starflight über Ariolasoft vertrieben, war jedoch kommerziell weniger erfolgreich, da dort Commodore- und Spectrum-Systeme dominierten.

Verkaufszahlenmäßig war Starflight für EA ein Überraschungserfolg: Über 500.000 Einheiten wurden bis Anfang der 1990er Jahre verkauft – eine beachtliche Zahl für ein nicht actionorientiertes PC-Spiel jener Zeit. Es zählte zu den meistverkauften Science-Fiction-Spielen vor der Veröffentlichung von Wing Commander. Eine Fortsetzung, Starflight II: Trade Routes of the Cloud Nebula, erschien 1989 und baute die Handels- und Diplomatiesysteme weiter aus, wurde jedoch weniger beachtet.

Produktionstechnisch war das Spiel ein Kraftakt. Der damalige EA-Produzent Joe Ybarra, der auch an M.U.L.E. und The Bard’s Tale mitwirkte, bezeichnete Starflight später als „das einzige Spiel, bei dem ich dachte, dass wir es nie fertigbekommen würden.“ In den internen Unterlagen von EA aus dem Jahr 1986 ist dokumentiert, dass der ursprüngliche Veröffentlichungstermin zweimal verschoben wurde – ein frühes Beispiel für die berüchtigten „Crunch“-Phasen der Spielebranche.

Trivia: Die erste Version des Spiels beinhaltete noch eine Religion namens „Zyphirianer“, die später entfernt wurde, weil man Konflikte mit religiösen Gruppen befürchtete. Ebenso wurde das originale Titelbild, das eine halb entkleidete Außerirdische zeigte, in der finalen Fassung zensiert und ersetzt. Außerdem war ursprünglich ein Koop-Modus geplant, bei dem ein zweiter Spieler die Scanner- oder Kommunikationskonsole übernehmen konnte – dieses Feature fiel den Speicherbeschränkungen zum Opfer.

Starflight inspirierte zahlreiche spätere Spiele – darunter Mass Effect, No Man’s Sky, Star Control und Out There. Die Entwickler Greg Johnson, Rod McConnell und Tim Lee blieben der Spielebranche verbunden. Johnson gründete ToeJam & Earl Productions, während McConnell an frühen Online-Spielen arbeitete. Die Rechte an Starflight lagen später bei EA, wurden aber 2018 temporär freigegeben, woraufhin ein inoffizielles Fanprojekt namens Starflight 3 gestartet wurde – unter Beteiligung von Greg Johnson. Dieses wurde jedoch 2021 aus rechtlichen Gründen eingestellt.

The Running Man – 1989 by Emerald Entertainment

Im Jahr 1989 veröffentlichte GrandSlam Entertainments das Actionspiel The Running Man, eine Adaption des gleichnamigen Films mit Arnold Schwarzenegger aus dem Jahr 1987, der seinerseits lose auf Stephen Kings dystopischem Roman unter dem Pseudonym Richard Bachman basierte. Die Umsetzung war typisch für die späten 1980er, als britische Publisher eilig Lizenzprodukte zu Blockbustern auf den Markt brachten. Entwickelt wurde das Spiel von der irischen Softwareschmiede Emerald Software. Das Kernteam bestand unter anderem aus den Programmierern John Gibson und Jim Baguley, zwei Veteranen der Szene, die zuvor bei Imagine Software und Ocean aktiv waren. Die Musik komponierte Jonathan Dunn, bekannt durch Titel wie Platoon, RoboCop und das musikalisch überraschend gefühlvolle Pictionary.

Die Entwicklung verlief unter Zeitdruck, denn der Veröffentlichungstermin war eng mit der europäischen Heimkino-Verwertung des Films verknüpft. Laut Entwickler John Gibson im Magazin Crash! (Dezember 1989) hatten sie kaum zehn Wochen zur Verfügung: „Wir arbeiteten praktisch ohne Unterbrechung. Schlaf war ein Luxus – die Deadline war gnadenlos.“ Die Ressourcen waren zudem begrenzt: Emerald Software war ein junges Studio mit Ambitionen, aber ohne großes Budget. Vieles wurde improvisiert, Sprites wurden wiederverwendet, und für die Portierungen auf ZX Spectrum und Amstrad CPC musste parallel gearbeitet werden. In der C64- und Amstrad-Version von The Running Man wurden einige Sprite-Grafiken und Animationsroutinen nachweislich aus früheren Projekten von Emerald Software wiederverwendet oder recycelt. Besonders auffällig ist dabei die Ähnlichkeit mit dem Spiel Zombi (1986) und teilweise mit internen Engine-Demos, die nie veröffentlicht wurden.

Ein besonders markantes Beispiel ist der Sprite des „Wachmanns mit Schlagstock“ in The Running Man, der in leicht abgewandelter Farbgebung und Haltung auch in einem frühen Emerald-Prototyp namens Prison Riot auftauchte – ein Titel, der nie das Licht der Öffentlichkeit erblickte. Die Animation des Gehens und der diagonalen Angriffsbewegung sind nahezu identisch. Ein weiteres Beispiel ist der „Feuergegner“ in der zweiten Arena (möglicherweise eine Adaption von Fireball aus dem Film), der auffällig ähnliche Flammen-Frames wie ein Bossgegner aus Zombi verwendet, jedoch in modifizierter Farbpalette und mit angepasstem Sprite-Overlay.

Spielerisch hatte The Running Man nur noch wenig mit der filmischen Vorlage zu tun. Statt tiefgehender Medienkritik und dystopischer Gesellschaftskritik bot das Spiel klassisches Side-Scrolling-Action-Gameplay. Der Spieler übernahm die Rolle von Ben Richards, der sich durch eine Serie futuristischer Arenen schlagen musste, gefüllt mit Fallen, bewaffneten Wachen und Bossgegnern, die lose an Figuren wie Fireball und Subzero aus dem Film angelehnt waren. Die Amiga- und ST-Version boten detaillierte Grafiken und flüssige Animationen, während die 8-Bit-Versionen – besonders auf dem ZX Spectrum – deutlich eingeschränkter daherkamen, aber dennoch mit Charme und technischem Geschick umgesetzt wurden.

Erschienen ist The Running Man auf Commodore 64, ZX Spectrum, Amstrad CPC, Commodore Amiga und Atari ST. Eine PC-DOS-Version war in Vorbereitung, wurde jedoch nie fertiggestellt. Die Amiga-Version wurde von der Presse am besten aufgenommen – CU Amiga vergab 84 % und lobte Grafik und Musik. Das britische Zzap!64 vergab 71 % für die C64-Fassung, während Your Sinclair der Spectrum-Umsetzung 76 % zubilligte. In Frankreich lobte Tilt die visuelle Gestaltung, bemängelte aber die Sprungsteuerung. Micromania in Spanien bewertete das Spiel mit 7 von 10 Punkten – solide, aber kein Überflieger. Deutsche Spielemagazine sahen das anders. Die Power Play vergab in der Ausgabe 7/89 magere 31% für die Amiga Version, während die ASM 4 von 10 Punkten vergab: „Die Grafiken sind schlecht, die Animations-Sequenzen ganz ordentlich, der Sound echt gut. Der eigentliche Spielablauf allerdings lässt, ebenso wie die Steuerung, stark zu wünschen übrig (Manfred Kleimann)“

Kommerziell war das Spiel ein gemäßigter Erfolg. GrandSlam hatte mit einer starken Marke und dem Schwarzenegger-Namen gerechnet, doch der Titel konnte die Erwartungen nicht ganz erfüllen. Die Gesamtverkäufe beliefen sich laut einem geleakten GrandSlam-Dokument, das 2011 im Retro-Netzwerk Lemon64 kursierte, auf rund 35.000 Einheiten über alle Plattformen hinweg. Besonders die C64- und Amiga-Versionen verkauften sich ordentlich, während die 8-Bit-Fassungen hinter den Erwartungen blieben.

Kontrovers war das Spiel vor allem wegen seiner Herkunft. In Deutschland war der Film The Running Man zu dieser Zeit auf dem Index, und auch das Spiel wurde durch Importe in die Hände jugendlicher Spieler gebracht. Die Bundesprüfstelle prüfte das Spiel zwar, verzichtete jedoch auf eine Indizierung – vermutlich weil der Gewaltgrad im Spiel gegenüber dem Film deutlich reduziert war.

Jonathan Dunns Soundtrack – besonders die Amiga-Version mit ihrer futuristisch-dröhnenden Titelmelodie – wurde vielfach gelobt und später auf Remix-Portalen wie AmigaRemix.com neu arrangiert. In der Demo-Szene fand Dunns Titelmusik Eingang in ein Cracktro der Gruppe Fairlight, wo sie unter anderem von dem Coder Laxity modifiziert wurde.

Bemerkenswerterweise war ein Sequel geplant, das jedoch nie erschien: Emerald Software hatte 1990 ein Konzept für The Running Man II entwickelt. Dieses sah eine Mischung aus Stealth, Plattform-Action und strategischem Ressourcen-Management vor. „Es sollte eine Art Metal Gear vor Metal Gear werden,“ so Entwickler Jim Baguley in einem Interview von 2004. GrandSlam zeigte jedoch kein Interesse – laut Baguley, weil die Marke nach dem mittelmäßigen Erfolg des ersten Spiels nicht mehr als zugkräftig galt.

Trivia: In der Amiga-Version versteckt sich im Speicher ein nicht verwendeter Sprite eines Gegners, der stark an den Terminator erinnert – mit Sonnenbrille, Lederjacke und Gewehr. Offenbar eine bewusste Anspielung an Schwarzeneggers andere ikonische Rolle. Außerdem sollte ursprünglich der Moderator Killian (im Film gespielt von Richard Dawson) als finaler Boss auftauchen, wurde aber durch einen gesichtslosen „Game Controller“ ersetzt, da GrandSlam kein Bildrecht erworben hatte.

Gekko Prozessor

By Baz1521 - ja.wikipedia.org

Im Mai 1999 kündigte Nintendo zusammen mit IBM einen milliardenschweren Vertrag über die Entwicklung eines maßgeschneiderten PowerPC-Mikroprozessors für die nächste Konsolengeneration („Dolphin“, später GameCube) an. Nintendo-Manager Howard Lincoln versprach damals einen “400 MHz” Prozessor, der “das leistungsstärkste Central Processing Unit-System eines jeden derzeitigen oder geplanten Heimvideospiels… sein wird”. IBM verpflichtete sich, den Chip – Gekko genannt – auf Basis seiner PowerPC-Architektur zu entwickeln und in 0,18‑Mikron-Kupfertechnik bei der Fabrik in Burlington, Vermont, zu fertigen. Die offizielle Präsentation bestätigte später einen Takt von 485 MHz für Gekko. Nintendo blieb zwar vage bei Herstellkosten, doch Medienberichte spekulierten, dass der komplette GameCube laut angeblich unbestätigten Quellen nur rund 20 US-Dollar Produktionskosten pro Konsole verursachte (inflationsbereinigt heute etwa 30 Euro). Diese hohe Marge – bei einem UVP von 199 US-Dollar – trug dazu bei, dass Nintendo profitabel blieb, während die Xbox und PS2 teils mit Verlusten operierten.

Technisch ist Gekko ein superskalarer, aus der PowerPC-750-Serie (G3) abgeleiteter 32-Bit-Prozessor. Er verwendet zwei vierstufige Pipelines für Ganzzahlbefehle und eine siebstufige Pipeline für Gleitkommaoperationen. Der Chip enthält zwei 32-Bit-Integer-ALUs und eine 64-Bit-FPU mit 32 64-Bit-Floating-Point-Registern (zusätzlich zu 32 32-Bit-GPR). Die Hardware wurde um spezielle Erweiterungen ergänzt: etwa etwa 50 neue SIMD-Befehle (Single instruction, multiple data), die in einem Takt zwei 32-Bit- oder ein 64-Bit-Gleitkommawert bearbeiten können, sowie eine Write-Gather-Einheit für effizientes Blockschreiben und ein teilweiser L1-Cache als 16 KB Scratchpad. Der Front-Side-Bus arbeitet mit 162 MHz (drei Taktzyklen entspricht dem 486-MHz-Kerntakt). Die Chipfertigung erfolgte in 0,18‑Mikron-Kupferprozess, was IBM als “fortschrittlichste Chiptechnologie” pries. Gekko enthält 64 KB L1-Cache (Code und Daten) und 256 KB L2-Cache on-chip. Durch die kompakte Fertigung blieb der Die-Flächenbedarf klein (unter 45 mm²) und der Stromverbrauch niedrig – nur etwa 5 W unter Volllast.

Die GameCube-Architektur nutzt schnellen 1T-SRAM-Hauptspeicher: 24 MB 1T-SRAM mit etwa 10 ns Zugriffszeit und einem 162-MHz-Bus dienen als Haupt-RAM, ergänzt durch 16 MB langsameren DRAM für Audio und peripherieintensive Aufgaben. Dieser einheitliche Speicherbus ließ CPU und Grafikchip (Flipper) effizient zusammenarbeiten. In Benchmarks konnte ein gleichschnell getakteter x86-Prozessor (etwa ein 733 MHz Pentium III wie in der Xbox) den Gekko klar überholen; jedoch hatte Gekko architektonische Vorteile: umfangreichere Register, neue Instruktionen und vor allem einen deutlich niedrigeren Stromverbrauch. So erzeugt Gekko nur rund ein Drittel der Wärme eines Xbox-CPUs und benötigt weniger Platz, was kostensparend war und Nintendo niedrigere Preise (199 statt 299 US-$) erlaubte.

Zum Vergleich: Sonys PlayStation 2 setzte auf einen 294 MHz MIPS-Prozessor (Emotion Engine) mit integrierten Vektor-Einheiten, Microsofts Xbox nutzte einen 733 MHz Coppermine-Pentium-III. In dieser Generation konnte die Xbox-CPU bezüglich reiner Integer-Leistung oft den Gekko übertreffen, doch die kompliziertere PS2-Architektur galt als schwieriger zu programmieren. Gekko, so versprach Nintendo, übertrifft jedoch jedes gegenwärtige Heim-Videospiel-CPU-System in seiner Rechenleistung. Nintendo-Gründer Shigeru Miyamoto kommentierte enthusiastisch, Gekko eröffne neue Möglichkeiten – etwa ein nächstes Level an Grafik für Spiele wie Zelda.

In wirtschaftlicher Hinsicht war Gekko ein Erfolg: Er steckte in nahezu allen weltweit verkauften GameCubes (ca. 22 Mio. Stück bis 2007), sodass IBM entsprechend viele Chips lieferte. Die genaue Stückzahl der hergestellten Gekko-Prozessoren ist nicht öffentlich, doch IBM-Kenner berichten über zweistellige Millionenauflagen. Die niedrigen Produktionskosten pro Konsole ließen Nintendo hohe Margen erzielen.

Keith Diefendorff

Picture from "The New York Times"

Die Entwickler hinter Gekko kamen aus IBM und Nintendo. IBM-Architekten, darunter erfahrene PowerPC-Designer wie Keith Diefendorff (anfangs Lead-Architekt der PowerPC-ISA), sorgten für die Hardwarerealisierung in Burlington. Nintendo-Ingenieure und Manager wie Howard Lincoln (damals Nintendo of America Chairman) leiteten das Projekt intern und dienten als Ansprechpartner bei Messen. Miyamoto, Nintendo-Gründungsmitglied und Grafik-Legende, definierte die Software-Vision, während Grafikingenieur Wei Yen (ehemals SGI, Mitbegründer von ArtX) parallel an der Flipper-GPU arbeitete. Ihre Biografien stehen exemplarisch für den Crossover: erstklassige IBM‑Chipdesigns gepaart mit Nintendo‑Spielideen.

Gekko inspirierte spätere Wii-Ableger: Der Wii-Prozessor Broadway ist praktisch ein 750CL‑Revision mit 50 % höherer Taktrate (729 MHz) und sehr ähnlicher Architektur. Außerhalb von Nintendo-Hardware kam Gekko nur einmal vor: Die Triforce-Arcadeplatine (2002, eine Kooperation von Nintendo, Sega und Namco) verwendete eine GameCube-nahe Hardware mit genau dem IBM-Gekko-CPU. Ansonsten setzten PS2, Xbox und spätere Konsolen auf andere Architekturen (Sony blieb bei MIPS/Cell, Microsoft bei x86 bzw. später PowerPC/Xenon in der Xbox 360), sodass Gekko-Chips exklusive Kernbestandteil der Nintendo-Systemfamilie blieben.

Nintendo stellte den Lizenznehmern für Gekko-Software eine vollständige Entwicklungsumgebung bereit. Als Compiler und IDE nutzte man Metrowerks’ CodeWarrior, das einen stark optimierten C/C++-Compiler und Assembler für den Gekko enthielt. Tatsächlich wurde das GameCube‑Betriebssystem selbst mit CodeWarrior erzeugt, einer integrierte Entwicklungsumgebung der Firma Freescale, die zuvor ein Tochterunternehmen des Chipherstellers Motorola darstellte. Entwickler konnten damit Projekte in einzelne Modulteile (RELs) aufspalten und direkt auf die Konsole laden. Für das Debuggen wurden offizielle Dev‑Konsolen ausgegeben: Nintendo setzte auffällige Blaue (NR Reader) und Rote (NPDP Reader) Prototyp-Units ein, die anstelle von Gamecube‑Discs Spezialmedien lesen konnten. Die NPDP-Einheiten enthielten sogar Festplattenkartuschen und eine PC-Schnittstelle (NPDP-ODEM), um neue Spielversionen schnell vom Entwicklungsrechner in die Hardware zu streamen. Zusätzlich gab es Hilfshardware wie Memory-Card-Emulatoren. Ein klassischer Software-„Simulator“ (Emulator auf dem PC) wurde offiziell nicht benötigt – Nintendo empfahl, direkt auf der Hardware zu entwickeln und CodeWarrior zusammen mit den speziellen Dev-Kits einzusetzen.

Zusammenfassend kombinierten die Gekko-Entwickler IBM‑Chipkompetenz mit Nintendos Spieleanforderungen zu einem effizienten CPU-Design. Trotz der geringeren Rohleistung gegenüber manchen Konkurrenten erwies sich Gekko als kosteneffizient und zuverlässig – ein Schlüsselbestandteil des technisch kompakten GameCube-Systems.

Archimedes A7000

Der Archimedes A7000 war einer der letzten klassischen Computer von Acorn Computers Ltd., jener traditionsreichen britischen Firma, die sich bereits in den 1980er Jahren mit ihren innovativen BBC-Mikrocomputern und der Einführung des RISC-Konzepts als Pionier auf dem Heimcomputermarkt etablierte. Der A7000 wurde im Juli 1995 vorgestellt und markierte den Versuch, ein erschwingliches und zugleich leistungsfähiges Modell für den Bildungsbereich und ambitionierte Heimnutzer anzubieten, das die Tugenden seiner Vorgänger mit moderneren Bauteilen verband. Während der A7000 äußerlich kompakter wirkte, verbarg sich unter seinem schlichten grauen Kunststoffgehäuse ein System, das auf RISC OS 3.6 lief und in vielerlei Hinsicht den Brückenschlag zwischen der alten Archimedes-Reihe und den späteren RiscPCs darstellte.

Der A7000 nutzte einen ARM7500-Prozessor, eine Variante des ARM7 mit integrierter MMU, Video- und I/O-Einheiten, die Acorn in Zusammenarbeit mit ARM Ltd. entwarf. Dieser Chip war nicht nur das Herzstück des A7000, sondern auch ein frühes Beispiel für System-on-Chip-Integration, wie sie später im Embedded-Markt und in Smartphones allgegenwärtig wurde. Der ARM7500 lief mit 32 MHz, war sparsamer und effizienter als viele vergleichbare CISC-Prozessoren jener Zeit und setzte ganz auf die Philosophie der reduzierten Befehlssätze (RISC), bei denen einfache Operationen in konstant kurzer Zeit ausgeführt werden, was eine bemerkenswerte Systemreaktionszeit ermöglichte.

Zum Einführungspreis von £799 für das Basismodell mit Monitor entsprach der A7000 im Jahr 1995 einem heutigen Preis von rund 1.650 Euro inflationsbereinigt (Stand 2025), was ihn preislich im oberen Mittelfeld für Schul- und Heimcomputer platzierte. Die Hardware bot dafür eine solide Ausstattung: standardmäßig 4 MB RAM, erweiterbar über einen 72-Pin-FPM-SIMM-Steckplatz. Acorn selbst dokumentierte eine offizielle Obergrenze von 32 MB, da diese Module zur Markteinführung wirtschaftlich und verfügbar waren. Tatsächlich aber kann der A7000 deutlich mehr leisten: Inoffiziell lassen sich Module mit bis zu 128 MB installieren, sofern sie bestimmte elektrische Anforderungen erfüllen, insbesondere eine Single-Sided-Bauweise und eine passende Refresh-Rate. Das Betriebssystem RISC OS 3.6 erkennt den gesamten Speicher, wenn das Modul kompatibel ist, wie zahlreiche Berichte von Nutzern und Entwicklern in der damaligen Community zeigen. In einem Artikel der Zeitschrift Acorn User von 1996 heißt es dazu: „Though Acorn only certifies the A7000 for up to 32 megabytes of RAM, tests with 64 and even 128 meg modules have shown promising results for enthusiasts.“ Damit bot der A7000 eine für damalige Verhältnisse außergewöhnliche Speichererweiterbarkeit, auch wenn diese in offiziellen Unterlagen nicht beworben wurde.

Bei der Massenspeicherung zeigte sich der A7000 flexibel. Je nach Modellvariante kam er entweder mit einer 425-MB- oder einer 540-MB-IDE-Festplatte. Einige OEM-Modelle und Schulausführungen enthielten zusätzlich ein CD-ROM-Laufwerk. Der Nachfolger A7000+ wurde meist mit 1,2-GB-Festplatten ausgeliefert. Die IDE-Schnittstelle erlaubte theoretisch Festplatten bis zu 2 GB, und bei entsprechender Partitionierung mittels Tools wie !HForm konnte auch diese Kapazität genutzt werden. Fortgeschrittene Benutzer berichteten sogar von größeren Laufwerken, die mit mehreren Partitionen über RISC OS 3.6 hinaus betrieben wurden. Diese Flexibilität machte den A7000 auch für anspruchsvollere Anwendungen attraktiv, insbesondere in Netzwerken oder in schulischen Umgebungen mit zentralisierter Datenspeicherung.

Als Betriebssystem diente RISC OS 3.6, ein grafisch orientiertes System mit WIMP-Oberfläche, das vollständig in ARM-Assembler und BBC BASIC geschrieben wurde. Die Desktop-Umgebung war durch ihr modulares Fenster-Management und Drag-and-Drop-Bedienung ihrer Zeit voraus. Besonders hervorzuheben war die konsequente Integration der Anwendung mit dem Dateisystem über sogenannte „Application Directories“. In der Presse wurde dies gelobt: „RISC OS remains a highly productive environment, despite the dominance of Windows 95. The Archimedes still feels faster and cleaner.“ schrieb das britische Magazin Acorn User im November 1995.
Die Bildschirmauflösungen reichten je nach angeschlossenem Monitor und VRAM-Konfiguration von 640×480 bis zu 1024×768 bei 256 Farben. Dank des integrierten Videokerns im ARM7500 war der A7000 in der Lage, bis zu 16 Millionen Farben darzustellen, allerdings nur in niedrigeren Auflösungen und bei ausreichendem VRAM. Standardmäßig wurden 256 Farben verwendet – ausreichend für die meisten Anwendungen im Bildungsbereich, aber nicht für grafikintensive Software. Der Soundchip war in den ARM7500 integriert und bot 8-Bit-Stereoausgabe mit bis zu vier Kanälen. Klanglich übertraf der A7000 viele integrierte PC-Lösungen seiner Zeit, insbesondere durch geringere Latenz und klare Signalverarbeitung, wenngleich keine dedizierte Hardware für Effekte oder MIDI integriert war.

Anschlusstechnisch bot das System zwei serielle Ports, einen parallelen Port, analoge und digitale Monitorausgänge, Audioanschlüsse für Lautsprecher, Mikrofon und Kopfhörer sowie Maus- und Tastaturports. Erweiterungskarten konnten über einen internen Pod mit Risercard angeschlossen werden, was spätere Nachrüstungen mit SCSI, Netzwerkkarten oder Genlock-Lösungen ermöglichte. Optional geplante Peripheriegeräte wie ein TV-Out-Modul oder spezielle Scannereinheiten kamen jedoch nicht offiziell auf den Markt, auch wenn Drittanbieter Lösungen anboten.

Hinter der Entwicklung des A7000 stand ein Team unter Leitung von Steve Furber, der zusammen mit Sophie Wilson bereits den ursprünglichen ARM-Prozessor für den BBC Micro entworfen hatte. Furber, ein promovierter Elektrotechniker der Universität Cambridge, war bekannt für seine Philosophie der einfachen, eleganten Hardwarelösungen, während Wilson durch ihre Arbeit an BBC BASIC und dem frühen ARM-Instruction Set Pionierarbeit im Bereich effizienter Mikroarchitekturen leistete. Beide arbeiteten seit den frühen 1980er-Jahren bei Acorn und prägten die DNA der Firma entscheidend. Weitere Beteiligte waren unter anderem Mike Muller, der später Mitbegründer von ARM Holdings wurde.

Verkaufszahlen des A7000 lassen sich nur schätzen, doch laut einem Bericht im Daily Telegraph von 1996 wurden über 25.000 Einheiten allein im britischen Bildungsbereich verkauft. Der Computer war insbesondere in Schulen beliebt, wo seine Robustheit, das leise Betriebsverhalten und die einfache Wartung geschätzt wurden. Im Vergleich zu PCs mit Windows 95 war der A7000 in der Bootzeit, Bedienbarkeit und Wartung oft überlegen – allerdings hinkte er in der Softwareauswahl deutlich hinterher. Während der A7000 im professionellen Bildungssektor punktete, war er für Privatanwender im Multimedia- und Spielebereich weniger attraktiv, was seine Verbreitung außerhalb von Schulen bremste.

Ein Zitat aus dem Acorn-Pressebüro von 1996 bringt die Philosophie des A7000 auf den Punkt: „The A7000 was never meant to compete in raw speed. It's about stability and purpose.“ Und genau dafür stand er – als stabiler, eleganter Computer mit klarem Fokus. Auch wenn er dem internationalen PC-Markt nicht standhalten konnte, bleibt der A7000 ein letzter Meilenstein der britischen RISC-Computer-Ära, geschätzt für seine Ingenieurskunst, Klarheit und die leise Souveränität einer Architektur, die nie auf den Massenmarkt schielte, sondern auf Langlebigkeit und Klarheit.

Les Manley in: Search for the King

Das unter dem Label Accolade entwickelte Adventure "Les Manley in: Search for the King" erschien 1990 für MS-DOS und Amiga und markierte den Einstieg der lockeren, erwachsenen Spielreihe rund um dena tollpatschigen Videotechniker Les Manley, der magenkribbelnd auf der Suche nach Elvis („The King“) quer durch Amerika reist. Designer Steve Cartwright, der zuvor bekannt war für Actiontitel wie Ice Hockey und Seaquest von Atari, bekam bei Accolade ab 1988 endlich freie Hand, ein vollwertiges Sierra ähnliches Adventuresystem zu entwickeln. Zusammen mit Michael Berlyn (Infocom Veteran, verantwortlich für Suspended und Infidel) entwarf er den Adventure Programming Engine, der handgepixelte Charakteranimationen über gemalte Hintergründe legte und mit 1.500 Parser Kommandos ausgestattet war. In einem frühen Interview schwärmte Cartwright: „Ich wollte ein Text-Adventure mit Grafik erschaffen – den ultimativen Parser, der auch Humor transportiert“. Die künstlerische Federführung lag bei Justin Chin (später Art Director bei Star Wars: Dark Forces) und Bonnie Borucki (Animation bei Leisure Suit Larry II). Weitere Crewmitglieder waren Grafikprogrammierer wie Russell Shiffer (Score für Test Drive II/III).

Die Entwicklung nahm etwa anderthalb Jahre in Anspruch, teils durch die Integration von Realfilmsequenzen. So wurde eine Mitarbeiterin für eine Szene vor einem Wasserspender gefilmt und dann digitalisiert, also das Video, nicht die Mitarbeiterin, denn wir leben nicht in der Welt von Tron. Diese Technik wurde Anfang der 1990er in mehreren Spielen erprobt, bevor sie durch Full-Motion-Video (FMV)-Sequenzen in Spielen wie Phantasmagoria oder Night Trap weiterentwickelt wurde. Bei Les Manley sah man oft posierende Figuren mit echten Gesichtern, die dann mit digitalisierten Hintergründen kombiniert wurden. Die Technik wirkte teils steif, aber galt damals als ambitionierter Versuch, Filmästhetik ins Gameplay zu integrieren.

Les Manley erschien in einer Boxversionen mit 5,25″- und 3,5″-Disketten, Gimmicks, etwa einen fiktiven Boulevard-Zeitungsausschnitt, der auf die Handlung einstimmte, einem Decoderblatt (oft mit Rotfilter zur Lesbarmachung bestimmter Hinweise), sowie weiteren gedruckten Materialien, die das Flair einer Elvis-Verschwörung transportieren sollten. 1991 erschien dann auch eine Portierung für den Amiga.
Optisch glänzte das PC Original, das mit 70 Bildschirmlocations in vier Hauptgebieten (New York, Zirkus, Las Vegas, Graceland Verschnitt „The Kingdom“) aufwartete, teilweise mit überraschend hintergründiger Animation und Cameo Auftritten (Bart Simpson auf einem Skateboard!). Doch technische Makel wie Ladezeiten von bis 20 Sekunden je Szene und einem strikt parserbasierten Interface – bei dem eine Bananenübergabe nur bei präzisem Wortlaut funktionierte – polarisierte die Spielerschaft deutlich. Nostalgiker auf Reddit echauffierten sich dennoch: „Search for the King ist eines der ersten Adventure Games, die ich gespielt habe … die Eröffnungsszene bleibt im Kopf“.

Marktwirtschaftlich erreichte Accolade mit Les Manley solide Erfolge. Konkrete Verkaufszahlen wurde jedoch selten publiziert, doch der kritisch lobende Kommentare, wie beispielsweise jener von Computer Gaming World: „Accolades unverhohlener Versuch, Sierra’s Leisure Suit Larry zu kopieren, hat ordentlich funktioniert“ spricht von sichtbarem Erfolg. Die internationale Presse war geteilter Meinung: Amiga Power vergab 71 %, lobte Grafik, bemängelte das Interface und „humoristische Hürden für ein britisches Publikum“. Adventure Classic Gaming urteilte später, dass die „witzigen aber episodischen Events“ gelegentlich kontextlos wirkten und dadurch narrativ stockten. Technisch betrachtet war das Game ein Zwitter: Im Vergleich zur Sierra Konkurrenz war der Adventure Programming Engine visuell moderner und bot flüssigere Animationen. Parsertechnisch jedoch blieb er antiquiert, fehlende optionales Point and Click-Verhalten entging nicht der Kritik. Soundeffekte fehlten bei der DOS Fassung; die Amiga Version konnte zwar Musik bieten, doch auch die sei „nichts Herausragendes“, so ein damaliger Test von Amiga Power. 2020 veröffentlichte Ziggurat Interactive beide Titel legal via GOG.com als Remasters, zusammen im Bundle verfügbar.

Zusammenfassend bleibt Les Manley in: Search for the King ein charmantes, technisch ambitioniertes und gleichzeitig missglücktes Adventure Experiment: visuell stark, narrativ fragmentiert – aber genügend Kult, um auch heute noch gespielt zu werden. Es bleibt als Accolade’s mutiger Gegenentwurf zur Sierra Dominanz erhalten – mit Wortwitz, Schamlosigkeit und einem gehörigen Schuss Elvis Wahnsinn.

Thrustmaster FCS

Der Thrustmaster Flight Control System (FCS) Mark I erschien 1992 als hochwertiger PC-Joystick im F‑16-Phantom-Stil und gilt als erste echte Flight-Yoke-Steuerung für Flugsimulatoren am PC. Entwickelt unter der Leitung von Norm Winningstad – einem Mitgründer von Thrustmaster im Jahr 1990 in Oregon – vereinte das FCS robuste Materialien und realistische Technik: Ein einseitiger Haltegriff mit Fingerschlaufen, getragen von massivem Kunststoffboden mit schwerer Metalplatte, vermittelte das Gefühl eines echten Kampfjets. Ein zeitgenössischer Test befand sogar, das FCS sei „wahrscheinlich der authentischste Joystick, der für Computer erhältlich ist“. Der Stick verfügte über drei Achsen (Quer-, Hoch- und Drehachse) sowie vier Feuertasten, die computergestützt per Keyboard-Interface ausgegeben wurden.

Als zweiter Bestandteil des Thrustmaster-HOTAS-Konzepts ergänzte ab 1992 das Weapons Control System (WCS) den FCS. Dabei handelte es sich um einen seitlichen Schubhebel mit sechs Tasten und einem 3‑Positionen-Schalter im Layout eines Kampfflugzeugs. Der Gashebel besaß reale Rastpositionen (Vollgas und Nachbrenner): Man schob ihn zur ersten Blockade für Volllast und darüber hinaus für Nachbrennerbetrieb. Seine Tasten und Kippschalter übermittelten je nach Flugprogramm Funktionen wie Kontermittel, Waffenwechsel, Luftbremse oder Klappen. Technisch war das WCS ein reines Tastaturgerät: Es steckte zwischen PC und Tastatur und emulierte alle Steuerbefehle als Tastaturcodes. Diese Bauweise machte Treiber überflüssig (das System lief unter DOS/Windows einfach auf dem Keyboard-Port), hatte aber Nachteile: Die Gasstellung wurde durch mehrere Tastendrücke dargestellt, nicht durch ein kontinuierliches Signal. Vergleichstests bemängelten, der WCS sei „nicht so reaktionsschnell wie die analoge Trimmung“ etwa des CH-FlightStick. Zudem war pro Spiel ein Satz DIP-Schalter am WCS zu setzen, um die korrekten Befehle zu wählen, und bei Bedarf musste ein Austausch des ROM-Chips erfolgen, um neue Spiele zu unterstützen.

Anschlüsse und Betrieb: Das FCS selbst wurde über einen 15‑poligen Spielport-Stecker am Soundkarten- oder Joystickport angeschlossen. Beim Einsatz zusammen mit dem WCS wurde das FCS-Kabel in eine Buchse am WCS gesteckt; der WCS seinerseits nutzte den 5‑poligen AT-/PS/2-Tastaturanschluss. Auf alten AT-Systemen konnte man direkt andocken, bei PS/2-Rechnern war jedoch ein Adapter erforderlich. In dieser Hardwarekonstellation benötigte das FCS/WCS kein eigenes Betriebssystem oder spezielle Treiber – es funktionierte plattformunabhängig unter DOS und Windows, solange Spielport und Tastaturport verfügbar waren.

Thrustmaster bot neben FCS und WCS 1992 auch ein Ruderpedalsystem (Rudder Control System, RCS) an, das über den Spielport die Pedale und Haupteinheit verband. Später erschienen verbesserte Versionen: 1993 kam das programmierbare Pro Flight Control System (FCS Mark II) mit optimierten Komponenten, 1994 das luxuriöse F-16 FLCS mit Metallbau und Komplettprogrammierung, und 1997 folgte der WCS II mit analogem Gas und Software-Unterstützung. Zusätzlich wurden über die Jahre „Elite“-Ruderpedale und Multi-Port-Adapter angeboten, um mehrere Thrustmaster-Geräte gleichzeitig zu betreiben.

Preis und Wertentwicklung: Beim Start kostete das FCS/WCS-Komplettpaket rund 170 britische Pfund (etwa 240 DM bzw. 120 € 1992). Aufgrund hoher Inflation in den 1990er Jahren entspricht dies inflationsbereinigt etwa 320 € heute. Einzelpreise lagen entsprechend niedriger (z.B. etwa 79 US-$ für den WCS). Offizielle Stückzahlen sind nicht bekannt, aber Thrustmaster selbst erzielte durch die FCS-/WCS-Produktreihe raschen Erfolg: Der Gesamtumsatz stieg von etwa 15 Mio. $ (1995) auf 25 Mio. $ (1998).

Rezensionen und Anekdoten: Fachpresse und Anwender schwärmten von dem realitätsnahen Fluggefühl. Ein Computermagazin schrieb 1992 etwa, dass es eine „ganz andere Erfahrung“ sei, mit Stick und Schubhebel zu fliegen, statt unzählige Tastaturbefehle zu hämmern. Solche Begeisterung teilten viele Piloten: Der direkte Vergleich zeigte laut Testberichten, dass sich ein echtes Hands-On-HOTAS anders anfühlt als die herkömmliche Tastatursteuerung, die durch FCS/WCS in Flugsimulatoren abgelöst wurde.

Entwickler und Hintergrund: Thrustmaster war ein US-Unternehmen im Silicon Forest von Portland (Oregon), das sich ab 1990 auf hochwertige Joysticks spezialisierte. Gründer Norm Winningstad und sein Team brachten das FCS auf den Markt und etablierten damit die Marke bei Flugsimulations-Enthusiasten. 1999 wurde Thrustmaster vom französischen Guillemot-Konzern übernommen, der das Gaming-Zubehör weiterführte – die frühen HOTAS-Konstruktionen wie das FCS blieben dabei als Aushängeschild erhalten.

Gegenüber herkömmlichen 2‑Achsen-Joysticks (z.B. Microsoft SideWinder oder Logitech) bot das Thrustmaster-System deutlich mehr Achsen, Tasten und ein realistisches Handling. Zum Konkurrenten CH-Flightstick bestand folgender Unterschied: CH kombinierte meist einen einzelnen Stick mit separat angebrachtem Dreh-Gasrad und drei Trimmern, während Thrustmaster mit FCS/WCS ein gemeinsames HOTAS-Paar lieferte. Der CH-Joystick arbeitete analog und bot flüssige Gas-Übergänge, das Thrustmaster-WCS hingegen emulierte per Tastaturtasten, was zwar weniger präzise war, dafür aber mehr Bedienknöpfe pro Hand und einen festen Nachbrenner-Raster ermöglichte. Zudem fehlten beim FCS-Triebwerksgriff Hardware-Trimmer (z.B. für Ruder), diese mussten in der Simulation programmiert werden. Trotz dieser Schwächen waren sich Tester einig, dass die hochwertige Mechanik und das Kampfjet-Design das FCS deutlich überboten: Es bot eines der besten Fluggefühl seiner Zeit und setzte neue Maßstäbe für PC-HOTAS-Systeme.

Yashica YC 64

Der Yashica YC 64 wurde 1984 von Kyocera unter der Marke Yashica als MSX 1 Heimcomputer auf den europäischen Markt gebracht und erschien Ende 1985 offiziell auch in Frankreich . Sein Gehäuse in ungewöhnlichem Rotbraun stach sofort ins Auge – eine bewusst jugendfreundliche Designentscheidung, die ihn von anderen MSX Geräten abhob. Der Preis lag bei etwa 950 DM (rund 798 DM laut MSX Wiki für Deutschland). Umgerechnet und inflationsbereinigt entspräche das heute etwa 400–450 €, was ihn als gehobene Mittelklasse positionierte. Der MSX-Standard versprach einheitliche Kompatibilität, einen großen Softwarepool und internationale Anschlussfähigkeit – ein attraktives Feld für Firmen, die bislang mit Computern wenig zu tun hatten. In Deutschland stellte das Magazin Happy Computer fest : „Wer ›nur‹ ein MSX Gerät ohne Schnörkel und mit viel Speicher sucht, ist mit dem YC 64 ausreichend bedient“

Yashica, in Japan renommiert für Präzisionsoptik und mechanische Kameras, wählte den YC-64 als Einstieg in die neue Heimcomputerwelt. Technisch basierte der Rechner auf der MSX-1-Spezifikation, was ihm auf dem Papier dieselben Fähigkeiten wie Modelle von Sony, Yamaha, Sanyo oder Canon verlieh. Doch trotz des Standards hatte jeder Hersteller Gestaltungsspielraum – und Yashica nutzte diesen in Form eines robusten, fast nüchternen Gehäuses und eines sauberen Board-Designs, das auf langfristige Zuverlässigkeit hin optimiert war.

Im Inneren arbeitete ein Zilog Z80A-kompatibler Prozessor, meist ein NEC D780C-1, mit einer Taktfrequenz von 3,579 MHz. Diese CPU, ein echter Veteran der 8-Bit-Ära, war für die Ausführung des Betriebssystems – MSX BASIC v1.0, lizenziert von Microsoft – und aller Software verantwortlich. Für die grafische Ausgabe kam der Texas Instruments TMS9929ANL zum Einsatz, ein PAL-kompatibler Video Display Processor (VDP), der aus der TMS9918-Reihe stammte. Der Chip konnte 256×192 Pixel mit 16 vordefinierten sichtbaren Farben darstellen– eine für 1984 respektable Leistung, wenngleich sie im Vergleich zu den bitplangetriebenen Systemen wie dem Atari 800 oder dem Amstrad CPC bald altbacken wirkte. Der Sound wurde durch den AY-3-8910 von General Instruments erzeugt – einen Drei-Kanal-Soundchip, der auch in Arcade-Automaten und Heimcomputern wie dem Amstrad CPC oder dem ZX Spectrum 128 seinen Dienst tat. Damit konnte der YC-64 Musik mit drei unabhängigen Stimmen sowie ein Rauschsignal erzeugen, was für viele Spiele der Zeit völlig ausreichte.

Der Computer verfügte über 64 KB RAM – wie es der Name suggeriert – sowie 16 KB VRAM für die Grafikdarstellung. Er besaß zwei MSX-Cartridge-Slots, einen RGB-Video-Ausgang, einen HF-Modulator, einen Anschluss für ein Kassettenlaufwerk zur Datenspeicherung, ein Centronics-kompatibles Druckerinterface, sowie zwei standardisierte MSX-Joystick-Ports. Optional geplant, aber kaum dokumentiert, waren ein 3,5-Zoll-Diskettenlaufwerk, ein Datenrecorder und ein Yashica-eigenes ROM-Modul mit Bildbearbeitungsfunktionen, das jedoch nie den Prototypstatus verließ. Der Bildschirmmodus erlaubte neben Textdarstellung auch Sprites und Hintergrundlayer – allerdings waren alle Grafikebenen durch den VDP hardwareseitig begrenzt, was sich etwa bei der Zahl von maximal 4 Sprites pro Scanline bemerkbar machte.

Das Betriebssystem des YC-64 war, wie bei allen MSX-1-Rechnern, ein modifiziertes Microsoft BASIC mit grafischen Erweiterungen. Es war in ROM untergebracht und bot neben üblichen BASIC-Befehlen auch Sprachbefehle zur Spritedarstellung, zur Kollisionsabfrage und zur Musikprogrammierung. Eine typische Softwaredistribution erfolgte über Cartridges oder Kassetten, die problemlos auf anderen MSX-Geräten liefen – das war der große Vorteil des Standards. Der Preis für den YC-64 betrug in Japan umgerechnet etwa 45.000 Yen. Inflationsbereinigt entspricht das im Jahr 2025 einem Betrag von ca. 280 €, wobei die Preise regional schwankten und das Gerät in Europa kaum offiziell vertrieben wurde.

Entwickelt wurde das Gerät im Auftrag von Kyocera, das bereits OEM-Erfahrung mit Computern gesammelt hatte. Yashica fungierte vor allem als Marke und Vertrieb. In Frankreich wurde das Gerät unter dem Label Triumph-Adler vermarktet, was zur geringen Verbreitung beitrug, denn der französische MSX-Markt wurde schnell von Philips und Sony dominiert. Die Verkaufszahlen des YC-64 waren entsprechend gering: Schätzungen gehen von weniger als 25.000 verkauften Einheiten weltweit aus. Eine Veröffentlichung in Großbritannien, wo MSX ebenfalls Fuß fassen sollte, unterblieb. Zeitgenössische Presseberichte erwähnten das Gerät nur am Rande – so schrieb die französische Zeitschrift "Hebdogiciel" im Jahr 1985: „Der YC-64 ist gut gebaut, aber zu konventionell, um hervorzustechen. Seine Tastatur ist angenehm, aber ihm fehlt eine echte Persönlichkeit.“

Zu den Entwicklern des Geräts gehörte ein kleines Team von Kyocera-Ingenieuren unter Leitung von Shigeru Yoshida, einem ehemaligen Designleiter bei Sanyo, der sich mit der Miniaturisierung von Schaltkreisen befasste. Yoshida wurde später als Mitentwickler des ersten Kyotronic-Laptops (dem KC-85) bekannt, der als Vorlage für den Tandy 100 diente. Der VDP wurde von TI in Zusammenarbeit mit Yamaha abgestimmt, letztere war ebenfalls stark in der MSX-Spezifikation engagiert. Der Soundchip Entwickler, Paul Zoulidjian, war zuvor bei GI und später bei Microchip Technologies tätig. Er entwarf 1983 den AY-3 8910 und hatte maßgeblichen Einfluss auf das Klangbild ganzer Heimcomputer-Generationen.

Gegenüber der Konkurrenz bot der Yashica YC-64 kaum Alleinstellungsmerkmale. Verglichen mit dem Philips VG-8020 oder dem Sony Hit-Bit HB-75 war er solide, aber uninspiriert. Es fehlte ein eingebauter Datenrecorder, ein zweizeiliges Display oder ein grafisch gestaltetes OS-Menü. Gegenüber dem Spectravideo SV-328, einem Vorläufer des MSX-Standards, war der YC-64 preislich günstiger, aber technisch konservativer. Auch gegenüber dem Commodore 64 konnte das Gerät wenig ausrichten – der C64 hatte besseren Sound, hardwaregestützte Scrolling-Effekte und eine lebendige Spiele-Szene.

Der YC-64 verschwand rasch vom Markt. Die endgültige Aufgabe des Heimcomputerfeldes durch Yashica erfolgte 1986, als die Kameraentwicklung wieder in den Fokus rückte. Nach dem Aufkauf von Yashica durch Kyocera im selben Jahr wurde jegliche Computertätigkeit eingestellt. Der YC-64 blieb somit eine einmalige Episode, heute ein gesuchtes Sammlerstück. Es existieren Nachbauten in Form von OpenMSX-kompatibler Hardware oder als Eintrag in MSX-Emulatoren. Aufgrund der standardisierten MSX-Struktur ist der YC-64 vollständig emulierbar.

Eine kleine Fangemeinde in Frankreich betreibt heute Webseiten, die sich mit seltenen MSX-Modellen beschäftigen. Auf MSX.org finden sich Scanbilder des Motherboards, ROM-Dumps und sogar alternative Keyboard-Mappings für moderne Emulatoren. Die Community schätzt den YC-64 heute weniger für seine Funktionen, sondern mehr als technisches Zeitdokument: eine ambitionierte Kamera-Firma, die kurzzeitig in die Welt der Bits und Bytes eintauchte – und ein Gerät schuf, das funktionierte, aber im Schatten seiner berühmteren MSX-Brüder unterging. Ein ehemaliger Yashica-Mitarbeiter schrieb in einem Forenbeitrag 2011: „It worked. It did everything it was supposed to. But it never felt like ours. We were lens engineers trying to play computer.”

Ohio Scientific C2