Slashdot Mirror
Why the Z-80's Data Pins Are Scrambled
An anonymous reader writes "The Z-80 microprocessor has been around since 1976, and it was used in many computers at the beginning of the PC revolution. (For example, the TRS-80, Commodore 128, and ZX Spectrum.) Ken Shirriff has been working on reverse engineering the Z-80, and one of the things he noticed is that the data pins coming out of the chip are in seemingly random order: 4, 3, 5, 6, 2, 7, 0, 1. (And a +5V pin is stuck in the middle.) After careful study, he's come up with an explanation for this seemingly odd design. "The motivation behind splitting the data bus is to allow the chip to perform activities in parallel. For instance an instruction can be read from the data pins into the instruction logic at the same time that data is being copied between the ALU and registers.
[B]ecause the Z-80 splits the data bus into multiple segments, only four data lines run to the lower right corner of the chip. And because the Z-80 was very tight for space, running additional lines would be undesirable. Next, the BIT instructions use instruction bits 3, 4, and 5 to select a particular bit. This was motivated by the instruction structure the Z-80 inherited from the 8080. Finally, the Z-80's ALU requires direct access to instruction bits 3, 4, and 5 to select the particular data bit. Putting these factors together, data pins 3, 4, and 5 are constrained to be in the lower right corner of the chip next to the ALU. This forces the data pins to be out of sequence, and that's why the Z-80 has out-of-order data pins."
[B]ecause the Z-80 splits the data bus into multiple segments, only four data lines run to the lower right corner of the chip. And because the Z-80 was very tight for space, running additional lines would be undesirable. Next, the BIT instructions use instruction bits 3, 4, and 5 to select a particular bit. This was motivated by the instruction structure the Z-80 inherited from the 8080. Finally, the Z-80's ALU requires direct access to instruction bits 3, 4, and 5 to select the particular data bit. Putting these factors together, data pins 3, 4, and 5 are constrained to be in the lower right corner of the chip next to the ALU. This forces the data pins to be out of sequence, and that's why the Z-80 has out-of-order data pins."
There was a Z-80 in the C=128 , but it wasn't used.
There was virtually no CPM software adapted to the C=128
Typically 128s mostly were used in C=64 mode
If you're interested in Z80 operating systems, go look at CP/M (seriously: get an emulator, some tools, and write programs for it). It's a fascinating look into just how minimal you can make an operating system and still have something that's not just functional but which spawned, back in the day, a vast ecosystem of tools and software. You suddenly realise just how much fat there is in a modern system (and also why modern systems have all this fat).
It's not at all unusual for the 5v and 0v (Vcc and GND) lines to be in the middle of a DIP package (the Slashdot summary sort of implies it's an odd thing). It means the leads within the package are shorter for those lines, lowering parasitic inductance and capacitance for the power supply to the chip, generally you want the decoupling capacitors to be as close to the actual chip as possible so they can be as effective as possible as the power demands change. Putting the supply pins at opposite corners (like it's done on things like 14 pin 74-series standard logic) would very significantly lengthen the distance that the actual supply rails on the chip are from the decoupling capacitors.
Oolite: Elite-like game. For Mac, Linux and Windows
Also cost was a huge factor - the 6502 was significantly less expensive than the Z80s at the time.
And the 6502 gracefully entered the 16 bit field with 100% backward compatibility in the 65C816.
Sadly, too late to make a big dent as the 68000 was just around the corner, although Nintendo took
great advantage of it in their SNES. Franklin Electronic Publishers used the 6502 exclusively in
their early hand-held spell checkers.
I don't know about the 6502, but the Z80 takes 4 clockticks per (basic) instruction. IOW, it's a bit below 1 MIPS at 3.57MHz. The later R800, used in the MSX turbo-R, ran at 7MHz at took 1 clocktick per instruction, which gave it the "28MHz Z80 speed" it was sometimes quoted.
The 6502 takes 2 to 6 clocks for most instructions: 2 to fetch the instruction itself and the first byte of the operand, then additional cycles to fetch the rest of the operand, perform address generation if necessary, and fetch a value from memory. With fewer register-to-register opcodes, more operations have to use memory. But there are probably plenty of studies from the C64 vs. Speccy flamewars of how this plays out in practice.
Not only is it still manufactured, but it is still used. There is a good probability that your DVD burner has a Z80 in it running the show.
The Z80 is a great example of a 'limited' CISC design (not enough transistors to be complete CISC like say a Motorola 68000 or a DEC NVAX).
The 6502 is a great example of a 'limited' RISC design, and quite an efficient one. http://www.visual6502.org is still out there, and you can enjoy that yourself. I'm looking forward to the Z80 version, myself.
And you can build your own brand-new Z80 machine in the N8VEM system, if you'd like something a bit more satisfying than an emulator and a bit more reliable than an old Kaypro or TRS-80. (Heh, I have a pair of TRS-80 Model 4P's myself......). The Z80 is a great way to learn the fine art of computer engineering with a chip that is easy to understand and apply, with an OS that one person can fully understand and work on (whether that be CP/M or the, in my opinion at least, superior LS-DOS 6.3.1 OS). Both of these OS's are small enough that you can read the full source code in a single weekend, and three or four months of study will be enough to where you can pretty much fully understand it.
Because, regardless of what toolkits may be available these days, it really does boil down to electrons and machine language (or assembly language mnemonics). Get a good grasp of those basics, and you can learn anything in the computer engineering field. (Computer engineering is not computer science, and vice-versa.)