fixed 1ms wait

c64/kernal/iec/iec_tx_command.s

@@ -18,7 +18,7 @@ iec_tx_command:
 	jsr iec_pull_atn_clk_release_data
 
 	;; Give devices time to respond (response is mandatory!)
-	jsr wait1ms
+	jsr iec_wait1ms
 
 	;; Did at least one device respond by pulling DATA?
 	lda CIA2_PRA
@@ -44,7 +44,7 @@ iec_tx_command:
 	;; 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
+	jsr iec_wait1ms
 	lda CIA2_PRA
 	and #BIT_CIA2_PRA_DAT_IN ; XXX try to optimize this, move to separate routine
 	beq +

c64/kernal/iec/iec_wait1ms.s

@@ -0,0 +1,20 @@
+
+;;
+;; Wait 1 ms (1000 usec)
+;;
+;; On NTSC this means 1023 cycles (slightly less on PAL, but we have to be sure).
+;; We can't count on badlines, as the screen might be disabled.
+;; Delay here is implemeented using VIC-II raster register. Since one raster is
+;; 63 cycles, we need at least 17 full rasters to be 100% sure we wait enough
+
+
+iec_wait1ms:
+	ldx #18 ; we probably won't start with the beginning of raster
+	lda VIC_RASTER
+*
+	cmp VIC_RASTER
+	beq -
+	lda VIC_RASTER
+	dex
+	bne -
+	rts

c64/kernal/wait1ms.s

@@ -1,14 +0,0 @@
-	;; 16 rasters = 16 x 63 cycles = ~1ms
-	;; (Probably 2 will be bad lines, so we will over-estimate the delay a bit)
-	
-wait1ms:
-	ldx #16
-	lda $d012
-*
-	cmp $d012
-	beq -
-	lda $d012
-	dex
-	bne -
-	rts
-