Hanlin v3+ application development

[Kryptozoon]

Sorry for jumping in medias res with my first post, but here we go: I've tried pretty much everything else and could not find any help with my problem, which is the following: I'd like to develop native applications (or maybe just one) for the Hanlin v3+, but I do not have the necessary toolchain and SDK. I'm sorry if this is not the right subforum to ask, but I could not figure out a better place for it.

I am aiming at porting a Xiang Qi (a Chinese relative of our chess)-playing application to the ebook reader, as a way to salvage what use remains in the device, now that I use an iPad for reading books. I have found the earliest version of the v3 toolchain and SDK on the Internet a couple of years ago, and although I managed to get it to work and compile Leo's SDK, the resulting binary is simply causing the device to hang, and it can only be restarted after a reset. Seems like the v3 and the v3+ aren't even ABI-compatible. No other versions of the kit appear to be present anywhere on the Internet.

I have also contacted the local distributor, who empathized with my problem but could not help. They proposed that I ask people on mobile reader forums, which I'm doing right now.

The v3+ and perhaps the v3 also have a somewhat limited and utterly undocumented Java virtual machine, which I have investigated deeply enough to have ported a limited version of the program to it. But this VM seems to have a very low size limitation on I don't even know what, perhaps memory left available to code + data after the JVM takes up residence in memory; anyway, it will crash with an out-of-memory entry in the log unless I pack all my data into bytes instead of ints. I plan to complete the port to Java - only the interaction part is missing -, but odds are it won't fit into memory and even if it will, it will run very slowly - thinks for almost a minute on a 4-ply search and although I don't expect to need more depth any time soon, this still seems like too slow, interfering with the joy of the game and depleting the battery like there's no tomorrow. (I have just outfitted the device with a new battery - some counterfeit Nokia, by the sound of it - but I doubt I will be able to do so again in a few years if this battery gets run down due to excessively frequent charging cycles.)

So, bottom line, can someone point me to a toolchain and an SDK (including documentation) suitable for the V3+? Many thanks in advance.

[pdurrant]

You're certainly asking this in the right place. I hope someone can help you. Have you tried asking the manufacturer directly?

[Kryptozoon]

Originally Posted by pdurrant

You're certainly asking this in the right place. I hope someone can help you.

Thanks a lot. Good to know at least I did not miss the proper place; I'm still wondering about the legality of my request, though, since afaik the manufacturer licensed the toolkit in a way that would forbid sharing it, but this limitation is in contravention to the GPL version they started with, so I really don't know where we stand from a legal standpoint.

Have you tried asking the manufacturer directly?

Unfortunately the manufacturer, Tianjin Jinke, went out of business a couple of years ago and I could not figure out whether there's some company who acts as a cessionary for them. I have tried downloading the SDK and miscellaneous other tools they offered while they were still in business but their servers were awfully slow and the download never finished, then my registration stopped working and finally could not register again because the confirmation e-mail never arrived. I have approached the local, Hungarian distributor, but they could not help either, in fact it was them who advised me to turn to Internet fora for help.

[rhari79]

i found some stuff under this link; Maybe could be of help.
https://4pda.ru/forum/index.php?show...ost&p=76948761

[Kryptozoon]

Originally Posted by rhari79

i found some stuff under this link; Maybe could be of help.
https://4pda.ru/forum/index.php?show...ost&p=76948761

Thanks for the link. I've checked out the discussion, but unfortunately it's all about finding various versions of the firmware. Nonetheless there are interesting links and ideas in there, such as:

• someone managed to flash a v3ext with a suitably hacked v3+ firmware, which tells me that maybe, just maybe a very late v3 EABI SDK might work on the v3+. It'd probably lack the ability to control the famous 16 shades of grey of the v3+ but then so does - to some extent - the Java VM. It all depends what the hacking consisted of - if it meant replacing the display driver, then of course this alternative won't work.
• there's a linked repository with lots of versions of the Tirwal and OpenInkpot firmwares. I wonder if I could flash one of those and develop for it instead of the original WolfLinux? Of course I know next to nothing about them, but I'm pretty good with C and Linux, so I'd probably would be able to cope. But since I can only find on the Internet indications that they "don't yet work" on v3+, maybe they really never did? OTOH if these firmwares don't have a v3+ version, then maybe there never was such a thing as a public v3+ SDK?
• a combination of the above: perhaps I should try to flash a regular v3ext firmware and expect it to work? I'd lose whatever extra features the v3+ had, but I never found myself using any of those. Then I'd only need a late v3 SDK ...

Bottom line, I'm now extending my request to include an as-late-as-possible v3 SDK, because I only have the first/earliest version. Thanks in advance for any kind of help.

[Kryptozoon]

While waiting for a miracle here I have finished implementing the game in Java, and it does run - for a low enough value of 'running' - on the ebook reader. I'd need some proper words to describe its performance, but for now we can probably settle on "abysmal". 2-ply search + extending the horizon by one ply at each check, plus a quiescence search along captures + repetition check using Zobrist hashes = sometimes three-four minutes worth of thinking. I'm sure I could tune the algorithm somewhat - e.g. the efficiency of the alpha-beta cutoff depends on a preliminary sorting and I am not at all sure I'm doing it correctly. For now, given how a weak player I am and how I'll use this game mostly amid distractions provided by public transport, I think I'll simply cut back on depths - no horizon expansion, a ten-ply limit even for quiescence search etc. We should be evenly matched, then.

I kept postponing this particular experiment for four years because when I last tried it I kept running into spurious Out of memory errors with it, and the errors seemed to be linked to the amount of static data I had. But it turns out the problem is with JVM initialization, not class loading. Specifically, I need two-three megabytes at most, but since I kept getting the OOM erros, I was trying to set the heap size as high as possible, which is 64 M. Turns out the problem is this heap size - if I set it to 32 M, which is still more than I need, the OOM errors go away.

All this is rather unsatisfactory, so I still hope someone can direct me to the proper SDK. I was told nothing ever disappears from the Internet once it makes it there, but I seem to have stumbled upon a counterexample.

[rhari79]

i have been plodding through the wayback machine.
one interesting link i found relating to v3+:
https://web.archive.org/web/20150923...r=asc&start=20

According to this, v3+ sdk seems same a a v5 sdk.
A suggestion is, try to contact Buggins. He may be able to help.
(github, sourceforge etc.,)
https://github.com/buggins

Failing which,
another suggestion is to create your own toolchain:
something like this, it deals with the exact same processor of the v3+.
https://www.sachinsharma.com/2010/12...hain_7883.html
(might be a real long shot this one)

On other thoughts: why try to develop for such an ancient device?
something like a BQ Cervantes, would be far more easier.
It is supposedly open source and sourcecode etc., all available in github.

[Kryptozoon]

Originally Posted by rhari79

i have been plodding through the wayback machine.
one interesting link i found relating to v3+:
https://web.archive.org/web/20150923...r=asc&start=20

According to this, v3+ sdk seems same a a v5 sdk.
A suggestion is, try to contact Buggins. He may be able to help.
(github, sourceforge etc.,)
https://github.com/buggins

Thank you for the suggestions, especially as they point to a region of the Internet I could not access myself with any efficiency. My Russian studies during my school years were a total waste of time, as I can't read anything without Google Translate and certainly could not search for anything in Russian.
I might have to contact the person in question. I have come across the claim that "v3+ resembles v5 more than v3" but I never thought that the SDK might be not just similar but identical.

Failing which,
another suggestion is to create your own toolchain:
something like this, it deals with the exact same processor of the v3+.
https://www.sachinsharma.com/2010/12...hain_7883.html
(might be a real long shot this one)

Yeah, sounds like something to be tried only in case of desperation, but it is definitely something that can be tried if all else fails. I wonder if the problem is merely the toolchain and whether the libraries work across the early-V3-to-V3+ divide? I guess I'll have to find out the hard way.

On other thoughts: why try to develop for such an ancient device?
something like a BQ Cervantes, would be far more easier.
It is supposedly open source and sourcecode etc., all available in github.

It's something like the sunk cost fallacy in action. I have bought this device almost ten years ago for an exorbitant price, and I'm simply trying to get some further use out of it; otherwise nowadays I'm doing my reading on my phone and on an iPad. The Hanlin is simply a still-working piece of hardware I would not throw out and cannot watch sitting there doing nothing. As long as I can do this with no actual investment except my time (accounted for under the heading 'hobby'), I'm okay with working on it.

On a positive note, the Java version seems to be working better now. I have figured out that quiescence search benefits from alpha-beta pruning too (yeah, sarcasm - I removed the supporting code in a bid to reduce code size, and when it turned out this was not a problem I forgot to re-enable it), and that the way I implemented alpha-beta, contrary to what I said earlier, is doing a very good job cutting down execution time - the long waits were due to quiescence search being done in a full minimax fashion, and basic search would have exploded similarly if not for alpha-beta. (On the flip side this also means the Java VM is even slower than I originally thought.) Now the program replies in a few seconds, rarely reaching 5s, and it also seems to play reasonably well (time to time it beats Zillions of Games with decent search depth settings - it's kind of a rock-paper-scissors situation, as I can beat the reader, the reader can beat Zillions and Zillions can beat me; sounds like our weaknesses line up in a funny way). So if all else fails, I'll stay with this implementation at least until I learn its quirks and weaknesses to the point that I cannot fix them but get bored with beating it due to knowing them.

[menneske]

I still have one of these - the L-book - and maybe also some software/firmware from those days too (if any interest).

It still holds a charge, but unfortunately the #2 button does not work anymore, and I have not had the energy to seek out a solution.