Handbuch
Aktuelles Handbuch fuer Amiga Imager v0.99. Dieser Leitfaden wurde mit dem aktuellen 0.99 / 260717 Build abgeglichen und deckt den voll nativen Build-Pfad, Vampire V4, IMP3-Community-Tools, die aktuelle PiStorm-Boardlogik, USB, WHDLoad-Sammlungen mit iGame beim ersten Start sowie den Werkzeugkasten rund um Amiga File Manager, Greaseweazle und direktes Schreiben auf Medien ab.
Dieses Handbuch ist der aktuelle Praxisleitfaden fuer Amiga Imager v0.99. 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. Neu wichtig fuer v0.99 sind vor allem der Vampire-V4-Pfad, die IMP3-Community-Tools, die direkte Einbindung eigener WHDLoad-Sammlungen sowie USB- und Desktop-Fixes aus Tests auf echter Hardware.
Amiga Imager ist eine native macOS-App zum Bauen, Verwalten und Schreiben startfaehiger Amiga-Systeme aus einem Workflow heraus.
.img-Dateien gebaut..hdf-Dateien gebaut.Fuer einen normalen Build sollten diese Dinge vorbereitet sein:
Welche Quelldateien noetig sind, haengt weiterhin von der gewaehlten AmigaOS-Version ab:
Optional, aber fuer aktuelle Setups oft sinnvoll:
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.
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.
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.
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.
PiStorm / Emu68, Classic Amiga oder Emulator / MiSTer.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.
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.
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.
lha- und 7z-Bootstrap-Wege sind entfernt.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.
.img-Datei..img erzeugt..hdf erzeugt.Greaseweazle bleibt der aktuelle native Floppy-Pfad auf macOS und ist heute der unterstuetzte Weg fuer reale Amiga-Disketten.
.adf einlesen.adf-Dateien zurueck auf Diskette schreibenDrawBridge 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.
Das aktuelle App-Build besitzt weiterhin getrennte Bereiche fuer Build, Storage, PiStorm, Classic und Debug.
Meist fehlen weiterhin Installationsmedien, Kickstart-ROM, ein Ausgabe-Pfad oder bei AmigaOS 3.9 die zusaetzlichen Boing-Bag-Dateien.
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.
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.
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.
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.
Pruefen, ob als Netzwerk-Stack Roadshow Demo oder Roadshow Full aktiv ist. Mit None wird A314 nicht unterstuetzt.
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.
Paketname und direkte Download-URL unter Settings -> Build -> Custom Packages pruefen. Die Datei sollte ein gueltiges Archiv sein, idealerweise ein .lha-Paket.
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.
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.