The 8051 is a Harvard-based microcontroller, but it allows us to connect external memory and simulate von Neumann's architecture. What is the main reason it was not used widely in 1980s home computers?

Was 8051 too late (1980)? Or has it too slow access to the external memory? Or is there a lack of an instruction set? Or is there another reason?

  • 7
    As I recall it saw some use in a games console. I don't remember which one. This means that it probably was a perfectly cromulent choice for a computer too. But I think it was more designed as a microcontroller. Feb 18, 2020 at 11:59
  • 1
    IIRC, 8051 with derivates are still used in home computer. As I remember it is the number one controller for keyboards.
    – UncleBod
    Feb 18, 2020 at 12:27
  • 2
    @UncleBod I saw only i8048 in keyboards but they are very similar to i8051 ...
    – Spektre
    Feb 18, 2020 at 12:53
  • 2
    There was a program named BASIC51 that ran on a i8051 with external RAM and a serial terminal. Does this combination count as a home computer? Feb 18, 2020 at 13:20
  • I think it was its limited instruction set that is too slow when accessing external memory. Feb 18, 2020 at 13:22

7 Answers 7


i8051 used shared buses which mean for simple connection of a memory you would need latches and some logic to select between RAM/ROM chips etc. That means more complicated circuitry and more ICs for design.

Also the i8051 architecture is more suited for static programs in EPROM/EEPROM instead of in RAM.

So a native bus driven CPU was the usual choice over i8051.

However, in the case of consoles and TV games, the i8051 is a valid choice (you know, EPROM cartridges or fixed games; no programming or OS or whatever dynamic behavior whatsoever)

Yes i8051 is an MCU; that means it's an "entire" computer on single chip (apart abbreviations without (E)EPROM) for some specific task and use most of its pins as I/O ports ... so it's more suited for very different tasks than a standard home computer we know ...

  • 3
    The i8051 is not the only chip with "shared busses", the i8088 had it also, and it was a great commercial success. Feb 18, 2020 at 13:19
  • Look for any talks by John Wharton (passed away a bit over a year ago). He used to talk about what led to the 8051 ISA. IIRC, it had a different product target than the 8080 et.al., and thus has lasted a lot longer as a high volume ISA.
    – hotpaw2
    Feb 18, 2020 at 15:28
  • @thebusybee: The RCA CDP1802 also required an external latch for half of the address bus, though it multiplexed the high and low order portions of the address while leaving data by itself--probably because that facilitated chip layout.
    – supercat
    Feb 18, 2020 at 18:07

The 8051 is a Harvard-based microcontroller,

Not really. It's a modified Von-Neumann design with non overlapping address spaces for program, data and I/O. There is no simultaneous access to program and data at the same time, which is the basic feature for any Harvard design (*1).

A modified Von-Neumann architecture combines the (software) advantage of separate address spaces with the need of only a single bus for data and program combined, which simplifies hardware design, quite important to save chip area on (early) microcontrollers.

What is the main reason it was not used widely in 80's home computers?

A main reason? Then it will be the same for all microcontrollers: It's a microcontroller.

Microcontrollers are about providing as many programmable ports as possible. The 8051 came in a 40-pin device offering 32 of the 40 as free accessible I/O, organized as 4 ports. With external memory, 3 of the 4 are used for control lines and address/data, leaving a single 8-bit port.

With external RAM/ROM, it gets reduced to a tiny (128 Bytes) RAM, 4 KiB of ROM, an 8-bit port and two timers. While not enough to define the core of a home computer of the early 1980s, it would need exactly the same external components as a standard CPU like an 8085: external latches, address decoding, RAM/ROM for program/data, video RAM, video controller and so on.

Considering that an MCU is usually more expensive than a MPU, using the 8051 that way would make it more expensive than using an 8085 - and less flexible as well.

Was 8051 too late (1980)?

Most definitely. Especially when considering that it would have taken 2-3 more years until a complex device, like a home computer, would be ready for market - that's about the time the Famicom/NES hit the market - with specs, a 8051 couldn't compete without at all.

Or has it too slow access to the external memory?

Not just that, but incrediblly slow in general, even more so in 1980. Its maximum clock frequency of 12 MHz may seem a lot, but that gets less impressive when considering that a machine cycle takes 12 clock cycles. Also, the full 12 MHz can only be sustained on external RAM/ROM with an access time of less than 166 ns. With RAM like that, a 6502 could run at 3 MHz or a Z80 at 8 MHz.

RAM speed is about cost, so it would be more likely that the 8051 would have run at only 4 MHz, as its memory interface had no way of extending access time when needed. The practical result would have been an even slower computer, delivering mediocre performance.


At that point it's important, that while random RAM access is quite slow on the 8051, this doesn't influence real world application as much. Most access will still be for code. A real setup would keep core access function in on board ROM, making execution fast and equal important, all heavy used data would be held in on board RAM, as well accessible in full speed - much like the zero/direct page of 6500/6800 type MCUs. In addition, 8051 code is quite compact, thus as well reducing impact of slowdown for external code.

Bottom line for speed: While the 8051 is quite slow in itself, when running some BASIC program, performance would still be competive.

Or is there any lack of instruction set?

It's almost never the instruction set. The fun about programmable devices is that everything can be done.

Or is there any other reason?

As said, it's not meant to work as a general purpose computer, but a controller. Using it as such is much like using a sporty convertible (imagine here a 1980s Fiat X15 or Alpha Spider) as the family car.

Now having said that, 8051 have been used in many computer like devices, especially various 'kid computers' of the 1990s. For the early, 1980 time frame, it was rather the 8048, the direct predecessor (*2) was used in several computer like devices:

  • IMSAI 8048 Control Computer, a very early (1977) single boarder, expandable to 64(!) KiB RAM.
  • Philips Videopac Computer G7000 (also known as Magnavox Odyssey 2) - eventually the most known one.
  • Kosmos Computer Praxis CP1, a course system. Here the 8049 runs a virtual decimal (!) processor.
  • 8052AH BASIC - almost a computer - it's basically a 8051 with double the RAM (256 Bytes) and an 8 KiB BASIC interpreter in ROM. As Busybee already mentioned, all it needs is some external RAM and a terminal (*3) .

The G700 is eventually the closest to a (home) computer here. It features a full keyboard and colour video capabilities. With a basic cartridge it could for sure compete with a ZX80/81 of the same time.

*1 - Harvard isn't about separate address spaces. They are just a side effect of parallel access to program and data store - which in turn is intended to allow independent read and faster operations (It as well relaxes the need to make program and data word size the same).

Logical a Harvard type CPU can still merge both into one address space (to simplify handling), without leaving its origin. Similar a Von-Neumann can separate them logically without turning into Harvard, as the access is still common. And 8051 is an example of such a modified Von-Neumann.

*2 - In fact, the very first data sheet puts the 8051 into the MCS-48 family.

*3 - In the late 70s to early 80s several manufacturers offered a MCU with BASIC embedded.

  • 1
    The Intel 8048 microcontroller which predated the 8051 was used in a home video game system, but the requirements for those are a bit below the requirements for a practical home computer.
    – supercat
    Feb 18, 2020 at 18:05
  • Not really. After all, the ZX80 was quite successful, despite is't rather restricted structure.
    – Raffzahn
    Feb 18, 2020 at 19:08
  • The G7000 did have a programming environment in the form of a cartridge, the C7420. But that was not just a BASIC, it came with a Z80 CPU and its own memory.
    – MSalters
    Feb 20, 2020 at 16:35
  • @MSalters True, but that's just the way they did choose to go. It doesn't change the basic design as a complete system, or does it?
    – Raffzahn
    Feb 20, 2020 at 16:51

So I've read all the answers written before my own and they all IMHO are more or less missing the main point.

8051 can have a single monolithic external 64kb address space, that is both written, read and where the instructions are also fetched from. Having peripheral devices somewhere in that space is also nothing new, known from pdp-11, continued in 68xx and 6502.

It still has at least 2 pointers into that space.

However, there are only few instructions that access that external space, that is, movx a,@ptr and movx @ptr,a, where ptr is either dptr or r0/r1 (with high address part coming from the P2 port). Joining external data space with external code space gives us another two: movc a,@a+dptr and movc a,@a+pc. And that's all. There is no direct addressing of external spaces, there is no arithmetic or logic operations possible between accumulator and external spaces, there is no possibility to load anything except accumulator from/to external spaces.

There are, however, internal RAM memory, where direct addressing in arithmetic, logical and move instructions is possible. The only problem is that its size is 128 bytes. And another 128 bytes are only accessible in indirect way (like op a,@r0/@r1). The stack is also resides there, 4 sets of eight registers each are also there.

As a consequence, when the size requirements for "stack+direct-addressable RAM" exceed those 128/256 bytes, the things become really BAD: imagine accessing every single variable by mov dptr,#addr: movx a,@dptr.

So, there are 2 points in general:

  1. lack of convenient ways to access external memory spaces
  2. extremely limited internal RAM

Compare that to 6502 -- where in the worst case (huge multitasking) the things could be circumvented by adding a hardware memory paging in the first 512 bytes.

  • 1
    "1. lack of convenient ways to access external memory spaces" Not that much worse than other processors of the era. And there are ways to access that space, even if inefficient. "2. extremely limited internal RAM" Data can be moved in and out of external memory. Sure it is inefficient, but it can be done. And tokenized BASIC programs are data, not machine code. The hardest thing to move to external memory is the call stack, but even that can be pushed and popped to external memory.
    – DrSheldon
    Feb 18, 2020 at 21:39
  • 2
    @DrSheldon It can be done, but how successful would it be against the competition at that time?
    – Mast
    Feb 19, 2020 at 7:56
  • 3
    @DrSheldon We programmers are mostly lazy. When writing code, we don't want to fight against the hardware. We usually will flock to thing that hates us the less while we're trying to work.
    – T. Sar
    Feb 20, 2020 at 11:38
  • 6
    @DrSheldon, "Not that much worse than other processors of the era.". It was far worse with external memory than processors around, far worse. I extensively programmed 8051 (MCS-51), Z80, 6502 and 6800 professionally back then. In MCS-51, only Accumulator could load/store into external memory, addressed through the DPTR or P2+@R0/@R1 registers. In the Z80, addressing was through BC, DE, HL, IX, IY or direct address. Any of A, B, C, D, E, H, L could be read or written through HL, IX, IY. ALU ops could read thru HL, IX, IY. MCS-51 was appalling at it. Terrific microcontroller, bad microprocessor.
    – TonyM
    Feb 20, 2020 at 14:00

Even if wired into a system that allows programs to be run from external RAM, the 8051 architecture is designed to allow quick operations with up to 256 bytes of internal RAM and internal I/O. Accesses to anything outside that range are much slower. This is great for applications which spend most of their time dealing with internal I/O, but not so great for computation-heavy applications which spend only a tiny portion of their time on I/O tasks.

An optimal-speed function to copy a range of data between regions of external RAM would be something like:

mov dpl,r7
mov dph,r6
movx a,@dptr
inc dptr
mov r0,a
movx a,@dptr
inc dptr
mov r1,a
movx a,@dptr
inc dptr
mov r2,a
movx a,@dptr
inc dptr
mov r3,a
mov r7,dpl
mov r6,dph

Which is 24 cycles to read four bytes from external RAM at R6:R7 into registers and update R6,R7. Writing the data back would be another 24 cycles, and looping would be another 2, for 50 cycles total for four bytes. Since each CPU cycle is two RAM cycles, that would be 100 RAM cycles per byte. An optimized loop on the 6502 using RAM at the same speed would average about 41 CPU cycles per byte, but only one RAM cycle per CPU cycle.

  • 2
    Nice calculation, but then again it's a rather constructed worst case. In reality the RAM access seed for data is of lesser importance for real world applications. Computers of that time do mostly access (operate from) program memory, while random data access only accounts for a tiny fraction, eventually in the low single digit percentage. Highly utilized data can be held in the internal RAM - much like with a 6502's zero page. Even with assembly, the mentioned 6502 uses most bandwith for code - a case where the 8051 excels due it's compact code.
    – Raffzahn
    Feb 18, 2020 at 19:22
  • 1
    I agree with @Raffzahn's comment. The computers of the 8-bit era were running BASIC, not C. You wouldn't be doing a lot of block moves. And it wouldn't be the only processor of that era to require a slow, convoluted routine to perform a simple task.
    – DrSheldon
    Feb 18, 2020 at 21:50
  • 3
    @DrSheldon: Most commercial software for most machines was written in assembly language, and word processing and many kinds of games require the ability to move large amounts of memory around. Further, even a BASIC interpreter will often spend a fair amount of its time copying strings.
    – supercat
    Feb 18, 2020 at 22:07
  • 1
    @Raffzahn, I seem to recall my Spectravideo pausing for garbage collecting (or something) its BASIC strings sometimes in my larger programs. Feb 19, 2020 at 12:00
  • 2
    @Raffzahn: I think of word processing as being one of the dominant practical uses for microcomputers, and the 8051 architecture with its single data pointer really isn't great for that. There was an 8052 BASIC released as a product, which I suppose could have been the core of a personal computer if one didn't mind being limited to running BASIC programs, but I don't think any interpreted BASIC would be fast enough for a practical word processor.
    – supercat
    Feb 19, 2020 at 17:08

While internally the 8051 is actually a stored program CPU, to the programmer and hardware designer, it behaves as a Harvard machine which separate program and data memories.

Because of this, programs can only execute from program memory. Critically, there's no built-in way to modify program memory. Even if you stored the program in RAM, there are no instructions to write to program memory.

That means no loading machine language programs from cassette, or disk. It means no ability to write machine language software on the machine directly for execution. Any programability would be limited to an interpreter running from a fixed program. It could run something like BASIC, but that would be all it could run.

While it's probably possibly to jury-rig up a circuit that could rewrite program memory under program control, it makes a lot more sense to use a processor specifically designed from the beginning to manipulate its programs as data, like the 8080 or the 6502.

  • 4
    The whole problem is evaded by combining X and C memory spaces (that is, addressed via movx and movc) externally.
    – lvd
    Feb 18, 2020 at 17:38

No DMA to do video

A video controller chip needs immediate access to video RAM when it is outputting a row. To this end, microprocessors provide a pin that holds the processor and releases the buses. The process is called "Direct Memory Access".

The 8051 has no provision for DMA. It's not intended for systems which are that complicated. The microcontroller is the only chip that is supposed to be controlling the buses, and there are no pins for DMA or stalling the processor.

I suppose you could wire up some buffers to release the memory buses, but you still have no way to tell the processor to wait. I also suppose you could also have the microcontroller itself generate the video signals, in the manner of "racing the beam". However, writing the software for that is a lot of work, difficult to debug, and consumes most of the CPU time. Why would designers of that era bother with such issues when there are plenty of other processors that are compatible with video controllers?

  • FWIW many terminals of the mid-80s like the DEC VT220 and Wyse-85 were based around the 8051 and used DMA (archive.org/details/bitsavers_decterminacAug83_1797611/page/n3/…) for video in a low cost way.
    – davefiddes
    Feb 19, 2020 at 15:43
  • 1
    @davefiddes: The linked schematic uses a split-bus architecture, with a separate dedicated RAM for the video which operates independently of the main CPU. Any attempt to access the display buffer while it was being displayed would result in video interference. The display controller is designed to allow lines to be shown from video memory in arbitrary order so as to minimize the number of situations that would require writing many bytes at once. Even at the highest baud rate, I don't know if there are any byte sequences the terminal could receive that would require writing more than...
    – supercat
    Feb 20, 2020 at 15:52
  • ...one byte per scan line to the display memory.
    – supercat
    Feb 20, 2020 at 15:56
  • There are lots of spare clocks in the standard predictable 8051 12-clock instruction cycle to access shared memory. Equally, the clock could be extended high while such accesses took place. Instead, the main reasons it wasn't used were (a) rubbish data processing choice compared to Z80/6502, (b) expensive choice.
    – TonyM
    Feb 25, 2020 at 22:27
  • The ZX80 used the CPU to generate the (black and white, no grey). I vaguely remember that putting it into "speed mode" made it about 9 times faster, at the expense of not displaying video. Another option would have been dual-ported RAM...which was extremely expensive at that time. Later "solutions" to such problems were video chips with their own dedicated RAM. The CPU could access that RAM only though the video chip....which meant that it was very slow.
    – Klaws
    Mar 16, 2020 at 11:47

I think the reason was not a technical one.

As you pointed out, 8051 was late and it was positioned as a high-end 8080. It was an expensive one.

8-bit computers at that time decided to go for 6502 because it was a cheap competitor.

Few still remember the company behind 6502 (MOS Technology). It was a low-profile cheap mass product.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .