Each square of the board doesn't even need a byte, only a nibble. There are 6 piece types so that fits in 3 bits, plus one for color. If you pack two of those nibbles per byte then you can do it in 32 bytes plus the castling and en passant bits.
Video Chess uses the lower nibble of 64 bytes for the board, and the upper bits of those for various other purposes.
You actually could condense further than that. Build the storage as an array of pieces rather than squares, so 32 storage locations. Each of those locations needs only 6 bits to indicate that piece's current square. (And even only 5 bits per bishop, although pawns need three more bits each to handle promotion and to which piece type.) Of course, writing an engine for that data structure is much more cumbersome, since it can't look at a square to find what piece is on it, instead it has to iterate over all the pieces to find out what's on a square.
> writing an engine for that data structure is much more cumbersome, since it can't look at a square to find what piece is on it, instead it has to iterate over all the pieces to find out what's on a square.
Ignoring the move generation, this is also way harder to render the output with. The Atari 2600 has very few cpu cyles per line, and I don't know if you'd have enough time to iterate through all the pieces to see if and where they are on the current line, even given that several video lines are spent on each chess rank.
Yeah, of course. I wasn't speaking of the Atari or any computer in any practical sense, just hypothetically about the minimum storage.
Of course it's possible to go even more than that - enumerate every reachable position (so remove situations like a pawn on the first or eighth rank, kings adjacent or in some check situation that couldn't have happened, pawns in positions that would require more captures than there are enemy pieces missing from the board, etc) and assign them all an index number, which requires log N storage size. And of course it would be practically impossible to do anything computationally with positions stored like that.
This link estimates an upper bound of around 10^46 reachable positions, so log2 of that would be only about 150 bits to enumerate them all.
You won't. You have 76 CPU cycles per line. Searching through a 32 byte array for a match - 4-5 cycles just to load the byte from the array if you use zero page indirect addressing.
Video Chess uses the lower nibble of 64 bytes for the board, and the upper bits of those for various other purposes.
You actually could condense further than that. Build the storage as an array of pieces rather than squares, so 32 storage locations. Each of those locations needs only 6 bits to indicate that piece's current square. (And even only 5 bits per bishop, although pawns need three more bits each to handle promotion and to which piece type.) Of course, writing an engine for that data structure is much more cumbersome, since it can't look at a square to find what piece is on it, instead it has to iterate over all the pieces to find out what's on a square.