Using Hard Drives

When it comes to using emulated hard drives in FS-UAE, you have several choices:

  • You can mount directories on your system as Amiga volumes (“directory hard drives”).
  • You can use hard drive images (HDF files).
  • You can mount zip files as Amiga volumes.
  • You can in some cases use a real Amiga hard drive / compact flash card.

The best choice depends on how you want to use it. The most convenient is directory hard drives, and I recommend to use this unless you have a good reason not to, especially with FS-UAE v2.1.28+, when support for file permission and metadata was added.

Using Directory Hard Drives

The advantages of using directory hard drives compared with other approaches are:

  • It will work with all Amiga models, with no Amiga-side setup needed. The volumes (directories) will automatically be accessible from the Amiga.
  • You’ll have “unlimited” Amiga storage capacity (as long as you have enough free space on your system), and you don’t have to allocate space upfront as you must do with HDFs.
  • You can also access the files directly from the host system, and you can easily add new files to your Amiga drive from the host system.

Note: you should be somewhat careful about modifying the directory hard drive from the Amiga and from the host system at the same time. Ideally, you should only modify the hard drive from the host system when FS-UAE is not running, since some information about the file system may be cached in the Amiga.

Amiga and Host File Names

Some file names which are valid on the Amiga are not allowed on the host file system. This is particularly true on Windows, which has one of the most restrictive set of allowed file names (Linux and OS X are more flexible).

FS-UAE handles this by “escaping” the invalid Amiga file names so the can be stored on the local file system. This is only done when necessary, so most file names will not be escaped. Also, the escaping is done so the host file name is valid on all supported FS-UAE platforms. For example, the following file name is valid on the amiga:

Foo\Bar

This is not valid on Windows however, so the file name is escaped and stored as Foo%5cBar. The Amiga will see a file called Foo\Bar when it accesses a directory with a host file called Foo%5cBar. Since Foo\Bar is not allowed on Windows, the file is stored as Foo%5cBar on *all* platforms. This makes the directory hard drives portable across multiple operating systems.

See also “Extracting Amiga Archives” for more relevant information.

Amiga File Permissions

The information in this section applies to FS-UAE v2.1.28+. Earlier versions do not store file permissions.

When FS-UAE looks up existing files in a directory hard drives, it initializes metadata about the file either from the host file system, or if it exists, from an accompanying metadata file.

When a file has an accompanying metadata file, date/time, file permissions and comment are read from the metadata file. If a metadata file does not exist, then:

  • The file will get the default permissions: ----rwed.
  • The file date/time will be read from the last modified timestamp of the host file.
  • The file will have no file comment.

When files are created/modified from within the Amiga, the host file mtime (last modified time) is updated based on the Amiga file date/time. FS-UAE then decides if it needs to store more information about the file in a metadata file:

  • If the file has a file comment, FS-UAE will create a metadata file.
  • If the file has non-default file permissions, FS-UAE will create a metadata file.
  • FS-UAE reads back the last modified time from the host file, and checks that the time was stored with high enough precision (Amiga files are stored with 1/50s precision). If the time could not be stored accurately, FS-UAE will create a metadata file.
  • If the file already has a metadata file, FS-UAE will always update the metadata file.

Additional metadata is stored in files with .uaem extension. If the original file is called Image.jpg, the additional metadata is stored in Image.jpg.uaem in the same directory. The metadata is stored in a text format, and you can even edit this file manually from the host side to alter the information about the file. Here’s an example of the content of a metadata file (where “hello” is a file comment):

----rwed 2013-02-12 21:20:52.02 hello

Note: file permissions / comments are not stored with FS-UAE < v2.1.28.

Extracting Amiga Archives

If you have an .lha archive with Amiga software, you’ll have two choices when you want to extract it:

  • Extract the .lha archive to the directory hard drive from the host system.
  • Copy the .lha archive to the directory hard drive, start FS-UAE and extract the archive with the “lha” program (or similar) inside the Amiga.

In many cases, both approaches will work well, but there are some cases where you should extract the archive from inside the emulated Amiga:

  • If the archive contains Amiga file names which are illegal on the host file system, you’ll not be able to extract the archive correctly on the host system.
  • The archive can contain file metadata (date/time, file permissions, comment), and if you extract the archive on the host system, information will be lost (the files will get the default file permissions ----rwed).

So whether you can extract an archive without (significant) loss of information on the host system depends on the archive. To be sure, you can always extract archives from inside the Amiga.

Using Hard Drive Images (HDF Files)

HDF files are “raw files” containing the content of hard drives, used directly by the Amiga as storage devices (like it would use a real hard drive). This means that the Amiga manages the file system.

There are two common variants of HDF files:

  • A full HDF image of a hard drive, often referred to as HDF files in RDB (Rigid Disk Block) format. This HDF file must be partitioned, like a real hard drive, before that Amiga can use it.
  • A HDF file which only contains a single partition. Behind the scenes, FS-UAE will fake a full HDF image with the content of the HDF file as the single partition in the drive.

Using HDF Files in RDB Format

When you mount a .hdf file as a hard drive in FS-UAE, FS-UAE will automatically recognize it as an RDB file when the HD is already partitioned (the file begins with the “RDSK” header). If the file is completely empty, FS-UAE will think that it is a partition HDF instead, but you can use the hard_drive_x_type options to force FS-UAE to handle it as an RDB file.

Note: When you use the ADF/HDF creator in FS-UAE Launcher to create a HDF file in RDB format (v2.1.26+), the file is created in a way that allows FS-UAE to autodetect it as an RDB file.

Empty hard drive images must be partitioned and formatted before use. Workbench may come with a tool called “HDToolBox” which you can use to partition the image. By default, the hard drive is accessed through a HD controller called uaehf.device. You need to tell HDToolBox to use this device when you start it, for example by running the command:

DF0:Tools/HDToolBox uaehf.device

Alternatively, if you emulate an Amiga 600 or Amiga 1200, you can attach the drives to an emulated IDE controller instead (see hard_drive_x_controller). When you use this controller, you can only use hard drive images which are less than 4 GB. The uaehf.device does not have this limitation, so using the default uaehf.device is recommended unless you have a very good reason not to use it. Additionally, uaehf.device is likely more efficient (faster) to use.

After you have partitioned the file, you may need to restart the Amiga. Then you can proceed to format the partition(s).

Using Partition HDF Files

When you use an empty partition HDF file, you’ll not partition it – but you still need to format it inside the Amiga before you can use it.

FS-UAE needs to know the geometry of the HDF file. Currently, FS-UAE assumes – and only supports – the default geometry (sectors = 32, surfaces = 1, reserved = 2, block_size = 512). There is no option to override this yet. This is compatible with most HDF partition files < 512 MB.

Mounting ZIP Files as Hard Drives

FS-UAE supports mounting ZIP files as hard drive. This works more or less like a read-only directory hard drive (though there is currently no support for metadata files in this case).

When you mount ZIP files and start FS-UAE via FS-UAE Launcher, the ZIP file is handled differently:
– The ZIP file is extracted to a temporary directory
– This temporary directory is mounted as a directory hard drive in FS-UAE
– When FS-UAE is done running, the Launcher scans the temporary directory for changes and saves the changes to the state folder, and when you run the same configuration later, the changed files are merged with the content from the zip file.

Via FS-UAE Launcher, ZIP files work more like a hard drive *template*, and you get support for metadata files and get a writable file system. The ZIP file itself will remain untouched.

Using Real Hard Drives

Note: This is not an officially supported feature, but it is described here because it still works on some platforms. This does not work on MS Windows.

On Unix-like systems, devices can be accessed like files. This means that you can mount a block device (for example a real hard drive or a compact flash (CF) card) as a hard drive, and FS-UAE will use it like it was a HDF file.

You need to make sure FS-UAE have read and write access to the device (you may need to chmod it and/or change device ownership), and also that you use the correct device -you don’t want to overwrite another device by accident.

People have been using this feature on Linux and OS X, but no guarantee is given that it works. The most common use is to mount a CF card which is also used as a hard drive on a real Amiga.

69 thoughts on “Using Hard Drives

  1. Hi, I’m running FS-UAE on a MacBook. It’s all working well. I’m using a directory hard drive and I can create a file on the Amiga which I can then access on the MacBook via the shared directory.

    However, when I copied an ADF file to the directory from the MacBook it was not visible in the Amiga environment.

    As I test I made a text file on the Amiga, copied it to the HD and then removed it on the MacBook (the 1 text file was actually 4 files when viewed on the MacBook) and then put it back again and it WAS visible on the Amiga.

    Is the problem that the Amiga will only see native Amiga files?

    • Hi, it does not matter where the files are created, as such. But Workbench (by default) only shows “icons” (.info files). Some Amiga programs will create both a document and a corresponding .info file when saving.

      There is a menu option in Workbench to “Show all files” instead of “Show icons” (or something like that). Enable that to see text files without a corresponding .info icon file.

  2. I’ve successfully installed Amiga Classic FE in FS-UAE 2.8.3, and hard drive image is RDB file.. and since I know directory hard drives will not work, only image file, how can I share between host and Amiga emulation as it’ just image ? I trying to share Eithnet.lha file from Aminet i’ve downloaded for Network access. Just enableling Network in GUI alone does not help as in FE i still need to point to .device, but the problem is its on the host downloaded,, I just need to share it.. How can this be done with am image?

    I tries adding hard drive directory as “secondary hard drive, but OS didn’t boot.. Remove it, and it boots to the OS.

    Must i use .zip ? What other options do I have?

    • Hi, a good option (until you get networking setup) is to use a second shared HDF/RDB with OFS/FFS. You can then boot a (classic) Workbench config with this HDF mounted – and a directory hard drive, move files from directory to HDF, and then boot AmigaOS 4.1 with this “shared HDF” as a second drive.

  3. I’m running a game (War in Middle Earth) through WHDLoad with a zipped image and I’m finding that my save games (not states, but the in-game option to save progress) doesn’t survive when I close FS-UAE and run it again. I can load a previously-created save as long as I don’t shut down FS-UAE, but as soon as I close the program, any modified elements of the hard drive seem to be lost. The documentation indicates that these save games should be in the state folder, but I’m having trouble finding that location. I’m sure I’m just making a simple mistake, but so far I haven’t been able to find the solution.

    • Hi, some WHDLoad slaves caches changed files until the WHDLoad slave quits. So what happens here is that the savegames are not really saved to disk at all, but exists only in memory. You need to shut down the slave with the correct quit key instead of closing FS-UAE (FS-UAE will close automatically once the slave quits). The WHDLoad splash screen often (always?) informs you what the quit key is.

  4. Can anyone please help me as to how i can have 2x separate “HDF”‘s so i can have 2x hard drives on my emulated A1200 Please ?
    I’ve setup my A1200 with 1x “HDF” so far.This i’ve labeled as “System” as it has all the workbench 3.0 discs installed,so the emulator boots into workbench no problem.
    Can i create a second “HDF” file so i can install games onto it,using WHDLoad ?
    I have tried and tried but when i boot up in my emulated A1200,it’s only showing the “HDF/System” on the screen,even though i’ve loaded the second “HDF/Games” into the second box down in the config.
    Any help would be awesome please guys

    • Hi! Yes, you can attach multiple .hdf files. There can be several reasons why the Games HDF does not show up. Did you create it as an RDB-type HDF? If so, you need to partition it within Workbench before you will see any drives there.

    • Btw, The by far easiest solution is to use directory hard drives. Just create an empty “Games” directory somewhere, and attach it using the folder button for the secondary hard drive.

  5. Hello,

    In the directions for HDL and RDB files, you mentioned that a hard disk file can be created using fs-uae launcher. I’ve looked all over and I’m embarrassed to say that I couldn’t find it. I am using the Windows version 2.6.2. Could you please direct me to where I can create a hard disk file?

    Thanks,

    Chuck Rose

      • Hmm now workbench 3.1 is refusing to recognize my new hard drive file and refuses to partition what it can’t see in HD toolbox. I’m emulating an A1200, any ideas? I’ve tried every way I can think of: from workbench HDtoolbox, from three different placed on the workbench install disk (including another HDtoolbox that was there. Any help would be wonderful.

        More info: The disk I created is mounted as the first drive in the HD section of the launcher, it is 512 MB size, and I specified HD 0 instead of the default 6 because as the website indicates the A1200 hard drive is an IDE and should be 0. When I try to partition the drive, the partitioning program responds “this drive can’t be partitioned and then all other options are grayed out…

        Thanks Frode.

  6. Hi,

    Directory Hard Drives are not working anymore with the latest stable release on OS X 10.11. Is this a known problem?

    Regards

      • There it goes…

        fs_uae_configure_hard_drives
        resolve_path System (relative)
        checking ./System
        - found ./System
        hard drive mount: ./System
        device: DH0
        mount name: System
        read only: 0
        boot priority: 0
        set option "filesystem2" to "rw,DH0:System:./System,0" (result: 1)
        set option "uaehf0" to "dir,rw,DH0:System:./System,0" (result: 1)
        resolve_path Work (relative)
        checking ./Work
        checking /var/folders/5x/q70zp_rs4bn7_h0945z2gb2m0000gn/T/Work
        checking /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work
        - found /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work
        hard drive mount: /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work

        (EDIT:log stripped by Frode)

          • Thanks a lot! Renaming Amiga’s partitions/directory hard drives to something else also did the trick. 🙂

  7. I have a different timestamp problem that is still present in 2.6.1. I’m running Linux (Ubuntu 14.04LTS) and all my Amiga partitions are directories in the host system. When creating a new file the file timestamp is correct. But when a file is written without being deleted first the timestamp is never updated as the Amiga sees it.

    When looking at it from the Linux side it looks like:
    Time stamp of actual file: old time
    Time stamp of .uaem file: new (correct) time
    Time stamp written inside .uaem file: old time

  8. I see in the docu here not how can add a amiga drive dh3: that use files from E: \ i use fs-uae win 64 version. on winuae gui i have a stringdad device (here i add dh3:) , on label i can add amiga name. and on path i can add E: \ . but in fs-launcher all this entries miss

    • Hi, you can add custom labels for the directory hard drives. There just isn’t any GUI for it yet. What you can do, is to add E: to the *fourth* hard drive entry (that will be dh3: automatically). As for the label, it will be chosen automatically based on the directory name. But to override this, you can go into “Custom configuration”, and enter:
      hard_drive_label_3 = Files (or whatever you want).

      -And there will be GUI controls added to tweak this later 🙂

  9. It behaves the same way on 2.5.30dev. If this bug wasn’t reported before, it’s no surprise that it wasn’t fixed. 🙂

    To reproduce:

    1) Create a file in an actual Amiga filesystem (e.g., adf or hdf file).

    2) Observe the correct timestamp.

    3) Copy the file to a “folder-based” file, with the CLONE option.

    4) Observe the incorrect timestamp in the result, in both the Amiga view and the host view. In European timezones, this should result in a timestamp in the future.

    The new mouse handling seems to be better in some ways and worse in others (better overall), though that probably doesn’t belong in this thread.

  10. There seems to be a bug in setting timestamps on “Directory Hard Drive” files. Simple writing of such files sets correct timestamps, but copying them from Amiga files with “Copy CLONE” sets the timestamps incorrectly. In my case, they were set 7 hours early, which corresponds (not coincidentally, I’ll bet) to the difference between PDT and UTC. My guess is that the SetFileDate implementation is treating the supplied Amiga timestamp as UTC rather than local time.

Leave a Reply

Your email address will not be published. Required fields are marked *