Expansion bus

From OpenCircuits
Jump to navigation Jump to search


Expansion buses are designed to allow people to mix-and-match peripheral devices and CPUs.


History

The earliest expansion buses were more-or-less directly connected to the pins of a CPU.

Some early systems had a unified "system bus" that both memory cards and peripherals plugged into, leading to "memory-mapped I/O". Typically a "system bus" is composed of the address bus, the data bus, and the control bus, and often also includes multiple pins dedicated to ground and power rails.

S-100

The highly influential expansion bus of the MITS Altair 8800 was apparently an afterthought; all the parts required to make a complete computer system would not be designed in time for the January 1975 launch date, so the second prototype put most of the parts on removable cards intended to plug into sockets on a backplane, so only the backplane and a few cards needed to be done by the January 1975 publishing deadline, and the remaining cards could be put off until later.

The original S-100 bus was designed to more-or-less directly connect to the pins of the Intel 8080. Unassigned lines of the original bus specification were later assigned to support other processors, including the 68000, the Zilog Z-8000, the 80286, etc. The Zilog Z80 was perhaps the most common "main CPU" in S-100 systems, even in systems with multiple processors (Z80/68030 or Z80/80286 or etc.).

That first expansion bus was later named the S-100 bus and standardized as IEEE 696-1983.

In retrospect the general idea of such a "modular system" with easily plugged-in parts turned out to have many other advantages

  • ...
  • reduces the temptation of "creeping featuritis", since more stuff can be added later
  • [FIXME]
  • easy repairability -- the ease of swapping out faulty cards is obvious, but less obvious is the various ways it makes it easier to figure out *which* cards are faulty.
  • "hackability" -- just one card can be quickly replaced with a different version, without requiring the entire system to be completely rebuilt from scratch.
  • ...
  • ...
  • etc.

Also in retrospect, many people (with the advantage of hindsight) have figured out many ways of improving on the S-100 bus.

video game cartridge

Gerald Anderson "Jerry" Lawson is known as the "father of the video game cartridge". That original video game cartridge on the market in 1976 (like many later video game cartridges) plugged into a socket that was directly wired to the CPU system bus.


[FIXME: link to a few of the more popular homebrew cartridge groups; delete redundant information here when it's easy to find there.]

  • "Pinout of 60-pin Famicom consoles and cartridges" and "Pinout of 72-pin NES consoles and cartridges" on the "Nesdev Wiki: Cartridge connector"; another copy at "Famicom Cartridge Pinout" apparently has a pin pitch of exactly 2.5 mm (different from the 0.1 inch == 2.54 mm pitch of many other connectors). The Famicon Cartridge and the NES Cartridge each have two separate and independent address/data/control buses typically connected to two separate chips in the cartridge: one 8-bit data CPU_D0..CPU_D7 and 15-bit address CPU_A0..CPU_A14 for game code connected to the CPU, and 8-bit data PPU_D0..PPU_D7 and 14-bit address PPU_A0..PPU_A13 another for graphical data connected to Picture Processing Unit (PPU).
  • "Nintendo 64 Game Pak" has a 16-wire multiplexed bus (AD0 ... AD15) where the other control lines indicate when an address is on the bus and when it's time for data on the bus. "The Nintendo 64 was the first Nintendo console to employ nonvolatile chips for saving game progress, alleviating the need for a battery to maintain the data, and avoiding the problem of dead batteries leading to lost saves" -- "Nonvolatile Nintendo 64 Controller Pak" and pinout. "Nintendo 64 Hardware Exposed" has pinouts for the N64 Controller Pak NUS-004 (32 KB memory card), N64 Transfer Pak NUS-019, etc.

In addition to data (executable code, graphic sprites, sound data, etc.) some game packs included a variety of experimental electronic hardware: the sunlight sensor in the 2003 GBA game "Boktai: The Sun Is in Your Hand!"; the rumble motor in several GBC games including "Pokemon Pinball"; etc.

  • "Game Boy Advance Architecture" by Rodrigo Copetti has detailed information about the Game Boy Advance (GBA), focusing on its ARM7TDMI CPU (the GBA also has a Sharp SM83 CPU, which is used to run Game Boy (DMG) and Game Boy Color (CGB) cartridges). According to "Connector Pinouts" at the Console Mods wiki, the GBA cartridge pinout has multiplexed 16-bit data and 24-bit addresses AD0..AD15 and A16..A23.

Confusingly, all game cartridges Nintendo made (NES, ... GBA) are all called "Game Paks", even though each one is compatible only with the specific game console it was designed for.

The RetroSix wiki has detailed repair information, including cartridge pinouts, for many classic no-longer-in-production game consoles and personal computers.

The Nesdev Wiki has a bunch of resources specifically for NES hardware and software development; and the NesDev discussion forum has discussions on hardware/software development.

The SNESdev Wiki has a bunch of resources specifically for SNES hardware and software development. (including 65c816 guides), and the r/snes on Reddit and NesDev discussion forum occasionally has discussions on SNES hardware repair and hardware/software development.

The Super Nintendo Development Wiki, aka the SNES Development wiki, aka the SFC Developement wiki, has lots of detailed technical information about the SNES hardware and (65c816 assembly language and SNES banking) game development.

The ObscureDev Wiki has detailed technical information on some historic game consoles, including the influential original 1980 "Pac-Man" stand-up arcade video game using the Zilog Z80A CPU.

The ConsoleMods wiki has detailed information on console modifications, repairs, and restoration for many classic no-longer-manufactured game consoles.

The Natalie The Nerd Wiki has extremely detailed information (some in KiCad format) on motherboard and cartridge PCBs in the original Game Boy (DMG), Game Boy Pocket (MGB), Game Boy Micro, Game Cube, etc. very useful for troubleshooting and repair.


[FIXME: mention OpenSFC, an Open Source Hardware (OSHW) project]

expansion bus as separate from system bus

Later systems generally separate high-speed stuff (the CPU, the RAM, on-board video (if any), graphics card slot (if any), and coprocessors (if any)) (the "Front-side bus") from slower speed stuff (expansion bus slots, off-board cables and ports).

There are two different reasons for this separation: In low-cost microcontrollers, the cost of pins is a significant cost of the whole system, so (a) we can use a much lower-cost packaging (far fewer pins) if we don't expose the address bus or data bus outside the chip (by putting all of the program Flash and data RAM on the same chip as the CPU) (b) using a "narrower" bus to communicate with peripherals also saves a bunch of pins in those peripherals, making them cost less. In high-end systems, the CPU, video, and RAM run much faster than peripherals, so separating the busses allows the CPU to do dozens or hundreds of memory cycles while waiting for a peripheral to handle a single expansion bus cycle.

qwiic

SparkFun's Qwiic Connect System uses 4-pin JST connectors. It's based on the I2C bus.

grove

Seeed Studio's Grove system has standardized 2 mm pitch 4-pin connectors.<ref> "What type of connector does the GROVE system use?". </ref>

"Seeed Studio Wiki: Grove Ecosystem Introduction"


Grove was originally developed by Seeed, and adopted by many brands and hardware designers, including M5Stack. Grove cables have the following pinout (depending on the module, I2C, Analogue, UART, or Digital):<ref> https://thepihut.com/collections/grove-cables </ref>

  1. Pin 1 - Yellow (SCL/Dn/An/RX)
  2. Pin 2 - White (SDA/Dn+1/An+1/TX)
  3. Pin 3 - Red - VCC on all Grove Connectors
  4. Pin 4 - Black - GND on all Grove Connectors


UEXT

Universal EXTension (UEXT) is a connector layout which includes power and three serial buses: UART, I2C, and SPI separately over 10 pins in a 2x5 layout.

Wikipedia: UEXT

BlackNet

Inspired by the 1-wire bus, the BlackNet serial network is an example of an expansion bus with the very modern assumption that microcontrollers are so cheap that we can afford to put one or more on each and every device that plugs into the bus.

RC2014 bus

"RC2014 is a simple 8 bit Z80 based modular computer. It was designed to be simple. Simple to build, simple to understand, and simple to program."

Backbone Bus

Backbone is a proposal for a backplane interconnect that supports multiple bus masters.<ref> "Backbone Bus". </ref> Samuel A. Falvo II

STEbus

PC104

The PC/104 standards defines both form factors and computer buses allowing consumers to stack together boards from a variety of manufacturers to produce a customized embedded system.

PC/104 boards are stacked on top of each other like LEGOs, unlike nearly all other expansion buses.

The original PC/104 connectors are electrically the same signals as the IBM PC/AT but with a different, stacking connector.

PATA

Parallel ATA (PATA) is also electrically the same signals as the IBM PC/AT, but with a different physical hardware -- PATA uses ribbon-cables and square header pins.

CAN bus

The CAN bus ...

RS485

... other articles that discuss RS485 include RS232 and RS232 RS485 USB Converter Board ...


GPIB

The GPIB bus ...


STD-80 bus

The "STD-80" bus, sometimes called called the "STD Bus", is named after the Zilog Z80 it was designed around, and not after it's 56-pin card edge connector.


80-bus

The 80-bus https://80bus.co.uk.mirror.jloh.de/pages/welcome.htm https://nascom.wordpress.com/the-magazines-2/80-bus-news/ also called the NASBUS https://nascom.wordpress.com/nascom/hardware/nasbus/ https://80bus.co.uk.mirror.jloh.de/pages/nascom/nasbus.htm is a 77-pin card-edge expansion bus designed around the Zilog Z80, carrying power (of several voltages), ground, 8 data lines, 16 address lines, and various other control lines.

"xbeaver" is a 80bus (nascom, gemini and others) emulator. Another "Nascom / Gemini / 80-BUS Emulator" is at https://github.com/codesqueak/Nascom . Another Nascom emulator is at http://www.nascomhomepage.com/#VirtualNascom .

Unibus

Unibus used with some PDP-11 and VAX systems ... 72-pin edge connectors (56 lines plus power and ground lines) ...

Expansion bus design considerations

  • latency (often *more* important than bandwidth)
  • How far apart are the ends of the bus (length)?
  • How many data bits to transfer per transaction (data bus width)?
  • how many address bits to transfer per transaction (address bus width)?
  • Dedicated 1 wire line for each address bit and and separate wire for each data bit (easier to test)? Or somehow multiplex 2 or more of those signals (lower cost)?
  • How many peripheral devices can be plugged into the bus at the same time?
  • How many controllers can be plugged into the bus at the same time? (A single controller and everything else are peripherals? Or multi-controller?)
  • Can 2 identical peripherals be plugged into the bus at the same time, and how can software distinguish them?
  • hot-pluggable?
  • fault-tolerant?
  • EMI/EMC
  • Fixed, dedicated, unshared interrupt lines from each peripheral to the CPU? Or daisy-chained interrupt line?
  • Fixed maximum number of peripherals per bus? Or daisy-chaining an arbitrary number of peripherals?
  • What's the maximum fanout of the devices that drive the bus? Early TTL-based systems used chips with a typical max fanout of around 5, so "clever" techniques were required to support more than 5 peripherals. Modern high-speed systems often use point-to-point links (fanout of 1) for speed.
  • Backplane? Motherboard? Stacking connectors? Ribbon cables? Something else?
  • Off-the-shelf connectors available from second sources?
  • Rugged connectors that are reliable for hundreds of plug/unplug cycles?
  • stripboard/Veroboard with 0.1″ header sockets?
  • bandwidth

For many years, the bandwidth (the number of bits we can shove across the bus per second) seemed to be so important that we sacrificed many things to increase the bandwidth. But surprisingly often, new systems are specifically designed for *lower* bandwidth in order to regain some of the things that were sacrificed.


Related

Retrieved from "http://www.opencircuits.com/index.php?title=Expansion_bus&oldid=93645"