FAT16 help needed!!!

If you create an empty FAT volume on your system and mount it on a win box, doe it appear? If not, make an empty FAT volume on the win box and compare it with yours bit-by-bit. Also run chkdisk/scandisk on it and windows might be able to tell you what's wrong.

Once you get an empty FAT volume to mount with no errors, write a trivial file. Again, if it won't mount or show, write the same trivial file on the win box and compare the 2 volumes. If it seems to work, be sure to run chkdisk/scandisk to make sure.

Ask these questions, in this order:

Is there a partition table on the disk, or did you use a "big floppy" format? You should have an MBR on the card, i.e. it should be a "hard disk" format card, not a "big floppy".

Does Windows mount the volume successfully? No-> Check the MBR contents. If OK, check the LBR contents. Run Scandisk on the volume and in particular look at what volume size is reported.

Yes-> Start at the directory entry.

Is the file in the root directory? If not, you're running before you can walk. Create an empty entry in the root directory.

I also suggest using an old version of Norton Disk Editor for DOS to inspect your card. It has an inbuilt FAT filesystem implementation and it's most useful for browsing sectors in a "cooked" mode, interpreting raw data as FAT, directory entries, LBR, MBR, ...

It works either way. In fact, Windows, when formatting a CF card does not write an MBR but starts with the partition directly (i.e. the big floppy aproach is used).

Markus

It may work either way under some circumstances, but _all_ embedded equipment uses the hard disk type format for removable media. Why behave strangely when there is a known standard to follow?

I respectfully disagre.

I just checked. My digital camera (a cannon PowerShot S45) which I'd say should run under the term "embedded equipment" definately formats the media the "big floppy" way. It accepts both formats which is wise cause both formats IMHO seem to be widespread used. Then, considereing that Windows formats CF's the big floopy way I really think that it's not a good idea to exclusively support MBR based media in an embedded system cause the likelyhood that an end user formats a CF in a Windows system is quite big. To make things even worse, XP defaults to format CompactFlash cards with FAT32 ! That's the main reason why I also support FAT32 in my FAT implementation (which btw. supports partitioning/formatting both kind of media). This implementation does not support long filenames but ignores them if present.

Markus

How did you determine this, btw? It is not uncommon for Windows hosts to show you only the int 24/25h "personality" of an inserted card, i.e. no int 13h support - which means you can never see the MBR. Example of drivers that work this way: Microtech DPCM-USB multi-card reader/writer, but I'm aware of several others that have the same behavior (just don't have their names to hand).

In testing literally hundreds of digital cameras for interoperability, we never encountered one single camera that uses "big floppy" format.

No! If I format a card on my Windows systems, if it already has an MBR Windows will leave the MBR there. That is with either a PCMCIA adapter or a USB adapter. If I destroy a card - zero it out - and then use Windows to format it, the behavior depends on what I'm using to connect the card to the Windows PC (and also the Windows version):

• PCMCIA card - Needs to be partitioned with FDISK and then formatted. Haven't attempted this under NT-class Windows.

• USB reader with its own format utility - Right-clicking the volume in My Computer and selecting Format invokes the OEM's format utility. An MBR is automatically created.

• USB reader without a format utility, using generic storage class driver - It winds up as a USB-floppy type volume.

Various other points come to mind, also, e.g. - will not work on systems using True-IDE boot mode. Your point about be liberal with what you accept and constrained with what you generate is well taken, but in this case the conservative approach is _always_ to write MBR-style cards.

Further, some formats (e.g. SSFDC) have hard-encoded in the format specification a requirement to precede the filesystem with an MBR. Truly, it is much safer to work with "hard disk" format.

I assume this made-up "big floppy" and "hard disk" terminology serves mainly to confuse everyone?

It's perfectly valid to have a fixed disc (media type 0xF8) with or without a partition table,and not unusual at all to have a partition table with just one of the four entries occupied - pointing to a fixed disc FAT image anyway,which always seemed a bit pointless to me.

Conversely the other media type bytes (0xF9/FC/FD/FE/FF) for removable media can't have partition tables.It's just that flash cards from cameras etc are considered by Windows et al as a 'fixed disc' but which just happens to be removable! Sprow.

Not really. The technical distinction is, of course, presence or absence of an MBR on the medium. Actual floppy disks (5.25", and their not quite so floppy 3.5" offspring) never have an MBR, which is why the no-MBR way of creating a file system on a medium gained the nickname "big floppy". No confusion to be found here.

OTOH, the format with a partition table and a single primary partition being referred to as "hard disk" is indeed a bit of a misnomer. It had better be called the "partitioned" style of formatting a medium.

Is it? So how would the system know not to treat the bytes in the relevant part of the boot code of a big-floppy medium as a partition table?

... but since each of those is inherently tied to a particular floppy disk format / density /sidedness, they may not be available for use with other formats that don't match any of the ancient floppy disk formats.

Windows indeed allows this superficially self-contradictory state of affairs --- but some other systems, at least traditionally, didn't. If memory serves, OS/2 was one system that strictly refused to treat anything but "big-floppy" formatted media as removable. At that same time, Windows didn't recognize anything big-floppy at all, causing never-ending friction between these two systems, e.g. for users of MO drives.

You assume wrong, Grasshopper. It's a reasonable qualitative way to differentiate between the two format methods, and it was at one stage the way DOS programmers talked about the two. I believe the first time I read it in a formal document was an Iomega whitepaper.

That's really irrelevant; the number of entries in the ptable is neither here nor there. The point is, embedded devices generate and look for a partition table (in the main). It's a better interoperability decision to format the card with an MBR and a single partition spanning the entire disk, than simply to commence with an LBR at physical sector 0. Yes, either are validly formatted disks, but there's a range of circumstances under which the latter won't work, whereas the former is the "industry standard" for cases where there is no actual formal standard.

And in some cases, flash media format specifications MANDATE that an MBR be present; in which case, it is perfectly legal and expected that if you put your MBR-less card in a compliant appliance, that appliance will fall over and die.

Note that every consumer appliance with removable flash and a reformat command in firmware that I have tested (which is a *large* number) generates an MBR.

You can be practically certain that /dev/sda1 will mount (if sda is a card-reader containing a card formatted in a piece of consumer electronics). You can be practically certain that /dev/sda won't.

What is the media type for 'big floppy' ??

( I never heard of it )

Partition tables and boot code can be distinguished between with cunning software,signature bytes,presence/absence of zeros in important places,partition table offset pointing to valid BPB of course,etc...

Of the last 3 camera cards I looked at in depth,2 were partition table-less,1 did have a partition table with only one entry,all 3 then had a single FAT volume with media type 0xF8 and all opened fine in Win98.

Though I would expect to find partition tables on the majority of flash cards it's not mandatory.

Absolutely.Still waiting to get my hands on some 8" discs to try out... Sprow.

No wonder. You were right, I'm wrong! I was fooled by my dump utility/usb card reader which did not showed me the MBR!!!

I this time took the ocasion to througly test, this time using my own embeded hardware where I have full control about which sectors are read etc. (as oposed to the USB card reader in my PC) and it turns out that you are 100% right with all you said. The only thing you did not mentioned is that windows XP defaults to formatting FAT32 on Cf cards. That's probably important to know.

I can't remember anymore why I was asuming that many CF's would not have an MBR. Basically I first implemented my FATxx software with only MBR in mind and then stumbled across a card that did not had this and as a result implemented my FAT library to also accept "big floppy" kind of media (along with FAT12). Maybe this is what triggered me here. Well, I'm sorry and thanks for pointing all this out so clearly!

Happy new year!

Markus

If you read the FAT spec (fatgen102.pdf, "FAT: General Overview of On-Disk Format") I think that you will find that Microsoft decides to format using FAT12/16/32 based on the capacity of the device. IIRC, by default, anything larger than 512MB is formatted as FAT32, less than 512MB and greater than 4MB it is formatted as FAT16, and less than 4MB it gets a FAT12.

Dear Sean,

during the past year I worked on a project of porting the FreeDOS' filesystem to an embedded architecture. The first thing I did was to compile the fs under MSVC, then I did many tests on a floppy, formatted FAT16 as a 128 kilobytes removeable media. I used a boot sector created by Windows, because I wanted the fs be able to read and write files just like Windows. Initially I had the same problems you had:

Windows was able to see the files but each time I tried to open them up, it turned out to be empty. After several hours spent using WinHex, I found that if I add an empty sector (512 bytes) between the last sector of the root directory and the first data sector, Windows was able to read correctly those files. It's still a mystery for me....

I just downloaded fatgen102.pdf and I promised my self to read it carefully in order to see if what I did is correct or not.

Enrico

Dear Sean,

during the past year I worked on a project of porting the FreeDOS' filesystem to an embedded architecture. The first thing I did was to compile the fs under MSVC, then I did many tests on a floppy, formatted FAT16 as a 128 kilobytes removeable media. I used a boot sector created by Windows, because I wanted the fs be able to read and write files just like Windows. Initially I had the same problems you had:

Windows was able to see the files but each time I tried to open them up, it turned out to be empty. After several hours spent using WinHex, I found that if I add an empty sector (512 bytes) between the last sector of the root directory and the first data sector, Windows was able to read correctly those files. It's still a mystery for me....

I just downloaded fatgen102.pdf and I promised my self to read it carefully in order to see if what I did is correct or not.

Enrico

Dear Sean,

during the past year I worked on a project of porting the FreeDOS' filesystem to an embedded architecture. The first thing I did was to compile the fs under MSVC, then I did many tests on a floppy, formatted FAT16 as a 128 kilobytes removeable media. I used a boot sector created by Windows, because I wanted the fs be able to read and write files just like Windows. Initially I had the same problems you had:

Windows was able to see the files but each time I tried to open them up, it turned out to be empty. After several hours spent using WinHex, I found that if I add an empty sector (512 bytes) between the last sector of the root directory and the first data sector, Windows was able to read correctly those files. It's still a mystery for me....

I just downloaded fatgen102.pdf and I promised my self to read it carefully in order to see if what I did is correct or not.

Enrico

Look at the allocation mechanism. An allocated block is, IIRC, at least 1k, not 512. You are probably simply running into failure of the translation between block number and the disk address, involving 0 based or 1 based numbering.

BTW, one copy of your message will normally suffice :-)

Any chance you could GPL the version of embedded Freedos that you created?

Not long after getting the uFlashTCP and ordering the 8 Meg M-Systems chip I got FreeDOS to run on it, so it's a good selling point Jim. I thought FreeDOS was already GPL'd though. But my configuration was done using the M-Systems chip as I don't have write access to the 512K chip. If I did then I imagine that the same technique would work for that. IIRC I just used the files from the FreeDOS download. If you're interested, I can do a short write-up on the few steps.

Dilton