• Please review our updated Terms and Rules here

Reading files from DEC Rainbow drive image

S

shirsch

Veteran Member
Joined
Aug 17, 2008
Messages
872
Location
Burlington, VT
I read the ST-412 (RD51) drive into a sector image using Dave Gesswein's mfmemu and would like to loop mount the MSDOS partition under Linux and read out the files. So far I've been able to decipher the Rainbow partitioning scheme (described in the DEC MS-DOS manual), determined that a +7 skew was used and wrote a quicky utility to de-interleave the data. I can see a valid FAT table and root directory. Problem is that Linux FAT support and the various utilities I've tried want to see a conventional MBR and partition boot sector. DEC went their own way and there is nothing resembling the usual 512 byte blocks ending with 55AA. So unless I'm missing something obvious it looks like I need to synthesize these bits and prepend them to the start of the FAT.

After a bit of study I'm almost ready to put the pieces together. The point I'm stuck on is that I need to know these bits of information about the filesystem:

  • Sectors / Cluster
  • # of FAT copies
  • Max # of root directory entries
  • Sectors / FAT copy
I cannot find anything in the DEC partition preamble that shows this information. Since the Rainbow boots I'm wondering if there is an MS-DOS utility that I can use in the running system to show me this information. All the digging I've done simply turns up various methods to extract the information from MBR and boot sector - a Catch-22 situation. Any DOS gurus here have a suggestion?
 
At least later chkdsk gave sectors/cluster. Number of FAT should be able to figure out from if you find duplicate sets of FAT data. If you do have 2 copies should be easy to figure out the size. Is root directory contiguous or do you need to use the FAT to find all the blocks?
 
Be careful here ...

An MBR is used on a partitioned disk. It's sector 0 of the disk and it defines the partitions.

A Boot sector is the first sector of each partition. The boot sector should have a "BIOS Parameter Block" that defines the layout of the FAT filesystem on the partition. That 25 bytes or so defines the sector size, number of FAT copies, total number of sectors, number of root directory entries, etc. That sector should also have the 55AA signature at the end. The BPB starts at byte 12 - you have three bytes for a JMP instruction, 8 bytes of OEM ID, and then the BPB.

The lack of a 55AA signature at the end of the sector should not be an issue. But not having a BPB or having something weird there is going to mess up the Linux VFAT driver. This is why you can't mount old DOS 1.x diskettes using VFAT - there is no BPB on those and I don't think the VFAT drivers bothers to read the media descriptor byte that is in the first FAT cluster entry.

What flavor of DOS was this thing supposed to be compatible with? Are you trying to loopback mount the DOS partition, or are you accidentally loopback mounting the entire device? (The later doesn't work; you need to loopback mount filesystems/partitions, not entire partitioned devices.)

Can you share the first 40 bytes of the first sector of the DOS partition? It would be interesting to see if there is a BPB there.
 
The BIOS is able to create the proper data structures when the Rainbow comes up, but I cannot find anything on disk that looks enough like a 'volume boot record' to make Linux happy. Unless I missed something it's inferring or reading the parameters from other sources (e.g. DPD blocks). I think the implementation predates what we think of as MS-DOS disk structure.
 
djg said:
At least later chkdsk gave sectors/cluster. Number of FAT should be able to figure out from if you find duplicate sets of FAT data. If you do have 2 copies should be easy to figure out the size. Is root directory contiguous or do you need to use the FAT to find all the blocks?
Click to expand...
After properly de-interlacing the image the root directory is contiguous. From the start of the first FAT to the end of data storage it's a textbook DOS volume. Just needs a block that looks like a VBR in front and all is well. The VBR is only there to make Linux happy and mount it.
 
Apologies if the following is all stuff you're aware of or have thought of!

From a quick look in the right places I found that Sydex released a tool called "RainDOS" which I gather is for mounting DEC Rainbow floppies under DOS (unless I got it the wrong way around and it's for mounting DOS floppies on a Rainbow!). Perhaps this might be a fallback if you can't get the hard disk image mounting to work.

If you can figure out how to make a suitable VBR, rather than have to edit it into your disk image, you can use Linux's dmsetup command to make a device mapper device that can provide a view of a virtual disk that concatenates ranges from other files. Of course it has a bit of a learning curve.

Have you considered trying to create a new DOS filesystem of the same size to steal its VBR?

shirsch said:
The point I'm stuck on is that I need to know these bits of information about the filesystem:

  • Sectors / Cluster
  • # of FAT copies
  • Max # of root directory entries
  • Sectors / FAT copy
I cannot find anything in the DEC partition preamble that shows this information. Since the Rainbow boots I'm wondering if there is an MS-DOS utility that I can use in the running system to show me this information. All the digging I've done simply turns up various methods to extract the information from MBR and boot sector - a Catch-22 situation. Any DOS gurus here have a suggestion?
Click to expand...
This probably won't help, but PC Tools DiskEdit (I tried the one in version 9.0) seems to show all of this information:
Options -> Drive Info shows Sectors / Cluster
F7 to select FAT, then Options -> Object Info shows number of FAT copies and sectors per FAT
F6 to select directory, then selecting the root directory, then Options -> Object Info shows maximum entries

I have no idea if this reads it from the disk though, and the box says it needs an IBM or 100% compatible machine, so perhaps that rules it out (but then it's such a big set of tools, maybe some of them don't have quite the same requirements).
 
You must log in or register to reply here.
Back
Top