As expected, the test version does recognize 0xC partitions and pass them to the camera. I almost didn't get to posting a confirmation given the amount of changes needed, the code that DataGhost posted (which should clearly work), and the fact that you almost certainly tested it yourself by forcing a 0xC ID. But, it is always better to close the loop on something like this.
I will post some benchmarks on the wiki later. I have been running a bunch to directly compare formats (i.e. using the same card with different format types).
Handing off partitions to the camera leads to a general question as to what partition types we should hand to the camera. Currently, properly ID'ed FAT32 and FAT32 LBA partitions are handed to the camera. At the moment, without thinking about it much, I like it this way. I routinely use Linux for partitioning, because after seeing the structures Windows has used on some extended partitions, I don't trust Windows to KISS. Thus, I can have full control over what the ID will be (should I choose). However, most users will be using Windows. When not using extended partitions, Windows generally Keeps It Simple and partitions using primary partitions. The various format methods in Windows appear to set the ID to type that was actually formatted.
However, the camera, and Windows, recognize partitions with other ID types. They should recognize them as it gives an opportunity for them to, at least, format the partition to a type that they can use. For Windows, drivers can be loaded that allow it to use types it does not understand natively (e.g. Linux ext2/3 for Windows:
Ext2 Installable File System For Windows (Read/Write),
Explore2fs (Read, multiple formats),
DiskInternals Linux Reader (Read)). I expect the camera to just be able to format a partition of a type it does not read/write.
The question for CHDK is: What partition types should CHDK pass to the camera? This can be rephrased into: Do we want to A) Do it Right[sup]tm[/sup]; B) emulate how the Camera would do it; C) emulate how Windows would do it; D) pass all partitions properly ID'ed that the camera can natively read/write; E) any one of many possibilities; D) many I have not thought of or enumerated.
For instance, should we pass "Hidden" partition types? I have never seen Windows pay attention to the "Hidden" bit (0x10). Should we? Personally, at some point, I might want to hide a partition from the camera. I expect this currently works, as only types 0xB and 0xC are passed.
The cameras, probably, can re-format any partition type resulting in a new ID type being written to the partition table.
The cameras, probably (untested), can read/write:
0x01 FAT12
0x04 FAT16 <32M
0x06 FAT16 (known to read/write and format to this type)
0x0b W95 FAT32 (known to read/write and format to this type)
0x0c W95 FAT32 LBA (known to read/write and format to this type)
0x0e W95 FAT16 LBA (this might not work)
0x11 Hidden FAT12
0x14 Hidden FAT16 <32M
0x16 Hidden FAT16
0x1b Hidden W95 FAT32
0x1c Hidden W95 FAT32 LBA
0x1e Hidden W95 FAT16 LBA
Personally, off the top of my head: I would definitely add 0x06 to the list. I would not add the "hidden" types. I would, probably, also add 0x0e to the list.
On the other hand, a good argument can be made for passing the camera the fist partition (actually the 2nd valid partition) with a non-zero ID type. This would, probably, be the closest to the current camera operation. It can reasonably be argued that the goal is merely to hide the first, small FAT16 partition and that beyond that is the responsibility of the person setting up the partitioning. This argument assumes that the multi-partitioning support is, and will remain, very basic (i.e. nothing beyond hiding the first, small FAT16 boot partition, no swapping multiple partitions).
