 Für viele von euch ist der Amiga genau wie für mich vielleicht eine Erinnerung an eure Jugend. Vielleicht war euer erster Computer ein Amiga. Ein paar von euch sind vielleicht noch ein bisschen zu jung dafür. Aber das Schöne am Kongress ist ja auch, dass es hier so einen schönen Mix an Themen gibt. Und deswegen kriegen wir jetzt heute eine schöne Einführung in das Hardware-Design des Amigas und wie man ihn programmieren konnte. Ich kann jetzt schon einen ganz kleinen Spoiler euch verraten, man hat es nicht in Java programmiert. Also begrüßt jetzt Rara mit einer Runde Applaus. Ja, auch von mir. Willkommen. Danke für die Einführung. Und willkommen zu meinem Wind-Hitch-Talk hier. Also wir werden heute über etwas reden, was vor ungefähr 30 Jahren stattgefunden hat. Es war in der Tat ein bisschen schwierig für mich, das alles vorzubereiten, denn Mitte der 80er habe ich vieles über den Amiga gewusst und wie man ihn programmiert. Aber im Laufe der Jahre habe ich mehr oder weniger alles vergessen. Vor fünf Jahren gab es einen Talk hier über den C64 und das weiß wahrscheinlich auch jeder hier drin. Es war ein toller Talk und das war für mich die Inspiration, ein Talk über den Amiga zu machen. Es hat allerdings eine Weile gedauert, um das alles zusammen zu bekommen hier und so fing das Ganze also an. Es war also wie gesagt vor ungefähr 30 Jahren und ich denke mal so ungefähr die Hälfte von euch sind wahrscheinlich hier, weil sie damals ein Amiga hatten. Also bitte mal die Hände heben, alle die einen Amiga hatten, ja das sind mindestens 50 Prozent und die anderen 50 Prozent sind vielleicht hier um ein bisschen was über die Geschichte zu lernen. Vielleicht wart ihr damals noch gar nicht geboren. Es fing also auf meinem Dachboden an. Ihr könnt dann sehen, das Ganze ist ziemlich verstaubt hier und ich habe da so gewühlt, ob ich da noch ein bisschen Hardware und Software finde und irgendwie noch andere Sachen über den Computer. Und was ich, ich habe einiges gefunden, dafür kann ich hauptsächlich meinen Brüdern danken, die mich mit Computern versorgt haben. Hauptsächlich einen Amiga 500 und einen Amiga 1000. Mein eigener hat leider nicht mehr funktioniert. Ich habe ihn noch, aber er funktioniert leider nicht mehr. Aber bevor wir jetzt in die Details gehen, will ich euch noch was zeigen. Ich habe hier den berühmten Amiga Emulator. Der heißt UAE. Manche Leute nennen das den Unix Amiga Emulator, aber der Ursprungsname bedeutete unusable, also unbenutzbarer Amiga Emulator. Warum unbenutzbar, naja, die Hardware des Amigas, die war so, so schnell und so stark, dass Mitte der 90er es einfach nicht möglich war, den Amiga auf irgendeiner anderen Plattform zu emulieren. Und selbst auf meinem Computer hier funktioniert es nicht übermäßig gut, aber gut. Das ist also ein Stück Software hier, was ich geschrieben habe, ungefähr 1990. Es braucht eine Weile, um hochzufahren. Es ist nämlich ein emuliertes Diskettenlaufwerk, wie ihr alle wisst. Okay, das ist hier so der typische Amiga-Stil. Was können wir hier sehen? Wir sehen in der Mitte hier, sehen wir ein Bild, was sich bewegt. Dann haben wir dieses Sternenfeld im Hintergrund, was sich ebenfalls bewegt. Ja, also jedes Amiga-Programm hat das so eine Art Intro. Und dann fliegt hier ein Sprite noch von neben rein und natürlich die Laufschrift. Und auf einem echten Amiga ist das alles auch, das Scrolling ist sehr weich, butterweich und auf diesem Emulator leider nicht so. Und jetzt kann man hier noch sehen, dass hier noch ein grafischer Effekt kommt. Hoffentlich. Es hat dieses Demo auch Sound, aber den können wir jetzt hier nicht hören. Ich habe es nicht angeschlossen, aber ihr könnt mir glauben, da ist auch Sound dabei. Okay, da ist also eine zweite Zeile mit Laufschrift, die hier so eine... Also es ist nicht mal gerade, es bewegt sich in so eine Art Sinus-Welle hier. Okay, ich halte das mal an hier. Okay, ich schiebe das hier mal gerade zur Seite. Okay, also machen wir mal... Hier weiter dieses Intro hier, was ihr gerade gesehen habt. Das habe ich selber geschrieben, das war ungefähr 1990, 1991. Ich war damals Mitglied einer Cracker-Gruppe. Also ich war ein Böserjunge, einige von euch vielleicht auch. Und damals war es ganz, ganz wichtig, dass man eben seine Programmierfähigkeiten auf diese Art und Weise unter Beweis stellte, indem man eben ein Intro programmierte, in dem sich alles bewegt hat und viele Farben durcheinander benutzt wurden. Und das war also ganz normal damals. Okay, also schauen wir uns mal die Geschichte des Amiga-Computers an. 1984 war der allererste Chaos-Communication-Congress. Das hat natürlich erstmal nichts mit dem Amiga zu tun, aber es zeigt euch so ein bisschen, was in diesem Jahrhundert so alles passiert ist. Der erste Amiga ist 1985 veröffentlicht worden. Es war der Amiga 1000, und es gab dann zwei Nachfolgemodelle, der Amiga 500 und der Amiga 2000. Das war ungefähr derselbe Computer, der eine hatte, ein paar mehr Erweiterungslots und wurde ein paar mehr Möglichkeiten, aber der Grunde war es der gleiche Computer. Viele Jahre später, ungefähr 1990, kam dann der Amiga 3000 und noch etwas später, die Liste ist nicht komplett, es gibt noch Zwischenmodelle wie zum Beispiel der Amiga 1200, den hier, glaube ich, einer im Saal hat, der 1200 ist 1992 veröffentlicht worden. Und naja, was ist danach passiert? Ihr wisst das wahrscheinlich, es gab dann zwei beschrömte Computerspiele. Ich erwähne die deshalb, weil das in meiner Meinung nach die beiden Computerspiele waren, die so den IBM PC, die auf dem IBM PC ungefähr so schnell und so schön liefen wie Amiga-Spiele. Und danach, naja, 1994 ist die Firma Commodore, dann musste Bankrod erklären. Und ja, wir wissen es eigentlich ganz genau, der offizielle Grund ist, sie haben ein, sie haben sehr stark investiert in Computer-Hardware und in die Entwicklung von neuen Computer-Hardware. Aber was sie nicht vorhergesehen haben, war, dass andere Hersteller natürlich auch nicht geschlafen haben in dieser Zeit. Das heißt also, in dem Zeitraum von 85 bis 94, das sind neun Jahre, also sagen wir mal rund zehn Jahre, die anderen Hersteller haben natürlich nicht geschlafen und haben auch ihre Hardware verbessert. Und meiner Meinung nach waren sie einfach zu spät. Und was noch dazu kommt, sie hatten zwei sehr erfolgreiche Modelle, nämlich den C64, den jeder kennt, eine der erfolgreichsten Computer aller Zeiten und dann hatten sie den Amiga 500, der ebenfalls sehr erfolgreich war und zumindest das Modell, was sich am besten verkauft hat. Und naja, diese Modelle waren einfach erfolgreich, ohne dass Commodore da ein Menge Marketing betreiben musste. Und naja, irgendwie haben sie das dann verpasst. Und das ist so meiner Meinung nach der Grund, warum Commodore dann irgendwann gestorben ist. Der Amiga ist selber, ich möchte über die alten Modelle reden, über die Original-Modelle. Und es gibt, später gab es dann noch den Amiga I, basierend auf dem PowerPC und der wird dann unter OS4 betrieben und die Firma wurde dann ein paar Mal verkauft. Es gab dann einige Firmen, die da involviert waren und Commodore wurde von einer Firma an die andere weiterverkauft. Naja, wie dem auch sei. Also technisch gesehen gibt es die Firma noch, die letzte Version von OS4 wurde, glaube ich, 2014 veröffentlicht. Na gut, hier sind die beiden Hauptmodelle. Das erste ist also hier der Amiga 1000, hier auf der linken Seite ein Desktopmodell mit einer externen Tastatur. Hier in der Mitte den kleinen Amiga 500, ein Gerät, wo alles in einem war. Tastatur eingebaut, Floppy-Laufwerk eingebaut, die Maus natürlich daneben und ein externes Diskettenlaufwerk konnte man noch anschließen. Und hier rechts das größere Amiga 2000 Modell. Die Hardware in dem 2000er ist die gleiche wie im Amiga 500, aber wie ihr seht, hatte der einen zweiten Einschub für ein Diskettenlaufwerk und war also ein bisschen besser erweiterbar. Man konnte da einige Erweiterungskarten einbauen. Das ist einfacher als beim 500er. Was waren die Konkurrenten? Der Amiga war natürlich nicht alleine auf dem Markt. Es gab einige andere Modelle. Es ist natürlich keine vollständige Liste, aber das ist das, die ich am wichtigsten erachte. Es gab die Atari ST-Familie. Also es ist nicht ein einzelner Computer, es ist eine ganze Familie von Computern. Der hatte die gleiche CPU, den Motorola 68000er, der auch im Amiga 500 benutzt wurde. Der wurde 1985 ebenfalls veröffentlicht. Dann gab es den Acorn Archimedes, ein ziemlich kraftvoller Computer damals, und der hatte einen ARM Version 2 CPU. Jeder hier kennt natürlich heute die ARM-CPUs, eine RISC-CPU. Dann gab es Apple. Apple hatte viele verschiedene Modelle damals, und das ich am ehesten als vergleichbar zum Amiga-Ansee ist die Macintosh-Serie. Die wurden auch mit dem 68000er Prozessor gebraut, wurden 1985 veröffentlicht. Die waren nicht ganz so erfolgreich wie die anderen Computer, denn genau wie heute auch war Apple damals natürlich unglaublich teuer. Die haben ungefähr das Dreifache gekostet von dem, was die anderen Computer zu dem Zeitpunkt gekostet haben. Und dann gab es die Intel-Modelle, also die sogenannten IBM PCs und Compatible. Es gab den 8088 und den 8086 und dann den 2680er. Ich habe die nicht auf der Folie drauf, hier fange ich mit dem 3680er an, denn der 3680er war der erste, der ungefähr so schnell war, wie die 68000er, also der erste, der wirklich vergleichbar war. Das restliche Design ist aber eigentlich ziemlich straight forward. Es gab die CPU, es gab einen Bus, es gab einige Peripheriegeräte, die man da anstehen konnte. Also nichts besonderes wie in den anderen Modellen. Aber nur um das mal so kurz zu umreißen, was sonst noch so in diesem Jahrhundert passiert ist, es gab die VGA-Karte, ist 1987 veröffentlicht worden. Es gab das Betriebssystem OS2, was auch ein Multitasking-Betriebssystem war. Es war ungefähr vergleichbar mit dem Betriebssystem, was unter dem der Amiga lief, was ebenfalls ein Multitasking-Betriebssystem war. Es gab eine Reihe von Unixen. Die Unix liste ich hier nicht auf, denn das war normalerweise ein System, was auf eine Mainframe lief und das konnte sich keiner für zu Hause leisten. Also ich habe hier auf dieser Liste nur solche Maschinen stehen, die die Leute auch wirklich zu Hause hatten. Wir hatten Windows Version 3, 1990 veröffentlicht die erste Version, die man wirklich als Multitasking-Betriebssystem bezeichnen konnte. Alles bis einschließlich Version 2.1 hatte die anderen Tasken in den Hintergrund geschoben. Linux selber erschien erst 1991, also wir sind noch vor dieser Zeit. Gut, dann Betriebssystem-Version. Die Betriebssystem-Version des Amigas, die allererste war natürlich die 1.X-Serie, was mit dem Amiga 1000 zuerst veröffentlicht wurde und auch auf dem 500 und 2000er lief. Auf dem Amiga 1000 musste man das Betriebssystem noch von Deskette hochfahren. Auf den anderen Modellen war das Betriebssystem ins Rom eingebaut. Auf einem Chip, das heißt man hat den Amiga einfach eingeschaltet und das Betriebssystem war da. Dann gab es Version 2, die ist ungefähr 1990 veröffentlicht worden und diese Version gab es nur auf dem Amiga 3000. Sie war aber abwärtskompatibel, das heißt man konnte einen Rom-Chip in die 2000er Modelle einbauen mit OS 3 drauf. Und dann gibt es die neueren Versionen, die auch heute noch vertrieben werden. Das war die 4.X-Versionen. Ich schreibe hier non-Komodore, denn das wurde lizenziert an andere Firmen und die haben dann dieses Betriebssystem weiterentwickelt. Basieren tut das 4 allerdings auch noch auf der 3.X-Serie. Das war dann auch PowerPC basiert, das heißt das ist also dann eine andere CPU-Familie. Es ist aber das Betriebssystem selbst aber unabhängig von dem Chip-Satz. Der Amiga hatte einen ziemlich kraftvollen Chip-Satz eingebaut und das alte Betriebssystem war davon abhängig, aber die neue Version, OS 4.X, war nicht mehr abhängig von einem bestimmten Chip-Satz, das heißt man konnte da vielen verschiedenen Computern zum Laufen bringen. Okay, hier haben wir einige Bücher, die ich gefunden habe auf meinem Dachboden. Das Wichtigste ist dieses hier, es ist das Amiga Hardware Reference Manual. Da steht alles drin über die Hardware. Die Hardware war relativ offen, in dem Sinne, man die, die, die, im Grunde waren die Schaltplatinen, waren offen gelegt. Natürlich war das alles geschützt im Sinne von Trademarks, aber es war alles dokumentiert und in diesem Buch steht alles drin darüber, wie die Hardware funktioniert. Und dann haben wir hier natürlich das 68.000 Mikroprozessor, Instruction Manual ist auch sehr wichtig. Und das hier ist das Amiga Basic Handbuch, das lag dem Amiga bei. Also der Amiga kam mit einem Basic Interpreter und auch das war sehr gut dokumentiert. Und dann gibt es hier noch eine Reihe anderer Bücher, wie das hier zum Beispiel, das sind alles deutsche Bücher. Ich selber bin aus Österreich, das habsen das deutsche Bücher. Also die Dokumentation der Systemroutine, der Systemaufrufe des Amigas. Es gab einige Hundert System-Routinen, mit deren Hilfe man zum Beispiel die Grafik-Chips ansteuern könnte, das User-Interface, die Hardware, die Floppy-Laufwerke und auch das war sehr, sehr gut dokumentiert. Und natürlich gab es auch eine ganze Reihe Zeitschriften. Ich habe hier eine gefunden, die nennt sich Kickstart, dann gab es noch das Amiga-Magazin. Und naja, wie das mit diesen Zeitschriften also war, da wurden immer neue Spiele vorgestellt und Tipps und Tricks für den Amiga. Da habe ich das hier noch, das Floppy-Book, das war ein ziemlich mieses Buch. So wie dieser Scan hier, da konnte man lesen, wie man Einsprünge in den Code im Rom macht. Man kann es schlecht sehen, aber das hier ist in der Tat ein Assembler-Listing und da konnte man einige Features der Floppy-Bibliothek ausnutzen. Naja, das Problem war immer, es gab eine neue Version, die Adressen änderten sich und dann war das Ganze nicht mehr brauchbar. Gut, schauen wir uns mal die Kernkomponenten an, was in diesem Computer da drin steckte. Der Kern war also ein Motorola 68000 Prozessor. Es war mehr oder weniger ein, ja es war ein 32-Bit Prozessor in der Sysc-Architektur. Es hatte 512 Kilobyte RAM. Man konnte das erweitern auf bis zu 8 Megabyte. Ein kleines bisschen mehr, aber es waren ungefähr 8 MB. Das Betriebssystem war ein preemptive Multitasking-Betriebssystem. Das heißt also, es gab außer UNIX kein anderes Betriebssystem in der PC-Welt, was dieses preemptive Multitasking beherrschte. Es hatte seriale Schnittstellen, parallele Schnittstellen, mit denen man Drucker, Maus, Joystick und so weiter anschließen konnte. Es hatte ein eingebautes 3,5 Zoll Floppy-Laufwerk und es gab auch einen Erweiterungslot im 500er-Model, der hatte einen, mit dem man externe Hardware an den Frontside-Bass anschließen konnte. Und es hatte einen analogen und digitalen Videoausgang und natürlich auch Audioausgänge. Also hier gibt es jetzt ein Rückansicht von dem 500er-Modell und was man hier sehen kann, ist ein Komposite-Videoausgang, der im Wesentlichen nutzlos war, der war nur schwarz und weiß. Hier daneben ist der Videoausgang, da gab es also Analog und Digital, RGB und dann geht der Anschluss für den Strom, danach Festplatte, Floppy-Audioausgang, Stereo links und rechts und zwei externe Geräte wie Moise oder Joysticks. So sah der von hinten aus. Dann haben wir noch ein paar weitere technische Spezifikationen. Die CPU lief bei 7,09379 Megahertz. Die amerikanischen Modelle waren ein bisschen auf einer anderen Frequenz und man kann sich natürlich fragen, warum gerade so eine komische Frequenz, das lag daran, dass die an das Video-Signal gekoppelt war. Das heißt, das PAL beziehungsweise und die komplette Hardware war auf dieses Video-Signal synchronisiert und wir hatten in Europa haben in Stück weit das PAL-Format und daran hängt diese wunderliche Frequenzzahl. Das komplette Bus-Timing, alles war synchronisiert auf diese Frequenz. Die hatten ein paar speziell angeforderte Chips, die Audio und Video und so weiter direkt in Hardware implementiert haben, Agnus, Paula und Denise. Es hat auch noch zwei interne Teile, da rede ich nachher drüber, Copper und Blitter. Und im klassischen Design gibt es die CPU, die auf den Bus und auf alles, was da drauf angeschlossen ist. Aber wenn man zusätzlichen DMA-Channel hat, dann kann man auch über DMA auf diesen Bass zugreifen, also parallel nicht nur die CPU, verschiedene Geräte können auf Bass und Speicher gleichzeitig sozusagen zugreifen. Und DMA wurde also für Audio und Bitplanes und für all möglichen Features benutzt und das bedeutet, man kann mehrere Dinge gleichzeitig machen, ohne die CPU zu benutzen. DMA macht das, nicht die CPU. Und das gab eine Pixel-Auflösung von bis zu 640 x 512 auf den europäischen Modellen mehr oder weniger, das war mehr oder weniger der Standard und 12-Bit Farbtiefe. Das sind 4096 Farben. Das heißt, CGA-Grafikarte hatte nur 16 Farben, die auch festgelegt waren und die konnte man auch nicht alle gleichzeitig anzeigen. Und hier gab es dann noch vier Audio-Kanäle, die alle interrupt kontrolliert waren. Und dann reden wir mal über Programmiersprache. Die Hauptprogrammiersprache war C, also die übliche Software wurde in C programmiert. Na klar, wenn es ums Timing ging, also dann konnte man auch in Assembler programmieren und Amiga Basic wurde auch angeboten, warum auch immer. Es war so ein Stück weit eingebaut, also es war die Software mal gleich mit dabei. Und dann für Versionen 2 und später gab es dann A-Rex, also Amiga-Rex. Das war eine Skripsprache von IBM entwickelt wurde, die da implementiert wurde, die man vielleicht mit Visual Basic oder sowas Ähnliches vergleichen kann. Hier kommt so ein üblicher C-Funktion-Header, der sah so aus, Cunningham & Ritchie Programmier-Style, C98-Standard, gab er erst 1998, das war also weit davor. Also schauen wir uns mal die CPU an. Die 86.000 CPU war eine der mächtigsten CPUs damals. Das war einer der Gründe, die in so vielen Computern mit eingebaut war. Die wurde tatsächlich 79 schon rausgebracht. Verglichen mit den anderen CPUs, zum Beispiel Intel 8088, das ist eine 16-Bit CPU mit einem 8-Bit-Bus. Mit 16-Bit-Obcodes, also mit orthogonalem Instraktionsinstruktionen. Das heißt, man konnte also jede Instruktionsmodus von anderen aus benutzen. Das ist total praktisch für Programmieren. Wenn man in Assembler programmieren will, zumindest in C, sieht man das natürlich nicht. Hat er zwölf verschiedene Adressierungsmoden, Modi, also Indirektregister, Register und so weiter. Hatte fast 32-Bit ALU. Das heißt, das ist der Teil in der CPU, die die eigentliche Ausrechnung dann macht. Und ungefähr, weil es nicht perfekt war, war fast. Das hatte acht Datenregister, acht Adressregister, inklusive dem Stack-Pointer. Das ist das letzte Register gewesen. Und das hatte natürlich auch Systemstatusregister und hatte sehr ausgefeilte Interrupt-Struktur. Zwar hat 56 verschiedene Interrupts möglich, nicht nur externe Hardware-Interrupts, sondern man konnte eben auch selbst Software-Interrupts definieren. Und damit konnte man eigene Instruktionen implementieren. Und es sah so aus, als ob es Benutzer- und Supervisor-Mode hatte. Das ist der erste Schritt auf dem Weg zu echten Multi-Benutzersystemen. Das heißt, es gibt also einen eingeschränkten Instruktionen-Set-User-Mode und eben Supervisor-Mode, wo man dann alles machen darf. Und das ist einer der wichtigen Schritte, wenn man zu echten Multi-Tests-Tasking gehen will. Zum Beispiel im... Und das selbe Konzept wurde auch im 286er dann implementiert. Ich weiß nicht genau, in welchem Jahr, aber ungefähr in derselben Zeit. Extern hat es ein 16-Bit-Datenbus. Das heißt, man brauchte immer mindestens zwei Datenbus-Zyklen, um ein komplettes 32-Bit-Wort in den Speicher zu laden. Und ein 24-Bit-Adressbus extern. Was bedeutet, man hat dann einen kompletten Adressraum von 16 Megabyte. Und hier ist ein Beispiel für so einen üblichen 86.000-Assembler-Code. Sieht aus wie alle anderen Assembler-Codes des AT&T-Syntags. Also von links und nach rechts zu lesen. Hier gibt es Punkt W, Punkt L. Da sieht man die Größe der Operation. Also 32-Bit oder 16-Bit breite Operation oder 8-Bit nur. Ja, die Nachfolgemodelle. Es gab einige Nachfolgemodelle. Also die 86.010 mit virtuellem Speicherunterstützung. Das hatte der 86.000 nicht. Was man aber für ein gutes Betriebssystem brauchen würde, war der 86.020, der hatte eine echte 32-Bit-ALU und einen externen 32-Bit-Bus und eine Memory Management Unit. Das heißt, das ist für den Amiga-Computer meiner Meinung nach das größte Fehl, das was er meisten gefehlt hat. Damit konnte man also insbesondere nicht verbieten, dass man auf bestimmte Speicherbereiche nur zugreifen kann. Und der Kernel konnte den Benutzer nicht darauf einschränken, nur bestimmten Speicherbereich zu zugreifen. Und die originalen Modelle hatten das eben nicht. Und dann gab es noch weitere Modelle. Das ist auch keine vollständige Liste, das geht weiter. Und so sah das Mainboard aus vom Amiga 500. Was wir hier sehen auf der linken Seite ist die CPU mit 64 Pins. Das ist ein 68.000 Prozessor. Da neben ist die ROM. Das ist tatsächlich eine Erweiterung, die ich gebaut habe. Hier drunter haben wir den dynamischen Arbeitsspeicher, also RAM 512 Kilobytes. Hier ist diese Agnes-Chip, einer von diesen zentralen, von diesen speziell dafür angefertigten Chips. Und darüber ist Paula, die hauptsächlich für Audio, DMR und so weiter benutzt wurde. Und hier haben wir Denise. Denise ist verantwortlich für Video-Ausgabe und Video-DMA. Und dann haben wir hier, was haben wir hier noch? Gary. Gary ist so eine Art dumme Bus-Controller, der sorgt dafür, dass die Kommunikation zwischen diesen Chips hinhaut. Und hier sind zwei CIA, also das ist nicht, was er jetzt denkt, sondern das ist ein Komplex-Interface-Adapter. Das ist im Prinzip ein angeschlossenes Gerät. Also man konnte da verschiedene Ports anschließen und hatte also quasi einfach die Möglichkeit, externe Geräte anzuschließen, wie man sie an einem Computer braucht. Und das ist die Festplatte. Oben sind die Anschlüsse. Das haben wir vorher schon gesehen, das Bild, wie es dann von hinten aussieht. Das ist eine 2 Megabyte Erweiterungskarte. Also hier unten konnte man Dinge einstecken. Zum Beispiel dieses Ding eben. Das ist eine 2 Megabyte interne Arbeitsspeichererweiterung. Genau genommen sind es nur 1,8 Megabyte. Wir sehen gleich, warum. Langsames RAM, auch das werden wir sehen. Und das hat etwa 200 Euro gekostet. Also vor 35 Jahren für 2 Megabyte. Das ist das Amiga 2000 Modell. Das ist mehr oder weniger derselbe. Hier haben wir den 68.000er Prozessor. Daneben dann RAM, Gary. Also da ist der RAM. Ja, da bin ich jetzt gar nicht mehr sicher. Einer ist Gary, der anderen Denise und Paula. Darüber die CIAs. Und dieses Ding da wurde genannt Buster. Das hat die Erweiterungskarten kontrolliert. Obwohl die, also die unteren, sind die Original Amiga Erweiterungskarten. Okay, das funktioniert nicht. Ich gehe einfach so mal rüber. Diese hier sind die sogenannten Zorro Slots. Die wurden direkt an den Bass angeschlossen. Und die Slots hier oben, das sind ESA Slots. Da konnte man also eine Bridgekarte einbauen. Und die hatte zum Beispiel nochmal eine eigene CPU an Bord. Und dann konnte man IBM-kompatible Komponenten da mit ansteßen. Und hier haben wir einen Slot für einen Co-Prozessor. Also zum Beispiel für Fließkommaberechnungen. Und hier oben ist ein Anschluss, wo man an die Videohatwert-Dinge anschließen kann. Da konnte man eine spezielle Videokarte anschließen, die man synchronisieren konnte. Das komplette Amiga-Bord mit dem externen Videotaktfrequenz. Und damit konnte man dann Video-Signale zusammenmixen. Das ist ein Skasi-Controller. Und hier habe ich jetzt also einen Hardware-Blockdiagramm. So sah das aus. Das ist also mehr oder weniger, wie die Kabel dann auch verlegt waren. Auf der linken Seite die CPU, Datenbus, Adressbus und hier die drei Spezialchips, die über diesen Bus hier unten angeschlossen waren. Und hier unten haben wir den die 512 Kilobyte eingebauten RAM und Erweiterungskarten und so weiter. Aber was interessanter ist, ist das funktionale Blockdiagramm. Und hier sieht man, dass auf der linken Seite die CPU ist. Und was wir heute den Frontside-Bus nennen, ist das hier vorne, der CPU-Bus. Und der ist direkt angeschlossen, die zwei CIAs für die seriellen Anschlüsse und so weiter. Und hier ist das ROM, also auf der das Betriebssystem lag. Und oben der Anschluss für die Erweiterungsanschlüsse für externe Hardware. Und hier dazwischen ist eine Logik, die für den Bus zuständig ist. Und auf der rechten Seite sehen wir die Chips, also die speziell angefertigten Chips, Agnes, Paula und Denise. Und was die gemacht haben, war, sie haben tatsächlich zwei Computer in einen Motherboard eingebaut. Das waren zwei komplett getrennte Computer durch diese Buslogik hier in der Mitte. Das waren also Chips, die einen eigenen Bus hatten, die miteinander reden konnten. Und natürlich auch hier das Chip-Ramm zugreifen, also die Chip-Konten auf ihr spezielles Ramm zugreifen. Und es war komplett getrennt von der CPU auf der anderen Seite. Die 68.000er-CPUs hatten Anschlüsse für externe Buslogik. Das heißt, es war möglich, dass andere Geräte außerhalb auf den Bass zugreifen konnten, was für gerade DMA ja notwendig war. Und wenn die 68.000er-CPU jetzt auf den Speicher da drüben zugreifen wollte, dann musste das anfordern auf dieser Buslogik und sagen, hier, ich würde gerne den Bus auf den Bus zugreifen. Und die Buslogik konnte dann annehmen oder eben ablehnen. Und das ist, was diesen Rechner so mächtig gemacht hat. Es gab diese speziellen Chips, die in sich schon Computer waren und die mussten nicht auf die CPU warten oder auf sonst irgendwas. Okay, so sah also die Speicherbelegung aus des Amigas. Wir haben insgesamt bis zu 16 Megabyte. Das ist also das, was man mit 24-bit adressieren kann. Hier oben die niedrigsten Adressen, da haben wir das sogenannte Chip-Ramm. Das ist also das, was wir eben gesehen haben. Die neueren Modelle konnten dann die nächsten 512 Kilobyte auch noch adressieren. Also bis zu einem MB und die noch neueren Modelle konnten dann noch weiter bis auf 2 Megabyte gehen und konnten, also diese Spezialchips hier noch auf dem Boss sind, was ihr auf dem vorherigen Diagramm gesehen habt, also was auf der rechten Seite war. Dann gibt es hier ein Loch, was 8 Megabyte groß ist. Das war also ein Speicherbereich, der für die Expansionshardware zuständig war und wie wir auf dem Diagramm sinken konnten, konnten diese Chips das nicht ansprechen. Da wurden also die Daten von Expansionskarten eingeblendet. Und dann hier, dieser Bereich ist interne Erweiterungsslot von 256 Kilobyte. Kann ich hier gerade nochmal zeigen. Das hier war, das ist der interne Bus der Chips und der Speicherzugriff wurde eben auf diese Art und Weise gemacht und deshalb haben wir hier für diese interne Speicherweiterung hatte eben nur 1,8 anstelle von 2 Megabyte, denn der Rest des Adressbereichs war für was anderes reserviert. Und dann hier hinten an diesem Speicherbereich hatten wir noch 256 Kilobyte für das ROM, wo das Betriebssystem gespeichert war. Und hier war noch mal ein Bereich von 256 Kilobyte, sodass wir da insgesamt 512 Kilobyte haben. Okay, schauen wir uns mal diese Spezialchips an. Es gab ein paar Spezialregister, über die man diese Chips kontrollieren konnte. Und das ging also über Interrupt-Kontrolle und Bus-Kontrolle. Bus-Kontrolle bedeutet also, man kann kontrollieren, wer den Bus zugreifen darf, denn es konnte immer nur ein einziges Gerät auf den Bus zugreifen. Das heißt also, dieser eine Chip hier kontrolliert das. Und was wir hier unten sehen, den Blitter und der Koppel, das waren also Spezialprozessoren, die ich jetzt gleich noch erklären werde. Der Bitplane-DMA ist also ein Chip, der dafür zuständig war, irgendwas anzuzeigen. Er hatte verschiedene Auflösungen, die er anzeigen konnte, 320 mal bis hin zu 640 mal 512, das waren die Standardauflösungen. Man konnte bis zu sechs Bitplanes haben, die Bitplanes waren dafür verantwortlich, welche Farben angezeigt wurden. Das heißt, die Farben wurden nicht wie heute in einer modernen Grafikkarte direkt gespeichert, sondern man hat also die Bitplane ausgewählt. Und diese Bitplane hatte ein Farbregister, und da drin waren dann die Farben abgelegt. Innerhalb des Farbregisters konnte man dann die Farben freidefinieren. Man hatte also 3 mal 4 Bit, und da kommen wir auf 12 Bit, und damit können wir 4096 verschiedene Farben darstellen. Und es gab einige Spezialmodi, den Dual Play Field Mode, das zeige ich gleich noch. Es hatte das Ham, das Hold and Modify, hieß dieser Modus. Mit diesem Modus konnte man alle 4096 Farben zur gleichen Zeit anzeigen. Und das selten benutzte Halfbrite Mode, damit konnte man 64 verschiedene Farben gleichzeitig anzeigen. Hier könnt ihr sehen, wie diese Bitplanes funktionieren. Eine Bitplane ist nichts anderes als ein Speicherbereich, der die Bits für ein einziges Bit enthält. Speicher ist natürlich beideorientiert, nicht bittorientiert. Das heißt, wir haben hier immer Blöcke von jeweils 8 Bit. Und die Hardware hat dann diese 5 Bitplanes genommen, hat sie übereinandergelegt, und hat dann aus jeder Bitplane das eine Bit rausgezogen. Und diese übereinandergelegt ergaben dann die Adresse des Farbregisters. Und in diesem Register war dann der eigentliche Farbwert abgelegt. Das heißt, was wir hier sehen, ist also nicht die Farbe selber, sondern es ist die Nummer des Registers, unter dem dann die Farbe abgelegt ist. Hier haben wir den Dual Play Field Mode. In diesem Modus kombinierte die Hardware zwei verschiedene Play Fields. Das heißt, man hatte also zwei separate Objekte auf dem Bildschirm. Und die Hardware sorgte dafür, dass die beiden Objekte kombiniert wurden. Das wurde ganz häufig in Spielen benutzt, wenn man da mehrere Sachen gleichzeitig anzeigen wollte. Das heißt, man hat also einen Play Field, was zum Beispiel alle beweglichen Objekte waren und ein weiteres, wo der Hintergrund zu sehen war. Und die Hardware kombinierte dann diese beiden. Und man konnte Bereiche definieren, wo die zweite Bitplane dann durchschimmert, weil die erste Bitplane an dieser Stelle transparent gemacht wurde. Wir hatten auch Sprites. Ich bin nicht sicher, ob ihr da weiß, was ein Sprite ist. Ein Sprite ist ein grafisches Objekt, das durch die Hardware auf den Bildschirm hinzugefügt wird. Es wird also nicht durch die CPU irgendwo in das Bild eingerechnet, sondern die Hardware macht das. Es ist also ein kleines Bild, was über das normale Bild drübergelegt wird, durch die Hardware Chips. Amiga konnte acht voneinander unabhängige Sprites standardmäßig anzeigen. Jedes Sprite hatte zwei Bitplanes. Damit konnte man insgesamt drei verschiedene Farben benutzen. Man konnte auch zwei verschiedene Sprites zu einem kombinieren, sodass das resultierende Sprite dann bis zu 15 Farben haben konnte. Also eigentlich 16, aber eine Farbe war reserviert für Transparenz. Und man konnte auch die DMA Kanäle wieder verwenden. Während der Amiga das Bild anzeigte, wenn man also den oberen, in dem oberen Bereich des Bildes schon acht Sprites hatte, konnte man in dem unteren Bereich weitere acht Sprites benutzen. Und so kam man eben auf 16 Bytes. Und je nachdem, wie man das mit dem Timing hinbekommen hat, konnte man auch 16 oder noch mehr Sprites hinbekommen. Es gab auch eine Kollisionserkennung in Hardware. Das ist also wichtig gerade für Spiele. Man hat verschiedene Sprites. Und wenn diese beiden Sprites kollidieren, dann muss irgendwas passieren. Zum Beispiel eine Explosion muss stattfinden, oder das Spiel zieht einem Gesundheitspunkte ab. Und die Berechnung dieser Kollision, wann diese zwei Sprites kollidieren, das wurde ebenfalls in der Hardware gemacht. Das heißt, also während der Bildschirm aufgebaut wurde und die Bitplanes kombiniert wurden, verglich die Hardware, die Planes miteinander und hat dann erkannt, ob da irgendwo eine Kollision vorliegt. Und wenn ja, gab es dann ein spezielles Register, um wo das Programm dann ablesen konnte, ob eine Kollision stattfand oder nicht. Okay, das war also die, wie das eigentliche Display dann aufgebaut wurde. Funktioniert folgendermaßen. Wir haben also bis zu sechs Bitplanes. Und diese sind auf Speicher abgebildet. Es gibt keine fester Adresse, sondern man legt einfach nur das, was man anzeigen möchte, irgendwo in das Chip Memory. Und dann gibt man die Adresse dieses Speicherbereichs irgendwo in einem Register und auf Planes liegen da und da und da. Muss also nicht an einer festen Adresse geschehen. Dasselbe gilt auch für die Sprites. Man konnte natürlich, die auch an Pixel-Grenzen ausrichten, nicht nur an Bit-Grenzen, sozusagen, nicht nur an Byte-Grenzen. Die Video-Hardware liest dann diese Bits ein, erstellt dann eine Prioritätenliste, legt also fest, welche Bitplane über welcher anderen Bitplane angezeigt wird, wählt dann die Farben aus den Farbregistern aus und wählt dann die Farbe aus, die man später tatsächlich auf dem Bildschirm sieht, erkennt dann noch, ob eine Kollision vorliegt. Und ja, so funktioniert das. Copper selber ist einer der wichtigen oder einer der wichtigsten Co-Prozessoren. Es ist synchronisiert mit dem Rest. Das heißt, alles ist also auf das Video-Signal ausgerichtet. Und das Video-Signal ist, kann ich euch als Elektronenstrahl vorstellen, der also das Bild zeichnet. Und das gesamte System war auf dessen Taktfrequenz synchronisiert. Und Copper war auf diesen Elektronenstrahl synchronisiert. Der wusste also genau, zu welchem Zeitpunkt sich der Elektronenstrahl an welcher Position des Bildschirms befand. Und das ist ganz wichtig für weiche Scrolling- und weiche Grafiken. Wenn man das also nicht hat, dann fängt die Grafik an und flackert und man kann das auf manchen Systemen sehen. Es gab drei Befehle, Weight-Move und Skip. Man konnte also warten, bis der Elektronenstrahl an einer bestimmten Position stand und dann konnte man Move machen, also Daten in einem bestimmten Register schreiben. Das heißt also, sobald der Strahl an einer bestimmten Stelle stand, konnte man dann Daten an einer bestimmten Stelle schreiben. Zum Beispiel die Adresse eines Sprites. Und damit hat man dann angefangen, ein neues Sprite zu zeichnen. Und es gab die Skip Instruktion. Damit konnte man sagen, wenn der Strahl bereits hinter der Position war, auf die man wartete. Es gab eigene Register, die man modifizieren konnte. Das heißt, es gab eine sogenannte Copper-List, was im Grunde ein eigenes kleines Programm für diesen Copper ist. Und es hatte Priorität auf dem Bus vor den anderen Ships. Das heißt, wenn es also etwas gab, was mit hoher Priorität gezeichnet werden musste, dann hatte der Copper immer Priorität und konnte seine Aufgabe erledigen. Dann gab es den Blitter, was der zweite sehr wichtige Co-Prozessor in diesem Computer ist. Blitter bedeutet Block-Image-Transfer. Es ist also ein DMA-System, was Bildblöcke von A nach B kopieren konnte. Bildblöcke, das Interessante an Bildblöcken ist, dass es kein Lineare-Adressbereich ist. Denn wenn man einfach ein Stückchen eines Bildes ausschneidet, dann hat man also ein paar Pixel und dann muss man eine Reihe von Pixel überspringen, bis man in der nächsten Zeile ist. Und das hat der Blitter-Chip gemacht, also in dem Sinne auch verantwortlich dafür, dass die Grafik sich sehr weich bewegte und Scrolling sehr weich funktionierte. Blitter hatte drei DMA-Quellen. Das heißt, man konnte von drei verschiedenen Quellen Daten kopieren. Blitter kombinierte das dann auf eine ganz bestimmte Art und Weise. Das heißt, man konnte auf diese Art und Weise 256 verschiedene Methoden definieren, die Bits von diesen drei Quellen zu kombinieren und hat das Ganze dann an eine bestimmte Speicherstelle geschrieben, was also der vierte DMA-Kanal war. Zusätzlich gab es noch die Möglichkeit, zu schiften und zu masken. Wie ihr wisst, ist ja Speicher bite-orientiert und nicht bit-orientiert, aber wenn man vielleicht etwas nur um einen Bit bewegen möchte, dann muss man eine bestimmte Operation machen, nämlich einen Shift, einen Bit-Shift und das wurde ebenfalls in der Hardware gemacht. Und maskieren ist also, wenn man bestimmte Bits eines Bites nicht kopieren will, es gab noch einen aufsteigenden und absteigenden Modus. Das war wichtig, wenn man sich über lappende Speicherbereiche kopieren wollte, wenn man das nicht in der richtigen Reihen vorgemacht, dann überschreibt man sich seine eigene Quelle und dann erscheint irgendwelche Mülle auf dem Display und er konnte auch Bereiche ausfüllen und auch Linien zeichnen. Und das alles in Hardware. Das heißt, es wurde dabei nicht die eigentliche CPU benutzt, sondern das hat alles der Blitter alleine gemacht. Okay, hier ist noch ein interessantes Diagramm. Das hier ist das Bus-Timing. Das sieht ein bisschen wild aus. Ich habe das aus einem Buch auskopiert. Das, was wir hier sehen, ist das Bus-Timing. Und das hier, das hier, das ist eine Fortsetzung von der Zeile hier oben. Das ist also das komplette Bus-Timing einer horizontalen Linie auf dem Bildschirm. Das heißt, auf dem Bildschirm gibt es aber auch noch einen bestimmten Bereich am Rand, den man nicht sieht. Und was wir hier sehen, ist die Zeitslotz einer kompletten horizontalen Linie. Jeder Slot, den wir hier sehen, ist ein Buszyklus, wo jedes Gerät auf den Bus zugreifen konnte. Und das Timing wurde so gestaltet, es wurde auf eine Art und Weise gemacht, dass die geraden Zyklen, also was hier zwischen diesen Bereichen liegt, das hier ist ein Gerader, und das hier, und das hier, und das hier auch, wurde von der CPU benutzt. Und das wurde so gemacht, dass in den 60.000er-CPU-2-Buszyklen brauchte, um eine Instruktion auszuführen. Der erste Zyklus wurde dazu benutzt, die Instruktion zu holen. Ein Fetch wurde gemacht, und im zweiten Zyklus machte die CPU nichts auf dem Bus, sondern sie hat nur die Instruktion ausgeführt. Und aus diesem Grunde haben sie das also so miteinander verwoben, dass in dem zweiten Zyklus die Hardware, die Spezialchips den Bus zugreifen konnten und die CPU konnte gar nicht sehen, dass da irgendjemand anderes auf den Bus noch zugreift. Aber wie wir hier sehen konnten, an diesen schwarzen, hier und hier, an diesen schwarzen Bereichen, was wir hier sehen können, da sehen wir die verschiedenen Bitplanes. Und es gibt, und an diesem ganzen Bereich gibt es quasi keine Zyklen für die CPU. Die CPU musste in diesem Bereich warten, bis das Chipram fertig war und mit den Spezialchips fertig war. Und aus diesem Grund nannte man das ganze Slowram, also langsames Ram, weil eben die Chips in diesem Bereich den Bus beschlagnahmten, um eben das Display darzustellen und die CPU konnte nicht mehr auf das Ram zugreifen. Und daher langsames Ram im Kontrast zu dem schnellen Ram von 8 MB, auf das die Chips nicht zugreifen konnten. Also daher diese Unterschaltung zwischen langsamer und schnellem Ram. Okay, die Audio Hardware. Es gab vier unabhängige 8-Bit-Audiokanäle, die ungefähr eine Samplerade von 28.000 Hz hatten. Und damit kamen wir auf eine Audiofrequenz von ungefähr 15 kHz. Und es hatte auch noch Support für Amplitudenmodulationen, die man zusätzlich noch tun konnte auf diesen Kanälen. Und man hat also in den einen Audiokanal einen Sample eingefügt und auf den zweiten Audiokanal hat man einen Funktionen festgelegt, die dann auf diesen Sample angewandt wurde. Und das war dann das, was der zweite Audiokanal ausgegeben hat. Und die CPU konnte dann Interrupt gesteuert, immer eine neue Adresse in das Audio-Register füttern. Okay, hier eine Zusammenfassung der Interrupts. Alles wurde über Interrupts kontrolliert. Und das ist sehr nett, denn die Hardware sagt einem dann, bzw. die Hardware sagt der CPU, dass irgendwas Bestimmtes gemacht werden muss. Das heißt, die CPU muss also nicht warten, was passiert, sondern sie wird benachrichtigt. Es gibt den sogenannten Vertical Interrupt, dass es also immer, wenn der Elektronenstrahl in der unteren rechten Ecke des Bildschirms angekommen ist, dann wird also ein Interrupt generiert. Und während der Elektronenstrahl in die obere linke Ecke des Bildschirms zurückfährt, kann die CPU eben Sachen ausführen. In der Bitplane passiert also in dem Fall nichts. Und das sind ungefähr 4.500 CPU-Zyklen. Und in diesem Zeitbereich konnte die CPU eine Menge Dinge tun. Was ich also euch vorher gezeigt hat, die meisten Sachen gingen sehr glatt und sehr weich, denn ein großer Teil der internen Logik während dieses Zeitraums gemacht, wo der Elektronenstrahl eben unsichtbar war. Hier haben wir noch ein paar weitere Interrupte. Wir haben den Copper Interrupt, wir haben den Blitter Interrupt, wenn also der Blitter mit seiner Aufgabe fertig war, irgendwas kopiert hatte, hat der Interrupt ausgelöst. Es gab den Disk Interrupt, das Floppy-Laufwerk war also auch über DMRs gesteuert. Die CIA-Erweiterungsslots haben ebenfalls Interrupts erzeugt, wenn irgendwelche Daten bereit waren zur Abholung. Und es gab noch eine Reihe von externen Interrupts für die Erweiterungskarten. Und zum Schluss noch ein paar Sachen über die Floppy-Disk. Was der Standard-Massenspeicher für diesen Computer war, es war ein relativ flexibler Disk-Controller. Es war also nicht alles in Hardware festgelegt. Man konnte diesen Controller programmieren auf verschiedene Art und Weisen. Man konnte bis zu vier Disketten-Laufwerke an den Amiga anschließen. Und man konnte auch mehrere Disketten-Laufwerke gleichzeitig ansprechen. Und das war sehr schön für das Kopieren von Disketten. Man konnte also z.B. von einem Laufwerk lesen und auf zwei andere Laufwerke gleichzeitig schreiben. Das Standard-Format waren 80 Tracks doppelseitig, 80 Sektoren. Und damit kommen wir auf ungefähr 880 Kilobyte. Und weil der Controller so flexibel war, konnte er sogar andere Formate lesen, wie z.B. das IBM PC-Format, was damals ProDiskette nur neun Sektoren hatte. Das Dateisystem war ursprünglich, wurde einfach nur File System genannt. Und später hat man das dann OFS, also Old File System genannt. Es gab 488 Bytes pro Sektor. Natürlich gab es insgesamt 512 Bytes pro Sektor. Aber 24 Bytes am Anfang wurden für Fehlerkorrekturen und ähnliche Dinge benutzt. Es war also durchaus so designt, dass für Disketten-Laufwerke, die eben so wie ich das so in Erinnerung waren, jede dritte Diskette war kaputt. Und dafür war das eben designt. Später wurde dann das Fast-Files-System entwickelt, was hauptsächlich für Festplatten-Laufwerke war. Und da hatte man dann 512 Bytes pro Sektor, also etwas mehr Nutzdaten, die man speichern konnte. Ja, das war eine kurze Einführung in die Hardware des Amigas. Gibt es irgendwelche Fragen? Okay, also funktioniert das hier? Ich habe eine Frage, was die Sprites angeht. Und du hast so gesagt, dass die Hardware Kollisionsdetektion kann. Und zwar wusste man da nur, welche Sprites betroffen waren oder wusste man auch, wer mit wem kollidiert ist? Ja, irgendwo dazwischen. Dieses Verfahren hat zwei Sprites immer kombiniert. Das heißt man hatte also, man musste programmatisch dann rausfinden, welche beiden Sprites das waren. Man konnte das rausfinden, man musste es paarweise rausfinden. Welche Sprites miteinander kollidiert waren, so ungefähr lief das. Gibt es Fragen vom Internet? Nein, dann habe ich eine zweite Frage. Und zwar, das Weight-Kommando von Copper, konnte man da nur auf Lines warten oder? Ja, für ganz bestimmte Positionen des Elektronenstraß. Man konnte also warten, bis der Elektronenstrand an einem ganz bestimmten Pixel war. Ja, danke. Ich denke, dann gibt es keine weiteren Fragen mehr. Wir sind auch mehr oder weniger an der Ende unserer Zeit. Also nochmal herzlichen Dank an den Speaker. Es war ein großartiger Talk. Ja, und auch Danke von uns. Das war der Talk der ultimative Amiga 500 Talk. Genau der. Wenn ihr Feedback habt, könnt ihr uns schreiben auf Twitter. Ihr könnt dazu benutzen. Entweder könnt ihr unseren Twitter-Account direkt anschreiben at c3lingo oder aber ihr benutzt einfach den Hashtag c3t. Wir freuen uns.