JP1 Remotes

I've been using 8810/8811s with extender-3 for some time and really like the platform. I've outgrown the standard 2K memory due to some devices that consume substantial memory (Onkyo Receiver, DirecTV DVR, TiVo, X10-Hacked, etc.). Fortunately it looks like extender-3 supports 8K devices. Can someone advice how to add an 8K eeprom ?

I searched the forum and it wasn't clear to me which 8k eeprom to use or whether you add the 8K chip versus replace an existing chip inside the remote.

Thanks for any help.

The 8810/8811 should be the same internally as the 801x and 601x. There's a sticky on the topic here:
http://www.hifi-remote.com/forums/viewtopic.php?t=2590

and there's a thread on someone solding an 8k chip:
http://www.hifi-remote.com/forums/viewtopic.php?t=3712
http://www.hifi-remote.com/forums/viewtopic.php?p=25463

Removing the old eeprom is probably harder than adding a new one (the advantage of the 801x and 601x for this is they start without an eeprom). Either task is far beyond my soldering ability.

BTW, remember that eeprom chips are normally sold by KBit capacity, but we discuss them here by KByte capacity. So if you just try to buy an "8K" chip you may find yourself with 8KBit = 1KByte.

You can multiply/divide by 128 to convert labeled Kbits to bytes. On my logger project, I have a 24C32 EEPROM. 128*32=4096. That's what it stores.
Just a hint.

Edited to fix error.

It sounds like adding the 8K eeprom to the 8810/8811s is beyond my skills, especially if it involves surface mount stuff (i.e. desoldering the existing 2K eeprom). I thought I had seen a few references in the past about the 881x with 8K but my earlier seaches and the information in the replies above indicate it was just the 801x remote (my memory isn't what it use to be).

Thanks for the responses.

nevolc wrote:It sounds like adding the 8K eeprom to the 8810/8811s is beyond my skills, especially if it involves surface mount stuff
Thanks for the responses.

I dunno, I wouldn't give up so easily if you want to try it. I took the EEPROM off - and while I am somewhat good at soldering it really wasn't hard at all with the right tools. If you get some solder wick it comes off easily - at least on the 8910. I have not looked in to replacement EEPROMs yet - I still have 22 bytes of upgrade space left

The other piece of this question is how easy is it to modify the extender etc to use the memory...

xnappo

The 8910 can't use any other eeprom size. There is nothing an extender could do to fix that. The 8910 doesn't just fail to use the extra space. It fails to use the eeprom at all if it is too big.

The 8810 can use other eeprom sizes. The extender isn't even absolutely required (JP1 is), but most of the value of a bigger eeprom requires an extender.

johnsfine wrote:The 8910 can't use any other eeprom size. There is nothing an extender could do to fix that. The 8910 doesn't just fail to use the extra space. It fails to use the eeprom at all if it is too big.

Well thanks for saving me some time That is too bad! Not to hijack the thread - but how hard is it to move key move space to upgrade space in the extender?

xnappo

xnappo wrote:how hard is it to move key move space to upgrade space in the extender?

I thought there was no need to.

Upgrades can go anywhere. Keymoves can't go in the upgrade area, but upgrades can go in the keymove area.

For a long time, IR.exe didn't understand that. But I thought that was fixed (so IR will use free memory in other areas for upgrades once the upgrade area is full).

I believe allocation of "move" versus "upgrade" space is set in the rdf file [edit] and there are corresponding changes that must be made in the extender code itself. A sample extract from an RDF file for the V3.3 extender for the 6011/8011/8811: I believe the last two lines shown (AdvCodeAddr & UpgradeAddr) are where you would shift "move" versus "upgrade" space. Note the extender code itself would have to be modified to match these values.

As johnsfine indicated in the previous post, this hopefully isn't necessary.

On the 8910, was the eeprom a separate, distinct surface mount chip ? This may sound like a dumb question but I was concerned the eeprom in the 8811 would be some kind of combo ram/eeprom/etc chip which would prevent a one for one swap.[/i]

The eeprom is a separate 8-pin surface mount chip in the 8811, 8910 and I think all other remotes that use a JP1 cable.

In remotes using JP1.1 and JP1.2 cables, it is not a separate chip. It is just a section of the flash memory inside the microprocessor chip.

To address several of the questions in the last 2 or 3 posts:

In all of the JP1 remotes (inclulding the 8811 and 8910), the EEPROM is a separate physical component from the processor. It is only the JP1.1, 1.2 and 1.3 newer remotes that have the combined Processor/Flash EEPROM chip.

I didn't know that you could not even add a larger EEPROM for the 8910, but I DO know that the 8811 has a NUMBER of RDFs to handle the larger EEPROMs. Just check the file section under Tools>RDFs.

Most extenders for JP1 remotes convert the LEARNING memory into Keymove/Upgrade memory. For the 8910, that leaves about 782 bytes for upgrades, of which the extender and its Special Protocols eat up quite a bit. Since IR can handle "overflow" of upgrade memory by using Keymve/Macro memory, that has usually not been a problem. (Try it and you will get a pop-up asking you if you want IR to do this. Select "Yes" and you will see the Keymove/Macro memory counter in IR turn Yellow)

If, however, you need more Keymove/Macro memory (WOW! that would be a buttload of keymoves/macros!) then you would need a tailored version of the extender to reallocate some of the UPGRADE memory as KEYMOVE/MACRO memory, since that "overflow" handling only goes one way.

Wow, thanks for the info guys. I have been being incredibly stingy with upgrades because I thought it would be a pain if I used my last 22 bytes Sounds like I didn't really need to be worrying about it as I have 200+ bytes of keymove left. I actually have seen the overflow pop-up - but misinterpreted it to mean that it would use keymoves to map functions in an upgrade instead of upgrade space.

As to the eeprom - yes it is a separate distinct chip. It is a serial 8-pin SOIC.

xnappo

nevolc wrote:In the case of the 6011/8011/8811 extender, I believe allocation of "move" versus "upgrade" space is set towards the front of the rdf file:

Code: Select all

[General]
Name=Extender 3 2K URC-6011,6012,8011,8811
EepromSize=$800
FavKey=$30, $1B, 15, 5
AdvCodeAddr=$401..$794
UpgradeAddr=$100..$3FF
.
.

I believe the last two lines shown (AdvCodeAddr & UpgradeAddr) are where you would shift "move" versus "upgrade" space. I'm not sure why AdvCodeAddr starts at $401 instead of $400 ($400 would be right on "top" of the UpgradeAddr memory).

Just to clarify things for those who might read this in the future, it's not as simple as this. The function of these entries in the RDF file is to tell the IR program where to load and store data in the remote. Changing these entries amounts to lying to the IR program, with the result that data will be misinterpreted. The remote itself has no knowledge of what the RDF file says, it expects things to be stored where they were programmed to be at the factory.

The only way to actually change the allocated spaces is with an extender, which of course would also require a matching RDF file with the correct entries.

My bad on over simplifying shifting "move" and "upgrade" space around with an extender. I edited my post that referenced the RDF file to include that corresponding changes would also have to made to the extender code.