JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RM/RMIR v2.03 available
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Mon Aug 10, 2015 9:27 pm    Post subject: Reply with quote

mathdon wrote:
ncoig wrote:
If you take the "plug-in and walk around the house" time out of it, wow...

Are you aware of the IR Widget? None of my development testing is done against real devices, it is all done by reading the signals with an IR Widget, which shows you exactly what is being sent by the remote. Despite information in other threads to the contrary, IR Widgets are still available. Google "ir widget (infrared signal recorder/decoder)" exactly like that, including the part in brackets but omitting the quotation marks. The top entry returned tells you how to get one, the second entry gives you a lot more details of what it does.


I wasn't aware of that in this context, no, and it looks useful -- however, that still wouldn't really show macro execution as an emu could. Imagine a disassembler-type interface where you step through the macro and the "virtual" remote shows what it's doing. You then could see exactly where it stops, the duration, etc. Again, this is in a fantasy world where development of this would be easy and effortless. I have gotten more than I could ask for with the perfect timing of your 6540 extender right when I start futzing with these remotes again, so I'm a happy camper. Smile

-N
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 834

PostPosted: Tue Aug 11, 2015 1:54 am    Post subject: Re: Some requests / bugfixes - totally non-essential Reply with quote

ncoig wrote:
Barf wrote:

I asked the same question here. But there are also potential legal problems, since a useful emulator has to ether contain UEI rom code, or re-engineer it.


Fiddlesticks. Console video games have long been emulated, and the emulators never contain the ROMs. Those have to be, ahem, self-procured. Legal quandary solved. Sure, sure, one could make the argument for contributory infringement, but I have never once heard of Nintendo, TI, or any other company blazing a path to some open source programmer's house over an emulator...


First, do not get me wrong; I am not "against", nor saying that it cannot be done, I am just pointing at some potential problems.

Your arguments are very general, and it is not at all clear to the extent they appy to the current use case. (They wanted to proved a platform that could execute Tomb raider etc, we want to analyze existing code.) I know of at least some emulators that required the user to supply his own copy to the ROM of the machine to be emulated: that is another alternative, although I think it is not immune to legal problems.

To be able to emulate/test/debug the UEI executors we need them extracted. Of course, they can be re-engineered, but then we are testing our code, not the one using for deployment....

But it may be doable. I suggest using a platform like Netbeans or Eclipse, not repeating the Arduino IDE mistake... First thing would be to find out if there is some decent chip emulator around, under an acceptable license.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Tue Aug 11, 2015 3:05 am    Post subject: Reply with quote

mathdon wrote:
ncoig wrote:
If you take the "plug-in and walk around the house" time out of it, wow...

Despite information in other threads to the contrary, IR Widgets are still available. Google "ir widget (infrared signal recorder/decoder)" exactly like that, including the part in brackets but omitting the quotation marks. The top entry returned tells you how to get one, the second entry gives you a lot more details of what it does.


So, am I to understand that Tommy vacated this forum as part of his political leanings but he still sells via that link in the search you propose? It's all I can piece together of the threads that are extant.

-N
Back to top
View user's profile Send private message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Tue Aug 11, 2015 3:31 am    Post subject: Re: Some requests / bugfixes - totally non-essential Reply with quote

Barf wrote:
Your arguments are very general, and it is not at all clear to the extent they appy to the current use case. (They wanted to proved a platform that could execute Tomb raider etc, we want to analyze existing code.) I know of at least some emulators that required the user to supply his own copy to the ROM of the machine to be emulated: that is another alternative, although I think it is not immune to legal problems.


Well, we can get as specific as you like... and I think the 'alternative' you suggest is precisely what I stated:

ncoig wrote:
the emulators never contain the ROMs. Those have to be, ahem, self-procured. Legal quandary solved.


As to the specificity:

First, we can start with the premise that there is no legal prohibition on reverse engineering anything, this much we know. There are some instances where as part and parcel of a license agreement, users may forego that right, but click-wrap, shrinkwrap, etc. licenses which suggest a user give up rights like that are tenuous at best, and I'd argue, somewhat contacts of adhesion. I see nothing in the OFA/URC remotes that I've purchased new that indicate any prohibition on the decompilation/examination/reversing of any remote, so that would seem to be a non-issue; thus we would move to the issue of any possible IP in the code.

The content of the URC/OFA chips MAY be copyrighted/registered with the LoC. The enforceability of this copyright in an infringement setting is also dependent on the age of the registration, which, given the likely age of these processors, would be within the author's life, or the span given to entity-assignees of copyright. Assuming a valid copyright exists in that regard, we then move to the notion that (C) is only valid for the code - not the concept - of the chip. This becomes relevant moreso in the discussion below on the distro, as unless there is a "substantial similarity" (read: copy) of the URC code, there would presumably be no infringement.

If these "works" are *not* registered (I see no notice on these remotes of such, though that is not *necessarily* a pre-requisite for an infringement suit), but there remains a valid copyright by vested in the author or an assignee, then any damages OFA/URC could theoretically seek would be limited to actual damages, which, in our pursuits here on JP1, would likely be de minimis. This scenario is only even a consideration IF the ROM were to be distributed with the Java/RoR/whatever distro. Distributing a program which utilizes a ROM absent from the software is not a copyright violation, IMHO.

In the other instance, or what I would suggest, wherein the emu is distributed naked, and the ROM(s) are procured by the user either through the downloading of the ROM themselves from a device they own, and presumably have the right to reverse engineer, or through the typical, "on the DL" channels of Bittorrent/etc., then the author is not distributing anything that would violate the presumed copyright in the OFA/URC chips.

This returns us to my passing reference to contributory or inducing infringement, which would be, in my estimation, a flimsy claim to make against the author of an emu in this context, unless perhaps the distro included code to strip the URC/OFA executor out of a remote -- but even then... In sum, I think the copyright issue... isn't. Heck, distributing images of the remotes is probably a more blatant copyright infringement than building an emu.

Further still, I see nothing on my recent purchases that indicates any patent protection on the device internals, so I don't see that as an issue, either.

So, I would theorize that based on the above, and precedent with other emus of similar ilk, that suggesting legal issues are a non-starter, is, in and of itself, a non-starter.

Specific enough? Smile

-N

OBLIGATORY DISCLAIMER: THIS SHOULD NOT BE CONSTRUED AS LEGAL ADVICE AND IS ONLY PROFERRED AS PART AND PARCEL OF A GENERALIZED DISCUSSION ON THEORETICAL CONCEPTS
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 834

PostPosted: Tue Aug 11, 2015 10:33 am    Post subject: Reply with quote

Again, I am not trying to prove or push a point, so I am not sure if you are arguing against me. BTW, I have been doing quite some work in a similar project.

Be sure to tell me if/when you are starting the project! Cool
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Tue Aug 11, 2015 12:59 pm    Post subject: Reply with quote

Barf wrote:
Again, I am not trying to prove or push a point, so I am not sure if you are arguing against me. BTW, I have been doing quite some work in a similar project.

Be sure to tell me if/when you are starting the project! Cool


Not in the least -- just trying to pave the way for those who might think they should be dissuaded for legal reasons, lol.

-N
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2970
Location: Cambridge, UK

PostPosted: Tue Aug 11, 2015 1:09 pm    Post subject: Reply with quote

ncoig wrote:
perhaps an option to turn off help tips or at least adjust that time to like 2 seconds, or make it variable in a setting?

I have made the delay before tooltips appear be freely settable through a new entry in the Options menu. This will be in the next build. I'm not entirely happy with an option to turn tooltips off completely, so have not added that. I don't want users posting queries that would have been answered if they had seen relevant tooltips.
_________________
Graham
Back to top
View user's profile Send private message
pH7_jp1



Joined: 14 Sep 2003
Posts: 457
Location: Sterling Heights, MI

PostPosted: Tue Aug 11, 2015 8:25 pm    Post subject: Reply with quote

Quote:
I have made the delay before tooltips appear be freely settable through a new entry in the Options menu. This will be in the next build. I'm not entirely happy with an option to turn tooltips off completely, so have not added that. I don't want users posting queries that would have been answered if they had seen relevant tooltips.
This is a welcome change. Thank you very much.
Back to top
View user's profile Send private message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Tue Aug 11, 2015 9:04 pm    Post subject: Reply with quote

mathdon wrote:
ncoig wrote:
perhaps an option to turn off help tips or at least adjust that time to like 2 seconds, or make it variable in a setting?

I have made the delay before tooltips appear be freely settable through a new entry in the Options menu. This will be in the next build. I'm not entirely happy with an option to turn tooltips off completely, so have not added that. I don't want users posting queries that would have been answered if they had seen relevant tooltips.


Very nice! Thank you, kind sir.

Your rationale is very understandable.

-N
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2970
Location: Cambridge, UK

PostPosted: Thu Aug 13, 2015 8:44 am    Post subject: Reply with quote

I have now posted build 8 of RMIR v2.03. This new build is available both as a complete installation file and as an upgrade to any of the earlier builds, both from the link just given. Note that build 7 was not publicly released, so this is the first update since build 6.

The main changes from build 6 are:
  • Ability to adjust the delay before tooltips appear, through new item on Options menu
  • Inclusion of RDFs for Extender v1.04 for URC-6440 and OARUSB04G
  • Support for global Special Functions, required for these two extenders
  • Corrected entries for TiVo protocol in protocols.ini
Please note that Extender v1.04 for the URC-6440 and OARUSB04G requires build 8 of RMIR. Its support for global Special Functions is not compatible with earlier builds.
_________________
Graham
Back to top
View user's profile Send private message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Fri Aug 14, 2015 10:33 pm    Post subject: Reply with quote

mathdon wrote:
I have now posted build 8 of RMIR v2.03.


Cool
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3383
Location: UK/USA

PostPosted: Tue Sep 08, 2015 1:00 pm    Post subject: Reply with quote

I'm now getting an odd problem, not sure if it is Windows 10 related.

Using RM V2.03 Build 8 (although it has been there since Build 1), if I export a Satellite (S) BIN file using a 'normal' Protocol, but then import it it shows up as using Protocol PID: 01 2A with 6 device parameters.

Cable and VCR BIN files export and import as expected.

Anyone else able top reproduce this ?
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3383
Location: UK/USA

PostPosted: Wed Sep 09, 2015 4:59 am    Post subject: Reply with quote

Further investigation is showing that the Export function is working OK, it is the Import function that is broken. As an example, if I import an S2010 file the 'Device Upgrade Code' on the Output tab of RM correctly shows:

Upgrade Code 0 = 3F DA (SAT/2010) (RM v2.03 build 8)
2A 00 F2 74 F2 20 00 FC 00 00 05 E................

But the Setup Tab decodes that as PID: 01 2A and the six Device codes are :

226
128
72
38
0
1
2


Make sense to anyone ?
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2970
Location: Cambridge, UK

PostPosted: Wed Sep 09, 2015 6:02 am    Post subject: Reply with quote

alanrichey wrote:
Make sense to anyone ?

Alan, you haven't given enough info for it to make sense.

Quote:
Upgrade Code 0 = 3F DA (SAT/2010) (RM v2.03 build 8)
2A 00 F2 74 F2 20 00 FC 00 00 05 E................

certainly corresponds to PID 012A, but the device parameter data starts where you finished, with the E... . I presume this continues E2 80 48 26 00 01 02, as this would correspond to the 6 device parameters you list, but 6 is a big puzzle. In protocols.ini there are two variants protocols with PID=012A, one with 4 fixed bytes and the other with 8, so how you have 6 is a mystery.

I know nothing of binary upgrades, but if you post the BIN file concerned, I will try to look into it.
_________________
Graham
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3383
Location: UK/USA

PostPosted: Wed Sep 09, 2015 8:12 am    Post subject: Reply with quote

Thanks. See http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13535

This has the original RMDU file for a Sky box and the PL BIN file it produces. All OK. But if I try and import that BIN file back into RM then I get the PID: 01 2A and 6 device codes, rather than the RC6-M-20, with M=6 and device 5:12

Any help ?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 3 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central