Feature Request: LHA/ZIP support for WHDLoad

[HoraceAndTheSpider]

This can currently be done through launch scripting, but native support for pre-installed WHDLoad games, in similar fashion to FS-UAE, as discussed.

This will take advantage of exisitng code within amiberry for LHA unpacking.

A file is parsed into the command line. e.g. amiberry DDay_v1.1_Impressions_0455.lha

• Clear any old content for /dev/shm/whdload_temp/
• Check file exists
• Check space limits
• Unpack contents to /dev/shm/whdload_temp/ - this will contain a sub-folder for the game e.g. /IK+/ (create whdload_temp folder if not existing)
• Check contents for WHDLoad .slave file (abort if not , remove folder and -> possibly revert to future ADF/ZIP feature)
• Set the A1200 Expanded Quickstart option
• Mount /dev/shm/whdload_temp/ as DH1 [READ ONLY]
• Mount /Amiberry/WHDLoad_Booter/ as DH0
• Parse the name and LHA file CRC into function whdload_autoprefs
• Use whdload_autoprefs to set additional bespoke game options (Text Data at first, Database file or similar for future)
• Launch Emulation
• On Quit or Config Load, delete content for `/dev/shm/whdload_temp/

I can borrow work already developed in the UAE Config Maker for this. I have already begun work on improvements to the WHDLoad Booter for this purpose, and will gladly take-on the whdload_autoprefs routine.

Advantages:

• Additional support for pre-existing WHDLoad data. Would be a useful tool for the future RetroArch branch (a single file solution)
• Removes requirements to do this with external scripting

To note: /dev/shm/ is a RAMDISK like solution for Linux. This is preferable for the game data to avoid unnecessary writes to the MicroSD Card when routinely unpacking game data and removing.

WHDLoad save files will be redirected to /Amiberry/WHDLoad_Booter/Savegames

Save-State support should be acceptable due to limited (although still partial) access to the writable booter drive once a game is loaded.

Symlinks for kick33180.A500 (Kickstart 1.2) kick34005.A500 (Kickstart 1.3) kick40068.A1200 (Kickstart 3.1 / A1200) should be created from the currently scanned ROMS location.

[ghost]

Like the sound of this. @midwan Could you also add the ability to mount archive's as Hardrive's like WinUAE does ? That way you can load a Workbench or ClassicWorkbench etc. and mount an LHA file in DH1: This way you can read the Manual, Tips and Readme's in the files for all WHDLoad files, Games, Demos and Magazines. And appreciate the nice icons !

[HoraceAndTheSpider]

I would think that effectively that would just mean triggering the following steps when a ZIP/LHA is attached as a hard-drive:

• Unpack contents to /dev/shm/whdload_temp/ - this will contain a sub-folder for the game e.g. /IK+/ (create whdload_temp folder if not existing)
• Mount /dev/shm/whdload_temp/ as DH1

Which we should be able to do.

If worked on further, I may look to add reading of Manual, Tips and Readme etc from the booter somehow anyway.

[ghost]

I assume this would be a lot easier to add as the code has been in WinUAE for several years. I'm not even sure if WinUAE extracts the archive as i'm able to mount some of the 'Extract on Amiga' WHDLoad games without any problems occurring.

[HoraceAndTheSpider]

WinUAE still has to unpack the files according to it's website; http://www.winuae.net/features/

File support
Transparent decompression of popular compression formats, supported by all file types, including disk and CD images (zip, 7zip, lzx, lha, lzx, rar)

If it works like FS-UAE (highly likely as the codebase for FS is from WinUAE) then it will use extraneous data to ensure support of 'difficult' files (e.g. unsupported characters or permission flags) which is why you may not see any issue with those difficult games.

Hopefully we can tap into the same.

[ghost]

From what I read in FS-UAE, it creates its own 'bootable' directory by extracting the game, some files from a workbench disk and the WHDLoad program similar to what you described in the first post. I'm not sure how WinUAE does it, you obviously need a boot disk like workbench but all the suspect files seem to work and display correctly in DirectoryOpus. Hope @midwan can explain how it does this (because he uses WinUAE) as I find it interesting.

EDIT: I checked FS-UAE and it extracts everything to a directory on the host OS, in my case Windows user/temp etc. I checked the filenames of some of the "problematic files" and it had changed some of the characters due to not being an Amiga OS. WinUAE must be using a different approach.

[HoraceAndTheSpider]

As i said, FS gets around this using extraneous data files (.uaem) which cover the difficult areas - i.e. it 'changes' names on the host OS (as you noted) but reports the 'correct' names back to the emulated Amiga.

The problem is mostly related to Windows anyway, so not particularly relevant for Amberry's target plaforms (Primarily Linux based systems) at the moment, but must have to do the same, but possibly using the _UAEFSDB.___ files which contains additional data about files in the same way as the .uaem files do.

By default, i would expect the reuse of the WinUAE code to result in the _UAEFSDB.___ files being produced if needed.

At the end of the day, it doesnt really matter for the purpose of this thread though, I am already working on this, for the best solution for Amiberry, without getting too hung up on what approach FS-UAE or WinUAE specifically takes.

Amiberry is not intended to be a clone of either, yet all three share code, and the LHA / Archive handling code which i've identified in zfile_fopen_archive_data and zfile_fopen_archive_data for example is almost certainly used by all of them the same.

[Voljega]

This seems heavily dependent on the mentioned folders existing and having the right users, won't be the case on some distributions

[HoraceAndTheSpider]

Latest commit adds a solution for this, including LHA file support.

Games like Batman which should not be unpacked on Windows etc have been tested working on the solution provided.