Beats me, I have no issues booting without any CD inserted, and then use Disc Control to insert something into CD0:…
Could you try getting a proper crashing debug log by building the core with DEBUG=1 and running through gdb to know where it actually crashes?
Also why on earth are you mixing a3000mem_size with some A4000 setup and not Z3?
Ok, had a look at the SCSI CD mounting code, and indeed at one point it is doing strdup for the null volume string when SCSI is enabled if nothing is mounted. The outcome of doing that most likely differs between platforms.
And also the empty unit has a default native mountpoint of / which does not even make sense from Windows point of view, but looks especially bad for non-Windows.
So could you confirm that there is no boot crash if you add cdimage0=x,? That extra ending comma is needed if the path itself has a comma in it.
I have a rather simple workaround ready too.
Sorry for the late response…work’s been busy.
I tested cdimage0 against the ISO and it worked on the very first try! 
If I replace the actual path to the ISO with an invalid path, I get the same thing as before…instant segfault.
Okeydokey, I pushed a fix for both cores, so stay tuned for the core to update.
Building now directly from source, will provide test results shortly
Confirmed - works exactly as expected!
Thank you VERY much!
Excellent, thanks for pointing out that flaw!
Also why on earth are you mixing
a3000mem_sizewith some A4000 setup and not Z3?
I forgot to respond to this.
As I understand it, a3000mem_size is misnamed (because that’s what it was first used for), and actually (generically) refers to any 32-bit motherboard memory that isn’t autoconfig, unlike Z3 RAM (which is treated like a Zorro board and is autoconfig). Thus, a properly-modeled A4000 with fully populated motherboard memory would indeed reflect as written.
Hi All,
I’m having a similar kind of problem and this is the closest kind of thread I can find where I can comment on it.
At the moment I’m trying out a new game I just picked up, Tales of Gorluth III. I’ve picked up the digital edition and it works fine in WinUAE, but I can’t get it to load in PUAE, which is generally the only way I play Amiga titles these days due to the shader support.
The reason I think it doesn’t work is because the file structure doesn’t include the libraries to run in it’s own folder and relies on workbench to load them in. To get it running in WinUae, you attach a Workbench ADF and attach the Zip file for the game as a hard drive folder - it boots into workbench and you double click the file/ executable and the game starts running.
In PUAE things are different, as you can’t just attach an ADF and a HD Folder the same time (or at least I’ve yet to work out how to do this in Retorarch or with a .uae file or .m3u file), so I haven’t been able to replicate the process.
So, if anyone can provide assistance - I consider there might four possible ways to solve this.
M3U file - the correct formatting to allow both ADF and a HD Folder to run at the same time and then just change disk and have the HD folder show on the workbench desktop. I actually don’t think this is possible considering the limitations PUAE, but if it is, this would be by far the easiest solution.
.uae config file - an example of a config layout for AGA 040, could allow first an ADF to be booted and allow the HD Folder to be seen on the workbench, and any recommended settings to be turned on in Retorarch to get this to work (Global Boot HD?).
Manually create a .slave file (I don’t know how to do this), add workbench .s files as part of src folder, and libs folder with the correct libraries (which ones?), as add a start-sequence or asm file which then defines the load sequence and loads in the libraries on boot - and I’d assume this would allow for a workbench environment to be created where the file could be loaded from.
Create a HDF file as a container for the HD Folder folder and it as part of it’s archive. This may or may not include step 3. I also wonder if this step would include turning on Boot Global HD? and using step 2 to get it to launch from a .uae config file?
Or is there a simpler way to do all this that I’m missing?
The folder structure looks like this:
Top level folder TOGIII-030-EN (Folder) TOGIII-030-EN.info
Sub level folder Pics (Folder) Levels (Folder) Files (Folder) TalesOfGorluthIII.info TalesOfGorluthIII (no association - this would be the executable?)
Thanks in advance for any help with this.
Does the folder necessarily have to be ZIPped, or can it be unzipped just sitting on the underlying filesystem as a series of files and folders? If the latter, I may have a solution.
The core does not care if the content is extracted or not. And this SCSI crash has nothing to do with this launch thing.
Understand the two are unrelated…but in local testing, at least the older/faster core does seem to care. I too can’t get it to mount a ZIP file of random files as a disk - the log looks clean, it says it’s mounted, info shows the device, but there’s no actual device presented. A raw directory works as expected.
If the zip contains recognized valid file extensions, an M3U will be created from them and launched. If not, the extracted temp dir is just a hard drive like any other directory, not a floppy disk. There is no difference between the core versions.
I put a zip inside a 7z, and when the “Global Boot HD” option is enabled, and a working Workbench is installed there, when the 7z is launched, the TEMP dir used for extraction is there as a drive.
Is there a max size limit on the extracted temp dir? As I said before, at least on RetroPie, the log looks very clean mounting a ZIPped directory of random content but nothing is actually presented in-emulator. It’s very easy to reproduce.
How do you determine what and how is something presented in emulation? Workbench won’t show any drive contents by default other than info files.
No, there is no max size limit other than your own local storage. Max file count for M3U generation is limited to 20.
.uae file:
floppy0=/home/pi/RetroPie/roms/amiga/amigados13.adf
filesystem2=ro,test:test.zip:/home/pi/RetroPie/roms/amiga/test.zip,0
So long as test.zip is big enough to pass the “too small” check, the log shows it mounted:
[libretro INFO] Mounting uaehf.device 0 (0):
[libretro INFO] FS: mounted virtual unit test (/home/pi/RetroPie/roms/amiga/test.zip)
[libretro INFO] FS: test.zip (flags=00000000,E=1,ED=0,EF=0,native='/home/pi/RetroPie/roms/amiga/test.zip') starting..
Opening a CLI in Workbench shows the test: device mounted (but with no disk inserted…however, that’s normal for uaehf), attempting “dir test:” results in an error that no disk with that name is mounted and no drive icon shows up on the workbench.
If you extract the contents of the zip and mount that in the .uae instead, it mounts and displays as expected.
I was talking about the automagic core launch method and not uae conf method, which should still work the same, sure. But why the need for the uae conf trickery?
Also that E=1 there means that the drive is empty, which kinda does not make sense with zips…
In any case, I haven’t tested that internal direct zip filesystem reading stuff at all.
Understand. I looked at the .uae method because it seemed the only way to solve the OP’s issue with a specific ADF and ZIPped content combination. It’s not the same at all as a “Global Boot HD” configuration/issue as I understood them.
@Chippy, two things - first, please start a new topic for unrelated issues in the future, and second, see my sample .uae file - DON’T zip your content (because it won’t work for reasons unknown, WinUAE 2.4.1 crashes outright when you even try to save such a config, so it’s probably an old bug), but as long as you’ve extracted it somewhere, just point filesystem2 at it and you should be good to go.
Something like this as a place to start:
“Tales of Gorluth III.uae”
with contents:
floppy0=/home/pi/RetroPie/roms/amiga/tales_of_gorluth_3.adf
filesystem2=ro,DH0:DH0:/home/pi/RetroPie/roms/amiga/tales_of_gorluth_3/,-128
Adjust paths and names to taste, change “ro” to “rw” if you want to be able to write to the filesystem “hard drive”. -128 means non-bootable.
If you need a different kickstart, RAM configuration, non-default CPU, etc., etc., etc. then standard WinUAE configuration filename conventions will work (e.g. kickstart_rom_file, chipset, chipset_compatible, bogomem_size, chipmem_size, fastmem_size, z3mem_size, cpu_model, et al) or compatibility options (cpu_compatible, cycle_exact).
@Chippy, two things - first, please start a new topic for unrelated issues in the future
Yeah, sorry about that - I could only previously post on existing ones, as I haven’t posted that many times, I would’ve created a new thread otherwise. I got promoted shortly after this post.
DON’T zip your content (because it won’t work for reasons unknown, WinUAE 2.4.1 crashes outright when you even try to save such a config, so it’s probably an old bug), but as long as you’ve extracted it somewhere, just point filesystem2 at it and you should be good to go.
That makes sense and is exactly what I experienced. The zip mounting seems to work with the latest version WinUAE. Retroarch sometimes trails a version or two in the cores in general, so I’m guessing that might work itself out in the next update or so - which is good news.
Hey I think you’ve answered my question with the .uae example (Thank You! 
) , it’s consistent with some of the info I’ve seen on other sites and nicely specific to what I’m trying to solve! I’ll give this a try. 
Passing this on for anyone who might need this in the future, and also if you’re not so great at writing config files for the Amiga emulators (like me). This was a few days of scratching my head, trying things out, asking for help, and at times being very frustrated… but I did have some success in the end.
To get the digital version of Tales of Gorluth 3 running. I created a .uae config that looks like this:
kickstart_rom_file=C:\Emulation\RetroArch\system\kick40068.A4000
kickstart_rom_file_id=D6BAE334,KS ROM v3.1 (A4000)
floppy0=D:\Amiga Games\Workbench\Workbench v3.1.adf
filesystem2=rw,DH0:TOGIII-030-EN:C:\Users\Amiga\Talesofgorluth3\TOGIII-030-EN,0
uaehf0=dir,rw,DH0:TOGIII-030-EN:C:\Users\Amiga\Talesofgorluth3\TOGIII-030-EN,0
I was able to do this by actually going back to WinUAE first, configuring it as normal, adding the adf (workbench) in the floppy drive section and then add the (Tales of Gorluth 3) unzipped folder as a directory in the Hard Drives section.
Once I could see it was running fine I saved the config and copied it over for use with PUAE. From here I edited the file in notepad and cut out everything except for what was relevant to get it running.
It now loads in PUAE and then is able to progress in game. There are some odd in game bugs and it will crash at certain screen, this might be down the game itself or the settings, but also could be emulation (maybe), hard to say yet. I’ll play around with the settings a bit more and see how it goes, now that I can get the thing to load.
So this method allows you to get into workbench and then load a hard disk folder successfully without the need to install workbench on to a (virtual) hard drive (HDF), or use any additional methods to get things running. This could also be useful for testing bugs between the different emulators I’m guessing.