Libretro-uae 2.6.1 (nee puae) segfault with SCSI

Libretro Cores
#21

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).

1 Like
#22

@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! :slightly_smiling_face:) , 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. :raised_hands:

#23

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.