Lately I tried to salvage files from my old Amiga 4000, and came across a somewhat weird file format issue. Specifically it is about Zip drives (the Iomega one's) I used to back up data back then.
My idea is to move sources and documents over to my Linux system, and try the original Amiga stuff in an emulator.

The physical part worked fine so far. I got an AHA-2940 SCSI controller card, a PC it fits in, and the HP-DB50 to DB-25 cable to attach the Zip drive.
The PC (running Linux Mint 20.2) couldn't mount the media, unsurprisingly, so I cloned them with 'dd'. The funny thing is, after inserting the medium (each of them), an icon appeared for a moment as if it was mounted, then it was gone.
This I can explain, I think.

To add some more context, I had most of those 100MB Zip disks re-formatted on the Amiga, as they came DOS pre-formatted.
One of the disks was still in DOS format, which the Linux PC mounted and listed without problems. Only I don't need Borland C 3.1 or some obscure Iomega tools...
If it is relevant, the drive itself was attached to a GVP SCSI controller back then. The Amiga, an EC020 model, came with an IDE drive and controller. I just remember after installing the GVP board, migrating the OS over to the SCSI disk was a bit of a pain, I had to phone the GVP constumer service back then to get it working.

But looking into the image files, I can't really make sense of the format. Following some details.

The very first sector is obviously a FAT MBR, containing "MSDOS6", FAT16, and the 0x55 0xAA identifier at the end.
Of the for partition table entries, all values are zero, except the "number of sectors" for partition 4 (00 00 92 00).

After several sectors containing all zeros, a string "DOS\05" appears at offset 0x04000 (0x44 0x4F 0x53 0x05).
And from offset 0x04200 on, the file is filled with a repetitive "DOS" pattern, perhaps to identify the position from the contents itself. This continues until about the middle of the image, to offset 0x2FFFFFF.

From offset 0x3000000 on it gets interesting. The first two blocks look like file system metainformation to me.
And they seem to contain file names I had noted on the disk, mostly lha archives.
After some blocks with all FF or all 00 data, files containing discernable strings seem to follow. And after the block limit of the last file, the regular formatting patterns of the first half appear.

There is no RigidDiskBlock (RDSK) to be found, and no subsequent partition block (PART).

From what I understand, the Amiga used write the root block of the file system in the middle of the medium, at least for
floppy disks.

Does anybody know this format, or some tool to decode it ?

@codis

If you don't find an answer here, you may try eab.abime.net (hardware and emulation gurus frequent that site).

@codis

There are Dos Drivers to read PC formatted Zip Disks so I just stick to PC Format. They can be read on anything then!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@codis

Quote:

Does anybody know this format, or some tool to decode it ?

This is standard Amiga FastFileSystem with directory cache on a partition which does not cover the entire disk. It begins in sector 32 (offset 0x4000) and probably ends before the end of the disk as well.

The area before the partition was never touched by AmigaDOS, so the information you find there (like the MS-DOS partition table) is of no use for recovery.

The partition was not mounted by a partition table on the disk itself (RDSK) but by mountlist or DosDriver on your boot disk. If you still have a backup of your Amiga boot disk it would be very helpful to see this mountlist or dosdriver.

In order to mount the Amiga partition you have to know the start and end sectors. The start sector is 32, the end sector is yet unknown. The location of the root block could give a hint. As you noted it is located in the middle of the partition. It is a sector which begins with the bytes 00 00 00 01 and contains the volume name of the disk and no other readable strings.

You might also find that the DOSxDOSxDOSx partern ends at the last sector of the partition, if it has not yet been overwritten by user data.

I believe that RDBRecov2 should be able to find the partition data. But it is an Amiga program, you have to run it inside an emulator with the disk image added as a harddrive.
https://thomas-rapp.hier-im-netz.de/downloads/rdbrecov2.lha

_________________
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de

@thomas

Well, that makes sense.

Quote:

The partition was not mounted by a partition table on the disk itself (RDSK) but by mountlist or DosDriver on your boot disk. If you still have a backup of your Amiga boot disk it would be very helpful to see this mountlist or dosdriver.

I currently don't have access to the Amiga, as it is stored a few hundred miles from here...
But reading out the boot drive is on my list. I thought I did id during my last visit, taking out the IDE drive, attaching it to an IDE-to-USB adapter, and clone it with dd ... only to find out later this was not the boot drive
I had moved boot to the GVP drive, but failed to remember such details after 30 years ...
The IDE drive has a proper RDB block, and two partitions. One for data, and the other assigned to a GoldenGate 386SX card, with a Win3.1 installation.

Quote:

You might also find that the DOSxDOSxDOSx partern ends at the last sector of the partition, if it has not yet been overwritten by user data.

Yes, exactly.

In the meantime, I could try to trim the FAT16 part from the image.
As said, I'm working with disk images right now.
Or try the emulator apprach you suggested.

As a side note, I made another copy from one of the Zip disks with the disk tools in an "Amiga Forever" installation. Except of a prepended 32k (64 block) additional header, the images are identical. And the emulator can't mount it in that form.

In a short test, I wrote some test code to read in a sector at offset 0x03000000, and interpreted it as AFFS rootblock. Everythings matches and is valid according to the documentations I found. So far, so good.

According to the same documentations, the "DOS\05" found at offset 0x4000 means AFFS with Dir-Cache and internationalization. Not sure how many tools support that.
Up to now I tried a Linux tool ("amiga_recovery" at github), but it fails because the Zip disks have no Amiga RDB and partitions.

I will try the mentioned Amiga route, and update this thread ...

@codis

Quote:

In the meantime, I could try to trim the FAT16 part from the image.

Indeed, if you remove the unused sectors from the beginning and the end of the image, the remaining part should mount successfully as AFFS or even as a hdf in an emulator.The challenge is to find out the exact amount of unused sectors so that the middle of the image exactly hits the root block.


Quote:

Except of a prepended 32k (64 block) additional header, the images are identical.

I don't think that Amiga Forever adds an additional header. It's rather so that you did not dd the entire disk in Linux.

It is quite easy to check: a ZIP 100 disk has 196608 sectors, so the image size should be 100,663,296 bytes. If your image files are smaller, then you did not image the entire disk. If your files are larger, then there is some header.

_________________
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de

@thomas
> I don't think that Amiga Forever adds an additional header. It's rather so that you did not dd the entire disk in Linux.

The size difference is exactly 16384 bytes (so 16k, not 32k - but 32 blocks).
The larger copy was made with the "Amiga Forever" tool, the smaller one with 'dd' - both directly from the SCSI device.
After this prepended 16k in the Amiga Forever copy, I can see the same FAT16 MBR the other file starts with. Not that it matters much, just saying.

By the way, my first attempt with the Amiga tool (RDBRecovery) failed. It couldn't find any partitions in the image file. Probably because there are none - at least no Amiga partitions. As said, there is no RDB or partition header to be found in these images.
I think the Amiga might have treated Zip disks as a giant floppy, connected to SCSI ...

@codis

Quote:

In the meantime, I could try to trim the FAT16 part from the image.

Linux can read Amiga filesystems, too. You can mount disk image with mount options "-taffs -oloop". It seems to be possible to specify an offset and a sizelimit ("-o loop,offset=123456,sizelimit=8765432").

Possibly need to do "modprobe affs" first.

Then in Linux you could write a little script with a loop increasing the offset until mount succeeds.

@Georg

Well, a lot of guesswork was involved here - because I had tried that already some time ago.
The point is, the offset to _what_ should I specify for setting up the loop device ?
The actual offset of the FFS rootblock obviously not, that didn't work. Nor to the preceeding blocks.
A hunch told me to try the location of the "DOS�5" string I found in the zip-disk image (@0x4000), and voila :

fm@fm-HP-ED-800:~/dev/rpi/zip$ sudo losetup -o 16384 /dev/loop3 /home/fm/temp/zipdrive/zd_R1.img
fm@fm-HP-ED-800:~/dev/rpi/zip$ sudo mount -t affs /dev/loop3 /media/fm/amidisk
fm@fm-HP-ED-800:~/dev/rpi/zip$ ls /media/fm/amidisk/
DVL_arc DVL_arc.info GnuC2.5.8.Lha HD_2_arc HD_2_arc.info LHX WB3.0_arc WB3.0_arc.info
fm@fm-HP-ED-800:~/dev/rpi/zip$ ls -l /media/fm/amidisk/
insgesamt 0
drwx------ 1 root root 0 Jul 5 1997 DVL_arc
-rw------- 1 root root 628 Jul 5 1997 DVL_arc.info
-rwx------ 1 root root 11870945 Feb 1 1996 GnuC2.5.8.Lha
drwx------ 1 root root 0 Jul 5 1997 HD_2_arc
-rw------- 1 root root 628 Jul 5 1997 HD_2_arc.info
-rwx------ 1 root root 35312 Apr 15 1994 LHX
drwx------ 1 root root 0 Jul 5 1997 WB3.0_arc
-rw------- 1 root root 628 Jul 5 1997 WB3.0_arc.info
fm@fm-HP-ED-800:~/dev/rpi/zip$

Unfortunately the formatting options of this forum seem somewhat limited, this the shell output is not so easily deciphered.
But that worked.
Thanks !

Last edited by codis on 30-Mar-2025 at 02:52 PM.

@Thread



Quote:

There are Dos Drivers to read PC formatted Zip Disks so I just stick to PC Format. They can be read on anything then!

Weirdly it needs to be formatted in FAT12 (MS-DOS) not FAT16 as originally bundled for my DOS Driver to see PC Zip Disks!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

My Amiga, which came with CrossDos, could read the and write the Zip disks as they came preformatted.
Although it's now 30 years, I'm sure I had reformatted most of them because of the annoying 8.3 limitation of those FAT versions.