[WHD packages] not running

[nemo93]

Describe the bug This ticket to track only the WHD packages actually not running on Amiberry.

• Battleisle (incl. datadisk)
• Drakken (image/files)
• Full Metal Planete
• Might & Magic 3
• Obitus
• Quest For The Time Bird/Quete de l'oiseau du Temps (image/files)
• SideWinder_v0.1_Arcadia (does work with KS 1.2)
• Starush (image/files)

To reproduce

1. Run any of the above (using the latest versions available)
2. you get to the "WHD trainers" screen
3. once that screen closes an error will be thrown

Additional context Packages do run fine on FS-uae. Even if it's likely due to issues with packages themselves (eg. #174) I wonder why they're not running on Amiberry.

I'm running 5.2 on Retropie 4.8 on Pi4. Buster / 32-bit / DMX. Everything (.uae, .chd, .lha) is therefore launched with the --autoload parameter.

[giantclambake]

Adding some comments/observations here, just in case such helps.

amiberry v5.6.1 / PLATFORM=x86-64 (Debian 11 but see the same on LFS 11.3)

Note: the --autoload option reliably throws a seg_fault for me here ~ using Quickstart and selecting a whdload.lha file via 'WHDLoad auto-config' tends to work successfully. Even though (most) of these archives don't run, they do get far enough to throw amigaDOS errors.

Wrt to listed WHDLoad archives here;

BattleIsle&DataDisks_v1.9_1991&0460&0667.lha & BattleIsle_v1.9_1991.lha (these titles don't require 68020)

Drakkhen_v1.3_Files_0769.lha (boots normally, gets past whdload trainer screen, then this)

FullMetalPlanete_v1.6_Files_0656.lha ...odd one, throws a seg_fault on Deb 11, but displays the same error as above on LFS-11.3

Might&Magic3_v1.2_2346.lha ..another odd one --- throws an amigaDOS error of "Illegal returncode #2336180" on the LFS-11.3 build, but on Deb 11 I see this error constantly scrolling up in amigaOS shell...

Obitus_v1.2.lha --- seems to load and work fine on both systems.

QuestForTheTimeBird_v1.2_Image_0564.lha -- another disparate result ; on Deb 11 I get the same error as above (rom error wrt devs:kickstarts stream up shell) ; on the LFS-11.3 I get "Dos-Error #205" as per above

Starush_v1.1_Files_2311.lha -- throws a seg_fault on Deb 11, on the LFS-11.3 I get "Dos-Error #205" as per above

I can't explain the disparity of results between the Deb 11 box, and the LFS-11.3 build (using the same amiberry git tree) --- that said, the Deb 11 system is AMD64 on nvidia vid drivers, whereas the LFS-11.3 is on i5 (Haswell) and i915 vid drivers (IGP)....and of course libc & friends will be different. I think I'll install Deb 11 to the i5 (Haswell) box, just to compare results.

[giantclambake]

Circling back to this ~ I'll have to setup my A1200 again one day, to get a baseline reading on whether the *.lha archives are sane/work on real hardware with ks3.1 roms. On a whim, I convinced myself the next best thing to check, would be trying to run the same whdload archives, from within ClassicWB (3.1) being hoisted on the amiberry uae engine ....

...this is so much fun -- in the emulated machine/AmigaOS environment, the results as shown above for the first 2 titles was accurately emulated (same dos error), the next 2 quietly failed to launch, Obitus ran fine, the next title threw the same error I saw on the LFS build ....but Starush (both archive versions I could find), runs & works fine ; go figure 8)

Starush_v1.1_Files_2311.lha -- throws a seg_fault on Deb 11, on the LFS-11.3 I get "Dos-Error 205" as per above Starush_v1.1_Image_2311.lha ..... ditto

So for mine, now another question becomes of this --- why do both of these whdload archives, load and run fine in the (stock) ClassicWB env running ontop of amiberry core? The contra question, might be what part of the amigaOS env is the WHDload auto-config function missing, to make things go off the rails here?

The seg_fault on Deb 11 is at a hunch going to be a glibc version thang, as it's libc.6 throwing error 4 (fetch from unallocated?), whereas the LFS boxen are on glibc 2.37 ...and flag the amigaDOS 205 error inside emulation of 'object not found' ... ie; nothing breaks =)

Either way, Starush -is- the anomally, by virtue of the fact it does work when amiberry is running classicWB and it's launched from there ...I get a gut feeling there's something here to answer the question 'why is it so?' ... and there's probably two things going awry here...ie; some of the titles listed are failing for different reason(s).

[midwan]

I suspect this has something to do with the .lha archiver code in Amiberry (which is currently in-sync with WinUAE). This allows us to open an archive as a read-only drive, but perhaps there are some issues in these cases documented above, considering they almost all report filesystem-related issues (like "Could not open Disk.1").

[giantclambake]

Hmmm.... behavior has changed here a bit (no longer crashing) ~ games aren't starting as per before, but now I see this wrt Starush (which now just blackscreens after whdboot cheatscreen);

FS: DH0 (flags=00000002,E=0,ED=1,EF=0,native='/tmp/amiberry/') starting.. FS: Games (flags=00000004,E=0,ED=0,EF=1,native='/home/gcb/Downloads/Starush_v1.1_Files_2311.lha') starting.. FS: Saves (flags=00000002,E=0,ED=1,EF=0,native='/home/gcb/Amiberry/whdboot/save-data') starting.. FS: DH3 (flags=00000000,E=1,ED=0,EF=0,native='/home/gcb/Amiberry/whdboot/boot-data/') starting.. Illegal instruction: 4e7a at 0022862C -> 0022863C B-Trap F200 at 00228656 -> 0022867A B-Trap F017 at 002286A2 -> 002286D4 VirtualProtect addr=0x5cf00000 size=16384 prot=4 PAGE_READWRITE ROM VP 00F00000 - 00F04000 4000 (16k) UNPROT VirtualProtect addr=0x5cf80000 size=524288 prot=4 PAGE_READWRITE ROM VP 00F80000 - 01000000 80000 (512k) UNPROT

Another odd thing wrt BattleIsle_v1.9_1991.lha .... in wiki/WHDLoad-Auto-booting is written;

whdboot/boot-data.zip must contain the Amiga WHDLoad Booter program.

However, an unpacked whdboot/boot-data folder may also be used.

If I unzip 'boot-data.zip' and then issue ./amiberry --autoload BattleIsle_v1.9_1991.lha I see this;

After hitting Cancel (Retry just returns and does nothing), the whdboot cheatscreen is displayed, and then I see;

Which I find odd, because amiberry.log discloses;

Mounting uaehf.device:0 0 (0): FS: mounted virtual unit DH0 (/tmp/amiberry/) Mounting uaehf.device:0 1 (0): FS: mounted virtual unit DH3 (/home/gcb/Amiberry/whdboot/boot-data/) Mounting uaehf.device:0 2 (0): FS: mounted virtual unit DH1 (/home/gcb/Amiberry/BattleIsle_v1.9_1991.lha) Mounting uaehf.device:0 3 (0): FS: mounted virtual unit DH2 (/home/gcb/Amiberry/whdboot/save-data) FS: DH0 (flags=00000002,E=0,ED=1,EF=0,native='/tmp/amiberry/') starting.. FS: Games (flags=00000004,E=0,ED=0,EF=1,native='/home/gcb/Amiberry/BattleIsle_v1.9_1991.lha') starting.. FS: Saves (flags=00000002,E=0,ED=1,EF=0,native='/home/gcb/Amiberry/whdboot/save-data') starting.. FS: DH3 (flags=00000000,E=1,ED=0,EF=0,native='/home/gcb/Amiberry/whdboot/boot-data/') starting.. Illegal instruction: 4e7a at 0022878C -> 0022879C B-Trap F200 at 002287B6 -> 002287DA B-Trap F017 at 00228802 -> 00228834 AUD0: forced idle state PER=512 PC=0022eee4 AUD1: forced idle state PER=512 PC=0022eee4 AUD2: forced idle state PER=512 PC=0022eee4 AUD3: forced idle state PER=512 PC=0022eede

AFAICT, this happens because if boot-data.zip does not exist (note: it doesn't ~ I unzipped boot-data.zip and moved that archive out of the way), Amiberry emits;

clipboard: reset (00000000) memory init end directory '/home/gcb/Amiberry/whdboot/boot-data/' not found, mounting as empty drive. uae_start_thread "filesys" function at 0x5573c5afb0a0 arg 0x5573c8d0eec0 uae_start_thread "filesys" function at 0x5573c5afb0a0 arg 0x5573c8d1aef0 uae_start_thread "filesys" function at 0x5573c5afb0a0 arg 0x5573c8d26f20 uae_start_thread "filesys" function at 0x5573c5afb0a0 arg 0x5573c8d32f50

...and somehow that gets passed onto the emulation, even though whdboot/boot-data/ does exist containing the contents of the boot-data.zip archive and is mounted later. What I find really weird, is so far, I find only the BattleIsle_v1.9_1991.lha whdload archive displays this behavior... ie; other whdload archives work fine with an unzipped boot-data.zip (and that .zip file is not present)....they might not run, but they don't error on DH3:

(rhetorical) -> why did/do I move boot-data.zip out of the way after unpacking it? It's because I found Amiberry will always try to unpack/mount that .zip file at DH3: if it exists, regardless of whether it;s been unpacked, and whdboot/boot-data/ contains all the necessary files...weird ;) Attaching said logfile wrt BattleIsle_v1.9_1991.lha ...

amiberry.log.gz

[midwan]

I tested WinUAE, by manually configuring it to the same thing we do with the WHDLoad booter:

It fails in the exact same way.

This seems to confirm my theory, that the problem here is not in Amiberry itself, or the emulation, but rather something with the archive reading code. We are mounting these .lha archives as virtual drives, and while this works fine in most cases, it seems to fail for some (those mentioned above), with filesystem errors.

An alternative would be to extract these archives before using them, but that will slow down the process of booting somewhat - and I don't like adding special cases for these titles only.

The best solution would be to find out what the issue is in the archiver code, and fix it there.

[midwan]

Actually, this fails even with the .lha archive extracted first. I think then that this is perhaps an issue with the .lha package specifically?

[giantclambake]

https://cdn.gamesnostalgia.com/getwhd.php?f=BattleIsle%C2%A3DataDisks_v1.10_0460%C2%A30667%C2%A31991.lha

Using amiberry v6.1.3

Quickstart -> select this .lha into the WHDload selector -> Start

-- I get an amigados error of MC68020 required to run this program....

F12 -> change CPU to 020 -> Reset

-- I get a different amigados error, claiming files are corrupted/damaged or 'unsupported version'

In ClassicWB setup, copy of same game archive;

-- get an amigados error of...

In Pimiga3 setup, copy of same game archive;

-- works correctly, so it's not a bad/gurged archive.

The pattern of it suggests to me that something's going arwy with the kickemu logic. There is/was a ticket on mantis to have the 020 requirement removed, but this was declined as it works IRL. In amiberry, we follow the XML which is stock A500 setup & ks1.3 rom as required, and we really shouldn't see the 020 required error (in Pimiga3 setup it's like this)... essentially speaking we should 'jump over' the kickemu/relokick to A500 kickrom..in effect....but we do A600 +ks2.05 and the switch to ks1.3 goes horribly wrong =) If this supposition is anywhere near correct, it explains more than half of the game titles mentioned here.

FullMetalPlanete_v1.7_Files_0656.lha , likewise, launches and runs fine in the Pimiga3 environment....you'd have to wonder =) That title looks like it tried to hook back to A500/OCS but fails miserably with chipset extra = A600 on ks2.05 ... I've yet to find what component(s) part of the Pimiga3 distrib allows these whdload game archives to work 'as expected'.

[midwan]

Maybe Pimiga doesn't include the DEVS:Kickstarts/* files, and WHDLoad cannot use them, so it skips that step? That would still indicate a problem with those specific slaves I think, however.

[giantclambake]

That seems to be correct ~ the Pimiga distrib does NOT include DEVS:Kickstarts/* files.

OTOH the ClassicWB distrib does include these files --- I went back for another look...

If we just aside any deference on case sensitivity in the requested path. it's obvious the file 'kick34005.a500' does in fact not exist in devs:kickstarts/ ....what we have is kick34005.A500.RDB .... on a hunch the 205 amigados error was being spawn from namespace, I renamed the kick34005.A500.RDB file to DEVS:Kickstarts/kick34005.a500 and tried to launch BattleIsle again...

That result would tend to infer that filename is an issue, but the subsequent amigados error of 'seek failure' I have no idea about, but clearly things are going awry here ...especially so when these titles work out of the box on Pimiga3 distrib =)

[giantclambake]

...which is me saying ClassicWB fails with these whdload titles, in similar fashion to how amiberry's whdbooter process is failing...

Wrt FullMetalPlanete_v1.7_Files_0656.lha failing with the 'Disk.1' error ...the amigados 'object' there is not a file I don't think, but rather a missing assign...ie; this would be something akin to "assign add Disk.1 DH1: " or such'n'similar... although thinking about it, 'Disk.1' is likely a volume id/name, and somehow that doesn't point back to the virtual filesystem of DH1: in amiberry.... like, I'd hedge a bet the .lha is decompressing correctly, and the files/structure are all intact, it just doesn't know where 'Disk.1' is ;)

edit;

Got these to work in ClassicWB (should've RTFM)... DEVS:Kickstarts/kick34005.a500 has to be a ks1.3 rom ; once that's inplace, all these titles launch fine in ClassicWB. Doesn't help much with amiberry's problems here, but at least proves these whdload game archives do work.

The 'Disk.1' error is the real show stopper here.

[midwan]

The RTB files are not the same as the kickstart files, that WHDLoad uses (if found) to improve the compatibility. In the case of Pimiga, those files are missing, so WHDLoad will not use them. These slaves happen to work correctly in that scenario, but fail when the kickstart is found and used, by WHDLoad.

The Disk.1 is a filename, which already exists in the archive. You can open it up and check for yourself. Also, considering that even WinUAE fails in exactly the same way when using the same mechanism that Amiberry does (minimal boot environment, using the DEVS:Kickstarts files and the same LHA archive), it's most likely not an issue with the emulator.

[giantclambake]

//...later, I figured out 'Disk.1' was actually a bootblock ; essentially if the .lha unpacked correctly, that should be present in the //virtual filesystem...in theory...

...I got to thinking about your suspicions the .lha decompress may have something to do with it... I went looking there...

Steps: debian12 AMD64, XFCE4 wm, firefox-esr -> download one of the above .lha archives --> double-click on entry in download list ---> this invokes xarchiver, which should display the archive contents, and allow you to extract same to location of choice...

That's all that happens, the xarchiver GUI gets 'stuck' there forever. If I look at cmd-line output for that operation...

So it appears lha l seems to be working, but for some inane reason, that output never makes it to xarchiver GUI .. what's more, most all of the .lha gamepacks here display the same behavior in xarchiver ....one exception is Might&Magic3_v1.2_2346.lha -- xarchiver only displays 10 files of the 50 it extracts ...

....I don't like coincidences, even though I'm talking about the system-wide lha command here, if it's getting just these .lha files wrong, and amiberry is having trouble with them ...maybe the internal decompressor is suffering a similar problem. I suppose I should check if lha x on the host, results in working unpacks that work on the guest ...(I've been unpack the .lha arcs in the Amiga host environment)...

[midwan]

@giantclambake I also suspected the archive handling, which is why I decompressed it and used it as a directory, in the test with WinUAE - still failed the same way.

[giantclambake]

I periodically recheck these, especially if I see any whdboot changes rolling in.

Wrt latest git pull from preview branch, the display behavour for these has gotten weird --- they still fail in the same manner, but, now they present like this;

All these failing whdload.lha packs are doing the same thing -- vertical shift of displayed image. (various lha packs that were working previously, still work fine.... go figure ;)

[midwan]

@giantclambake That's due to the gfx rewrite there, the manual crop settings won't always look correct (Autocrop might do a better job in this case). That being said, the settings are supposed to be for the game screen to look best, not the WB screen before that (although, since this game doesn't start, I don't know if it looks OK there with these settings).

[sonnenscheinchen]

There is nothing wrong with the lha-unarchiver or Amiberry. Whdload gets wrong configuration from the xml file and can't find it's data directory. If you edit the xml file and replace <datapath></datapath> by <datapath>data</datapath> the games will start with E.g.: whdload SLAVE=FullMetalPlaneteFilesNTSC.Slave DATA=data

Background: The xml builder automatically scans the .slave files for all kinds of information. But some slaves do not provide ws_CurrentDir. If you launch from workbench this it not a problem because whdload gets its configuration from the icon's tooltypes.

[giantclambake]

@sonnenscheinchen --- unfortunately speaking, that doesn't seem to be the issue with BattleIsle (see snippets below from the XML file) .... the directive <datapath>data</datapath> is already included, but the titles do not start/run.

I can understand if current directory is unknown, that could spawn an amigados error 205, but not the error 'data/disk-file are damaged or unsupported version' .

The title FullMetalPlanete has the XML directive<datapath /> which I've always construed to be the root_dir of the extracted .lha file (which we mount at Games: ), however changing that directive to <datapath>data</datapath> has no effect ~ title still does not start/run and produces same error.

On top of that, the directive <datapath /> does seem to work fine for other titles (ie; FullContact)

Did you test FullMetalPlanete with the XML edited to include <datapath>data</datapath> and it started/runs fine? If so, I'd be interested to know which version of the FullMetalPlanete whdload.lha file you used, along with amiberry version and some detail of your host OS.

battle-isle-snippets.txt

[sonnenscheinchen]

I re-checked again and, yes, You are right, editing the xml does not work. Amiberry does not set data dir even if provided. (It worked some time ago). Maybe faulty xml file and/or parser? But still... missing data dir is the problem. You could try the following: While emulation is still running and showing the amiga dos error message, open /tmp/amiberry/s/startup-sequence on the host os and add DATA=data to the end of WHDLOAD command line. Save the file and do a soft reset and see the game(s) running fine. Example: WHDLoad SLAVE="Games:FullMetalPlaneteFilesNTSC/FullMetalPlaneteFilesNTSC.Slave" PRELOAD NOREQ NOWRITECACHE SAVEPATH=Saves:Savegames/ SAVEDIR="FullMetalPlaneteFilesNTSC" DATA=data

[giantclambake]

@sonnenscheinchen ~ thanks for the suggestion -- I retested the titles listed here, and got the following results;

• appending DATA=data to the /tmp/amiberry/s/startup-sequence file as described, does indeed get the following titles working as expected;

Drakkhen_v1.3_Files_0769.lha FullMetalPlanete_v1.6_Files_0656.lha QuestForTheTimeBird_v1.2_Image_0564.lha Starush_v1.1_Files_2311.lha

The title Obitus_v1.2.lha should be excluded here, because 1. it seemed to work for me OOTB & 2. the .lha doesn't contain a DATADIR and the XML directive <datapath /> would actually be correct (and all that is required).

As I suspected earlier here, we were looking at more than one issue, and this round of testing seems to lend credence to that suggestion... NB: all the following titles start & run fine under ie; ClassicWB, so I'm reasonably sure the archives themselves are not corrupted.

BattleIsle_v1.9_1991.lha & BattleIsle&DataDisks_v1.9_1991&0460&0667.lha

Both of these display the following error, irrespective of DATA=data being set in sus...

Might&Magic3_v1.2_2346.lha

Setting DATA=data in sus has no effect, the only change being this title is now throwing an amigados error on this deb12 box, much like I was getting on the LFS-11.3 build during initial testing...

Again, thanks for the hint ~ that's really helped comb out what looks like 3 issues here in total ; likely midwan will have to weigh in this lot to figure out what if anything in amiberry is responsible for the carry-on ;) Kudos

[midwan]

@sonnenscheinchen Thanks for the find, that seems interesting enough. We have already established that it's not the mounting of the archives which was at fault, since the exact same thing happened on WinUAE as well.

It seems that the Datapath parameter is not being parsed at all in the Booter, so I'll look into that. In combination with updates to the XML where necessary, it should fix most of these cases then. Please report any XML fixes to the right repo, to ensure they are included in auto-updates from Amiberry as well: https://github.com/HoraceAndTheSpider/Amiberry-XML-Builder

@HoraceAndTheSpider ping ;-)

I guess the BattleIsle and Might&Magic cases are different and are not related to this issue, however.

[sonnenscheinchen]

@midwan Thanks for the quick fix.

Despite this is closed already, some remarks: :-)

• Obitus should run fine with fixed data-dir
• Battle Isle (+Data Disks): This is a very special case. Slave definitely needs 68020 which could be fixed but it also needs CUSTOM1=X as an whdload argument where X is a number between 1-5 depending on what you want to run (intro, data disk etc.) So this can't autoboot at all, at least not with the current implementation.
• Might&Magic3: This needs CUSTOM1=2 for whatever reason (not documented in the slave's readme)

[midwan]

Custom values parsing is the next item to fix, so hopefully that will take care of that. The rest (e.g. CPU) can be fixed by updating the XML accordingly.

[HoraceAndTheSpider]

@midwan Thanks for the quick fix.

Despite this is closed already, some remarks: :-)

• Obitus should run fine with fixed data-dir
• Battle Isle (+Data Disks): This is a very special case. Slave definitely needs 68020 which could be fixed but it also needs CUSTOM1=X as an whdload argument where X is a number between 1-5 depending on what you want to run (intro, data disk etc.) So this can't autoboot at all, at least not with the current implementation.
• Might&Magic3: This needs CUSTOM1=2 for whatever reason (not documented in the slave's readme)

you are able to set the CUSTOM parameter inside the .uae config file, just that , going by the above, they won't work "out of the box"