Thanks for your reply yy1.

In our code, we check the status of CC1 after the SRD operation via the JP instruction in order to jump out of the loop.

Now for a 32 bit double word, which has 32 bits (Bit 0 LSB to Bit 31 MSB);

To move bit 0 to CC1, we shift right by 1;
To move bit 1 to CC1, we shift right by 2;
To move bit 2 to CC1, we shift right by 3;
and so on, so
To move bit 31(MSB) to CC1, we shift right by 32.

Thus i would think we would need to do the shift by 32 to get the MSB to CC1. Please correct me if am wrong.

I do believe there is an issue with the SRD with a 32 bit move. Maybe from what you are saying that for a 32 bit move, it will have zero in the results, meaning we are getting 0 in CC1, where we are actually expecting CC1 to hold the status of the last bit that was shifted (which would have been the MSB in the double word in case of shifting right by 32 bits). I want to make sure that is the case, or find out if i am doing something wrong.

Tauseef

Now for a 32 bit double word, which has 32 bits (Bit 0 LSB to Bit 31 MSB);

To move bit 0 to CC1, we shift right by 1;
To move bit 1 to CC1, we shift right by 2;
To move bit 2 to CC1, we shift right by 3;
and so on, so
To move bit 31(MSB) to CC1, we shift right by 32.

Thus i would think we would need to do the shift by 32 to get the MSB to CC1. Please correct me if am wrong.

Tauseef

I do believe there is an issue with the SRD with a 32 bit move.

Sydney,

Thanks for your post.

I am attaching a file with two blocks for the scroll. One for scrolling 32 messages, and one for 64. We have always used the 32 bit message scroll as per FC501. Since we needed to expand, FC501 was modified as per FC503.

You would notice we do not do any subtraction in FC501 as we do not need to (only 32 messages are needed). However, even with FC501 we had the same issue (the CPU would stop if we only had message 32 bit high). This was the first thing i tried when i had the issue. I tried using only the 32 bit message scroll (FC501) and held bit for message #32 high only in the LL message double word, and got the same issue (CPU stopped for cycle time exceeded). This leads me to believe that an unconditional jump would not solve the issue or not having it is the cause for it.

Please inform if you think likewise or if you have any reason to believe the contrary.

Sydney

anyway the unconditional jump across the second checking should be there if you want the function working correctly and also it could cause the unfinished loop as I wrote...