Als der Amiga 1000 im Jahr 1985 auf den Markt kam, war er als Heimcomputer zu teuer, sondern zielte eher auf den Markt für professionelle Grafik-Workstations ab. Entsprechend niedrig waren die Verkaufszahlen. Nur 27.500 Einheiten wurden in Deutschland verkauft. Dennoch und ohne Zweifel ist der Amiga 1000 das Juwel jeder Amiga-Sammlung. Nun hatte ich endlich das Glück, meinen eigenen zu bekommen.
Der Gesamtzustand ist in Ordnung, wenn man bedenkt, dass die Maschine fast 40 Jahre alt ist. Der Amiga selbst ist nur ein wenig vergilbt, hat aber einige starke Kratzer an einer Kante. Die Tastatur hat ein französisch/belgisches AZERTY-Layout, das mit Aufklebern auf das deutsche Layout geändert wurde, wie es bei den ersten in der EU verkauften Geräten üblich war. Ihr Gehäuse und die Leertaste sind viel stärker vergilbt. Die Aufkleber sind ebenfalls vergilbt und einer fehlt.
Der Erweiterungsslot an der Vorderseite enthält ein 256KB-RAM-Modul. Die Originalmaus und die Disketten sind verloren gegangen, aber ich kann jede andere Amiga-Maus verwenden und selbst neue Disketten erstellen.
Das Innenleben
Im Inneren fand ich ein Rev-A-Mainboard und ein Piggyback-Board (Huckepackplatine). Diese Zusatzplatine speichert den Kickstart, der von der Diskette geladen wird, wenn die Maschine eingeschaltet wird. Spätere Revisionen verwendeten Kickstart-ROMs und benötigten dieses Piggyback-Board nicht mehr.
Normalerweise wurden alle Piggyback-Amiga-1000 für den US-Markt produziert. Aufgrund unterschiedlicher Netzfrequenzen und TV-Standards konnten sie in Europa ohne Modifikationen nicht betrieben werden. Meine Maschine wurde Anfang 1986 hergestellt, vermutlich für den US-Markt. Ein Jahr später wurde sie für den europäischen Markt modifiziert. Der ursprüngliche Agnus-Chip wurde durch einen 8367R0 ersetzt, der PAL-Videosignale erzeugen kann. Der Quarz ist jedoch noch der originale 28,6363-MHz-NTSC-Quarz, sodass das Videosignal kein echtes PAL ist.
Das System verfügt über einen Denise 8362R6, was die erste Revision ist, die auch den EHB-Modus darstellen kann.
Insgesamt ist es ein frühes Amiga-Modell und sehr wahrscheinlich eines der ersten, die in Deutschland verkauft wurden.
Das Netzteil
Generell empfehle ich nicht, einen alten Computer nach vielen Jahren der Lagerung sofort einzuschalten. Ohne eine Sichtprüfung und die notwendige Überholung könnte das Netzteil den Computer beschädigen, oder interne Komponenten könnten explodieren.
Eine erste Sichtprüfung des Netzteils schien in Ordnung zu sein, ohne offensichtliche Schäden und ohne gewölbte oder ausgelaufene Kondensatoren. Aber dann fand ich winzige Risse in einem Sicherheitskondensator.
Diese RIFA-X-Klasse-Kondensatoren sind tatsächlich berüchtigt dafür, nach vielen Jahren hochzugehen. Ihre Isolatoren bestehen aus Papier. Das Material wird durch Alter und thermische Belastung spröde, lässt Feuchtigkeit ein, was das Problem verstärkt. Letztendlich kann der Kondensator aufplatzen und in Rauch aufgehen.
Es war gut, dass ich das Netzteil nicht ans Stromnetz angeschlossen habe. Es wird nun von @DingensCGN überholt, einem Mitglied des A1K.org Forums, das viel Erfahrung mit der Restaurierung von Amiga-Netzteilen hat.
Das Mainboard
Ich habe die Kondensatoren auf dem Mainboard und dem Piggyback-Board ausgetauscht. Für die sieben 22µF-Kondensatoren habe ich stattdessen einen bipolaren Typ verwendet. Diese Kondensatoren werden zum Filtern der Audio- und RGB-Signale verwendet. Hier bipolare Kondensatoren zu verwenden, könnte die Signalqualität verbessern und schadet ansonsten nicht.
Um ehrlich zu sein, hatte ich dieses Mal Zweifel, ob ich die alten Kondensatoren austauschen sollte. Dieser Amiga 1000 wird keine Workstation werden, dafür habe ich andere Amigas. Er ist eher ein Sammlerstück. Dennoch möchte ich, dass er sich in einem guten technischen Zustand befindet. Als ich anfing, Retro-Computer zu sammeln, habe ich mir versprochen, keine Maschinen zu behalten, die kaputt oder anderweitig nicht einsatzbereit sind.
Danach entfernte ich den gesamten Staub und unterzog die Platinen einer gründlichen Wäsche mit IPA.
Das Mainboard ist nun bereit, wieder mit dem Piggyback-Board vereint zu werden und dann zurück ins Gehäuse zu ziehen.
Bleichen
Das Erste, was ich eigentlich getan habe, war, die gesamte Maschine zu zerlegen. Die Kunststoffteile des Gehäuses wurden in Seifenwasser gereinigt und vorsichtig mit einer Spülbürste geschrubbt. Danach nutzte ich das sonnige Juli-Wetter und bleichte alle Teile im Sonnenschein. Ich habe keine Chemikalien verwendet, nur die Sonne. Nach zwei Tagen war der Amiga fast wieder weiß.
Das war’s für den ersten Teil der Amiga-1000-Geschichte. Im nächsten Teil wird es um die Restaurierung der Tastatur gehen. Dort gibt es viel zu tun.
Mitte der 1990er Jahre veröffentlichte MacroSystem Germany die Maestro Professional Soundkarte für den Amiga. Sie war eine besondere Soundkarte, da sie vollständig digital war und nur optische und koaxiale digitale Anschlüsse hatte. Sie eignete sich für verlustfreie Aufnahmen von CD und DAT sowie für die Erzeugung verlustfreier Audioausgaben für DAT-Aufnahmen. Mit Tools wie Samplitude wurde der Amiga zu einer digitalen Audio-Workstation in Studioqualität. Es gab auch ein Tool für Backups auf DAT. Damals waren diese Bänder die billigste Möglichkeit, ganze Festplatten zu sichern (ein 90-Minuten-DAT-Band konnte fast 1 GB an Daten sichern, was in den 1990er Jahren eine Menge war).
Leider hatte MacroSystem nie einen Treiber für die Soundkarte veröffentlicht, sodass sie nur von wenigen (und meist kommerziellen) Tools genutzt werden konnte. Ich löcherte ihre Entwickler auf jeder Amiga-Messe, die ich besuchen konnte, aber ohne Erfolg. Dann, Ende 1994, beschloss ich, die Datenblätter der Yamaha-Chips zu suchen, das Board-Design einem Reverse Engineering zu unterziehen und selbst einen Treiber zu schreiben. Es kostete etwas Zeit durch Ausprobieren, aber schließlich war ich erfolgreich. In den kommenden Jahren wurde mein Treiber, die maestix.library (Quellcode), zum inoffiziellen Standardtreiber. OctaMed Professional ist vielleicht die bekannteste Software, die ihn nutzt. Einige professionelle Musiker nutzten Amiga und OctaMED für ihre Produktionen, vielleicht wurde mein Treiber also sogar für die Aufnahme der Master einiger bekannter CDs verwendet? 😁
Digitales Audio in aller Kürze
Die MaestroPro kann digitale Audiodaten entweder im S/P-DIF- oder AES-EBU-Standard empfangen und senden. Ersterer ist heute noch weit verbreitet in Heimgeräten, während letzterer eher in Studiogeräten üblich war. Heutige Standards erlauben verschiedene Kodierungen und hohe Abtastraten, aber die MaestroPro konnte nur 2-Kanal 16-Bit Raw-Audio mit Abtastraten von entweder 48kHz (DAT), 44,1kHz (CD) oder 32kHz (DAB) lesen.
Neben den reinen Audiodaten transportiert der Standard auch Channel Status Bits (CSB) und User Data Bits (UDB). Die CSB enthalten Informationen wie die verwendete Abtastrate und den Kopierschutzstatus. Die UDB sind nicht standardisiert und transportieren normalerweise proprietäre Daten zwischen Studiogeräten.
Das Innenleben der Maestro
Das Design des Boards ist geradlinig. Es enthält hauptsächlich einen Sender, einen Empfänger und einen FIFO-Speicher für den Transport der Samples zwischen dem Board und AmigaOS.
Die optischen und koaxialen Eingänge gehen an einen Yamaha YM3623B Digital Audio Interface Receiver (DIR). Dieser Chip dekodiert den Audiodatenstrom, extrahiert die CSB und UDB und generiert einen rohen Bitstrom der Audiosamples. Schieberegister wandeln ihn in einen parallelen 16-Bit-Strom um, der in einem 1K x 16-Bit Empfangs-FIFO gespeichert wird. Sobald der FIFO zur Hälfte gefüllt ist, wird ein Interrupt ausgelöst und der Amiga-Treiber liest die empfangenen Daten aus dem FIFO. Dies geschieht bis zu 190 Mal pro Sekunde.
Die wichtigsten CSB sind über ein Statusregister des Board-Controllers auslesbar. Die UDB werden in ein separates 8-Bit-Schieberegister kopiert, das vom Treiber abgefragt werden könnte. Allerdings sind UDB normalerweise 32 Bit breit, sodass ihr Auslesen in der Praxis eigentlich nie genutzt wurde (zumindest nicht meines Wissens). Der Maestix-Treiber bot nur eine sehr rudimentäre API für die UDB.
Auf der Senderseite werden die 16-Bit-Samples in einen Sende-FIFO geschoben und dann durch Schieberegister in einen seriellen Bitstrom umgewandelt. Ein Yamaha YM3437C Digital Audio Interface Transmitter (DIT2) wandelt ihn in einen digitalen Audiostrom um und sendet ihn über einen optischen Ausgang. Die Maestro Pro hat keinen koaxialen Ausgang, vermutlich weil auf dem Board nicht genug Platz für einen vierten Anschluss war.
Der DIT2 kann den Takt der Abtastrate nicht selbst generieren. Er benötigt stattdessen eine externe Taktquelle. Auf der Maestro Pro wird dieser Takt durch den DIR generiert. Er wird entweder aus dem Bitstrom des ausgewählten Eingangs abgeleitet oder durch eine interne feste 48kHz-Taktquelle generiert. Aus diesem Grund ist die Maestro Pro für Ausgabe-Abtastraten von 32kHz und 44,1kHz auf externe Signalquellen angewiesen.
Der Sender kann aus zwei Datenquellen wählen. Eine Quelle ist der Sende-FIFO. Die andere Quelle ist der Bitstrom vom DIR, der die FIFOs umgeht. Dies ermöglicht es dem Board, die UDB und CSB des eingehenden Signals direkt zu ändern, ohne die CPU einzubeziehen. Da Sende- und Empfangsweg jedoch vollständig getrennt sind, ist die MaestroPro sogar in der Lage, Full-Duplex-Audiostreaming zu bieten. Die maestix.library nutzt das mit der „Realtime FX“-Funktion, bei der das Signal aus dem Empfangs-FIFO gelesen, von der CPU modifiziert und dann sofort wieder an den Sende-FIFO zurückgeschickt wird.
Das gesamte Board wird von drei GALs und einer kleinen Handvoll 74LS-Logikchips gesteuert. Sie kümmern sich um das Zorro-Bus-Protokoll, stellen Modus- und Statusregister bereit und orchestrieren die Sende- und Empfangswege.
Defekte MaestroPro
Alle Komponenten einer MaestroPro sind noch auf dem Markt zu finden, obwohl beide Yamaha-Chips nicht mehr produziert werden und nur noch auf einigen chinesischen Online-Märkten als NOS-Teile zu finden sind. Aber im Grunde ist es immer noch möglich, eine defekte MaestroPro zu reparieren.
Die größte Schwachstelle sind die drei kundenspezifisch programmierten GALs. Der GAL-Hersteller gibt eine Speichererhaltungszeit von etwa 20 Jahren an. Das klingt nach ziemlich viel, aber vergiss nicht, dass diese Boards inzwischen fast 30 Jahre alt sind. Wir haben diese Lebensdauer bereits um 50% überschritten!
Als ich meinen Amiga im Jahr 2021 reaktivierte, funktionierte meine MaestroPro ein paar Minuten lang einwandfrei, aber dann begann sie, die Synchronisation mit der Audioquelle zu verlieren. Der einzige Weg, das Problem zu beheben, war, den Amiga auszuschalten und ihn für ein paar Minuten abkühlen zu lassen. Eine genauere Diagnose zeigte, dass sich die Karte anscheinend vom Zorro-Bus trennte. Es schien, dass einer der GAL-Chips thermische Probleme hatte oder vielleicht anfing, seine Programmierung zu „vergessen“. Zum Glück konnte ich das Programmierschema wiederherstellen. Ich habe die originalen GALs durch brandneue Atmel ATF16V8C-7PU ersetzt, und zu meiner Erleichterung funktioniert meine MaestroPro jetzt wieder stabil.
Die Fusemaps sind durch MacroSystem urheberrechtlich geschützt, daher ist es mir nicht gestattet, sie der Öffentlichkeit zugänglich zu machen. Wenn du jedoch zufällig eine defekte Maestro Pro hast, setze dich bitte mit mir in Verbindung. Vielleicht kann ich dir bei der Reparatur helfen.
Die Maestro (ohne Pro)
Es gab einen Vorgänger dieses Boards. Er hieß einfach “Maestro” und hatte einige große Nachteile. Erstens hatte er keinen Sender und konnte nur Audiodaten empfangen. Zweitens hatte er keinen FIFO, sodass die Sample-Wörter von der CPU gelesen werden mussten, sobald sie verfügbar waren, was bis zu 96.000 Mal pro Sekunde entspricht. Dies war nur möglich, indem Multitasking und Interrupts während der Aufnahme ausgeschaltet wurden, was auch bedeutete, dass Aufnahmen nicht auf Festplatte geschrieben werden konnten, sondern zunächst im RAM gespeichert werden mussten.
Im Vergleich zu ihrem Nachfolger war die Maestro kein großer Erfolg. Ich habe seit Ende der 1990er Jahre keine mehr gesehen, und ich kenne auch keine einzige Software, die sie tatsächlich nutzt. Aufgrund der technischen Einschränkungen wird sie vom Maestix-Treiber nicht unterstützt.
Es ist möglich, EPROMs zu verwenden, um deinen Amiga auf das neueste AmigaOS zu aktualisieren. Leider werden diese EPROMs nicht mehr hergestellt, weshalb es zunehmend schwieriger wird, diese Teile auf dem Markt zu finden. Ein weiterer Nachteil ist, dass eine spezielle UV-Lichtquelle erforderlich ist, um EPROMs zu löschen, im Gegensatz zu modernen Flash-ROMs, die elektrisch gelöscht werden können.
Wäre es also nicht besser, stattdessen Flash-ROMs zu verwenden? Sicherlich ja, aber sie sind nicht in DIP-40-Gehäusen erhältlich, die in die Amiga-ROM-Sockel passen.
Der Flash-ROM-Adapter
djbase hat freundlicherweise das Design eines Amiga Flash-ROM-Adapters veröffentlicht. Er kann mit 29F400-, 29F800- oder 29F160-Flash-ROMs bestückt werden. Diese sind bei allen möglichen Elektronikhändlern erhältlich und können bis zu vier Amiga-ROMs in einem einzigen Chip speichern.
Neben der Platine und dem Flash-ROM-Chip benötigst du nur vier SMD-Widerstände, einen SMD-Kondensator und Stiftleisten. Das Problem ist jedoch, dass die Komponenten winzig sind und das Rastermaß der Flash-ROM-Chip-Pins sehr fein ist, weshalb dieses Projekt definitiv nicht für Löt-Anfänger geeignet ist. Vertrau mir. Ich habe drei davon für die Tonne produziert, bevor ich erfolgreich war.
Die Programmier-Hardware
Zur Programmierung verwende ich einen XGecu TL866II Plus Programmer und das SN001 Adapter Kit. djbase bietet außerdem einen speziellen Programmieradapter an, der mit dem TSOP48/SOP44 Base Board des SN001 Adapter Kits verbunden wird.
Beachte, dass du das aktive Base Board (SN001, rot auf dem Foto) benötigst. Das Standard-TSOP48-Base-Board (grün) funktioniert hier nicht.
Dieses Programmieradapter-Sandwich wird in den ZIF-Sockel des TL866-Programmers gesteckt. Der Flash-ROM-Adapter wird in den ZIF-Sockel der Adapterplatine gesetzt und die Stiftleisten beider Platinen werden entsprechend ihrer Beschriftung verbunden. Beachte, dass die aktuelle Revision der Adapter Flash-ROMs bis zum 29F160 unterstützt und fünf Kabel benötigt. Ich verwende noch die vorherige Revision mit nur vier Kabeln, weil sie mir besser gefällt.
Der GND-Pin deines Flash-Boards kann für den Flash-Vorgang offen bleiben. Er wird normalerweise verwendet, um einen Jumper oder Schalter in deinem Amiga anzuschließen, um die ROM-Bank auszuwählen.
Wenn du nicht vorhast, den Flash-ROM-Inhalt nach dem Löten zu ändern, kannst du dir auch den Programmieradapter sparen und stattdessen den SN003-Adapter verwenden (der oft dem SN001-Adapter-Kit beiliegt). Du würdest das Flash-ROM dann vor dem Löten flashen.
Die Binärdatei
Für die Vorbereitung der Binärdatei nutze ich mein Pynaroma-Toolkit. Es kümmert sich um das Zusammenfügen mehrerer ROM-Dateien und das notwendige Byte-Swapping. Um zum Beispiel ein ROM-Image von AmigaOS 2.04 und AmigaOS 3.2.1 für den Amiga 500 zu erstellen, kann diese Befehlszeile verwendet werden:
rom2bin -o flash.bin A500.37.175.rom CDTVA500A600A2000.47.102.rom
Je nach Flash-ROM-Chip kannst du bis zu vier verschiedene ROM-Dateien zu je 512 KB verwenden. Wenn die ROM-Datei eine Größe von 256 KB hat, denke daran, sie zu duplizieren.
Sobald sich der Adapter im Amiga befindet, kann das gewünschte ROM-Image über die Adressleitungen der Stiftleiste ausgewählt werden (z. B. durch Verwendung von Jumpern oder Schaltern). Beachte, dass die Adresspins des Flash-ROMs durch den Adapter auf High-Pegel gezogen (Pull-Up) werden. Das bedeutet, dass die letzte ROM-Datei der Sequenz verwendet wird, wenn alle Header-Pins offen sind.
Flashen
Für die Programmierung bevorzuge ich die Open-Source-Software minipro gegenüber der Originalsoftware von XGecu, hauptsächlich weil die Originalsoftware nicht für Linux verfügbar ist.
Es ist wichtig, den richtigen Flash-ROM-Typ auszuwählen. Wähle den Typ, den du tatsächlich auf deinen Adapter gelötet hast. Wähle immer das TSOP48-Gehäuse, da der Programmieradapter einen TSOP48-Sockel simuliert.
Ich verwende ein M29F800FT, daher ist die korrekte Geräteeinstellung M29F800FT@TSOP48, und die Befehlszeile zum Flashen der obigen Binärdatei lautet:
minipro --device 'M29F800FT@TSOP48' --write flash.bin
Das Flash-ROM wird gelöscht (es ist also nicht nötig, es vorher zu löschen), das Image darauf geschrieben und dann in einem letzten Schritt verifiziert.
ROM-Austausch
Das Flash-ROM ist ein Drop-in-Ersatz für das Amiga-ROM. Ich habe das Original-ROM vorsichtig mit einem Schraubendreher mit breiter Klinge aus dem Sockel entfernt.
Danach habe ich den Flash-ROM-Adapter in den Sockel gesteckt. Die richtige Ausrichtung ist entscheidend. Der Adapter wird so eingesetzt, dass die Stiftleiste die gleiche Ausrichtung hat wie die Kerbe des Original-ROMs.
Manchmal sind die Löcher des Sockels zu klein, um die Pins des Adapters aufzunehmen. In diesem Fall ist die einzige Möglichkeit, entweder den Sockel auszutauschen oder ein EPROM zu verwenden.
Wenn du ein Amiga 500 Rev. 5 Mainboard besitzt und mit dem neuen Flash-ROM zufällige Abstürze erlebst, musst du möglicherweise Widerstände in die Adressleitungen einbauen. Dies kann entweder über Widerstandsnetzwerke erfolgen oder durch die Verwendung eines Amiga 500 EPROM-Adapters, der in einigen Amiga-Shops verkauft wird.
Ich habe dieses Action Replay MK-I Modul bekommen. Laut dem Verkäufer war es ungetestet und wurde aus diesem Grund als defekt verkauft. Es war in einem… sagen wir mal sehr gebrauchten Zustand. Das Gehäuse war dreckig, bis zu einem Punkt, an dem es fast schon eklig war, es anzufassen. Eine Seite des Gehäuses war aufgebrochen und ein Drehknopf fehlte. Das Modul muss irgendwann mal heruntergefallen sein.
Ich öffnete vorsichtig das Gehäuse. Die obere und untere Schale sind nur zusammengesteckt, es gibt keine Schrauben, also war es einfach, sie auseinanderzuziehen. Im Inneren fand ich eine Art Belag auf der Platine, also wurde vielleicht auch ein Getränk über das Modul verschüttet. Ich fand außerdem eine Menge feinen Papierstaub wie von Pappe, und eine kleine Delle an der Ecke der Platine, die durch den Sturz verursacht wurde.
Als Erstes habe ich das gesamte Modul ordentlich in einem Ultraschallreiniger gesäubert, nur mit warmem Wasser und einem Tropfen Spülmittel. Und ja, ich habe die Platine auch auf diese Weise gewaschen, sie dann abgetrocknet und mit Isopropanol (IPA) eingesprüht, um die letzten Wasserspuren zu entfernen. Dieses Bad hat Wunder gewirkt.
Ich ging davon aus, dass der Dreck auch das Innere der mechanischen Teile erreicht hatte, also beschloss ich, sie alle auszutauschen. Sie waren als Ersatzteile etwas schwer zu finden, aber immer noch verfügbar. Da der originale Knopf verloren gegangen war, habe ich ein anderes Potentiometer verwendet, das mit einem Knopf geliefert wurde. Leider ist der neue weiß, während der originale wahrscheinlich schwarz war, daher konnte ich den ursprünglichen äußeren Look nicht vollständig wiederherstellen.
Das Gehäuse war an einer Seite aufgebrochen, weil innen zwei Stifte abgebrochen waren. Ich habe die Stifte mit Sekundenkleber repariert. Danach habe ich das Gehäuse für einen Tag in die Sonne gelegt, was die Vergilbung ein gutes Stück entfernt hat. Dann konnte ich alles wieder zusammensetzen. Im Vergleich zum Originalzustand sieht das Action Replay jetzt wieder schön und sauber aus.
Ich habe einen Testlauf in meinem Amiga 500 gemacht, und es funktionierte einwandfrei! Jetzt habe ich ein Action Replay für meine Amiga-Sammlung. Das einzig Traurige ist, dass man es nicht auf ein MK-II oder MK-III aufrüsten kann, da diese Module anders aufgebaut sind.
AmigaOS war ein Betriebssystem, das seiner Zeit weit voraus war. Es hatte Funktionen, die anderen Heim-Betriebssystemen (wie Windows oder MacOS) damals fehlten, wie präemptives Multitasking. Es gab auch eine Funktion namens Zuweisungen (Assignments). Das vermisse ich wirklich bei Linux!
Ein Amiga-“Assign” ist ein wenig wie der Laufwerksbuchstabe, den du vielleicht von Windows kennst. Zum Beispiel bezieht sich der Windows-Pfad C:\example.txt auf eine Datei namens example.txt im Hauptverzeichnis der Hauptpartition, während dieselbe Datei auf dem ersten Diskettenlaufwerk A:\example.txt heißt.
Auf dem Amiga heißt die Hauptpartition normalerweise DH0:, die zweite Partition DH1: und so weiter, während das erste Diskettenlaufwerk DF0: heißt. Ein ähnlicher Pfad auf dem Amiga wäre also DH0:example.txt oder DF0:example.txt.
Wie du sehen kannst, kann ein “Laufwerksbuchstabe” auf dem Amiga tatsächlich aus mehreren Zeichen und auch Zahlen bestehen. Dies wird als Zuweisung bezeichnet. Der Name DH0 ist der Hauptfestplattenpartition zugewiesen.
Aber warte, da ist noch mehr!
Du kannst mehrere Assigns haben, die auf dasselbe Ziel verweisen. Zum Beispiel enthält die Hauptpartition normalerweise die Amiga-Desktop-Umgebung namens Workbench. Aus diesem Grund hat die Hauptpartition auch ein Label wie Workbench, und auf die Datei könnte auch als Workbench:example.txt zugegriffen werden.
Das ist eigentlich ein ziemlich cleveres Konzept, besonders für austauschbare Medien. Stellen wir uns zum Beispiel vor, wir haben gerade ein Spiel namens shredzone gestartet, und es muss auf eine Datei Music/Opening.mod auf seiner Installationsdiskette zugreifen (AmigaOS verwendet einen Schrägstrich als Dateitrennzeichen, wie alle ordentlichen Betriebssysteme). Es würde eine Datei namens shredzone:Music/Opening.mod öffnen.
AmigaOS würde sehen, dass es keine Zuweisung namens shredzone gibt, und würde einen solchen Dialog öffnen:
Aus Benutzersicht wüsste ich nun, dass ich ein Medium namens shredzone finden und in den Computer einlegen muss. Es spielt keine Rolle, ob es sich um eine Diskette, eine CD oder sogar um einen Netzwerk-Mount handelt. AmigaOS befiehlt mir auch nicht, das Medium in ein bestimmtes Laufwerk einzulegen. Wenn es eine Diskette ist und ich mehrere Diskettenlaufwerke habe, kann ich einfach das auswählen, das ich möchte. AmigaOS erkennt dann, dass ein Medium mit diesem Namen eingelegt wurde, schließt den Dialog und gewährt dem Spiel Zugriff auf die Datei.
Unter Linux müsste ich auf dieses Medium unter einem Pfad wie /run/media/shred/shredzone zugreifen, was viel zum Tippen ist, meinen Benutzernamen enthält und schwerer zu merken ist als nur shredzone:.
Aber warte, da ist immer noch mehr! 😄
Es ist einfach, dem System über die Befehlszeile Zuweisungen hinzuzufügen. Es ist sogar möglich, Unterverzeichnisse als Zuweisungsziel zu verwenden. Bleiben wir bei unserem shredzone-Spielbeispiel. Ich war es leid, jedes Mal die Installationsdiskette einlegen zu müssen, wenn ich dieses Spiel spielen möchte. Also erstelle ich ein Verzeichnis namens DH2:Games/Shredzone/Files auf meiner Festplatte und kopiere alle Dateien von dieser Diskette in dieses Verzeichnis.
Danach gebe ich diesen Befehl in die Befehlszeile ein:
assign shredzone: DH2:Games/Shredzone/Files
Wenn ich das Spiel jetzt starte, sieht AmigaOS, dass bereits ein shredzone-Assign existiert, und greift dort auf die Dateien zu. Auf die Songdatei shredzone:Music/Opening.mod würde also unter DH2:Games/Shredzone/Files/Music/Opening.mod zugegriffen.
AmigaOS nutzt Zuweisungen auch selbst. Zum Beispiel gibt es eine Standardzuweisung namens C:. Sie zeigt normalerweise auf das Verzeichnis C des bootenden Geräts, wo alle Kommandozeilenbefehle (wie dir, copy, delete usw.) erwartet werden. Dieses Assign ähnelt dem, was $PATH für eine Linux-Shell ist.
Stell dir vor, ich habe eine Reihe von Entwicklungswerkzeugen installiert, wie einen Assembler und einen C-Compiler. Die Befehle dieses Toolsets befinden sich unter DH1:Development/DevTools/C. Auf einem Linux-System würde ich diesen Pfad zur Umgebungsvariablen $PATH hinzufügen, damit ich einfach den Befehlsnamen eingeben kann, um einen dieser Befehle auszuführen.
Auf AmigaOS füge ich diesen Pfad einfach zu einer bestehenden Zuweisung hinzu:
assign add C: DH1:Development/DevTools/C
Nun weiß AmigaOS, dass es, wenn ich einen Befehl in die Befehlszeile eingebe, in Workbench:C danach suchen muss, und wenn er dort nicht gefunden wird, wird es versuchen, ihn in DH1:Development/DevTools/C zu finden. Ich könnte sogar Befehle wie dir C: ausführen und alle Dateien in beiden Verzeichnissen sehen. Natürlich ist dies nicht auf zwei Ziele beschränkt.
Es gibt noch mehr, wie z.B. verzögerte Assigns (deferred assigns). Aber ich möchte dir nur einen allgemeinen Eindruck davon vermitteln, was Amiga-Assigns sind und warum ich sie bei Linux vermisse.