When the design of the combo-interface was released, an elaborate software initialization scheme was included that relied on separate drivers for pins 4 and 5 of the interface. Pin 4 was held low during reset to initialize a JP1.2 remote, and pin 5 for a JP1.1 remote. That scheme is described in detail here:
https://www.hifi-remote.com/forums/dload ... le_id=4259. If I understand correctly, binky123 is suggesting you can upgrade an interface built for JP1.2 only (without the three components R1, D1, and Q1) so that it will operate with JP1.1 remotes also, by just connecting pins 4 and 5 together.
When a JP1.x remote comes out of reset there are four possible combinations of pins 4 and 5 that decide what happens next:
.......PIN 4......PIN 5...............JP1.2 ACTION......................JP1.1 ACTION
(1).....1.............1..........start normal operation..........start normal operation
(2).....0.............1..........go to serial comm mode...................?
(3).....1.............0..........go to background mode........go to serial comm mode
(4).....0.............0.......................?.......................................?
The fourth condition can occur only if pins 4 and 5 are tied together. We don't know how the remote software is written, or even whether it is the same for different version remotes, so we don't know the results of condition (4) for JP1.2 or conditions (2) and (4) for JP1.1 except from experimental evidence.
Consider first the JP1.2. Since condition (4) is ambiguous (it's telling the remote to do two different things) it may or may not have been specifically dealt with in the remote's software, depending on the skill and imagination of the programmer. Some programmers might decide that, since this as an invalid combination, to treat "0 0" the same as "1 1". But for the binky123 scheme to work, the software has to be written to treat condition (4) the same as condition (2), by looking first at pin 4 and, if it is low, disregarding pin 5.
Now look at the JP1.1. Here the programmer has the option of disregarding pin 4 altogether, so that condition (2) is equivalent to (1), and (4) is equivalent to (3).
For testing with JP1.1 I used a Comcast URC-1058BG0 remote. Most of the time the remote did initialize into serial comm mode with both pins 4 and 5 low, but every once in a while it would come up in a state where it was neither operational nor willing to communicate. It remained in this limbo state indefinitely until I sent a break signal, which kicked it on into serial comm mode. I conclude from this that there may be a timing issue. Perhaps the remote sees pin 5 low following reset, starts serial comm mode, then sees pin 4 low and has to wait for that to clear to move on.
For testing JP1.2 I used a URC-10820B00 remote. Resetting the remote with just pin 4 low initializes it in serial comm mode as expected, but resetting the remote with both pins low always left it in a state where it would neither operate nor communicate, which I assume is background mode. That suggests that when the processor comes out of reset it looks first at pin 5 and, if low, disregards pin 4.
All the foregoing tests were made with an interface having manual switches for holding pins 4 and 5 low, either separately or together. For thoroughness I decided to make an adapter that actually wired pins 4 and 5 together, and let the test software program (which I am sure embodies the initialization sequence described in the link above) do the startup. I almost wish I hadn't. The remote always initialized in serial comm mode, which contradicts the last sentence of the above paragraph. Go figure.
My conclusion is that the binky123 scheme may or may not work at all times with all remotes. You can try it, and if it seems to work for you, great. If the results are unsatisfactory you will have to put in the three optional components.
Tommy