Yet another new engine for your mobile devices: CT800 is an average level engine released by Ratmus Althoff who recently concentrated on compiling for Android and finally managed to obtain working binaries.
CT800, in fact, was born as a dedicated chess computer idea and it was designed by Rasmus Althoff. The original CT800 featured an ARM Cortex M4 microcontroller of an Olimex H405 board that operates up to 168 Mhz, with 1 MB of flash memory, 192+4 kB of SRAM, and multiple I/O and USB connectors, with a 4x20 character text display, two leds, and a 4x4 + 1 keypad as peripherals aka user interface. Voltage source is due to four NiMH rechargeable AA batteries or external 5 V DC power supply.
The "chess computer" CT800
CT800's firmware is developed by Rasmus Althoff, released under the GPL Version 3. The chess playing software is an ARM port of George Georgopoulos' open source engine NG-play including a KPK bitbase by Marcel van Kervinck.
I cant get arm8 engines to work u der Droidfish.Engine exits in play mode but works in analysis mode ? Android 6.01 exynos cpu .arm7 work fine
ReplyDeleteEngine error seems to occur if i leave opening book early.hm.ill look some more.ill as also try in cfa
ReplyDeleteWhat is the elo range of this engine?
ReplyDeleteWell ccrl version 1.12 40/4 gives 2200+
Delete..actually im sad to say the arm7 binaries act same way as arm8 for me
ReplyDeleteunder Droidfish.Version 1.12 32 bit from ct800 website works perfectly for me in Droidfish
Yes seems engines work fine in cfa.But i like using droidfidh too as i can play around with engine settings.if anyone gets these engines working under Droidfish(please try leaving book first 5 moves) let me know.
ReplyDeleteEngines also have tgis error when leaving book late in droidfish.reminds me of cheese 1.9 in droidfish before it was fixed.Anyway..enough talk..
ReplyDeleteCT800_1.20p04.RA_uci.arm8_r16b
ReplyDeleteCT800_1.20p04.RA_uci.arm8_r16c
I try this in droidfish after 23 and 33 moves says engine error and terminated..only 32 bit can run in droidfish. Please fix this issue..thanks.
I have downloaded ct800 from its websit n it works fine
ReplyDeleteon my 64 bit naugat
No problem try it
Yes but its 32 bit from the website.the anonymous user above was trying the 64 bit versions..which is preferable but I suppose 32 bit is all we have for now
DeleteFor those whose ct800 arenot working
ReplyDeleteits website download it
https://www.ct800.net/software.htm
..... chysiddh14 said...
ReplyDelete(For those whose ct800 arenot working
its website download it
https://www.ct800.net/software.htm)
it's CT800_1.12 version only in that site....
CT800_1.20 is strong but the error occured...
CT800_1.20 64 bit is very unique attacking and defense..after middle game its error or engine terminated, after I closed droidfish gui and open it, its active again..
ReplyDeleteEngine is highly unstable getting excited every time
ReplyDeleteThe author here. Thank you all for your interest!
ReplyDeleteThe 'P' versions are preliminary ones for the upcoming V1.20, and the P04 especially was meant to get feedback how exactly the engine fails under Android. One thing is clear at least, why the P04 executables generated with Android NDK r16b didn't work, and that's because static linkage doesn't work properly with r16b. I've settled for NDK r15c and dynamic linkage - which also gives smaller executables. Besides, there are a couple of fixes in handling the UCI input that might have something to do with the Android problems.
Tested under Windows and x86-Linux using Arena, but not under Android, so here are the current preliminary versions for Android (32 and 64 bit for ARM and x86 each):
https://www.ct800.net/download/ct800_v1.20p10.zip
If these also fail, does Droidfish have a feature like Arena where the communication between GUI and engine can be logged? That would be valuable.
After 35 moves error again..
DeleteNice to hear from an engine author.I think your engine especially excites as it forms part of a chess computer !Unfortunately on my device the latest 64bit v1.20 has same problems as before..ie it only shows score and then when its time to make a move i get engine error.I havent tried 32bit yet but 33 bit 1.12 works perfectly for me.I like your
ReplyDeleteCpu speed feature a lot! Great way to naturally weaken an engine-no cheap random weak moves.Stay in touch here.A lot of passionate computer chess lovers visit this blog :-)
Glad to hear from Author
ReplyDeletebut only website android version works in my device ( 64 bit Naugat )
It will be great if u introduce this ct800 as app also , many will use it from playstore
n also aggressive name if possible
dont mind i m new as well
Since things have been working under Arena, but not under Droidfish, I went through the Droidfish source code to dig out some difference. Unlike all other chess GUIs, Droidfish does not use UCI to just give the moves from the initial position, but from the position since the last irreversible move. If that has been a White move and the CT800 has Black, then the rewrite of my UCI layer for V1.20 has introduced a subtle bug: the side to move would only be evaluated if a move list followed.
ReplyDeleteMeans, the CT800 engine could get the moving side wrong if it has Black right after an irreversible move by White, and that all the way down from the V1.20P04 to V1.20P10 versions. This would also explain why my tests with Arena and Shredder GUI did not spot this bug, and why V1.12 did not show these issues.
The fix was not difficult; it was more of a headache how to still notice PV hits in an ongoing game, with the move list lacking.
https://www.ct800.net/download/ct800_v1.20p11.zip
If someone could please try that? Hopefully, that will work.
@ Lazar : the "real" device also has this CPU throttling feature so that even I can win. ;-) The pre-search with 3 plies depth (plus quiescence) is not throttled so that the engine always has a somewhat reasonable looking move. I also dislike "winning" against random blunders, that doesn't feel real. Btw., I've implemented that throttling feature in an energy saving way especially with mobile devices in mind.
@ chysiddh14 : The playstore has the problem that I probably would have to launch a full app. But GUI programming is a whole lot of work, and most users don't even want to change a GUI once they have found one they like and know. That's why I've targeted "Droidfish" and "Chess for Android", both of which allow to install 3rd party engines.
The engine's name actually is aggressive once you get the reference. ;-)
regards, Rasmus
Yes Rasmus..I'm happy to report your latest fix has worked! V1.20p11 64 bit works perfectly under Droidfish.There is a slight delay (just under 1 second) after I make a move before CT800 then starts calculating its moves but I don't think it's an issue.The only thing id request for future releases, would be to perhaps consider adding a limit NPS or max NPS option in settings? This would allow speed tuning between different devices/machines as well.I suggest this to add to and complement the current CPU throttling option not replace it.Texel chess engine also has this feature as well and it's fun.Eithet way though I'm glad CT800 is on Android.Its an interesting engine. By the way you were never able to get any chess computer manufacturers to mass produce your idea for CT800? It sounded like a great idea as you described it.It also sounded very affordable! If that's all no longer happening well no matter but i DO still hope something could come of it.Thanks for the CT800 fix and stay in touch from time to time :-)
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteMany many thanks for this updated chess engine for android
ReplyDeleteit works perfectly in my device
thanks Rasmus
Thanks for the updated chess engine. It works perfectly in droidfish..
ReplyDeleteHello all,
ReplyDeleteI'm happy that the bug is fixed - thanks for your support!
@ Lazar: I think the delay is caused either directly by the GUI, or by the OS because Droidfish reduces the process priority for engines as to make sure that you can still operate the GUI even when an engine puts full load on all cores.
Setting the NPS rate is an interesting idea as it allows to readily have the same reduced playing strength across different devices. I've implemented it right away already for this release, just as battery friendly as the other throttling.
There are three options now: first, selecting between how to throttle, via percent CPU or via node rate. Then CPU percent and node rate limit. In CPU percent mode, the node rate setting does not have any effect and vice versa. Default is throttling via CPU percent (set to 100%) because this will not run the risk to erroneously throttle with faster future hardware.
The "real" device comes out at around 30 kNPS, and if you combine this with minimum hash tables (1 MB), the playing strength should be in the same ballpark under Android. With that node rate, you may also want to activate the "show short PVs" option. And no, I havn't met commercial interest yet; I tried to contact Millennium, but they were not interested so far. However, the engine is intended to be included as native engine on the Revelation II, and the Raspberry Pi build has the DGT Pi in mind.
I've tested it under Windows and Linux, so I think it should work with Android, too:
https://www.ct800.net/download/ct800_v1.20p12.zip
regards, Rasmus
Many thanks Rasmus! Node throttling works superbly on my 64bit mobile.thanks for implementing it and thank you for the update regarding commercialising CT800.I may look into the Raspberry pi.I look forward to your future development of CT800 whether its in strength or improving the 'fun factor' of the engine ;-)
DeleteBy the way Rasmus, I was about to ask whats the benefit in using the 'show short PV' option when i simply starting playing using that option 'ticked' .To my pleasant surprise-at least in my device- im finding that the delay in response from CT800 is greatly reduced.It seems as responsive as most other engines.So very nice !
DeleteHm, user feedback has already indicated that the idea with the throttle mode selector on top of the two options is a usability problem. From a UI point of view, the two options just have to work both, and the engine has to figure out itself which throttle to apply (if any).
ReplyDeleteregards, Rasmus
One last question....for now lol.Is there somewhere in your site that users can download this latest v1.20p12 for PC ? I really want this on my PC as well.Thank you
DeleteHi Lazar,
ReplyDeleteI've made a build including Windows executables, and it eliminates the mode selector for the throttling options. Both work now at the same time even when the limits are close to each other. I think this behaviour is more like what users will expect. The engine supports "debug on" for testing; e.g. in Arena, you can just send that command to the engine. If the engine throttles, it will also show the reason - CPU percentage or node rate. If you experience problems, the debug output will be useful.
https://www.ct800.net/download/ct800_v1.20p13.zip
Yes, the "Show Short PVs" option printed all PVs immediately and not only after half a second. I just re-read the UCI spec and found out that the recommendation to start output only after a second did not refer to PVs, but to currmove infos. I removed this option altogether, now always printing, so that the lag is gone without tinkering through the options. Two usability fixes in one day, that's something! ;-)
regards, Rasmus
Lol...that IS something! Indeed! Nicely done Sir! Engine responds instantly by default :-) Question: If i keep CPU at 100% and simply want to play at a certain kns example 30kns or 100kns its exactly same as previous version right ? Of course now i can set CPU speed at 50% AND 30kns but its the same anyway as far as that combo goes.i guess id still be inclined to choose ONE option OR the other but i see how youve made it more freeing and less confusing for users. Regarding the keep hash tables option, thats on by default i should rest assured there is a good gain in elo and that hash entries can be overwritten correct? Ive never really wrapped my head around engines keeping hash tables and getting almost 100% hash full but i see that at example 16mb hash CT800 seems to reset the hash full at every turn to 72% even if it had reached 85% full on its last turn.I cant give less than 16mb in Droidfish so when im simulating the dedicated CT800 with 16mb hash and 30kns & engine showing 85% hash full in long time controls i should be unconcerned and no need to give more hash?
DeleteHope you find time to answer those couple of questions and Thanks Again Rasmus!
This comment has been removed by the author.
DeleteThank you Mr.Rasmus!
ReplyDeleteHi Lazar,
ReplyDeletethe throttling now takes the effective minimum of the two options, evaluated every second. So if you set the CPU Speed [%] to 100%, which would give let's say 300 kNPS full speed, and you set the CPU Speed [kNPS] to 30 kNPS, then the engine runs at 30 kNPS. Just as if the selector from the previous version were set to "CPU [kNPS]". If you put CPU Speed [%] to 50%, and let's say that would give 150 kNPS, but set the CPU Speed [kNPS] to 30 kNPS, then the engine still runs at 30 kNPS. So for practical purposes, the mode selection is implicit and automatic.
Keeping hash tables should be enabled for normal play as it retains information from the search of the previous move turn, and that benefits move ordering. The drop from 85% to 72% is due to age management. There are four age levels, and before each search, the enries with the oldest one get deleted. However, this step may be omitted under time pressure. Reaching 100% is OK because the engine also decides itself which entries to overwrite, but it's also helpful to throw away the most irrelevant entries up-front. Other engine do this on the fly during search so that the drop isn't visible.
Btw., you don't need to specify the hash table size in powers of 2. The engine accepts any setting and will automatically figure out the highest amount it can use without exceeding the given limit, and that will not be a power of 2 anyway.
The "real" CT800 has only about 120 kB for hash tables because the total RAM is only about 200 kB - yes, kB, not MB. UCI, however, allows the hash size setting in megabytes only, that's why 1 MB is the minimum for the UCI version.
Btw., how does Droidfish handle engine specific options? Does it remember them for each engine or do you have to set them every time you start Droidfish with a certain engine?
regards, Rasmus
Μany thanks for your comprehensive reply Rasmus! Yes i understand keeping hash tables and age hash much better now. Thanks for the mode selector explanation too.i was fiddling around after i posted my questions and came to understand what you have explained...but i got excited and impatient and asked...Yes Droidfish remembers specific engine parameters as you last set them for example 30 kns throttling is all remembered when CT800 is loaded again. Hash size is universally set so it may have to be reset depending on the size you had set for the previous engine. But Droidfish allows minimum hash of 16mb..which is not great for 'simulating' the real CT800.
DeleteThe book that the uci engines come with is same size as the 17000 ply of dedicated unit you mention on your site? .
I like the Ct800 playing style.i love the hypermodern 'vibe' the tactical strength and overall dedicated engine feel.it seems to scale poorly just like Chess genius.The 32bit ct800 engine (32 bit in real ct800 right?) reaches about 950kns at 5 seconds with 1% of 16mb full on my galaxy s7 exynos processor from the start position.For comparison Mill CG pro is 58x faster on my mobile vs Millenium CG pro.So allowing for the faster 168mhz m4 in ct800 still id say ct800 engine is roughly 45x faster on my mobile if it was running on MCG pro cpu of 120mhz(assuming 21000 pos/s from start position for ct800). Im not bothered by this but is that your conclusion too regarding scaling? Just curious :-)
If you change an UCI option to another value than the default value, DroidFish will save it as an extra ini file in the same directory of the engine file (uci directory). So DroidFish will remember the settings for each engine.
ReplyDeleteHi Lazar,
ReplyDeletethe hash table size won't matter too much with the node limiter in place, I guess. The opening book is indeed the same, now at 22,000 moves. It favours variety over strength to give more fun, plus that you'd also get sub-optimal moves in human amateur play. I'm happy that you like the playing style. :-)
The scaling seems quite plausible. 950 kPNS at 2.6 GHz (that's what this S7 should offer), and in the starting position, the hash tables don't matter much. The Cortex-M4 (32 bit, yes) is around 30 kNPS, so that's a factor of 30. Well, 2.6 GHz / 168 MHz gives 15 and not 30, so why is the Cortex-M4 only half as fast as the clock rates would suggest?
With a mobile, at least the hot spots of the engine should fit the cache so that it can run at full CPU speed, more or less. But Cortex-Ms don't have a cache, and they run the flash-ROM with 5 waitstates at 168 MHz. They sort of circumvent this because the one I'm using reads 128 bits at once from the flash, and with the average instruction length, that gives 5 instructions. So nominally, zero waitstates, that's what the manufacturer advertises.
But here's the catch: that goes downhills with branching, and a chess engine branches a lot, especially if it is mailbox based and not bitboard. But a bitboard engine takes too much RAM, and I think that can't be done on a Cortex-M4.
regards, Rasmus
Hi,
ReplyDeleteI guess this will be the last preliminary version for V1.20. Hopefully.
Before, the engine woke up every 10 ms to poll its internal interface when in idle state. While this did not cause directly visible battery drain, it made it harder for the operating system to apply proper energy saving. In other words, not a functional bug, but an energy bug. I've rewritten the input handling, and now the engine is in suspended state when idling along.
Besides, the CPU Speed [kNPS] mode has become more energy efficient. The CPU [%] mode needs a bit more energy at the same resulting node rate because it first has to put some dummy load on the CPU to get it fully going.
Tested under Windows and Linux so far.
https://www.ct800.net/download/ct800-uci-v1.20p14.zip
regards, Rasmus
Thanks Rasmus! Ive been playing games vs CT800 myself.Very much a Club Feel strength engine.At leqst i understand its moves unlike other enginesq altgough the tactics at times are overwhelming.ive also tested it vs Mill CG pro aimulating 40/120 time control.It goes toe to toe with genius although in the endgame Genius seems to be stronger.And yet..i like CT800 more because its much more configurable.One thing...if i select a low nose count ie <20kns CT800 seems ro overstep the selected node count especially if playing in faster blitz games.i think it oversteps generally at low node counts regardless of time used.Can this be improved in any way ? Not a big deal...but i play with CT800 so much so just wondering if it can be improved in this regard.
ReplyDeleteYou mentioned earlier i think or in release notes that with throttling you still made it so that the engine still does an effective 3 ply search to make reasonable moves.Does this at times cause a speed up in early search that exceeds the set limit and this shows up especially in blitz games or is that unrelated to the speed up?
Thanks again for the update!!
Hi Lazar,
ReplyDeleteyes, club level is what the device is about. :-) The endgame is certainly not the strongest part of the engine, and I bet Genius is stronger here. After all, it's by Richard Lang. The CT800 tries to cover up because is is reluctant to trade pieces - which keeps the board full and creates more opportunities for humans to miss out on tactics. Doesn't work against another engine, of course.
With the node count, the UCI version cannot reduce the CPU clock and instead divides the thinking time into seconds that it applies the throttling to. This drives the huge overshoot if the move time is as short as 200 ms: the engine subtracts the move overhead, per default a 100 ms, and has a 100 ms thinking time left. The allocated throttled node budget, however, is for a full second.
Here the logic can be improved: if the engine knows that the move time will be over within the current second, then the throttling can be adjusted proportionally. Say, we have a 100 ms left, then the effective node rate must be 1/10th of what's configured for this final second. Both in terms of % and kNPS, of course.
However, there are some remaining factors. First, as you already noted, there is the pre-search, but the nodes spent there at least do count towards the throttling afterwards. Second, the PV outputs don't fit in that one second pattern, so short minor spikes are displayed when a new depth is finished and the PV is displayed. That can't be postponed because then the perceived engine starting lag would be back again. Third, the engine can decide that there is move time left, but not enough that another depth iteration would pay off, so it ends before the move time is used up. Fourth, the quick replies for "obvious" moves can end the search before throttling hits in. But still, the overshoot will be much less on average.
So, here's another preliminary version - do you like this behaviour better?
https://www.ct800.net/download/ct800-uci-v1.20p15.zip
regards, Rasmus
Thanks for you usual comprehensive reply Rasmus!Some interesting explanatioms on the inner workings of your engine.Also sorry for my typing errors in my last post example 'low nose count' lol.
DeleteAs far as your latest P15 version, in about 10 minutes of testing i honestly couldnt detect any difference between the behavior of p15 vs p14 for Android 64 bit.Im guessing i missed something or need to test some more? I will test further. Honestly the 'overshoot' isnt terrible in any event.it only really shows up in low node counts and blitz time controls.Id suggest to perhaps have a quick peek at Texel source code for alpha test versions 1.08 a2 to a8 (1.07 doesnt have node feature) to see its implementation of node count if you have time and are so inclined ? Not sure that would in any way reveal anything but Texel node limiting is very smooth with virtually no overshoot and i only suggest it as its the only other Android engine i know that has this feature.Once again though not a big deal
:-)
For what its worth i really respect your passion and dedication to your CT800 project !
Kind Regards,
Lazar
Hi Lazar,
ReplyDeletethe difference between P14 and P15 will mostly be visible at very short time controls. If you start the Windows versions directly (without GUI), it is easy to see when you type in the following UCI command sequence:
uci
setoption name cpu speed [knps] value 30
go searchmoves d2d4 e2e4 movetime 200
P14 will search around 30,000 nodes with a resulting node rate of 300 kNPS, that's what I meant by "huge overshoot". P15 will search around 3,000 nodes and come out with a node rate of 30 kNPS, just as configured. With longer move time of several seconds, this will level out, and you won't see much difference.
I'll have to see whether I understand what Texel is doing, but a major point when throttling the way I'm doing it is that it allows for longer continuous engine suspend. This in turn benefits battery life especially on mobiles.
Thanks for your thumbs up regarding the CT800. :-) When I think back, what I originally wanted was just gathering some experience with the Cortex M4 microcontroller, and I thought that building a chess computer would be an interesting project for learning about the chip.
regards, Rasmus
Ah...yes! Typing in the command as instructed i see now.However under Droidfish according to Droidfish output - and at least with what my eyes can see lol - p15 and p14 seem the same but i see that there must be a difference.ill play some games where p14&15 are given 15 and 30 seconds total time blitz with low node count limit and then compare the moves.im assuming there will be a difference.
ReplyDeleteRegarding Texel im the user that requested this feature back in October 17 as i wanted engines to be more fun and weaker to play against wheras all i was seeing was an obsession with strength and analysing with engines.To my surprise it was implemented in texel version 1.08a2 3 weeks later.Peter Osterlund also mentioned that he had tested texel at just 100 nodes/sec vs dedicated Constellation 3.6mhz from 1985 at 40/5 with final score of 1.5 to 0.5 with texel winning.So i think he got a little excited with this feature.By the way texel allows you to set nodes at literally 1 node/sec although its silly and weak but it allows very low node limits.
I am however more enthusiastic about CT800 because its expert strength to start with and most club players would feel very comfortable playing against it at lower node counts in my opinion PLUS its originally conceived as a dedicated Chess Computer..which makes me drool :-D .And i dont want to overemphasize the node feature.I AM glad that you are actively updating your engine on windows and android
I just hope other players give it a go and actually play against CT800..as that is what its all about!
It plays so unique
ReplyDeletevariety of moves both attck n defense
thanks for it
Rasmus
ReplyDeletecan it be possible , like other chess engine
it is influenced by other open chess en gine to make it stronger ?? by taking ideas
Hi chysiddh14,
ReplyDeletethe engine itself is a fork of NG-Play v9.86. Plus that I've taken the code for the bitbase of king and pawn vs. king from Marcel van Kervinck because it is quite self-contained and was easy to interface.
NG-Play in turn has credits to TSCP for the opening book handling, which was the first thing that I rewrote completely. Then there are credits for the Winboard protocol handling, which I eliminated in my previous release when I went for UCI.
For ideas, I find it a lot easier to just read them up in clear text from the chess programming wiki or from discussions at talkchess instead of digging through another code base and extracting them. And from a code base, you don't get the ideas in their "pure" form, but already adapted to the structure and dependencies of a certain code base.
I've also changed the evaluation as per my own chess understanding, that concerns e.g. the pawn structure, which is now closely interrelated with the rook handling.
regards, Rasmus
Hello Rasmus i forgot to ask Is there a small story to the name CT800 or it just sounded like a 'cool' name for a dedicated unit? To my ears it has a nice vintage sounding feel to it :-)
ReplyDeleteHi Lazar,
ReplyDeletethe story is the movie sequels that I've been watching a lot during the development, and it seemed an appropriate acronym for a machine that is designed to be put against humans. Especially since "basic chess psychology is among its subroutines." ;-)
Btw., I'm working on at least a bit more endgame knowledge; the rule of the square for passed pawns is easy enough, and the defence with rook against rook and pawn could be better.
regards, Rasmus
Hello Rasmus,
ReplyDeleteAh..movie sequels.As of now i havent yet quite figured out which movies you are talking about but when i do "I'll be back" here to let you know :-D
Very welcome news that you are adding more endgame knowledge ! I look forward to seeing the extra knowledge in action...in an incremental way at least. ALL THE BEST and hope to hear from you when its ready :-)
Kind Regards
Lazar