Re: Mysterious 1541 behaviour

From: Pete Rittwage <peter_at_rittwage.com>
Date: Sun, 20 Jan 2013 20:43:17 -0500 (EST)
Message-ID: <63742.75.76.203.106.1358732597.squirrel@rittwage.com>
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, silverdr@wfmh.org.pl 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 list
Received on 2013-01-21 03:00:01

Archive generated by hypermail 2.2.0.