Closed rhester72 closed 2 years ago
Yep, something weird with the creation of the new Disk.1
under redirected savepath. It stops in the middle, as in the file size is only 500KB when it should be 880KB.. It is not uncommon for slaves to recreate the whole disk when saving data, but this is the first one I've encountered that fails doing so.
But funnily enough the saving does work when the LHA is launched extracted (via info file or directory). That way it replaces the original Disk.1
when saving. But even more funnily the redirected save method still DOES work when I launch the extracted version in a separate Workbench installation by defining SavePath
just like the WHDLoad helper image does..
I also tried with default ReadDelay
and WriteDelay
in WHDLoad.prefs
but no difference. And if it would be Libretro VFS related, it should have failed also with the file based Workbench installation method, so this is a head scratcher. But looks like the WHDLoad helper image is somehow to blame and not the core per se.
Lolwut, when launching the LHA it seems to work if I only delete the broken Disk.1
under WHDSaves/Portal
, but if I delete the whole Portal
directory, it does not..
Not sure what to say...I can reproduce exactly what you described as well but have no explanation at all LOL
Well, some good came of it...the world now has a legitimate IPF-derived version now (attached). It doesn't change a thing about the problem (or gameplay) besides having a virgin name register. =)
Well WHDLoad installs are made using retail IPF dumps.
Search for "portal" in http://www.softpres.org/games and the ID is 1971, as usually added in the pre-installed filenames. It is just a database, as in no downloads.
The Portal WHDLoad available everywhere currently was made from the (cracked) BTTR images, not the IPFs. You'll note significant differences in the Disk.x files in the version I created and attached.
Ach, okey, I shall try it then.
Looked a little further at this - the Disk.1 copy into the Portal directory truncates at 585,216 bytes, which is not-so-coincidentally the last byte of data that Portal attempts to write to the disk when you register a new player (diff between successfully modified disk versus virgin):
pi@retropie:~/RetroPie/roms/amiga/Games/WHDSaves $ grep ^585 /tmp/diff | tail -1
585216 375 1
Found another game that does the exact same thing (tries to create a full floppy sized save file, and fails in the middle), and also the same workaround works (delete only the broken file): Bobo_v1.0b_Fr_1951.lha
Hahaa, it actually is a bug in WHDLoad 18.7.. I tried again with 18.5 and it works fine. Looks like there is a fix for similar issues in 18.8 beta, so I'll update it at once when it comes out.
'Bobo_v1.0b_Fr_1951.lha' is over 20 years old ! Have you tried v1.1 that was updated to use WHDLoad 17 features, just in case that version doesnt play ball ?
But it is the exact same problem as with Portal. Both also work with 18.6, so maybe downgrade to that in the meantime..?
http://mantis.whdload.de/view.php?id=5536
Edit: Yep, 1.1 Bobo works with 18.7, since it is not saving the whole Disk.1
but small score.dat
instead.
Edit2: Doh, that 18.8 beta is not fixing this issue, so let's go back to 18.6 for the time being..
With WHD in either files or HDF mode, once you identify yourself at the start of the game Portal, WHDLoad throws the following error:
DOS-Error #219 (seek failure) on reading "Disk.1".
The same lha works on WinUAE/WHDLoad and MiSTer. Nothing interesting appears in the debug log and I can confirm Disk.1 is visible and readable by breaking WHDLoad Startup-Sequence and examining the filesystem directly.