Chiba City

Wie bekommt man Daten komfortabel auf einen Power Macintosh 7600 — ohne Brenner, ohne Netzwerk-Bastelei, ohne Disketten-Turnschuh? Meine Antwort seit diesem Wochenende: ein einziges Festplatten-Image, das drei Maschinen nativ lesen und beschreiben können — das MacBook Air M4, eine Mac-OS-9.2.2-VM unter UTM und die echte 7600 mit BlueSCSI v2. Hier ist der Weg dorthin, inklusive aller Stolpersteine.

Die Ausgangslage

Auf dem M4 läuft seit kurzem Mac OS 9.2.2 in UTM (QEMU, PowerPC-Emulation, Maschine mac99). Die 7600 hängt längst am BlueSCSI v2 und bootet ihre Systeme von SD-Karte. Was fehlte, war die Brücke: ein Austausch-Volume, das ich am modernen Mac befülle, in der VM mit echtem OS 9 bearbeite und dann einfach auf die SD-Karte der 7600 lege.

Die Idee liegt auf der Hand, denn BlueSCSI-Images sind nichts anderes als rohe Sektor-Abbilder — Apple Partition Map, HFS-Volumes, fertig. Der Bus (SCSI, IDE, USB) ist dem Dateiformat egal. Genau deshalb kann QEMU dieselben Images als IDE-Platte servieren, die BlueSCSI der 7600 als SCSI-Platte anbietet.

Stolperstein 1: SheepShaver-Images sind keine echten Platten

Mein erster Versuch: ein vorhandenes Image, das unter SheepShaver seit Jahren brav funktioniert, als IDE-Platte in die UTM-VM hängen. Ergebnis im Apple System Profiler: Platte erkannt, aber „Mac OS Partitionen: 0", kein Volume aktiviert.

Des Rätsels Lösung: SheepShaver und Basilisk II arbeiten mit „Hardfiles" — rohen HFS-Volumes ohne Partitionstabelle. Die Emulatoren blenden die Partitionslogik komplett aus. Ein echtes Mac OS (und die QEMU-VM ist aus Sicht des Gastsystems ein echter Mac) verlangt dagegen zwingend eine Apple Partition Map am Plattenanfang. SheepShaver ist beim Plattenformat schlicht toleranter als echte Hardware — die QEMU-VM erwies sich hier als die strengere und damit ehrlichere Verifikationsinstanz.

Die Lösung: Drive Setup partitioniert, alle profitieren

Statt vorhandene Images umzubauen, habe ich den umgekehrten Weg gewählt: In UTM eine neue Platte anlegen und sie vom OS 9 in der VM selbst mit „Laufwerke konfigurieren" (Drive Setup) initialisieren. Das Ergebnis ist ein Image mit allem, was ein klassischer Mac erwartet — sichtbar, wenn man es am Host mountet:

$ hdiutil attach .../Data/C57CA640-....img

/dev/disk4s1   Apple_partition_map

/dev/disk4s2   Apple_Driver43

/dev/disk4s4   Apple_Driver_ATA

/dev/disk4s6   Apple_FWDriver

/dev/disk4s9   Apple_HFS        /Volumes/Chiba

Drive Setup schreibt neben den ATA-Treibern auch die klassischen SCSI-Treiberpartitionen (Apple_Driver43) mit — das Image ist damit von Haus aus BlueSCSI-tauglich.

Zwei Details machen das Setup rund:

Raw statt qcow2. UTM legt Platten standardmäßig im qcow2-Format an — platzsparend, aber nur QEMU versteht es. Beim Anlegen lässt sich stattdessen ein Raw-Image wählen. Der Lohn: macOS kann die Datei direkt mit hdiutil attach mounten (HFS+ liest und schreibt der Mac bis heute), und BlueSCSI kann sie unverändert verwenden. Kein Konvertieren, keine Zwischenschritte.

Ein Name mit Programm. Das Volume heißt Chiba — nach Gibsons Chiba City, dem Umschlagplatz, an dem die Technik von überall her zusammenläuft. Genau das ist die Rolle dieses Volumes.

Stolperstein 2: Das falsche Image auf der SD-Karte

Der erste Test an der 7600 schlug fehl — „Laufwerke konfigurieren" zeigte auf der SCSI-ID nur „". Der Apple System Profiler lieferte den entscheidenden Hinweis: Die gemeldete Gerätegröße passte nicht zum Image. Des Rätsels Lösung war profan: Auf der SD-Karte lag versehentlich eine qcow2-Datei aus der falschen VM. Ein qcow2 beginnt mit einem QCOW-Header statt mit der Partition Map — für die 7600 ist das Kauderwelsch.

Merksatz daraus: Vor dem Kopieren einen Blick auf Größe und Art der Datei werfen. Der Finder verrät qcow2-Dateien als „QCOW archive", Raw-Images schlicht als „Image". Und die Dateigröße muss byte-genau zur Nenngröße des Volumes passen.

Stolperstein 3: Der Finder mag keine großen Kopien auf frische SD-Karten

Beim Kopieren des 8-GB-Images auf die (exFAT-formatierte — wichtig, FAT32 kann keine Dateien über 4 GB) SD-Karte blieb der Finder bei „0 Byte, verbleibende Zeit berechnen…" hängen. Übliche Verdächtige: Spotlight, das die frisch eingelegte Karte indizieren will.

Das Terminal war unbeeindruckt:

$ mdutil -i off /Volumes/PM7600B

$ cp -v ".../Data/C57CA640-....img" "/Volumes/PM7600B/HD2_512 Chiba.hda"

$ diskutil eject /Volumes/PM7600B

Der Dateiname folgt dem BlueSCSI-Schema: HD2_512 bedeutet SCSI-ID 2 mit 512-Byte-Sektoren. Danach Karte in den BlueSCSI, 7600 einschalten — und Chiba erschien auf dem Schreibtisch, als hätte es nie anders sein können. Der erste Kopierjob (StuffIt-Archive und Werkzeuge, gut 15.000 Objekte) lief direkt durch.

Der Workflow im Alltag

Damit sieht der Kreislauf jetzt so aus:

1. 1.Befüllen am M4: VM herunterfahren, Image per hdiutil attach mounten, Dateien per Finder auf /Volumes/Chiba ziehen, auswerfen. Klassische Mac-Software gehört dabei verpackt aufs Volume (.sit, .bin, .hqx) und wird erst auf dem Zielsystem entpackt — sonst verlieren die Dateien ihre Resource Forks und Typ-/Creator-Codes.
   

2. 2.Arbeiten in der VM: Image hängt als IDE-Platte in UTM, OS 9.2.2 liest und schreibt nativ.
   

3. 3.Reise zur 7600: Datei auf die SD-Karte kopieren (Terminal!), nach BlueSCSI-Schema benennen, fertig.
   

Die eine Disziplin, die das Setup verlangt: Nie zwei Instanzen gleichzeitig auf dasselbe Image lassen. Host-Mount bei laufender VM — oder parallele Änderungen in VM und auf der 7600 — enden zwangsläufig in HFS-Schäden, weil keine Seite von der anderen weiß. Ich behandle Chiba deshalb wie eine echte Wechselplatte mit klarer Flussrichtung pro Reise: befüllen, transportieren, zurückspielen.

Fazit

Kein Brenner, kein AppleTalk-Server, keine Adapterkarten — nur ein Image, das die Regeln des klassischen Mac OS respektiert, und drei Systeme, die es dadurch als das akzeptieren, was es vorgibt zu sein: eine ganz normale Festplatte. Die Werkzeuge dafür lagen die ganze Zeit bereit; man muss die Kette nur einmal sauber durchdeklinieren. Zwischen dem Anlegen der VM und dem ersten Kopierjob auf der 7600 lag genau ein Wochenende — inklusive aller Irrwege, die dieser Artikel hoffentlich abkürzt.