Oeffentlicher Release - macOS 14+, Apple Silicon und Intel. Aktueller Build: 260621.
Was an v0.94 heraussticht
v0.94 baut auf allem auf, was seit v0.90 passiert ist, aber die
Release-Geschichte ist diesmal eine andere. Es geht nicht vor allem um
eine einzelne neue Oberflaechenfunktion, sondern darum, dass die
native Build-Engine jetzt ueber die drei wichtigen
Zielfamilien hinweg praktisch komplett ist:
PiStorm, Classic Amiga und
Emulator-Workflows.
- Native Build-Engine praktisch komplett - Standard-Workflows fuer PiStorm, Classic, UAE, Amiberry und MiSTer koennen jetzt ueber die In-Process-Swift-Engine laufen, statt stark vom aelteren Script-Pfad abzuhaengen.
- AmigaDiskKit traegt deutlich mehr vom Produkt - dieselbe Basis deckt jetzt Disk-Layout, Dateisysteme, PiStorm-FAT32-Boot-Handling, Dateizugriff und mehr vom echten Build-Pfad ab.
- Weniger Glue in der Mitte - weniger Uebergaben zwischen Shell-Skripten, Hilfswerkzeugen und nativer App bedeuten sauberere Verifikation und eine deutlich klarere Langzeit-Architektur.
- Greaseweazle bleibt der bewaehrte reale Floppy-Pfad - waehrend experimenteller DrawBridge-Support jetzt vorhanden ist, aber vor verlaesslichen physischen Reads noch Hardware-Validierung braucht.
Die native Engine ist jetzt selbst die Release-Geschichte
v0.90 hat den ersten oeffentlichen AmigaDiskKit-Engine-Pfad eingefuehrt.
v0.92 hat Amiga Imager zu einem breiteren nativen Werkzeugset gemacht.
v0.93 hat Teile davon in den Finder gebracht. v0.94 ist der Punkt, an
dem sich die Build-Pipeline selbst ueber die wichtigsten Zielplattformen
hinweg erstmals wirklich nativ anfuehlt.
- PiStorm-, Classic- und Emulator-Ziele teilen sich heute eine deutlich einheitlichere In-Process-Build-Architektur.
- Der native Pfad deckt jetzt mehr von der echten taeglichen Arbeit ab und nicht nur isolierte Formatier- oder Format-Sonderfaelle.
- Dadurch wirkt Amiga Imager immer weniger wie eine native UI ueber alten Script-Fugen und immer mehr wie ein wirklich zusammenhaengendes Produkt.
Was das praktisch bedeutet
Das ist optisch nicht der spektakulaerste Release, aber einer der
wichtigsten technischen Releases, die das Projekt bisher hatte.
- Bessere architektonische Konsistenz - mehr vom Disk-, Dateisystem- und Paketfluss lebt jetzt in einem zusammenhaengenden nativen Pfad.
- Sauberere Erweiterbarkeit - neue Plattformarbeit und neue Medien-Workflows muessen nicht mehr von einer shell-script-first-Basis ausgehen.
- Fallback dort, wo er sinnvoll bleibt - einige ausgeschlossene Randfaelle behalten weiter den Script-Fallback, aber die Hauptgeschichte des Releases ist jetzt die native Engine.
Floppy-Workflows: was heute gilt und was noch validiert werden muss
Greaseweazle bleibt heute der aktuelle native macOS-Floppy-Pfad
in Amiga Imager. Das ist weiterhin der reale unterstuetzte Weg fuer Lesen,
Schreiben und den praktischen Umgang mit physischen Amiga-Disketten.
- Greaseweazle bleibt first-class - der native Swift-Floppy-Stack ist weiterhin der aktuelle Pfad fuer echte Laufwerksarbeit auf macOS.
- DrawBridge ist jetzt experimentell dabei - es sitzt jetzt neben Greaseweazle und verbreitert die Floppy-Seite der App, ist aber noch nicht der Pfad, auf den man sich fuer physische Reads verlassen sollte.
- Was als Naechstes bestaetigt werden muss - auf echter Hardware muessen die DrawBridge-Command-Bytes und das 2-Bit-Mapping noch validiert werden, bevor physische Reads als verlaesslich gelten koennen.
Warum das wichtig ist
v0.94 ist der Punkt, an dem die native Build-Engine nicht mehr nur wie
eine lange interne Migration aussieht, sondern selbst wie die eigentliche
Release-Ueberschrift. Sie gibt Amiga Imager ein deutlich staerkeres
Fundament fuer alles, was als Naechstes kommt, inklusive breiterer
Floppy-Hardware-Unterstuetzung und weiterer nativer Medien-Workflows auf
macOS.