Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
NuBus
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Architecture== Early microcomputer buses like [[S-100 bus|S-100]] were often just connections to the pins of the microprocessor and to the power rails. This meant that a change in the computer's architecture generally led to a new bus as well. Looking to avoid such problems in the future, NuBus was designed to be independent of the processor, its general architecture and any details of its I/O handling. Among its many advanced features for the era, NuBus used a [[32-bit]] backplane when 8- or 16-bit busses were common. This was seen as making the bus "future-proof", as it was generally believed that 32-bit systems would arrive in the near future while 64-bit buses and beyond would remain impractical and excessive.{{fact|reason=NuBus is 1980s, 64 bit computing already existed in supercomputers and arrived in workstations at the beginning of the 90s, it wasn't a surprise|date=May 2023}} In addition, NuBus was agnostic about the processor itself. Most buses up to this point conformed to the signalling and data standards of the machine they were plugged into (being big or [[little endian]] for instance). NuBus made no such assumptions, which meant that any NuBus card could be plugged into any NuBus machine, as long as there was an appropriate [[device driver]]. In order to select the proper device driver, NuBus included an ID scheme that allowed the cards to identify themselves to the host computer during startup. This meant that the user didn't have to configure the system, the bane of bus systems up to that point. For instance, with [[Industry Standard Architecture|ISA]] the driver had to be configured not only for the card, but for any memory it required, the [[interrupt]]s it used, and so on. NuBus required no such configuration, making it one of the first examples of ''[[plug-and-play]]'' architecture. On the downside, while this flexibility made NuBus much simpler for the user and device driver authors, it made things more difficult for the designers of the cards themselves. Whereas most "simple" bus systems were easily supported with a handful of [[input/output]] chips designed to be used with that CPU in mind, with NuBus every card and computer had to convert everything to a platform-agnostic "NuBus world". Typically this meant adding a NuBus controller chip between the bus and any I/O chips on the card, increasing costs. While this is a trivial exercise today, one that all newer buses require, in the 1980s NuBus was considered needlessly complex and expensive.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)