Generally this looks like transfer/copy code from BurstNibbler. The idea is if there is a delay in receiving the byte-ready signal, the hardware is probably waiting for a sync signal to end, so it sends a "sync" data byte back to the C64 (or drive RAM is extra RAM is used) every so often. This makes it easier to "write" this area back to the disk as a sync. The delays are cycle-counting to guess the actual sync length. This is also density specific, so these delays are usually runtime-modified. -Pete On Sun, January 20, 2013 12:18 pm, firstname.lastname@example.org wrote: > 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 > Message was sent through the cbm-hackers mailing listReceived on 2013-01-21 03:00:01
Archive generated by hypermail 2.2.0.