FAT16 help needed!!!

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


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

( I never heard of it )

Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote in message news:<bst5l7$2e6$1@nets3.rz.RWTH-Aachen.DE>...
> Sprow <news@sprow.co.uk> wrote:
> 
> > It's perfectly valid to have a fixed disc (media type 0xF8) with or
> > without a partition table,
> 
> 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?

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.

> > Conversely the other media type bytes (0xF9/FC/FD/FE/FF) for
> > removable media can't have partition tables.  
> 
> ... 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.

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

>> 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
>
>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 wonder. You were right, I'm wrong! I was fooled by my dump
utility/usb card reader which did not showed me the MBR!!!

>> 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
>
>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 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

Markus Zingg wrote:


> The only thing you did not
> mentioned is that windows XP defaults to formatting FAT32 on Cf cards.
> That's probably important to know.

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.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144

"... abstractions save us time working, but they don't
   save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1

Sean Whitesell wrote:

> My code is writting data to a CompactFlash card.  I can see the data
> with WinHex. But, windows does not acknowledge the file.  I'm using
> the same functions as examples that work elsewhere in the project.  I
> need help analyzing the FAT info to see where the problem is so I know
> where the problem lies in the code.  I have read the FAT specs and
> compared my file to good files and the differences are just not
> evident.  Any help on this would be most appreciated.  I'm really
> under the gun here.
>
> Sean W.

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

Sean Whitesell wrote:

> My code is writting data to a CompactFlash card.  I can see the data
> with WinHex. But, windows does not acknowledge the file.  I'm using
> the same functions as examples that work elsewhere in the project.  I
> need help analyzing the FAT info to see where the problem is so I know
> where the problem lies in the code.  I have read the FAT specs and
> compared my file to good files and the differences are just not
> evident.  Any help on this would be most appreciated.  I'm really
> under the gun here.
>
> Sean W.

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

Sean Whitesell wrote:

> My code is writting data to a CompactFlash card.  I can see the data
> with WinHex. But, windows does not acknowledge the file.  I'm using
> the same functions as examples that work elsewhere in the project.  I
> need help analyzing the FAT info to see where the problem is so I know
> where the problem lies in the code.  I have read the FAT specs and
> compared my file to good files and the differences are just not
> evident.  Any help on this would be most appreciated.  I'm really
> under the gun here.
>
> Sean W.

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

Enrico Migliore wrote:
> Sean Whitesell wrote:
> 
> > My code is writting data to a CompactFlash card.  I can see the
> > data with WinHex. But, windows does not acknowledge the file. 
> > I'm using the same functions as examples that work elsewhere in
> > the project.  I need help analyzing the FAT info to see where
> > the problem is so I know where the problem lies in the code.  I
> > have read the FAT specs and compared my file to good files and
> > the differences are just not evident.  Any help on this would
> > be most appreciated.  I'm really under the gun here.
> 
> 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.

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 :-)

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Enrico Migliore wrote:

> 
> Sean Whitesell wrote:
> 
> 
>>My code is writting data to a CompactFlash card.  I can see the data
>>with WinHex. But, windows does not acknowledge the file.  I'm using
>>the same functions as examples that work elsewhere in the project.  I
>>need help analyzing the FAT info to see where the problem is so I know
>>where the problem lies in the code.  I have read the FAT specs and
>>compared my file to good files and the differences are just not
>>evident.  Any help on this would be most appreciated.  I'm really
>>under the gun here.
>>
>>Sean W.
> 
> 
> 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:


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

"Jim Stewart" <jstewart@jkmicro.com> wrote in message
news:bt280g$f11@library2.airnews.net...
> Enrico Migliore wrote:
>
> >
> > Sean Whitesell wrote:
> >
> >
> >>My code is writting data to a CompactFlash card.  I can see the data
> >>with WinHex. But, windows does not acknowledge the file.  I'm using
> >>the same functions as examples that work elsewhere in the project.  I
> >>need help analyzing the FAT info to see where the problem is so I know
> >>where the problem lies in the code.  I have read the FAT specs and
> >>compared my file to good files and the differences are just not
> >>evident.  Any help on this would be most appreciated.  I'm really
> >>under the gun here.
> >>
> >>Sean W.
> >
> >
> > 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:
>
>
> 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