Handbuch

Amiga Imager v0.95

Aktuelles Handbuch fuer Amiga Imager v0.95. Dieser Leitfaden wurde mit dem aktuellen 0.95 / 260622 Build abgeglichen und deckt den voll nativen Standard-Build-Pfad, volle AmigaOS-3.9-Unterstuetzung sowie den aktuellen Werkzeugkasten rund um Amiga File Manager, Greaseweazle und direktes Schreiben auf Medien ab.

Download v0.95 Zurueck zu den Downloads
  • Mit Build 260622 abgeglichen
  • Deutscher Referenzleitfaden
  • Aktuell fuer den v0.95-Release
Zurueck zu den Downloads

Worum es in diesem Handbuch geht

Dieses Handbuch ist der aktuelle Praxisleitfaden fuer Amiga Imager v0.95. 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 jetzt fuer Standard-Builds komplett ist, inklusive voller AmigaOS-3.9-CD-ISO- und Boing-Bag-Unterstuetzung.

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.95 vervollstaendigt die native Build-Engine fuer Standard-Builds auf PiStorm, Classic, UAE, Amiberry und MiSTer, inklusive AmigaOS 3.9 vom CD-ISO mit Boing-Bag-Updates.

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.95 ist weniger ein sichtbarer UI-Wechsel als die Tatsache, dass jetzt auch volle AmigaOS-3.9-Builds und die verbleibenden Standard-Hardwarekombinationen auf dem nativen Pfad bleiben.

So arbeitet die native Engine in v0.95

Die wichtigste Architektur-Aenderung in v0.95 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.
  • AmigaOS 3.9 bleibt jetzt ebenfalls nativ - CD-ISO-Installationen plus Boing Bag 1 und Boing Bag 2 werden ueber alle unterstuetzten Zielfamilien hinweg auf dem nativen Pfad verarbeitet.
  • 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.95 damit der Punkt, an dem sich die native Engine nicht mehr wie der neue Weg anfuehlt, sondern wie die eigentliche Grundlage des Produkts.

Plattformspezifische Hinweise fuer v0.95

PiStorm / Emu68

  • Der Build erzeugt eine .img-Datei.
  • v0.95 fuehrt den vollstaendig nativen PiStorm-Pfad fuer RDB, FFS, PFS3, den FAT32-Boot-Workflow und volle AmigaOS-3.9-plus-Boing-Bag-Builds weiter.
  • FrameThrower, Wi-Fi und die aktuellen PiStorm-spezifischen Einstellungen bleiben Teil des normalen Konfigurationsflusses.
  • FrameThrower-Builds mit Emu68-Prerelease bleiben jetzt ebenfalls auf dem nativen Pfad.
  • 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.95 ist, dass auch Classic-Standard-Builds jetzt fuer die verbleibenden normalen Kombinationen auf derselben nativen Build-Basis sitzen, inklusive AmigaOS-3.9-CD-ISO-Installationen.

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.95 fuehrt auch diese Builds auf derselben nativen Engine-Basis weiter, inklusive nativer AmigaOS-3.9-plus-Boing-Bag-Installationen.

Floppy-Workflows im aktuellen Release

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.