more IEC work - iec_tx_command can now detect missing devices

c64/kernal/iec_tx_byte.s

@@ -14,8 +14,25 @@ iec_tx_byte:
 
 	pla
 	jsr iec_tx_common
-
+	
+	;; All done - give device time to tell if they are busy by pulling DATA
+	;; They should do it within 1ms
+	ldx #$FF
+*	lda CI2PRA
+	;; BPL here is checking that bit 7 of $DD00 clears,
+	;; i.e, that the DATA line is pulled by drive
+	bpl +
+	dex
+	bne -
+	bpl iec_tx_byte_error
+*
 	;; All done
 	clc
 	rts
 
+iec_tx_byte_error:
+
+	jsr iec_set_idle
+	jmp kernalerror_DEVICE_NOT_FOUND
+
+

c64/kernal/iec_tx_command.s

@@ -14,7 +14,7 @@ iec_tx_command:
 
 	;; Did at least one device respond by pulling DATA?
 	lda CI2PRA
-	and #BIT_CI2PRA_DAT_IN
+	and #BIT_CI2PRA_DAT_IN ; XXX try to optimize this, move to separate routine
 	beq +
 
 	;; No devices present on the bus, so we can immediately return with device not found
@@ -39,7 +39,27 @@ iec_tx_command:
 	pla
 	jsr iec_tx_common
 
-	;; All done
+	;; According to https://www.pagetable.com/?p=1135 there is some complicated and dangerous
+	;; flow here, but http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf (page 6)
+	;; advices to just wait 1ms and check the DATA status
+	jsr wait1ms
+	lda CI2PRA
+	and #BIT_CI2PRA_DAT_IN ; XXX try to optimize this, move to separate routine
+	beq +
+	
+	;; XXX possible optimization of the flow above: for many commands it is enough
+	;; to wait for the DATA being pulled, as confirmation is expected from
+	;; a single device only - but not sure if it's worth the trouble
+
+	jsr printf
+	.byte "DBG: NO CONFIRMATION FROM DEVICE", $0D, 0
+
+	jsr iec_set_idle
+	jmp kernalerror_DEVICE_NOT_FOUND
+*
+	;; All done - before exiting wait a moment and restore bus to idle state
+	jsr iec_wait20us
+	jsr iec_set_idle
 
 	clc
 	rts

c64/kernal/iec_tx_common.s

@@ -1,6 +1,7 @@
 
 ;; This is a common part of iec_tx_byte and iec_tx_command
 ;; Implemented based on https://www.pagetable.com/?p=1135, https://github.com/mist64/cbmbus_doc
+;; and http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf
 
 iec_tx_common:
 
@@ -48,33 +49,8 @@ iec_tx_common_bit_is_sent:
 	dex
 	bpl iec_tx_common_nextbit
 	pla
-
-	;; Whole byte send, make sure ATN is released
-	jsr iec_release_atn_clk_data
-
-	;; XXX the flow below is REALLY dangerous, as if there are multiple devices,
-	;; one can signal that it's busy much earlier (more than 100ms) than the other.
-	;; Can we do something about it?
 	
-	;; All done - give devices time to tell if they are busy by pulling DATA
+	rts ; Flow continues differently for data/command
-	;; They should do it within 1ms
-	ldx #$FF
-*	lda CI2PRA
-	;; BPL here is checking that bit 7 of $DD00 clears,
-	;; i.e, that the DATA line is pulled by drive
-	bpl +
-	dex
-	bne -
-	bpl iec_tx_common_done
-*
-	;; Wait 100us to give busy devices some time
-	jsr iec_wait100us
-	
-iec_tx_common_done:
-
-	;; Byte sent, return
-	clc
-	rts
 	
 iec_tx_common_nextbit:
 

c64/kernal/open.s

@@ -84,25 +84,19 @@ open_iec:
 	;; Request device to talk
 	lda current_device_number
 	jsr talk
-	bcs open_iec_error ; XXX what about the accumulator?
+	bcs open_iec_error
 
-	jsr printf
-	.byte "DBG: OPEN 1", $0D, 0
-	
 	;; Send secondary address
 	lda current_secondary_address
 	jsr second
-	bcs open_iec_error ; XXX what about the accumulator?
+	bcs open_iec_error
-
-	jsr printf
-	.byte "DBG: OPEN 2", $0D, 0
 
 	;; Turnaround
 	jsr iec_turnaround_to_listen
-	bcs open_iec_error ; XXX what about the accumulator?
+	bcs open_iec_error
 
 	jsr printf
-	.byte "DBG: OPEN 3 - DEVICE EXISTS", $0D, 0
+	.byte "DBG: TURNAROUND SUCCEEDED", $0D, 0
 	
 	;; Indicate success
 	lda #$00