Changes

! !! A !! B !! C !! D !! E !! F !! G !! H!! !! !! !! !! !! !! !!

| '''! 8''' || '''70''' || '''71''' || '''72''' || '''73''' || '''74''' || '''75''' || '''76''' || '''77''' || 78 || 79 || 7A || 7B || 7C || 7D || 7E || 7F

| '''! 7''' || '''60''' || '''61''' || '''62''' || '''63''' || '''64''' || '''65''' || '''66''' || '''67''' || 68 || 69 || 6A || 6B || 6C || 6D || 6E || 6F

| '''! 6''' || '''50''' || '''51''' || '''52''' || '''53''' || '''54''' || '''55''' || '''56''' || '''57''' || 58 || 59 || 5A || 5B || 5C || 5D || 5E || 5F

| '''! 5''' || '''40''' || '''41''' || '''42''' || '''43''' || '''44''' || '''45''' || '''46''' || '''47''' || 48 || 49 || 4A || 4B || 4C || 4D || 4E || 4F

| '''! 4''' || '''30''' || '''31''' || '''32''' || '''33''' || '''34''' || '''35''' || '''36''' || '''37''' || 38 || 39 || 3A || 3B || 3C || 3D || 3E || 3F

| '''! 3''' || '''20''' || '''21''' || '''22''' || '''23''' || '''24''' || '''25''' || '''26''' || '''27''' || 28 || 29 || 2A || 2B || 2C || 2D || 2E || 2F

| '''! 2''' || '''10''' || '''11''' || '''12''' || '''13''' || '''14''' || '''15''' || '''16''' || '''17''' || 18 || 19 || 1A || 1B || 1C || 1D || 1E || 1F

| '''! 1''' || '''00''' || '''01''' || '''02''' || '''03''' || '''04''' || '''05''' || '''06''' || '''07''' || 08 || 09 || 0A || 0B || 0C || 0D || 0E || 0F

! !! A !! B !! C !! D !! E !! F !! G !! H!! !! !! !! !! !! !! !! 

The difference of valid 0x88 coordinates A and B is uniquely with respect to [[Distance|distance]] and [[Direction|direction]], which is not true for classical packed three bit rank and file coordinates (for instance -+7 may occur on [[Ranks|ranks]], [[Anti-Diagonals|anti-diagonals]]). That makes lookups for [[Distance|distance]], [[Manhattan-Distance|Manhattan-distance]], possible piece attacks and that like, much more resource friendly. While classical square coordinates in the 0..63 range require 4K (64*64) sized tables, the 0x88 difference takes 1/16 or 256 sized tables - or even 16 less.

When I was at the Hong Kong [[WCCC 1995|WCCC in 1995]], I had some conversations with [[David Kittinger]]. He told me about a [[Move Generation|move generation scheme]], whose name I promptly forgot. When I came back home, I explained this scheme online many times. Since I didn't know the name, I couldn't give it the proper name, and it kind of acquired a name. The name that seems to have stuck is "0x88", which is means [https://en.wikipedia.org/wiki/Hexadecimal hexadecimal] 88. The reason it's called 0x88 is that this constant is critical in the implementation of the scheme.

I was told this technique at I believe the [[WMCCC 1981|Travemunde world championship]] . It just involved using 0rrr0ccc encoding. The advantage was that (sq + offset) & 0x88 would tell you if off board. Many of and on the devices I programmed on took longer to read ram than test a register result. Also, immediate test for < 0 (byte value) could test for off board, so faster off board test than accessing a 'collar' utilization of off board values. The fellow who told me this attributed it to [[Mikhail Botvinnik|Michael Botvinnik]] (Former USSR World Champion) as something used in a version of [[KaissaMemory]] <ref>presumably in [[Pioneerhttp://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=462700&t=43447 Re: Hello all]], see also by [[Boris StilmanDavid Kittinger|Dave Kittinger]] ('''1994'''). ''A Linguistic Geometry of the Chess Model''. , [[Advances in Computer Chess 7CCC]], April 26, 2012</ref>. However, when I was riding an elevator w/Mr. Botvinnik and asked him about this to confirm the derivation, one of his handlers asked that I not ask Mr. Botvinnik any questions.

Another advantage of the 0rrr0ccc was that I put the 'ioboard' at 0rrr1ccc so basically used 1/2 a page of ram efficiently for both boards... I would then have the piece table at 1000wwww and on 1000bbbb for the utilization of [[Memory]] <ref>[http://www.talkchess.com/forum/viewtopicwhite and black pieces respectively just to pack things in.php?topic_view=threads&p=462700&t=43447 Re: Hello all] by [[David Kittinger|Dave Kittinger]], [[CCC]], April 26, 2012</ref>

Another advantage ... and the difference of the 0rrr0ccc was that I put the 'ioboard' at 0rrr1ccc so basically used 10x88 coordinates <ref>[http://2 a page of ram efficiently for both boardswww.talkchess. I would then have the piece table at 1000wwww and 1000bbbb for the white and black pieces respectively just to pack things incom/forum/viewtopic.php?topic_view=threads&p=462734&t=43447 Re: Hello all] by [[David Kittinger|Dave Kittinger]], [[CCC]], April 27, 2012</ref>

... and the difference of 0x88 coordinates <ref>[http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=462734&t=43447 Re: Hello all] by [[David Kittinger|Dave Kittinger]], [[CCC]], April 27, 2012</ref>  The whole 0x88 is pretty obvious. In fact, another big benefit is that you could take the difference of two sqs and use that to look into a table to see the legal piece types that could be attackers. Having bit 3 cleared prevented wrap around on this look up. Hence, for most my programs the basic capture routine iterated from [[MVV-LVA|largest to smallest captured piece]], using smallest to largest capturing piece, taking the difference of the sqs, looking up in att_table and seeing if nz, if nz, then if & with attacker type bit nz then just had to check if [[Sliding Pieces|slider]] and had [[Square Attacked By#By0x88Difference|path clear]]. Of course, w and b pawns had different [[Pieces#PieceTypeCoding|type]] bits. Made for a decently fast and ordered [[Quiescence Search|capture search]].