Hmm is there some trick to this? I am starting with an Atlas B03 code, trying to get this to reveal, but I can't figure it out, is it buried somewhere in the documentation?

No trick. If you want an example, try this:

Open RMPB
Click the down arrow on the toolbar to open Import Protocol
Select NEC1 in the drop-down box in the dialog that opens, press OK
Select the MAXQ610 line in the table of hex codes, press Import Hex
Select the Analyzer tab to see the analysis

Wow have you been busy while I've been in JP1-remission. I have found so many new menu options.

Okay, questions;

1) Is there a vector and variable list somewhere, I know its in the code because you use it for disassembly, to show the meaningful names. I never ever would have been able to write an executor, if I didn't have the list for the other processors.

2) It appears that each data type is enclosed in a container, (I believe you call them segments), but I also see that the executable code is divided into into segments to. Is this a size limit type thing where they page data in and out?
If so what is the maximum size of the code segment part?

3) Is there some reason that you moved from calling the Device Command Buffer DCBUF to Fix_ and Var_? Just wondering?

Also kinda related question

In RMIR, there is a "Clear PID History" and I'm not sure where the PID history is stored and how that effects my work with RMPB. When I create a one-of protocol, I always use PID 01FF. Nearly every room where I have a remote control has at least one device that needed a custom protocol.

And then I done one-of protocols for many people on the JP1 site as well. I also open other peoples RMIR files where there custom protocols. What is my best practice withe the "Clear Pid History"?_________________Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

No, the concepts are not really relevant to the JP2 protocol structure. The JP2 pseudocode runs in model processor with 256 bytes of RAM. What you are asking for is essentially a memory map for that model processor. With our current partial understanding, what we know so far has not been made into a coherent document.

Quote:

I also see that the executable code is divided into into segments to. Is this a size limit type thing where they page data in and out?

No, a JP2 protocol executor has various sections, each of which may or may not have associated pseudocode.

Quote:

Is there some reason that you moved from calling the Device Command Buffer DCBUF to Fix_ and Var_?

As the above answers indicate, concepts do not carry over naturally from the structure of earlier executors.

Quote:

In RMIR, there is a "Clear PID History"

This relates to Alternate PIDs. If you set an Alternate PID for a standard protocol (one in protocols.ini) to avoid a clash of PIDs, this gets stored in your properties file so that if you download from the remote a setup that references that alternate, RMIR will recognise it. If another user downloaded that remote, it would instead show up as a manual protocol. "Clear PID History" clears that data from your properties file. It is nothing to do with the situations you describe._________________Graham