65SPI

[plasmo]

GARTHWILSON wrote:

Bill, before committing, do consider also our SPI-10 hobbyist-friendly connector. From the "Expansion buses and interfaces" page of the 6502 primer:

Thanks for the link to SPI10. Since SPI10 and UEXT share the same power and ground and the other 8 pins go to CPLD, the functionalities of the 8 pins can be redefined by how the CPLD is programmed for a specific application. So I think of them as compatible, depending on how the connector is populated and how CPLD is programmed.
Bill

[jaccodewijs]

Hello all!

A few years later (life happened), but I can confirm that the 65SPI on the ATF1504 is working flawlessly at 8 MHz as well!

I have implemented it in my homebrew SBC and use SPI for all communication to the outside world (apart from a UART)
It now controls a sound device, WiFi modem, game controllers, USB thumbdrive interface, and I have more plans in the making.

[8BIT]

That's great news - thank you for providing feedback.

Daryl

[powellb]

Just wanted to let you know that I also use your 65SPI with my 68k SBC. I modified the PLD logic slightly as the 68k-series is asynchronous, so rather than being keyed to PHI2, It is qualified by /AS on the 68k. This also lets me have two independent clocks to pick from for each device, since some are slow, but others (SD card, etc.) can have much faster clocks. If interested, I can post the modified .pld for 68k.

One thing I notice in reviewing the SD Card docs and other libraries is a lot of deasserting CS and then sending clock signals to "sync the device". I'm unsure if that is really needed at the moment, but I may have to modify the PLD to still transmit if no device is asserted.

Thanks for a great design!

[8BIT]

Hi powellb,

Glad to hear you have a working SPI interface for your project. Post the sources here if you like.

The setting of the slave select outputs is independent of the shift operations, so you should be able to trigger a shift the normal way even though no devices are selected.

Daryl

[powellb]

8BIT wrote:

Glad to hear you have a working SPI interface for your project. Post the sources here if you like.

Daryl,

I have attached the PLD file. It removes the MRD and MWR lines as not needed (and I was thinking to add an /BGACK line for 68k, but my glue chip handles that anyway). The only thing it really does is not qualify to PHI2, but to /AS (Address Strobe). Works great! Thank you for your hard work on this.

NOTE: I fought with the original PLD file for a week because I could not get anything to work. The 65SPI was completely taking over the system bus. It was very aggravating, then I realized that the new WinCUPL (I downloaded the latest for Windows 11) was reassigning all of the pins from the PLD. I changed the line:

Code: Select all

PROPERTY ATMEL {PREASSIGN = YES};       /* Allow pin pre-assignment */

to

Code: Select all

PROPERTY ATMEL {PREASSIGN = KEEP};      /* Allow pin pre-assignment */

Then, it kept the defined pin locations. It was only because I started going through each of the output files carefully, and one of them produces a pin map that I realized what was happening. I assume that change was with the new WinCUPL; otherwise, it would have been brought up.

[powellb]

8BIT wrote:

The setting of the slave select outputs is independent of the shift operations, so you should be able to trigger a shift the normal way even though no devices are selected.

You're right. I forgot to mention that I spent a couple of hours on the SD Card yesterday and got it to read sectors off of the card. I did it all with the SD Card CS asserted, so I didn't bother just pulsing SCLK without asserting a device. I have to say that SD Card SPI spec is a pain (lots of filler bytes, etc.) compared to most other SPI devices I have tried...

Thanks again!

[8BIT]

Thanks for posting the source! I'm glad it is working with your SD card.

I have not played with SD cards, I kept my projects working with the CF Flash IDE adapter I built. They were very easy to access and FAT16 compatibility was much simpler that trying to support FAT32. I didn't see the value added for simple 8-bit SBC's.

Have fun with all you projects!

Daryl

[barnacle]

8BIT wrote:

...and FAT16 compatibility was much simpler that trying to support FAT32....

Now he tells me

Neil

[BigDumbDinosaur]

powellb wrote:

NOTE: I fought with the original PLD file for a week because I could not get anything to work. The 65SPI was completely taking over the system bus. It was very aggravating, then I realized that the new WinCUPL (I downloaded the latest for Windows 11) was reassigning all of the pins from the PLD. I changed the line:

Code: Select all

PROPERTY ATMEL {PREASSIGN = YES};       /* Allow pin pre-assignment */

to

Code: Select all

PROPERTY ATMEL {PREASSIGN = KEEP};      /* Allow pin pre-assignment */

Then, it kept the defined pin locations. It was only because I started going through each of the output files carefully, and one of them produces a pin map that I realized what was happening. I assume that change was with the new WinCUPL; otherwise, it would have been brought up.

You should know that it isn’t WinCUPL doing that; it’s the fitter.  That has been the default for as long as I’ve been messing with Atmel PLDs (about 15 years now).  In other words, it’s normal behavior.

My usual procedure with a new design is to only assign pin numbers for pins with specific functions, e.g., clock inputs, reset, etc..  The rest of the pin assignments aren’t numbered, which allow the fitter to better distribute the logic.  So I actually design the circuit to work with the fitter’s choices.

Something else to note is Atmel has long recommended that statements such as NODE [si0..7];   /* shift in data reg */ should be written as PINNODE [si0..7]; /* shift in data reg */.  It turns out that during the fitting process, the PINNODE verb causes the fitter to use shorter paths through the logic fabric.  At least, that is how Atmel technical support explained it to me years ago.  That only applies to the CPLDs, not the GALs.

[BigDumbDinosaur]

barnacle wrote:

8BIT wrote:

...and FAT16 compatibility was much simpler that trying to support FAT32....

Now he tells me

Well, whaddya expect when it’s a Micro-$oft “invention”?