This an update to a post I deleted so if you saw that sorry I found the issue now and its not what I originally thought
Basically
There seems to be a section of Ram at the bottom that is not being written to. I wrote some ASM that wrote from 0x01 - 0x05 and none of the methods I can see saw the ram locations change
This is explains my delay issues in that the a delay value is being loaded into ram at 0x01 and some maths performed on it a BTFSS was done on the carry flag and as the ram is reading Zero it returned prematurely. Delays under 254 are passed in the wreg so were ok
No, you need to use the General Purpose Register area. Open the Memory GPR pop up window to get access to this area.
The issue with Delay_ms(1000) is more complex than that. It is because ADDWFC instruction that gives wrong results in some combination of data and adversely affects the state of the Carry bit. I have fixed this but I'm still testing.
In my first post on this, (that I deleted) I thought it was ADDWFC or BTFSS but after doing a lot of checking and looking at the carry flags on the 2 devices I was testing I was not sure and that lead me off into the weeds that the ram.
There are a lot of memory options I tried a few and thought I had the right one
Confirmed that issue about long delays - DelayMs(1000) - was because some bugs with arithmetic instructions, as for instance ADDWFC.
The fix is scheduled for the next service pack or release.