Nice!

I thought that Mike got out of the biz of doing that and we were now just ordering direct from WDC...

Oh, and a gentle prod... Much knowlege about what NOT to do has been gleaned from your difficulties, which is great. But you might consider writing up a little more about exactly how you exhaustively tested your system for proper functioning.

You might consider making a Kestrel 1p4, where the only difference is that it decodes the top 8 bits of the address bus. But I will send you a spare 74HC573 or two that I ordered by accident..

Because?

Is there any real reason to when you're only moving data at most at 4MBps? Even plain-vanilla 7400 can keep up with that.

Right now, the Kestrel is limited in speed by the RAM; with only a 70ns access time, the CPU clock frequency is limited to somewhere in the vicinity of 7MHz or so. Most logic families now-a-days can easily cover those frequency ranges. Therefore, there really isn't any real need to use more exotic parts.

Also, when doing a search for 74ACH00 on Google, I didn't readily find a source for a 14-pin DIP component. 74AC00 and 74HC00 are both readily available in DIP form-factor.

Oh, that makes sense, now that WDC is no longer imposing a minimum order...



Well, my testing procedures weren't as methodical as I'd liked them to have been. No sooner than I declared the kit "done", another hardware bug resurfaced, under a different circumstance.



I think I have a few of those lying around here too. However, that will not be the 1-series. That will remain the domain of the 2- or 3-series, at most. The 1-series is intended expressly to be very simple to build (minimum parts count), code for, and just plain play around with and enjoy. It's a toy, pretty much.

The 2-series will build on the experiences gained with the 1-series, but will be optimized for a different purpose: expansion. I'm intending 128KB of RAM stock (since I just so happen to have 4 62256 chips lying around ), and the capacity for 7 expansion slots of some kind, each of which is bus master capable.

This is the conundrum that I'm having though: do I or do I not make PCBs for the Kestrel 1-series? While I've had people who offered to purchase a Kestrel 1, the fact is, to me, it's just a toy, and the Kestrel 2 is where all the really fun stuff is going to happen. With up to 7 expansion slots, which if my calculations are correct will be able to move 12 to 14MBps practically, a PCB is a much more practical expense to invest in. Right now, the Kestrel 1 is very limited in what it can do, because of the virtually non-existant address decoder. Is the Kestrel 1-series worth investing in a PCB design and production?

Makes sense. I read in a few places that AC logic can be pretty noisy though, due to the high slew rate.

Yeah, I've noticed that the rise and fall times are *steep*, and that there is a lot of initial ringing (sometimes as much as 5V!). However, it doesn't appear to be affecting anything.

Right now, it's still sitting on a solderless, pluggable breadboard, which means there is still a lot of stray capacitance. I suppose that if I go to printed circuit board or wirewrap, the capacitance will be significantly reduced, and the spikes I observe won't be nearly as prevalent. The other thing to do to eliminate these spikes is to terminate the signals with resistors to ground. As long as the resistance equals the signal impedance, that should eliminate the spikes pretty well (since the spikes are a manifestation of high SWR on the signal path, caused by impedance mismatches).

I really do want to rebuild the circuit in a more robust and reliable manner; I'm still playing with "pcb", the printed circuit board editor for Linux (part of the gEDA suite). It has a very steep learning curve, but seems fairly capable. I hate the UI it has though.

But as indicated earlier, I'm hesitant on doing something like this, because I want to move the Kestrel from "toy SBC" status to "viable, albeit slow, desktop computer." And even then, slow is relative -- I don't need an 800MHz AMD Athlon to read my e-mail, or do a search on Google, to read 6502.org, nor to chat on IRC with my friends.

> The other thing to do to eliminate these spikes is to terminate the
> signals with resistors to ground. As long as the resistance equals the
> signal impedance, that should eliminate the spikes pretty well (since
> the spikes are a manifestation of high SWR on the signal path, caused
> by impedance mismatches).

If you reduce the length of the transmission line to an insignificant part of a wavelength of the highest frequency components, characteristic impedance becomes irrelevant. It will be easier to build small and keep all the lines short than to control the characteristic impedances and contend with Y's in the nets and so on. This is one reason why I'm not in favor of taking the processor's own buses out on a backplane. On the next computer I make, I hope to keep these buses confined to an area about 2" square (using PLCCs if not PQFPs).

Ground bounce however comes from inductance in the power and ground pins and connections, not the signal lines. Having a real ground plane helps, although DIPs unfortunately usually have the power and ground leads on the corners instead of the middle pins, requiring longer connections there and making it hard to minimize the inductance. Some of the faster memories have them in the middle now, so the connection from the die to the power and ground planes is really short, especially with the .300"-wide DIPs or SMT parts.

The problem is the rise and fall times require frequency components so high that even a 3" long strip constitutes a quarter-wave radiator for them. That results in sharp, high-frequency spikes and oscillations on an otherwise near perfect square wave.

I forgot where I read it (I believe it was in QST magazine), but if you have a part that is capable of running at 100MHz, but you're only running it at 1MHz, you still need to use the design techniques for 100MHz construction, because of those sharp rise/fall times.



You're looking at more than two layers on the PCB then. I can't see any other way to keep the CPU's buses so short without using more layers.

That being said, though, I've been thinking about this for the Kestrel's expansion systems. Looking at all modern I/O architectures, it seems that a fully synchronous channel is used in all cases (even if an asynchronous handshake protocol is employed), and there is a trend towards narrower buses. For example, if I go fully synchronous at 16MHz, an 8-bit wide bus would transfer 16MBps peak, and have two asynchronous handshake signals, and maybe about four more lines for "bus command" (e.g., this is an address, this is data to be read, etc). That's a total of 14 lines of control, so you figure with additional grounding, you get about 20 lines to 24 lines. That's pretty tiny, for a bus that is as capable as that. And, the bus protocol is fully abstracted from the CPU, so the CPU can run at an independent clock-speed, and wait-states can be inserted as appropriate to ensure synchronization.

So, I'm currently researching affordable ways of making this a reality, even for us lowly hackers. PCI's protocol is actually pretty simple from what I've seen. When FRAME# is first asserted, the first 32-bit word is an address. All subsequent words transferred are data words. The C/BE# lines control which bytes to transfer, and other attributes (such as, reading-vs-writing, burst control, config-vs-I/O-vs-memory space, etc).

If there are special lines telling board hardware when to latch an address versus when to transfer data, it seems to be that we can get pretty decent data rates without a whole lot of weird and obtuse logic. The disadvantage is that there would be some duplication, and partial address decoding would be right out. But, if it results in a cheaper, more future-proof expansion system, I'm down with it.

I'm still researching this of course. What are your opinions regarding this? Thanks.

Hrmm...

Jameco has AHC parts in DIP packages. I tend to go through them because they are reasonably cheap and have a will-call desk that's 10 minutes from work.

My thoughts are that if you are going to sell a 1-series Kestrel, you should sell it as a kit, with the DIP parts, a breadboard, etc. No PCB, just the schematic and the confidence of knowing that if you RTFM you'll have a working, albeit limited, piece of hardware.

For I/O busses, I think the most important goal is that we need simplicity. If it can't be done in more than a few pieces of 74xx logic, it's probably better to just implement an existing bus in one way or another.

Other nifty ideas to make a "useful" computer would be to just implement a compliant PCI, ISA, PCMCIA, or SDIO IO bus.

I don't have such a convenience, and as I said earlier, a "quick" Google search yielded no DIP form-factors for AHC parts, while they were one fo the first things to come up for AC logic.



I do not believe that selling a breadboard will be a good idea for something like this. While the breadboard is the ultimate in hackability (can rip parts apart, rewire as needed, etc), it's also grotesquely unreliable. Wiring a breadboard with this kind of circuit takes a lot of skill -- note that even I had to rewire it once just to get things working.



What pre-defined bus is there, that doesn't require more than "a few" pieces of TTL logic? Implementing ISA bus on a 6502/65816 system requires quite a bit more than "a few" pieces of TTL. IDE is about as simple as things get -- but only because it has 3 address lines and no support for DMA in most non-Intel implementations, so you can pretty much get away with utter simplicity there.

But let's look at PCI. PCI is *very* simple. But, because it multiplexes address and data on the same set of lines, each and every card will need logic on board to trap the address as it comes in.

The simplest possible bus for the 65816 will be the CPU's native bus. There are a few problems with this though:

* Will Terbium have the same bus interface? We don't know. If not, can we coax it into emulating the 65816/6502's bus interface semantics?

* I make my Kestrel to run at 4MHz. You make yours to run at 8MHz. Will my expansion card work in yours? Remember that phase-2 mitigates literally everything that occurs on the bus, and is often used for synchronization between master and slave. Will the slave be able to handle 8MHz? How about 16MHz?

* Of course, we can decouple the core functionality of the expansion card from the bus clock. But we now run into the situation where the card runs at 4MHz, and the bus runs at 4MHz, but they may not be phase locked. OR, we have a card that runs at 12.6MHz and a bus that runs at 7MHz. How do you phase-lock the latter? You can't -- the end result will be unpredictable numbers of wait-states, even though the card is plenty fast enough to handle the bus transactions!



I never heard of SDIO bus, but the others I've heard of, and PCI holds the greatest promise. But PCI is also pretty "fast" too, requiring everything to occur with a 33MHz clock. PCI also requires weird bus driver support, because it actually uses signal reflections to its advantage instead of having to fight them all the time (if that isn't an aikido response to a problem, I don't know what is!).

Wishbone bus is the bus that I've been eye-balling, because it's so very close to the 6502 bus that it's just uncanny. But it has many elements of VMEbus and PCI in it too. The problem with Wishbone as-is is that it's a SoC bus, and 100% not applicable for buses external to the chip (in order to make it work, you need bi-directional bus transceivers that couple to the separate input and output buses, thus forming a "wishbone"-like thing on diagrams used to explain the concept. This is, in fact, where the bus got its name from!). However, again, we run into the problem of the synchronous clock -- will my card that is known to work in your 8MHz UberPuter? Will my 5MHz Kestrel prototype interface cleanly to the "standards-imposed" 16MHz hypothetical, synchronous I/O bus?

It is for this reason that I prefer fully asynchronous buses, and I have a circuit that wraps the 65816's bus and makes it asynchronous, with a few caveats. I was almost certainly going to employ that circuit. But, again, standards compliance will require that a card maker add some logic to their circuit to make things play nicely together.

Bus architecture design is not easy. Let me tell you.

Sure, but a 1ns rise time (which apparently the 74ASxx can achieve) does not mean there's necessarily much frequency content above 1GHz or even 400MHz (remember that one rise time is really less than half a sine-wave cycle); and a 3" line there is only around .09 wavelength. (I don't remember the exact phase propagation velocity of transmission lines on FR4.) Still, the phenomenon is why I recently said in another post that such fast rise and fall times are almost scarry, making me wonder if I could make a circuit that would be well behaved with these fast parts (74ASxx). The amateur radio materials (at least from around 1980 when I was active) seem to only use the Smith chart for antenna-related things; but you can use it for all kinds of RF calculations even when antennas are not (intentionally) involved. I find myself now having to be more careful in board lay-out in digital work and even with small switching power supplies than I was 25 years ago with my HF ham-band equipment construction where I seemingly got away with murder on things that topped out at 10 meters and were mostly for 40 and 80 meters.



That's not to say that the entire SBC must lie within such a small area, but rather just the processor's own buses. For the high-speed parts however, power and ground planes are essential. That doesn't necessarily mean you have to make multilayer boards, although that might not cost any more than using the expensive wire-wrapping board with a plane on each side plus plated-thru holes, and the PLCC WW sockets which are not only expensive but also take more room than PLCCs, or better yet, PQFPs, soldered right to the board without sockets. If you do get boards made, you could even put parts on both sides. (I've put DIPs on both sides before, but definitely not with WW!)

Multilayer boards were well out of the reach of hobbyists until recently, but I might try PCBexpress.com for one myself sometime.

See, my logic is this. A Kestrel 1 series, as is, isn't going to be too much more useful than Daryl's SBC. The board that would be quite useful is the Kestrel 2 series or beyond, with a proper IO bus and a 24 bit address space and whatnot.

So if you are going to sell a Kestrel 1 series at all, it should probably be an "instructional" kit. Or you can just put off selling it until the 2 series.



My point is.. there's two directions you can go.

One direction is to provide an easy "hobyist" way to do things. Either as a "few" pieces of 74xx logic, a "low speed" interface, a CPLD or FPGA provided by you, or a pre-populated protoboard, allow somebody to make arbitrary peripherals. Simplicity.

The other direction is to go the hardcore route, where people who don't pick through datasheets with a fine-toothed comb aren't going to be able to easily create new peripeherals. Where it really doesn't matter what you do, as long as it's stable and you are willing to provide at least kits for a reasonable set of peripherals.

"kc5tja"]

I never heard of SDIO bus, but the others I've heard of, and PCI holds the greatest promise. But PCI is also pretty "fast" too, requiring everything to occur with a 33MHz clock. PCI also requires weird bus driver support, because it actually uses signal reflections to its advantage instead of having to fight them all the time (if that isn't an aikido response to a problem, I don't know what is!).[/quote]

I left it at that because I wasn't going to have the time to look things up properly.

SDIO is part of the Secure Digital standard. Apparently the SD Association has finally realized that people hate paying for standards, so they are posting "simplified" versions of it. The SD interface is a 9-pin bus that you can either talk to it via SPI, a 1-bit mode or a 4-bit mode.

Now that I look at it, although it wouldn't be the best performance in all situations, you can have a pretty reasonable set of "hobyist" stuff hooked up to one or more SPI cards, because SDIO cards "must" talk SPI.

The part that I like about the MMC/SD/SDIO family of standards is that you have a workable low-speed, low-tollerance option to connect to a reasonable set of peripherals.... assuming you can write drivers for it. And it's asynchronous and can be clocked at any speed under 25 MHz. The only quirk is that it's a 3.3v standard.

But the theme is that you could always just do the 4-bit SD/SDIO bus as the way you do things.



Remember, my views are colored by what I think would be useful. What I have in mind as my personal project is very different from the Kestrel, the main things in common being that I want it to be useful and use the 65816.

But I think, for a high-speed bus, the direction you are going is pretty good. Of course, I'm not a bus designer, I'm just a crazy tinkerer.

One mental picture I had was to treat each side of the bus as an addressable bidirectional latch, with an 8 bit wide bus. Thus, you could have a pseudo-burst mode just by changing only the lowest word of the address latch and the data latch and still make it possible to do a peripheral without too much work. And the "I can't be bothered to think about timings" version of a peripheral would be a row of latches, a comparator for decoding, and a counter to make all accesses happen at 1 MHz.

One option for simplifying address decoding for the Kestrel user would be to put a little more logic onto the motherboard to do a small set of default decodings, say 8 blocks of 64k, that you could use a DIP switch to route to an extra pin on the peripheral port.

For all we know, the Terbium might be completely useless for our hacker purposes and what you really want to do is make something that hooks up to a 68k, an external memory bus LPC, or a FPGA-CPU.

The people who expressed interest in the Kestrel 1 wanted it to be in a finished form. They are not interested in building it themselves. I of course told them that wasn't going to happen until I got a sufficient number of orders. Which, predictably, hasn't happened.



I've looked at the SDIO standard (at least what I could find of it) briefly before screaming into work, and, . . . I don't really think that I would call it "simple." Yeah, the hardware seems simple (I still don't see how the hardware can automatically detect SPI, 1-bit, or 4-bit modes though), but then there's all sorts of other hidden gotchas in the standard. There are multiple address spaces you need to be aware of, and so forth. And the command list makes PCI's command list pale in comparison. That implies that the SDIO device would require local intelligence, which pretty much means I might as well just use something like an IEEE-488 bus or something.

My goal is to make a capable, future-proof, yet minimal bus system that people can readily hack without requiring post-doctorates to design even the simplest of parallel port interfaces. I do not want it tied to any one special interest group (try downloading the PCI 3.0 specs from the PCI SIG -- won't happen unless you are a member, paid in full). Ideally, the bus interface would be licensed LGPL.



To nitpick: anything that depends on a clock, regardless of its speed, is synchronous by definition. SDIO is quite synchronous in this nature. It just happens to be rather flexible in what speeds it runs at.

I did learn that PCI can run all the way down to 0Hz -- that is, it's perfectly legal to have a PCI slot that has a 4MHz clock! Of course, I'm willing to bet you that most PCI cards would croak if run that slowly, but still...

I do want an expansion bus that offers reasonable performance of course, but most importantly, that doesn't require much CPU intervention. That means, it must be capable of supporting multiple bus masters, able to read and write from/to memory as required.



I want a bus interface that can satisfy the needs of a large number of hackers. I don't want to spend all my time hacking and re-hacking the Kestrel to support something new that I or someone else wants to support.



This really doesn't make any sense to me. Can you elaborate a bit?



Yes, that was part of the original I/O bus concept (32K of I/O space, supporting 8 "slots" of 4K space each, but I'm probably going to shrink that down to 256 bytes each). Even so, I do want the ability to handle a greater address space than that (e.g., adding more RAM to the system -- potentially megabytes).



As we do know that the Tb will be a 65xx processor, I'd like it to at least design a new motherboard around the Tb without having to redesign all my expansion peripherals.

Ah, see, software doesn't faze me, but hardware does.

The standard is based on the MMC standard. So the "missing piece" is the SD standard, which they don't seem to have put a "simple" version that doesn't have DRM info that they don't want to talk about.

Maybe I should just say, "Hey, put a SPI bus on the Kestrel, even if you don't use it as the main bus." Because, as long as somebody writes a driver, you can hang AVR microcontrollers, MMC cards, SD cards, and SDIO peripherals off of it.

Or maybe I'm compensating for a decided lack of experience building electronics with my decided wealth of software building experience.



Hah! Yeah, I bungled that.



Make the bus best suited to the Kestrel and then make a PCI mezanine interface?



It could make no sense in general, for all I know. Remember, I software dude who dabbles in hardware. I connect power to ground and ground to power and let the magic smoke out.

So, we've got 8 bidirectional data lines. We have 3 bits on the side for the "latch address", the write transaction line, the read transaction line, the transaction complete line, plus whatever other extra signaling and contention lines are needed.

So the transaction goes as follows.

Write : Latches 0-3 are the address latches. So we set the "latch address" to 0, put the first byte on the latch and repeat until all 32 bits of the address are entered into the latch. We write the lower 8 bits of the address bus to latch 7. (latches 4,5,6 are left for future expansion). Then, once all 5 bytes are latched, signal that the transaction is complete on the write line. We can stream-ahead and wait until we've got another transaction pending, or we can just halt the processor until the device signals for transaction complete.

Burst write: We're only going up by one. So we only change the value in latch 0 and latch 7, then signal the write line again.

Read: We latch the address into latches 0-3, signal on the read line. Halt the processor until the transaction complete line kicks in and we can latch the read buffer.

Burst read: We only change the value in latch 0 and then signal the read line, synch as before.

So, at burst mode, you have 1 bye transfered every other clock cycle. Sure, you could have a transfer every cycle, but then you have to use a counter or an adder, not a latch. Latches are available in all kinds of fast low-voltage CMOS 74xx parts and counters aren't.

The highlight here is that the simple device without bus mastering is pretty simple. With 6 tri-state latches, a 3to8 decoder, and some misc logic, you have everything you need for a simple peripheral. (Yes, I'll call that a "few" pieces of 74xx logic. But then again, my definition of the words "Couple" and "Few" seem to match nobody's ) You end up with a local address bus, a local data bus, and a write and read strobe. Add some driver logic that just delays, by default, the transaction complete logic, everything down to 1 MHz, you have something that just about anybody who understands the basics of electronics and is lazy can do something with because all of the hard stuff is in whatever's driving the bus. And it's even not too hard to do a vaugely inefficent driver that always does all 4 address lines.

Mostly it's just a weird variant on your "bus command" thing. And for all I know, it's a really really dumb idea and I'll be forever known as He Who Can't Design A Bus Worth A Crap.



Make the protocol such that you have 8 "slots" of 4k up high in the address space (Assuming that you get the top 8 bits) and then dictate that if you want more than 4k, you hafta do the decoding yourself.



The problem is they could do a 65xx processor with a bus interface more suited to ASIC / embedded usages....

But, I was talking about the hardware. GPL and LGPL apply to hardware as well as software. gEDA (GPLed EDA tools) was used to develop RONJA (a free-space, point-to-point, optical, 10Mbps network link), which itself is GPLed hardware.



I've already considered using SPI for the serial interface, along with Garth's serial loop ideas (themselves derived from HP-IL), and I've also considered re-implementing the Commodore IEC bus too. Each has their merits.

SPI, though, only defines the physical layer information -- that is, you have an 8-bit shift register, with DI shifting data in, and concurrently, DO shifting data out. The data circulates through the register -- this is how T1 lines are handled in telephone switches and channel banks, for example.

I don't believe SPI defines any additional protocol information above that, do they?



This is always possible, of course. But that's a circular suggestion, because the whole point of my consternation is precisely that of deciding the bus best suited to the Kestrel.



What you're describing is actually called "page-mode" accesses, and is commonly used on DRAMs, where the row-address is strobed in once, and only the column-address changes between accesses. In this case, we can feed A23-A16 and A15-A8 in two write operations, and then A7-A0 is modified every other write or read cycle.

Of course, to fully support burst mode, a feedback signal could be used to indicate, "Yes, I support burst."

However, what you basically just described is exactly how PCI works (except that it assumes the address registers are full-on counters). PCI starts a bus transaction by asserting REQ#. When GNT# is asserted in response, the card is now the bus master, and can assert FRAME#. When FRAME# is asserted, the starting address is placed on AD0-AD31 (or AD63 if on a 64-bit implementation). All subsequent clock cycles are data transfer cycles, with the implicit assumption that the address increases by one unit (byte, word, dword, or qword, depending on the byte-enables and such) each clock cycle.



Unless you're considering three of those tri-state latches for use as storing the device's "base address register" (aka BAR), I don't see why you need 6. Three bytes are needed to hold the full 24-bit address bus. OK, 4 if you're going with a 32-bit bus. The data port needn't be implemented with a physical latch -- a bidirectional buffer is sufficient. So that's 5 chips. OK, I see where you're going.



Yeah, that'd require an 8-bit magnitude comparitor, like what Garth was suggesting in another thread.



As evidenced by the difficulty in wrapping an asynchronous bus interface around the 6502/65816 interface, I can already say with impunity that it's already far better suited for ASICs than for board-level design. I refer you to the Wishbone bus specification (see http://www.opencores.org/projects.cgi/w ... e/wishbone) to see just how similar that SoC bus is to the external, 65816/6502 bus interface. Unlike PCI, it's freely downloadable, viewable by anyone, and essentially public domain, except for the "oversight" of the specification by the opencores.org community.

Much of the following has been said before under other forum topics, but I'll repeat for newcomers.


> The standard is based on the MMC standard. So the "missing piece" is
> the SD standard, which they don't seem to have put a "simple" version
> that doesn't have DRM info that they don't want to talk about.

That's why an article in one of the electronics industry magazines last year said they suspect that MMC will gradually gain popularity on SD which uses the same connector. MMC is an open standard but SD is not. MMC has an SPI mode. None of the lines need to be bidirectional for interfacing to something like flash, so the voltage translation is really easy using a quad open-collector comparator IC like the LM339.


> Maybe I should just say, "Hey, put a SPI bus on the Kestrel, even if
> you don't use it as the main bus." Because, as long as somebody writes
> a driver, you can hang AVR microcontrollers, MMC cards, SD cards,
> and SDIO peripherals off of it.

SPI can be used for all kinds of things although it will be kind of slow for some bus uses, especially if you have to bit-bang it for lack of hardware. Even the bit-banging is easy though, and you could hang several SPI's on a single VIA. As long as you have connectors to interface a VIA to the outside world, SPI can be implemented without advance planning.


> So, at burst mode, you have 1 bye transfered every other clock cycle.
> Sure, you could have a transfer every cycle, but then you have to use
> a counter or an adder, not a latch. Latches are available in all kinds of
> fast low-voltage CMOS 74xx parts and counters aren't.

You can load a set of 74xx161's for the counters and have them increment automatically with each access. What you're describing sounds very much like a parallel extension bus I devised (PXbus) for my "next computer" which has been extremely slow in coming partly since upgrades on the old one have breathed new life into it. Since then I have mostly scrapped the PXbus idea for several reasons, including size, the quantity of hardware required and the need to have it simple enough to complete within my lifetime :P , and that in spite of how attractive it looks, I find that I have not really needed the PXbus in my scores of workbench-computer projects over the 13 years of use since it existed in its original version. One of the uses I originally thought I'd have for the PXbus was a huge EPROM and battery-backed SRAM array using one I/O bit to dictate whether to auto-increment or not; but that has become unnecessary now that you can get an MMC flash memory with hundreds of megabytes, which is a lot less work to interface with its only-7 connections (including power and ground). Lots of things can be connected to the same SPI at the same time, and there are thousands of peripheral ICs available today that are interfaced through the serial ports, mostly SPI and I²C, and to a lesser extent, 1-Wire. Microwire, BTW, is almost the same thing as SPI, and parts can often be mixed on the same interface.


> I don't believe SPI defines any additional protocol information above
> that, do they?

There are four modes (mode 0 through mode 3) but I think mode 3 is a lot more common than the others. The modes have to do with the clock polarities. It's quite simple though-- set the desired device's select line low and clock the serial data in and out (simultaneously). How you feed instructions, addresses, and data to the device, and what the output means, will depend on the device and will be in the data sheet.