What happened to exposed address pins/address bus?

Question

This could be a question for the Electronics StackExchange, but I figured that if I couldn't find any info about it it might be more of a Retrocomputing thing.

I've been poking around on Google and some vendor sites looking for a simple processor that I could just buy and plug into a breadboard or maybe hand-solder if necessary, and just mess around with as I learn about electronics and computer hardware.

I know about the 6502, as it were Ben Eater's videos that sparked my interest, but I thought "Hey, there must be some old 32 bit processor like this still in production". I'm the kind of guy who doesn't mind doing everything from scratch, even if it's impractical, so I was looking for something where I can hook up the 32 address lines to some memory or whatever in the same way you would a 6502. Turns out that that's not a thing. From what I understand, everything goes through controllers inside the chip for NAND or DDR or whatever and you connect those particular components/controllers to those pins, no exposed address bus or data pins.

I would have thought that some other people would want something like this, and that somebody would be making a really simple Microprocessor for that, whether it be in ARM or some old ISA, but all the chips I find are either 8/16 bit or have so many pins they need BGA, and none of them have anything clearly labelled as an address bus, so there must be a good reason it doesn't exist. I might just be using the wrong search terms or know way too little about electronics, but I can't seem to be able to find anything about this. If somebody could explain why to me, that would be greatly appreciated!

Answer 1

[...] but all the chips I find are either 8/16 bit or have so many pins they need BGA, and none of them have anything clearly labelled as an address bus, so there must be a good reason it doesn't exist. I might just be using the wrong search terms or know way too little about electronics, but I can't seem to be able to find anything about this. If somebody could explain why to me, that would be greatly appreciated!

The raesoning is rather simple: Total System Cost.

As much as we would like it, processors are not made to foster needs of students and tinkering hobbyists, but usage in real world applications. Here cost cutting is a major force if not the all over rule.

• For devices needing small RAM/ROM sizes (which is by now several hundret KiB) it's best to include it already with the controller. Saving all additional cost for its users.

• When it comes to larger amounts of RAM/ROM that can't be included, conversion from a classic address-/data-bus to what either memory is necessary. While this was, in the early days, a task comparable to the microprocessor itself, it's nowadays neglectable. Thus including it in a SoC is no deal, but cuts out the middle man, saving cost.

• Including the (DRAM) memory interface not only simplifies interfacing, it also enables higher access speed due specific burst protocols - something the last generation with a 'classic' bus (NS32532/M68060/iPentium) did already include - diverging from a simple A/D bus like mentioned.

• A variation thereof are applications of comparable low speed but high data need. Here using a serial (or small word size) interface like SPI or its extensions SD-Card and eMMC.

• Historically (and for the x86) CPUs were supplemented since 80286 times by 'chipsets' (NEAT) often consisting of (at least) two chips, a memory controller providing all memory translation and fast busses and an I/O controller offering standard busses for expansion like PCI(e), USB and so on.

  Over time the memory controllers have been integrated into the CPU, not at least because handling them needs at least as many pins as they provide - one of the most daring problems in chip design are pins - there are never enough.

  The latest iteration is with AMD's Ryzen CPUs which are more of a SoC, as they integrate the I/O controller as well. Chipsets for Ryzen only increase available interfaces and could be saved for minimal systems.

Bottom line, a classic A/D bus might be the most simple and versatile solution, but like all simple solutions, it doesn't scale well.

C's everything is a byte in sequential storage might be the perfect counterpart in software. Quite flexible to handle everything and equally portable to a majority of architectures - but on the other hand extreme bad to improve on for performance. Just hink about all the add-ons all later versions up to today's C++ and derivativ languages did introduce to fix it one way or another.

It's quite funny that hardware was way more able to simply drop it and switch to higher grade interfaces.

Answer 2

You won't find a 32-bit processor that had a clock speed slow enough to work with a breadboard type of layout, and in any case the chip would have too many pins to package that way (the address and data bus would take 64 pins, without anything else).

A 32-bit data bus doesn't mean that data is always transferred 32 bits at a time - some instructions only transfer 16 or 8 bits. So you need the logic circuits to handle that, not just a direct connection to the memory chips.

For an early 32 bit CPU like the 80386, you need a circuit board with power and ground planes, not a breadboard.

There is nothing stopping you designing and building 386-based computer "from scratch" if you really want to, but Intel's hardware reference manual for the 386 is a 300-page document, compared with the simplicity of a chip like the 6502.

Answer 3

To expand on the 68000-family suggestion from @user and @Stefan Skoglund's comments, in community wiki form:

The 68000 is a 1979 processor with a 32-bit instruction set that appears still to be supported by GCC*. It was initially available as a 64-pin DIP, using a 24-bit address bus and 16-bit data bus. Additional complexity over an 8-bit machine is:

• it may access either a 16-bit quantity or an 8-bit quantity — there are a couple of pins to tell you which halves of the bus are in use; and
• more minor, it's full-speed bus is asynchronous in the sense that the processor itself will announce the intended access then wait for DTACK (i.e. data acknowledge) before completing the access. As per the title of a famous newsletter, you can just ground DTACK to get a bus that just always powers on through.

Other interesting variants are:

• the 68008, which has the same instruction set but is packaged as a 40-pin DIN and uses only an 8-bit data bus. So interfacing is very similar indeed to a 6502 or Z80;
• the 68010, which is a very minor improvement over the 68000, primarily in supporting recovery from faults, including access faults, which facilitates virtual memory.

From the 68020 onwards you're looking at quad flat pack or pin grid array sockets; both use full 32-bit data and address buses and have a correspondingly more complicated set of signalling for identifying which parts of the data bus are being used in any memory access. The QFP version has 132 pins.

* at least they're still documenting 68k-specific command line flags in that, the GCC 11 documentation. I can't speak as to how well maintained that support is.

Answer 4

Welcome to the site (I am also very new). If the reason for your question was as you said "looking for a simple processor that I could just buy and plug into a breadboard or maybe hand-solder if necessary, and just mess around with as I learn about electronics and computer hardware.",what was wrong with 6502 / why do you need a 32-bit one?

If you preferred Sinclairs to Commodores, I think you can get the same with e.g. a Z80A. At least mine worked OK without soldering just on a "push-wire-in-breadboard" (with all the data + address lines) Can't remember how high I set the clock, maybe around 400 kHz.

https://www.amazon.com/s?k=z80a&ref=nb_sb_noss_2

Answer 5

Some microcontrollers have I/O pins that can be configured to operate as a memory bus for part of their address space, with configurable wait states. Most of the applications which would need more memory than could fit on a chip would either also demand more speed than could be achieved with all code having to be conveyed on an external bus, or could get by with a serial memory interface, so there isn't going to be much market for a CPU which operates purely off an external bus and doesn't have a fair amount of on-board storage as well (in the form of cache if nothing else). Modern memory systems can process sequences of related accesses, such as those used to fill a cache, much faster than they can process random accesses, so it makes sense to have a memory interface that is based upon that concept, rather than one that regards every memory access as independent.

I've not used any external bus features on any controllers lately, but the ST reference manual RM0038 for the STM32L100xx and STM32L151xx series describes a bus interface that will treat an external 8 or 16-bit bus as a region of the device address space which could be operated slowly enough to support breadboard use if one had a suitable carrier board.

Answer 6

The primary reason you don't see open address buses is clock speed. At the >100Mhz speeds modern processor's chipset buses operate at, having multiple things connected to an electrical line results in complex wave behaviors. Thus it is a lot easier to have a single point to point bus to a chipset IC, which handles fanout to the various controllers.

A secondary reason you don't see an open address bus from the chipset is autoconfig. A DIMM doesn't have a hardwired mapping from the CPU address space to DIMM addresses. The processor memory controller queries the DIMM to find out its geometry, and then automatically configures the mapping. This is sufficiently complex to need an IC, and its easier to have the IC built in to something else than to need a dedicated IC.

For a 32 bit processors this translation was usually done by the chipset, but as memory bandwidth and chipset bandwidth requirements have gone up, the memory was moved to a dedicated bus from the CPU, at which point it makes sense to have the controller on the CPU.

Likewise for expansions cards, PCI and latter needs a controller negotiate with the card as to which address space the card should respond to, and then map that into the address space. Again as bandwidth and latency requirements for Graphics cards, SSDs and Network cards have gone up, some processors have started including PCIe controllers for the expansion cards directly on the CPU.

Answer 7

High-end processors do still expose their busses- but you typically need special support chips to do anything useful with them.

In the past I was involved with an (AMD) '386 design, but it also had to have an external bus exchange chip to handle all possible combinations of 32/16/8-bit accesses.

These days, if you can't find the kind of chip you want, build your own. The link below is for RISCV, and implements the CPU on an FPGA with external RAM and at least partial support for non-aligned access.

https://www.youtube.com/watch?v=yLs_NRwu1Y4

Otherwise, there's been at least one project (mentioned on Hackaday, link below) which implemented a low-end ARM on an AVR chip using an external SIMM for storage... it was apparently able to boot Linux (s-l-o-w-l-y :-)

http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit