smatovic wrote:MicroMaxs Castling Handling is still a little mystery for me...i have to take a closer look into your code. I use the idea of a king capture engine also for castling. If the lastmove was a castling (therefore the castling flag ) i check if the affected squares are attacked.
Micro-Max uses the same system. The square skipped by the King on castling is passed as e.p. square E to the daughter node. There a check is made if the e.p. square is occupied (to distinguish it from genuine e.p.; after castling the Rook stands there), and if it is any capture to a square between E-1 and E+1 is considered a King capture, and causes an immediate return with a +INF score. (This caused a bug in early uMax versions, because the capture to the old from-square of the King is a capture to an empty square, so that Pawns refused to make it, and you were allowed to casle out of a Pawn check. So I had to move the test up to before testing the validity of Pawn moves, which now also considers a Pawn non-capture to any of these squares as a show stopper. This turned out to be without consequence, as when you have a Pawn non-capture to one of the criticl squares, you will always have at least one Pawn capture to nother critical square. Come to think of it, this probably fails in variant berolina for Fairy-Max...)
I suppose you have not enough RAM to keep move lists. So when you use the triply nested loop for move generation, and immediately search every move as it is generated (as uMax does), you would have to store the state of the move generator (the three loop indices) as well. Now the inner and outer loop indexes are the to- and from-squares themselves, but you still would have to store the ndex of the loop over directions.
An alternative I thought about for when RAM is extremely scarce is to encode moves as 1 byte, using a lookup table (which can be in ROM) to transte the byte code to a piece number plus step vector. On undo the to-square could then be recovered from the piece list, and the from-square calculated from it with the aid of the step vector. Another lookup table, also indexed by the move code, could give you the code for the next move of this piece.