Enter Your Reply The Comment You're Replying To H. G. Muller wrote on Fri, Apr 3, 2009 09:48 AM UTC:The WinBoard move parser actually does accept a very wide range of move notations, and Xa1-b2 is one of those. This is fine in 'perfect' Chess variants like Shatranj, Xiangqi, and Shogi, where the only capture is replacement capture, and moves never have side effects. But in FIDE Chess there ae already problems with castling and e.p. capture: somewhere along the line from PGN to display it should be known that Ke1-g1 means that a Rook should be moved as well, and that on e5xf6 a Pawn should be removed from f5. In the ChessLive! viewer I solved those problems by recording such moves in the intermediate format as multiple move: in general a move can consist of multiple (fromSquare,toSquare) pairs, and for 0-0 I write, say, e1g1h1f1, and for e5xf6 e.p. I write e5f5f5f6 (or f5f6e5e6). This can keep the viewer totally dumb. But you can't expect that information to be present in the original PGN. it seems that you have a different concept of PGN from what it really is already: you would not find a move like Xa1-b2 in any PGN file, as PGN is supposed to use Standard Algebraic Notation (SAN), which would list the move as Xb2. Or, if there are multiple X on the board that could move to b2, like (preferably) Xab2 or X1b2. I guess in theory Xa1b2 could occur, if there are three pieces of type X, located on the intersections of two files and two ranks (e.g. Na1, Nc1, Na5) that could all go to the same square (b3). So it could occur even in FIDE Chess. But I have never seen it happen. So in SAN normally a full specification of the from-square is absent, even if the instance gnerating the SAN is totally unaware of how the pieces move, so that it has to add a disambiguating rank or file indicator for every move with a piece of which there are multiple copies on the board. This puts the burden on the SAN parser to keep track of the board state, so that it knows where each piece of a given type is located. Anyway, the sitution in WinBoard is that it currently supports 22 different piece types (for both black and white), that you can assign any letter to. If you switch legality testing off, the pieces can move any way you want. (With legality testing on, it has a pre-programmed notion of how every piece should move.) Each piece has a standard pictogram representation on the screen, but this can be overruled as well by user-provided graphics. Board size is adjustable, but in practice the SAN parser does not work beyond 12x10 yet (e.g. it does not understand double-digit rank indicators). PGN defines a variant tag (e.g. [Variant 'xiangqi']). The WinBoard convention for variant naming is such that you can use non-standard board sizes by prefixing them to the variant name, and that a catchall name 'fairy' is defined, where every piece can partcipate. So you could specify 6x6_fairy for a mini-variant on a 6x6 board including Elephants and Achbishops, or even 6x6+4_fairy if it was a Shogi-like variant with piece drops and holdings for 4 piece types. Edit Form You may not post a new comment, because ItemID Javascript cv does not match any item.