I have put together an SPI interface that can connect directly to the 65C02/65C816 bus.
I would like to know how many people are interested in using this interface. If there is
enough interest, then I'll continue with testing and let you know how it progresses.

thanks!

Daryl

65SPI

It uses a 44-pin (PLCC) Xilinx XC9572 CPLD. It is currently in prototype. I have not tested it yet.

It had the typical 65xx bus connections:
/RES, PHI2, R/W, /CS, A0, A1, /IRQ

The SPI side has MOSI, MISO,SCLK, 8 Slave Select Lines (SS0-SS7)
The MOSI, SCLK, and Slave Select pins are tristated when SPI is disabled

Here is a preview of the features:

Operates as an SPI master
SCLK has an 8 bit programmable divider
range is 1/2 PHI2 down to 1/512 PHI2
Mode 0,1,2,3 supported
Shifts MSB first
8-bit Slave select register with 8 Slave Select outputs.
External decoding can yield up to 255 addresses.
Direct decoding yields 8 devices

The register addresses are decoded like this:


Control register has these functions
ENA - SPI Enable - disable tristates SPI pins and disables shifting
IER - Enables IRQ when shifting is completed
CPOL - selects mode
CPHA - selects mode
** /RES clears all 4 Control registers.

Status Register reports these flags:
IRQ - active IRQ - reading Data Register clears this flag
IER - Interrupt Enable Register
ENA - SPI interface enabled
FIN - Finished shifting current byte, cleared when Data Register is read - for polled interface
BSY - Active while shifting is in progress, cleared when shifting is completed - for polled interface
CPOL - reflects status of CPOL register
CPHA - reflects status of CPHA register


Your Feedback is welcome

For a long time, I have wished there were such a part. I've done a lot of SPI and other synchronous-serial work, but always bit-banged it, which, although it gives total control, is limited in speed, and requires total processor attention.

I hope you'll add another CS line so it will be like the 6522 and 6551 and other 65xx parts that have both a CS\ and a CS line. For compatibility, these lines should expect to be valid and stable before phase 2 rises.

The part should be able to support different modes for different SPI selects. IOW, if you have a device at address %00000001 that wants mode 0 and one at %00000010 that wants mode 2 etc., it should be able to accommodate them without having to set it up differently every time you change which device you talk to. Actually, it would be good to be able to set the speed for each device too, so the slowest one does not hold everything else back.

Even if you don't want to mess with a PLL or onboard oscillator, there should be a separate clock input to optionally use with your divider. I say this because many SPI devices can operate with shift clocks up to 50MHz or even beyond, and it would be nice to shift fast enough that consecutive LDA or STA instructions don't need delays between them. With a slick addressing setup, a 65816 could copy a 1KB or 2KB page of serial flash memory at a time into or out of main memory at a rate of one byte every seven clocks. At the extreme low-speed end, dividing phase 2 by 512 would require thousands of 6502 clock cycles to get one byte through.

I can't think of anything offhand that would be incompatible with our 6502.org serial bus devised at viewtopic.php?t=1064 and the following pages, but it would be good to double check. (It should be enough to read just the last few pages if you don't want to read the whole thing as it developed and some ideas were dumped.) I'm sure kc5tja will have some input based on his work in progress on the protocol for autoconfiguration and related things. This bus is an externalization of SPI but can be used for Microwire and dumb shift registers as well. It is very versatile. Some of the hardware spec. refers to the connection scheme for select lines, interrupts, powering up tiny peripherals that don't have their own power supply, and probably something else I'm forgetting at the moment.

I know I'm coming up with a wish list for Santa Clause, but can you put I²C on it too? That's another one I've been bit-banging, but there would be less to gain by having a 65xx part do it automatically because I²C is never as fast. Still, it would save code space to not have the bit-banging program in memory, it would save bits on the 6522s, etc..

Having slave mode too would be nice but not very necessary.

That should not be a problem.


That would require at least 10 bit's per slave address to be registered. The CPLD doesn't have enough register space for that. You'll have to Write the Control register to set clock mode, the clock divisor register to set the clock speed, the slave select register, then your data on the data register. Not exactly efficient, but much faster than bit banging. Consecutive writes to the same device would only require this set-up before the first write. You can then write the data register only for consecutive bytes.


I'll see if I can squeeze that in. I'm currently configured for specific interfacing on my SBC-3. If I remove some SBC-3 logic, I should be able to add the ext. clock.



That might me more than the CPLD can handle, but I can research it.

As far as I2C, that may be best handled by another custom CPLD, similar to this one.

Thanks for the feedback.

As far as the CPLD not being able to handle more-- is there a bigger one in the same family? I realize it's a big job, but we might as well get all the desired features in one part to avoid more bus loading and board real estate.

I just love the idea, if you make the core of the functionality separate from the IO section this could be used to build even more advanced functions in FPGAs. I'm thinking SPI, I2C a UART and maybe some PIO in the same FPGA. Xilinx has an inexpensive FPGA XC3S50 (50K gates) that could incorporate some or all of these functions.

/Pontus

The XC95108 is the next largest size. It is an 84 pin PLCC. It has 108 registers total. My design is using 70 registers. I'm not sure if I can get an I2C in the space left over. The higher 95 series devices are all surface mount with .5mm pin spacings.

Moving up to an FPGA also involves some surface mount parts, lower voltage requirements, and flash/eeprom configuration IC's as well.

Let me get the SPI working, and then I'll take a look at I2C.

If you're not planning on selling these in 1000+ volumes I'd prefer keeping things simple, please Multifunction chips are fine, unless you're not using the functionality and the "extra free stuff" in the chip actually makes things harder by precluding the use of through-hole parts, requiring more different voltages on the board, etc.

As long as people are suggesting ideas for things to put in a CPLD, how about a DMA controller that makes use of that "secret free DMA" trick described in http://homepage.mac.com/jorgechamorro/a ... a2DMAMagic ?

I don't know of any CPLDs that are available as DIPs, but a PLCC can go into a thru-hole (even wire-wrap) PLCC socket. I don't know how big this other series is that he's talking about that is SMT-only and has the .5mm (.020") lead spacing, but since not all the pins would need to be connected, we could make a tiny PC board that converts the SMT part to plug it into a PLCC socket, or maybe one that sits on top of, and gets soldered to, a DIP header. A 28-pin DIP header won't be enough for all the pins he's talking about so far:

RST\, phase 2, CS0\, CS1, R/W\, RS0, RS1, IRQ\
8 data (for µP interface)
External-clock input
MOSI, MISO, SCLK
8 SPI select lines
2 grounds, 2 Vcc (power and ground on adjacent pins near the center)
I²C CLK and Data

That's 34 pins already, and he may want to add more register-select lines if he puts in more than he initially said. Certainly a 40-pin will be enough, although I was hoping it wouldn't be so big. The adapter board would sit on top of the DIP header and maybe stick out the sides a little since the CPLD will probably be too wide to go between the DIP header's pins. Since WW PLCC sockets are so expensive and hard to find, the adapter board and DIP header may be the better way to go.

I know PLCC ICs can be used in through-hole designs. All I'm asking is that he doesn't give in to feature creep and produce an all in one uber chip that is all but impossible to use by someone without years of industry experience.

Since these are all programmable logic, it really doesn't matter until pin count or registers become a limitation. With CPLDs, "registers" are 1-bit wide, and are used both for CPU-facing registers as well as implementation-specific registers. This is one reason why the Amiga chipset exposes most of its internal registers to the CPU, allowing for such weird things as 1.536Mbps throughput on the RS-232 port, 12-bit RS-232 data frames, and a whole host of other neat things that most chipsets would look at you funny for.

So, why not compromise?

Start with the most basic chip design. Let's call it the 65100 for lack of better identifier. This is the basic 65SPI implementation.

Now, fabys comes along and says, "You know what? I need to address 4 SPI devices, but I don't have enough room for another VIA chip to man the /CS pins." So, the 65101 is released, incrementally adding the features requested by fabys.

Now, Garth tags along and says, "Gosh, kc5tja is taking for EVER to release his Kestrel design. I really need the SerBus implementation now! I'd like to have 8 /CS outputs, a rate generator, etc." Knowing that this is a proper superset to the 65101, the 65102 is released, based on the design of the 65101.

Then, maybe Mike comes along and says, "I don't need 8 /CSs, but can you throw in an IRQ controller for me? Turn 4 of the /CS pins into IRQs from other devices, and, . . ." you get the idea. So hardware permitting, of course, that can be released fairly simply as well as the 65103.

So, we find our chip's family tree as follows:

I believe this is how most semiconductor manufacturers work. Then, if/when I release the Kestrel's chip design in FPGA form factor, I might release it as the 65200 or whatever. Likewise, if people want customizations, I can either just send them the Verilog code, or, make the mods they request, and release it under a new part number.

In other words, I agree with Fabys here. Keep it simple. Wait and see what happens with the chip that gets produced.

My current design was created as part of my SBC-3 and incorporates the SPI with 8 Slave Selects and an address decoder for 2 VIA's with IRQ decoding for both. I used every pin in doing so. Dropping back to pure SPI will allow for external clock input and adding a CS to go with the /CS.

As kc5tja pointed out, let me get the basic SPI working, and them we can look at adding more options.

I received my SBC-3 daughter boards today. I've got a busy weekend, but will try to get one completed and do some testing on the 65SPI. I will be using an ATMega8 first. It will pass RS-232 data to the SPI and from the SPI to the RS-232. I can experiment with the 4 clock modes and different speeds, including an external clock as Garth requested.

I'll let ya know how it goes.

Daryl

Status on the 65SPI:

I have put the daughter board together, gotten the 6522 IO working and after a few glitches, have the SPI registers accessible on the 65816 bus.

I connected my scope to the SCK and MOSI lines and can see pulses when writing to the SPI data port. I will be checking for correct phase in the 4 modes and then will try to connect up an SPI device.

Daryl

Feature creep from here: USB
but since they have RS232 to USB, that would be redundant and trivial.

but definitely interested as well.

I am thinking on my pinball side since3 I am using an XC57108 to integrate all teh spare logic eventually that there may be enough room left over to use your SPI interface and make a debug for this pup (Kowalsi's debug step can only go so far on this....)

I think the 134 uses a SPI in certain modes, forgot offhand.

_________________
"My biggest dream in life? Building black plywood Habitrails"

They also have SPI to USB, so if your microcontroller or home-made computer has SPI, you can get USB with one IC. There are probably more of these and cheaper too, since SPI is a better match speedwise than RS-232 is.