JP1 Remotes

[wwwoholic]

I almost out of memory for upgrades, while still have a lot macro/keymove space. Just a thought - since extender modifies eeprom partitition anyway, can it be configurable? e.g. as parameters for installer. I was going to play with constants in the beginning of .asm to see what happens, but then decided to ask first.

[sfhub]

There are probably ways you can reduce memory usage which may
not be immediately evident. Some folks remove the special protocols
they aren't using to save memory. Using a builtin device code instead
of creating a custom upgrade, then using keymove for a few keys is
usually better for memory than creating a brand new custom device map.

There are some defines in the .asm and .rdf which you can look at
(I think you are using 2116ex2):

.asm
NewKeyMoveArea= 401

.rdf
AdvCodeAddr=$401..$751
UpgradeAddr=$100..$3FE

increase 401 in the .asm and .rdf to shrink the keymove area and increase
3FE accordingly to be one less than the keymove area start.

You need to recompile the extender.

[wwwoholic]

Thanks, I'll try this. Pretty much what I thought, except I forgot about .rdf file. And I was hesitant to change anything because there could be some hardcoded addressing and I havent had time to go through the whole source.
As for removing special protocols - I need all of them but pause. Guess I overdid it with device upgrages, but it is so easy to get excited with KM convenience...

[Mark Pierson]

[johnsfine]

I don't know why the original limit address of the upgrade area was 3FE. It looks like it should be 3FF (so you get one extra byte for free )

When you make the ASM and RDF changes to move that boundary, you create a minor risk of problems that would occur before you activate the extender if at all.

Without moving the boundary, the byte at $400 contains a zero to tell the remote that there are no learned signals. Moving the boundary doesn't change that, but installing enough upgrades to take advantage of the new boundary does. Then there's no zero at $400 and the remote thinks there's some set of invalid learned signals. When you press the key to activate the extender (or any key you press before that) the remote tries first to find that key in that set of learned signals. There is a tiny chance that it will think it finds it and thus send a garbage signal instead of activating the extender, and there is a slightly larger chance that it will get lost while looking for it and never come back to do anything until reset.

If you can't activate the extender after loading a new upgrade with the boundary moved, you should delete some upgrades and reinstall them in a different sequence, which might rearrange the contents of the memory starting at $400 so the remote sees a different set of garbage learned signals and probably won't have the problem again.

As I've said every time this comes up, there's a change someone should make to IR which would fix the whole issue and let you have more upgrades whenever space could be available even without moving the boundary, without losing the zero at $400, without even needing an extender, and without multiplying the number of RDF files. It would be a tiny change to the Pascal code to write an eeprom that way (but *I* don't have a Pascal compiler). It would be a somewhat harder change to the Pascal code to understand what upgrades are present when reading back an eeprom after that tiny change had been used. I guess Mark doesn't have time to make those changes.