Open source A500 simple SPI controller

[Mathesar]

I have been working on this idea for a very simple SPI controller for the Amiga 500 and I am pleased to announce that it is ready for release!

Called the "A500 simple SPI controller", this small internal device plugs into the 68K CPU socket and allows you to connect an internal SD card and an internal/external ENC28J60 ethernet controller to your Amiga 500.
This SPI controller is designed to be as simple as possible so that anyone can build it, hence the "simple" SPI controller. The design uses no programmable logic chips but only jellybean 3.3V 74LVCXX logic chips and a jellybean quad analog switch. It also uses readily available cheap modules for the ethernet and SD-card interfaces. This design was done in Kicad 6.0 and all the files plus a lot more pictures can be found here: https://github.com/Mathesar/a500-simple-spi-hardware.

Drivers are also provided and can be found here: https://github.com/Mathesar/a500-simple-spi-drivers
The drivers are build upon the excellent previous work by Niklas Ekstrom and Mike Stirling.

Hardware:




Internal/external ethernet, I have to print some nice 3D enclosure for this...




AmiTCP in action! Downloading some stuff from Aminet, pinging my favourite website...



The SD card is more than 200% faster than a standard Amiga 500 floppy drive!

[Niklas]

Very cool! It's always nice to see new open source Amiga hardware. Nicely done.

[Mathesar]

Originally Posted by Niklas

Very cool! It's always nice to see new open source Amiga hardware. Nicely done.

Thanks! But most of the work was actually in the software. Luckily I had some great examples

[utri007]

Nice! Zorro version would be nice, but maybe too much to wish.

Though there are open source Zorro II passthrough for a Amiga 500 to use with sidecars. Which would mean more possible users?

[Mathesar]

Originally Posted by utri007

Nice! Zorro version would be nice, but maybe too much to wish.

Though there are open source Zorro II passthrough for a Amiga 500 to use with sidecars. Which would mean more possible users?

The goal with this design was to make it as simple as possible, just like the 14MHz accelerator I posted before.

It wouldn't be too hard too make a Zorro-II version but then I would probably use a CPLD or something similar. SPI interfaces are among the simplest interfaces to implement. The hard work is always in the software. A Zorro-II version could be a more sophisticated design with a hardware shifter and autoconfig logic contained within a small CPLD. That would easily be at least 10 times faster even on a 7MHz 68000. And the only thing that would have to change are the lowlevel SPI functions.
Thinking about it.... an open source ethernet controller for big box Amiga's would be nice. I don't think any exist right?

[utri007]

Originally Posted by Mathesar

Thinking about it.... an open source ethernet controller for big box Amiga's would be nice. I don't think any exist right?

There is this

https://github.com/MHeinrichs/Zorro-LAN-IDE

SPI could be lots of more than LAN, or mass storage.

[SukkoPera]

Nice work, keep it up!

[orphan264]

Nice! Well Done!

[tygre]

Bravo!

[Mathesar]

Originally Posted by utri007

There is this

https://github.com/MHeinrichs/Zorro-LAN-IDE

SPI could be lots of more than LAN, or mass storage.

A design by Matze so should be good! No need for a new design then.

Maybe the next project for me is to combine the 14MHz accelerator and the SPI controller in an nice external GVP HD8+ like design that plugs into the side expansion slot. Sort of like an ACA500+ but then good looking. I tried stacking the 14MHz accelerator stacks upon the simple SPI controller and that worked like a charm. Made everything go much faster but the low amount of fast ram (only 1MB) is a limiting factor so a new external design would need 4MB or more.

What else would be interesting on SPI btw? An RTC clock? MP3 decoder?

[utri007]

Originally Posted by Mathesar

Maybe the next project for me is to combine the 14MHz accelerator and the SPI controller in an nice external GVP HD8+ like design that plugs into the side expansion slot. Sort of like an ACA500+ but then good looking. I tried stacking the 14MHz accelerator stacks upon the simple SPI controller and that worked like a charm. Made everything go much faster but the low amount of fast ram (only 1MB) is a limiting factor so a new external design would need 4MB or more.

I have GVP HD8+ and it looks really looks good. How you gonna get cases for these? I like the idea, would like to have one.

What else would be interesting on SPI btw? An RTC clock? MP3 decoder?

MP3 decoder would be nice, BT module would be too much to wish, but there are also, USB hosts, LCD displays, radio receivers, etc. Would be cool to have status messages to LCD screen, etc.

I think that most import part would be make a standardized SPI control and library system with GUI, which would allow others make drivers for what they want.

[Daedalus]

Originally Posted by utri007

I think that most import part would be make a standardized SPI control and library system with GUI, which would allow others make drivers for what they want.

Absolutely, this is a key think for SPI, I2C and similar add-ons that are appearing. There are already some device driver libraries out there, it would make sense to keep things consistent and present a standard API so that one driver for e.g. an SD card reader can be used with any SPI interface by setting the appropriate options.

[Mathesar]

Originally Posted by utri007

I have GVP HD8+ and it looks really looks good. How you gonna get cases for these?

3D printing! I got inspired by this one:
https://www.thingiverse.com/thing:4830638. That one looks a bit "boxy", but imagine it with a GVP HD8+ design but then a bit smaller...
We don't need to house a whole 3.5" drive, just a (micro) SD card and some RAM chips....

[Mathesar]

Originally Posted by Daedalus

Absolutely, this is a key think for SPI, I2C and similar add-ons that are appearing. There are already some device driver libraries out there, it would make sense to keep things consistent and present a standard API so that one driver for e.g. an SD card reader can be used with any SPI interface by setting the appropriate options.

We talked about this before right? I would love something like this. For me, as a hardware developer I would only have to build a "spi.device" or something and then everything would work. We could then also have some standard, fully developed, stable and feature-complete SD, Ethernet and whatever drivers. Now anyone (like me) who has dedicated a few gates to an SPI controller has to re-invent the wheel.

[Daedalus]

Yep, I'm sure we have writing drivers and developing APIs is something I really need to get into. Every time I sit down to do something like that though I think "boring!" and instead cobble together a quick hardware-banging proof-of-concept and leave it at that :/

[Mathesar]

Originally Posted by Daedalus

Yep, I'm sure we have writing drivers and developing APIs is something I really need to get into. Every time I sit down to do something like that though I think "boring!" and instead cobble together a quick hardware-banging proof-of-concept and leave it at that :/

First thing to determine is what this shared SPI thingy should be, a device? a resource? a library?
Personally I think the overhead of a device may be too large.
Just look at the SD or ENC28J60 driver code, lots of small consecutive read/write operations happening. I think the overhead of calling DoIo() or BeginIo() which then calls BeginIo(), message passing, task switching, etc would slow the system down too much. Or am I missing something and is the overhead manageable if we only do QUICKIO or something?
I think a library or a library masquerading as a resource is way leaner. A library function can be called directly without any overhead. But a resource needs to be loaded by some application while a library is automatically loaded from disk by the OS....
So I would think it needs to be a library or maybe a device.....

[nikosidis]

Mathesar: Nice I like to use this with your accelerator. Did you build any extra for sale?

[Niklas]

Originally Posted by Mathesar

We talked about this before right? I would love something like this. For me, as a hardware developer I would only have to build a "spi.device" or something and then everything would work. We could then also have some standard, fully developed, stable and feature-complete SD, Ethernet and whatever drivers. Now anyone (like me) who has dedicated a few gates to an SPI controller has to re-invent the wheel.

I wrote together this wiki page just now: https://github.com/niklasekstrom/ami...-device-driver

Let me know what you think about this proposal. The wiki is publicly editable if you want to edit there directly, or comment here and I can update later.

[hooverphonique]

Originally Posted by Mathesar

First thing to determine is what this shared SPI thingy should be, a device? a resource? a library?
Personally I think the overhead of a device may be too large.
Just look at the SD or ENC28J60 driver code, lots of small consecutive read/write operations happening. I think the overhead of calling DoIo() or BeginIo() which then calls BeginIo(), message passing, task switching, etc would slow the system down too much. Or am I missing something and is the overhead manageable if we only do QUICKIO or something?
I think a library or a library masquerading as a resource is way leaner. A library function can be called directly without any overhead. But a resource needs to be loaded by some application while a library is automatically loaded from disk by the OS....
So I would think it needs to be a library or maybe a device.....

For such an SPI interface API to be useful, I think it should cover move than a "simple" SPI implementation such as yours (sorry ;-).
Won't this mean that it should support asynchronous transfer of larger buffers, which an exec device is perfect for (compared to a library) ?

[patrik]

@Niklas:

Could the spi.device itself handle the aquire/relinguish when appropriate? It should be the one who knows if there is a separate spi bus for each unit, or if it is shared, right?