Atlas JP1.3 Extender beta - Topic CLOSED

[Capn Trips]

For the time being, I'm not using LKP on Device Buttons, since they behave oddly. My goal/standard practice is to use the SHORT KP to turn on and line up all of the equipment and remote for watching from the selected source, and the LONG KP to simply execute a device selection macro. I think this (or its mirror image) is pretty common practice.

I have experienced that on the Device buttons, such an LKP that has a lot of X-DEV commands switching devices for turning on and input selection (in my case the SHORT side), that sequence does not execute properly - it only works every OTHER time, while the LONG sequence (which has just a straight device selection macro) seems to work OK.

So I do NOT currently have an LKP assigned to the Device buttons, only a device selection macro, and am trying OTHER buttons to have the stand-alone TurnOn/LineUp sequences.

"Normal" LKPs seem to work OK (ones WITHOUT Device selection sequences embedded) like I use STOP (SHORT) and EJECT (LONG) on the STOP button for VCR and DVD modes. This works fine.

The common thread for almost all of my problems seems to be the remote's insistence on adhering to some sort of internal logic in device selection that frequently overrides, or conflicts with what one has assigned in IR.

[vickyg2003]

The common thread for almost all of my problems seems to be the remote's insistence on adhering to some sort of internal logic in device selection that frequently overrides, or conflicts with what one has assigned in IR.

Yes some of the cable remotes have some strange hard coded punch through.

[speaker.guy]

"Yes some of the cable remotes have some strange hard coded punch through."


All of the Atlases I have used have the capability to shut it off though...

[greenough1]

Yes all the punch throughs can be turned off in the unextended remotes. I bumped into this when testing binky's macro speed-up and LKP/DKP protocols. Turning them all off finally got things working reliable, for the unextended remote.

Might we just be bumping into the same thing in the unextended remotes? I'm at work so I can't look, but I don't remember if the extended remote IR window has checkboxes anywhere like the unextended one does for turning off all that stuff... I'll look when I get home. if not, might some bits/registers just need to be set in the asm?

Best,
jeff

[vickyg2003]

On the remote that I'm working on there isn't an option on the punch through for the transport keys in the E2 area. It's not checking a bit, its checking the device type of the setup code. If its a TV, it switches you over to the AUX buttons for transport. If its a Cable setup, it leaves the transport keys assigned to the cable. It will give you some unruly behavior if you hit that code.

[greenough1]

Hi Vicky,
Then what's IR doing when it shows all those check boxes for the unextended 1056 OCAP remote that controls the punch-throughs? Is there no analogous way to turn that stuff off in the extended remote? Shouldn't there be since the it can be controlled in the unextended remote?

Best,
jeff

[greenough1]

There is a much newer ASM file, however, I'm traveling right now nd the files are on my machine at home. I'll send them to you when I get back on Saturday

Just a reminder that when you're back to "bulk-mail" out the latest asm.

Thanks for all your work on this extender,
jeff

[unclemiltie]

ok, I'm back on the left coast (Jeff, some day we should meet, I'm living in San Ramon) I'll package up what was my last source, etc and post it tonight.

I haven't looked at this thing for a couple of months, so I'm going to be a bit rusty. Things are starting to settle down so I hope that I will soon have time to get back to JP1 stuff.


As for the diagnostic stuff and the comments, those are very helpful and I'm going to have to start tracking down where I'm going wrong. I have three theories:

1: I'm using a set of device table registers that are getting clobbered when something happens in the remote

2: Since I'm using the main loop from the remote and patching in the extender (instead of doing the main loop myself) there is some path in the main loop that gets executed in some conditions

3: I have a bug in the extender code


All are equally plausible. To those who want to try to chase these bugs, turn on the conditional assembly that builds in the WriteReg and WriteRAM functions and look where they put data. They're already in there so use them.


-bill

[unclemiltie]

All

I've uploaded a ZIP file here:

https://www.hifi-remote.com/forums/dload ... le_id=5328

that contains the following:

The 3000-3033.ASM source file for this extender (complete with already reported bugs) This has not changed since the end of October, just before I took my new job in CA. I've been following the thread here intermittently but all of you should know that the issues that are being reported here.

a BAT file that will build the extender so you can see how to build it. This ASM uses a good bit of conditional assembly to control which version of the extender it is building as well as what options are turned on when it is being built. The BAT file takes the extender source, assembles it, then installs it into a "base" IR file that I took from the remotes, and then for good measure puts some comments in the IR file to document the extender. You can ignore the comments if you like, they are probably not correctly aligned with what is being built right now. (the comments will show up in IR but they may be wrong)

Also included are the RDF's for the unextended remote and the extended remote. Right now, 3000 and 3033 remotees are built. I have preliminary support for the 3032 but don't have one of those to test. But, the remotes are very similar and I did find all of the correct entry points, but the EEPROM layout is very different so that version may not work at all. YMMV.


I *hope* to start to find some time to work on these in the coming weeks. I now have a Comcast cable box that came with an Atlas remote so I've got more of an incentive to get this done. Then again, I'm still moving, don't have a permanent home yet, haven't sold my house in NY AND have to share the only computer in the apartment with my wife and kids! oh well!


if you have questions on how the source works or what's going on in the extender feel free to send me an email or a PM. Most of you who would be so bold as to start looking at the assembly language already know my email address!


-bill

[unclemiltie]

Hi Vicky,
Then what's IR doing when it shows all those check boxes for the unextended 1056 OCAP remote that controls the punch-throughs? Is there no analogous way to turn that stuff off in the extended remote? Shouldn't there be since the it can be controlled in the unextended remote?

Best,
jeff

Jeff

this is a function of the RDF not being done yet. It started out as a derivative of the unextended RDF and now has some of that legacy in there.

The design of the extender doesn't look at those registers so those settings should have no impact on what the extender is doing since it "has no VPT"

[unclemiltie]

OK, I *THINK* I found the mysterious device selection bug.

The new extender V0.04 is here:

https://www.hifi-remote.com/forums/dload ... le_id=5328

For those who are interested:

When I ported the code from the URC-9960B01 to this remote, I forgot to fix up the code that processes the X_Cancel command by assuming that it was on the 8th device in the remote. (clever way to save space) Anyway, my last release I only got half of that logic which left a situation where the Active Device (R_DevA) could get set to $FF but the extender still believed that it was valid and would then try to use that as the active device. I've fixed the logic in this version that should always detect an invalid R_DevA.

I've done very limited testing on this, so please let me know if this fixes the mysterious device selection issues with this extender. Next on my hit parade is to fix the device multiplexer issues that have been reported here.

BTW, I also updated the RDF's in this release to fix a couple of things that were out of position. This one is correctly identified as V0.04 to match the extender



-bill

[unclemiltie]

To whomever was having the issue with a non-working Dev Multiplexer, please try version 0.04 and let me know if it is still not working (maybe the other bug was inter-related)

I've been doing a bit of testing and found that the device table was getting updated properly for dev multiplex. I'm not pointing it at anything but the device code in the register file is getting updated properly on a Dev Multiplex keypress.

If you're still having issues, shoot me a PM and I'll send you a build of the extender that you can use to help me debug this.


thanks

-bill

[Capn Trips]

To whomever was having the issue with a non-working Dev Multiplexer, please try version 0.04 and let me know if it is still not working (maybe the other bug was inter-related)

Bill,

It was I (perhaps others, but I've been whining about it the most )who has had trouble with the multiplexer and will definitely test it at my earliest opportunity. Unfortunately, that MAY not be before tomorrow night.

Thanks for your efforts (may they long continue! )

[greenough1]

Bill,
Your timing is most excellent. I was going to get back to this remote project tonight. I'll have a go at it and see where we are. THANK YOU for your help and hard work.

Best,
jeff

[Capn Trips]

Question about Exinstall.

Is its proper functioning dependent upon both the old and new RDF's being present and in the same folder? Or does it do its magic directly on the raw data in an IR file?

If the former, then one cannot use extinstall to convert from v0.02 of the extender to v0.04 of the extender since they both use RDFs which have the same name (3A333A33).

I'm asking because I have deleted the v0.02 RDF (replaced with the v0.04) and when I open my v0.02-created file (obviously it's opening using the NEWER RDF and NOT the RDF with which it was created) and run extinstall, I get a "system error Code: 14001. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem."

I don't know whether that configuration message is referring to IR or EXTINSTALL, but NEITHER of these applications is "installed". They are just copied and saved in my JP1 folder, and I know IR is correctly pointing to EXTINSTALL since otherwise the "Merge using EXTINSTALL" option in IR would be grayed out.

(Of course, I just noticed that get the same symptom when I take a 30333033 IR file and try to convert it to 3A333A33, so I guess it's not RDFs, but something in my configuration - HAAALP!)