Reading PC-DOS 1.0/1.1 FAT12 File system.

[Matriks404]

Is there a program to read/extract files from PC-DOS 1.0/1.1 image? (which is early FAT12 fs).

[OCTAGRAM]

I would try to either mount image in DOSBox or open file in 7-zip. 7-zip (at least, the one bundled with FAR Manager 3.0) can open .iso, FAT16 .img, Mac OS X, so maybe FAT12 too.

[Archenemy]

Any file extracting program will help you extract the files.

[Battler]

- Archemeny: This is an old version of FAT12 that differs from the well-known version, so most software won't be able to read it.

[Matriks404]

Neither 7-ZIP or WinRAR can open this file.

ReadMe for PC-DOS 1.1 file tells this:

.IMG format.
Will NOT be read by WinImage as uses non-standard boot sector.
Needs special flag on Bochs.
Should be able to be read by DOS and most BIOSes.

Maybe, there is a way to replace boot sector, with standard one?

[Archenemy]

Power iso may help extract fat12.

[charrison82]

Power ISO will work as I have used it for such zipped files old OS files I wanted to go back and check out.

[Matriks404]

Power ISO will work as I have used it for such zipped files old OS files I wanted to go back and check out.

Nope, it says:

---------------------------
PowerISO
---------------------------
C:\Users\Marcin\Desktop\oldOS\IBMDOS11.img



The file format is invalid or unsupported.
---------------------------
OK
---------------------------

[os2fan2]

You replace the first 32 bytes of the floppy with something later (ie dos 2 image), and it opens like an ordinary floppy.

I wrote a rexx script to do this. You may need to fix the string "call stream diskimg, 'c', 'open both' " to match your version of rexx. Basically, you write the 32-bit nldr to the start of the diskette, and it will open in any diskette tool. Write the string oldr to restore the original boot strap.

This works with other DOS1 era stuff, like Personal Editor 1.0 and Fixed Disk Organiser.

Code: Select all

/* rexx */
/* a program to fix the boot sector of a dos 1 160 diskette */

nldr = 'EB 3C 90 49 42 4D 20 32 2E 30 20 00 02 01 01 00'x
nldr = nldr || '02 40 00 40 01 FE 01 00 08 00 01 00 00 00 00 00'x

oldr = 'EB 2F 14 00  00 00 60 00  20 37 2D 4D  61 79 2D 38'x
oldr = oldr || '31 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00'x

parse arg diskimg
call stream diskimg , 'c', 'open both'
call charout diskimg, nldr, 1
call stream diskimg, 'c', 'close'

regina fix160.rex dos110.img

[Matriks404]

You replace the first 32 bytes of the floppy with something later (ie dos 2 image), and it opens like an ordinary floppy.

I wrote a rexx script to do this. You may need to fix the string "call stream diskimg, 'c', 'open both' " to match your version of rexx. Basically, you write the 32-bit nldr to the start of the diskette, and it will open in any diskette tool. Write the string oldr to restore the original boot strap.

This works with other DOS1 era stuff, like Personal Editor 1.0 and Fixed Disk Organiser.

Code: Select all

/* rexx */
/* a program to fix the boot sector of a dos 1 160 diskette */

nldr = 'EB 3C 90 49 42 4D 20 32 2E 30 20 00 02 01 01 00'x
nldr = nldr || '02 40 00 40 01 FE 01 00 08 00 01 00 00 00 00 00'x

oldr = 'EB 2F 14 00  00 00 60 00  20 37 2D 4D  61 79 2D 38'x
oldr = oldr || '31 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00'x

parse arg diskimg
call stream diskimg , 'c', 'open both'
call charout diskimg, nldr, 1
call stream diskimg, 'c', 'close'

regina fix160.rex dos110.img

Thank you very much Works as it should.

[JustZisGuy]

Please keep in mind that modified image files are no longer genuine.

The technically correct thing to do would be to contact the vendor of your image management tools (such as WiniImage) and have them add support for DOS 1.x formats.

[os2fan2]

WinImage actually reads this bit to figure out how many sectors etc the diskette has.

What we do is to provide WinImage enough information where it needs it to read the diskette. The files come off exactly as they would in a DOS 1 boot.

[Chorg]

Beware !

When modifying bytes in the disk image to make it readable by WinImage (for instance, by adding a BPB), you are overwriting data or code in the boot sector. Depending on the DOS variant, this could make the disk image unbootable and make it hang the computer (or stop the emulator) when booted.

Furthermore, altered disk images are no longer genuine and loose their historical value. They could be misleading for computing historians. Therefore, they may only be good for an experiment and should always be discarded immediately after.
Please understand that, depending on the DOS variant, the way that your script is restoring the image to a fixed byte string may leave the image altered as well.

The only suitable way to read a disk image is to use a software natively able to understand its format.

[Matriks404]

Beware !

When modifying bytes in the disk image to make it readable by WinImage (for instance, by adding a BPB), you are overwriting data or code in the boot sector. Depending on the DOS variant, this could make the disk image unbootable and make it hang the computer (or stop the emulator) when booted.

Furthermore, altered disk images are no longer genuine and loose their historical value. They could be misleading for computing historians. Therefore, they may only be good for an experiment and should always be discarded immediately after.
Please understand that, depending on the DOS variant, the way that your script is restoring the image to a fixed byte string may leave the image altered as well.

The only suitable way to read a disk image is to use a software natively able to understand its format.

For me, I think it doesn't matter. I used this trick only to extract and read files by comparison program to compare PC-DOS 1.0 and PC-DOS 1.1 to show differences between these two. For testing I use separate image with emulator.

[JustZisGuy]

In theory there is little reason why WinImage couldn't add a fallback method for disks that lack the BIOS Parameter Block data. It would have to determine the format based on the image file size or other data, ideally mimicking how later MS-DOS figures it out.

[Matriks404]

Any idea how to open MS-DOS Compaq 1.12 disk image? It shows files in WinImage (using above trick) but it doesn't want to extract any files, like it doesn't know where to look to find data.

[tarlabnor]

Any idea how to open MS-DOS Compaq 1.12 disk image? It shows files in WinImage (using above trick) but it doesn't want to extract any files, like it doesn't know where to look to find data.

The easiest way to extract files from DOS 1.x images:
1. mount such image in any emulator (PCEm, 86Box, PCE, MESS etc.)
2. copy all needed files to the virtual hard disk or virtual floppy with more "common" format (360 kb or bigger)
3. extract anything from it using WinImage or any other similar tool

[Tadrio]

I think the reason why WinImage won't read DOS 1.x disks is not related to the missing MBR flag, but that they have a different physical layout than later DOS versions. Single-sided disks for DOS 1.x were formatted to 160k capacity, while later DOS versions formatted them to 180k. This is because DOS 1.x formatted disks to 8 sectors a track (8 × 40 tracks × 512 Bytes per sector = 160 kB), while DOS 2.x and later used 9 sectors per track (9 × 40 × 512 Bytes = 180 kB). WinImage gets confused because it assumes that 5.25" PC disks should be in the DOS 2.x format.

It doesn't seem possible to convince WinImage to open these images, but you can with an alternative called DiskExplorer. It generally opens many images that WinImage doesn't, because it supports automatic detection of the layout and file system parameters. However, for DOS 1.x disks, the detection fails, so you'll have to choose "Manual FD" mode and set the following parameters, according to DOS 1.x FAT12 standards:

FAT type: FAT12
FAT offset: 512 (since the first sector is the MBR)
FAT quantity: 2 (two copies of the FAT)
FAT size: 512 (each FAT is 1 sector long)
Root offset: 1536 (sum of everything from before: 512 + 2×512)
Data offset: 3584 (+2048, the fixed length of the root directory)
Cluster size: 512
Total clusters: 320 (160 kB / 512 B)

Then you should be able to explore the image and extract/inject/edit files at will.

[Battler]

It has nothing to do with the MBR, and all to do with the fact the BPB in the boot sector is simply missing (because it was, if I recall correctly, introduced in DOS 2.x), causing anything that detects the floppy geometry based on the BPB to fail to detect it properly.

[Tadrio]

It has nothing to do with the MBR, and all to do with the fact the BPB in the boot sector is simply missing (because it was, if I recall correctly, introduced in DOS 2.x), causing anything that detects the floppy geometry based on the BPB to fail to detect it properly.

Yes, sorry for the confusion. For some reason I thought an earlier reply linked this to the missing 0x55AA flag at the end of the MBR, which is why modern systems and emulators usually won't boot the floppies, but has nothing to do with why tools like WinImage won't open it. But I must've confused this with another discussion, I can't see any reference to it above. Anyway, technically it does have to do with the MBR, because the BPB is part of it.

The switch to 9 sectors probably coincided with introducing the BPB, which is why those images are more difficult to get to open in these tools. It makes sense, I guess, there's not much use for the BPB if the OS only supports one layout anyway. That's why I assumed the failed auto-open was related to the sector count.

There really isn't any reason why image tools should require the BPB, the layout is very easy to detect even without it. At least DiskExplorer allows manual entry of the parameters, which WinImage doesn't.

[JustZisGuy]

Alternatively you can replace the first few bytes of the boot sector with the following for each disk type:

Code: Select all

160K: (163,840 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 01 01 00    .'.IBM  2.0.....
00000010  02 40 00 40 01 FD 01 00-08 00 01 00 00 00 00 00    .@.@............

320K: (327,680 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 02 01 00    .'.IBM  2.0.....
00000010  02 70 00 80 02 FF 01 00-08 00 02 00 00 00 00 00    .p..............

180K: (184,320 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 01 01 00    .,.IBM  2.0.....
00000010  02 40 00 68 01 FC 02 00-09 00 01 00 00 00 00 00    .@.h............

360K: (368,640 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 02 01 00    .,.IBM  2.0.....
00000010  02 70 00 D0 02 FD 02 00-09 00 02 00 00 00 00 00    .p..............

Some PC BIOSes require the 0x55AA signature in order to boot a disk, but it is not needed to read it.

And yes, for varying reasons there are indeed some 180k and 360k (DOS 2) disks with faulty or missing BPB information.

[Matriks404]

Alternatively you can replace the first few bytes of the boot sector with the following for each disk type:

Code: Select all

160K: (163,840 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 01 01 00    .'.IBM  2.0.....
00000010  02 40 00 40 01 FD 01 00-08 00 01 00 00 00 00 00    .@.@............

320K: (327,680 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 02 01 00    .'.IBM  2.0.....
00000010  02 70 00 80 02 FF 01 00-08 00 02 00 00 00 00 00    .p..............

180K: (184,320 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 01 01 00    .,.IBM  2.0.....
00000010  02 40 00 68 01 FC 02 00-09 00 01 00 00 00 00 00    .@.h............

360K: (368,640 bytes)
00000000  xx xx xx 49 42 4D 20 20-32 2E 30 00 02 02 01 00    .,.IBM  2.0.....
00000010  02 70 00 D0 02 FD 02 00-09 00 02 00 00 00 00 00    .p..............

Some PC BIOSes require the 0x55AA signature in order to boot a disk, but it is not needed to read it.

And yes, for varying reasons there are indeed some 180k and 360k (DOS 2) disks with faulty or missing BPB information.

Yeah, this works very well, Thank you

[Battler]

There really isn't any reason why image tools should require the BPB, the layout is very easy to detect even without it.

It can me ambiguous... an 1.23 MB or 1.28 MB image could either 8 1024-byte (the Japanese format uses 77 such tracks formatted at 360 RPM) sectors per track or 16 512-byte sectors per track. And for smaller images, there's the question of sides too - there's two 360k formats, both at 9 sectors per track - one is the common format with 2 sides and 40 tracks, while the other is less common format with 1 side and 80 tracks. Without a BPB, it's not easy to disambiguate in these cases.
Add to that the possibility of trunacted images (ie. those that has unused sectors at the end simply cut off from the file), which give using the BPB even more of a reason.

[Tadrio]

It can me ambiguous... an 1.23 MB or 1.28 MB image could either 8 1024-byte (the Japanese format uses 77 such tracks formatted at 360 RPM) sectors per track or 16 512-byte sectors per track. And for smaller images, there's the question of sides too - there's two 360k formats, both at 9 sectors per track - one is the common format with 2 sides and 40 tracks, while the other is less common format with 1 side and 80 tracks. Without a BPB, it's not easy to disambiguate in these cases.
Add to that the possibility of trunacted images (ie. those that has unused sectors at the end simply cut off from the file), which give using the BPB even more of a reason.

Absolutely, and I would say that a good image tool should be able to handle all that and everything else imaginable.
I was more thinking about some heuristics to determine things like sector size, FAT offset and root directory offset by looking at the actual data, in the example that I could tell the tool that I know there's some type of FAT on there. Sometimes when I'm unsure about the format of an image, I open it in a hex editor and it's usually very easy to see what's going on, so it should be possible to improve automatic detection somewhat that way. If there still remain a few possibilities, it wouldn't even be a big deal to exclude the wrong ones by simply parsing the entire image using all possible parameters and see which ones make sense.

I wonder though about your 1s/80t or 2s/40t example, would it even be discernible or make a difference when it comes to raw image files? I was under the impression that at least in the IBM case, sectors are just sequentially numbered regardless of whether they're distributed over one or two sides, so that the number of sides is effectively hidden, and handled by the drive.

[Battler]

- Tadrio: For an image editor, it wouldn't really make a difference, however when you are trying to get the correct geometry from a floppy image for an emulator, the difference does matter as the sector ID's have to be right, and they include a side field. Though even with an image editor, it's important it gets things right so that if you happen to change the boot sector, it can write back the correct parameters rather than incorrect ones.