Feature Request: Mount LHAs & ZIPs as HD Files

[HoraceAndTheSpider]

I notice you have support for HDFs already. Persumably you are still sharing the HDF reading code from WinUAE upstream.

Please could you enable the mounting of ZIPs and LHA archives as read-only images. The code for handling these in UAE already allows for this. I appreciate this may require adding the archivers modules.

This would allow some games to be played by mounting a 'boot drive' as a folder, and also attaching 'game data' (e.g. a pre-installed WHDLoad game) in distributed format.

Thanks :)

[rsn8887]

Just use .hdf. WinUAE might have zip/lha extraction built-in but UAE4All2 doesn't. On systems with a shell like Pandora, GP2X, Raspberry Pi, Android, Windows, etc., a workaround was used where a shell command was invoked to extract lha and zip files into a temp folder. This worked because those platforms run some kind of kernel with a shell and external programs available. On those platforms, UAE4All2 started an external lha executable from within c using the system call, for example:

sprintf (cmd, "lha pq %s >%s", src, dst);
    return !system (cmd);

This would summon the external (separately installed) lha executable to extract archives into a temp folder. In the case of Pandora and GP2X, it is a mystery to me why you would want to run bloated Linux or Unix kernels with all the unneeded overhead and all these shell commands pre-installed on such underpowered portable devices to begin with, but that is a different question.

Of course, a codepath like the one above cannot simply be "enabled" on Vita/Switch like you suggest. This approach doesn't work on Vita/Switch at all, because there is no shell and no system call. It was painful enough to get .adz support to work because of these differences between Pandora, GP2X, Android, etc. and Vita/Switch.

Also, keep in mind that many Amiga filenames and file attributes are not compatible with the FAT32 filesystem used on Vita/Switch SD cards. So extracting Amiga archives onto the host filesystem is kind of asking for trouble anyways. Same with HD Dir of course. It is not very compatible compared to .hdf.

[HoraceAndTheSpider]

To be clear I am in no way suggesting using an external extractor for this via a system call.

WinUAE (and as a result Amiberry downstream) have this code already included and handle the data direct in memory, so my thought was that was that you would re-use the upstream winuae code.

I understood uae4arm and uae4all shared code base with winuae, or is this only the case with the former?

The compatibility on file system attributions is another reason I believe this would be a useful feature and why I would prefer not to be extracting these files manually.

HDF use may be a future option, but is time consuming to convert files and is a bit dependent of the ease of sharing a boot disk - as per my other request- comes into play (batch converting LHAs won’t carry the boot files)

I appreciate based on the above this may not be possible at this stage though, which is a shame, but I can understand if the code simply isn’t available downstream.

Thanks for the explanation

[rsn8887]

UAE4All2 is based on a very old WinUAE version (0.8.6 or so) with some later WinUAE code backported into it here and there. Amiberry is based on UAE4Arm which itself is based on a much more recent WinUAE version (not sure which). You can see that by comparing source files such as custom.cpp etc.

[HoraceAndTheSpider]

Makes sense. Thanks for the clarification.

I think midwan is putting some of winuae 3.x into Amiberry as we speak, but that does likely come with a speed hit, so I always see places where uae4all2 is going to be preferable.

Happy to close this on this basis, and will look into batch LHA->HDF conversion for a solution with a few tweaks.