After hours of debugging and looking at the code I finally realized (again) that cl65 has put one segment of my code at wrong address due to incorrect configuration.
Here is the configuration file for my port of "Microchess":
RAM1: start = $0400, size = $0520, fill = yes;
RAM2: start = $0920, size = $006E;
CODE: load = RAM1, type = rw;
DATA: load = RAM2, type = rw;
Before the corrections, the size property of RAM1 was one byte shorter ($051F). Notice fill=yes property setup? That's right, as you probably already realized, my DATA segment was put at wrong address because of the wrong size declaration of RAM1 memory. When using fill=yes property, (which is necessary to produce continuous code for my bin2hex tool that generates write memory statements to plain text file, which are then sent to the MKHBC-8-R1 via terminal emulator using Send Text File feature), the size of the memory section must be the exact difference between the start of the next section and start of the current section. In above example: $0920 - $0400 = $0520.
After correction to configuration file cl65 linked all segments of program to proper address locations and runs flawlessly:
Figure 1: Peter Jennings's "Microchess" running on MKHBC-8-R1.
Next step (if I ever find time) is to improve the user interface a bit. The presentation is OK I guess, It wont get much better in text mode. However data input is a bit awkward (commands are taken key by key, refreshing the screen unnecessarily after each key stroke, instead of just taking full command line and parsing it when fully entered). I think this is KIM-1's legacy of taking input from hex keypad, Daryl Rictor did not change this part of code much). Well, poor user friendliness is the price you pay for compact code. The whole thing fits in just 1407 bytes! Original program on KIM-1 ran in standard 1 kB of RAM. The whole chess engine! This is awesome. As a professional programmer I can appreciate efficiency in coding.
That's it for today. Thank you for reading.