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

What new extender feature would you like?
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Extenders
View previous topic :: View next topic  
Author Message
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Sat Apr 17, 2010 10:55 am    Post subject: Reply with quote

xnappo wrote:

Does it not do that? I think on my Atlas it did - but I no longer have the device/setup I used it with so I could be wrong... If it doesn't do it, unfortunately it is beyond my skill level to fix.


Try this for a version that executes the key that aborted the pause:

Code:

RCA:
00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 03 2A EF AF F6 48 2D AF

Atlas:
00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 03 2A EF AF F6 48 2A AF


This seemed to work on my Atlas and of course I don't have an RCA to test with. It did seem to take a fairly deliberate press vs. just a tap though...

I should note that while my original 'pause with abort' is solid, this one is a bit of a hack. If your remote starts acting weird, remember to remove this and see if it fixes it.

xnappo
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Sun Apr 18, 2010 9:35 am    Post subject: Reply with quote

Thanks for the continued efforts, xnappo. Unfortunately, that latest RCA version doesn't appear to pause at all. That might have something to do with the
Code:
CALL   4189H
instruction reverting back to
Code:
CALL   4009H
between versions, since that appeared to be the adjustment you made to get your original Atlas version to work on the RCA in the first place.

Unfortunately, while correcting that subroutine call does restore the pause behavior, interrupting the pause with a button press seems to completely confuse the RCA, requiring a battery pull to get it responsive again. So I'm guessing the subsequent
Code:
CALL   482DH
is sending the RCA off into someplace it has no business going. Presumably, if we can get the correct subroutine address in there, we might have something.
Back to top
View user's profile Send private message
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Sun Apr 18, 2010 9:56 am    Post subject: Reply with quote

R2-M0 wrote:


Unfortunately, while correcting that subroutine call does restore the pause behavior, interrupting the pause with a button press seems to completely confuse the RCA, requiring a battery pull to get it responsive again. So I'm guessing the subsequent
Code:
CALL   482DH
is sending the RCA off into someplace it has no business going. Presumably, if we can get the correct subroutine address in there, we might have something.


Thanks for the correction to the 4009 call. The problem is that there isn't a subroutine that does exactly what we need, so I am jumping into the middle of another routine. This means that some CPU registers may not have the data in them that they should and could be causing the crash.

Looking at it again though, you might try one more time with 482A instead of 482D.

xnappo
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Sun Apr 18, 2010 10:27 am    Post subject: Reply with quote

xnappo wrote:
Looking at it again though, you might try one more time with 482A instead of 482D.

Unfortunately, that doesn't appear to work any better. Sad

Might I ask how you obtained these addresses in the first place? I'm assuming that there must be some tool (or combination of tools) that provides a disassembled view of the remote's built-in code. I'd be interested in poking around such a listing myself.
Back to top
View user's profile Send private message
StephenR0



Joined: 12 Feb 2007
Posts: 109
Location: Iowa, US

                    
PostPosted: Tue May 11, 2010 12:59 pm    Post subject: Reply with quote

I hope I'm not too late to request this, but I currently use the 6131 extender beta 2.0. This extender has an Input Select protocol that is able to operate the input selection menu on my (admittedly lame) tv. It's not the friendliest thing to use, but it works quite well for me. I'm interested in the Atlas remotes, but I'm going to need this function at least until I get a less lame tv. Is there any chance that this could be ported to the Atlas extender?
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Wed Aug 25, 2010 7:12 pm    Post subject: Reply with quote

Apologies for resurrecting a comatose thread. But after several months of using my RCRP05B with the interruptible pause protocol, I believe I have a better grasp on the other half of my original feature request.

I previously wanted whatever button was used to interrupt the pause to then be "pressed" at the end of the macro. But I've realized that what I'm really looking for is a one-button typeahead whenever a macro is running, regardless of whether or not I happen to be in a pause at the time of the button press.

So if I kick off a macro, then press another button while the macro is running, I'd like the extender to remember that button and, when the macro ends, fire off the action associated with the remembered button. If it so happens that said button also interrupted a pause in the middle of the macro, that's just a bonus.

I think a single button typeahead queue should be more than sufficient. But I have no idea how difficult even that would be to implement.
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Thu Dec 23, 2010 3:38 pm    Post subject: Reply with quote

xnappo wrote:
Code:

00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 02 2A EF AF


NOTE: this is for Atlas OCAP - it is very likely it will not work - if not I can probably get one to work for the RCA but will need to do some consulting with the experts.

I just need to confirm this is ok to use in the Atlas1056 extender and also, have you assigned an official protocol number to it or do I just invent my own?
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Thu Dec 23, 2010 3:49 pm    Post subject: Reply with quote

Capn Trips wrote:
Another vote for MORE DEVICES (I know I already voted - but like they say in Russia, "Vote early, vote often!"). Whatever amount of back-breaking, and mind-numbing effort it takes is absolutely a worthwhile investment of your time.
Haven't voted yet, so here's one more vote for the 10 devices. It's an enormous remote. Looking at the empty space makes me want to cry. 8-10 devices would make it great for me.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
underquark
Expert


Joined: 20 Jun 2005
Posts: 874
Location: UK

                    
PostPosted: Thu Dec 23, 2010 5:43 pm    Post subject: Reply with quote

If voting has be re-activated on this, I'd vote for a feature to select different groups of devices so that you could use the remote in different rooms, e.g. Group A has devices TV/0001, VCR0002, DVD0003, PVR004, SAT0101 etc., Group B maybe TV/1250, VCR/0800, DVD1103, PVR004, SAT0101. Group selection could be done by [SHift]-digit or [XShift]-digit or other suitable key. Since few seem to use the Fav key it could be turned into the Group selection (aka [XShift]) key.
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Thu Dec 23, 2010 8:44 pm    Post subject: Reply with quote

2-3-4 groups here, but with only 5 devices is rough on Atlas, really rough, inspite of its enormous space.
On the 8910 I do know which "group" I'm in, but it does require to remember what you coded on which device button Sad

Anyway, I'd rather not see anything too fixed to a FAV button, as I need unadulterated FAV and I'm serious about that need.

s**t-FAV or xshift-FAV trigger for groups (or on any other key really) would be cool but doesn't that take us back to the need for an excellent multidevice multiplexer that would not confuse keymoves and special keymoves, would handle 2-byte hex codes, etc.? And without an LCD screen how would we know which group the remote is currently thinking of using as you walk about the house with it hanging 'round your neck? Just thinking out loud.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Tue Mar 01, 2011 10:43 am    Post subject: Reply with quote

To resurrect this somewhat dormant thread. I've been working on the RCA RCRP05B (3179) and the Insignia (3147) extenders lately and went back and re-read this entire thread. An update:

V1.01 of the 3179 and V0.01 of the 3147 extender now have two of the requested features built in to the extender:

    1: a key press will interrupt the pause protocol and cause it to terminate. This does not execute the key that caused the keypress, it could but... more on that later

    2: there is a user selectable value for delays between macro keys ranging between $00 and $FF. This is settable in the general settings in the IR tab
.


now, some questions:

First, on the key that caused the pause interruption. how would you prefer that I deal with it. It can either:

    a: interrupt the pause and any macro that was playing and execute that key and that key alone

    b: interrupt the pause and stuff the key that caused the interruption at the end of any currently playing macro

    c: ignore the key (currently implemented)


Second, on the macro delays: Is a small delay between macro keys acceptable to most people? Right now, there is

Code:


CLR    RC0
LD      RC1,#xx
CALL   DelayWW0 ($010D)
 



in between fetching the key from the macro and the execution of that key. If the DelayWW0 value is $00, I think it'll return pretty quickly. Will anyone even notice?



Third, I can probably put an interruptable macro into these things, but that will introduce more delay in between the processing of keys. A scankeypad to check to see if something was pressed in between each key process will be a pretty big penalty. I'm inclined to not do it. We'd have the same issue of what to do with the key as with the interruptable pause so think about that as well.

    _________________
    this JP1 stuff is a sickness!
    Back to top
    View user's profile Send private message
    mdavej
    Expert


    Joined: 08 Oct 2003
    Posts: 4500

                        
    PostPosted: Tue Mar 01, 2011 11:38 am    Post subject: Reply with quote

    I vote for B. But I don't see myself ever using interruptible pause at all, especially not at the expense of performance.

    On the other hand, user selectable macro delay will be very handy. Personally, I think the default delay is a bit too short, but if I can adjust it, it doesn't matter.
    Back to top
    View user's profile Send private message
    ElizabethD
    Advanced Member


    Joined: 09 Feb 2004
    Posts: 2348

                        
    PostPosted: Tue Mar 01, 2011 12:04 pm    Post subject: Reply with quote

    The needs I see are:
    1. Flexible delays between macro buttons. Would that need a device keymove or be a global type of thing? I don't care how. It's needed.
    2. Interrupt a long pause within a macro and continue with the macro, i.e. go to the next command in a macro. useful for some sluggish devices. This might fall under a or b or some variant thereof.
    3. Interrupt and kill a macro totally - useful when a macro contains several commands to do several 30-sec skips, and fewer might be needed. I think this falls under point c.
    _________________
    Liz
    Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
    Back to top
    View user's profile Send private message
    unclemiltie
    Expert


    Joined: 21 Jan 2004
    Posts: 1795
    Location: Pittsburgh, PA

                        
    PostPosted: Tue Mar 01, 2011 12:35 pm    Post subject: Reply with quote

    Actually the more that I thought about it last night, I'm not sure that option (a) is all that viable.

    I many of the extenders, you will have a lot of temporary device settings and depending in the macro where you are, the temp device will be different and thus the key that is going to be substituted could have a different effect. (I'm somewhat cautious of Chris' protocol upgrade that executes the key pressed when in use with the extender by the way as it doesn't clean up things that the extender cleans up when it passes control back to the core remote, so I wouldn't recommend using it. I think it's safe with the unextended remote)

    option (b) adding the key to the end would at least produce consistent results. (although not necessarily desirable since a temp-device cancellation may not have taken place)

    ignoring the key seems like the right thing to do (which is what I implemented in the 3147 and 3179 extender)


    re: Liz

    Interrupting and killing a macro totally will introduce a pretty significant delay between each of the keys since I'm going to have to scan the keypad in between every key. I guess I could "skip" the scan with a flag setting but that's more code and some of the JP1.3 extenders are pretty tight as it is. (the RCA is one of them since it has so much configuration data there is less room for the extender)


    When you say "flexible delay between macro keys" do you mean:


      1: a delay that is used between all of the keys in every macro (easy)
      2: a delay that is used between the keys in each macro, but can be different for each macro (much harder, would likely require support in IR and RMIR to do it)
      3: a delay that is different between every key within a macro and different in different macros (makes my head hurt)


    (1) is already implemented in the 3147 extender (not the one that is in private beta) and in V1.01 of the 3179 extender that I'm gonna need some testers for.

    (2) and (3) would likely require a "new format" for storing macros that had the delay embedded into them and thus would require changes to IR and RMIR and Extinstall to deal with it. Again, not impossible but I'm not sure that it's really worth the effort.
    _________________
    this JP1 stuff is a sickness!
    Back to top
    View user's profile Send private message
    ElizabethD
    Advanced Member


    Joined: 09 Feb 2004
    Posts: 2348

                        
    PostPosted: Tue Mar 01, 2011 1:30 pm    Post subject: Reply with quote

    My head hurts too even though I'm not the one writing the extender Smile

    unclemiltie wrote:
    When you say "flexible delay between macro keys" do you mean:...
    Most flexible delays can now be handled by Pause keymoves. Your solution 1: seems like a good one.

    Regarding
    unclemiltie wrote:
    (2) and (3) would likely require a "new format" for storing macros that had the delay embedded into them and thus would require changes to IR and RMIR and Extinstall to deal with it. Again, not impossible but I'm not sure that it's really worth the effort.


    Ok, skip my point 2. It can be adjusted while we setup the macros and test on the real gear, so no big problem, as I think about it
    .
    My point 3. So this one is the only one that I'd like to see. It's not a matter of delay. It's a matter of the need for early exit. People do like to skip commercials, and often make a macro of several skip steps or a forever looping macro (while the key is held) in order to skip a minute, 2 minutes ... would be nice to kill when fewer ads were broadcast than anticipated. Since the extender space it tight, it could just be an optional device and protocol we can load when needed and make a keymove to insert before all the SKIP commands or at the end. Yes? No?
    _________________
    Liz
    Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
    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 - Extenders All times are GMT - 5 Hours
    Goto page Previous  1, 2, 3, 4, 5  Next
    Page 4 of 5

     
    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
    Top 7 Advantages of Playing Online Slots The Evolution of Remote Control