IEC cleanups and size optimization
This commit is contained in:
FeralChild64 committed
1 parent
ee499b6b21
commit
e3314f8b8f
6 files changed
+74
-100
No files matched your search
@@ -76,7 +76,7 @@ open_iec:
|
||||
lda current_secondary_address
|
||||
jsr iec_cmd_open
|
||||
bcc +
|
||||
jmp kernalerror_DEVICE_NOT_FOUND ; XXX find a better error message for wrong channel (create new one?)
|
||||
jmp kernalerror_DEVICE_NOT_FOUND
|
||||
*
|
||||
|
||||
;; We need our helpers to get to filenames under ROMs or IO area
|
||||
|
||||
@@ -65,7 +65,7 @@ load:
|
||||
;; Open channel 0 (reserved for file reading)
|
||||
lda #$00
|
||||
jsr iec_cmd_open
|
||||
bcs lvs_load_verify_error
|
||||
bcs lvs_device_not_found_error
|
||||
|
||||
;; Send file name
|
||||
jsr lvs_send_file_name
|
||||
|
||||
@@ -19,11 +19,73 @@ iec_tx_byte:
|
||||
;; and it is going to be a data byte (released ATN)
|
||||
jsr iec_release_atn_clk_data
|
||||
|
||||
;; Common part of iec_txbyte and iec_tx_common - waits for devices
|
||||
;; and transmits a byte
|
||||
;; 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:
|
||||
|
||||
;; Timing is critical here - execute on disabled IRQs
|
||||
php
|
||||
sei
|
||||
|
||||
;; Wait till all receivers are ready, they should all release DATA
|
||||
jsr iec_wait_for_data_release
|
||||
|
||||
;; At this point a delay 256 usec or more is considered EOI - add waits if necessary
|
||||
bcc +
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait60us
|
||||
|
||||
;; XXX waits above should be enough - why do we need more waits???
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
|
||||
;; Receiver should now acknowledge EOI by pulling data for at least 60 usec
|
||||
jsr iec_wait60us
|
||||
jsr iec_wait_for_data_release
|
||||
*
|
||||
;; Pull CLK back to indicate that DATA is not valid, keep it for 60us
|
||||
;; We can use this routine as we don't hold DATA anyway (and its state doesn't even matter)
|
||||
|
||||
jsr iec_pull_clk_release_data_oneshot
|
||||
jsr iec_wait60us
|
||||
|
||||
;; Now, we can start transmission of 8 bits of data
|
||||
ldx #7
|
||||
|
||||
iec_tx_common_sendbit:
|
||||
;; Is next bit 0 or 1?
|
||||
lda IEC_TMP2
|
||||
lsr
|
||||
sta IEC_TMP2
|
||||
bcs +
|
||||
|
||||
;; Bit is 0
|
||||
jsr iec_release_clk_pull_data
|
||||
jmp iec_tx_common_bit_is_sent
|
||||
*
|
||||
;; Bit is 1
|
||||
jsr iec_release_clk_data
|
||||
|
||||
iec_tx_common_bit_is_sent:
|
||||
|
||||
;; Wait 20us, so that device(s) can pick DATA
|
||||
jsr iec_wait20us
|
||||
|
||||
;; Pull CLK for 20us again, before sending the next bit
|
||||
;; or performing any other action
|
||||
jsr iec_pull_clk_release_data_oneshot
|
||||
jsr iec_wait20us
|
||||
|
||||
;; More bits to send?
|
||||
dex
|
||||
bpl iec_tx_common_sendbit
|
||||
|
||||
plp
|
||||
|
||||
jsr iec_tx_common
|
||||
|
||||
;; Give device time to tell if they are busy by pulling DATA
|
||||
;; They should do it within 1ms
|
||||
ldx #$FF
|
||||
@@ -36,5 +98,3 @@ iec_tx_byte:
|
||||
bpl iec_return_DEVICE_NOT_FOUND
|
||||
*
|
||||
jmp iec_return_success
|
||||
|
||||
|
||||
@@ -20,8 +20,9 @@ iec_tx_command:
|
||||
jsr iec_pull_atn_clk_release_data
|
||||
|
||||
;; Give devices time to respond (response is mandatory!) by pulling DATA
|
||||
jsr iec_wait1ms_for_data
|
||||
bmi iec_tx_command_dev_not_found
|
||||
jsr iec_wait1ms
|
||||
lda CIA2_PRA ; pulled DATA = highest bit 0 = 'plus'
|
||||
bmi iec_return_DEVICE_NOT_FOUND
|
||||
|
||||
;; At least one device responded, but they are still allowed to stall
|
||||
;; (can be busy processing something), we have to wait till they are all
|
||||
@@ -34,19 +35,5 @@ iec_tx_command:
|
||||
;; and transmits a byte
|
||||
|
||||
clc ; Carry flag set is used for EOI mark
|
||||
jsr iec_tx_common
|
||||
jmp iec_tx_common
|
||||
|
||||
;; 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 iec_wait1ms_for_data
|
||||
bmi iec_tx_command_dev_not_found
|
||||
|
||||
;; Done
|
||||
|
||||
jmp iec_return_success
|
||||
|
||||
iec_tx_command_dev_not_found:
|
||||
|
||||
jmp iec_return_DEVICE_NOT_FOUND
|
||||
@@ -1,72 +0,0 @@
|
||||
|
||||
;; 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
|
||||
|
||||
;; Expects byte to send in IEC_TMP2 ($A4 is a byte buffer according to http://sta.c64.org/cbm64mem.html)
|
||||
;; Carry flag set = signal EOI
|
||||
|
||||
iec_tx_common:
|
||||
|
||||
;; Timing is critical here - execute on disabled IRQs
|
||||
php
|
||||
sei
|
||||
|
||||
;; Wait till all receivers are ready, they should all release DATA
|
||||
jsr iec_wait_for_data_release
|
||||
|
||||
;; At this point a delay 256 usec or more is considered EOI - add waits if necessary
|
||||
bcc +
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait60us
|
||||
|
||||
;; XXX waits above should be enough - why do we need more waits???
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
jsr iec_wait100us
|
||||
|
||||
;; Receiver should now acknowledge EOI by pulling data for at least 60 usec
|
||||
jsr iec_wait60us
|
||||
jsr iec_wait_for_data_release
|
||||
*
|
||||
;; Pull CLK back to indicate that DATA is not valid, keep it for 60us
|
||||
;; We can use this routine as we don't hold DATA anyway (and its state doesn't even matter)
|
||||
|
||||
jsr iec_pull_clk_release_data_oneshot
|
||||
jsr iec_wait60us
|
||||
|
||||
;; Now, we can start transmission of 8 bits of data
|
||||
ldx #7
|
||||
|
||||
iec_tx_common_sendbit:
|
||||
;; Is next bit 0 or 1?
|
||||
lda IEC_TMP2
|
||||
lsr
|
||||
sta IEC_TMP2
|
||||
bcs +
|
||||
|
||||
;; Bit is 0
|
||||
jsr iec_release_clk_pull_data
|
||||
jmp iec_tx_common_bit_is_sent
|
||||
*
|
||||
;; Bit is 1
|
||||
jsr iec_release_clk_data
|
||||
|
||||
iec_tx_common_bit_is_sent:
|
||||
|
||||
;; Wait 20us, so that device(s) can pick DATA
|
||||
jsr iec_wait20us
|
||||
|
||||
;; Pull CLK for 20us again, before sending the next bit
|
||||
;; or performing any other action
|
||||
jsr iec_pull_clk_release_data_oneshot
|
||||
jsr iec_wait20us
|
||||
|
||||
;; More bits to send?
|
||||
dex
|
||||
bpl iec_tx_common_sendbit
|
||||
|
||||
plp
|
||||
rts ; Flow continues differently for data/command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
|
||||
;;
|
||||
;; Wait 1 ms (1000 usec) - afterwards can use 'bpl' to check that DATA is pulled
|
||||
;; 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.
|
||||
@@ -8,7 +8,7 @@
|
||||
;; 63 cycles, we need at least 17 full rasters to be 100% sure we wait enough
|
||||
|
||||
|
||||
iec_wait1ms_for_data:
|
||||
iec_wait1ms:
|
||||
ldx #18 ; we probably won't start with the beginning of raster
|
||||
lda VIC_RASTER
|
||||
*
|
||||
@@ -18,5 +18,4 @@ iec_wait1ms_for_data:
|
||||
dex
|
||||
bne -
|
||||
|
||||
lda CIA2_PRA ; pulled DATA = highest bit 0 = 'plus'
|
||||
rts
|
||||
Reference in new issue
Block a user