I have now added support for this to ChessV 2.  Silly me, I thought this would be pretty simple.  All directional movement is handled by lookup from a big multi-dimensional array indexed by direction number and square number that gives the number of the next square in that direction or -1 if it leads off-board.  I thought I could just update that lookup table to accomodate the board wrap and I'd be set.  But, of course, there were several additional challenges:

First, I had infinite loop problems since a Rook on an open rank can just zoom around and around.  Needed to add a check to internal move generator to stop generating whenever a piece returns to its starting square.  (And not generate that move, since null move is not allowed.)  This check will slow down, at least microscopically, move generation in all games, most of which don't have this problem, but that's life.  ChessV is not built for efficiency.  And Circular Chess is another example of a game with this problem.

Next, I had an issue with the move generator generating duplicate moves.  If a Rook is on a rank that is empty except for one enemy piece, that piece can be captured by two different paths.  So the generator adds the capture twice.  This is not good.  So I had to build deduplication capability into the move generator.  This is slightly expensive, so it is controlled by a Game flag and only enabled for games that need it.  (This could be an issue for more than games with funky boards - for example Switching Chess - a1 switches with b1 is really no different than b1 switching with a1.)

Then, a related problem with having multiple paths between squares, is that this could totally screw up the Static Exchange Evaluator (SEE).  A fix for that would be complex and I wouldn't want to complicate the regular SEE engine so it would require building a special one just for this game. And I'm not doing that.  So I switch it off.  There was already a game flag for disabling SEE since other games I've implemented are not compatible - most notably, anything with a Chinese Chess Cannon (or similar piece.)  I've tried to think about how SEE should be reprogrammed to support cannon-type pieces, and it is a fascinating problem, but it makes my head hurt.  Quite frankly, I don't think I'm smart enough to ever get that right.  Fortunately, SEE is a nice trick but not really necessary.  Quiescent search solves the same problem, and more accurately, just far more slowly ...

Ok, at this point, we have a functioning, accurate program.  But there are still problems with the positional evaluation functions.

Piece-Square-Tables (PST) encourage pieces to move into the center, but this game has a radically different concept of "center."  Instead of a square, the center is a stripe accross the center of the board.  Fortunately, I could adjust which squares were considered part of "small center" and "large center" and that fixed the PSTs intelligently.  It also fixed the consideration of which squares are elligible for knight outposts. This change was clean and worked out well.

Then there is pawn structure evaluation, and this is important.  There are a number of issues, for exmaple ... We penalize isolated pawns. But in this game, an A-pawn is not isolated, even if there is no B-pawn, if there is an H-pawn.  I was able to fix pawn structure issues pretty cleanly.

Then there is end-game evaluation.  King+Rook is no longer a win, it is now a draw.  So I fixed that, although in a cheesy way. (I also fixed this issue in Omega Chess while I was at it.)  But this "fix" was not good, and there are probably other changes required ... can KBB or KBN mate?  Probably not.  But that's enough for now. I expect I've already reached the point where this will be the world's strongest Cylindrical Chess engine (not that I've looked) and this is a lot more time than I had planned to invest in this.