Handbuch v0.94 - Amiga Imager

Worum es in diesem Handbuch geht

Dieses Handbuch ist der aktuelle Praxisleitfaden fuer Amiga Imager v0.94. Es beschreibt den Build-Alltag, die unterstuetzten Plattformen, den aktuellen Schreibpfad auf reale Medien und vor allem, was sich geaendert hat, seit die all-native Build-Engine der normale Standardpfad fuer Builds ist.

Was die App macht

Amiga Imager ist eine native macOS-App zum Bauen, Verwalten und Schreiben startfaehiger Amiga-Systeme aus einem Workflow heraus.

PiStorm / Emu68 und Classic Amiga werden als .img-Dateien gebaut.
Emulator- und MiSTer-Builds werden als .hdf-Dateien gebaut.
Fertige Images koennen direkt auf SD-, CF-, SSD- oder USB-Medien geschrieben werden.
Amiga File Manager erlaubt das Durchsehen von Images und unterstuetzten Amiga-Medien direkt unter macOS.
Greaseweazle bleibt der aktuelle native Floppy-Workflow auf macOS.
v0.94 macht die native Build-Engine zur Hauptgeschichte fuer Standard-Builds auf PiStorm, Classic, UAE, Amiberry und MiSTer.

Was du vor dem Start brauchst

Fuer einen normalen Build sollten diese Dinge vorbereitet sein:

ein Mac mit macOS 14 Sonoma oder neuer
eine gueltige Kickstart-ROM
passende AmigaOS-Installationsmedien
ein Zielmedium wie SD-, CF-, SSD- oder USB-Datentraeger, wenn direkt geschrieben werden soll
Internetzugang fuer optionale Paket-Downloads

Welche Quelldateien noetig sind, haengt weiterhin von der gewaehlten AmigaOS-Version ab:

AmigaOS 3.1 / 3.1.4: ADF-Quellordner
AmigaOS 3.2.x: ADF-Quellordner oder 3.2-CD-ISO
AmigaOS 3.9: CD-ISO plus Boing Bag 1 und Boing Bag 2

Die Haupt-Workflows

Build bootable image

Das bleibt der wichtigste Modus. Plattform waehlen, OS-Medien und ROM angeben, optionale Software und Hardware-Einstellungen setzen, die Build Summary pruefen und anschliessend ein einsatzbereites Image erzeugen.

Build & Write to Card

Wenn ohne getrennten Export direkt auf ein reales Medium geschrieben werden soll, nutzt dieser Workflow denselben Build-Pfad und schreibt anschliessend unmittelbar auf das Zielmedium. Leere Bereiche muessen dabei nicht unnoetig voll geschrieben werden.

Flash existing image

Dieser Modus schreibt ein bereits vorhandenes Image auf ein reales Medium. Image auswaehlen, Zieldatentraeger auswaehlen, bei Bedarf Only show external disks aktiv lassen und dann Write to Disk klicken.

So funktioniert der aktuelle Build-Ablauf

1. Grundlegende Eingaben festlegen

Target platform auswaehlen: PiStorm / Emu68, Classic Amiga oder Emulator / MiSTer.
AmigaOS version waehlen. Wenn moeglich auf Auto lassen und mit Check Media pruefen.
Je nach OS-Version ADF source, ISO oder beides angeben.
Die Amiga ROM auswaehlen.
Den output image path oder direkt das Schreibziel festlegen.

2. Entscheiden, ob Simple reicht oder Advanced noetig ist

Simple bleibt der schnellste Weg. Advanced schaltet die volle Auswahl fuer Hardware, Archive, Transfer-Ordner, Custom Packages per URL, WBDock, eigene Image-Groessen und gespeicherte Profile frei.

3. Die Build-Karten durchgehen

Die aktuelle Struktur mit Input, Configuration, Optional Software und Image & Build bleibt erhalten. Der groesste Unterschied in v0.94 ist weniger ein sichtbarer UI-Wechsel als die Tatsache, dass der eigentliche Build unter der Haube jetzt ueberwiegend nativer laeuft.

So arbeitet die native Engine in v0.94

Die wichtigste Architektur-Aenderung in v0.94 ist, dass Standard-Builds jetzt ueber die In-Process-Swift-Engine laufen und nicht mehr fuer den Hauptteil der Arbeit auf den aelteren, script-lastigen Pfad angewiesen sind.

Die App loest zuerst den Plan auf - Plattform, Image-Groesse, Partitionslayout, Pakete und benoetigte Assets werden vor dem eigentlichen Build geprueft.
Die native Engine uebernimmt den Standardpfad - normale PiStorm-, Classic-, UAE-, Amiberry- und MiSTer-Builds laufen jetzt innerhalb des App-Prozesses.
AmigaDiskKit uebernimmt die Low-Level-Disk-Arbeit - dazu gehoeren jetzt groessere Teile des echten Build-Pfads fuer RDB, FFS, PFS3, ADF, LHA und den PiStorm-FAT32-Boot-Workflow.
Weniger Glue in der Mitte - weniger Uebergaben zwischen Shell-Scripts, Hilfstools und nativer UI machen Verifikation und spaetere Erweiterungen sauberer.
Fallback bleibt dort, wo er sinnvoll ist - ausgeschlossene oder historische Sonderfaelle koennen weiterhin den aelteren Pfad nutzen, aber die Hauptgeschichte des Releases ist jetzt die native Engine.

Praktisch ist v0.94 damit der Punkt, an dem sich die native Engine nicht mehr wie ein Parallelpfad anfuehlt, sondern wie die eigentliche Grundlage des Produkts.

Plattformspezifische Hinweise fuer v0.94

PiStorm / Emu68

Der Build erzeugt eine .img-Datei.
v0.94 fuehrt den vollstaendig nativen PiStorm-Pfad fuer RDB, FFS, PFS3 und den FAT32-Boot-Workflow weiter.
FrameThrower, Wi-Fi und die aktuellen PiStorm-spezifischen Einstellungen bleiben Teil des normalen Konfigurationsflusses.
Der Legacy-Disk-Pfad ist nur noch als Fallback oder Vergleichsweg interessant.

Classic Amiga

Classic-Builds werden ebenfalls als .img erzeugt.
Aktuelle RTG- und Netzwerk-Optionen bleiben ueber die Advanced-Hardwareauswahl verfuegbar.
Wichtig in v0.94 ist, dass auch Classic-Standard-Builds jetzt auf derselben nativen Build-Basis sitzen und sich nicht mehr wie ein separater Script-Pfad anfuehlen.

Emulator und MiSTer

Emulator- und MiSTer-Builds werden als .hdf erzeugt.
UAE und Amiberry sind bestaetigt getestet und funktionierend.
MiSTer ist ebenfalls mit RTG-Support bestaetigt.
v0.94 fuehrt auch diese Builds auf derselben nativen Engine-Basis weiter.

Floppy-Workflows im aktuellen Release-Kandidaten

Greaseweazle bleibt der aktuelle native Floppy-Pfad auf macOS und ist heute der unterstuetzte Weg fuer reale Amiga-Disketten.

reale Disketten als .adf einlesen
.adf-Dateien zurueck auf Diskette schreiben
Disketteninhalte aus dem nativen macOS-Workflow heraus durchsuchen

DrawBridge ist jetzt als experimenteller Pfad neben Greaseweazle vorhanden. Der wichtige aktuelle Vorbehalt ist, dass die DrawBridge-Command-Bytes und das 2-Bit-Mapping auf echter Hardware noch validiert werden muessen, bevor physische Reads als verlaesslich gelten sollten.

Settings-Fenster (Cmd+,)

Das aktuelle App-Build besitzt weiterhin getrennte Bereiche fuer Build, Storage, PiStorm, Classic und Debug.

Build: allgemeines Build-Verhalten, Asset-Pfade, Exposition und Custom Packages
Storage: Reduktionswerte, damit Images verlaesslicher auf reale Karten und Datentraeger passen
PiStorm: Boot-Bundle-Quelle, Prerelease-Verhalten und PiStorm-spezifische Optionen
Classic: Classic-Hardwarehilfen wie A314-bezogenes Verhalten
Debug: Diagnose und Legacy-Vergleichsoptionen fuer Engine-Arbeit

Fehlersuche

Der Build laesst sich nicht starten

Meist fehlen weiterhin Installationsmedien, Kickstart-ROM, ein Ausgabe-Pfad oder bei AmigaOS 3.9 die zusaetzlichen Boing-Bag-Dateien.

Der Build faellt auf aelteres Verhalten zurueck

Bei ungewoehnlichen Medienkombinationen oder Legacy-Sonderfaellen kann die App weiterhin Fallback-Verhalten nutzen. Das bedeutet nicht, dass die native Engine fuer normale Builds nicht aktiv ist.

Schreiben auf Datentraeger scheitert unter macOS

Full Disk Access fuer Amiga Imager unter System Settings -> Privacy & Security -> Full Disk Access aktivieren und danach erneut versuchen. Ein erneutes Einstecken des Zielmediums kann ebenfalls helfen.

A314 funktioniert nicht

Pruefen, ob als Netzwerk-Stack Roadshow Demo oder Roadshow Full aktiv ist. Mit None wird A314 nicht unterstuetzt.

Ein Custom Package wird nicht installiert

Paketname und direkte Download-URL unter Settings -> Build -> Custom Packages pruefen. Die Datei sollte ein gueltiges Archiv sein, idealerweise ein .lha-Paket.

Es wird Hilfe bei einem Problem benoetigt

Nach dem Fehler Export Log verwenden und die Angaben aus der Build Summary sichern. Mit der nativen Engine ist das Log noch hilfreicher geworden, weil mehr vom echten Build-Pfad in einem zusammenhaengenden System laeuft.