Mysterious 1541 behaviour

Well... maybe mysterious only for me (which I hope it to be :-)

There is a code for 1541, which transfers A supplied byte over (SpeedDOS type) parallel port:

parallel_send_byte_to_host:
	sta unused_44
	lda $1800
	ora #$02
	sta $1800
	lda #$ff	; data direction for Port A ($1801) all OUTPUTS
	sta $1803
:	lda $1800
	and #$04	; mask bit 2 CLK-in bit out
	beq :-		; wait for (CLK-in) bit to get HI...
	lda $1800
	and #%11100101	; clear DATA-out (and CLK-out and ATN-out)
	tay
	lda unused_44
	sta $1801	; put the byte on parallel port
	sty $1800	; bring DATA LO (it will get inverted on the host side)
:	lda $1800
	and #$04	; mask bit 2 CLK-in bit out
	bne :-		; wait for CLK-in to get LO
	lda $1800
	ora #$02	; prepare to set DATA HI
	tay
	sty $1800	; set DATA HI
	rts

Handshakes are done over DATA line.

What is mysterious though is that if there is a delay before sending out the very first byte (only!) then instead of the actual byte a $ff gets through.

	sei
	jsr delay
	jsr sync_with_host
	jsr delay
	lda #'1'
	jsr parallel_send_byte_to_host
	jsr delay
	lda #'2'
	jsr parallel_send_byte_to_host
	jsr delay
	lda #'3'
	jsr parallel_send_byte_to_host
	jsr delay
	lda #'4'
	jsr parallel_send_byte_to_host
	jsr delay
	jmp ($FFFC)

Only the "delay" _directly_ before lda #'1' affects the result sent. "delay" is a simple busy loop like:

delay:
	ldy #$00
	ldx #$00
:	dex
	bne :-
	dey
	bne :-
	rts

On the host side an equally simple routine receives the bytes:

parallel_get_byte_from_drive:
	ldx #$00    ; all CI2PRB (USER PORT)
	stx $dd03	; bits set for INPUTs
	ldx #$13    ; CLK HI and VIC bank 0 selected
	stx $dd00	; set to HI
	ldx #$03    ; that's for next handshaking - ATN, CLK, DATA set to LO while keeping VIC bank 0 selected
    
@wait_for_DATA_line_HI:
	bit $dd00	; wait for DATA line ack on the SERIAL (inverted LO from drive)
	bpl @wait_for_DATA_line_HI
        
	lda $dd01	; fetch the byte off the parallel port
	stx $dd00	; ATN and CLK set to LO while keeping VIC bank 0 selected
@wait_for_DATA_line_LO:
	bit $dd00	; wait for DATA line ack on the SERIAL (inverted HI from drive)
	bmi @wait_for_DATA_line_LO
    
	rts


IRQs are disabled on both sides.. Is there a known explanation to this phenomenon?

-- 
SD!
       Message was sent through the cbm-hackers mailing list