This is the readme file for Romi Chess -- version ProtoRomi an alpha release.

2/6/2005 Version Proto Romi 1.
  I have been wanting to write a chess program for more than twenty years, but, did not
know how to write one. It has been a very long and steep learning curve for me to get 
this far. I can't count the number of times I've quit and gave up. Even with source code
available for some really strong programs, it has been next to impossible for me to create
a complete working program. I did not want to write a weak chess program and even though
it has crossed my mind, to first copy someone else's program, I just could not rip off 
another's hard work and call it my own. I'm not the sharpest tool in the shed when it comes
to chess programmers -- probably a sledge hammer would be a good analogy. I just keep 
pounding and pounding and pounding until the square peg fits in the round hole and if I
can't get it to fit, I just get a bigger hammer. I hope this conveys some of what I've gone
thru to get to this point. There are probably many chess programmers that will sympathize 
with these comments. Some of whom wrote a working program, even a very good program and 
others that never finished. I'm glad that I, really, never gave up! I owe a lot of thanks 
to Tom Kerrigan the author of TSCP for posting my example of a simple bitboard move 
generator on his website. Without the boost in moral, it gave me, I doubt that I would yet
have a working program of my own.

  ProtoRomi1 is not as strong as I would have liked my first release to have been. The
program has many faults and is not very robust when it comes to functionality. That's the
reason for the designation "pre pre alpha". However; she can and does play some positions
very well -- good enough to take 46.5 points out of 50 in a Nunn2 match against faile1.4,
36 points from Olithink4.13 and even 8 points from crafty19.15. Fruit 1.5 totally destroys
Romi as of now -- it seems as though Fruit must be an avatar of the abyss. You would have
to be a fan of the show Andromeda to get what I mean about that. It is really meant as a
compliment though.

 The reason for this release is manifold. First, when Romi wins it's more often than not 
aesthetically very beautiful the way in which she does it. Often sacrificing material for a
long term initiative and total domination of the board. Amazing comebacks are her stock and
trade. Yes, I am a little partial I suppose, but; I would like others to enjoy these games
as well. Second, the programming method that I've developed makes programming chess easier
(more on this later) and should enable others that want to write a chess program to be 
able to do so with a lot less effort. Third, a total rewrite is in the works that is far
more advanced in its basic mechanics, and will take along time to complete. In the meantime
I hope to get some feedback as to what was done right or wrong so I can make Romi a stronger
player than without the feedback. Fourth, is a restatement of three above -- I just plain 
need help and lots of it. There is plenty of stuff(algorithms) that just wont work well or
not at all, and no amount of hammering has been able to get these square pegs to fit. I 
know by reading the bulletin boards and the credits in various programs that there are lots
of people willing too help others to be successful with their programs. I hope that they 
will help me as well.

 Why did I choose RomiChess as the name for my chess program? Well, I had quite a few 
possible names picked out, most of wich I won't devulge in case I have, for some reason to
revert back to one of them. I really hope that I won't have to do that though, as I very much
like the name RomiChess. One of the names that I was toying with was Paradigm, while watching
an episode of Andromeda about a 'MOON BRIDGE' when Captain Hunt said to Romi, while both were
taking cover behind a big rock, "Romi, clear a path." Romi responds, "better stay here." 
Then Captain Hunt says, "Good idea!" Romi then walks out into the open, pulls two force lances
from their holsters and proceeds in multitasking fashion to annihilate several dozen enemy 
combatants as though she was an old west gun slinger. That's the instant that I knew that 
RomiChess was to be the name of my chess program. Romi just totally embodies everything that
I want my chess program to be, that I envision my chess program will become, smart, strong,
fast, accurate, beautiful and yes, even sexy. I am going to keep at it until this is achieved.

 Now about the programming method employed in RomiChess. I wanted to use the Bitboard method
to write the program because, it seems like a superior method to use, especially with 64 bit
machines just around the corner. What Bob Hyatt said about bitboards just made a lot of sense
to me. However, I could not quite wrap my mind around the totality of his 'rotated bitboard
method.' And still can't. I wanted to devise a bitboard method of my own that was both simple
and fast, but even though, for months I tried, it just would not come to me. I decided to write
an assembly program using precomputed move tables as in GNU Chess instead. The move generator
is done as well as the make move and take back routines including enough support routines for
and including a benchmark. The node rate during the benchmark on an athlon 1300+ in the 
original starting position is 12,000,000 nodes per second. Very fast. But, before I turned
it into a real chess program I woke up one morning knowing how to write the bitboard move
generator that I had wanted to in the first place. I put the assembly program aside.

 I know that others have thought the same, that Bitboard would run say, as much as 80% faster
on a 64 bit machine, only to be very disappointed to get a mere 20% increase in node rate.
However, the rotated bitboard method was originally written for 32 bit processors in which 
64 bit accesses were designed to be minimized by huge look up tables using triple array 
indexing with other computations inside the indices. This is a good solution for 32 bit
machines. Machines with 64 bits still have to pay the price for all that array indexing
overhead but, pay no price for 64 bit accesses. My method uses lots of 64 bit accesses and
almost no double or triple array indexing and should gain more when moved to 64 bits. My
rewrite will even use less multi array indexing. Also the rotated bitboard method would be
totally inappropriate for the rewrite and would not work. I'm going to be a little mysterious
about the rewrite until it is up and running. If I'm right it will reduce to almost nothing
a lot of the functions that now take a lot of time away from the search with very little 
overhead of its own. The two methods work synergistically together. A new paradigm if you
will. Actually this is what I wanted to do in the first place but, once again could not
figure out how to do it until one morning I woke up and just knew how. I believe that
I will achieve node rates on a 64 bit machine in excess of the assembly routines I wrote.
I will post the assembly program as well.

 I will maintain ProtoRomi in the future and include any and all improvements that people send
me or help me with including updated source files. However, I maintain the right to keep the
source code to RomiChess proper proprietary in the hope that someday it could go commercial
with Romi, Andromeda and crew pictured on the box and their personalities able to play in 
Romi's stead if desired. Okay I have a dream. Everyone is allowed a dream, aren't they? Please
don't wake me!

 Any way I hope that I have created something worthwhile on some level and that people will
enjoy my effort so far. Thanks to all the authors that publish their source code as a lot
of the rest of us would not have been able to do what we've done without it.

  
7/6/2005 Version Proto Romi 1a.
  Earlier version was mostly tested with Arena and it worked fine. Major deficincies
showed up under winboard. Winboard 4.2.6 allowed Romi to play the black pieces okay,
however winboard 4.2.7 did not. My fault, not winboards, the mistake is corrected now.
Draw and mate claims seem to be working just fine, after rewrite of interface code.
I did not really have to change the interface code, if I would have realized that the
problem was that I did not fflush() after draw and mate claims. Arena did not mind this.
However, I am happy with the changes. The reason for the 'a' in the version number is
because there have been minor changes to the evaluation function. Pawn structure values
were too high and thus Romi would often sacrifice a piece for two pawns and a weakend
enemy pawn structure. Against lesser engines Romi would win anyway. Against stronger
engines Romi would win sometimes, but, also would loose more. I've only tested the new
values in a few games with GNUChess5 and Romi went from loosing with ease to winning
with difficulty. An improvement. A couple other minor changes as well. The changes to
the evaluation function are temporary as I believe a redesign will be needed. Oh yes,
please email me at msher18987@aol.com if you have any thoughts on RomiChess. It does
not matter to me if your thoughts are positive or negitive, just please be honest. I
really need some feedback to work with. Thank you.  


10/6/2005 Not a new version -- just a bug fix and some match results.
  There was a pawn promotion bug. This is fixed. I know of no more bugs at this time.
Some match results for ProtoRomi1a follow:
All matches were Nun2.pgn matches, ran on an athlon 1300+ computer before the bug fix.
Romi 44.5/50 vs. Faile     1.4    +40   -1   =9    40 moves in 2 minutes.
     38.0        Olithink 4.13     34    8    8    "
     28.5        Beowulf   2.3     22   16   11    "
     16.0        Arasan    8.2     11   29   10    70 moves in 1 minute.
      8.5        Pipito    159      6   39    5    "
     14.0        Crafty  19.19     10   32    8    " 
and after the bug fix.
     14.5        Crafty  19.19     10   31    9    "
  
  My philosophy on Nunn2 matches is as follows. The Nunn2 positions are volitle and do
not properly reflect the absolute strenth of the participating engines. The biggest
reason is, because, the stronger engine is often set the task of playing an unfriendly
position that it does not handle well, while the weaker engine is given the side that 
is easy to play. This skews the result in favor of the weaker engine. However, I am
not trying to gauge the absolute strenth of Romi or her opponents, but only, if Romi is
making progress against each engine, or not. And, I believe that this is the best method
for determining this. I want to test my engine against the actual chess algorithm of 
the other engines. I do not want the results skewed by their opening books and the 
randomness thereof, their learn files, their egtb files or any other factor that is
not part of the basic chess engine. This seems to work well for me. As an illustration
of this, at first I only played Romi against TSCP181 by Tom Kerrigan. To me TSCP is
the first gatekeeper at the base of the chess programs mount Olympus -- home of the
chess computer gods. If you can't get past TSCP then you have no business trying to 
scale that mountain! Romi's first match (without gui problems) against TSCP surprisingly
ended in Romi's favor with a score of 28 to 22. Right, 'out of the box' Romi was a 
winner! After that, progress was slow but steady, and a few more points were gained
every second or third try or so. The best result that Romi ever had against TSCP was
49.5 out of 50. Several times Romi achived this score, but, never bettered it. Always
TSCP would manage to draw a different one of the fifty games. Even after many
improvements to Romi that allowed her to garner more points from various engines, TSCP
would always snaggle at least a draw and sometimes even more. This is the nature of
the Nunn2 positions that make them very interesting to test with. Well then, TSCP, said 
to Romi, "Romi, you were not able to finish me off, but, for want of only half a point,
I guess that I'll let you pass, so you can try to climb the mountain. Maybe if you get
near the top, you can try me again some day." I thought that was very nice of TSCP, don't
you? Ok I'm done.

15/7/2005 Version Proto Romi 2.
  The new version number is due to the addition of learning. A learn.dat file is created
which can hold 1,000,000 positions in a tree configuration. When a result command is 
recieved, the function LearnGame() is called, which takes the moves from the game and
overlays them into the learn.dat file. Other information is also updated, like the score
if the depth is >= to the stored depth. Wins, losses, draws are updated although not used.
Record 0 holds an index to the first free record and the number of records used. Record
1 is the entry point for the black thread and record 2 the white. Any record can be 
printed with the pr # (pr 0, pr 1, pr 2) command. At the beggining of every search the
white/black thread is followed untill the current position is reached when SetThread()
returns a thread index on success or 0 on failure. Then Learn2Hash() is called which 
places the tree section pointed to by thread into the hash table. The benifit from this
if any, is derived from the fact that if in the search, the closer to the end nodes you
are the shallower the information normally stored in a hash entry is, however, a hash
entry that comes from the learn file will give a score based on a complete search. This
then can double the depth that information is gained from, especially in the most
criticle lines. Higher saturation levels in a particular opening should help more. I 
have not done much testing, yet, however, a 50 game match between ProtoRomi2 and 
Crafty19.19 starting from the original position and using no opening books, ended in
Romi's favor with a score of 28 to 22, even after a 0-3 start. Note, that Crafty also 
had the benifit of learning during the match. Also randomness as described below was
not used.
  
  Also randomness was added to the score of the first move in the root search of + to -
4 points. The reason for this is the idea that the learn file will eventually compensate
for less strong lines from the randomness and the randomness will keep the learn file
from becoming stagnated or said in another way, from becoming set in it's ways. Or at
least some dynamic may be added that might be interesting. 
  
  This is all just speculation on my part and may have to be abandoned like so many
other things that I've tried. There is no more time for testing, before Leo's Edition 11
tournament begins, so I am just taking a chance and submitting it.

  Other changes include:
1. a minor bug fix to analyze mode. Mate detection no longer stops the search.
2. a passed pawn extention was added.
3. the value of the pieces were changed and made consistant with the value array.
4. some other very minor changes.

  Below I am starting my THANK YOU section.

16/7/2005 Version Proto Romi 2a.
  There was an oversight that I had made in the learning code. It was something that I had
thought about and then just forgot to do. Now there is backward propagation of values in 
the learn file as well as a few minor fixes. The backward propagation works as such. If on
backing up through the move nodes, say at a max node, there is a child node with a lower 
score and that child has enough childern of it's own so that there has been sufficiant tries
for a better score, but to no avail, then the lower score is backed up to the parent node.
This means that information can be backed up, as set up now, about 160 ply and a search can
have access to information a 160 ply away! This of course is how it is supposed to work,
however, wether my code really works as supposed is another matter. I am way over my own 
head in this one.

  After falling way behind to Crafty19.19 I was going to cancel a match and scrap this 
version. But, I had to go away for the day, so I decided to let the 400 game match continue 
to see just how bad it would turn out. On returning home I was shocked to find that Romi
was actually winning the match at the 252 game mark with a score of +159 -80 =13 and that
she had won the last 100 games in a row (give or take). Please let me know what you think
about the learning system or about the rest of RomiChess. So far no one is beating down my
door, with help or advice concerning the programming part of RomiChess.
 
  I'm finished for now with the prototype version and will be working on getting the "real"
more advanced version up and running. So do not expect updates for a long time. If someone
else wants to help then there might be more updates. If someone wants to take over the lead
role on the prototype version and have their name associated with it and supply the updates
then that person or persons need to email me. For the sake of the project I will try to 
choose the most ambitious and qualified.

  For now I just sit back and see how well ProtoRomi does. Okay maybe I will get some sleep 
first. Thanks for listening to my rantings and ravings. I will try to be more subdued in the
future. 
 
19/7/2005 Version Proto Romi 2b.
  Is three days concidered to be any time soon? Well I did not mean that I would not do bug
fixs. In the backward propagation code I failed to sign flip the childs scores. So I added
four minus signs and here is the new version. In a 300 game match with the old version 2a it
scored +139 -88 =73. Most of the point lead was gained in the second half of the match.
This is all I have, to tell me that this new version is more correct. Can someone take a look
at the learn.c file and tell me if I am doing things correctly. I'll put your name in my thank
you section! Please note that in the Compute function Romi gets the opponents score for the
previous ply from the current ply and that score is sign fliped, so, that score will go into
the hash later, corectly.

P.s. Just found out another problem. An endless loop in LearnGame(); Fixed. 

21/7/2005 Version Proto Romi 2c.
  When I tried to modify the time command to adjust to different tournament settings -- better
, I introduced a divide by zero bug. I changed 'maxTime = myTime / 16;' to 'maxTime = myTime /
(numMoves >> 1);', and since in time per move modes, numMoves is zero, hence a divide by zero
bug was created. The line now reads 'maxTime = myTime / (numMoves > 1 ? (numMoves >> 1) : 4;.
The windboard forum people figured it out before I did, but, no one emailed me the cause. I
only found out that they already knew after I had fixed the bug and then Leo directed me to 
the forum. Anyway the bug is fixed now and that is what matters. Also, randomness has been 
removed as short time results were poor. A couple of other minor changes and now it's good to
go. Famous last words! 

23/7/2005 Version Proto Romi 2d.
  A bug fix -- 'gameOver = FALSE;' added to NewGame(). Thanks to Richard Pijl (site admin)
for this one. Also changed time management for blitz games. Uses time more evenly now. Added
back the root threat detection and good responce extention. Tweaked some pawn structure
values.

13/8/2005 Version Proto Romi 2e.
  I was not satisfied with 2d, so, I decided to tune it up some so that 2e would be stronger
than both 1a and 2d. This version, 2e, won matches against both 1a and 2d. The score against
2d was +24 -16 =10 and the result against 1a was even better, but I do not remember exactly.
Also it won a match against Faile 1.4 +42 -2 =6 which is a new best result and as well a new
best result against Crafty 19.19 16 out of 50 vs 14.5 out of fifty that 1a scored. Some king
safty was added. The third killer was dropped. Better time management (I hope). The root search
threat extension was also dropped -- again. The value of the pieces was changed. Maybe some
other minor changes as well.

18/8/2005 Version Proto Romi 2f AND Proto Romi 64 bit 2f.
  Got a new Athlon64 3400+ computer and recieved from Microsoft for $5.99 each, Visual Studio
2005 beta 2 and Windows XP Pro. x64 -- evaluation copy. I just had to add three small 64 bit
fuctions to get a good 64 bit build! However, VS2005 showed me an error that I knew was there
that I could not find with VC6. A simple fix, but it played worse after the fix. I removed
the LASTMOVED case from NextMove() and while I was at it, also removed was the IID case. Romi
performed better without either. I've tried to get IID working for me, like in other programs,
but, to no avail. Then I added something that I call MOVEKILL -- it stores the killer move in
a move history type array that is accessed by the previous move. When that previous move is 
played again then the MOVEKILL move is tried just after the normal two killers. Seems to help.
Anyway Romi achieved a new record vs. Crafty 19.19 in a Nun2.pgn match of 17 points out of 50.
The 64 bit version, due to the extra speed, got 20 points out of 50. It's about 50% faster.

  Here is a list of things that I could not get to work well, or not at all, for me:
1. Internal iterative deepening. Slows Romi down.
2. Enhanced tranposition cut-off. Does not help at best. Plays bad at worst.
3. PVS zero window. Slows Romi down and can play some wierd moves. 
4. History tables. Romi runs slower.
5. Futility cuts. Romi plays bad.

  There are more. If anyone can help me with these problems, I would very much appreciate that.
However, so far, no one has offered any help at all (with programming) to help make RomiChess
a stronger program. That's okay, because, well, that's life. The flip side to this is there is
no reason for me to continue to release any more source code. I hope that Romis' source has 
been helpfull to some people, either as an introduction to bitboard programming or as an
alternative method for bitboard programming that is simple to implement. On the other hand, if
someone or someones were to give me some help, then the new improved source will be released.

23/8/2005 Version Proto Romi 2g.
  Just a bug fix. Stupid me broke blitz mode -- again. Source included for bug fix.

26/8/2005 Version Proto Romi 2h.
  Added iid.

07/9/2005 Version Proto Romi 2i.
  Removed iid. Tinkered with learn.c. This is ABSOLUTLY the last prototype version.

*********************************************************************************************

Thanks to: 

  Leo Dijksman:   For hosting my program and source code on his site and for hunting down
                  all those bugs so Romi can play in his tournament.

  Tom Kerrigan:   For posting on his site, my simple bitboard move generator, example.

  Dan Corbit:     For pointing out that nameless structs are not standard. 

  Charles Smith:  Of CEGT and AEGT, he emailed me some nice comments about RomiChess.

  Guenther Simom: Of RWBC, he did some testing on RomiChess and reported some problems.
                  Also said, that he finds RomiChess "highly interesting!"
 
  And to all those that are running or will run Romi in their tournaments. 
                   
*********************************************************************************************

THANKS
Michael J Sherwin
msher18987@aol.com
