Mounting a disk image with later version of FFS

[mark_k]

I'm trying to mount a ~1.3GB disk image file in WinUAE. The file contains a single FFS partition (LowCyl=0, Reserved=2).

With "Do not mount" checked I can mount it manually using a mount file on the Amiga side. Doing it that way allows me to specify the latest FFS version as opposed to the ROM FFS 40.1, so "Version IMG:" reports: filesystem 45.13

After I manually fix the bogus auto-generated geometry (surfaces/sectors/block size), WinUAE can mount the partition automatically at boot. With the FileSys field blank it gets mounted with the ROM FFS as you'd expect. I copied FFS 45.13 to a folder on the PC and selected it in the FileSys field. However the partition still gets mounted with the ROM FFS, not FFS 45.13. Is there any way to fix that?

Also, I noticed (according to the Scout monitor program) that the IMG: stack size is only 600 bytes. If that's correct, would it be a good idea to increase that a bit? And maybe allow the user to specify the size? Non-FFS filesystems might require a larger stack.

[Toni Wilen]

Originally Posted by mark_k

After I manually fix the bogus auto-generated geometry (surfaces/sectors/block size), WinUAE can mount the partition automatically at boot. With the FileSys field blank it gets mounted with the ROM FFS as you'd expect. I copied FFS 45.13 to a folder on the PC and selected it in the FileSys field. However the partition still gets mounted with the ROM FFS, not FFS 45.13. Is there any way to fix that?

Filesystem version won't be user configurable setting (see below) but maybe it is possible to look for "VER:" field and parse the version number and replace ROM filesystem if it is older.

I don't want to replace blindly because filesystem backwards compatibility isn't always guaranteed.

Also, I noticed (according to the Scout monitor program) that the IMG: stack size is only 600 bytes. If that's correct, would it be a good idea to increase that a bit? And maybe allow the user to specify the size? Non-FFS filesystems might require a larger stack.

Yes (default stack can be larger), no (It won't be user setting). This is a hack and it isn't meant to be fully configurable.

[Toni Wilen]

Done.

[mark_k]

Thanks. I can get WinUAE to mount the image file with FFS 45.14 and the default stack size is 8000. (Do you check the filesystem version or just always use the user-specified one? I think the latter is preferable actually; I can think of at least one case where it would be necessary to use an older FFS version than the one in ROM.)

8000 might be a little large for the default stack, especially if the user has several image files mounted on a low-memory configuration. [Later versions of FastFileSystem switch the stack. They do that unconditionally and not always in a bug-free way... ]

[Toni Wilen]

Originally Posted by mark_k

Thanks. I can get WinUAE to mount the image file with FFS 45.14 and the default stack size is 8000. (Do you check the filesystem version or just always use the user-specified one? I think the latter is preferable actually; I can think of at least one case where it would be necessary to use an older FFS version than the one in ROM.)

I still think it is bad idea because filesystem will get added to FileSystem.resource which means any later mounted HD will also gets same filesystem (if dostype matches) which can be quite surprising in some situations..

(It needs to be added to FileSystem.resource because shared mount code requires it)

[mark_k]

Does that also apply when the user manually specifies a filesystem in the mount file?


Another issue I noticed... I have a config which has an image file set to auto-mount. Read/write and Bootable are unchecked and I manually set Surfaces/Sectors/Block size so as to cover the entire disk. That works fine.

Choosing another disk image should just require double-clicking the entry in the Hard drives settings to open the Hardfile settings window, selecting another image file and rebooting. But when I do that (wanting to keep all other settings unchanged), WinUAE reverts the Read/write and Bootable settings, and the fake geometry values to the defaults.

There's also a minor display issue with the geometry status line in the hardfile settings window. This just seems to be cosmetic. My image file is 1303563264 bytes; the original disk had 1273011 1024-byte blocks. WinUAE initially shows the fake geometry
10103/4/63, 2545956/2546022 blocks, 1243.1MB/1243.2MB

I changed Surfaces to 1, Sectors to 51, Block size to 1024. The geometry info line then showed
24961/1/51, 1273011/2546022 blocks, 1243.2MB/1243.2MB

The 2546022 should read 1273011 in that case, I think?

Edit: I also noticed lines like this in the WinUAE log, even when Do not mount was checked:
RDB: fakefilesys, trying to load 'Z:\Shared\FastFileSystem_45.14', dostype 0x444F5301 (DOS\1)
HDF: 444F5301 (DOS\1) in FileSystem.resource version 40.1
HDF: faked RDB filesystem 444F5301 (DOS\1 45.14) loaded

[Toni Wilen]

Originally Posted by mark_k

Does that also apply when the user manually specifies a filesystem in the mount file?

I don't think so but it has nothing to do with this anyway.

Choosing another disk image should just require double-clicking the entry in the Hard drives settings to open the Hardfile settings window, selecting another image file and rebooting. But when I do that (wanting to keep all other settings unchanged), WinUAE reverts the Read/write and Bootable settings, and the fake geometry values to the defaults.

It is by design. Default geometry is what 99.9% users want. (Replacing HD is not same as replacing disk, it is more like replacing whole disk drive with different model and capacity)

Edit: I also noticed lines like this in the WinUAE log, even when Do not mount was checked:
RDB: fakefilesys, trying to load 'Z:\Shared\FastFileSystem_45.14', dostype 0x444F5301 (DOS\1)
HDF: 444F5301 (DOS\1) in FileSystem.resource version 40.1
HDF: faked RDB filesystem 444F5301 (DOS\1 45.14) loaded

It was loaded to host PC memory but Amiga never saw it.

(I repeat: this is just another hack that shouldn't be normally used, do not expect too much)

[mark_k]

Originally Posted by Toni Wilen

It is by design. Default geometry is what 99.9% users want. (Replacing HD is not same as replacing disk, it is more like replacing whole disk drive with different model and capacity)

What about, if the new disk image file is the same length as the old one, don't change the geometry settings. (And don't change the read/write and bootable settings in any case.)

[Toni Wilen]

I changed filesystem.resource behavior a bit, now filesystem in hardfile panel is only added to resource if it does not already have matching dostype. (I removed filesystem must be in filesystem.resource requirement)

Originally Posted by mark_k

What about, if the new disk image file is the same length as the old one, don't change the geometry settings. (And don't change the read/write and bootable settings in any case.)

I don't like this solution either, reselecting same hdf should mean same as starting from scratch, geometry should reset.

read/write, bootable, do not mount are now saved.

[mark_k]

The auto-mounting feature only works for hardfiles which don't have RDB, is that right?

While the default fake geometry should be fine for hardfiles which the user originally created and formatted in WinUAE, for images of other non-RDB media it will usually be wrong. For example, the user could have image files of their old Zip, Jaz, MO, SyQuest etc. disks which each contain a single partition covering the entire disk. Or maybe they created image files of individual partitions from their old hard disk.

In the absence of generic removable drive support in WinUAE, being able to easily change image files would be quite useful. Having to manually fix the geometry values each time to change file is a bit of a pain. Some possible solutions:

• Implement generic removable drive support. (Allow on-the-fly changing of image file, which the filesystem would detect as a disk change.)
• Maintain a list of image file sizes and corresponding fake geometries. If the user selects an image file of the same size as they have used before, WinUAE would fill out the fake geometry fields with the last-used values for that image file size.
• Add a "set geometry to cover entire disk" button which would change the fake geometry like that.
• I guess some kind of FFS-specific hack would be possible, where you check for an FFS root block in the expected place according to the geometry, warn the user if it's not there.

[Toni Wilen]

The auto-mounting feature only works for hardfiles which don't have RDB, is that right?

What auto-mounting?

For example, the user could have image files of their old Zip, Jaz, MO, SyQuest etc. disks which each contain a single partition covering the entire disk. Or maybe they created image files of individual partitions from their old hard disk.

Why is this a problem? You need to use mountlists or utilities to mount those on real Amigas too.

How is automounting supposed to help? Geometry does not magically appear from thin air when removable drive is inserted, it needs to be specified somewhere.

geometry stuff

I think there should be hdf geometry extension or separate geometry file that describes the geometry. Any other method is not good enough for me.

Technically you could append <512 byte data (of gemeotry stuff and other) at the end of hardfile without breaking compatibility with older version.

First block (after dostype identifier) or second block (which is normally also unused) could also work. If course formatting would erase it..

Or perhaps just file called hardfile_name.geom or something like that would work. Probably safest and most compatible solution. It could be simple text file.

--

Removable drive support is really difficult to do safely because AOS does not have any real support for removable stuff. Floppy drives or removable zip archives (and similar) are easy.

Filesystem handlers are the problem.

Killing "old" filesystem handler and starting new ones is tricky because not all filesystems support ACTION_DIE (and some even support it badly..) If filesystem does not support ACTION_DIE, it must be kept in inhibited state and then uninhibited when new drive is mounted (if same dostype) and we can only hope that the filesystem does TD_GETGEOMETRY call when it gets uninhibit packet..

Another "solution" is to leave it in inhibited state forever but it will waste resources..

[mark_k]

Originally Posted by Toni Wilen

What auto-mounting?

Where the partition/hardfile is mounted automatically at boot by WinUAE, without the user needing to use a mount file on the Amiga side.

Originally Posted by Toni Wilen

Why is this a problem? You need to use mountlists or utilities to mount those on real Amigas too.

How is automounting supposed to help? Geometry does not magically appear from thin air when removable drive is inserted, it needs to be specified somewhere.

Well sure. If WinUAE had some kind of removable drive support, after running a suitable mount file on the Amiga side the user would "insert" an image file into the removable drive. The Amiga FFS would recognise that. Later the user could "eject" the disk and insert another image.

WinUAE doesn't allow changing the image file on-the-fly as far as I can tell. E.g. change image file then run DiskChange command, nothing happens. So you have to reboot the emulated Amiga in order to access the new image. The idea of having WinUAE automatically use the correct geometry would allow different types of disk image to be mounted automatically at boot, without the user needing to manually adjust geometry values (after the first time). It could be more convenient than the user having multiple mount files and running the one corresponding to the image file they are using.

Originally Posted by Toni Wilen

I think there should be hdf geometry extension or separate geometry file that describes the geometry. Any other method is not good enough for me.

Technically you could append <512 byte data (of gemeotry stuff and other) at the end of hardfile without breaking compatibility with older version.

First block (after dostype identifier) or second block (which is normally also unused) could also work. If course formatting would erase it..

Or perhaps just file called hardfile_name.geom or something like that would work. Probably safest and most compatible solution. It could be simple text file.

Yes a separate text file would be best I think. Like I mentioned, you could automatically populate it with a default geometry each time the user uses a different-sized image file and manually sets the geometry. So when the user first mounts a 100MB Zip disk image, record that file size and the user's selected geometry in the config file. Later when the user selects another 100MB Zip image, the size is known so default the geometry values to what the user entered for the previous 100MB Zip image.

Originally Posted by Toni Wilen

Removable drive support is really difficult to do safely because AOS does not have any real support for removable stuff. Floppy drives or removable zip archives (and similar) are easy.

Filesystem handlers are the problem.

Killing "old" filesystem handler and starting new ones is tricky because not all filesystems support ACTION_DIE (and some even support it badly..) If filesystem does not support ACTION_DIE, it must be kept in inhibited state and then uninhibited when new drive is mounted (if same dostype) and we can only hope that the filesystem does TD_GETGEOMETRY call when it gets uninhibit packet..

With my Amiga 2000 I had a GVP SCSI controller and could use removable media with no problems with FFS 40.1 then later 43.x & 45.x. (Well, one capacity of removable media. Swapping different-capacity disks wouldn't work without using a second mount file.) gvpscsi.device doesn't support TD_GETGEOMETRY, but I could eject and change disks and things seemed to work fine. The old disk icon disappeared from Workbench before the new one appeared. Maybe gvpscsi.device did some kind of hack/magic to make that work? I think the manual mentioned it even working with Workbench 1.3.

FastFileSystem only calls TD_GETGEOMETRY for new-style devices (only recent FFS versions) or for devices whose names begin with trackdisk.device or carddisk.device. A hack to get pre-NSD FFS versions to use TD_GETGEOMETRY would be to make the Exec device name something like carddisk.device_really_myscsi.device.

I seem to remember that SFS supports TD_GETGEOMETRY, using it when LowCyl=0 in the mount file to allow one mount file to support multiple disk capacities. If I recall correctly though, the support was broken so I couldn't use it properly. [Basically, if the device driver — gvpscsi.device in my case — doesn't support TD_GETGEOMETRY, then SFS refuses to work when you specify LowCyl = 0 in a mount file. Meaning interchange of disks from a system which does support TD_GETGEOMETRY to one which doesn't isn't possible unless you patch SFS.]

[Toni Wilen]

Geometry file support is now done (filesystem geometry stuff needed rewrite, old messy parameters replaced with single structure, may have broken some things..)

File is <name of hardfile>.geo. It has dosdriver file structure, key = value pairs. Most dosdriver/mountlist parameters are supported, including those that are not available via config file or GUI (lowcyl, mask, buffers, etc..)

Loading config file: hardfile path is parsed, geometry structure is filled with defaults, then geometry file is checked and values changed in geometry structure, finally config file entries are loaded, overwriting any default/geometry values. (Config file has priority over geometry file)

Selecting new hardfile using GUI: geometry file has priority over default geometry.

Geometry is not saved automatically, not sure if only causes confusion..

(Removable stuff: much later..)

[Toni Wilen]

On the fly HDF replacement should now work when using GUI. Will also send "disk change" notification if enabled by the filesystem (CMD_REMOVE or CMD_ADDCHANGEINT/REMCHANGEINT)

Config file (uae-configuration etc..) will be supported later.

Harddrive parameter handling update really made this much cleaner and easier.

[mark_k]

That sounds good, I'll test it out later. Could you also support TD_EJECT, so the disk could be "ejected" from the Amiga side?

That new hardfile support could be useful for working with ADF files too; the user could configure several drives and select ADF files for them. Much faster than floppy drive emulation and (probably) less hassle than using an Amiga-side program to mount disk images, where you'd need the ADF files to be accessible from the Amiga side.

[Toni Wilen]

TD_EJECT done (Not tested), only allowed if partition hardfile.

Note that only removal/replacement is supported on the fly, adding HDF on the fly won't work.

[mark_k]

Testing today's winuae.zip, it looks like the Bootable setting for a hardfile isn't saved/restored when you save a config. It always appears to be enabled after loading a config, even if you disabled it before saving the config.

I get a Software Failure requester, error #80000006 on booting (from a different, RDB-type, hardfile) when the hardfile is set to auto-mount. On clicking Reboot I get an alert: error 80000002, task 0021E570. Then the machine reboots with another software failure requester, this time with error 80000002.

I wasn't using a custom .geo file. Geometry entered in the hardfile settings window was 51 surfaces, 109 sectors, block size 1024. If I check the Do not mount option, the system boots and I can use a mount file on the Amiga side to access the hardfile.

I can upload a formatted-but-empty image file of the same size if you have trouble reproducing the issue.

[mark_k]

Could you allow hardfiles to be added without the user specifying a filename? That would allow the user to have several "empty" drives which they can insert disk images into during the course of a session.

[Toni Wilen]

Mostly useless information without logs. (and also explaining what does work if anything and there has been multiple updates, make sure it is latest)

[mark_k]

Hopefully this will help???

I can access the hardfile with no problems if it's not set to auto-mount, and I use a mount file on the Amiga side instead. PS: I get the same crash with JIT disabled.