In the P2 documents I found an example of the RDQUAD delays required after the instruction executes. I could not find a similar example for RDxxxx instructions. What I have found by trial and error is this...
LMM_call01 rdlong LMM_opcode,LMM_PC ' read next hub instruction to be executed (pointed to by LMM_PC)
add LMM_PC,#4 ' inc LMM_PC (to next hub instr)
nop ' required delay for rdlong to execute
LMM_opcode nop ' execute the hub instr
Is this correct or should there be more NOP's ?
I just realised that the JMPRET instruction can save the C & Z bits in a CALL version using the WC & WZ modifiers,
and can be restored by RET using the WC & WZ modifiers. I presume the save v restore is triggered by the NR modifier
implied in the instruction bits. This is a really neat no penalty feature
I have noticed that the TX routine in the Rom_Monitor v0.1 dated 11/01/2012...
The bit time delay commences before the start bit is sent, and that the stop bit is untimed. This
probably does not matter here. (it caught me out when I copied your routine)
A simple solution would be to move the "passcnt" after the "setpc" instruction.
' Transmit chr (x)
tx shl x,#1 'insert start bit
setb x,#9 'set stop bit
getcnt w 'get initial time
:loop add w,period 'add bit period to time
passcnt w 'loop until bit period elapsed
shr x,#1 wc 'get next bit into c
setpc tx_pin 'write c to tx pin
tjnz x,#:loop 'loop until bits done