The David Assembler documentation lists three boundary conditions for the C=G instruction where the operation is strange. They all have to do with cases where the active pointer is (or was, or will be) pointing at the most significant nibble. Case 3 is when the pointer is decremented from pointing at the MS nibble immediately before the C=G instruction. This document explicitely states that this is for the DEC PT instruction only. But my reverse-engineered Nut CPU also does a similar thing for the case where the pointer is changed (from pointing at the MS nibble) with a PT=d instruction. In this case the behavior is identical to that listed for the DEC PT case, only relative to the new pointer value. Can anyone confirm that the original Nut CPU operates this way? Or is the operation "correct" in the case where the pointer is loaded with a new value, where it was previously a "B", followed immediately by C=G? Thanks in advance.

Monte

This is a bit too detailed for me, but I advise to look in the V41 sources as this emulator is very accurate. I have done this too for sorting out some details when developing my MLDL2000.

Meindert

I do not regard myself as an expert, but when I programmed my NutEm (Coconut emulator) I respected all CPU bugs (had a list from can't remember where) with a warning. Running the OS of the HP-41CX I had to discard all those warnings. So it is not clear for which CPU version was this bug list.

Ciao.....Mike

Unfortunately the V41 operation in these cases was taken from the David Assembler bug description, and the source code has comments questioning the behavior. Thanks anyway.

Monte