Why is this happening? Another set of eyes please...

[giantclambake]

//..further results of my recce through whdload.lha game packs...

This has been happening for a little while now ~ I just spent the last few hours looking at it, and I'm really coming up short finding a cause or explanation for the behavior. I think it's breaking in amiberry somehow, but I can't put my finger on it...

To recreate is a tiny bit involved, but it's worth a look...I'm presuming $CWD is ~/Amiberry

cd ~/Amiberry
Install links in graphical & text guises --> sudo apt install links2
Open an xterm (or at the console), launch links2 once, to create the user conf_dir/files -> links2 -g --> press q to exit links2
Edit the resultant ~/.links2/links.cfg file, and add the following line and save the file (x11 version, console trailing flags differ);

association "Amiberry" "application/x-lzh-compressed" "~/Amiberry/amiberry %" 10 1

Now launch links2 again, with the following invocation (I have a desktop launcher icon to do this);

links2 -g -mode 1024x768 whdownload.com

On that webpage, navigate to the A/Arkanoid entry, and click on the link ...

...process: links2 downloads the file to /tmp/hashed-filename.lha and appends that to the cmd ~/Amiberry/amiberry <file>
As amiberry is filename agnostic here, I only need rely on the .lha handling for the whdbooter, and md5sum checking in the XML, to arrive at the correct result...ie; you should find the title starts and runs as expected...

Quit amiberry
In the links2 window, click on the A/Arkanoid (NTSC) link --> result here is the whd-booter autoconfig shizzle appears..
If you follow on with F12 -> WHDload panel, I see..

So it appears as though the .lha trigger went off, but the whd-booter process, caught an empty handle?

Quit amiberry

Back in the links2 window, press g and enter the URL http://ftp2.grandis.nu/turran/FTP/Retroplay%20WHDLoad%20Packs/Commodore_Amiga_-_WHDLoad_-_Games/A/ and OK --> click on the link Arkanoid_v1.9_0954.lha ...result here;

Goodgrief... F12 -> WHDload panel ...all textboxes empty ...BUT.. if that's the case, why did we end up booting to this Amigados error, if nothing is apparently loaded? It appeared to me it was in direct whdload process, and not at the same time.. run.exe??

Cross check for sanity: ie; ./amiberry /tmp/linksKqMkZY.9_0954.lha ...works as expected, go figure..$file is good..

Quit amiberry, retest.. same result, but this time F12 to really check, and finally found what had been loaded, where....

...and yep, I had that Mr. Spock raised eyebrow thing happening ;) Why the blazes did it decide to do that?...pop a filename.lha archive, into the DF0: slot?... I doubt that's even possible to recreate at the user level ...my justifiably paranoid spidy senses are starting to tingle....

What is going on here? Do we have some sort of race condition, or crazy overrun happening or such and similar? It'd be worrying in a deployment context if one had another web-browser..ie; firefox-esr, hauling the same problem (hard to test currently, but in the future the 'Open (with amiberry) when download completes' route would be analogous)...

I doubt many folks are using a web browser like links2 as a launcher for whdload.lha game packs, online, using amiberry, and operating out of the semi-volatile /tmp location... and only the crazy would find themselves here... but I doubt I'm that ; it should not be possible for a whdload.lha file, to be loaded into DF0:

Note: the really odd thing, is something like 90% of titles work as expected with links2 -g -mode 1024x768 whdownload.com using this setup, while just about all error out using turran ftp...

Anyone got any idea what's manifest here?

TIA

[giantclambake]

..a new day and a new dawn ~ retesting the examples above with a debug build of Preview on x86-64...

First example for Arkanoid that works...

WHDLoad... /tmp/linksxL2cRa.9_0954.lha
WHDBooter Launched
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
SymLink Kickstart ROMs for Booter
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
WHDBoot - using kickstarts from /home/gcb/Amiberry/whdboot/save-data/Kickstarts
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick33180.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick34005.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick37175.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick39106.A1200  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40063.A600  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40068.A1200  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40068.A4000  [Ok]
WHDBooter - Host: A600 ROM available, will use it for non-AGA titles
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
WHDBooter - Searching whdload_db.xml for linksxL2cRa.9_0954
WHDBooter - Selected Slave: Arkanoid.Slave
WHDBooter - Game H/W Settings:

                        PRIMARY_CONTROL=MOUSE
                        PORT0=MOUSE
                        PORT1=JOY
                        SCREEN_AUTOHEIGHT=FALSE
                        SCREEN_HEIGHT=432
                        SCREEN_WIDTH=720
                        SCREEN_CENTERH=SMART
                        SCREEN_CENTERV=SMART

WHDBooter - Created Startup-Sequence

|

Second example for Arkanoid (NTSC) that ends up with WHDBooter autoconfig.....

WHDLoad... /tmp/linksu4EYxX.9_NTSC_1136.lha
WHDBooter Launched
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
SymLink Kickstart ROMs for Booter
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
WHDBoot - using kickstarts from /home/gcb/Amiberry/whdboot/save-data/Kickstarts
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick33180.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick34005.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick37175.A500  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick39106.A1200  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40063.A600  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40068.A1200  [Ok]
Making SymLink for Kickstart ROM: /home/gcb/Amiberry/whdboot/save-data/Kickstarts/kick40068.A4000  [Ok]
WHDBooter - Host: A600 ROM available, will use it for non-AGA titles
internal savedatapath [/home/gcb/Amiberry/whdboot/save-data]
WHDBooter - Searching whdload_db.xml for linksu4EYxX.9_NTSC_1136
WHDBooter - Game: Port 0     : nul
WHDBooter - Game: Port 1     : nul
WHDBooter - Game: Control    : nul
WHDBooter - Game: CPU        : nul
WHDBooter - Game: Blitter    : nul
WHDBooter - Game: CPU Clock  : nul
WHDBooter - Game: Chipset    : nul
WHDBooter - Game: JIT        : nul
WHDBooter - Game: CPU Compat : nul
WHDBooter - Game: Sprite Col : nul
WHDBooter - Game: Scr Height : nul
WHDBooter - Game: Scr Width  : nul
WHDBooter - Game: Scr AutoHgt: nul
WHDBooter - Game: Scr CentrH : nul

So it appears as though the WHDBooter process is failing to find a match?

./amiberry Arkanoid_v1.9_NTSC_1136.lha works as expected...
./amiberry /tmp/linksu4EYxX.9_NTSC_1136.lha works as expected...

The md5sum values match;

gcb@gallah:~/Amiberry$ md5sum Arkanoid_v1.9_NTSC_1136.lha
ac52c284f99354074d6c67d4766f27fa  Arkanoid_v1.9_NTSC_1136.lha

gcb@gallah:~/Amiberry$ md5sum /tmp/linksu4EYxX.9_NTSC_1136.lha
ac52c284f99354074d6c67d4766f27fa  linksu4EYxX.9_NTSC_1136.lha

|

Retesting 3rd case above, using the Turran ftp link....

WHDBooter process doesn't get invoked -- it seems the .lha trigger fails to fire -- the name of the filename.lha ends up loaded into DF0: -- we end up booting to the Amigados error above -- direct loading the file ie; ./amiberry /tmp/linkssFN7t0.9_0954.lha works...

Attached amiberry.log.gz of this last case.

The behavior is undefined enough for me to call bug ~ it appears like amiberry and/or the WHDBooter process are failing, but I can't seem to isolate the exact cause =^/

amiberry.log.gz

[giantclambake]

src/disk.cpp: const char *fname1 = "runme.exe";

..so that's where the amigados error is being hauled from...

Tried unpacking boot-data.zip to eliminate that decompression task ~ didn't have any effect...

[giantclambake]

....I just knew this would come back to bite me one day....chronologically..

-around 12 months ago when I was investigating filetype associations, I noticed that links2 made a distinction between which .lha files were classified as application/x-lzh-compressed or instead application/octet-stream . In practice you could see this, by downloading some .lha archive from animet, or instead a whdload.lha game archive for example. As that basically suited purpose, I didn't question the why behind it....

-at this time, I had added another association line to links2.cfg, to autoload disk images ...keep in mind, this was before we had the amiberry <file> invocation. ..

association "Amiberry" "application/x-adf, application/x-dms, application/octet-stream" "~/Amiberry/amiberry --autoload -0 % -G" 10 1

'For some reason' (still checking into it), in links2 the whdload.lha game archives from Turran ftp, were being initially detected by the download handler as lzh-compressed files, but when being passed off the application launcher, would get handled as if it were an octet-stream. Somewhere in here, it managed to get amiberry to load the whdload.lha file into -0, and try to start it like a disk image. This was largely sublime, it's all happening just before amiberry's invoked...hmmm...

*Feature add -- If Enable logging = True, log commandline used at top of logfile.

..after I figured out what was going on, and changed the association for floppy images to the amiberry % construct, whdload.lha game packs work as expected now...in fact, Arkanoid_v1.9_NTSC_1136.lha worked...

Turns out, the file on whdload.com is not the same as the one on Turran (in ../Downloads/ )...

gcb@gallah:~/Amiberry$ sha1sum Arkanoid_v1.9_NTSC_1136.lha
217656ffcbac7219b5b4b73542db1d43b0eb78a8  Arkanoid_v1.9_NTSC_1136.lha

gcb@gallah:~/Amiberry$ sha1sum ../Downloads/Arkanoid_v1.9_NTSC_1136.lha
09aa50a221287f4f4cd57e965b58311ffc9c35a2  ../Downloads/Arkanoid_v1.9_NTSC_1136.lha

Go figure...why is it with particularly things Amiga, filenames can be (and are) so crazy & misleading at times...so that explains why it was falling through to the WHDBooter autoconfig shizzle -- no match in the XML....hmm...

Possibly that's a telltale, we don't address...ie; wiki/WHDLoad-Booter-(WHDBooter)-F.A.Q. ...ie;

Q. When I load a whdload.lha title, I see the WHDBooter screen, what's wrong?
A. It is very likely the XML does not (yet) contain an entry for that particular whdload title, so... //add explanation as necessary

....ummm... it might be prudent to know, absolutely, what cmdline invocation leads to a failure like this..yes? The expectation might be, that amiberry bails if file isn't a floppyimage.ext when being asked to put <file> into DFx: ... might hoist a ticket per above, it'll be useful here and maybe other usage scenarios when you need to know how amiberry was called..

[giantclambake]

Closing this one ; I figured out all the weirdities and the ticket's to be actioned -- maybe the FAQ bit might close off a hole ... a hole that grows ever larger with new whdload titles being added every few months ~ that's another issue I'll have to think about...