how does fat16 work ?

Search for the FAT16 driver for MSX-DOS2 from Okei. It's on the interwebs somewhere and I seem to remember that the latest version came with source code...

The most useful thing would be to figure out how to r/w SDHC cards (4G & up), so that support for those cards might be added to existing SD card interfaces. Basically: how SDHC cards differ from non-SDHC cards, and what would be required to use them (pure software issue? hw modification needed?). Not because we need the storage space, but because non-SDHC (up to 2G) may disappear out of your local computer shop soon.

Anything else is just re-inventing the wheel... which of course is your business but kind of a waste.

then i wonder how fat16 work , i understand that command2.com has to be modified so it can understand FAT16 description on the disk, but in order to go beyond 32megs i believe the diskrom has to be modified also.
I've been using FAT16 (in DOS2) with Sunrise CF interface, Erikie's SD interface and the 1chipMSX, in all cases with unmodified MSXDOS2.SYS, and a small patch to COMMAND2.COM to make free space calculation (what is shown on each "DIR" command) show the correct result. But that COMMAND2.COM patch is not needed for correct operation AFAIK (works fine unpatched), it's more a cosmetic issue.

The FAT16 driver from Okei is what makes FAT16 work with Sunrise CF and Erikie's SD interface, the 1chipMSX doesn't need it - it has FAT16 support built in.

Should i deal with bigger sectors in 16bits numbering by modifying the media descriptor for the disk ?
The media descriptor has no role anymore in determining the exact disk parameters. And for DOS2 sectors are defined to be always 512 bytes (probably hardcoded in a number of places). So forget that.

or deal with 512byte sector with more than 16bits for r/w routine (in that case fat16 may not be enough and fat32 is required ? )
Ehmm, FAT12/16/32 refers to the number of clusters in a FAT disk, not the # of bits for raw disk I/O (although there is a relation of course when disks get bigger). Nor do you need FAT32 to access >2G disks: you only need FAT32 to work with >2G partitions.

if i modify r/w routine to take 24 bits sector number and modify command.com accordingly , i must define these routines on other entry points , i wonder how compatible is this , would it only work with my modified command.com ?
The only thing that would need modification is your disk interface's built-in physical I/O driver code. AFAIK there exist some applications (MultiMente?) that have been modified to use FAT16 disks. Which would mean there is some sort of 'standard'. Also there are some sources & programmer info for the low level driver code of several disk interfaces which support >2^16 sector disks. I suggest you check some of those driver sources to see how the parameters are passed.

I still wish all of this would be built into a generic, updated version of DOS2 (the ROM part). So that driver code (different for each interface) would do only 2 things: detect cards, and r/w raw sectors. With the generic code (same for all interfaces) doing everything else: FAT12 / FAT16 detection, how to assign partitions to drive letters, how to translate sector I/O requests to raw sector r/w's, etc.

Right now every interface has its own partition-table formats, its own manner of detecting partition types & assigning those to drive letters, its own tools for initializing cards etc. That is just ANNOYING , very user-unfriendly, and a (big!) unnecessary duplication of effort.

Erhm, FAT12/16/32 refers to the number of bits per FAT entry, not to the number of clusters in the FAT.
Technically yes (shame on me ), but it's essentially the same thing: FAT12 -> 12 bits/FAT entry -> max. just under 2^12 FAT entries, with each FAT entry referring to a cluster of [sectors/cluster] sectors. FAT16 -> 16 bits/FAT entry -> just under 2^16 FAT entries. Etcetera...

In theory you could just increase that sectors/cluster number. It would increase wasted space, which is hardly an issue these days. But:

• The max. number of clusters also limits the number of files & directory entries. With bigger partitions, you're likely to have more of those as well. There's little point in creating a 5 GB. partition if you can only store ~4000 files (FAT12) on it.
• There's some commonly used maximums for the [sectors/cluster] value (around 64 sectors, 32 KB usually). Go beyond those, and you're likely to run into (unexpected?) compatibility problems when accessing that partition on other systems.

thanks for the answers , i know fat <>sector number and there is limitations from fat map , if 512 byte is hardcoded as sector size and bios routine deals only with 16bits sector address then you are stuck to 32megs, so you need fat16 modifs in msxdos and also bios modifs in diskrom.

@nyyrikki that is exactly what i was looking for !

i believe sdhc needs a different init sequence just like mmc has different init than sd.
then , the sdhc does not deal with addresses in byte but in fixed block size of 512byte.
so they can be 512 times bigger than sd's.
i read it here :
http://elm-chan.org/docs/mmc/mmc_e.html
look for : "How to support SDC Ver2 and high capacity cards"

the point is that the basic diskio has to be aware of this so it can shift or not address by 9 bits.
so the init phase on msx boot and diskrom init should store somewhere whether it is sd or sdhc.
i dont know where to put that bit in a safe area ...

i have some ideas : using a register in the interface sinceit has other periphs as well there is a
good chance to find an unused reg in those periphs...

well i am not sure this area is not used for some other sw ... i meant i already have other periphs on same sd board : i could find some place on already existing hw.

thinking it twice , the 23 bits adressing allows only 4 gigs , not a lot more th an 2gigs , so fat32 instead of fat16 does not bring huge improvement....

by the way i am targeting only dos1 for time being , it fits well with msx1 and turbor's, but not very well with msx2's, and less hardware for rom + mapping.