English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   HDF behavior different between uaehf.device and C= scsi.device? (http://eab.abime.net/showthread.php?t=91258)

Akira 13 March 2018 21:19

HDF behavior different between uaehf.device and C= scsi.device?
 
I made an HDF of my CF which I was using in WinUAE with the Commodore A1200/600/4000 IDE scsi.device, and when I try to use it with uaehf.device instead, I get an error trying to mount the FFS partitions within.

The disk is formed of a first partition using PFS3, and 3 subsequent partitions using FFS.

When I try to mount any of the FFS partitions, it takes a long while, spews out no error, but the partitions aren't mounted.

Does uaehf.device just not accept partitions with different filesystems, or I am doing something wrong?

I can use the hardfile perfectly wth the C= scsi device, but I was wondering if this was a problem or just user stupidity :P

thomas 13 March 2018 21:32

What do you mean by "When I try to mount any of the FFS partitions"?

Why aren't they mounted automatically and how do you (manually?) mount them (or try to)?

Switching from scsi.device to uaehf.device and vice versa shouldn't make a difference.

However, if you left the chipset extra with IDE port, but there is nothing connected to the IDE port, the OS (or rather scsi.device, which now has nothing to do any more) might need up to 10 seconds before it starts to boot. That's the same as on a real Amiga.

And scsi.device of course has all its limitations (like 4 GB and 7.8 GB) even on emulation. All these do not apply to uaehf.device.

So if your CF card was bigger than 4 GB and you hadn't installed the appropiate patches for scsi.device and FFS, then your partitions won't work on uaehf.device. That's correct. Actually on scsi.device it was not working correctly, your partititions were going to corrupt each other.

Toni Wilen 13 March 2018 21:34

winuaelog.txt includes detailed RDB information, attach it.

Akira 13 March 2018 22:06

1 Attachment(s)
Quote:

Originally Posted by thomas (Post 1226625)
Why aren't they mounted automatically and how do you (manually?) mount them (or try to)?

Because I don't want to mount them all the time.
I mount them with MOUNT from a mountlist made with giggledisk.

Quote:

However, if you left the chipset extra with IDE port, but there is nothing connected to the IDE port, the OS (or rather scsi.device, which now has nothing to do any more) might need up to 10 seconds before it starts to boot. That's the same as on a real Amiga.
It's not a boot delay.

Quote:

Actually on scsi.device it was not working correctly, your partititions were going to corrupt each other.
Everything was working correctly, I know how to setup a >4GB disk.
This is an image of my actual CF drive. It works fine with scsi.device.
The PFS3 partition boots fine (which loads updated scsi.device with loadmodule)

Ah!, there, could that be the problem? That the system loads an updated scsi.device to ROM?

Quote:

Originally Posted by Toni Wilen (Post 1226626)
winuaelog.txt includes detailed RDB information, attach it.

Cool, find it attached!

Toni Wilen 13 March 2018 22:15

uaehf.device only loads and installs RDB filesystem to FileSystem.resource if at least one partition that needs it is mounted. (Due to historic reasons, now it probably can be changed relatively easily)

Akira 14 March 2018 00:54

So this kind of drive will not work with uaehf.device then?
As I said, just curious, I don't mind using C= IDE.

thomas 14 March 2018 08:21

Just make proper mount lists with the file systems in L: and a FileSystem= entry in the mount lists.

Toni Wilen 14 March 2018 09:42

I am wondering if there is any kind of "spec" for RDB filesystem loading behavior or if Commodore scsi.device behavior is simply implementation detail.

Sounds unlikely because far too many HD controllers have all kinds of odd behavior with RDB filesystems..

Akira 14 March 2018 15:16

I think I figured it out.
The mountlist entry specifically targets "scsi.device". This must be the problem.
Could it be?

idrougge 15 March 2018 01:49

Yes, that sounds like it.


All times are GMT +2. The time now is 23:31.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.07326 seconds with 11 queries