tilem-devel — Discussion of TilEm development

Re: [TilEm-devel] Some nspiring thoughts

[Thibault D. <t.d...@gm...>]

Hi guys.


I have not many time recently that's why I answer so later...
I hope you spend nice holidays (while your skiing week for luc).


Benjamin : ACK for the nspire.
I will not attempt to disassemble or decompile it


The gui-qt is really nice. The visual feedback is really impressive.
Your work is great Luc.

I hope I can help you soon.

About the GTK gui :

I've commited a completely new gui.
It use tiemu/vti skin format (actually you can test with the tiemu skin
--ti89.skn ti89t.skn ti92.skn--)
You can easily change the skin with the right click menu (it works
perfectly)

A preliminary msg box (loaded immediately when tilem is started) allow to
choose the kind of rom (like you suggest Benjamin)
But it don't wait the answer of the user... so it is not used actually just
printed ;D (I will add an event waiting while soon)

The lcd is added in the window (automatically even when we change skin)

The core is semi connected.
I have tried to use the testemu.c code.
The core_thread seems to be OK (the state changes correctly I think) but
nothing is printed on the LCD screen.

Simply write into the lcd is OK :
For the debug, I reached to print line and change pixels when clicking on
the "ON" button. (on the ti89.skn)

There 's a lot of work to make all this properly (even it's not really ugly
;D).

You should maybe test this new gui.
For the code, you should maybe wait a little time because I will try to
finish to connect the core soon and make all this properly.

But your help is welcome even !

Benjamin : This gui is a better start for the gtk gui. I hope it will please
you.
I wait for your feedback.
I will probably need your help if I can not connect the core in the next
week.


Luc : your gui is really nice.
I will try to learn Qt4 in parallel of the GTK developpement.
The gui is very promising !
Your skills are precious.
The gui could be compiled on Windows actually?


Thibault Duponchelle

Re: [TilEm-devel] Some nspiring thoughts

[luc b. <non...@gm...>]

Hi Benjamin,

Having a Nspire-like emulation would indeed be extremely useful to ensure
cross-platform-ism of assembly programs.

I used to have troubles with linking on a 84+ ram but exclusively with TIOS
and it appears that this bug vanished after I reworked the networking code.
Right now here's what works :
 * emulated calc <-> emulated calc
 * pc (drag'n'drop) -> emulated calc
 * pc (tilp and other ticables based softs) <-> emulated calc
I'd like to add real calc <-> emulated calc but there are other items with
higher priority on my tod list (e.g UI to manage connections and debuger).

As for Nspire-related IP-issues : I have unencrypted/disassembled a version
of the Nspire OS just for the fun of testing the process but I did not do
anything
with the result because I lack time and ARM-knowledge for that. Besides,
if I only contribute to TilEm GUI I don't think even the most skilled lawyer
could ever use that against us but I'll keep your warning in mind and stay
away from Nspire OS.

I'll be enjoying a week of skiing with my family (it is quite rare for us to
be
together these days...) so I won't be very responsive either. I wish you to
spend pleasant holidays.

Luc

[TilEm-devel] Some nspiring thoughts

[Benjamin M. <flo...@us...>]

Hi guys,

I've committed some preliminary code to support emulating the Nspire's
TI-84+ emulation mode.  It still needs some work (someone needs to
work out the correct behavior of all the EDED opcodes, and I'm
guessing that the current I/O emulation is far more detailed than what
the Nspire actually supports.)  Also, linking doesn't seem to work -
Luc, I think you mentioned you were having a problem with linking with
the regular 84+; was that issue ever resolved?

Somewhat relatedly... I'm sure you're both aware that some folks have
recently managed to decrypt the Nspire's OS.  I probably should have
mentioned this earlier, but if you happen to have a copy, then,
please, do *not* attempt to disassemble or decompile it.  We need to
ensure that no part of TilEm could be considered a derivative work of
TI's copyrighted OSes, and the best way to be sure of that is to avoid
looking at any of TI's code.  (This is particularly a worry for the
Nspire because what TilEm does is quite similar to what the Nspire's
OS does.)

I'm going to be off visiting relatives next week, so if I don't have a
chance to email before then, enjoy your winter-solstice holiday(s) of
choice. :)

Benjamin

Re: [TilEm-devel] TilEm GUI

[luc b. <non...@gm...>]

> While we're talking about possible new features for skin formats,
> another idea that occurred to me is that it would be nice to give some
> visual feedback to indicate which keys are being pressed.  This could
> be done using a second image file, or perhaps (since creating a second
> image would be a lot of work) we could simply draw a dotted rectangle
> around the key.  Maybe this could be combined with the key mask file
> somehow.
>
I had thought about this but did not find time to try implementing it. I'll
see
what can be done.


> Luc, you suggested that perhaps we could define a skin using multiple
> files combined in a zip archive.  That's also an interesting idea, but
> if it means adding yet more libraries to the list of dependencies, I'd
> be inclined to say forget about it.  Does Qt include a zip-file
> reading library?
>
Qt does include zip compression/decompression but I'm not sure how
it behaves with a filesystem in the zip so I'll investigate and keep you
informed.

It's not very well documented.  libticables2 supports a rather limited
> sort of virtual linking: there is one "virtual cable" with two
> endpoints that programs may connect to.  Normally, you should use 0 as
> the port number, which will attempt to connect to whichever endpoint
> is not currently in use.  If both endpoints are already in use,
> ticables_cable_open() will fail.
>
> (The original libticables did not support auto-detecting which port to
> use, so port 1 was designated as the "emulator" port and port 2 as the
> "TiLP" port.  You can still use port 1 or 2 manually, for
> compatibility with older programs, but it's not recommended.)
>
I had a look at TilEm 0.973 source code and tried to understand how it
worked. Now that you brought certainty to some of my suspicions
I think I can get it to work relatively easily.

One think that I'm still unsure about is whether linking the emulator to
a real calc is (reasonably) feasible (i.e I don't want to rewrite half of
TILP).

cheers

luc

Re: [TilEm-devel] TilEm GUI

[Benjamin M. <flo...@us...>]

About skin files:

> We are talking about border transparency, not general transparency,
> isn't it?
> I heard that VTI reads 2 times the image.
> The second times, he deliberately decided to ignore the parties
> united.
> citation :
>
> "VTI uses a very basic algorithm: if the entire edge of the image (1
> pixel all around) has nearly the same color, VTI reads each line of
> the image 2 times starting from the left and right, and note as
> transparent all pixels with almost the same color - it stops on each
> line to 1 pixel that fails the test: the party line will be visible
> unread"
>
> I'm not sure that's true !
> (but I have good reason to believe it)

That's interesting (and rather strange.)  So, no, not very
general... and if you're using JPEG compression, I'm surprised that it
works at all!

For some skins, PNG format might work well.  For others, it might be
better to stick with a JPEG image for r/g/b and use a second,
grayscale PNG image for alpha.

While we're talking about possible new features for skin formats,
another idea that occurred to me is that it would be nice to give some
visual feedback to indicate which keys are being pressed.  This could
be done using a second image file, or perhaps (since creating a second
image would be a lot of work) we could simply draw a dotted rectangle
around the key.  Maybe this could be combined with the key mask file
somehow.

Luc, you suggested that perhaps we could define a skin using multiple
files combined in a zip archive.  That's also an interesting idea, but
if it means adding yet more libraries to the list of dependencies, I'd
be inclined to say forget about it.  Does Qt include a zip-file
reading library?

About linking:

>> (Do note, however, that we still ought to allow libticables2 virtual
>> linking, as I find it very useful on occasion to test communication
>> with TiLP itself, or with my own protocol testing programs.)
>
> Question : how do I do that? I mean : what is the process required
> to advertise the existence of a virtual calc that might be reached
> by TiLP and how do I test that using TiLP?

It's not very well documented.  libticables2 supports a rather limited
sort of virtual linking: there is one "virtual cable" with two
endpoints that programs may connect to.  Normally, you should use 0 as
the port number, which will attempt to connect to whichever endpoint
is not currently in use.  If both endpoints are already in use,
ticables_cable_open() will fail.

(The original libticables did not support auto-detecting which port to
use, so port 1 was designated as the "emulator" port and port 2 as the
"TiLP" port.  You can still use port 1 or 2 manually, for
compatibility with older programs, but it's not recommended.)

libticables2 on Windows is also supposed to support virtual linking
with VTI; I don't know how well this works.

Benjamin

[TilEm-devel] TilEm skin format

[Thibault D. <t.d...@gm...>]

Hi guys,

>Regarding skin formats:

>> I agree that being compatible with an existing skin format wouyld be nice
>> however I have some complaints about the VTI/TiEmu skin format :
>>  * it's binary yet doesn't enforce a specific endianness but just somehow
assume
>> that designers use little endian

>So you swap the bytes if need be.  In the case of VTI it's always
>little-endian, because to my knowledge, VTI has only ever been used on
>little-endian machines.  In the case of TiEmu, there's a flag to tell
>you which format it's in.  Not ideal, maybe, but it works just fine.

That's the piece of skinops.c (from TiEmu) to illustrate the swap :

if (endian != ENDIANNESS_FLAG)
    {
        si->colortype = GUINT32_SWAP_LE_BE(si->
colortype);
        si->lcd_white = GUINT32_SWAP_LE_BE(si->lcd_white);
        si->lcd_black = GUINT32_SWAP_LE_BE(si->lcd_black);


        si->lcd_pos.top = GUINT32_SWAP_LE_BE(si->lcd_pos.top);
        si->lcd_pos.left = GUINT32_SWAP_LE_BE(si->lcd_pos.left);
        si->lcd_pos.bottom = GUINT32_SWAP_LE_BE(si->lcd_pos.bottom);
        si->lcd_pos.right = GUINT32_SWAP_LE_BE(si->lcd_pos.right);


        for (i = 0; i < (int)length; i++)
        {
            si->keys_pos[i].top = GUINT32_SWAP_LE_BE(si->keys_pos[i].top);
            si->keys_pos[i].bottom =
GUINT32_SWAP_LE_BE(si->keys_pos[i].bottom);
            si->keys_pos[i].left = GUINT32_SWAP_LE_BE(si->keys_pos[i].left);
            si->keys_pos[i].right =
GUINT32_SWAP_LE_BE(si->keys_pos[i].right);
        }
    }




>It is a major benefit to have everything contained in *one* file.

>>  * it forces the use of jpeg. Besides the fact that I generally don't
like such a
>> technological lock it's a shame to be deprived of transparency

>Interesting point.  But doesn't VTI format support transparency? How
>does that work?

We are talking about border transparency, not general transparency, isn't
it?
I heard that VTI reads 2 times the image.
The second times, he deliberately decided to ignore the parties united.
citation :
"VTI uses a very basic algorithm: if the entire edge of the image (1 pixel
all around) has nearly the same color, VTI reads each line of the image 2
times starting from the left and right, and note as transparent all pixels
with almost the same color - it stops on each line to 1 pixel that fails the
test: the party line will be visible unread"

I'm not sure that's true !
(but I have good reason to believe it)


>I think this is an area where we can and should encourage more
>compatibility between the various emulators.  If there are compelling
>new features that we can't get with the existing formats, then perhaps
>we should be trying to improve those formats, ideally in a
>backwards-compatible way.

>In any case, I guess I'm not opposed to creating a new format (so long
>as it's well documented and easy for other programs to work with) but
>I really would like to see TilEm able to use files in the older
>formats.

Lot of users use skins perso (or replace default skins by another got on the
web).
Have a big number of skins (already created), could make it easily (with a
good precision of the key), could switch it easily are important feature
request.
So a new skin format who separate image and key place could be an
 unnecessary additional difficulty.



Best regards.

PS: I send this mail 2 times for luc :D

Thibault Duponchelle

[TilEm-devel] TilEm skin format

[Thibault D. <t.d...@gm...>]

Hi guys,

>Regarding skin formats:

>> I agree that being compatible with an existing skin format wouyld be nice
>> however I have some complaints about the VTI/TiEmu skin format :
>>  * it's binary yet doesn't enforce a specific endianness but just somehow
assume
>> that designers use little endian

>So you swap the bytes if need be.  In the case of VTI it's always
>little-endian, because to my knowledge, VTI has only ever been used on
>little-endian machines.  In the case of TiEmu, there's a flag to tell
>you which format it's in.  Not ideal, maybe, but it works just fine.

That's the piece of skinops.c (from TiEmu) to illustrate the swap :

if (endian != ENDIANNESS_FLAG)
    {
        si->colortype = GUINT32_SWAP_LE_BE(si->colortype);
        si->lcd_white = GUINT32_SWAP_LE_BE(si->lcd_white);
        si->lcd_black = GUINT32_SWAP_LE_BE(si->lcd_black);


        si->lcd_pos.top = GUINT32_SWAP_LE_BE(si->lcd_pos.top);
        si->lcd_pos.left = GUINT32_SWAP_LE_BE(si->lcd_pos.left);
        si->lcd_pos.bottom = GUINT32_SWAP_LE_BE(si->lcd_pos.bottom);
        si->lcd_pos.right = GUINT32_SWAP_LE_BE(si->lcd_pos.right);


        for (i = 0; i < (int)length; i++)
        {
            si->keys_pos[i].top = GUINT32_SWAP_LE_BE(si->keys_pos[i].top);
            si->keys_pos[i].bottom =
GUINT32_SWAP_LE_BE(si->keys_pos[i].bottom);
            si->keys_pos[i].left = GUINT32_SWAP_LE_BE(si->keys_pos[i].left);
            si->keys_pos[i].right =
GUINT32_SWAP_LE_BE(si->keys_pos[i].right);
        }
    }




>It is a major benefit to have everything contained in *one* file.

>>  * it forces the use of jpeg. Besides the fact that I generally don't
like such a
>> technological lock it's a shame to be deprived of transparency

>Interesting point.  But doesn't VTI format support transparency? How
>does that work?

We are talking about border transparency, not general transparency, isn't
it?
I heard that VTI reads 2 times the image.
The second times, he deliberately decided to ignore the parties united.
citation :
"VTI uses a very basic algorithm: if the entire edge of the image (1 pixel
all around) has nearly the same color, VTI reads each line of the image 2
times starting from the left and right, and note as transparent all pixels
with almost the same color - it stops on each line to 1 pixel that fails the
test: the party line will be visible unread"

I'm not sure that's true !
(but I have good reason to believe it)


>I think this is an area where we can and should encourage more
>compatibility between the various emulators.  If there are compelling
>new features that we can't get with the existing formats, then perhaps
>we should be trying to improve those formats, ideally in a
>backwards-compatible way.

>In any case, I guess I'm not opposed to creating a new format (so long
>as it's well documented and easy for other programs to work with) but
>I really would like to see TilEm able to use files in the older
>formats.

Lot of users use skins perso (or replace default skins by another got on the
web).
Have a big number of skins (already created), could make it easily (with a
good precision of the key), could switch it easily are important feature
request.
So a new skin format who separate image and key place could be an
unnecessary additional difficulty.



Best regards.

Thibault Duponchelle