 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
robert
Joined: 27 Mar 2004
Posts: 6
|
 Posted: Sat Mar 27, 2004 11:54 pm Post subject: |
 |
|
How is IR.exe different from RM.exe?
I found libDelcom.pas in the IR.exe tarball. This contains the Delcom USB communication code. In the USBIODS.pdf (Delcom's DataSheet on the USB chip) pg 7, it states that commands are sent to the chip using DeviceIOControl Windows function in the Setupapi.dll (which is effectively sending raw data commands to the USB chip) OR "you can use the DelcomDLL which has specific functions already defined". It looks like the libDelcom uses the DeviceIOControl function, so it is NOT using the DelcomDLL, is this correct? |
|
| Back to top |
|
 |
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sun Mar 28, 2004 12:23 am Post subject: |
|
|
| robert wrote: | | How is IR.exe different from RM.exe? |
The two programs perform different tasks.
IR uploads and downloads the I2C EEPROM in the remote, and interprets & modifies the data based upon remote charateristics defined in an .rdf file.
RM is a recent development that is attempting to do what the KM Excel spreadsheet does in a platform-independent way. Both RM & KM generate device upgrades that are pasted into the IR program, which then inserts them into the EEPROM image. The author(s) of RM have hopes that someday the functions of the IR program can be integrated into RM, but it's not yet to that point. | robert wrote: | | I found libDelcom.pas in the IR.exe tarball. This contains the Delcom USB communication code. In the USBIODS.pdf (Delcom's DataSheet on the USB chip) pg 7, it states that commands are sent to the chip using DeviceIOControl Windows function in the Setupapi.dll (which is effectively sending raw data commands to the USB chip) OR "you can use the DelcomDLL which has specific functions already defined". It looks like the libDelcom uses the DeviceIOControl function, so it is NOT using the DelcomDLL, is this correct? |
You are correct that it is not using the Delcom DLL.
As you have probably noted, IR is written in Delphi. There are not too many Delphi programmers around here (I'm not one of them), so very few people are in a position to answer your questions about the inner workings of IR. I will say, in the spirit of fair warning, that things are not as simple as they seem. All of the basic JP1 tools (IR, RM & KM) put on a pretty face, but there is a lot of intricate code going on behind the scenes to make it all look simple. For example, even the (relatively) straighforward task of downloading the EEPROM is complicated by routines that attempt to automatically determine the EEPROM size.
_________________
Mike England |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Mar 28, 2004 12:42 am Post subject: |
|
|
| mr_d_p_gumby wrote: | | I will say, in the spirit of fair warning, that things are not as simple as they seem. All of the basic JP1 tools (IR, RM & KM) put on a pretty face, but there is a lot of intricate code going on behind the scenes to make it all look simple. For example, even the (relatively) straighforward task of downloading the EEPROM is complicated by routines that attempt to automatically determine the EEPROM size. |
That's actually very true. Even though JP1 may seem intimidating at first to some newcomers, they very quickly find that it's actually very easy to use. But behind the scenes, KM, RM and IR are doing some pretty impressive stuff. Before RM came along, many people would complain about needing to buy Excel in order to use KM and many people have volunteered to write a replacement program (assuming it would be easy) only to discover that that's not the case, and then they quietly disappear. That is until Greg Bush came along and headed up the RM project and I bet if you ask him he'll tell you he had no idea what he was getting into! 
But, that all being said, if you can find a way to port the existing programs over to the Mac platform and make them work, you shouldn't need to worry about the inner workings, all you should need to worry about (in theory at least) is changing the logic that talks to the various ports.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
robert
Joined: 27 Mar 2004
Posts: 6
|
| Posted: Sun Mar 28, 2004 8:51 am Post subject: |
|
|
I've heard of Delphi, I THINK that's just the name of Borland's development environment; looking at it, it looks like Pascal (it's been 15 years since I'ver written any Pascal).
It's not to difficult to read the code and see exactly what it's doing (well, I only looked at the Delcom file). If the rest of the files are like the Delcom file, it should be pretty easy to port. I would not ever consider redesigning the code unless it was so horribly convoluted that no one but the author knows it -- but IR.exe doesn't appear to be that way.
I'm going to have to buy the cable parts and get that built first though so I can have something to test against. |
|
| Back to top |
|
|
alex750
Joined: 14 Sep 2003
Posts: 70
Location: Fayetteville AR USA
|
| Posted: Sat Sep 11, 2004 12:22 am Post subject: Delphi and....Pascal? |
|
|
So Delphi is "just" a Pascal dialect, eh? That's a bit of luck...or maybe not!
'Back in the day' before the dominance of C, Pascal was the language of choice for Mac developers (circa 1991/System 7.0). One had two choices: Apple's own MPW (about $800), or Symantec's THINK Pascal (about $250). I had the latter, natch.
The problem is that Pascal, like BASIC, was never intended to be a general purpose programming language, and it showed. There were some rather large differences between the MPW and Symantec versions; one whole volume of the Symantec docs dealt just with porting code from one to the other. And this was the same language, on the same platform!
Now fast-forward to OS X's "Macintized" NetBSD/GNU environment. While GNU have a Pascal compiler available, it's most likely not up to the same standard as its C, C++, or Objective counterparts, and (my guess) probably isn't in the standard OS X Developer install. Which would mean building a Pascal compiler from C source, before even starting on IR and translating Windows OS and device calls to their Mac equivalents, building a Mac interface, and--oh yes--writing that all-important I2C driver, probably in the form of a separate kernel extension. Ouch!
And I don't even want to know about assembly. As far as the PowerPC is concerned, Intel x86 assembly is an ugly rumor. 
In other words, "porting" would mean starting over from scratch--something perhaps only IR's original developer could do, from what I surmise.
I'm glad I found that old PC in the dumpster!  |
|
| Back to top |
|
|
pgk
Joined: 21 Aug 2004
Posts: 113
Location: London
|
| Posted: Sat Sep 11, 2004 2:24 am Post subject: |
|
|
| Quote: | | it should be pretty easy to port |
I would agree porting the logic is potentially fairly easy (I've used delphi a fair bit, but not looked at the IR code so don't know how it's been put together), copying/recreating the user interface etc. would quite possibly be painful. And debugging of course would be an issue.
But assuming you did go through with that, you'd end up with a port of IR as it is now. You'd then have to keep further development going to keep it up to date.
If you were going to put all that effort in, it would seem better directed into cross-platform development, like say RM. (java+swing I think) |
|
| Back to top |
|
|
alex750
Joined: 14 Sep 2003
Posts: 70
Location: Fayetteville AR USA
|
| Posted: Sat Sep 11, 2004 9:05 pm Post subject: Building a Mac UI |
|
|
| Quote: | | I would agree porting the logic is potentially fairly easy (I've used delphi a fair bit, but not looked at the IR code so don't know how it's been put together), copying/recreating the user interface etc. would quite possibly be painful. |
The "painful" part would probably be translating Windows UI calls to their Mac equivalents. Actually building those elements--windows, menus, dialogs, and so forth--is the easy part, using either ResEdit (in Classic) or Interface Builder (in OS X). These work very much like an image editor (e.g., Gimp, Photoshop, etc.)!
Also, the Mac UI is very much more standardized, and UI code can generally be used "off the shelf" from any application's source with appropriate modifications.
That said...
| Quote: | | But assuming you did go through with that, you'd end up with a port of IR as it is now. You'd then have to keep further development going to keep it up to date. |
Which would mean keeping up with the Windows source, and possibly merging the Mac and Windows (and LinuxPPC, Alpha, StrongARM, etc., etc.) code bases into a common "development tree" (or "devtree," in Open Source parlance). Eventually, you'd probably want to set up a CVS system for contributors.
That's already the case for RM, except--RM being Java--there's only one code base for it: the Java VM.
I'll agree a Java solution is looking better and better, but there's still the issue of speed and USB access... |
|
| Back to top |
|
|
pgk
Joined: 21 Aug 2004
Posts: 113
Location: London
|
| Posted: Sun Sep 12, 2004 3:25 am Post subject: |
|
|
| Quote: | | ..be translating Windows UI calls to their Mac equivalents |
Yes, I wasn't really refering to the look of the thing, more the interaction between the interface and the underlying logic. Most Delphi code won't call the Windows UI directly, but uses the supplied component library (VCL/CLX). It also behaves like many graphical langugages and is event driven, this has the side effect that many applications end up with "business logic" intertwined with the UI logic. (Again I haven't looked at IR so don't know how it's written/structured)
| Quote: | | still the issue of speed and USB access... |
Not sure I understand what speed issue you are referring to. As for hardware access going the java route would probably mean having a very small amount of non-java machine specific code accessed through JNI, this should be fairly well defined and thus not need changing often. |
|
| Back to top |
|
|
classicsat
Joined: 20 Feb 2004
Posts: 279
|
| Posted: Sun Sep 12, 2004 9:43 am Post subject: |
|
|
A good deal of the USB chips (probably not the delcom one) use an I2C EEPROM to hole parameters. Going out on a limb, one could probably use that I2C bus to read the JP1 EEPROM (I mentioned that in the early days of
the USB JP1 project).
The Delcom chip is based on a Cypress chip, so one may be able to start there, or even as Delcom about Mac support for their chips.
IMO, once you get a dump of the EEPROM, and can upload it., you are halfway there. |
|
| Back to top |
|
|
Mark Pierson
Expert
Joined: 03 Aug 2003
Posts: 3017
Location: Connecticut, USA
|
| Posted: Sun Sep 12, 2004 11:35 am Post subject: |
|
|
| classicsat wrote: | | The Delcom chip is based on a Cypress chip, so one may be able to start there, or even as Delcom about Mac support for their chips. |
There's a Mac USB I/O driver for the Delcom chip listed here. I know nothing about Mac's, so I don't know if this is a viable solution.
_________________
Mark |
|
| Back to top |
|
|
todd_i
Joined: 24 Sep 2003
Posts: 34
Location: West Michigan
|
| Posted: Sat Sep 18, 2004 3:47 pm Post subject: |
|
|
Just thought I'd add my two cents here.. I would love to be able to fully manage my JP1 remotes from my PowerBook. ir.exe is just about the only application I commonly use that I can't do on my Mac.
I have run RM on my PowerBook, it appears to work fine. I just received my USB JP1 cable. So, I would be happy to do Mac testing on any IR functionality. |
|
| Back to top |
|
|
classicsat
Joined: 20 Feb 2004
Posts: 279
|
| Posted: Sun Sep 19, 2004 8:28 pm Post subject: |
|
|
| IMO., the best one could to is to have an app read/write the EEPROM to a file or the clipboard, and have a cross platform IR/RM app |
|
| Back to top |
|
|
todd_i
Joined: 24 Sep 2003
Posts: 34
Location: West Michigan
|
| Posted: Fri Sep 24, 2004 11:50 am Post subject: |
|
|
| classicsat wrote: | | IMO., the best one could to is to have an app read/write the EEPROM to a file or the clipboard, and have a cross platform IR/RM app |
I have no idea what is involved in the JP1 communications, so I'm basically guessing.. But, from what I've read here, it seems like the parallel interface is doing some old-school bit twiddling, writing directly to hardware. So, that would be very difficult to port to another architecture (which may not even allow direct hardware access). But, with the USB interface/driver, is it still using such wizardry? Since the the company now has MacOS X drivers available for the USB I/O chip, it seems like it could be feasible. If RM incorporates ir.exe functionality (I have read here that this is one of their goals, I don't know if this is accurate), it might not be too far fetched to have cross platform support, where USB-I/O drivers exist. |
|
| Back to top |
|
|
classicsat
Joined: 20 Feb 2004
Posts: 279
|
| Posted: Sat Sep 25, 2004 2:23 pm Post subject: |
|
|
| The USB interface is doing essentially the same thing as the PC parallel and serial version, manually twiddling and reading lines. I have said, with many USB chips using an I2C eeprom themselves, one could "borrow" that interface to read/write the EEPROM on the remote. Once it is in the memory, the real portion of the IR software can take over, which can be in a higher level language. |
|
| Back to top |
|
|
todd_i
Joined: 24 Sep 2003
Posts: 34
Location: West Michigan
|
| Posted: Tue Sep 28, 2004 7:58 am Post subject: |
|
|
| I just downloaded the Mac driver, and was surprised to see that it also includes source code. It looks like it was at least based on an example driver by an Apple employee. He gave his e-mail address and the source code, which could be useful in developing or debugging support on the Mac. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
