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
Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.
The Z-80 was a great chip and overall system design supported by very capable support peripheral chips in that family. The best part of working with it, is Zilog's Documentation, which was very well written and demonstrated the consistency of the entire product line (in terms of it's functional programming interfaces). There really is not any need to 'reverse engineer' the chip, everything you need to know is freely available already. I think this article and author means to say "Here are some plausible possible reasons behind some of these physical implementation decisions...".
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
Ahhh, those were the days. a whole CPU in a 40 pin DIP. you could actually do useful things with this mounted on an experimental breadboard. thanks for bringing back memories.
Not sure how sarcastic you're trying to be. I know nothing about chip design. I read the article and learned something. These are the type of articles that reflect what I believe slashdot is about. So it's something that I came here to learn about. There's no NSA/Snowden/loss of freedom/political drama/clickbait/ in the article, so there's no trolls. Win win.
Now if only there were more comments to add to the understanding.
Politics; n. : A religion whereby man is god.
Back in 1980 my parents got me a British ZX81 kit to assemble, with 1024 bytes of RAM. (I still have it buried in the closet along with my other antiques- AFAIK it still works.) It ran BASIC so slowly that you could actually read the code about as fast as it executed, so I was "forced" to learn assembly language. I was amazed by how fast it was- it ran a million operations in just a few seconds! (wow.) You had to start by writing a BASIC program:
10 REM AAAAAAAAAAAAAAAA
20 PRINT USR(16514)
Then you had to POKE each assembly instruction into the comment, starting at 16514 for the first "A". The comment line would slowly turn into "10 REM x&$bL;,$_)[vU7z#AAAAAAAA". The next line was 20 PRINT USR(16514) (printing out the return value from the BC register).
Saving any ZX81 program onto a cassette tape was excruciating- they recorded as several minutes of loud high-pitched screeching. Usually you needed to save them twice because it failed half the time. Then to load the program you had to cue the tape you had to find exactly where the start of the screeching was, rewind several seconds, play the tape, and only then could you hit enter on LOAD. (Otherwise LOAD got confused by the *click* noise when you pushed the play button on the tape player.)
You young people don't realize what an easy life you have.
The news what why it was that way.
And the Z80 was a major player in computing in the early personal computers before IBM PC. Even today it's still around in variants, and many have seen a variant of it in the Nintendo Gameboy. It was popular enough to render some clones as well, however they weren't always fully compatible, mostly on the undocumented instructions - which caused for example the Sinclair ZX80 to not work unless you had a real one.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It looks like the firing order for an 8 cylinder engine. I thought maybe the engineer tasked with that pin out was moonlighting in a garage somewhere.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
It's always refreshing to see stuff like this waft across the front page of /. every now and then - I wish there was a way to re-apply the "News For Nerds... Stuff That Matters" logo to top of the page only on stories like this.
(Pro-Tip: Please mod this "+1 Nostalgic" :) )
My father had built a Heathkit H89 computer built around a Z80. As a kid I earned money soldering together boards my father had designed that under software control would double the speed from 2 to 4MHz. The H89 actually had two CPUs since it was also a H19 terminal. While it didn't do color and was limited to text based graphics it was a nice machine. My father's computer had something like 4 floppy drives and a hard drive hooked up to it. It ran both CPM and HDOS which was the first microcomputer operating system with loadable device drivers.
Later in college we used the Z80 for our microprocessor design class. The Z80 was trivial to wire up and included such things as automatic DRAM refresh support.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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
Articles like this, makes me warm and fuzzy all over, probably because I'm an old geezer in comparison to kids of today, but I think it's very important for anyone serious about hardware development and/or software development to dive into the past once in a while, it's a great way to learn simplicity and how the hardware inside our relatively complicated devices of today really works.
/. back to the roots.
I'm a moderator of a major international electronics forum, and I don't have the number on just how many times the young generation feel completely lost when they're fresh out of school, trying to understand very complex structures. They either lack understanding of general electronics, or how the microprocessor works with different layers, ram, rom (especially embedded systems when they are working with complex IDE's with a maze of classes & libraries), they simply forget how the hardware works, and get to focus too much on programming.
I understand exactly that frustration, especially since this old geezer was lucky enough to grew up with basic home computers like the Commodore 64, Zx81 (Z80 cpu), Spectrum, Oric, Dragon 32, BBC etc. We often did our own hardware modifications, made fast I/O port load&save systems ourselves because we had a basic understanding of how the innards worked, and it really wasn't rocket science.
Sometimes it is relevant to take a step back in time (Like this article does, explaining some of the oddities with the Z80 processor), and spark interest in these old CPU's and their systems & possible uses even today. As an example, I have a HUGE stash of Micro-Controllers in my workshop, these are an absolute GEM to me. Why? Because they are very simple to work with. Like the good old Commodore 64 or ZX 81 - they don't have advanced hardware layers where you have to do special addressing to access certain memory areas or have to be kind to the operating system in order to write something to control your hardware (homemade or otherwise), it's as simple as writing a few pokes into memory...and you can turn on/off some external units such as relays, lights - or read on/off states from your sensors...maybe build your own satellite tracker the easy way, or control your homemade lawnmover unit.
And we still have VAST amounts of these MCU's unused all over the world, these are SUPER USEFUL (if you didn't get the above, think standalone apps...like each MCU was an app for a specific task). Many of these CPU's (MCU usually comes with internal memory/Ram/Rom/Flash/ and the most important part...an I/O) ready to use, just program it...and watch it go. If the kids of today understood this, they'd have a BLAST programming these (just watch the maker society with their modern versions...Arduino etc.) and the sky's the limit.
More articles like these thanks, brings
What this world is coming to - is for you and me to decide.
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.