Charlieplexing is good only for lighting ONE LED at a time in an array of LEDs. It takes advantage of the diode characteristic of an LED to allow two LEDs connected in anti-parallel to illuminate independently, but not simultaneously. Read the
Wikipedia article for enlightenment. The article also has some good links at the Resources section at the end. Sensing independently closed multiple switches is not the same thing.
There is no advantage to trying to charlieplex your 8x8 array of chess board positions. At any given time you will have as many as thirty-two switches closed simultaneously, at almost random positions on the board. I know of no charlieplexing scheme that will unambiguously identify the location of those switches.
All you need is two 8-bit ports, one configured as an output port and the other as an input port, to read 64 switches connected to an 8x8 matirx with a diode in series with each switch. Use your schematic diagram, but orient all the diodes the same directions. The output port will have one bit set and the other seven bits cleared while the input port reads the state of eight switches. Then the output port bit that is set is shifted to another bit position, while the other seven bits are again zeroed. In other words, the output port is programmed to behave like an 8-bit shift register with a single bit set. After seven shifts from the initial state, you will have read the states of all 64 switches. Programming this is a "piece of cake" compared to wiring up the logic equivalent, which I did sometime in the 1970s using TTL components.
I once used a static Hollerith card reader that used movable pins to sense which holes in an array of 12 rows by 80 columns were punched in the card. Each of the twelve rows had a diode connected to a pin, and all the pins in any one of the eighty columns were connected together for a total of eighty "outputs". To read the card, I applied a logic "1" value to each column in succession using 1-of-16 data selectors, reading out twelve bits of data on the twelve rows for each column selected.
It turned out I only needed eight bits of data from each column, so four of the rows went unread. The columns were addressed in binary using eight bits applied to five appropriately decoded and enabled 1-of-16 data selectors. The sixteen outputs of each data selector were connected to sixteen columns on the card reader. Obviously it required five 16-line data selectors to drive 80 columns. And of course we could not use the "full" address range of 0 to 255 that an 8-bit address provided, but the end result was a Hollerith card "ROM" consisting of eighty bytes. It did take some skill to multi-punch a card with binary data, and they (the CS Department owners of the card punch) hated us when we tried to duplicate a card... apparently the card punch is not made to do that with binary data punched in the columns. It prefered EBCDIC.
Eighty bytes was more than enough memory to allow me to write assembly code for an ASCII ASR-33 paper-tape bootstrap loader for an Intel 8080 microprocessor with 16 kB of static RAM. Much later (after this proof of concept was up and running) we bought a proper Intel Microprocessor Development System, complete with a "full boat" of dynamic RAM, some EPROM, two 12" floppy disk drives, a monochrome CRT monitor and keyboard, a dot-matrix printer, an EPROM programmer, and an ultraviolet EPROM eraser. It is so much easier to do firmware development today, thirty-something years later, but we had to learn to crawl before we could walk or even think about running or multi-tasking. There were no hard disk drives available for microprocessors (at least none my lab could afford to buy) when Intel dropped their bombshell and revolutionized logic design forever. Old-school minicomputer makers didn't realize what was happening until it was way too late to get in the game...
