Civil Rights
Movements, leaders, victories and the continuing fight for equality.
Explore the people, places, events, achievements, struggles and stories that shaped our journey.
Movements, leaders, victories and the continuing fight for equality.
Innovation, patents, science, technology and world-changing contributions.
Pioneers, champions, Negro Leagues, records, activism and excellence.
Meet the people whose lives, choices and achievements shaped the journey.
Black towns, communities, institutions and places where history happened.
Moments that changed communities, movements, institutions and the nation.
In August 1908, a white mob attacked Springfield, Illinois’s Black community, destroying homes and businesses and lynching two Black men. National outrage over the violence helped spur the movement that created the NAACP the following year.
MORE →Reflects the personal views, recollections, and perspective of the author, Mike Davis.
This is a personal recollection on the Move fire on May 13, 1985
This article includes a list of general references but lacks sufficient corresponding inline citations. (April 2009) |

VMEbus (VERSAmodule Eurocard bus[1] bus) is a computer bus standard physically based on Eurocard sizes.
In 1979, during development of the Motorola 68000 CPU, one of their engineers, Jack Kister, decided to set about creating a standardized bus system for 68000-based systems.[2] The Motorola team brainstormed for days to select the name VERSAbus. VERSAbus cards were large, 370 by 230 mm (14+1⁄2 by 9+1⁄4 in), and used edge connectors.[1] Only a few products adopted it, including the IBM System 9000 instrument controller and the Automatix robot and machine vision systems.

Kister was later joined by John Black, who refined the specifications and created the VERSAmodule product concept. A young engineer working for Black, Julie Keahey designed the first VERSAmodule card, the VERSAbus Adaptor Module, used to run existing cards on the new VERSAbus. Sven Rau and Max Loesel of Motorola-Europe added a mechanical specification to the system, basing it on the Eurocard standard that was then late in the standardization process. The result was first known as VERSAbus-E but was later renamed to VMEbus, for VERSAmodule Eurocard bus (although some refer to it as Versa Module Europe or Versa Module European).[1]
At this point, a number of other companies involved in the 68000's ecosystem agreed to use the standard, including Signetics, Philips, Thomson, and Mostek. Soon it was officially standardized by the IEC as the IEC 821 VMEbus and by ANSI and IEEE as ANSI/IEEE 1014-1987.
The original standard described a bus with up to 16-bit width, designed to fit within the existing Eurocard DIN connectors and which has a maximum transfer bandwidth of 40 MB/s.[3] However, there have been several updates to the system to allow wider bus widths. The current VME64 supports up to 64-bit bus width in 6U-sized cards and 32-bit in 3U cards. Doubling the bus width also doubles the maximum transfer bandwidth of VME64 to 80 MB/s.[4] Other associated standards have added hot-swapping (plug-and-play) and doubling bandwidth in VME64x[5], smaller 'IP' cards that plug into a single VMEbus card, and various interconnect standards for linking VME systems together.
In the late 1990s, synchronous protocols proved to be favourable. The research project was called VME320. The VITA Standards Organization called for a new standard for unmodified VME32/64 backplanes.[6] The new 2eSST protocol was approved in ANSI/VITA 1.5 in 1999.
Over the years, many extensions have been added to the VME interface, providing 'sideband' channels of communication in parallel to VME itself. Some examples are IP Module, RACEway Interlink, SCSA, Gigabit Ethernet on VME64x Backplanes, PCI Express, RapidIO, StarFabric and InfiniBand.
VMEbus was also used to develop closely related standards, VXIbus and VPX. The VMEbus had a strong influence on many later computer buses such as STEbus.
The architectural concepts of the VMEbus are based on VERSAbus, developed in the late 1970s by Motorola. This was later renamed "VME", short for VERSAmodule Eurocard, by Lyman (Lym) Hevle, then a VP with the Motorola Microsystems Operation.[1][7] Lyman was later in 1982 the founder of the VMEbus Marketing Group, itself subsequently renamed to VMEbus International Trade Association in 1984/1985[8][9], since shortened to VITA in 2005[8][10].
John Black of Motorola, Craig MacKenna of Mostek and Cecil Kaplinsky of Signetics developed the first draft of the VMEbus specification. In October 1981, at the System '81 trade show in Munich, West Germany, Motorola, Mostek, Signetics/Philips, and Thomson CSF announced their joint support of the VMEbus. They also placed Revision A of the specification in the public domain.
In 1985, Aitech developed, under contract for US Army TACOM, the first conduction-cooled 6U VMEbus board. Although electrically providing a compliant VMEbus protocol interface, mechanically, this board was not interchangeable for use in air-cooled lab VMEbus development chassis.
In late 1987, a technical committee was formed under VITA under the direction of IEEE to create the first military, conduction-cooled 6U × 160 mm, fully electrically and mechanically compatible, VMEbus board co-chaired by Dale Young (DY4 Systems) and Doug Patterson (Plessey Microsystems, then Radstone Technology). ANSI/IEEE-1101.2-1992 was later ratified and released in 1992 and remains in place as the conduction-cooled, international standard for all 6U VMEbus products.
In 1989, John Peters of Performance Technologies Inc. developed the initial concept of VME64: multiplexing address and data lines (A64/D64) on the VMEbus. The concept was demonstrated the same year and placed in the VITA Technical Committee in 1990 as a performance enhancement to the VMEbus specification.
In 1993, new activities began on the base-VME architecture, involving the implementation of high-speed serial and parallel sub-buses for use as I/O interconnections and data mover subsystems. These architectures can be used as message switches, routers and small multiprocessor parallel architectures.
VITA's application for recognition as an accredited standards developer organization of ANSI was granted in June 1993. Numerous other documents ( including mezzanine, P2 and serial bus standards) have been placed with VITA as the Public Domain Administrator of these technologies.
| Topology | Year | Bus cycle | Maximum speed (MB/s) |
|---|---|---|---|
| VMEbus32 Parallel Bus Rev. A | 1981 | BLT | 40 |
| VMEbus IEEE-1014 | 1987 | BLT | 40 |
| VME64 | 1994 | MBLT | 80 |
| VME64x | 1997 | 2eVME | 160 |
| VME320 | 1997 | 2eSST | 320 |
In many ways the VMEbus is equivalent or analogous to the pins of the 68000 run out onto a backplane.
However, one of the key features of the 68000 is a flat 32-bit memory model, free of memory segmentation and other "anti-features". The result is that, while VME is very 68000-like, the 68000 is generic enough to make this not an issue in most cases.
Like the 68000, VME uses separate 32-bit data and address buses. The 68000 address bus is actually 24-bit and the data bus 16-bit (although it is 32/32 internally) but the designers were already looking towards a full 32-bit implementation.
In order to allow both bus widths, VME uses two different Eurocard connectors, P1 and P2. P1 contains three rows of 32 pins each, implementing the first 24 address bits, 16 data bits and all of the control signals. P2 contains one more row, which includes the remaining 8 address bits and 16 data bits.
A block transfer protocol allows several bus transfers to occur with a single address cycle. In block transfer mode, the first transfer includes an address cycle and subsequent transfers require only data cycles. The slave is responsible for ensuring that these transfers use successive addresses.
Bus masters can release the bus in two ways. With Release When Done (RWD), the master releases the bus when it completes a transfer and must re-arbitrate for the bus before every subsequent transfer. With Release On Request (ROR), the master retains the bus by continuing to assert BBSY* between transfers. ROR allows the master to retain control over the bus until a Bus Clear (BCLR*) is asserted by another master that wishes to arbitrate for the bus. Thus a master that generates bursts of traffic can optimize its performance by arbitrating for the bus on only the first transfer of each burst. This decrease in transfer latency comes at the cost of somewhat higher transfer latency for other masters.
Address modifiers are used to divide the VME bus address space into several distinct sub-spaces. The address modifier is a 6 bit wide set of signals on the backplane. Address modifiers specify the number of significant address bits, the privilege mode (to allow processors to distinguish between bus accesses by user-level or system-level software), and whether or not the transfer is a block transfer. Below is an incomplete table of address modifiers:
| Hex Code | Function | Explanation |
|---|---|---|
| 3f | Standard Supervisory block transfer | Block transfer A24, privileged |
| 3e | Standard Supervisory Program access | A24 instruction access, privileged |
| 3d | Standard Supervisor Data Access | A24 data access, privileged |
| 3b | Standard Non-privileged block transfer | A24 block transfer for normal programs |
| 3a | Standard Non-privileged Program access | A24 instruction access, non-privileged |
| 39 | Standard non-privileged Data Access | A24 data access, non-privileged |
| 2d | Short supervisory Access | A16 privileged access. |
| 29 | Short non-privileged Access | A16 non-privileged access. |
| 0f | Extended supervisory Block transfer | A32 privileged block transfer. |
| 0e | Extended supervisory Program access | A32 privileged instruction access. |
| 0d | Extended supervisory Data Access. | A32 privileged data access. |
| 0b | Extended Non-privileged Block transfer | A32 non-privileged block transfer. |
| 0a | Extended Non-privileged Program access | A32 non-privileged instruction access. |
| 09 | Extended non-privileged data access. | A32 non-privileged data access. |
| Note | An as in A16, A24, A32 refers to the width of the address |
On the VME bus, all transfers are DMA and every card is a master or slave. In most bus standards, there is a considerable amount of complexity added in order to support various transfer types and master/slave selection. For instance, with the ISA bus, both of these features had to be added alongside the existing "channels" model, whereby all communications was handled by the host CPU. This makes VME considerably simpler at a conceptual level while being more powerful, though it requires more complex controllers on each card.
When developing and/or troubleshooting the VME bus, examination of hardware signals can be very important. Logic analyzers and bus analyzers are tools that collect, analyze, decode, store signals so people can view the high-speed waveforms at their leisure.
VITA offers a comprehensive FAQ to assist with the front end design and development of VME systems.
Computers using VMEbus include:
Seen looking into backplane socket.[12][13]
P1
| Pin | a | b | c |
|---|---|---|---|
| 1 | D00 | BBSY* | D08 |
| 2 | D01 | BCLR* | D09 |
| 3 | D02 | ACFAIL* | D10 |
| 4 | D03 | BG0IN* | D11 |
| 5 | D04 | BG0OUT* | D12 |
| 6 | D05 | BG1IN* | D13 |
| 7 | D06 | BG1OUT* | D14 |
| 8 | D07 | BG2IN* | D15 |
| 9 | GND | BG2OUT* | GND |
| 10 | SYSCLK | BG3IN* | SYSFAIL* |
| 11 | GND | BG3OUT* | BERR* |
| 12 | DS1* | BR0* | SYSRESET* |
| 13 | DS0* | BR1* | LWORD* |
| 14 | WRITE* | BR2* | AM5 |
| 15 | GND | BR3* | A23 |
| 16 | DTACK* | AM0 | A22 |
| 17 | GND | AM1 | A21 |
| 18 | AS* | AM2 | A20 |
| 19 | GND | AM3 | A19 |
| 20 | IACK* | GND | A18 |
| 21 | IACKIN* | SERCLK | A17 |
| 22 | IACKOUT* | SERDAT* | A16 |
| 23 | AM4 | GND | A15 |
| 24 | A07 | IRQ7* | A14 |
| 25 | A06 | IRQ6* | A13 |
| 26 | A05 | IRQ5* | A12 |
| 27 | A04 | IRQ4* | A11 |
| 28 | A03 | IRQ3* | A10 |
| 29 | A02 | IRQ2* | A09 |
| 30 | A01 | IRQ1* | A08 |
| 31 | −12V | +5VSTDBY | +12V |
| 32 | +5V | +5V | +5V |
P2
| Pin | a | b | c |
|---|---|---|---|
| 1 | User Defined | +5V | User Defined |
| 2 | User Defined | GND | User Defined |
| 3 | User Defined | RESERVED | User Defined |
| 4 | User Defined | A24 | User Defined |
| 5 | User Defined | A25 | User Defined |
| 6 | User Defined | A26 | User Defined |
| 7 | User Defined | A27 | User Defined |
| 8 | User Defined | A28 | User Defined |
| 9 | User Defined | A29 | User Defined |
| 10 | User Defined | A30 | User Defined |
| 11 | User Defined | A31 | User Defined |
| 12 | User Defined | GND | User Defined |
| 13 | User Defined | +5V | User Defined |
| 14 | User Defined | D16 | User Defined |
| 15 | User Defined | D17 | User Defined |
| 16 | User Defined | D18 | User Defined |
| 17 | User Defined | D19 | User Defined |
| 18 | User Defined | D20 | User Defined |
| 19 | User Defined | D21 | User Defined |
| 20 | User Defined | D22 | User Defined |
| 21 | User Defined | D23 | User Defined |
| 22 | User Defined | GND | User Defined |
| 23 | User Defined | D24 | User Defined |
| 24 | User Defined | D25 | User Defined |
| 25 | User Defined | D26 | User Defined |
| 26 | User Defined | D27 | User Defined |
| 27 | User Defined | D28 | User Defined |
| 28 | User Defined | D29 | User Defined |
| 29 | User Defined | D30 | User Defined |
| 30 | User Defined | D31 | User Defined |
| 31 | User Defined | GND | User Defined |
| 32 | User Defined | +5V | User Defined |
P2 rows a and c can be used by a secondary bus, for example the STEbus.
A team of engineers at Motorola Microsystems led by Jack Kister, designed a 68000 development system called the EXORmacs. The backplane of the EXORmacs was called VERSAbus. While coordinating the efforts of his team, Jack wrote a 41-page bus description of VERSAbus which was published in November of 1979. The first EXORmacs was shipped in January 1980.
Source: Wikipedia. Article content is retrieved live through the MediaWiki API.
VMEbus (VERSAmodule Eurocard bus bus) is a computer bus standard physically based on Eurocard sizes.
VME eXtensions for instrumentation (VXI) bus refers to standards for automated test based upon VMEbus. VXI defines additional bus lines for timing and triggering as well as mechanical requirements and standard protocols for configuration, message-based communication, multi-chassis extension, and other features. In 2004, the 2eVME extension was added to the VXI bus specification, giving it a maximum data rate of 160 MB/s. The basic building block of a VXI system is the mainframe or chassis. This contains up to 13 slots into which various modules (instruments) can be added. The mainframe also contains all the power supply requirements for the rack and the instruments it contains. Instruments in the form of VXI Modules then fit the slots in the rack. VXI bus modules are typically 6U in height (see Eurocard) and C-size (unlike VME bus modules which are more commonly B-size). It is therefore possible to configure a system to meet a particular requirement by selecting the required instruments. The basic architecture of the instrument system is described in US patent 4,707,834. This patent was freely licensed by Tektronix to the VXIbus Consortium. The VXIbus grew from the VME bus specification, it was established in 1987 by Hewlett Packard (now Keysight Technologies), Racal Instruments (now Astronics Test Systems), Colorado Data Systems, Wavetek and Tektronix. VXI was promoted by the VXIbus Consortium, whose sponsor members were (as of 2009) Astronics Test Systems (formerly Racal Instruments), Bustec, Keysight Technologies, National Instruments, Teradyne, and VTI Instruments (formerly known as VXI Technology). The VXIplug&play Alliance specified additional hardware and software interoperability standards, such as the Virtual Instrument Software Architecture (VISA), although the alliance was eventually merged with the IVI Foundation. Application software that supports VXIplug&play instrument drivers for controlling instruments include LabVIEW and MATLAB.
The Nuclear Instrumentation Module (NIM) standard defines mechanical and electrical specifications for electronics modules used in experimental particle and nuclear physics. The concept of modules in electronic systems offers enormous advantages in flexibility, interchange of instruments, reduced design effort, ease in updating and maintaining the instruments. The NIM standard is one of the first (and perhaps the simplest) such standards. First defined by the U.S. Atomic Energy Commission's report TID-20893 in 1968–1969, NIM was most recently revised in 1990 (DOE/ER-0457T). It provides a common footprint for electronic modules (amplifiers, ADCs, DACs, CFDs, etc.), which plug into a larger chassis (NIM crate, or NIM bin). The crate must supply ±12 and ±24 volts DC power to the modules via a backplane; the standard also specifies ±6 V DC and 220 V or 110 V AC pins, but not all NIM bins provide them. Mechanically, NIM modules must have a minimum standard width of 1.35 in (34 mm), a maximum faceplate height of 8.7 in (221 mm) and depth of 9.7 in (246 mm). They can, however, also be built in multiples of this standard width, that is, double-width, triple-width etc. The NIM standard also specifies cabling, connectors, impedances and levels for logic signals. The fast logic standard (commonly known as NIM logic) is a current-based logic, negative "true" (at −16 mA into 50 ohms = −0.8 volts) and 0 mA for "false"; an ECL-based logic is also specified. Apart from the above-mentioned mechanical/physical and electrical specifications/restrictions, the individual is free to design their module in any way desired, thus allowing for new developments and improvements for efficiency or looks/aesthetics. NIM modules cannot communicate with each other through the crate backplane; this is a feature of later standards such as CAMAC and VMEbus. As a consequence, NIM-based ADC modules are nowadays uncommon in nuclear and particle physics. NIM is still widely used for amplifiers, discriminators, nuclear pulse generators and other logic modules that do not require digital data communication but benefit from a backplane connector that is better suited for high-power use.
Sun-3 is a series of UNIX computer workstations and servers produced by Sun Microsystems, launched on September 9, 1985. The Sun-3 series are VMEbus-based systems similar to some of the earlier Sun-2 series, but using the Motorola 68020 microprocessor, in combination with the Motorola 68881 floating-point co-processor (optional on the Sun 3/50) and a proprietary Sun MMU. Sun-3 systems were supported in SunOS versions 3.0 to 4.1.1_U1 and also have current support in NetBSD and Linux. It used to be supported by OpenBSD, but the port was discontinued after the 2.9 release.
Before the 1921 destruction of Tulsa’s Greenwood District, Black residents had created a remarkable center of business and community life. The district included stores, professional offices, entertainment venues and homes owned by Black citizens. Understanding Greenwood means learning what was built—not only what was burned.
MORE →Shirley Chisholm, elected in 1968.