While there is much talk about just receiving the data with the SR (or in general). SPI is a bidirectional protocol, you need to be able to send commands as well.
So, if you use the VIA SR to receive data, I assume to get as fast as you can, you use Phi2 clock input for the SR. that means that you need to use CB1 clock output as source for the SPI clock. And then you end up in the mode 0 / mode 3 mess already again, right? I even wonder how you are going to receive mode 0: data is shifted out when /SEL activates (first valid bit), and on falling clock of SCLK. If you use the inverted SR clock as SPI clock, you shift the data in exactly when the device already shifts out a new bit. That typically works if the device goes by the "specification". I've done that as well, but it is not a good design. You would need a delay circuit for the clock anyway, as Bruce has proposed in the other thread.
But how are you going to send data? If you switch SR direction, you need to switch SR output CB2 between MISO and MOSI, which costs additional gates and a gate that switches direction.
You can bit-bang data out on MOSI - but then you need to have a way to send pulses on SPI clock also - despite it is driven by SR clock (CB1) when receiving. Again additional gates.
Ok, at a minimum hardware you could use an NAND between CB1 and a port bit used as SPI clock output when sending to drive the SPI clock, put MOSI from another port bit and MISO to the SR input. But that means that anytime you want to send data you have to bit-bang it. (Note that I'd probably use the clock delay from here
download/file.php?id=20395&mode=view and connect the output clock port bit to IC2 pin 12, to have a more compliant SPI mode 0 clock).
Yet, at the cost of that single external serial-to-parallel shift in chip, I firmly believe that this
download/file.php?id=20395&mode=view is a very balanced and efficient approach in terms of hardware and software used, and provides full speed in both directions.
Code:
BIT PORTA ; trigger /ACK for clock circuit
; ... per byte
STA SR ; trigger transfer
LDX #$FF
L0 LDA #4
L1 BIT IFR ; check
BEQ L1
LDA PORTA ; read incoming data
STX SR ; trigger next transfer (by sending $ff in this case)
; process received data (e.g.)
STA (ZP),Y
INY
BNE L0
If you count clock cycles, and your processing time is long enough, it may even be possible to remove the IFR check.
You may need to be careful with the end condition.
_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content:
http://6502.org/users/andre/