Feature release
Amiga Imager 0.99.9 speaks FS-UAE natively: every UAE/Amiberry build now writes an .fs-uae config alongside the .uae, and the emulated CPU is selectable – 68020 to 68060 – in both dialects. ADF folders that hold more than one OS release are handled more precisely.
Feature release - macOS 14+, Apple Silicon and Intel. Build: 260810.
The companion config written next to a UAE/Amiberry HDF described itself as being for “FS-UAE / WinUAE / vAmiga” – but used WinUAE option names throughout, and FS-UAE reads none of them. An FS-UAE user got a config that loaded and silently did the wrong thing: no RTG board, no networking, and only the 8 MB of Zorro II Fast RAM, which is exactly the “programs fail for no obvious reason” situation the handbook’s troubleshooting chapter has been patching around.
Both files are now written next to the image, describing the same machine in each
emulator’s own dialect: .uae for WinUAE and Amiberry,
.fs-uae for FS-UAE – RTG board, bsdsocket networking and the full
256 MB of Zorro III Fast RAM included. Launch FS-UAE with the
.fs-uae file and everything is simply there. As before, set your Kickstart
ROM path in whichever file you use.
UAE and Amiberry builds gain a CPU picker: 68020 (the default), 68030,
68040 or 68060. The choice is written into both configs with the matching FPU, and on a
68040 or 68060 the image relies on the CPU libraries from MMULibs.adf
– keep that disk in your ADF folder; the build checks and warns if the libraries
are missing. Only the library matching the chosen CPU goes onto the image: the OS 3.2
CPU libraries refuse to run on the wrong processor, so a 68060 image carrying
68040.library throws an alert the moment something scans the libraries. Installing
ScummVM raises the CPU to a 68060 automatically, as its bundled build requires one. On
a 68040/68060 the configs also ask the emulator to implement the full instruction set
directly, so datatypes and FPU software work even before the CPU library is active.
Many of us keep every ADF we own in one folder – 3.1 next to 3.2 next to the 3.2.3 update disks. Handling of such folders got a thorough tightening: Auto now installs the newest release present in the folder, an explicit version pick in the GUI is honoured exactly, and the build log names the release that actually went onto the disk.
The install order is now strictly oldest-to-newest across the whole disk set, so files
from an update disk can no longer be shadowed by their base-disk versions during the
merge. Previously, some updated system files in a mixed base-plus-update folder could
end up at their base-release versions – nothing visibly broke, but a
Version check could show e.g. an older workbench.library than
the update ships. If you keep base and update disks together, a rebuild with 0.99.9
puts the current versions on disk.
SYS:Programs is packed onto the icon grid instead of leaving placement
to Workbench, and the amiagent drawer got proper system icons.