FAT12, FAT16 and longfilenames on GP32


Active Member
Apr 16, 2003
There seems to be a lot of confusion about FAT12, FAT16 and long filenames in releation to SMC and the GP32. I decided to pick my brain (and the internet) to come up with some answers.

The GP32 supports FAT12 and FAT16. The 12 and 16 refer to the number of bits used for adressing a cluster on the disk (SMC). So FAT12 can adress 4096 clusters and FAT16 ~65000. For this reason FAT12 is normally only used for smaller (<16MB) volumes giving a cluster size of 4 KB.

When you format your SMC with GPLink however it will use a cluster size of 16KB. For this reason a 32MB card still gets formatted with FAT12. A 128MB card gets formatted with FAT16. (I don't have a 64MB card)

This can waste a lot of space if you have a great number of files on your SMC because a 16KB cluster size means that the file size is always a multitude(?) of 16KB. So a 12 byte highscore file takes up 16KB disk space, a 50Kb file takes up 64KB (4*16) diskspace.

When you format you SMC from Windows with a cardreader Windows will put FAT16 on it with a 2KB cluster size. So if you have a lot of small files on your SMC you can put more files on the same SMC when formatted with windows using a cardreader.

Long filenames
FAT12/16 only support filenames with the 8.3 format. Long filenames are supported by MicroSoft through VFAT. VFAT (Virtual FAT) is not a file system but a driver that sits between Windows and FAT12/16. VFAT allocates additional directory blocks to hold the long filename. So where a 8.3 filename takes up 1 FAT entry a long filename takes up several.

It first creates the file with the 8.3 filename and then creates additional 0-byte dummy 'files' which have the attributes DHSV (Directory, Hidden, System, Volume) set. These files are ignored by non VFAT systems because the volume attribute can never be set together with one ot the three other attributes.

So this make it possible to format your SMC with GPLink and then with your cardreader have Windows put long filenames on it. Your GP32 won't see the long filenames (unless the program your running has VFAT support) but when you copy files back to your PC with a cardreader the long filenames are still intact.

I don't know exactly when Windows makes a VFAT entry. Obviously it does this when the filename is longer than the 8.3 format. I think it also makes a VFAT entry when the filename is within the 8.3 limit but you use 'strange' characters in you filename (spaces) or even use lowercase letters in you filename.

Another thing I noticed is that FAT12/16 only support one datetime field (date last changed). When you copy a file to your SMC with a cardreader this file automatically has a creation, modification and last accessed date. I think this information can only be stored in a VFAT entry. This would mean that Windows *always* makes a VFAT entry for every file. Even if your file fits perfectly in the 8.3 filename specification.

As explained before a long filename consists of the real file and several 0-byte dummy files containing the long filename. VFAT makes sure that when a file(name) gets changed, moved or deleted that the short and the longfilename get changed.

On a system that doesn't support VFAT however only the short filename will be changed, moved or deleted. So while the (V)FAT still contains the longfilename the (short filename) file itself may already be deleted. This can lead to a damaged FAT and an unreadable SMC on your GP32. I still don't know when this happens.

My estimated guess is that this does not happen imediatley (because the file is still there, only the FAT entry is removed) but happens when the GP32 starts to write files over the sectors containing the deleted file.

More info
For checking most of the things mentioned above I used the excellent WinHex.

For more information about VFAT,FAT16,FAT12,SMC and long filenames check the following links:



Micro$oft is just 2 lazy :angry: all they make is "virtual" things, because there is this VFAT and also Win 3.*/9x/Me is really graphical DOS (virtual stuff, not real). Micro$oft is EVIL!!!!!!!
Micro$oft is just 2 lazy  :angry:  all they make is "virtual" things, because there is this VFAT and also Win 3.*/9x/Me is really graphical DOS (virtual stuff, not real). Micro$oft is EVIL!!!!!!!
I second that. :p

Lets make Bill Gates (Spit) use his own operating system. :D

Last edited by a moderator:
This is really helpful...although I didn't know that the 'dummy' files were moved along with the normal ones by PC-Link. This explains why some DOS apps work with long filenames.

Pinned ... not sure if it needs to be moved though.
And also, more importantly for me, why whenever I try to delete small files from my SMC writer, they're still there as 0kb ones - its the f***ing vfat thing that's been left there for some reason. Possibly also the reason why small files sometimes refuse to copy properly... this is very very interesting, and potentially extremely useful.