Now you've got me thinking. Four bits per piece is enough to say what each piece is and whether it's moved yet. Three bits per piece and a 22 bit bit field covers every piece (on both sides) that we actually care about having moved -- since only kings, pawns, and rooks care about their first move.

But both of these options are only optimizing for data size. They'd be unwieldy to actually work with because most architectures aren't really designed for splitting up bytes arbitrarily like this. Plus you'd need some representation of the board itself, with a pointer on each space with a piece on it to the appropriate data.

A better option if we're trying to keep data usage to a minimum while not wasting cycles slicing and dicing arbitrary bits might be 8 bits per piece. That's enough to tell you what piece it is, whether it's moved or not, what square it's in, and still have a bunch of states and a whole bit left over. The extra states are kind of wasted, but you could use the high bit as a flag to say whether it's a white or black piece. Store the whole thing in a linked list and you need 32 bytes to store your entire game state, with the storage needs decreasing as pieces are removed from the board.