The Upgrade overflow code in IR7 still allocates the device/protocol upgrade pointer table within the upgrade region so it doesn't need to oveflow into the start of the Learned region. If it needs to overflow upgrades into the Learned and/or KMM regions, it'll allocate from the end of each region. The upgrade chunk pointers within the pointer table would then point to the Learned and/or KMM regions used.
This algorithm still allows the use of the Learned(if available) and KMM regions. The user just has to be careful to not create KeyMoves/Macros or Learn functions on the remote itself such that it overwrites the overflow upgrades at the end of each region.
30333033 Identifying JP1.3 Atlas PVR
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
very cool....
I suppose that as long as the table has the right addresses, anything goes within the remote. clever approach.
So, I guess that I could set the boundaries back in the extender for the 6960/9960B01 given that IR now will give more space as necessary. When I wrote the V1.2 of the extender, I moved the 6960 boundary to $480 and the 9960B01 boundary to $600 (I think, this is from memory) to allow for more upgrade space. Now, there is really no reason to do this, and in fact, if the user (especially the 6960) has lots of KMM, this is a BAD thing. Should I move it back in the next release?
I suppose that as long as the table has the right addresses, anything goes within the remote. clever approach.
So, I guess that I could set the boundaries back in the extender for the 6960/9960B01 given that IR now will give more space as necessary. When I wrote the V1.2 of the extender, I moved the 6960 boundary to $480 and the 9960B01 boundary to $600 (I think, this is from memory) to allow for more upgrade space. Now, there is really no reason to do this, and in fact, if the user (especially the 6960) has lots of KMM, this is a BAD thing. Should I move it back in the next release?
this JP1 stuff is a sickness!