JP1 Remotes

Vista x64 protects the system by stopping any unsigned device driver from working. In addition there is also the 32/64 bit issue around the device driver.

The only way I have got around this is to run IR on a virtual PC within Vista x64 i.e. make use of VMWare or similar. Within this virtual PC ...

I found a workaround in the use of creating a Vmware XP 32 bit client on the Vista 64 bit host. I was a bit concerned that the Vmware virtual computer wouldn't be capable of passing the parallel port commands through to the physical port on the host, but it did work.

Hi, the current version of IR fails to talk to the JP1 device. The reason behind this is that Vista x64 requires a signed 64 bit .sys file in order for the sys file to be loaded. From what I can see, the gwiopm.sys is very x86 specific (uses undocumented APIs) and is also not signed. I don't own the ...

Given the way that the 9960 eats batteries, I was wondering if anyone had thought of a way of creating a docking station for it that could charge let say some AA NiMH cells.

In order to provide some ability to program the new remotes, wouldn't it be possible to use the wav import / export function? If a RDF can be created from the flash memory, we should be able to create our own device and protocol files.

Thanks, it seems to work with 1.05

I have recompiled the 9960's experimental SSM/CODS protocol for the 8060. As I don't have an 8060, let me know if it works.

For more information, look at the "Screen (& start dev.) specific macro protocol for 9960 e" topic in this forum

The way the screen/current O_group dev index specific macro ...

Hi Paul, I agree that it can be confusing in a case where you have set the O_,M_,T_ etc. at different devices and don't make use of X_ (which won't effect the dev value). If you tend like me to try to keep all the groups against the same device and use the X_ to initiate keymoves, then it is a lot ...

Previously, when I tested the 9960 extender, the macro seemed to override the keymove rather than the other way around. (I might be wrong and will need to retest to confirm this).
In any event, the ability to create a number of "if then else" chained scenarios based upon device index and screens ...

Hi pgk. The concept of the original device is to allow for cases like:
I want macro 1 to behave one way if the device is a TV and another way for all other devices. I could do this by putting a keymove on all the devices but it is simpler to create a macro that just calls a keymove (for instance via ...

Thanks, I have now corrected the description of the command to read for the true and false cases.

R03 and R2D both start off referring to the same value, so the result is fine. (In fact this part of the code is directly copied from the LKP/DKP).

I have checked the 8060 extender asm, and this code ...

Hi, I put together a protocol for screen / and start device specific protocol for the 9960 extender. The reason for this is to allow me to change a behavior of a key move depending which screen it is on or which device the original macro/key move started on.

The way the screen/orig dev index ...

Oops.

Thanks, my hex is having a day out.

Having had a look thorough the code for for these in the 9960 & other extenders, they are all similar in terms of the way that they handle the hex commands eg. (from 9960 extender):
Protocol_1F9:
db 00,00,01
org Ram
LD R4A, R03 ;Get the "HEX command" from the KeyMove
SWAP R4A ;Timeout value in ...

I have having a problem saving certain device files with RM 1.04. To replicate this problem, run RM 1.04. Open the attached file and do a save as (eg. dgtec_4). If you then look at or re-open the newly created .rmdu file, it is blank. At no stage is an error message produced.

Dgtec DH2000A_3.rmdu ...