From: BruceMcF on
OK, the User Port has two serial shift registers, as well as all of
PortB from one of the CIA's. Plus one generic I/O line from PortA and
the Handshake line.

The SPI interface is a four wire synchronous interface, and is a "de
facto" interface rather than a standardised-then-spread interface. The
controller is called the "Master", and the device being controlled is
called the "Slave". I normally call it the "Device".

SCLK: the serial clock
SS: Device Select. Pulled LOW to select the device.
MOSI: Serial Master Out Device In line ... output from controller to
device.
MISO: Serial Master In Device Out line ... input to controller from
device.

As a de facto standard, much depends on the specific device ... most
SPI devices are byte-wide, but some are 16-bits wide, and some Digital/
Analog chips are 12 bits wide.

One thing that makes SPI popular is that in the device being
controlled, the interface is often little more than a serial shift
register with bi-directional parallel access inside the device, and a
counter to trigger a write of data to the shift register and/or read
data from the shift register.

One of the most ubiquitous SPI interfaces was introduced with the
Playstation One, where digital switches were replaced with an joypad
controller interface that was read from over an SPI line. Other SPI
devices include a very large selection of flash RAM ... SPI is one of
the common bootflash interfaces, since the clock can be as fast as
both sides can handle ... SD and MMC cards, which support SPI as well
as their native three wire serial interface, and MAX parts that
provide both USB host controller and serial UART.

What I didn't understand, until I recently read through an example of
implementing an MMC interface for a 6502 hobbyist computer, is that
there are four possible modes implied by the above, and as a de facto
standard, all four modes have been used in one SPI device or another:

* The serial clock can start high, with the leading edge being the
falling edge and the trailing edge being the rising edge, or start
low, leading with a rise and trailing with a fall
* The data can either be available/read on the leading clock edge or
trailing clock edge.

If the User port is set up with the CIA serial shift register running
flat out, and the clock line for the register chosen as MISO tied to
the clock line for the register chosen as MOSI, it is a high clock,
trailing edge SPI ... this is called "Mode 3". Then the SS line can be
either the sole general purpose PortA I/O pin, or one of the eight
PortB I/O pins.

As C64 I/O goes, its reasonably nippy. The fastest the CIA can be
programmed to go is one serial shift register cycle for each 4 clock
cycles, so that is one byte transferred per 32 clock cycles. If the
next byte is loaded before the 32 clocks are up, its continuous
transfer, so that's 1 million cycles divided by 32 or 30KB/s+

The Mode 3 is intrinsically the "native" mode when using a CIA ... the
serial shift data is available from the end of the falling edge of the
clock cycle, through the following rising edge, and to the start of
the next falling edge.

The most common mode is Mode 0 ... data is available and required when
the clock cycle starts, and the clock starts low, rising and falling
for one complete clock cycle.

What can you do to get Mode 0 from the CIA? Well, one solution is to
bit bang. That is, specify SCLK, SS, MOSI and MISO at PortB pins and
just do it in software. Getting a byte out that way takes around 300
to 350 clocks, or about 3KB/s ... a program taking logging data from a
a 9600bps serial port would be able to keep up, but only if it did not
spend a lot of other clock cycles doing anything interesting.

However, Mode 0 and Mode 3 have their data available in the same SHAPE
of the clock cycle ... low, rising, and high ... its just a different
PHASE of the clock cycle, depending on whether the clock starts low
and that is the start, or the clock starts high and that is the end.

So hardware support would be able to convert the "intrinsic" UserPort
SPI into a Mode 0 SPI, if it could hold the serial clock low when the
serial bus was idle, keep it low until the first rising clock of the
hardware CLK line, and then when all the work for that transfer is
finished (one byte or hundreds of bytes), pull the clock low again
before deselecting the device.

Working that through, back of the envelope style, it turns out that
that is much easier to do in hardware if you give the hardware extra
help by having two "mode" lines ... the device select line, which is
pulled low at the start of the process and pulled high when the
process is over, and a phase line, which is flipped one way to to put
the hardware into "hold low until rising edge, then follow the clock"
mode, and flipped the other way to actually do the final pull down of
the serial clock line, after the CIA hardware clock is finished.

To me that says, eight PortB lines are four pairs of select and mode
control lines, for four possible devices on the SPI backplane. Since
that gives internal flash RAM ... say, 512KBytes, (described in parts
catalogues as 4Mbits), an SD/MMC socket, a high speed RS-232 UART, and
an option of a USB host controller, four seems ample. If it was me,
and given that some form of CPLD (maybe a PEEL18CV8) is required
anyway, I'd have design it with the internal flash and the UART, and
the other two SPI ports as DB-9 connectors on a specified pin-set
(female DB-9 connectors to avoid the RS-232 being plugged into the
wrong connector).

From: Jim Brain on
BruceMcF wrote:

Actually, the datasheet states data is valid on SP when the CLK falls,
so it is actually MODE 2. so you should be able to just invert the CLK
line and get MODE 0.

http://archive.6502.org/datasheets/mos_6526_cia.pdf (p 7)

You well need SS lines for each slave device you wish to talk to. Since
you won't talk to more than 1 at a time, I suggest a '138 to select 1 of
8 targets, using 0 as "idle". (G1 tied to Vcc, G2A to Bit3. G2B tied
to bit 4 of PortB). A second 138 can be used (G1 tied to Bit3, G2A tied
to GND, G2B tied to bit 4) for 16 targets, address 0 still being "idle".

Jim
From: BruceMcF on
On Jan 28, 2:52 pm, Jim Brain <br...(a)jbrain.com> wrote:
> BruceMcF wrote:
>
> Actually, the datasheet states data is valid on SP when the CLK falls,
> so it is actually MODE 2. so you should be able to just invert the CLK
> line and get MODE 0.

No, in Mode2/Mode0, the data has to be valid on MISO/MOSI prior to the
clock transition. The low bit of the Mode number is the phase ... data
is either valid *through* phase 0 or *through* phase 1 of the clock
cycle, the high bit is the default state of the clock.

Or lining them up by the actual transition, Mode 0, Mode 3: Data is
valid before, during, and after the CLK rise. Mode 0, CLK rise is the
leading edge of the clock phase, Mode3, CLK rise is the trailing edge.

Most dual mode devices *that I have seen datasheets for* (I have by no
means seen a large number) are Mode0 or Mode3.

Mode1, Mode 2: Data is valid before, during, and after the CLK fall.
Mode 1 is default low, so clock fall is phase0, Mode 2 is default
high, so the clock fall is phase0.

The datasheet says: "Data shifted out becomes valid on the falling
edge of CNT and remains valid until the next falling edge." So its the
trailing phase of the clock that data is available *through* a clock
transition. For Mode 0, it has to be the leading phase of the clock
that has data available *through* a clock transition.

> http://archive.6502.org/datasheets/mos_6526_cia.pdf(p 7)
>
> You well need SS lines for each slave device you wish to talk to. Since
> you won't talk to more than 1 at a time, I suggest a '138 to select 1 of
> 8 targets, using 0 as "idle". (G1 tied to Vcc, G2A to Bit3. G2B tied
> to bit 4 of PortB). A second 138 can be used (G1 tied to Bit3, G2A tied
> to GND, G2B tied to bit 4) for 16 targets, address 0 still being "idle".
>
> Jim

Having too many slave SPI devices is a headache in any event, but I'll
think about that.

Fewer parts is better ... if I can get by with Mode3 alone, I'll be
grinning.
From: Jim Brain on
BruceMcF wrote:
> The datasheet says: "Data shifted out becomes valid on the falling
> edge of CNT and remains valid until the next falling edge." So its the
> trailing phase of the clock that data is available *through* a clock
> transition. For Mode 0, it has to be the leading phase of the clock
> that has data available *through* a clock transition.

OK, I misread, but there should still be a way to easily switch it to Mode0.

I don't like the idea of so many SEL lines, as in your original idea.
That's wasteful of the limited IO on the user port. If there is no way
to switch to Mode0, I vote you hang a small SPI uC of some type off the
user port and be done. An AVR or PIC takes no more to program than a
PEEL or PAL/GAL and can provide a lot more value at the same cost.

> Fewer parts is better ... if I can get by with Mode3 alone, I'll be
> grinning.
I vote for uC, one IC to mess with. The advantage of that is the
ability to handle some higher level protocols (FAT for SD cards, etc.)
and you get a real USART to boot.

You can do an ATAPI-style interface with just the IO on the user port.
PORTB is data, PA2 is CMD/DATA, /IRQ could be /FLAG2, and /PC would
signal good data on PORTB. With a little thought, you could arrange it
so normal RS232 operation would not impact this communication.

Jim

From: BruceMcF on
On Jan 28, 2:52 pm, Jim Brain <br...(a)jbrain.com> wrote:
> BruceMcF wrote:
>
> Actually, the datasheet states data is valid on SP when the CLK falls,
> so it is actually MODE 2. so you should be able to just invert the CLK
> line and get MODE 0.
>
> http://archive.6502.org/datasheets/mos_6526_cia.pdf(p 7)
>
> You well need SS lines for each slave device you wish to talk to. Since
> you won't talk to more than 1 at a time, I suggest a '138 to select 1 of
> 8 targets, using 0 as "idle". (G1 tied to Vcc, G2A to Bit3. G2B tied
> to bit 4 of PortB). A second 138 can be used (G1 tied to Bit3, G2A tied
> to GND, G2B tied to bit 4) for 16 targets, address 0 still being "idle".
>
> Jim

A picture is worth a thousand words, but this is an ascii text
picture, so it only works in a fixed pitch font (courier, etc.)

The phase diagram from top to bottom: SEL, Clock0, Clock1, phase0,
phase1.

I'm typing this in Google groups, so I have to copy it from a fixed
pitch text editor.

\_________________________________/--
__/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\____
--\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/----
..=1=x=2=x=3=x=4=x=5=x=6=x=7=x=8=x=...
...x=1=x=2=x=3=x=4=x=5=x=6=x=7=x=8=...

CIA native is the second clock line (clock=1) and the second phase
line (phase=1) ... mode %11 = ... Mode3.