Trying to mount and boot muFS hardfile images.

[Ionizer]

Hi. I'm trying to boot from an Amiga 3000 hard drive image formatted using an old Professional File System / MultiUser File System, identifying as muFS.

I am using the uaehf.device to mount the drive, as when I select the A3000 scsi.device the drives are not detected in the emulator.

I'm using a 3.1 workbench floppy image to boot and run HDToolbox, images below.

My A3000 had three hard drives, and 2 of them show up in Workbench, but the boot drive does not. The only difference I can see is the boot drive has 2 partitions. Is that an issue?

If I try and boot from the drive image, I just get a black screen, sometimes a blinking red Software Error.

In summary, I have 3 drive images, 2 mount when booting from floppy but one does not.

Also, why can't I get the scsi.device option to work? I assumed that would give better compatibility?

The frustrating thing is years and years ago I got it to boot up on an Android tablet based emulator, so I know the images work.

Thanks!

Edit:

More information. The A3000 has 2.04 ROMS, and the boot hard drive loads a 3.1 ROM off disk. Workbench is 40.42. I have tried running the emulator with both 2.04 ROMs and using the kickstart file from the HDD with no luck.

If I wait about a minute I do get a Software Error 8000 0008. With no drives it just gives me the insert disk animation.

Should I be matching my hardware setup with the 2.04 ROM or use the 3.1 ROM?

[Toni Wilen]

Did you configure proper A3000 config? It isn't enough to just set CPU type and select Kickstart. Start with A3000 Quickstart config, then adjust it to add harddrives etc..

[Ionizer]

Originally Posted by Toni Wilen

Did you configure proper A3000 config? It isn't enough to just set CPU type and select Kickstart. Start with A3000 Quickstart config, then adjust it to add harddrives etc..

Thanks, I did use the quickstart then added the drives, still get the Software Failure on trying to boot.

I'm not sure what part is failing, the initial attempt to mount the drive or trying to load the 3.1 kickstart file from disk. I don't see any options to be able to debug what's going on under the hood.

At least it's working with the scsi.device option now. Any options or debugging I can enable?

Edit:

Playing with the debugger I can see it repeats this DMA disk access a dozen times before crashing.

side 0 dma 2 off 0 word 0000 pt 0000256A len 9A9E bytr 8000 adk 1500 sync 4489

I'm guessing... "len 9A9E" is the length of the transfer and "pt 0000256A" is the destination? I don't think I'm reading it right. I can't find much documentation on the debugger commands and output format.

[Toni Wilen]

KS shouldn't do any floppy disk DMA transfers if drive is empty. (But make sure DF0: is enabled because otherwise you'll get long delay when KS tries to access non-existing disk. KS expects that DF0: exists)

Do you get CLI screen if you boot without startup-sequence? If yes, you probably have some device/driver/something on your boot image that crashes if some expansion hardware is missing etc..

[Ionizer]

Originally Posted by Toni Wilen

KS shouldn't do any floppy disk DMA transfers if drive is empty. (But make sure DF0: is enabled because otherwise you'll get long delay when KS tries to access non-existing disk. KS expects that DF0: exists)

Do you get CLI screen if you boot without startup-sequence? If yes, you probably have some device/driver/something on your boot image that crashes if some expansion hardware is missing etc..

DH0 exists and is empty.

I tried booting with no startup-sequence, but get the same result. A near instant crash.

I assumed the DMA breakpoints would catch hard disk activity but I guess that's just for floppies? It's been a while!

Been trying to step through the code but not having much luck so far in figuring out what's happening. Still relearning exec and how the 68k series works.

I remember the jump table offset is at $00000004 so that's a start...

After the Software Error I can find the RDSK entries for all three drives in memory, so I know it is getting that far. I'm assuming the crash is executing the custom filesystems, but hard to tell.

Execbase at 0x078007F8
Current:
07803278: TASK 'exec.library'
Ready:
Waiting:
07809488: TASK 'SCSI handler'
Waiting signals: c0000000
SP: 078098b8 PC: 00f89780
07808850: TASK 'scsi.device'
Waiting signals: e0000000
SP: 0780883c PC: 00f88b7c
078184B8: TASK 'console.device'
Waiting signals: f0000000
SP: 078184a8 PC: 00f929ca
07807082: TASK 'input.device'
Waiting signals: 00000010
SP: 0780808c PC: 00f82e9a
07803278: TASK 'exec.library'
Waiting signals: 00000010
SP: 07802fc0 PC: 7fff0000

[Toni Wilen]

Does it still crash if you disable all partitions in early boot menu? If not, try all combinations to narrow down if the cause is specific partition.

Also mount the drive using UAE controller, enable logging, boot. Check the log, perhaps partition table logging shows something interesting.

Another possibility (that can accidentally happen if you never changed the hardware): drives might have different filesystems (or different versions) stored in RDB but with same dostype. In this case result depends on behavior of HD controller driver and/or order of drives.

[Ionizer]

Originally Posted by Toni Wilen

Does it still crash if you disable all partitions in early boot menu? If not, try all combinations to narrow down if the cause is specific partition.

Also mount the drive using UAE controller, enable logging, boot. Check the log, perhaps partition table logging shows something interesting.

Another possibility (that can accidentally happen if you never changed the hardware): drives might have different filesystems (or different versions) stored in RDB but with same dostype. In this case result depends on behavior of HD controller driver and/or order of drives.

Thanks.

It's trying to boot from the WB_2.x: partition that causes the crash. Even with all other partitions disabled with the boot menu. There is only one filesystem stored in the RDB for that drive.

It can mount 2 of the 3 drives, but crashes if it tries to boot from the boot drive. That has two partitions, WB_2.x: and DH0: neither of which mount. DH1: and DH2: from drives 2 and 3 mount if I boot from a floppy image.

It only crashes when trying to boot from WB_2.x:

I've used a program, called SCSIMounter to mount the two images after a floppy boot but it fails silently.

For logging do you mean the checkbox "Create winuaelog.txt log"? I set up the UAE controller to boot from but the winuaebootlog.txt file shows nothing about mounting drives.

Frustrating as I know I got this to work in the past on an Android tablet. Just zero luck after weeks of poking at it.

Still trying to work with the debugger but just can't tell where it crashes. I don't have a way to really know what it's doing at each stage.

[thomas]

IIRC muFS does not encrypt files. You can disable it simply by setting the partition back to FFS. Then you can access the files from any other boot drive.

The usual Amiga debugging should be done, too: hold down both mouse buttons after reset, boot without startup-sequence, enter set echo on and execute s:startup-sequence. Then you can follow each command as it is executed and find out which one crashes.

[Ionizer]

Originally Posted by thomas

IIRC muFS does not encrypt files. You can disable it simply by setting the partition back to FFS. Then you can access the files from any other boot drive.

The usual Amiga debugging should be done, too: hold down both mouse buttons after reset, boot without startup-sequence, enter set echo on and execute s:startup-sequence. Then you can follow each command as it is executed and find out which one crashes.

It still crashes with the startup sequence disabled, so whatever is happening is before that point.

I'm not ENTIRELY sure what filesystem is being used here. I think it's some combination of two of them. These are strings found in the filesystem stored in the RDB with a DOS type of 0x6d754146 (muAF) and a length of 45056 bytes.

$VER: Ami-FileSafePro 15.9 (30.08.95) written by Michiel Pelt and copyright (c) 1995 Fourth Level Developments
intuition.library utility.library dos.library
Ami-FileSafe V2.01
Ami-FileSafePro V2.2

What is strange is I know I had the multi-user version of this installed, which is "Ami-FileSafeMultiuser 15.9 (30.08.95)" but the filesystem seems to be already pointing to the non-MU version. Ugh, I wonder if years past I already tried to switch back to the non multi-user version.

I set it back to FFS but the drive won't mount, says Not a DOS disk, but I suspect that's because I am actually using Ami-FileSafe which is not compatible with FFS.

Is there a way to figure out the DOSType of a filesystem in L: by looking at the file?

[thomas]

If it's AFS you have to use AFS, it does not work with FFS. You didn't mention AFS before. You talked about muFS, not muAF.

Originally Posted by Ionizer

Is there a way to figure out the DOSType of a filesystem in L: by looking at the file?

It does not work like this. The DosType is something you give to it. It's good to use meaningful values so that you don't confuse them. And some file systems give special meanings to certain values. But other than that you are free to choose.

The important part is that the DosType of the file system matches that of the partition. The DosType connects a file system to a partition. If the boot partition has an unknown DosType, this could be the cause of your crash. Especially as the crash happens before startup-sequence.

[Ionizer]

Originally Posted by thomas

If it's AFS you have to use AFS, it does not work with FFS. You didn't mention AFS before. You talked about muFS, not muAF.



It does not work like this. The DosType is something you give to it. It's good to use meaningful values so that you don't confuse them. And some file systems give special meanings to certain values. But other than that you are free to choose.

The important part is that the DosType of the file system matches that of the partition. The DosType connects a file system to a partition. If the boot partition has an unknown DosType, this could be the cause of your crash. Especially as the crash happens before startup-sequence.

I am trying to remember how all this works.

I created a mountlist for the boot partition and after unmounting the drive, I can manually successfully mount it now. and verify that the filesystem is correct, Ami-FileSafeMultiuser 15.9 (30.08.95).

So progress of a sort, I know the drive images are fine.

I just can't boot from it. What is odd is there is one filesystem on the RDB but it's the non-multiuser version of AmiFileSafe. That could be the issue, but I am unsure how to change this without destroying the drive.

Ok.. while writing this reply I replaced the filesystem in the RDB with the correct one and now it's booting.

No idea why the image had the wrong filesystem, I must have messed with it in years past and forgotten.

Thanks for all the help!

[thomas]

Originally Posted by Ionizer

What is odd is there is one filesystem on the RDB but it's the non-multiuser version of AmiFileSafe. That could be the issue, but I am unsure how to change this without destroying the drive.

In order to not destroy the drive you should make an image file and act on that. WinUAE's Add Harddrive page has a "create harddisk image file" button. Once you have a file, you can easily make as many backup copies of it as you need.

To change the file system, run HDToolbox, select the drive, go to Partition Drive, Advanced Options, Add/Update. Delete the file system which is in there, add Ami-FileSafeMultiuser and give it the right DosType.

Then select the boot partition, go to Change and check that it has the same DosType. Do not change anything else.

Save changes and reboot. That's it.

[Ionizer]

Originally Posted by thomas

In order to not destroy the drive you should make an image file and act on that. WinUAE's Add Harddrive page has a "create harddisk image file" button. Once you have a file, you can easily make as many backup copies of it as you need.

To change the file system, run HDToolbox, select the drive, go to Partition Drive, Advanced Options, Add/Update. Delete the file system which is in there, add Ami-FileSafeMultiuser and give it the right DosType.

Then select the boot partition, go to Change and check that it has the same DosType. Do not change anything else.

Save changes and reboot. That's it.

Oh yes, I've been using hard files. The actual drives haven't been powered on in probably 10 years. Not sure they ever will again after all this time especially as my poor motherboard got badly eaten by battery leakage.

It's all working now, thanks to everyone for the suggestions and help.