hap,
there's a problem with the chess plugin for ssystem4.
Since the driver code (and also the LCD screen) for ssystem3 and ssystem4 are identical (except one additional line 'm_display->set_segmask(0xf, 0x7f)' for ssystem3), I assumed that the plugins could be the same, too.
But it seems the plugin can't read the 7seg digits in ssystem4, at least not just in the same way as in ssystem3.
For ssystem3 the plugin code is:
Code:
function interface.is_selected(x, y)
local xval = { 0x77, 0x7c, 0x39, 0x5e, 0x79, 0x71, 0x3d, 0x76 }
local yval = { 0x06, 0x5b, 0x4f, 0x66, 0x6d, 0x7d, 0x07, 0x7f }
local d0 = machine:outputs():get_value("digit3")
local d1 = machine:outputs():get_value("digit2")
local d2 = machine:outputs():get_value("digit1")
local d3 = machine:outputs():get_value("digit0")
return (xval[x] == d0 and yval[y] == d1) or (xval[x] == d2 and yval[y] == d3)
end
The digits in both devices are identical, so I can only guess, that the problem may be the names "digit3".."digit0" - are they different for the ssystem4?
I don't see these name anywhere in the driver and also not in the 2 SVG files - I've compared the 2 SVGs and I see there only different numbers for
"title id="titleXXX" ... Y.Z title", but I have no idea about these numbers or what they may have to do with these digit names "digitX".
Can you tell me which names I have to use for the 4 digits in the plugin?
Edit: Ok, with InkScape I found now the reason for the problem. The single segments of the digits are numbered in a chaotic way, not only are they NOT in the usual bit order (0,1,...6) for a single digit (which could be solved by different letter/digit codes in the plugin), but also the 1st number (usually the digit number) is mixed among the different digits!
What an idiotic coding of these LCD digits - I've no idea how I should solve this!