OSDev.org

Hello everyone, I've been having an issue with my FAT12 driver. I have a function that loads a file into memory at 0x00105000, ReadFile, (this is only for testing purposes please only patronize me about the location if it is a problem) then returns the pointer to 0x00105000 (again the same as before). Of course I load the Root Directory at 0x00100000. I also have other functions like FindFile(looks for a file in the root directory then returns which entry it is), DisplayRootDir(should display all files in the root directory), fgetc (should return the specified byte), and fread(should read bytes and ints then return them). But the only function that works is the LoadRootDir, which you can imagine what it does... The ReadFile function always returns error, FindFile never finds the file, DisplayRootDir displays some random character at the end of all the filenames, and fread always returns some weird values. Here's a picture:


Also if you want to know what the bitmap fields are the type is the file type, size is the size, width and height are what you guessed. Really those are just there to test my FAT12 driver functions and testing how to read a bitmap.

This is probably a piece of information worth noting: I am using the Chapter 20 tutorial from Broken Thorn Entertainment demo. I use the tutorial's demos from Broken Thorn to get a grasp on the subject then I port it to my OS.

Anyway my drivers code is attached. Remember this only works with the Chapter 20 tutorial demo from Broken Thorn Entertainment.

Edit sorry about the driver not being attached. I need to reorganize my os's directory

Does your driver assume that the filename string in the directory entry is 0 terminated? It shouldn't, and from the look of your display routine I'm guessing that at least that does. You should always use only the 11 bytes in the field, because byte 12 isn't guaranteed to be 0.

No, it only reads the first 11 bytes of the entry for the filename.
Oh, and by the way I just actually posted the drivers code now that I finished searching through my os's directory...

Edit: I was able to fix the random characters at the end of the filenames and "No more files." apparently I had to 1 affix a null character to the end of the filename (should of displayed correctly but apparently my DisplayRootDir function adds a random character at the end) and 2 I can't have more then one end of line character at the end of a string (problem with "No more files."). Now the only problems I have left are the FindFile, ReadFile, fgetc, and fread functions.

Edit 2: I added some debug string outputs and there is something clearly wrong here:

By the way the yellow text with white background is me using the highlight button in Vista's snipping tool to show how f***ed up this is.

Also this as a side question anyone know how to convert those padded file names to the ones we've come to know (the ones with the name and extension separated by a period)?

accelleon wrote:Also this as a side question anyone know how to convert those padded file names to the ones we've come to know (the ones with the name and extension separated by a period)?

I believe some people tend to put the FileName and Extension in 1 char array (of 11 bytes?), but you can also split them up in 2 char arrays of e.g. 8 chars and 3 chars. However, I think this will take away the possibility to have a file-extension of more than 3 characters (well, you might still have them but it might divide the extension over the two arrays).

Besides that, I think you could parse the file-name or display it differently to the user as it is on the disk. I think the the actual filenames (as you showed them) are internally different than the ones represented to the user (name.ext).

There are probably many other programmers here who programmed FAT before which can probably give you some better ways .

Creature wrote:I believe some people tend to put the FileName and Extension in 1 char array (of 11 bytes?), but you can also split them up in 2 char arrays of e.g. 8 chars and 3 chars.

FAT Specification - fatgen103.doc wrote:The DIR_Name field is actually broken into two parts+ the 8-character main part of the name, and the 3-character extension. These two parts are “trailing space padded” with bytes of 0x20.

DIR_Name[0] may not equal 0x20. There is an implied ‘.’ character between the main part of the name and the extension part of the name that is not present in DIR_Name. Lower case characters are not allowed in DIR_Name (what these characters are is country specific).

So no, you cannot split the file name in any other way than 8.3 format, with trailing spaces if either the file name or extension are not 8 or 3 characters long respectively.

accelleon wrote:Also this as a side question anyone know how to convert those padded file names to the ones we've come to know (the ones with the name and extension separated by a period)?

Manually - read the filename (first 8 chars) and trim the space (0x20) characters from the end of the file name. Do the same with the extension. Copy to a new character array with a dot between the two for display purposes.

Cheers,
Adam

AJ wrote:Manually - read the filename (first 8 chars) and trim the space (0x20) characters from the end of the file name. Do the same with the extension. Copy to a new character array with a dot between the two for display purposes.

Cheers,
Adam

Are trailing spaces simply not allowed (i.e. what if the user WANTS the last spaces)?

Thanks for the help with my side question. But now its time to discuss the first question I had that's messing up my FAT12 driver . The FindFile and ReadFile functions.

Edit: Ok now I definitely know there is something wrong . I added this code to parse the file names to the format I wanted help with (name.ext) : And it raises a General Protection Fault .

Creature wrote:

AJ wrote:Manually - read the filename (first 8 chars) and trim the space (0x20) characters from the end of the file name. Do the same with the extension. Copy to a new character array with a dot between the two for display purposes.

Cheers,
Adam

Are trailing spaces simply not allowed (i.e. what if the user WANTS the last spaces)?

Then they have to pay Microsoft for LFN and VFAT crap royalties and use that, hehehe.

Hello,

retval is an uninitialized pointer that you are writing to. That is basically the same as asking your code to crash.

If you are just looking for a way to convert a string ("test.txt") to the filesystem format ("TEST TXT") I can post the routine that I use if you like.

I couldn't get my function to work so could you please post yours that way I can try to adapt from that. Mine causes the memory to overlap then writes some junk to the screen.

Hello,

filename - 0 terminated string. Input
fname - 11 character filesystem name. Output. Should be an array of 11 characters. This should be used with the filesystem code in finding files on disk. (Not null terminated)
FNameLength - should be 11. Its the size of the fname buffer. Input

The code is modified a little to make it easier to port. Replace the calls to BmFatalError with your error handling system. The only known limitation is that it does not deal with the case of the filename (thus it must be all caps.) This is easy to fix though.
For example of use: ..Also works for files without extensions (such as directories) and entire 8.3 names ("MYFILE12.TXT" will result in "MYFILE12TXT" as expected by the filesystem)

Hope this helps

neon wrote:Hope this helps

Interesting code, Neon, but you didn't mention a license/public domain/whatever. Is it public domain code?

Troy Martin wrote:Interesting code, Neon, but you didn't mention a license/public domain/whatever. Is it public domain code?

Thanks - its public domain without restrictions of use. I personally do not care much for licensing specific routines of my software. well..except one at this time I suppose.

Thanks alot but don't forget about my original question about my FindFile problem. The drivers code is attached to the first post I will attach the updated code to this post later when I'm finished porting neon's code.

accelleon wrote:The drivers code is attached to the first post

Um, I don't know if you noticed, but it cuts off in the middle of a function... and I can't find any references to most of the functions...