Okay, so I did some preliminary work on it this morning.
It's been about a decade since I last looked at low level partition info on IDE drives, so it took a while for it all to come back.

It's not rocket science, but it's not trivial either.


Basic partitioner strategy:

Use GETGEO or IDENTIFY to get drive C/H/S + LBA parameters
Do standard CHS geometry scaling to taste, and to comply with expectations for Large LBA geometries.

Heck, just get them from my /proc/ide/hd?/geometry entries.. duh!.

Construct partition tables as follows:

Extended partition /dev/hda1:
/dev/hda5: 16MB root (or maybe 32MB to give room for more apps)
/dev/hda6: 64MB swap

Other primary partitions:
/dev/hda2: 32MB spare (normally, nothing uses this space)
/dev/hda3: 16MB dynamic data (or maybe double it?)
/dev/hda4: many GB everything else

The current partitioner likes to round up partitions to even cylinders, but we really do not need to do this if we don't want to, apart from padding the MBR out to a full 63 sectors for universal compatibility.

Anyone have any comments or important things to point out or suggest?

In particular, would the player binary actually use a larger dynamic data area?? I know we could put longer bookmarks (and a longer current running order) in their if we left enough space, and we already know how to patch the player binary for those..

Cheers