Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
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?
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 ...
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.
But...
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:
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.
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:
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.
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.
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.
movx and movc) externally.
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?
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.
i8048in keyboards but they are very similar toi8051...