The maxfid patch doesn't work quite that way; you can't set it for a particular number.

What happens is that the size of the dynamic data partition isn't absolutely set -- it depends on the size and geometry of your particular hard drives. Kind of like a rounding error, the actual partition size is going to be at least the set size, but there might be a little bit of extra space. It's like asking for 1.5 plates of food and the chef giving you two, because he only makes whole plates. If you want 0.8 plates, you get one, if you want 1.1 plates you get two. Integer units of measure. It's not rounding, and not truncating, I forget the exact term.

Newer and larger harddrives have larger minimum units for allocation. (Don't forget that the factory default drive sizes were like 8 & 12 gigs.) So when the disk is partitioned, in order to get the expected 16MB of disk space the partition may actually be 18MB or 21MB or 32MB or whatever it happens to be based on the geometry of that particular drive. (These numbers aren't real, but should serve as examples. Cylinders, heads, sectors, blocks, &c. are more detailed than I care to deal with right now, and then there's all the IDE dynamic addressing stuff.)

Mark's maxfid patch first figures out exactly how big your particular dynamic data partition is And then it overwrites the player binary file with a number that corresponds to the size of your dynamic data partition. What gets overwritten is a number that is based on a true 16MB partition, and takes into account how the dynamic data partition is allocated. So if you have a 22MB instead of the safe-to-assume 16MB, then you have 6 more MB's worth of fids, how ever many fids that ends up working out to.

When you run the program it will tell you how many fids there's room for. And that's the number you get. With an 80GB drive, you're likely to be fine, since you're not that far over the default max.

Bitt will likely post in a few minutes correcting all of the errors and assumptions I've made in this post.

--Nathan