I did some assembly programming on the Fairchild F8 mentioned in the prequel article. Quaintest feature: Doing a “long” jump (more than 127 bytes away) would cause the accumulator register to be clobbered. Presumably, there was nowhere else to store the high (low?) order address byte routing things around to the PC register. This was also a problem for the debugger (in ROM on the development system), since continuing from a breakpoint necessitated a long jump, so it couldn’t restore the accumulator. So, the debugger would just simulate instructions until it hit a jump, which it could then jump to. Or something like that. Fairchild provided a listing of the source to the debugger / emulator, and the line that simulated messing up the accumulator during single-stepping was commented “The F8 Touch!” It made an impression 50 years ago.
The article kind of disses the Intel 8085. For those of us with 8080 code bases that were never going to be rewritten for the Z80, it was a welcome upgrade. On the paper dryer process control systems I was working on in 1979, the 8085 based Intel 80/30 Multibus SBC could be dropped in for the older 8080 based 80/20 SBC with no changes and provide a significant 2.5X performance upgrade.
The Signetics 2650 found its way into a bunch of arcade games by lieu of British company Century Electronics. I have a conversion kit of theirs installed into a Donkey Kong Jr. board, which outright replaces DK Jr.'s Z80 with a daughterboard containing the CPU. Always wondered why they chose that in particular, it's not a very common chip, and just using the Z80 that was there and replacing the ROMs was the more common option for conversion kits like that.
Given the era, I wouldn't be surprised if it came down to "someone on the development team liked that part". (Or "someone in the purchasing department got a bunch of them really cheap".)
The 2650 was one of the first microprocessors on the market you could buy, it was shockingly simple to design, and had some dedicated I/O lines. Look up the reference schematic and compare to what a 6502 or Z80 needs. It was used in a lot of early embedded systems. It makes sense in that light
Question: I once heard somebody talk about a micro-controller (with a minimal instruction set) where every register could be the program counter. It did not have jump or call instructions. You had 'emulate' those with the instruction (possibly conditionally) that changed the assignment of the program counter to one of the instructions. If I am not mistaken, it had eight registers. Does this ring a bell?
“The ARM architecture provides sixteen 32-bit general purpose registers (R0-R15) for software use. Fifteen of them (R0-R14) can be used for general purpose data storage, while R15 is the program counter whose value is altered as the core executes instructions. An explicit write to R15 by software will alter program flow.”
Similarly, the PDP-11 used R7 for that. https://en.wikipedia.org/wiki/PDP-11_architecture: “The CPU contains eight general-purpose 16-bit registers (R0 to R7). Register R7 is the program counter (PC)”
I’m not aware of any CPU where “every register could be the program counter”. Such a feature also feels weird to me from a design view because I think it complicates the hardware with few (code might be smaller for a limited set of jumps) benefits. Maybe you’re confusing that with the ability to jump to whatever address is in any of the general purpose registers?
“The SEP instruction can select any of the 16 registers to be the program counter. The SEX instruction can select any of the 16-bit registers to be the index register.”
That description does not match the RCA 1802 [1] perfectly, but it is probably the best known microprocessor (not a microcontroller, though) without a dedicated program counter. There are a lot of misconceptions about it floating on the internet, so I would not be surprised to hear it described as you did.
The RCA-1802 was used in the COSMAC Elf computer which was described as a hobbyist project to build in a series of articles in Popular Electronics 50 years ago. The Elf may be obscure but one thing developed on it (or its successor, the COSMAC VIP), CHIP-8, lives on -- it was (by some definitions) the first "fantasy console" like Pico-8 and TIC-80 today -- a virtual machine designed for writing action games.
Oh yes, I cut my teeth on a Finnish 1802 based TELMAC in the 1970s. It all of 2 kb of RAM (in 16 chips manually soldered on the board), and room for another 2kb if anyone would need so much, as it said in the instructions. I might almost be able to reconstruct the instruction set now, it was so deep ingrained in my brain. Once I had nightmares directly in hex. Sold my first pieces of code on that CPU, a 2kb long "monitor" rom, maybe a bit like a BIOS in today's terms. Added .5 kb of new features and optimized it so it could still fit in that 2kb EPROM.
Slightly orthogonal, but I'm curious how much effort is going into capturing historic hardware in accurate FPGA representation?
There'll come a day when the final physical 6502, 80486 (etc etc) powers off for the final time, and it seems like these technologies would be worth preserving. (I'm sure this is much easier said than done, not trying to minimise the effort involved.)
A lot of effort goes into accurately emulating historic processors in the MAME project, as well as other vintage hardware. It's generally accurate enough that MAME is regularly used to emulate vintage hardware when reverse-engineering devices.
Full die capture, full transistor level simulation.
Most of the others are being emulated in proportion to their importance to games, in arcade machines and consoles. Those emulations are going to be as cycle-accurate as required.
There are some issues around things like the Yamaha synth chips, which are mixed-signal and depend on analogue properties that can be difficult to emulate.
Most fun I ever had with a 6502 was when I realized that, at 1 MHz, I could do 250,000 average instructions per second. So I divided my monitor up into 20 boxes to have 12500 (fairly complex!) instructions per per second for each box. I used them to separately animate the contents of each box differently.
Just calculating or shuffling data around was invisible.
With that visualization I first realized how much stuff could be done with a 1MHz CPU.
It's easy to forget how much innovation divergence was happening in the early 70s. Up till the late nineties we speculated that ISAs other than x86 (spec. RISC designs) would win in the end.
Imagine these 8 bitters were mostly hardwired, with less than a million transistors.
It depends on how you want to treat the internal (not seen by user or compiler) decoding that both AMD and Intel are doing; some would argue that these CPUs are RISC chips that decode x86 and x64 instructions into their own RISC implementation.
The 8-bit monolithic CPUs of the seventies all had a few thousands transistors.
The first generation of true 16-bit CPUs, i.e. Intel 8086, Motorola MC68000 and Zilog Z8000, had almost an order of magnitude more transistors, i.e. in the range of 15000 transistors to 50000 transistors.
The first true 32-bit CPUs, like the National 32000 series, Motorola MC68020 and Intel 80386, had a few hundred thousand transistors.
By the end of the eighties, the second generation of 32-bit CPUs reached 1 million transistors.
I think there were actually 68000 transistor positions. In the ROMs and PLAs not every potential transistor is populated but the missing ones were counted as well. But the number of actual transistors is only slightly smaller so it doesn't really matter.
I do not remember the exact number of transistors in MC 68000, but I think that it was less than 40000, so not just slightly smaller. In any case, it had more than twice as many transistors as Zilog Z8000, which was super-optimized for size (a very bad decision of Zilog, which lead to a too long time-to-market and to many initial bugs), and slightly more than 4/3 times as many transistors as Intel 8086.
The 68000 transistors number claimed by the Motorola marketing was close to what you get by dividing the die area to the area of one transistor, so it did not correspond to actual transistor positions.
The MC68000 die had large areas occupied with microprogram ROMs, and there as you say only a part of the array of transistors are active, depending on the stored bits. Nonetheless, a significant part of the die was occupied with random logic, where all the physical transistors are used and a part of the area does not have any transistors.
I did some assembly programming on the Fairchild F8 mentioned in the prequel article. Quaintest feature: Doing a “long” jump (more than 127 bytes away) would cause the accumulator register to be clobbered. Presumably, there was nowhere else to store the high (low?) order address byte routing things around to the PC register. This was also a problem for the debugger (in ROM on the development system), since continuing from a breakpoint necessitated a long jump, so it couldn’t restore the accumulator. So, the debugger would just simulate instructions until it hit a jump, which it could then jump to. Or something like that. Fairchild provided a listing of the source to the debugger / emulator, and the line that simulated messing up the accumulator during single-stepping was commented “The F8 Touch!” It made an impression 50 years ago.
The article kind of disses the Intel 8085. For those of us with 8080 code bases that were never going to be rewritten for the Z80, it was a welcome upgrade. On the paper dryer process control systems I was working on in 1979, the 8085 based Intel 80/30 Multibus SBC could be dropped in for the older 8080 based 80/20 SBC with no changes and provide a significant 2.5X performance upgrade.
The Signetics 2650 found its way into a bunch of arcade games by lieu of British company Century Electronics. I have a conversion kit of theirs installed into a Donkey Kong Jr. board, which outright replaces DK Jr.'s Z80 with a daughterboard containing the CPU. Always wondered why they chose that in particular, it's not a very common chip, and just using the Z80 that was there and replacing the ROMs was the more common option for conversion kits like that.
Zaccaria pinballs I think used it pretty heavily as well. Again, no clear explanation there either.
Given the era, I wouldn't be surprised if it came down to "someone on the development team liked that part". (Or "someone in the purchasing department got a bunch of them really cheap".)
The 2650 was one of the first microprocessors on the market you could buy, it was shockingly simple to design, and had some dedicated I/O lines. Look up the reference schematic and compare to what a 6502 or Z80 needs. It was used in a lot of early embedded systems. It makes sense in that light
Question: I once heard somebody talk about a micro-controller (with a minimal instruction set) where every register could be the program counter. It did not have jump or call instructions. You had 'emulate' those with the instruction (possibly conditionally) that changed the assignment of the program counter to one of the instructions. If I am not mistaken, it had eight registers. Does this ring a bell?
There are/were quite a few CPUs where the program counter is one of the general purpose registers.
For example, https://developer.arm.com/documentation/den0013/0400/ARM-Pro...:
“The ARM architecture provides sixteen 32-bit general purpose registers (R0-R15) for software use. Fifteen of them (R0-R14) can be used for general purpose data storage, while R15 is the program counter whose value is altered as the core executes instructions. An explicit write to R15 by software will alter program flow.”
Similarly, the PDP-11 used R7 for that. https://en.wikipedia.org/wiki/PDP-11_architecture: “The CPU contains eight general-purpose 16-bit registers (R0 to R7). Register R7 is the program counter (PC)”
I’m not aware of any CPU where “every register could be the program counter”. Such a feature also feels weird to me from a design view because I think it complicates the hardware with few (code might be smaller for a limited set of jumps) benefits. Maybe you’re confusing that with the ability to jump to whatever address is in any of the general purpose registers?
EDIT: I just saw a comment mentioning the 1892. It indeed had that ability. https://en.wikipedia.org/wiki/RCA_1802#Registers_and_I/O:
“The SEP instruction can select any of the 16 registers to be the program counter. The SEX instruction can select any of the 16-bit registers to be the index register.”
That description does not match the RCA 1802 [1] perfectly, but it is probably the best known microprocessor (not a microcontroller, though) without a dedicated program counter. There are a lot of misconceptions about it floating on the internet, so I would not be surprised to hear it described as you did.
[1] https://en.wikipedia.org/wiki/RCA_1802
This might have been the PDP-11.
The RCA-1802 was used in the COSMAC Elf computer which was described as a hobbyist project to build in a series of articles in Popular Electronics 50 years ago. The Elf may be obscure but one thing developed on it (or its successor, the COSMAC VIP), CHIP-8, lives on -- it was (by some definitions) the first "fantasy console" like Pico-8 and TIC-80 today -- a virtual machine designed for writing action games.
https://en.wikipedia.org/wiki/COSMAC_Elf https://en.wikipedia.org/wiki/CHIP-8
Oh yes, I cut my teeth on a Finnish 1802 based TELMAC in the 1970s. It all of 2 kb of RAM (in 16 chips manually soldered on the board), and room for another 2kb if anyone would need so much, as it said in the instructions. I might almost be able to reconstruct the instruction set now, it was so deep ingrained in my brain. Once I had nightmares directly in hex. Sold my first pieces of code on that CPU, a 2kb long "monitor" rom, maybe a bit like a BIOS in today's terms. Added .5 kb of new features and optimized it so it could still fit in that 2kb EPROM.
Slightly orthogonal, but I'm curious how much effort is going into capturing historic hardware in accurate FPGA representation?
There'll come a day when the final physical 6502, 80486 (etc etc) powers off for the final time, and it seems like these technologies would be worth preserving. (I'm sure this is much easier said than done, not trying to minimise the effort involved.)
Is there a project that does something like this?
A lot of effort goes into accurately emulating historic processors in the MAME project, as well as other vintage hardware. It's generally accurate enough that MAME is regularly used to emulate vintage hardware when reverse-engineering devices.
The 6502 is one of the most heavily preserved technologies: http://www.visual6502.org/JSSim/index.html
Full die capture, full transistor level simulation.
Most of the others are being emulated in proportion to their importance to games, in arcade machines and consoles. Those emulations are going to be as cycle-accurate as required.
There are some issues around things like the Yamaha synth chips, which are mixed-signal and depend on analogue properties that can be difficult to emulate.
Quite a few. There's a great project to do cycle accurate emulation of the 8086, too, which is more my area of interest than 6502.
Note that 6502s are still being produced, albeit in a modern CMOS version.
Most fun I ever had with a 6502 was when I realized that, at 1 MHz, I could do 250,000 average instructions per second. So I divided my monitor up into 20 boxes to have 12500 (fairly complex!) instructions per per second for each box. I used them to separately animate the contents of each box differently.
Just calculating or shuffling data around was invisible. With that visualization I first realized how much stuff could be done with a 1MHz CPU.
It's easy to forget how much innovation divergence was happening in the early 70s. Up till the late nineties we speculated that ISAs other than x86 (spec. RISC designs) would win in the end.
Imagine these 8 bitters were mostly hardwired, with less than a million transistors.
> ISAs other than x86 (spec. RISC designs) would win in the end
They're correct: ARM won the mobile space, won Apple, and is very gradually seeping into wider availability for other operating systems.
Never mind the majority of raw FLOPS these days are almost certainly going through GPU architectures.
It depends on how you want to treat the internal (not seen by user or compiler) decoding that both AMD and Intel are doing; some would argue that these CPUs are RISC chips that decode x86 and x64 instructions into their own RISC implementation.
Way less than a million! I believe usually in the order of thousands.
Indeed. The 6502 had 3510 enhancement transistors and 1018 depletion transistors for a total of 4528...
With the layout fitting entirely on a large sheet of paper: https://archive.archaeology.org/1107/features/mos_technology...
Amazing article!
The 8-bit monolithic CPUs of the seventies all had a few thousands transistors.
The first generation of true 16-bit CPUs, i.e. Intel 8086, Motorola MC68000 and Zilog Z8000, had almost an order of magnitude more transistors, i.e. in the range of 15000 transistors to 50000 transistors.
The first true 32-bit CPUs, like the National 32000 series, Motorola MC68020 and Intel 80386, had a few hundred thousand transistors.
By the end of the eighties, the second generation of 32-bit CPUs reached 1 million transistors.
The Motorola 68000, a great CPU with 32-bit operands, was initially implemented with 68,000 transistors.
The model number was decided long before the transistor-level design was finalized.
I think there were actually 68000 transistor positions. In the ROMs and PLAs not every potential transistor is populated but the missing ones were counted as well. But the number of actual transistors is only slightly smaller so it doesn't really matter.
I do not remember the exact number of transistors in MC 68000, but I think that it was less than 40000, so not just slightly smaller. In any case, it had more than twice as many transistors as Zilog Z8000, which was super-optimized for size (a very bad decision of Zilog, which lead to a too long time-to-market and to many initial bugs), and slightly more than 4/3 times as many transistors as Intel 8086.
The 68000 transistors number claimed by the Motorola marketing was close to what you get by dividing the die area to the area of one transistor, so it did not correspond to actual transistor positions.
The MC68000 die had large areas occupied with microprogram ROMs, and there as you say only a part of the array of transistors are active, depending on the stored bits. Nonetheless, a significant part of the die was occupied with random logic, where all the physical transistors are used and a part of the area does not have any transistors.
A 486 already had over a million transistors. These are in the thousands.
The 6809 was a little of a beast too. It powered the Vectrex and some TRS-80 Color models.
The OS was interesting too: https://en.wikipedia.org/wiki/OS-9