Join us on Discord: discord.gg/jmf6M3z7XS Follow me on Twitter: twitter.com/WeirdBoyJim Support the channel on Patreon: www.patreon.com/JamesSharman

If you came here to comment that I popped the registers in the wrong order (thereby swapping “b” and “d” rather than preserving them) well done. I didn’t spot that until previewing the final video.

I would very much enjoy seeing a full SPI implementation.

I would love to see a full SPI implementation! I had a go at designing one a couple of years ago, using parallel to serial (and vice versa) shift registers, but never had the time to finish it. Would love to see how you implement one!

I would love to see a full implementation! And then hooking the cpu up to a variety of " Arduino " sensors ? distance, proximity, temp and moisture etc etc.

Last year I had a lot of fun learning SPI using my 6502 sbc and the MAX3100 serial IC. It wasn't nearly as complicated as I thought it would be. Great video, sir!

The SPI implementation used inside the atmega328p is described pretty well in the datasheet, and I've often thought about trying to design a ttl implementation of it...

ISO date format ftw! YYYY-MM-DD all the way!

Neat. SPI will open up a world of interesting peripherals. If you want to go even faster, implement a QSPI interface and you'll get a full byte in only two clock cycles. 🙂

I like the idea of a hybrid implementation as well. I have designed SPI blocks for instantiation in FPGAs and those are simple. I have also used the RP2040s PIO blocks to implement modified SPI and the protocol is highly amenable to implementation with just a handful of simple commands, so I think the SW/HW hybrid solution would be interesting to see.

You have the best sounding keyboard I have ever heard. 😮

A hybrid approach would probably be the most fun and rewarding. While throwing a bunch of silicon at the problem has its allure, it would reduce the flexibility that software gives, while doing it all in software will be slow and tedious. So a mixed approach is what I would favor.

FWIW, you've inspired me - not just this video but the series. I always fancied Forth, wrote interpreter/compilers as a teenager on C64/6510 and then 68k on Amigas. At least on paper, I'm going to tinker with a simple Stack based CPU. Sure - its been done before, but the mental exercise of drilling down to microcode/metal level with potential for implementation on 74 series chips is irresistible - kind of like learning to code in the early 1980s. Heading back to the infinite rabbit hole of computing :) Great series - many thanks for sharing your progress.

Well done again :-) I would prefer to see the full hardware SPI implementation.

Absolutely make a full SPI hardware block!

Being honest, I'd like to see a full implementation of SPI if just because I want to see the process of designing and implementing a peripheral like that.

I've always wondered what SPI mode actually referred to. Now I know - thanks James!

A partial implementation would be neat, but it'd bug me that it'd be incomplete. What I'm more interested in is the variety of SPI devices out there. IIRC SD cards do SPI but there's also SPI to Ethernet adapters. you'd still need to do a lot more to get online but the possibility is cool enough.

A common technique I've seen in microcontrollers is to (ab)use the spi peripheral to achieve certian I/O tasks faster than they can be done on the gpio. Maybe an I/O peripheral that could be leveraged to do things like SPI and something else like I2c would be useful. Or maybe that would be scope creep. :)

Nice work, great video as usual, I'm inspired to go interface some slave devices on the bench.

If you have a spare peripheral line on hand you can build a 4MHz hardware SPI with 4 ICs, just use the good old 74HC165 for MOSI and 74HC595 for MISO and some basic logic ports.

I would love to see a hardware implementation!

i love artificial limits like making sure chip count stays low :)

In the software version a single routine which does a swap will work for either a read or a write. That would take a few more cycles when just a reading or writing but would save some code. (When reading it doesn't matter what ends up going out on MOSI.) I always enjoy the puzzle of doing a minimal hardware acceleration of some software.

Awesome video - thank you!

Hi James! Great Flic! Yes, go for a minimal chip and max speed approach in hardware. Curious to see how you can implement thatbwithpit Interrupts.

17:37 ISO-8601 FTW!!!

I wish what you said about date order wasn't controversial... I fully agree, today is either 14/12/2023 or 2023-12-14 (I'm used to dashes for the "correct" order). Any other order is just weird and illogical! (the rest of the video is also interesting :) ) I think some simple hardware help would be interesting and useful. Having things go faster than pure software bitbanging should expand the possibilities a lot and change the way you use things. I think even for the RTC, I suspect if you wanted to show a timer on screen now (say a game level elapsed time thing) you'd use some sort of VGA frame counter or something like that and you wouldn't waste hundreds of cycles to read the RTC just for that, but if that gets reduced to say a dozen or two cycles the option will be there.

Regarding sensibly sorted date formats: ISO 8601 takes care of this, and uses - as a separator Current time: 2023-12-29T17:50+01:00

James your amazing! Software SPI protocal in half a day in assembly 😮 I would love to see you build a full hardware SPI set up and see what speeds you could get. Would you create a buffer for in/out?

And where were you when I was fumbling around trying to learn SPI? 😅😂 Awesome vid as always. 😊

Thoroughly enjoyed this, thanks 🙂

I think it would be interesting to have the unrolled loop in hardware. This may have little/no effect on the overall transfer speed (assuming the spi is using the same clock) but might free up the cpu to do something else while it waits for an entire byte to be available. Not a very efficient way to do things here, but a good opportunity to demonstrate async i/o maybe?

Hi! I have watched most of the videos on your channel and I really enjoyed the progression! It’s actually inspired me to start my own homebrew “modern retro computer”…. One thing that I didn’t see and I was curious about is how big is the full build at this point…. It seems like the size of about “3 hands wide😅” but I’m curious to see how big it actually is…

Most interesting application for high speed SPI for me is graphics. I would love to see the machine to show animated video on an off the shelf spi tft display. If this would work with your simple approach, I would cheer for it. But if the simple approach cannot deliver the needed SPI mode or if varying bit widths are needed (some sensors have 12 or 14bit spi, if I recall correctly) I would like to see the full blown version. In other words if the SPI is just a proof of concept it's no good, but it does not have to support every mode that theoretically exist but no device really relies on

I would be very interested in seeing a full SPI hardware build. Did a reduced version recently for an 80s style electronics clock. :)

I would love to see a full SPI implementation, maybe interfacing more RAM, a flash device, things like that.

I’m curious about the DS1391 time accuracy because of its’ external crystal. I used DS1307 (ext crystal, I2C) for my watch project and it drifted like half an hour per month. After switching to DS3231 with integrated crystal and temperature correction it now drifts just few seconds per month. Maybe it would be worth it to switch to SPI based DS3234? Maybe it’s overkill though, but I can imagine in some more permanent exhibitions/installations it would make sense 🙂 and it also has an 256 byte battery backed SRAM, could be used for some experiments.

Funny to see your homebrew system with hardware UART and software SPI vs my homebrew system with hardware SPI and (potential) software UART

As we're using console accessories, a PS1(2) Memory Card would be fun, it uses SPI with a couple of quirks.

yes please do a full SPI circuit.

Personally I would go for a partial implementation. I'm doing professional development of embedded software for typical automotive and mainstream ARM controllers for nearly 30 Years now and the "full" implementations of many of these controllers are very limited, especially when it comes to word lengths and bitrate settings. So as soon as you have some hardware that e. g. requires 24bit or 32bit transfers (a collegue of mine currently is fighting with an ADC requiring these) you may have to turn of all the nice automatic features and fire the data by software. It's not bitbanging but still you will have a higher CPU load. And exactly this is the level I would implement: Clock out the data of let's say an 8 bit word automatically, perhaps add another byte as buffer and do the rest by code.

Nice to check the OSF flag before a reading the time or date, so you have an indication whether you can trust the data. Oscillator Stop Flag (OSF). A logic 1 in this bit indicates that the oscillator has stopped or was stopped for some time and may be used to judge the validity of the clock and calendar data.

I'd like to see either implementation! start w/easy one first, and assess from there if full is needed still.

Am I right in thinking the SPI protocol allows for accessing SD cards?

To me, I'd love to see octalSPI or QuadSPI. Probably too much for 8-bit computers, but easy to do with bit-banging. Good job !

Uff, this is a complex situation, for one part we want something simple, but for the other part we want something that fullfill all of owr spectations.

Wow. I have researching SPI and bit banging. Coincidence

Also would loke to see a full SPI implementation. Curious to know: are you going to make an implemtation that allows to promatically switch between the differerent SPI modes (0-3), or are you just going to swop out wires if you encounter an SPI device that needs a different SPI mode?

SNEScon is just a pair of shift registers, and those do play nice with SPI. Enough so that a shift register and a few logic gates are all you need for an SPI bus controller.

If you were willing to accept a small compromise of streaming in blocks of 256 bytes at a time, you could load data at 4mhz directly to RAM using a few chips: A shift-in parallel out connected to the SPI sub (I'll assume flash memory here) An 8 bit counter with bit 3 used to latch the data in the above register to its output, and reset this counter An 8 bit counter with its outputs on the low 8 bits of the data bus (of course you could use 2 of these, to allow loading up to 64k blocks) This would require some way to disconnect the CPU from the data and address bus during the transfer - the old ZX81 (I believe) used resistors so that the data bus could be overridden on the CPU side of the resistors to the NOP instruction whilst drawing the screen. So the set up would use a normal SPI write to set the read address from the SPI flash chip, then using one of the unused bits of the GPIO output to initiate the DMA transfer, with some sequence like: 1. Set a latch to force NOPs on the data bus of the CPU 2. Force the high 8 bits of the address bus to a fixed value 3. Reset the two counters. Then each clock would read a bit from the SPI flash into the shit-in register, and after 8 clocks the first counter would latch the output into RAM, and reset itself (which would also reset the latch) then via a slight delay circuit, increment the memory address counter register. This would continue until the overflow of the address counter register, which could signal the end of the transfer and release the forced NOP from the CPU, allowing it to continue. Of course you could reuse most of that to also stream data out if you wanted, but I guess that's not really needed so much for games! The bus arbitration would be a couple of parts, but I guess this all depends on if you want to load in 256 bytes in under 1/2 a millisecond :) Obviously this is at 4mhz - I cant remember if you use a clock divider on your main crystal, but obviously this could run as fast as the SPI flash/RAM can handle the transfers.

Yeah in the UK we do dates backwards which is better than some places, where they do them inside-out. ;)

You will also need to accommodate clock speed setup since different devices can operate in different clocks, probably a register/counter/comparator schema, I guess that is what going to consume more logic.

If I was you, I would not go for the last bit of every integration now, just what you need for the moment, with room for improvement. But that's me only.

What you should watch out for, is that interfacing with a full hardware implementation of SPI could end up being as much code as interfacing with a partial implementation.

This type of data transmission is so easy to bit bang, this goes of any form of well documented data transfer, I much prefer this than RS232. Reading RS232 where you can have no idea of how many characters are coming , whether they will end with CR/LF or LF/CR. even down to if the sending Baud rate is the same as your receiving rate even when they are set the same. Can't beat a nice preamble to lock your clocks. 🙂

I would like to see a hardware implementation instead of bit banging. The reason is that I created a spi slave in VHDL but haven't seen a logic components version

The date is the 'correct' way around here in Australia. Why is it upside down though?

Full SPI or a hybrid optimised for speed? Hmmmm... If You're not going to use SPI for a lot of different purposes, the latter of Your suggestions might be the most interesting one. I guess that I'll be leaning towards that one too :-)

How much would it take to implement it fully in electronics instead of software? How much faster would it be? I know it's implemented in hardware in the ATMega8 (as well as I2C), which makes it piece of cake to interface small OLED screens (including color ones in 16 bits), and such thing is not really possible at 70K per second... Meanwhile (IIRC), an ATMega8 on an Arduino at 16MHz "limits" the bandwidth to 4MHz (f(osc)/4) as a slave, which would be more like 300KB/s (including protocol bits), which lets it do something else (such as reading the clock it displays, or reading the MPU6050 and calculate the display lines for a compass while sending orders to servo motors, read the position of the paddle to set the desired roll/yaw/pitch, etc.).

I am using SPI for years now and never bothered to _really_ understand it.. very comprehensive, thanks .. (If I had to use your Keyboard on my PC it would drive me crazy in milliseconds.. 😅🙈)

What about using the INTEL 8251 for SPI

with SPI in, ENC80J60 says hello

SPI? Mentioning moving towards a storage solution? I'm guessing SD cards. Could be a flash chip with SPI too but that seems less useful.

How about putting the SPI hardware in to a PAL and do SPI to parallel transfers. kind of fitting with the era of the design.

Does the cryatal not need capacitors?

Can't SD cards also be read via SPI? At least in MMC compatibility mode! It probably only takes a few shift registers to convert from SPI to 8 bits in parallel.

Do a full SPI!

17:27 - I don't see how it's annoying to call out how ISO 8601 is a thing. ;)

I was actually disappointed you used bit banging. So yes please build a full spi peripheral. It's true you could load your memory in a second with bit banging. But.... The full system will have many peripherals it needs to control, not just the load. You need to monitor the gamepad, make sound, write graphics. All that will take CPU cycles. So 70kb per second is rather optimistic in a real scenario. Also if you are going to talk to an SD card or something, there is far more protocol overhead. So the number of actually transferred bytes will increase. Like the VGA having spirits to offload drawing, you might want to give the full spi hardware a buffer, so if you're busy doing something else transfers keep going and you can catch up later.

should add scsi to the computer for data storage

Hardware SPI!

Master Out Slave In, Master In Slave Out. There is some stupid notion that people will be offended by mere existence of certain words, so we should change established nomenclature just to make those hypothetical individuals "safe". The problem is not in the nomenclature, but in the people who elect to get offended by anything and everything. I don't understand this trend at all.

"Other geographies do it differently". No, one geography does it wrong - let's not beat around the bush.

In Europa the order is day/month/year. In China year/month/day. In the US the order makes no sense: month/day/year

Wiki changing Master/Slave to Main/Sub is very much intentional.

The Master/Slave designations are being ruled out because of the Snowflake Generations!

Too crappy keyboard

Get a haircut