Extend --autoload functionality to handle floppy disk images [feature request]

[giantclambake]

As a member of the typical 'target audience' for my emulator setup ( my 10yo grand-daughter =), she is here giving a quick demo/try of where things are right now --> https://www.youtube.com/watch?v=h4dHic7cQ5U

...ostensibly download the whdload.lha, right-click on file, run with amiberry (amiberry --autoload %F) ...

...the same custom action applies for other filetypes supported by the --autoload feature ..ie; CD32 .CUE/BIN CD images ...so one can download those filetypes as well, right-click on file, run with amiberry (amiberry --autoload %F) ...

In the first instance above wrt a wdhload.lha archive, amiberry has found the corresponding .uae config file for that title ( as the file conf/AddamsFamily_v1.3_0419.uae ), and is using the local config for that file, not the default whdload_db.xml config.

More or less I had something to do with the floppy panel in the GUI having this widget removed...

^

I never got around to testing that but the GUI panel is presenting better for it's loss ...so not to worry.

IMO it'd be a really good feature for the amiberry --autoload option, to recognize {adf/adz/dms/other?) files, and handle them with the same mechanisms/process as is current for whdload.lha archive autoloading ...ie;

amiberry --autoload filename.{adf/adz/dms} --> check for conf/filename.uae and use that if found, else use default.uae -> go!

One supposes if that were so, a cmdline like amiberry filename.{adf/adz/dms/cue/bin/lha} might be an alias for 'amiberry -G --autoload filename.ext , could be built into amiberry itself ...(largely because desktop app XDG mimetype default action is simplified if amiberry did, directly, something with a file it knew how to handle =)

What do you think?

[midwan]

@giantclambake
Thanks for the feedback!
That's not a bad idea, but the WHDLoad mechanism is based on matching those LHA packs with their checksum value or title alternatively, in order to recognize them. Obviously we can't use the checksum for non-WHDLoad cases, as there are too many versions of the same disk out there. The title matching might work better in that case, but the titles in the XML currently are based on the WHDLoad packs, and include the specific version of each pack. Floppy versions won't have the same names, and sometimes have extra stuff appended to their names as well (e.g. Disk-1).

There would have to be some sort of "clean title" field, either by adding that to the XML or by doing some guess-parsing on the filenames (which can be tricky and prone to errors). And even then, we'd have to match the floppy title to the list of "known" titles in the XML.

To give you a real-life example, I have the following ADFs for the Addams Family game in my collection:

Addams Family, The (1992)(Ocean).zip
Addams Family, The (1992)(Ocean)[a].zip
Addams Family, The (1992)(Ocean)[cr FSN].zip
Addams Family, The (1992)(Ocean)[cr FSN][a].zip
Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX].zip
Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX][a].zip
Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX][a2].zip
Addams Family, The (1992)(Ocean)[cr FSN][t +4 ATX].zip
Addams Family, The (1992)(Ocean)[cr FSN][t +20 LSD].zip
Addams Family, The (demo-playable) (1992)(Ocean).zip
Addams Family, The (demo-playable) (1992)(Ocean)[a].zip

And the XML contains one entry for it, with the following identifiers:
filename="AddamsFamily_v1.3_0419" sha1="a54a35018bb1d7928de291f70a0adae7cf94b0a4"

As you can see, there are a few issues to match those two together: spacing, extra text, version info, year info, etc.

Regarding the autoload becoming the "default" mode of parsing a parameter, that's probably easier to do of course.

[giantclambake]

Thanks for the comments ~ it seems my intent has been somewhat misconstrued, but this is understandable =)

Let's backup a little here, so I can ask you a question;

Question: How were the GUI options of 'Save config for disk' & 'Load config with same name as disk' supposed to work?

Surely this was only a namespace match between 'diskname'.floppyimage & conf/'diskname'.uae ???

[giantclambake]

//Lets see if I can explain this a little better...
//I'll use the youtube vid linked above as a visual reference here...

Firstly, I do NOT want to use the XML to handle floppydisk image auto-configuration using the --autoload option. (that would be a parsing horrowshow =)

As can be seen in the video, users of my desktop emulator build can do the following....

• Download AddamsFamily_v1.3_0419.lha from a website
• In the desktop file-manager, use RMB -> Run with amiberry (invokes amiberry --autoload %F )

software perspective:

amiberry --autoload AddamsFamily_v1.3_0419.lha

-> check if conf/AddamsFamily_v1.3_0419.uae exists, and if found use that to start the emulation, without consulting
 the XML at all (no sha1 sum check)
-> if not found parse the XML for a match to 'AddamsFamily_v1.3_0419.lha' and use those settings to start the emulation
-> if no match is found in the XML, launch the whd-autobooter thingy

What I'd like to be able to show you in a future video, is one of my emulator users doing the following... (note: just 1 floppydisk image format used, presuming most all floppy image extensions supported)

• Download Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX].zip floppydisc image from a website
• In the desktop file-manager, use RMB -> Run with amiberry (invokes amiberry --autoload %F )

software perspective:

amiberry --autoload Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX].zip

-> check if conf/Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX].uae exists, and if found use that config
 file and start the emulation
-> if not found, start emulation with  'amiberry -0 Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX].zip -G' 
     (this would analogous to GUI > Quickstart > load floppy image > start emulation)

Following on with the example drawn, it happens to be the case that both the above titles require 'gfx_center_horizontal=smart' set to display correctly, and this presents the user the task of having to create the associated .uae to automatically set this instead of using the XML or the default.uae config. This means the user has to manually fill out the Name: field for the config file, and 'AddamsFamily_v1.3_0419' is already a cumbersome task prone to (10yo =) user error in the first example above, and expecting anyone to get 'Addams Family, The (1992)(Ocean)[cr FSN][t +2 SCX]' right, is some form of sumbliminal mental torture imho =)

Thinking about it holistically, the --autoload switch does represent GUI > Quickstart panel usage for pretty much all media/file types supported...ie; load & go ... and seeing as we've forgone the 'Save config for disk' widget, it would be extremely useful if the Quickstart panel had a "Create .uae for loaded title" button or such and similar, to aid users when they need/want a local .uae config that differs from the XML and/or the default.uae config when floppy images are autoloaded...(saves users from errors/frustration typing in truly crazy strings full of whitespace 8)

For mine (and my users =), this would make amiberry the 'swiss-army-knife for desktop Amiga emulation', in that one can download any of these supported Amiga title filetypes, and double-click/RMB to run with amiberry, and it will...and some greater % of the time, the default.uae or the XML params will work, and when one needs/wants to create a local.uae for that title, there's an 'easy' route to achieve that. When you use the command 'amiberry --autoload floppyimage.ext' and a .uae file exists, in a way replaces the 'Load config with same name as disk' widget, as that's effectively what you're doing here.

It would then make a lot of sense to be able to do 'amiberry titlename.ext' (inferring --autoload), and be able to set the default_app mimetype to amiberry itself for these file extensions, which is useful for the purposes of ie; being able to download an Amiga disk/whdload file, and launch with amiberry after download (no local copy of the file kept, handy if booting live system from USB stick).

Does that explain it any better?

[midwan]

Thanks for the explanation.

Let's see if I got everything right:

• The --autoload option triggers the WHDLoad booter mechanism, which will use the XML file by design, as part of the process. Using this option for floppy images doesn't seem like a good idea, for the reasons mentioned above.
• We can add an option to save a config based on the loaded title (either floppy or WHDLoad) in the Quickstart panel. That way, if you use the GUI to load things up, you can make your modifications and save a config with the proper name easily.
• We can also add the functionality to look for a .uae config with the floppy filename loaded into DF0: when starting up. I think this would be best set as an option, perhaps in amiberry.conf, to control if it should be enabled by default or not. Just to be on the safe side (it will come as disabled by default).
• In order to use a fallback where a filename passed with no options, will be treated the same as it was specified with --autoload, we'd need to expand the logic behind --autoload to detect the type of image it got. We've got floppy images in the various supported formats, CD-ROM images (for CDTV/CD32) and of course, WHDLoad images in the supported archive formats.

Then if the above is done, it would be possible to use the following scenarios:

• amiberry MyGame.adf -> uses the autoload logic to determine it's a floppy image, redirects the flow to loading a floppy image to DF0:, checks if an existing config with the name MyGame.uae exists (and loads that if it does) otherwise proceeds with the default configuration.
• amiberry MyGame.zip (where the .zip file contains a single .adf) -> same process as above
• amiberry MyGame.lha -> uses the autoload logic to load the WHDLoad game as it does today
• amiberry MyGame.zip (where the .zip file contains a WHDLoad slave installation) - same process as above

Is this what you're looking for?

[giantclambake]

@midwan

That is absolutely spot on, and would be fantastic if you could make it so. I did think there was some overlap on the .zip extension but figured a floppy image wasn't too hard to test for. One supposes this would allow for drag&drop launching of these file-types as well.

This would be an excellent feature add imo ~ I'll be sure to check it out, but if you need any specific testing here give me a ping =)

[giantclambake]

//Another example, roping in ticket #960

Fact: There are several, multi-disk Amiga game titles, that do not have a whdload alternative. Some of these titles can comprise of up to 15 disk images.

If #960 was addressed in such a way, that the .ZIP file could contain as many disk images as required... with the changes proposed above, one could ..

'B.A.T. II (1992)(Ubi Soft)(Disk 1 of 5)[cr SR].adf' 'B.A.T. II (1992)(Ubi Soft)(Disk 3 of 5).adf' 'B.A.T. II (1992)(Ubi Soft)(Disk 5 of 5).adf'
'B.A.T. II (1992)(Ubi Soft)(Disk 2 of 5).adf' 'B.A.T. II (1992)(Ubi Soft)(Disk 4 of 5).adf'

Create a .ZIP archive of these 5 files -> B.A.T.-II.zip

Create a B.A.T.-II.uae config-file to automagically handle the B.A.T.-II.zip archive and apply any required configurata.

//just thinking out loud ;)