Kategorie: Hardware

Sekunden? Minuten? Egal!

hubersn

Man geht ja als ITler gerne mit der Zeit. Mindestens, um sich dann darüber aufzuregen, dass früher alles besser war.

Neulich habe ich einen neuen Drucker in Betrieb genommen. Geht jetzt per App. Klingt nach einer guten Idee, und war es letztlich auch. Aber zwischendrin dann etwas Schockierendes: bei der Erstbefüllung der Tintentanks kündigte die App an, dass das Befüllen einer Farbe (bei meinem Modell insgesamt 6) nicht weniger als 40 Minuten dauern soll. Gott sei Dank nur eine falsche Einheit in der App, die gedruckte Schnellanleitung sprach dann korrekt von 40s, und genau so war es.

Weiterer kleiner Zwischenfall: während der Drucker dann die Tinteninitialisierung vornimmt, schlägt die App vor, doch gleich mal währenddessen (der Initialisierungsvorgang dauert nicht weniger als 7 Minuten) das WLAN einzurichten. Gute Idee. Dazu braucht man das Admin-Passwort des Druckers. Das steht nur im Innern des Druckers (beim Anheben der kompletten oberen Einheit). Das Anheben ist aber genau das, was man während der Tinteninitialisierung AUF GAR KEINEN FALL machen darf, wie der Drucker auf seinem Display verkündet. Sagt einem die App aber nicht. Aber der erfahrene Installateur elektrischer Geräte hat vorher natürlich alle papiernen Handbuchfetzen (die meisten davon mit völlig überflüssigen Sicherheitshinweisen der Kategorie “Gerät eingesteckt nicht unter Wasser betreiben” oder “auf Frequenz 2400 MHz wird mit 53 nW gesendet”) akribisch durchgearbeitet und hat deshalb das Passwort schon vorher notiert. Auch merkwürdig in der App: man hat es für notwendig erachtet, eine eigene Tastatur zu implementieren. Die echt komisch aussieht. Und für die Eingabe sicherer Passwörter gar nicht taugt. Aber man kann einfach auf die Standardtastatur zurückschalten. Könnte für den unbedarften Anwender aber schon eine Extrahürde sein, und der Sinn dahinter erschließt sich mehr jetzt nicht so direkt.

Auch eine App löst halt nicht automatisch alle Probleme, vor allem wenn vom Hersteller schlampig gearbeitet wird. Drucken tut er aber gut. Und das ist in diesem Falle wirklich die Hauptsache.

Apple setzt auf ARM

hubersn

Auf der WWDC (die jährliche Apple Entwickler-Konferenz) wurde in der Keynote wie schon seit Längerem allgemein erwartet (erste Gerüchte etwa seit 2011) verkündet, dass zukünftige Macs als CPU ein selbstentwickeltes SoC auf ARM-Basis enthalten werden. Höchstwahrscheinlich ein performanceoptimierter Abkömmling der A12Z-und-Nachfolger-Reihe aus dem iPad Pro.

Viel wurde schon geschrieben über Apples erneuten Pferdewechsel bei der CPU für seine Desktoprechnerlinien – MOS 6502 im Apple I und II, Motorola 68xxx im Mac der ersten Generation, Motorola/IBM PowerPC in den PowerMacs ab Mitte der 90er, und schließlich Intel x86/x64 seit Mitte der Nullerjahre. Und jetzt also ARM. Für alle historisch interessierten schließt sich damit der Kreis, der mit der Ausgründung von ARM Ltd. aus Acorn als Joint Venture mit Acorn und VLSI Anfang der 90er begann, und Apple den ARM610 als CPU im Newton PDA einsetzte – damals mit mageren 20 MHz getaktet, der finale Newton hatte dann einen schnellen StrongARM intus.

Meine Einlassung hier soll auch nicht als Expertenmeinung im MacOS-Universum eingestuft werden – ich habe wenig Plan von und Einblick in MacOS und der derzeit dort so eingesetzten Software. Der Presse entnehme ich, dass im Prinzip ausschließlich mit den MacBooks der Gewinn eingefahren wird und der Rest eher so nebenher läuft. Das traditionelle Profilager der Kreativen, von DTP über Illustrationen bis Bitmap-Bearbeitung scheint im großen Spiel der Dinge inzwischen eher nachrangig. Photoshop, Final Cut Pro, InDesign, Illustrator, QuarkXPress, Premiere Pro, Finale…sowieso allesamt auch unter Windows erhältlich und wohl nicht mehr der entscheidende Faktor bei der Useranzahl und damit auch dem Umsatz. Die Lifestyle-Kundschaft, die einfach alles aus dem Apple-Universum kauft was nicht bei drei auf dem Baum ist – von MacBook über iMac, Apple Watch, HomeKit, iPhone bis iPad und Apple TV – ist der Umsatztreiber.

Was treibt also Apple zu diesem Wechsel, der ja nicht ohne Risiko ist? Ich kann da einige Gründe ausmachen. Wie man die jeweils gewichtet, liegt im Auge des Betrachters. Wir werden erst hinterher schlauer sein.

Zunächst ganz schnöde: der Wechsel spart vermutlich einen Haufen Geld. Intel-CPUs sind ja doch eher teuer, und Apple musste immer Chipsätze und Zusatzchips drumrum entwickeln oder zukaufen. Die ARM-Entwicklung erfolgt ja sowieso aufgrund von iPhone und iPad, warum dann nicht etwas nach oben skalieren. In Zeiten von “viele Cores helfen viel” ist ein ARM-Core da sicher keine unbedingt schlechte Basis. Es heißt ja, dass die letzte Inkarnation des iPad Pro CPU- und GPU-technisch mit den mobilen Core i-CPUs locker mithalten kann.

Wichtig erscheint mir auch, dass Intel in den letzten Jahren seinen ehemaligen Vorsprung bei der Prozesstechnik eingebüßt hat. Die Auftragsfertiger wie TSMC oder Samsung haben Intel mindestens eingeholt, eher überholt. Angeblich hat TSMC den 3nm-FinFET-Prozess 2022 produktionsreif. Allerdings ist das nicht ohne Risiko, denn andere große Auftragsfertiger haben beim großen Technologierennen schon abreißen lassen müssen – Globalfoundries dürfte der bekannteste Fall sein, früher ganz vorne dabei als Ausgründung von AMD, aber inzwischen nur noch Massenfertiger ohne Spitzenfertigungstechnologie. Jedenfalls ist die Verfügbarkeit von Auftragsfertigern mit topaktueller Prozesstechnologie eine Voraussetzung für den Erfolg von “fabless CPU designers” wie ARM, Qualcomm, Apple oder AMD. Dass dieses Pendel mal wieder in Richtung Intel zurückschwingt ist jetzt nicht völlig ausgeschlossen.

Viel wird über die Vereinheitlichung der Plattformen iOS und macOS geschrieben. Aus meiner Sicht ist das ein schwaches Argument, denn wo genau ist denn hier die zugrundeliegende CPU-Architektur entscheidend? Entscheidend ist doch hier vielmehr, ob sich die Benutzeroberflächen angleichen und das Software-Ökosystem aus Bibliotheken und Frameworks möglichst identisch ist. Ob dann am Ende der Compiler x86-Code oder ARM-Code draus macht, ist doch weitgehend irrelevant. Vielleicht werden die allermeisten Programme bis in 10 Jahren sowieso alle im Browser laufen und in JavaScript und WebAssembly geschrieben sein, dann haben sich solche Details eh erübrigt.

Ein aus meiner Sicht wichtigeres Argument ist, dass sich Apple der einfachen Vergleichbarkeit – besonders was den Preis angeht – seiner Hardwareplattform entzieht. Heutzutage ist komplett transparent, dass Apple gegenüber der x86-Welt für seine MacBooks einen nicht unerheblichen Aufpreis nimmt, der sich nicht in erhöhter CPU- oder GPU-Leistung niederschlägt. Der Wechsel zu ARM nützt hier zweifach: zum einen kann Apple sehr einfach Coprozessoren aller Art im SoC unterbringen, die speziell auf die neueste Modeerscheinung der IT hingedengelt wurde – sei es Spracherkennung, Bildverarbeitung, Video-Encoding oder irgendwas-mit-KI. Zum anderen kann Apple zukünftige Herausforderungen durch einen cleveren Mix aus Software und Hardware erschlagen, ohne dass jemand genau abgrenzen kann, ob jetzt die geniale Programmierung oder die geniale Hardware letztlich verantwortlich ist.

Dadurch, dass Apple von ARM eine Architektur-Lizenz hat, also völlig eigenständige Cores entwickelt und nicht auf die fertigen Cortex-Axx- oder Neoverse-Cores zurückgreifen muss, können die CPUs für MacOS und den muss-nicht-unbedingt-allzu-stromsparend-sein-Anwendungsfall maßgeschneidert werden. Das ist bei iOS ja auch passiert – während die Android-Fraktion eher auf viele Core gesetzt hat, hat Apple eher die Single-Core-Leistung in den Vordergrund gestellt. Welche Reserven die Architektur hat, wenn man die TDP in Richtung Intel Core i9 erhöhen kann, bleibt abzuwarten. Der A12Z mit 8 Cores in big.LITTLE-Konfiguration, je 128 KiB 1st level instruction und data cache und 8 MiB 2nd level cache ist ja noch eher auf Sparsamkeit und lüfterloses Design ausgelegt. Bechmarks sahen den A12Z ja ungefähr auf Augenhöhe eines Mobile-i5 mit integrierter Intel-Grafik. Technisch ist das der Stand von 2018, da der A12Z nur ein leicht erweiterter A12X ist. Mal sehen, mit was Apple um die Ecke kommt, wenn es ernst wird mit dem ersten MacBook-on-ARM.

Apple hat in der Vergangenheit durch das Backen ganz eigener Brötchen ja große Erfolge gefeiert und ein immer geschlosseneres Ökosystem geschaffen. iOS, Objective-C, Swift, Metal, Apple Store, iTunes, Apple TV, HomeKit – solange die Nutzeranzahl eine kritische Masse überschreitet und das Ökosystem technisch und aus Anwendersicht plausibel bleibt, ist es eine clevere Art von “Vendor Lock-In”.

Ein Risiko der Apple-Strategie steckt natürlich in dem, was in der Industrie unter “zu große Fertigungstiefe” läuft. Apple muss alles selbst entwickeln, vom Betriebssystem (iOS und MacOS) über CPU, GPU und Zusatzprozessoren bis hin zu Compilern (Objective-C, Swift) und natürlich der Hardware selbst. Das birgt eine irre Komplexität und hohen Aufwand in sich, um in jedem einzelnen Bereich Spitze oder zumindest nahe dran zu sein. Firmen, die das früher mal versucht haben, waren dauerhaft nicht erfolgreich (Sun, SGI, Acorn, mit Abstrichen auch die klassischen Heimcomputerhersteller wie Commodore und Atari).

Eine gewisse Ironie steckt im Zeitpunkt des jetzt angekündigten Wechsels. Gerade hat – dank AMD – die x86-Welt wieder deutlich an Schwung gewonnen nach fast einem Jahrzehnt gefühlter Stagnation. Ein wenig vergleichbar mit dem damaligen Wechsel von PowerPC zu Intel, als kurze Zeit später IBM ein wahres Feuerwerk an High-Performance-PowerPCs abbrannte. Aber wie wird es sich längerfristig entwickeln? Apple hat auf jeden Fall genügend finanzielle Ressourcen, um seine ARM-SoCs auf Augenhöhe mit den x86-CPUs von Intel und AMD weiterzuentwickeln. Aber das alleine ist keine Garantie, wie man gerade an Intel sieht, die trotz gigantischer finanzieller Ressourcen eher alt gegen AMD aussehen. Kopf schlägt Kapital, zumindest manchmal – oder wie jeder Fußballfan weiß: “Geld schießt keine Tore”, und trotzdem heißt der Deutsche Meister auch 2020 wieder Bayern München. Und andererseits ist Freiburg auf einem einstelligen Tabellenplatz in der Bundesliga, während der Hamburger SV, der VfB Stuttgart und Hannover 96 in der zweiten Liga spielen. Es bleibt also spannend.

MISTer-Fortschritte und die zweite Luft für MIST

hubersn

Schon lange nichts mehr zu MISTer und MIST geschrieben (zuletzt im Juni 2017). Dabei gibt es großartige Fortschritte bei beiden Projekten.

Der MISTer hat einen neu implementierten CPC-Core bekommen, der um Welten besser funktioniert als die alte, ursprüngliche Variante. MISTer-Mastermind Sorgelig hat viel Zeit darauf verwendet, besonders die CRTC-Implementierung (ein Motorola 6845, der in verschiedenen Varianten im CPC verbaut wurde, die sich alle in Kleinigkeiten unterscheiden, was von verschiedenen Demos auch weidlich ausgenutzt wird) und auch teilweise die Z80-Implementierung sowie die Floppy-Simulation (NEC 765), um endlich auch diverse Kopierschutzmaßnahmen sowie Sonderformate zu unterstützen.

MIST und MISTer profitieren gerade gemeinsam von einer Weiterentwicklung des Sega Genesis-Cores (für Europäer: Sega Megadrive), bei der unter anderem Sorgelig, GreyRogue und MIST-Mastermind Till Harbaum (“MasterOfGizmo” im Atari-Forum) zusammenarbeiten, nebst einem Spezialisten (“Jotego” im Atari-Forum) für die Soundchips des Genesis und mehreren Kennern der Originalspiele, die in langwierigen Testläufen die diversen Änderungen, die teilweise im Stundentakt gemacht werden, auf Regressions prüfen.

Im Zuge dieser Anpassungen und Weiterentwicklungen wurde auch für den MISTer eine neue Art des Scalings für den HDMI-Output implementiert auf Basis des “Nearest Neighbor”-Algorithmus, der diverse Artefakte des bisher benutzten Scalers verhindert (und dafür auf gewissen Hardware-Kombinationen aber auch neue Artefakte erzeugt). Das ist noch “work in progress” und derzeit eine Compile-Time-Einstellung, es sieht aber so aus wie wenn über zur Laufzeit ladbare Koeffizienten beide Skalieralgorithmen gleichzeitig im selben Core leben können. Und ein komplett neuer Scaler ist derzeit in Entwicklung – Stand heute ist die Scaler-Geschichte etwas unschön, weil sie spezielle IP erfordert, und diese nur für eher teure Quartus-Versionen (quasi die “Entwicklungsumgebung” für die Intel/Altera-FPGAs) verfügbar ist und die freien Versionen solche Cores nicht bauen können. Mit einem unabhängigen Open-Source-Scaler wäre dieses Hindernis auch aus dem Weg geräumt.

Lange Zeit fehlte ein Atari ST-Core beim MISTer – eigentlich die einzige große Lücke, alle anderen Cores waren längst auf dem MISTer portiert und teils sogar stark verbessert gegenüber ihrem MIST-Original. Und hier gibt es den vermutlich größten Fortschritt: ein komplett neuer Core namens FX CAST (von Jorge Cwik aka ijor im Atari-Forum), basierend auf einer zyklenexakten Nachbildung des Motorola 68000 und einer sehr präzisen Nachbildung von Grafik- und Soundchip. Die Sourcen dazu sind noch nicht offen, das soll aber demnächst so weit sein.

Also, ran an den MISTer, oder den alten MIST nochmal auspacken. Es gibt für den MIST inzwischen viele Cores, die das “Component out”-Kabel unterstützen, was es deutlich erleichtert, den MIST an einigermaßen aktuelle Fernseher oder Projektoren anzuschließen – bei vielen Bildgeräten hat “Component” neben HDMI als Input-Schnittstelle überlebt, während Scart-RGB mit der Lupe gesucht werden muss, genauso wie VGA-Eingänge mit ausreichender Flexibilität für die “krummen” Videosignale der diversen Cores.

Für den MISTer gibt es auch eine neue Version des USB-Hub-Boards mit der Wiederauferstehung des 9pol-Digital-Joystick-Anschlusses. Und es wird gerade mit Serial-to-MIDI experimentiert, um auch noch diese letzte MIST-MISTer-Lücke zu schließen.

Rundrum großer Fortschritt und viel Bewegung und Weiterentwicklung. Es ist eine Freude, das zu verfolgen, und ein schönes Beispiel für “Open Source funktioniert”. Besonders freue ich mich, dass Till wieder aktiv ins Geschehen eingreift, er klang zuletzt etwas negativ bezüglich der MIST-Zukunft (Produktion eingestellt, im Prinzip Abverkauf der letzten Exemplare, und Ärger mit Billig-Nachbauten wie Mistica die ihre Kunden im Regen stehen lassen). Er scheint wieder neue Energie gefunden zu haben.

Vom MIST zum MISTer

hubersn

Es gibt ein interessantes neues Projekt im MIST-Universum. Sorgelig, einer der aktivsten Core-Portierer und -Entwickler fürs MIST-Board, hat ein neues Projekt gestartet: der MISTer ist sowas wie ein Nachfolger für das MIST-Board, mit deutlich verbesserter Hardware, aber weitestgehend kompatibler Firmware und damit einer einfachen Möglichkeit, die verfügbaren MIST-Cores auf den MISTer zu portieren.

Warum überhaupt neue Hardware? Das MIST ist langsam an die Grenze seiner Leistungsfähigkeit angekommen. Atari ST und Amiga sind noch im machbaren Bereich, beim Acorn Archimedes wird es schon sehr knapp, und am Sega Megadrive scheitert man aktuell (einige Dinge laufen gut, andere weniger). Die Atari ST-Community träumt natürlich von einer Falcon-Nachbildung, was von den Experten für das MIST aufgrund mangelhafter Leistungsfähigkeit ausgeschlossen wird. Dazu kommt, dass der VGA-Ausgang des MIST ein ständiges Problem darstellt: der Core selbst muss sich darum kümmern, dass videotechnisch so einigermaßen was Kompatibles zu heute verfügbaren Monitoren oder Fernsehern rauskommt. Im MIST-Forum behandeln gefühlt 90% der Postings die Themen Scandoubler, Picture Centering und Konvertierung des analogen Videosignals nach HDMI. Fast alles am MIST ist Plug-and-Play, aber nicht die Bildschirmfrage.

Hardware-Basis des MISTer ist das Terasic DE10-nano-Board. 130 US$ kostet das Basis-Board, natürlich ohne Gehäuse oder ähnlichen Schnickschnack. Der zentrale FPGA-Baustein übertrifft den des MIST um Längen: ein Intel (ex-Altera) Cyclone V mit 110K LEs (MIST: Cyclone III mit 25K LEs), einem ARM Cortex-A9 mit 800 MHz (MIST: 48 MHz ARM), deutlich mehr internem Speicher, und der ARM kann deutlich enger mit dem FPGA-Teil kooperieren. Ein HDMI-Ausgang ist an Bord, es wird automatisch auf 720p skaliert. Per Daughterboard gibt es aber weiterhin Zugriff auf das analoge Signal der Cores nebst analogem Audio-Ausgang.

Während im MIST der ARM nur Steueraufgaben hatte – USB, Menü anzeigen, auf die SD-Karte zugreifen, I/O-Ports kontrollieren – kann im MISTer der ARM durch die enge Kopplung viel mehr Aufgaben übernehmen, sogar Teile der Emulation selbst. Vor allem für Dinge wie das Auslesen von Daten aus Floppy-Images oder ähnliches ist das ein Segen, weil man auf fertig verfügbare Bibliotheken zurückgreifen kann, wie sie auch gewöhnliche Emulatoren verwenden. Mit einem Cortex-A9, der auf nicht weniger als 1 GB RAM zugreifen kann, ist sowas kein Problem. Auf dem ARM läuft ein Minimal-Linux, so dass man auch auf vorgefertigte Treiber z.B. für USB-Devices zurückgreifen kann. Damit ist ein einfacher Weg geebnet, um einiges an Legacy-Hardware wiederzuerwecken, vom seriellen über den parallelen Port bis hin zu IDE oder Floppy (z.B. über Kryoflux).

Aus Entwicklersicht ist laut Sorgelig der größte Vorteil, dass man komfortabel in einer IDE wie Visual Studio die Firmware entwickeln kann und per Knopfdruck auf das Board deployed. Neben der Tatsache, dass die Hardware viel leistungsfähiger ist natürlich und man deshalb bei der Verwendung oder Portierung anderer FPGA-basierter Projekte nicht mehr so viele Handstände machen muss.

Das Projekt ist noch im Frühstadium. Die MIST-Firmware wurde erfolgreich portiert, einige Cores auch. Im Moment wird der Sega Megadrive-Core angepasst.

Gibt es andere Nachteile außer der Tatsache, dass sich das Projekt in einer unausgereiften Frühphase befindet? Der MISTer hat keine klassischen DB9-Joystickports und auch keine MIDI-Ports wie das MIST Plus (aber es gibt GPIO-Pins, die dafür verwendet werden könnten). Und man kann das Ding (noch?) nicht fertig kaufen inklusive Gehäuse. Beim MIST konnte man das Board noch komplett selbst bauen – Platine ätzen und bestücken, kein Problem (genügend Geduld und entsprechendes Equipment vorausgesetzt). Der MISTer-FPGA ist in BGA-Bauweise, so dass man zwingend ein professionell gefertigtes Board wie das Terasic DE10-nano als Basis verwenden muss.

Ich bin gespannt auf die weiteren Fortschritte des Projekts.

Neues vom MIST

hubersn

Ich hatte mich schon in früheren Beiträgen (hier, hier und hier). Speziell der Archimedes-Core liegt naturgemäß in meinem Fokus (siehe hier und hier).

Beim Archimedes-Core hat sich leider wenig getan, aber dafür hat sich im Rest der MIST-Welt erheblicher Fortschritt ereignet, über den ich kurz berichten will.

Zum einen gibt es jede Menge neue Cores. Der C16-Core gilt inzwischen als ausgereift und weitgehend komplett. Der VC20 steht nun auch als Core bereit. Und um die Commodore-Fraktion abzurunden, ist ein PET2001-Core gerade in der Mache. Bei den Arcade-Cores gibt es viele Neuzugänge – Galaga ist sicher das Highlight, viele weitere sind in der Pipeline. Bei den Spielkonsolen freuen wir uns auf den Sega MegaDrive (aka Genesis) Core – der macht schon einen guten Eindruck, aber die Soundunterstützung fehlt noch. Unter der Rubrik “Exoten” würde ich den Mattel-Aquarius-Core einordnen. Die Sinclair-Fraktion freut sich über den Spectrum-128K-Core und den Sam-Coupe-Core. Und noch was aus der Rubrik “Ultra-Exot”: der BK0011M aus Russland, quasi ein PDP11-Clone, gab sein Debüt.

Signifikante Fortschritte gab es beim Amiga-Core (Minimig-Aga) und beim Amstrad CPC-Core, der nun sowohl 60Hz-VGA- als auch 50Hz-TV-Ausgabe beherrscht. Auch der NES-Core hat eine Neuauflage erfahren. Der Atari800-Core kann nun 50Hz-PAL. Der MSX-Core kann auch mit der allerneuesten MIST-Auflage, wo wohl leicht verändertes SDRAM-Timing am Start ist, arbeiten.

Sorgelig hat sich um verbesserte Kompatibilität mit Bildschirmen gekümmert. Viele Cores unterstützen nun den 15kHz-Modus und erlauben eine Videoausgabe nicht nur per RGB für die Scart-Fraktion, sondern auch per YUV (auch als YPbPr oder Komponente bekannt). Das hat einige Vorteile. Während bei RGB via Scart strenggenommen nur PAL klassisch interlaced unterstützt war und die progressive-Ausgabe klassischer Computer und Konsolen mehr aus Versehen bei den typischen Röhrenfernsehern funktioniert hat, ist die progressive Ausgabe beim Komponenten-Signal anständig spezifiziert. Das erhöht die Chance, auch mit modernem Equipment anständige Ergebnisse zu erzielen. Seit der Erfindung von HDMI ist der Komponenteneingang zwar auf dem Rückzug (bei Fernsehern der neuesten Generation fehlt er ebenso wie der Scart-Eingang), aber selbst die neueste Generation AV-Receiver hat immer noch Komponenten-Eingänge an Bord, wenn auch in ständig reduzierter Anzahl.

Die Firmware des MIST wurde ebenfalls verbessert, vor allem die Konfigurationsoptionen zur Zuordnung von Funktionen auf Buttons von USB-Controllern wurden flexibilisiert. Die Repeat-Intervalle für Feuerknöpfe können nun ebenfalls eingestellt werden. Dazu die Unterstützung für die YUV-Ausgabe per mist.ini.

Ich hoffe, ich habe nix vergessen. Ich finde es sehr erfreulich, wie sich die MIST-Community über die Jahre entwickelt hat – zu Anfang lag noch viel Last auf den Schultern des MIST-Erfinders, aber in letzter Zeit gibt es immer mehr Contributers. Es bleibt spannend. Wenn jetzt noch Stephen Leary ein paar seiner geplanten Erweiterungen des Archimedes-Cores nachlegt…

Die Idiotie nachträglicher Änderungen an altgedienten Schnittstellen

hubersn

Update – siehe unten

Ich beschäftige mich derzeit mit allerlei Retro-Hardware in Vorbereitung auf die Classic Computing 2016, wie man auf dem Nachbarblog nachlesen kann. Also Floppylaufwerke, viel zu kleine IDE- und SCSI-Festplatten (Megabytes statt Gigabytes), alte Rechner als Festplatten noch Sonderausstattung waren.

Dabei ist mir eine besondere Idiotie der IT-Industrie sauer aufgestoßen. Es geht um die gute alte IDE-Schnittstelle. Früher war alles bestens: 40pin Wannenstecker am Controller und am Device, verbunden per 40pin-Flachbandkabel mit 40pin-Pfostenstecker. Verpolsicher wurde es gemacht durch die klassische “Nase” am Stecker und einer entsprechenden Nut an der Wanne. So weit, so prima. Alle waren glücklich.

Irgendwann kam jemand auf die Idee, die Verpolungssicherheit per Nase-Nut könnte eventuell nicht ausreichend sein (und tatsächlich gab es einige Ultra-Billigheimer-Kabel, die doch tatsächlich die Nase einsparten) und führte ein zusätzliches Merkmal ein: das fehlende Loch an Pin 20 des Pfostensteckers, und damit korrespondierend der fehlende Pin in der Wanne.

Jedem Durchschnittsdummen sollte sofort klar sein: eine derartige Inkompatibilität kann nur zu Problemen führen. Während der fehlende Pin in der Wanne logischerweise nie zum Problem wird, macht das nicht-Loch nur Scherereien. Kabel passen nicht mehr in die Wanne, und wenn man nicht aufpasst, ruiniert man sich schnell mal die Hauptplatine. Aktuell habe ich hier ein Mainboard eines Microdigital Omega, der Ultra-ATA unterstützt, aber alle Pins in der Wanne bestückt hat. Ersatzkabel finden? Fehlanzeige. Pin abtrennen scheint die einzige Möglichkeit zu sein. Macht keinen Spaß bei wertvoller alter Hardware. Bei einem CF-IDE-Adapter dasselbe Problem. Gut, es geht auch noch schlechter: ein SD-IDE-Adapter hat nur eine doppelte Stiftleiste ohne Wanne, dafür mit allen Pins – wie man da die Polung herausfinden soll, bleibt im Dunkel. Vorsichtshalber wurde auch jegliche hilfreiche Beschriftung wie “Pin 1” weggelassen.

Ebenfalls dämlich: das nicht-Loch an einem Noname-IDE-Flash-Modul. Schon die Tatsache, hier die weibliche statt der männlichen Steckerseite zu verbauen, ist besonders dämlich – somit taugt das Modul nicht als Drop-In für ein altes Laufwerk, sondern man muss noch einen Gender Changer dazwischen hängen. Oder das Modul direkt in die IDE-Buchse auf dem Mainboard reinstecken – klar, so ein kleines Flash-Modul hat als Zielgerätschaft ja keinesfalls altgediente Hardware, die mit modernen großen Platten nix anfangen kann. Und natürlich belegt man gerne mit einem Device einen IDE-Strang, der prima zwei Devices betreiben könnte. Aber gut, dann hätte man ja noch einen wertvollen Jumper vorsehen müssen für die Master-Slave-CS-Einstellung.

Und übrigens: Molex-Stecker und -Buchsen für die Laufwerksstromversorgung sind das Allerletzte.

Update – in der ersten Version dieses Artikels wurde den Transcend-IDE-Flash-Modulen unterstellt, ein nicht-Loch im weiblichen Stecker zu haben und keine Master-Slave-CS-Umschaltung zu unterstützen. Ersteres war falsch, zweiteres teilweise falsch – Master-Slave geht per kleinem Schalter, CS aber nicht (was vergleichsweise aber ein unbedeutendes Problem ist). Ich hatte das verwechselt mit einem Noname-Flash-Modul. Sorry, Transcend.

ARM-Missverständnisse

hubersn

Durch die möglicherweise anstehende Übernahme von ARM Ltd., Macher der allseits beliebten ARM-Prozessoren (oder eher: des lizenzierbaren “Materials”, aus dem ein Lizenznehmer dann den Prozessor machen kann), liest man wieder vermehrt von den Gründen, warum ARM es eigentlich als einzige alternative Prozessorarchitektur geschafft hat, x86 die Stirn zu bieten. Wir gedenken für einen Moment PowerPC, MIPS und SPARC als “zwar noch nicht tot, aber eher wenig verbreitet” und ignorieren sie ab sofort. Ein kurzes Gedenken an den Alpha ist natürlich auch zulässig.

Oft ist zu lesen, das Tolle an den ARM-Prozessoren sei, dass sie so stromsparend sind. Das ist zwar irgendwie richtig, reicht aber als Erklärung nicht aus. Eine Menge Prozessoren (oder Prozessorarchitekturen) sind stromsparend und könnten relativ problemlos nach unten skalieren – denn viele ARM-Prozessoren, die sehr leistungsfähig sind (man denke an die diversen Cortex-A15-Implementierungen), sind auch nicht so richtig stromsparend. Viele Intel-Prozessoren, die sehr leistungsfähig sind, sind verhältnismäßig stromsparend. In punkto “Effizienz” hat ARM also nicht wirklich eine magische Technologie entwickelt, die der Konkurrenz voraus ist.

Nein, die Gründe für die ARM-Dominanz sind woanders zu suchen – und bis sie sich etabliert hatte, hat es ja auch eine ganze Zeit gedauert. ARMs entscheidender Vorteil, der meines Erachtens auch die Basis für den erfolgreichen Abwehrkampf gegen Intels Eindringen in die Welt der “mobile chips” war, ist das preiswerte, flexible Lizenzierungsverfahren. Ein Intel-Chip kommt aus einer Intel-Fabrik und enthält die Komponenten, die Intel dafür vorgesehen hat. Ein ARM-Chip kommt aus irgendeiner Fabrik und enthält die Komponenten, die der Lizenznehmer dafür vorgesehen hat. Die Lizenznehmer konkurrieren untereinander, sind ganz nah bei ihren Kunden, bauen teilweise spezifische Lösungen, die dann unerwartet bei anderen Kunden auch beliebt werden. Durch die niedrigen Lizenzgebühren braucht man keine Millionenstückzahlen, um Gewinne einzufahren – das erleichtert das Experimentieren, Versuch und Irrtum, kurze Verbesserungszyklen. Es hat sich ein riesiges Ökosystem entwickelt, wo praktisch jeder “seinen” Chip finden kann. Oder er baut ihn gleich selbst (siehe als herausragende Beispiele Apple und Samsung, oder früher DEC mit dem StrongARM). Ethernet, Wifi, Bluetooth, S-ATA, LTE, USB, Grafik, Flash-RAM – der Variantenreichtum ist unerschöpflich, und alles kann strom- und kostensparend auf einem einzigen Chip vereinigt implementiert sein. Und der Wechsel des Lieferanten ist auch einfach.

Am Ende ist es vielleicht der Kampf zwischen Marktwirtschaft (ARM und Alternativen, Lizenznehmer, Auftragsfertiger) und Zentralverwaltungswirtschaft aka Planwirtschaft (Quasi-Monopolist Intel). Es dauert, es geht auf und ab, aber am Ende ist der Sieger eindeutig. Selbst wenn der Verlierer am Anfang des Kampfes gewaltigen Vorsprung hatte.

Wird sich an der ARM-Dominanz etwas ändern durch den Verkauf an Softbank? Man wird sehen. Glaskugeln sind gerade Mangelware.

Pyra-Vorbestellung möglich

hubersn

Ich bin etwas spät dran, weil Vorbestellungen schon seit Anfang Mai möglich sind. Irgendwie ist das aber an mir vorbeigegangen. Also besser spät als nie.

Was ist denn nun überhaupt eine Pyra? Im Prinzip eine OpenPandora in schöner und besser und schneller und überhaupt.

OK, aber was ist jetzt eine OpenPandora? Geistige Vorgängersysteme waren portable Spielkonsolen in der Tradition von Atari Lynx oder Sega GameGear, aber ganz auf der Idee offener Systeme basierend: GP32 (2001), GP2X (2005) und GP2X Wiz (2009), allesamt von der südkoreanischen Firma Game Park/GamePark Holdings entwickelt. Linux-basiert, mit einem ARM als Herz, Grunddesign mit Pad links, Bildschirm in der Mitte, Knöpfe rechts. Da die Systeme softwaretechnisch vollständig offen waren, waren sie der Traum für die “Homebrew”-Szene. Dementsprechend viele, meist freie Software entstand deshalb für diese Handhelds. Der Markt für native Spiele war eher klein, aber es gab eine Menge Emulatoren für den Spielspaß unterwegs, vom C64 bis zum CPC konnte zumindest aus der 8bit-Welt praktisch alles emuliert werden, das GP2X Wiz mit einem 533 MHz ARM9 hatte sogar genug Saft für die 16bit-Spielkonsolen. Die OpenPandora war dann quasi der inoffizielle Nachfolger der Game Park-Handhelds, die nicht nur den Handheld-Spielekonsole-Charakter abdecken sollte, sondern ein vollständiges portables Linux-System mit integrierter Tastatur.

Die OpenPandora – manchmal auch kurz Pandora genannt – basiert hardwaretechnisch auf einem BeagleBoard-ähnlichen Design, also ARMv7 TI OMAP 3 mit bis zu 1 GHz Taktfrequenz. Verpackt in ein klappbares Gehäuse – im weitesten Sinne ähnlich einem Nintendo DS – mit einem Sack voll Schnittstellen von 2 SD-Cards bis zu USB. Auf der einen Seite dank der Tastatur eine Art Mini-PC, auf der anderen Seite aber auch als Handheld-Spielkonsole positioniert dank entsprechenden Controller-Elementen vom 8-Wege-Pad bis zu Schultertasten. Ein 4,3″-Touchscreen mit 800×480 Bildpunkten sorgt für ein klares Bild. Es gab eine Menge Probleme und Verzögerungen bei Herstellung und Auslieferung, grob ab 2010 war die OpenPandora endlich in Stückzahlen erhältlich.

Genug der Historie. Der Nachfolger der OpenPandora ist die Pyra. OMAP5 statt OMAP3, also 1,5 GHz Cortex-A15 Dual-Core statt maximal 1 GHz Cortex-A8 Single-Core. Über den groben Daumen gepeilt bedeutet das eine etwa um Faktor 5 erhöhte Rechenleistung. 2 bis 4 GB Hauptspeicher sind verbaut, dazu aktuelle Schnittstellen wie HDMI, eSATA und USB3. Das Display ist nun 5″ groß und schafft die 720p-HD-Auflösung. Kontakt nach außen gibt es via WiFi und Bluetooth, optional gibt es auch ein UMTS/LTE-Modul inklusive der gängigen Smartphone-Sensorik von GPS über Höhenmesser bis zum Gyro-Sensor. 32GB Flash ist eingebaut, damit man auch ohne eingesteckte SD(XC)-Karte das System seiner Wahl booten kann. Es steckt ein 6000mAh-Akku drin, der ausgetauscht werden kann. Die Tastatur hat eine Hintergrundbeleuchtung spendiert bekommen.

Eine weitere Besonderheit: das Hardware-Design ist modular. So leben CPU und RAM auf einem separat tauschbaren Board, was zukünftige Updates ermöglicht. Inwiefern dieses Szenario realistisch ist, insbesondere nachdem TI die OMAP-Reihe nicht mehr fortführt, sei dahingestellt – ich habe es noch nie für eine gute Idee gehalten, auf spätere Updates zu hoffen. Man kauft am besten das, was existiert, und nicht die Hoffnung auf etwas eventuell irgendwann existierendes.

Wer ist nun Zielgruppe der Pyra? Schwer zu sagen. Sie ist portabler als ein kleines Netbook. Aber auch deutlich dicker als ein Smartphone oder von mir aus eine PS Vita. Aber die hat halt auch eine vollständige Tastatur, die – ich nehme mal meine OpenPandora als Benchmark – durchaus benutzbar ist. Sie ist nicht ganz preiswert, mit 4 GB RAM und mit 3G/4G-Modul liegt man doch schon bei 750€. 2 GB ohne Mobile-Modul liegt bei 600€. Also doch eher unterm Strich ein Liebhaberstück. Damit bin ich Zielgruppe. Hurra! Zumal RISC OS auf der OpenPandora problemlos lief und die Pyra dank HDMI-Out und USB ja sowohl als stationäres als auch mobiles System dienen könnte.

Hier unter pyra-handheld.com gibt es die volle Info-Dröhnung und Details zur Vorbestellung.

Raspberry Pi 3 verfügbar

hubersn

Heute hat die Raspberry Pi Foundation den Raspberry Pi 3 offiziell vorgestellt. Er ist bereits (im Gegensatz zum RPi Zero, der immer noch bei der Verfügbarkeit schwächelt) in kleinen Stückzahlen bei den üblichen Verdächtigen lieferbar. Preise liegen bei rund 40€.

Jetzt gibt es also harte Fakten. Die weichen gar nicht so sehr von den Gerüchten ab, die ich vorgestern eingesammelt habe:

  • SoC 1,2 GHz BCM2837 Quad-Core Cortex-A53 – also ARMv8 64bit, aber mit AArch32-Unterstützung
  • WiFi (802.11n) und Bluetooth (4.1) über BCM43438 on board

Rest ist unverändert zum RPi 2 – 1GB RAM, 4x USB2.0, 100MBit Ethernet über USB angebunden, analog Video/Audio out über Klinke, HDMI für digital Video/Audio, microSD-Slot. Es wird ein 2,5A-Netzteil empfohlen, wenn man die 4 USB-Ports voll belasten will. Alle Ports sind an der gleichen Stelle wie beim RPi B+ und RPi 2 B, die Gehäuse sind also kompatibel.

Performancetechnisch wird die Steigerung vermutlich bei 50% gegenüber dem RPi 2 liegen – etwas höherer Takt, und höhere Effizienz des Cortex-A53 gegenüber dem Cortex-A7. NEON soll deutlich schneller geworden sein.

Ben Avison hat ein paar interessante Details zur Rückwärtskompatibilität im ROOL-Forum gepostet. Es scheint diesmal kein übles Ei wie die Änderung der non-word-aligned-memory-access-Geschichte bei ARMv7 vs. ARMv6 zu geben, nur Kleinigkeiten die vermutlich nur das OS betreffen.

In Summe ist der RPi 3 eine super Sache – gleicher Preis wie bisher, und man hat die Chance preiswert einen realen 64bit-ARM zu betreiben. Und im High-End-Bereich gibt es genügend Platz für Alleinstellungsmerkmale wie Gigabit Ethernet und S-ATA.