Handbuch

Amiga Imager v0.99.5

Aktuelles Handbuch fuer Amiga Imager v0.99. Dieser Leitfaden wurde mit dem aktuellen 0.99.5 / 260727 Build abgeglichen. Neu in diesem Punkt-Release: der Paketmanager amipkg 0.5.2 mit dem signierten AmigaPKG-Katalog von ueber 200 Paketen auf jedem Image. Dazu weiterhin der voll native Build-Pfad, Vampire V4, IMP3-Community-Tools, die aktuelle PiStorm-Boardlogik, USB, WHDLoad-Sammlungen mit iGame beim ersten Start sowie Amiga File Manager, Greaseweazle und direktes Schreiben auf Medien.

Download v0.99.5 Handbuch PDF Zurueck zu den Downloads
  • Mit Build 260727 abgeglichen
  • Deutscher Referenzleitfaden
  • Aktuell fuer das oeffentliche v0.99.5-Release
Zurueck zu den Downloads

Worum es in diesem Handbuch geht

Dieses Handbuch ist der aktuelle Praxisleitfaden fuer Amiga Imager v0.99.5. 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 den gesamten Produktpfad traegt. Die grosse Neuerung in v0.99.5 ist der Paketmanager amipkg, der jetzt auf jedem gebauten Image liegt und Software aus dem signierten AmigaPKG-Katalog direkt auf dem laufenden Amiga installiert - ein eigenes Kapitel weiter unten erklaert ihn im Detail. Aus v0.99 weiterhin wichtig: der Vampire-V4-Pfad, die IMP3-Community-Tools, die direkte Einbindung eigener WHDLoad-Sammlungen sowie USB- und Desktop-Fixes aus Tests auf echter Hardware.

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.99 uebernimmt eigene WHDLoad-Spielesammlungen weiter direkt in das fertige System, baut den iGame-Index schon vor dem ersten Start und erweitert den Classic-Pfad um Vampire V4.
  • Die Roadshow-Demo ist Teil des Standardpfads, waehrend Roadshow Full weiterhin mit eigenem Archiv genutzt werden kann.
  • Die neuen IMP3-Community-Tools koennen optional mit vorbereitet werden, ohne die Community-eigenen Skripte direkt in die App zu ziehen.
  • Der Build-, Disk- und Archivpfad laeuft jetzt durchgaengig nativ, inklusive der Host-seitigen Archivverarbeitung.
  • Jedes Image bringt den Paketmanager amipkg mit: Software aus dem signierten AmigaPKG-Katalog installieren, aktualisieren und sauber entfernen - direkt auf dem Amiga oder vom Mac aus (Manage Amiga Software).

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

Optional, aber fuer aktuelle Setups oft sinnvoll:

  • ein gekauftes Picasso96-Archiv von Individual Computers
  • ein eigenes Roadshow.lha, wenn die Vollversion statt der gebuendelten Demo genutzt werden soll
  • Registrierungsdateien fuer IBrowse oder IMP3

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.

Guided Build

Auch in v0.99 bleibt der Vollbild-Assistent der einfachste Einstieg. Er fuehrt klar durch Plattform, Hardware, Sprache, lizenzierte Dateien, Zielmedium und Build-Review. Bei PiStorm sind Board-Auswahl, USB, FrameThrower und WLAN sauber voneinander abgegrenzt, und im Classic-Pfad passt der Build jetzt auch besser zu Vampire-Hardware.

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. v0.99 prueft ADF-Ordner dabei nur auf der obersten Ebene, wie es auch der Build spaeter macht, und kann einen offensichtlichen Unterordner direkt uebernehmen.
  • Die Amiga ROM auswaehlen. Mehr Hyperion-3.2.x-ROM-Varianten werden direkt erkannt, und bei Bedarf greift die App auf den Kickstart-Header zurueck.
  • Den output image path oder direkt das Schreibziel festlegen.

2. Entscheiden, ob Simple reicht oder Advanced noetig ist

Simple bleibt der schnellste Weg und nutzt den Standardpfad inklusive Roadshow Demo. 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.99 ist, dass der Produktpfad nicht nur nativ bleibt, sondern jetzt auch den Vampire-V4-Zielpfad, die IMP3-Community-Tools und die juengsten realen Hardware-Fixes integriert.

So arbeitet die native Engine in v0.99

Die wichtigste Architektur-Aenderung in v0.99 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 innerhalb des App-Prozesses.
  • AmigaDiskKit uebernimmt die Low-Level-Disk-Arbeit - dazu gehoeren RDB, FFS, PFS3, ADF, LHA und der PiStorm-FAT32-Boot-Workflow.
  • Auch die Host-seitige Archivverarbeitung bleibt jetzt nativ - die letzten lha- und 7z-Bootstrap-Wege sind entfernt.
  • AmigaOS 3.9 bleibt nativer Teil des Hauptpfads - CD-ISO-Installationen plus Boing Bag 1 und Boing Bag 2 laufen ueber alle unterstuetzten Zielfamilien hinweg auf derselben Basis.
  • Weniger Glue in der Mitte - weniger Uebergaben zwischen Shell-Scripts, Hilfstools und nativer UI machen Verifikation und spaetere Erweiterungen sauberer.

Praktisch ist v0.99 damit der Punkt, an dem sich nicht nur die Build-Engine, sondern der komplette Produktpfad wie die native Grundlage des Produkts anfuehlt.

Plattformspezifische Hinweise fuer v0.99

PiStorm / Emu68

  • Der Build erzeugt eine .img-Datei.
  • v0.99 behaelt die board-spezifische Logik fuer A1200 PiStorm32-lite, A600 PiStorm16 und PiStorm Classic bei.
  • FrameThrower, Wi-Fi und USB bleiben Teil des normalen PiStorm-Konfigurationsflusses.
  • PiStorm Classic startet konservativer: der Classic-Kernel-Pfad bleibt explizit und der Turbo-Overclock ist im v1.1-Classic-Pfad auskommentiert.

Classic Amiga

  • Classic-Builds werden ebenfalls als .img erzeugt.
  • Aktuelle RTG- und Netzwerk-Optionen bleiben ueber die Advanced-Hardwareauswahl verfuegbar.
  • USB-Hostkarten nutzen den Poseidon-Pfad, wenn eine unterstuetzte Karte ausgewaehlt ist.
  • Die IMP3-Community-Tools koennen auch auf Classic-Builds vorbereitet werden, damit die noetigen gemeinsam genutzten Libraries und CLI-Werkzeuge direkt vorhanden sind.
  • Wichtig in v0.99 ist, dass die Dateisysteme pro Partition sauber respektiert werden, statt durch eine vereinfachte Primary-Annahme zusammengezogen zu werden.

Vampire V4 / Apollo 68080

  • v0.99 fuehrt einen eigenen Zielpfad fuer Vampire-V4-Systeme ein.
  • Der Build bereitet SAGA RTG, V4Net beziehungsweise V2ExpEth und das Onboard-SD-Verhalten passend vor.
  • Die Apollo-Kickstart-Tools gehoeren absichtlich dazu, weil Vampire-Hardware den Boot-Pfad anders lebt als ein generischer Classic-Amiga.
  • USB ist im RC sauberer in den First-Boot-Pfad integriert und stoert den Systemstart nicht mehr so leicht.

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

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.

Die App haelt sich selbst auf dem Laufenden

Seit v0.99.6 prueft Amiga Imager einmal am Tag (und auf Wunsch ueber Amiga Imager -> Check for Updates…), ob ein neueres Release existiert. Die Pruefung liest ein kryptographisch signiertes Versions-Manifest - verifiziert gegen einen fest in die App eingebauten Schluessel, dem Webserver wird nie vertraut - und zeigt bei einer neueren Version ein dezentes Banner mit Details-Knopf. Nichts laedt oder installiert sich selbst: Das Update bleibt immer dein Klick auf der Download-Seite. Der automatische Check laesst sich unter Settings -> Build -> Check for app updates at launch abschalten.

Der Paketmanager (amipkg) und der AmigaPKG-Katalog

Jedes von Amiga Imager gebaute Image enthaelt amipkg - einen Paketmanager fuer AmigaOS 3.x im Geist von Homebrew oder apt. Er installiert, aktualisiert und entfernt Software aus AmigaPKG, einem kuratierten, kryptographisch signierten Katalog von ueber 200 frei verteilbaren Klassikern und Werkzeugen - direkt auf dem laufenden Amiga. amipkg funktioniert auch auf jedem anderen 3.x-System vom A500 aufwaerts: Das eigenstaendige amipkg.lha gibt es kostenlos auf GitHub und auf Aminet.

Auf dem Amiga

amipkg wohnt in einem Home-Verzeichnis - SYS:Tools/AmigaImager, veroeffentlicht als Assign AMIPKG:. CLI, beide GUIs, der signierte Katalog, der Download-Cache und die Receipt-Datenbank liegen dort zusammen (wie bei MUI:), so dass das Self-Update immer die tatsaechlich genutzten Programme trifft:

  • AMIPKG:amipkg-mui - die MUI-Oberflaeche (braucht MUI 3.8+, keine zusaetzlichen Klassen): Toolbar, Sidebar mit Ansicht- und Kategorien-Filter, sortierbare Spalten, Beschreibungsfeld und Statusleiste mit Live-Zaehlern. Ein Fehlschlag zeigt die vollstaendige Meldung in einem Requester.
  • AMIPKG:amipkg-gui - die GadTools-Oberflaeche: dieselben Funktionen, laeuft auf jedem 3.x-System ganz ohne Abhaengigkeiten.
  • amipkg - die Shell-Version, die auch beide GUIs antreibt. Die wichtigsten Kommandos: amipkg update (Katalog holen), avail, info, install <id> (mit DRYRUN nur als Vorschau), check, upgrade, remove <id>, adopt, doctor und dir (Install-Verzeichnis anzeigen oder aendern). Die vollstaendige Dokumentation liegt als AmigaGuide auf dem Image (AMIPKG:amipkg.guide, auch im Documentation-Menue der GUIs).

Auf gebauten Images erscheint amipkg auch im WBDock (die MUI-Version, wenn MUI installiert ist), und GlowIcons-Builds bekommen ein echtes Farb-Icon.

Installieren, aktualisieren, entfernen

Beim Installieren loest amipkg Abhaengigkeiten automatisch auf - eine App, die MUI oder AmiSSL braucht, bekommt es passend zur CPU der Maschine dazu - und zeigt den Plan (Pakete plus Downloadgroessen) vor der Ausfuehrung. Hardware-Anforderungen (CPU, Kickstart) und freier Plattenplatz werden vorab geprueft; unterbrochene Downloads setzen fort, wo sie aufgehoert haben. Jede App landet in ihrem eigenen Verzeichnis im Install-Ordner - und der kann auf jedem Laufwerk liegen, nicht nur auf der Boot-Partition: Standard SYS:Programs, aenderbar mit amipkg dir (z. B. amipkg dir Work:Software). Alles wird in einer Receipt-Datenbank festgehalten: remove loescht genau das, was installiert wurde, inklusive der User-Startup-Zeilen. Bereits vorhandene Programme uebernimmt amipkg adopt <id> <Verzeichnis> an Ort und Stelle - und amipkg upgrade amipkg aktualisiert den Paketmanager selbst.

Downloads brauchen einen TCP/IP-Stack (Roadshow oder das bsdsocket eines Emulators); das Blaettern im mitgelieferten Katalog geht offline. Katalog und fast alle Archive sind ueber einfaches HTTP erreichbar - fuer https-only-Quellen installiert amipkg auf Wunsch AmiSSL 5.x gleich mit.

Integriert, eigenstaendig - oder gar nicht. Beides liegt in Settings -> Packages -> Package Manager: Integrate into the system at boot (Standard: an) setzt beim Booten den AMIPKG:-Assign und legt das Verzeichnis auf den Shell-Pfad. Ausgeschaltet bleibt amipkg komplett eigenstaendig in seinem Verzeichnis, ohne irgendetwas am System zu veraendern. Und amipkg selbst ist voellig optional: Wer den Paketmanager nicht moechte, schaltet Install the package manager on built images aus - Amiga Imager baut dann komplett amipkg-freie Images, exakt wie zuvor.

Vom Amiga aus beitragen

Der Katalog ist keine Einbahnstrasse: Seit amipkg 0.6.x kann der Amiga selbst Einreichungen verfassen. Beide Oberflaechen bieten Submit a Package… (ein kleines Formular: Paket-Id, Archiv-URL, Kategorie, Beschreibung), das Shell-Aequivalent ist amipkg submit <id> <archiv-url> [CAT=<Kategorie>] [Beschreibung]. Die einreichende Maschine laedt das Archiv, berechnet den SHA-256-Pin selbst und schickt den Entwurf ein; ein Courier prueft den Pin gegen einen unabhaengigen Download, validiert den Eintrag und eroeffnet einen Review-Branch. Ein Maintainer prueft weiterhin Lizenz und Eintrag und signiert offline, bevor irgendetwas einen Katalog erreicht - der Amiga ist das Autorenwerkzeug, nie eine Abkuerzung am Vertrauensmodell vorbei. Bereits vorhandene Ids lehnt der Amiga sofort ab (neue Versionen bestehender Pakete holt die naechtliche Aktualisierung automatisch - keine Einreichung noetig).

Der AmigaPKG-Katalog und die Vertrauenskette

Der Katalog hinter amipkg ist ein offenes Projekt: github.com/thomas-luebker/amiga-pkg. Jeder Eintrag pinnt das exakte Archiv (SHA-256, Groesse, Mirrors) mit ehrlichen CPU-/Kickstart-Anforderungen und Abhaengigkeiten - und der gesamte Index prueft sich jede Nacht automatisch gegen die Upstream-Quellen und wird neu signiert. Der Amiga verifiziert die Ed25519-Signatur des Katalogs gegen einen fest eingebauten oeffentlichen Schluessel, und jeder Download muss zur SHA-256 im signierten Katalog passen - dem Download-Host wird nie vertraut, weshalb einfaches HTTP hier sicher ist. Fehlt ein Programm? Neue Pakete sind ein einfacher Pull-Request (eine JSON-Datei; die PACKAGING.md im Repo erklaert alle Felder).

Manage Amiga Software (auf dem Mac)

Dieselbe Paketverwaltung ohne laufenden Amiga: Der Paket-Button in der Toolbar (oder Shift-Cmd-P) oeffnet Manage Amiga Software. Ein gebautes .hdf/.img oeffnen und alle installierten Pakete mit Version und Update-Status sehen; suchen, installieren (mit Abhaengigkeitsaufloesung wie auf dem Amiga), einzeln oder alle aktualisieren, entfernen - und das Install-Verzeichnis frei waehlen: Voreinstellungen, ein Eintrag pro Laufwerk des Images oder ein beliebiger Pfad wie Work:Software ueber das Install-Drawer-Menue. Das Fenster bearbeitet direkt die Receipt-Datenbank des Images - Amiga und Mac sind sich also immer einig, was installiert ist.

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, Quick Look, Custom Packages und der taegliche App-Update-Check (signiertes Manifest, nur Benachrichtigung)
  • Storage: Reduktionswerte, damit Images verlaesslicher auf reale Karten und Datentraeger passen
  • PiStorm: Boot-Bundle-Quelle, Prerelease-Verhalten, EMU68BOOT-Auto-Mount und PiStorm-spezifische Optionen
  • Classic: Classic-Hardwarehilfen wie A314-bezogenes Verhalten sowie Vampire- und Apollo-spezifische Helfer
  • Packages: Package Manager (amipkg auf Images, Boot-Integration), Build Download Cache und Custom Packages
  • Debug: Diagnose und Entwickleroptionen fuer die 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.

Die ADF-Sammlung wird nicht erkannt

v0.99 scannt nur die oberste Ebene des ausgewaehlten Ordners. Wenn die Disketten in einem einzelnen Unterordner liegen, den vorgeschlagenen Wechsel verwenden oder direkt diesen Unterordner auswaehlen.

Die ROM wird gelb statt gruen erkannt

Auch ein gelber Haken ist eine positive Erkennung. Meist hat die App den Kickstart-Header statt eines exakten Hashes verwendet, was bei offiziellen Hyperion-3.2.x-Varianten voellig normal ist.

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.

Vampire landet in ApolloOS statt in AmigaOS

Wenn die Hardware noch ueber ihren ApolloOS-ROM-Pfad startet und ein Hinweis auf fehlende V47+-ROM-Module erscheint, zuerst den mitgelieferten Apollo-Pfad nutzen und die passende Kickstart-ROM per Apollo-Tool mappen oder flashen. Der Build bereitet diesen Weg vor, aber die reale ROM-Situation kommt weiterhin von der Hardware.

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.

Die WHDLoad-Spiele fehlen beim ersten Start

Pruefen, ob vor dem Build wirklich eine Games collection gesetzt war und ob auf der Zielpartition genug Platz fuer die entpackte Sammlung vorhanden ist. Wenn Spiele Kickstart-Dateien benoetigen, auch den Ordner fuer WHDLoad Kickstarts angeben.

Ein Paket laesst sich auf dem Amiga nicht installieren

Zuerst pruefen, ob der TCP/IP-Stack laeuft, dann amipkg update fuer den aktuellen Katalog. Ein Fehlschlag zeigt die vollstaendige Fehlermeldung in einem Requester - sie nennt die Ursache (z. B. fehlendes AmiSSL fuer https-Quellen oder zu wenig Plattenplatz) direkt.

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.