added JiffyDOS byte read error detection

This commit is contained in:
FeralChild64 committed 2020-05-05 20:13:29 +02:00
1 parent a76b3e21b0
commit dad5d21945
3 files changed
+25 -1

No files matched your search

+11
View File
@@ -75,6 +75,17 @@ kernalerror_ILLEGAL_DEVICE_NUMBER:
// FALLTROUGH
#if CONFIG_IEC_JIFFYDOS
kernalerror_IEC_TIMEOUT_READ:
lda #K_STS_TIMEOUT_READ
skip_2_bytes_trash_nvz
// FALLTROUGH
#endif // CONFIG_IEC_JIFFYDOS
kernalerror_TOP_MEM_RS232:
lda #K_ERR_TOP_MEM_RS232
+9 -1
View File
@@ -86,8 +86,11 @@ jiffydos_rx_byte:
// If CLK line active - success
bvc jiffydos_rx_byte_end
// XXX the DATA line can probably be used to distinguish between file not found error and normal stream EOI
// EOI or error, released DATA (highest byte set to 1) means error - see protocol analysis by Michael Steil, step R7a
lda CIA2_PRA
bmi jiffydos_rx_byte_error
// EOI - no error
jsr kernalstatus_EOI
// FALLTROUGH
@@ -109,5 +112,10 @@ jiffydos_rx_byte_end:
// End byte reception
jmp iec_rx_end
jiffydos_rx_byte_error:
jsr kernalerror_IEC_TIMEOUT_READ
bcs jiffydos_rx_byte_end // branch always
#endif // CONFIG_IEC_JIFFYDOS
+5
View File
@@ -100,6 +100,11 @@ jiffydos_tx_byte_wait_eoi:
sta CIA2_PRA
jsr iec_wait20us
lda C3PO
// According to protocol analysis by Michael Steil (step S8) we should pull the DATA here
// to signal there was no error; but DATA pulled by the controller is a normal state
// (which should be stored in C3PO), so there is nothing to do here.
jmp jiffydos_tx_byte_finalize