... appears to be quite of the $0.25 vanilla flavour, but this PUSH, which makes it non-biblical marginally.

However, if I think into it, I would like to have it THIS way rather than the Intel way - e.g. when I push P2 (= the upper part of address when using movx @Ri) in an ISR to make space for an another movx @Ri, I'd like to push the content of the latch, rather than the port, for case the upper address driver is loading P2 heavily. On the other hand, I see little use of pushing a port because of its inputs.

I was curious enough to write a q'n'd test and run it on P89V51RD2 and T89C51RD2 I happened to have at hand, and both do behave "biblically". I wonder whether there are other such "deviates" around...

Could those of you who have a '51 system around please try?


JW


PS. The "test" (X=18.432MHz, baud = 9600, having buttons on some bits of P3 - it was not the best idea to try P3 as it returns also some garbage via serial when doing the djnz P3 thingy):

   mov   SCON,#52h    ;set serial mode 1
   ORL   PCON,#80h
   mov   TMOD,#21h    ;timer0 16-bit, timer1 autoreload
   mov   TH1,#-10     ;9600
   setb  tr1          ;enable timer 1

Loop:
    jnb  ri,$         ;wait until character received 
    clr  ri           ;    not to flood the terminal
    mov  P3,#0FFh     ;refresh P3 for all cases
    mov  a,P3         ;direct load (should show inputs)
    call TxHexa
    mov  a,#'-'
    call TxChar
    push P3           ;push - this would show latch in OKI
    pop  acc
    call TxHexa
    mov  a,#'-'
    call TxChar
    clr  a
l1: inc  a            ;Chris's djnz solution - it works!
    djnz P3,l1
    mov  P3,a
    call TxHexa
    mov  a,#','
    call TxChar
    sjmp Loop


TxHexa:
    push acc
    swap a
    anl  a,#0Fh
    add  a,#TxHexaT-TxHexaX1
    movc a,@a+pc
TxHexaX1:
    call TxChar
    pop  acc
    anl  a,#0Fh
    add  a,#TxHexaT-TxHexaX2
    movc a,@a+pc
TxHexaX2:
;fallover
TxChar:
    jnb  ti,$
    clr  ti
    mov  sbuf,a
    ret

TxHexaT:
    db   '0123456789ABCDEF'

    end