Shared folder issue with Kickstart 1.3
 

Hi,

Bit of a noob question, can anyone tell me what I'm doing wrong?

I'm using WinUAE 2.3.3. The problem seems to be that under Kickstart 1.3, a shared folder is always bootable, even if you set it to be non-bootable.

I set up WinUAE so the emulated Amiga has Kickstart 1.3, and uses an image file of my actual Amiga hard disk (uaehf.device). [The HD boot partition startup-sequence loads Kickstart 3.1 using ReKick, then reboots and loads Workbench 3.1. Booting that way works fine.]

I then added a shared folder in WinUAE. The problem is that, even though it's marked as non-bootable (BootPri shows as -128 in the Hard drives panel), when using Kickstart 1.3 the emulated Amiga boots from the shared folder instead of the HD boot partition. Under Kickstart 3.1 the emulated Amiga boots from the hard disk as it should, not from the shared folder.

I guess it is 1.3 limit. It probably keeps looking for first "bootpoint" (bootable HD) device but does not check if there are more when creating list of bootable devices. (Floppy drives use bootblock booting and are handled separately)

Directory harddrives and hardfiles from Amiga point of view are two different devices (they use single autoconfig board but only because it was easier to implement)

Perhaps it is possible to reorder devices depending on boot priorities or something. Did you try moving hdf above the directory drive on harddrives panel?

Yes, the HDF is above the directory in the hard drives panel.

Something which might be relevant: the HDF has no filesystem in its RDB. The bootable partition is OFS, and that's the only auto-mounting partition. The startup-sequence on the OFS partition mounts and transfers control to FFS partitions.

Would a workaround for this issue be possible? Maybe the WinUAE boot-from-shared-folder code could check whether the shared folder is set as bootable in WinUAE settings, and if it's not, boot from the proper bootable device instead.

You don't see the relevant information: your HDF is not bootable. You make every effort to get the directory non-bootable, but all you will achieve by this is that you'll see the insert disk screen.

Put FFS into the RDB with dostype DOS\0, then it will probably work better.

Right, KS1.x can't boot without RDB filesystem (not even if it is OFS formatted). RDB + 1.3 compatible FFS in RDB or "FileSys" path in harddrive properties pointing to 1.3 compatible FastFileSystem probably works too.

Check winuaelog.txt for more information.

The HDF boots fine on both my real Amiga (with Kickstart 1.3) and WinUAE. You don't need FFS in the RDB to boot from an OFS partition.

The problem is that once I add the shared directory, under Kickstart 1.3 WinUAE boots from that in preference to the HDF. When the shared directory is marked as non-bootable, could WinUAE just not create a bootpoint for it?

I guess it was emulation problem in some older version that causes non-booting OFS under 1.3..

Does http://www.winuae.net/files/b/winuae.zip boot "correctly"? Not tested but technically it should fix this problem, at least if there are no strange 1.3 restrictions..

Yeah, you fixed that one a while ago.
No, unfortunately with winuae.exe from that URL I get the same issue of it booting from the shared folder with Kickstart 1.3. :(

Redownload and try again. Attach winuaelog.txt if it still isn't working (one from 1.3 and another from 3.x setup)

Excellent, it now seems to work fine!

The emulated Amiga boots from the HDF under Kickstart 1.3. It also still boots from the HDF when the shared directory is marked as bootable but with bootpri lower than the HDF. Edit: and if the shared bootpri is higher than the HDF partition bootpri (-100 in my case), it boots from the shared dir.

BTW, under Kickstart 1.3 using the Info command when the shared dir is mounted shows this:
And under Kickstart 3.1 Info (version 43.7) shows:
Are any programs known to have problems when presented with such large disk/free space sizes? Maybe a compatibility setting to report a maximum of 2GB free space could help in some cases?

Great.

Most common problem are installers reporting something like "You have -500M free, can't install"..

DOS uses two fields to report disk size: total blocks and blocks in use. Technically only working solution is to set total blocks = 2G/1024 and blocks in use = 0 but I am not sure if it is less confusing..

Directory Opus 4 (version 4.12CU) shows a requester "Selected entries will probably not fit in destination. Continue with copy?" when I try to copy files to the shared directory. It also shows a negative number for the free space.