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."

Comments

C=128

[rossdee]

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

Re:C=128

[Ihlosi]

There was a Z-80 in the C=128 , but it wasn't used.

Yes, I found this part of the article amusing too.

C128s were cobbled together from too many different parts. And they appeared when the 8-bit generation was already on its way out.

However, the C128 mode had its uses. The BASIC was had lots of additional features (commands for music, graphics, sprites), and it had a built-in sprite editor. If you didn't know the C64 inside out and could do these things in assembly (blindfolded), the C128 mode gave you much more access to the machines capabilites. Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.

Re:C=128

[scsirob]

Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.

Really? Ever heard of MSX? See: http://en.wikipedia.org/wiki/M...
It came with graphics, sprites (TMS9918/9929) and was a standard design carried by several manufacturers.

Re:C=128

[MindPrison]

Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.

Really? Ever heard of MSX? See: http://en.wikipedia.org/wiki/M... It came with graphics, sprites (TMS9918/9929) and was a standard design carried by several manufacturers.

Ah, MSX... weirdest computers in history. The Yamaha MSX computer was an awesome music computer with built in FM synthesis, and then you had the vastly different Spectravideo MSX, it was fully compliant with the MSX standard...but it's just that, not everyone was compliant - every MSX computer seemed to be a special variant of itself, something that confused me something so fierce back in the days, I even had a Memotech MSX, weird WEIRD computer.

The games on the MSX computers wasn't mind blowing, nowhere near the commodore 64 games, it simply lacked the awesome sound capabilities of the 64. They had a wider color range though.

I remember the war between us Commodore users (65xx type processors) vs the Z80 series, yes - the Z80 was a far superior processor in many ways and sometimes I wished we had that processor just for the extended registers alone, not to mention that the speed was 4 mhz instead of our meager 0.97mhz (could be doubled if you turned off the screen). But the hardware sprites & scrolling is what beat the living bejeezus outta the other competing products.

And I nearly cried snot when the Commodore 65 didn't make it. It was a super-cool Commodore 64 with beefed up hardware, higher resolution, stereo SID sound (6 channels!) of pure ring-modulated goodness.

Ah, I'll go stare at my stash of Z0840004PSC, 27xxxx's and the rest of the Chip Pron in my vast land of NOS components...aaaahh.. :)

Re:C=128

[Sun]

And then Commodore went on to (half inherit, half design) the Amiga. Maybe "cobbled together" is too harsh for it, but still. Floppy controller that can decide, per track, whether to work in MFM or RLL (but not read a single sector, mind you), more DMA channels than the CPU can handle, and a display processor with a built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor.

I loved it, but the Amiga gave the impression that it was designed by engineers that couldn't make up their mind on what choice to make, so they created hardware that would offload all decisions to software.

One last anecdote. Many have heard of the famous "Guru meditation". What only Amiga users know is that you knew one was coming because the power led would blink three times. Yes, the power led was software controlled, making the Amiga the first ever computer that could play dead.

Shachar

Re:C=128

[Blaskowicz]

Amstrad CPC6128 was very successful, especially popular in Europe - cheap price as a dedicated monitor was always bundled and a floppy drive was integrated, whereas other stuff like C64, Spectrum etc. tended to be used with a cassette drive and on the television.

It's not a killer machine, though. Rudimentary sound and no sprites - but it was colorful, with 16 colors out of a 32 color palette (much better than 8 fixed colors on some of the 8bit crap :p)
Then it did have an upgrade that made it a "killer 8-bit"! These were the ill-fated CPC Plus and GX-4000 console. Typical fate of an upgraded model and a failed, unsupported console. It didn't help that the year was 1990, well into the times of Amiga 500 and Megadrive/Genesis and NES utterly dominating the game consoles.

Re: C=128

[Anonymous Coward]

Actually Z-80 vs 65xx is still a valid debate. The 65xx was much more capable at lower clocks. A good example being the "Woz Machine" floppy controller compared with many Z-80 boxes needing a second 6mhz Z-80 to run their floppy drives.

Re:C=128

[oldhack]

Speed of Z80 at 4Mhz was comparable to that of 65xx at 1Mhz - many of Z80 instructions took more cycles to execute than those of 65xx. Sort of CISC-vs.-RISC before the phrase/concepts were invented.

Re:C=128

[Anonymous Coward]

What only Amiga users know is that the only way the power led can be controlled is by enabling/disabling the low-pass filter on the audio output since the status of the enable signal is indicated by dimming the led. It's not possible to turn it off completely to simulate the computer being dead.
It's controlled by bit 1 of ciaa->pra. (Address $BFE001)

It's also possible to read a single sector, but that would require starting the DMA on a timer so it's more cumbersome than reading the entire track and it's not guaranteed to be faster since it's a spinning media. The memory is there so reading a single sector is just pointless. As for MFM/RLL encoding the floppy controller does neither, it reads the raw bits. The order of the bits is interleaved on Amiga formatted disks to allow for blitter accelerated MFM-(de)coding.

Don't trust anecdotes, the developer guides are available online.

Re:C=128

[Anonymous Coward]

The Z80 was used every time the C128 was turned on. It was added specifically to work around a compatibility issue with the C64 and one single, solitary, cartridge (Magic Voice) for the C64. To make it work, Bill Herd added the Z80, It would start (at address 0x0000), run a handful of instructions that initialised the C128 hardware, and then started the 8502 proper. (The Spectacular Rise And Fall Of Commodore, pg. 368)

Re:C=128

[AmiMoJo]

The 6502 may have run at a little under 1MHz, but it was efficient. Most instructions were one or two cycles and they did a lot. It's actually a really fun processor to write for because it's both a nice architecture and very challenging to get the most from.

Re:C=128

[NewtonsLaw]

The problem with the 6502 was that if you were writing code for someone else's environment then your use of Page 0 (which many of the index-based instructions used intensively) was restricted because the OS often took up most of that space.

If you were writing code that was totally stand-alone (ie: no bios or OS to worry about) then the 6502 environment was *very* nice and could perform incredibly well. However, if you were writing code that sat atop a BIOS/OS layer then the Z80 was just so much simpler and less frustrating to code for.

Speed-wise, the Ohio Superboard (6502) would roundly trounce a TRS80 Model 1 in single-precision floating point math run through the relevant BASIC interpeters and ultimately and tightly coded 6502 code would also trounce the same written for the Z80 -- unless Page0 was already used up on the 6502 system.

Re:C=128

[neonsignal]

The problem with the 6502 was that if you were writing code for someone else's environment then your use of Page 0 (which many of the index-based instructions used intensively) was restricted because the OS often took up most of that space.

Yes, there was a mindset problem when programming the 6502. In hindsight, page 0 RAM should have been treated as a working space register set, whereas at the time it was treated mostly as a fast RAM littered with persistent variables.

Re:C=128

[Anonymous Coward]

Z80 had to be 4Mhz because all of its instructions take 20-30 cycles to do anything.
6502 instructions are 2 to 7 cycles.

Re:C=128

[ChrisMaple]

Most Z80 code was written to be compatible with the 8080. As a result, the second register set wasn't used. Floating point math using the second register set for temporary variables made possible a substantial speedup.

If the 6502 and Z80 waveforms for various instructions are examined, it quickly becomes apparent that the Z80 effectively divided its clock by 2 before using it. This is why, for the technology available in any particular year, they had comparable performance but the Z80 used twice as many clock cycles.

The 6502 was a tremendously clever design for making effective use of a small number of transistors. The Z80, striving to be a superset of the 8080, was also a clever and powerful design for its time.

Re:C=128

[ChrisMaple]

Z80:
8 bit register adds, 4 clocks (equivalent to 2 6502 clocks)
16 bit register adds, 11 clocks, with carry, 15 clocks.
The slowest instructions (23 clocks) are obscure instructions like swap register with memory, or indirect indexed addressing. These were limited by the number of memory accesses needed.

I've built hardware and done a lot of assembly level programming on both the Z80 and 6502. There is simply no substantial speed difference between them for the level of technology available in any particular year.

Re:C=128

[Megane]

A lot of people never heard of MSX because by the time it came out, the US was already going 16-bit with PC, Mac, Amiga, and Atari ST, with the C64 firmly entrenched in what was left of the cheapie 8-bit market. And the TMS9918 was pretty weak, being the same graphics chip used in the TI99/4A and Colecovision. (Coleco used the 9928, which had a different video output.) Later versions of MSX video chips were better, but by then it was even more outclassed by 16-bit systems. (The Sega Genesis graphics were also an extension of the 9918.)

Re:C=128

[Anonymous Coward]

Still, MSX and especially MSX-2 were very popular in the Netherlands, Spain, Brazil and Japan. I have fond memories of playing Konami's original Metal Gear 2, Solid Snake on it. I still play it sometimes on openMSX. It is quite possibly the best 8-bit game ever made. Running on a normal Z80A..

Re:C=128

[Enter the Shoggoth]

built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor

I'm curious... any more detail on this?

Re:C=128

[Anonymous Coward]

The Z80 was essential for the boot process, detecting expansions in the cartridge slot before handing off to the 8502 in either c64 or 128 mode. The engineers had a lot of trouble with that step before deciding on putting in the z80.

Besides, CPM was still quite popular back then and plenty of people used it on the 128, which was a cost-effective CPM system.

Re:C=128

[Anonymous Coward]

" every MSX computer seemed to be a special variant of itself,"

Nonsense!
Most of these variants were just implementing the standards and most were perfectly compatible. They all implemented a standardized minimum core system that was expanded upon, depending on the model. So the standards dictated a minimum amount of RAM or VRAM, but a system could provide more than that.
What probably confuses you is that there was a lot of peripheral stuff, but that was mostly standardized too.
The FM chip you talk of has been built into some MSX'es but could also be bought as a cartrige add-on.
In fact, there were two standards, MSX-AUDIO and MSX-MUSIC. Both of these revolve around a 2-op yamaha fm chip. The first one having higher quality registers, some obscure AM settings (for phoneme generation) and one channel of sampling. This was designed for more serious applications, but was too expensive for casual users. The second one (in the guise of, for instance, the Panasonic FM-PAC) was the slightly cheaper and simpler music-only chip that turned out to be the more popular option.
Besides those there was the konami SCC, which was a custom chip that came on konami cartriges and did 5 channel wavetable. This one was not part of the MSX standard but was simply included in konamigames, which tended to come on cartriges. Some pretty chiptunes came out of that one. The music trackers written by konami were pretty amazing.
MSX2 had much better graphics compared to the C64 (check out Metal Gear 2:Solid Snake) and with any of the sound-options also had much better sound.
The MSX2 standard was designed with gen-locking in mind so it was easy to build a model that could superimpose graphics on video. I think at least 3 companies released a version that could do this.
We had memory mappers as a standard, could expand memory through cartriges.
We had MSX-DOS, for crying out loud (a honest to god MS-DOS port).
We had real 3.5" diskdrives.
We even had SCSI cartriges that alowed for hard drives to be used.
There was tons of stuff.
BTW, MSX systems run at 3.579..MHz.
And had hardware sprites.
And the MSX2 could do hardware scrolling (sortof).

Meanwhile, on the software side, it was a de facto standard for many japanese game developers.
A lot of long running game series started out on MSX. We had lots of stuff that simply never got made for US or british architectures.

In reality the MSX standards were way ahead of their time when it comes to architecture platforms.
MSX was not weird. It was just misunderstood.

Re:C=128

[Anonymous Coward]

"Speed of Z80 at 4Mhz was comparable to that of 65xx at 1Mhz "

I guess this is difficult to quantify.
The Z80 had some horribl long instructions. I think there is stuff in there that takes 20+ cycles to execyte.
Other things could be done pretty fast.
Also, the z80 had a second secret set of registers that alows you to do cool interleaving tricks.
So, at least from the z80 side of things it kind of depends on what you're doing with it.
But generally the latencies were more that you'd expect.

Re:C=128

[Anonymous Coward]

There are no one cycle instructions on the 6502. The shortest time to execute one instruction is 2 cycles vs. 4 on the Z80.

Re:C=128

[Anonymous Coward]

It is more like a factor of 2-3 times at equal clock frequency (i.e. a 4 MHz Z80 is comparable to a ~1.3-2 MHz 6502), depending on what kind of code is being executed. 4:1 is pretty much the worst case. For operations that mostly just require memory throughput or fast indexed table access, the 6502 is relatively better, while the Z80 has the advantage of more registers and relying less on memory variables. Also, for certain types of memory operations, like simple copying, the Z80 has specialized instructions that are "only" twice as slow as the best 6502 equivalent (fully unrolled loop) at the same clock frequency, and the 16-bit stack pointer can be abused for fast sequential table reading.

Re:C=128

[Anonymous Coward]

On the Amiga 2000 the LED dims. On the Amiga 500 it turns completely off.

Re:C=128

[gadg3ts]

Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.

Then there was this: http://en.wikipedia.org/wiki/S...

Re:C=128

[jeremyp]

In later models, i.e. well after the 6502 was obsolete for general purpose computers, there was an 8 register that you could set to change which page was regarded as zero page. If that had been available from the start, it would have saved me a lot of time looking for locations that didn't zap the MS Basic interpreter on our Commodore PET. I seem to remember that the floating point accumulators were considered the best bet.

Re:C=128

[matfud]

If I remember correctly changing display modes mid scan was often done so that workbench could do things like display HAM images in windows.
I think the OP may be talking about the "copper" which was a FSM with three states (MOVE, WAIT and SKIP) and a list of instructions to be processed when screen timing events occur. All three were used though and it was used for many things such as sprites and the above mentioned screen mode changes.

MOVE (put data in pretty much any register such as changing the location of a sprite to allow the sprite to be reused in another location)
WAIT (wait for a screen event such as a pixel position.)
SKIP (skip the next instruction in the copper list)
An interesting thing that could also be done in change the screen mode so that the top part of the screen displays the game and the bottom in a different mode (colour deapth/resolution) to display the game controls

Maybe I missunderstood the OP?

Re:C=128

[Sun]

You got a partial answer. If "SKIP" was ever used, I'm interested to know by whom. I only know of a single example, which was EXTREMELY special case.

The commands:
MOVE: move immediate value into copper register. These included such actions as where in memory the video memory was (i.e. - where to fetch the picture from), what is the palette, video resolution, where on screen the video fetch starts and where it ends and many others.
WAIT: wait for the screen update to reach a certain point. There was a mask argument which allowed you to have don't cares on some of the bits.

These two was how most of the programs worked. From simply displaying a static image (the memory fetch registers had to be reset each frame), through "copper waves" (things like telling the hardware to start displaying the image in a different timing each line, so that a straight in memory was a wave on screen), to what matfud erroneously called "display HAM in a window" (it took several scan lines for the copper to completely replace the display mode, so you couldn't display two modes side by side, but you could display them one above the other). It also allowed "virtual sprites" by reusing the same 8 hardware display sprites for different things in the same frame, so long as they were not in the same line.

The third command, skip, had the same arguments as WAIT. Instead of waiting, however, it skipped the next command if the condition was not met. Add to that copper registers that restarted the copper program if written to, and the fact you could load two start addresses and switch between them, and you get the ability to perform a loop.

Back in 1994 there was a Mac "emulator" called A-Max. It was not really an emulator. It loaded Mac ROMs into the ram, patch some hardware related entry points so that it would work on the Amiga, load a copper instruction that caused the Amiga display to act like a Mac black & white display, and simply executed the ROMs. As a result, a 7.2Mhz Amiga 500 ran programs written for the 8Mhz Mac at 120% speed.

One (rather minor) problem they had was that while the display content was showing correct colors, the Amiga was hard-coded to use color 0 for the overscan. As a result, the overscan, black on the Mac, was white on A-Max. Around 1993 I figured a way to resolve this, using the SKIP command and the loop method mentioned above. I assumed that if I figured it, it was obvious, and didn't do anything with it. Around a year or two later, A-Max released a version which had text similar to the following:
Thank you (don't remember the name) for providing us with a method to give a black overscan without writing a huge copper program. As thanks, we've given him a free version of A-Max.

Which caused me to kick myself no ends, and never assume my ideas aren't innovative.

As far as I know, there was no other use for the skip command (which might explain why the A-Max guys never thought about it themselves).

Shachar

Re:C=128

[Sun]

If I remember correctly changing display modes mid scan was often done so that workbench could do things like display HAM images in windows.

You misremember. The Copper code to change display modes took several scan-lines to run. Having a window with different display mode was impossible. You could, and did, have a UI construct called a "screen", which had its own display mode. You could drag a screen down and see another screen behind it.

All three were used though and it was used for many things such as sprites and the above mentioned screen mode changes.

AFAIK, none of those utilized SKIP. They were all based on WAIT and MOVE. If you know differently, please provide further details.

Maybe I missunderstood the OP?

I don't think so. I am, however, fairly sure you mis-remember.

Shachar

Re:C=128

[Sun]

What only Amiga users know is that the only way the power led can be controlled is by enabling/disabling the low-pass filter on the audio output since the status of the enable signal is indicated by dimming the led. It's not possible to turn it off completely to simulate the computer being dead.

The original Amiga 500, including the early Kickstart 1.3 ones, would actually completely turn off the LED. If you don't believe me, you are welcome to visit me. I still have my original machine in (more or less) working order.

You are correct that later models would not turn it off completely, but rather only dim it. I only remembered that fact after I hit Send, and thought no one will be anal enough to demand a clarification.

It's also possible to read a single sector, but that would require starting the DMA on a timer so it's more cumbersome than reading the entire track and it's not guaranteed to be faster since it's a spinning media.

In other words, the hardware does not support it.

As for MFM/RLL encoding the floppy controller does neither, it reads the raw bits. The order of the bits is interleaved on Amiga formatted disks to allow for blitter accelerated MFM-(de)coding.

That is one point I am not as sure about. It goes against what I remember, but I might be wrong on that point. However:

Don't trust anecdotes, the developer guides are available online.

Do provide links. Please. I failed to find them, and my black 2.04 books are buried in some box from my latest moving day (if I had not thrown them out).

Shachar

Re:C=128

[kheldan]

It wasn't an all-in-one-minus-monitor design like a C64 or C128, it was an S100/IEEE696-bus system, but Morrow Designs produced a Z80 processor board that had memory management hardware on it for more than 64K of system memory. Of course there was no operating system that supported it, so it wasn't very useful. Personally, I wrote a RAMdisk driver around it that worked in CP/M 2.2, and had a 128kB RAMdrive.

Re:C=128

[matfud]

SKIP does seem a bit limited if it is only one entry that it skips.
I think you either overran the time to execte so events had already occured or you finished early and waited for the next frame/whatever.

So how did workbench give provide windows containing HAM8 images or where they only full screen windows with a menu bar? (too long ago and I do not remember). I was using PC's back then but I was most impressed with a flatmates Amiga. Shame it struggled to run Elite :)

Re:C=128

[Anonymous Coward]

There was the Sam Coupé.

Re:C=128

[tlhIngan]

If the 6502 and Z80 waveforms for various instructions are examined, it quickly becomes apparent that the Z80 effectively divided its clock by 2 before using it. This is why, for the technology available in any particular year, they had comparable performance but the Z80 used twice as many clock cycles.

Actually, the problem was the ALU of the Z-80 was only 4 bits wide. So processing an 8 bit operand required two trips through the ALU, thus incurring twice the number of clocks or half the effective clock rate..

The 6502 and others had an 8-bit ALU which meant they could do an 8-bit operand in half the clocks.

Re:C=128

[bjb]

Do provide links. Please. I failed to find them, and my black 2.04 books are buried in some box from my latest moving day (if I had not thrown them out).

If you want a 1.3 ROM Kernel Manual, you'll have to pull it out from under my kid's car seat. Just the right size and thickness to correct the seat angle :-)

Always wonder if someone will ever catch a glimpse of that and know what the heck it is...

Re:C=128

[david_thornley]

Some Z80 instructions could take far more than 20 cycles, such as LDIR (which copied an arbitrary amount of memory from one arbitrary place to another). Most of them were 4 clocks for the first byte and 3 for each succeeding memory access. The Z80 had some additional capabilities that were wedged into the 8080 instruction set, and required long instructions. When I was building the fastest 64-bit multiply I could, I didn't use the index registers (IX, IY), since I could always get better performance with slightly more complexity by avoiding them. The second set of registers was very useful, though.

My estimate was that a Z80 did approximately half of what a 6502 did per clock cycle.

Re:C=128

[Sun]

You can keep your ancient 1.3 books. I have the shining new 2.04 manuals in one of my unpacked boxes here (or maybe it is in storage, next to my actual Amiga?)

Shachar

Re:C=128

[Sun]

Menus on the Amiga were bound to the screen, not the window. You are probably remembering a full-window.

Shachar

Re:C=128

[tmh - The Mad Hacker]

There was virtually no CPM software adapted to the C=128

I wasn't aware that it needed to be adapted. When I think of CP/M software I don't think of fancy programs highly customized for specific hardware -- if it had a keyboard and at least an 80x24 screen, it was happy! Being able to run CP/M software was one of the main reasons I got a C128, and I did so for several years with no more adaptation than setting up book scripts on the floppy to automatically load everything the way I wanted.

Re:C=128

[matfud]

Quite possibly :)

The story

[Anonymous Coward]

That's an interesting anecdote, but is there more of a story here?

This is definitely for nerds, but I'm having trouble understanding the news part.

I'll be the first to suggest i don't know much about Z80 architecture. So, maybe someone informed on the issue could fill us in, here.

Re:The story

[Z00L00K]

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.

Re:The story

[Dahamma]

It's totally non-news.

It's basically a trivial fact that could probably have been answered just by ASKING anyone who actually knew about the details of the Z-80 development, but some dude decided to puzzle it out himself, slow /. news day, and bam, here's the article.

Hold on... I just had an epiphany about why manhole covers are round - give me a sec, I think I'm going to submit it...

Re:The story

[TheRealHocusLocus]

Hold on... I just had an epiphany about why manhole covers are round - give me a sec, I think I'm going to submit it...

They could also be pointy or rounded equilateral triangles, leading to an interesting and annoying and dangerous pointy down dangle wedgie situation. But what is most annoying is that many sealed round lids have no lifter points on the underside, what were they thinking, so if it flips over before it settles into the ring you are reduced to prying opposite edges while wishing for a simple clamping magnet.

Why didn't they just ask Federico Faggin?

[Anonymous Coward]

Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.

Re:Why didn't they just ask Federico Faggin?

[Lord Apathy]

This is what I came in here to say. They guy who designed the chip is still alive. Just shoot him a email, phone call, or smoke signals and just ask him.

I'm going to go out on a limb here and say there is probably a logical reason behind the arrangement and not some conspiracy or something.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

Perhaps their IT department blocks Googling for Faggin.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

If you were driving around in an unfamiliar town and you didn't have GPS, would you stop at a gas station and ask for directions?

Yes, you could do that, but everyone knows that that just isn't done.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.

That eliminates the opportunity to show off for your friends.

Re:Why didn't they just ask Federico Faggin?

[Alioth]

The Z80 is still manufactured in classic form. It may be considered a trade secret and Faggin might not be at liberty to divulge anything about the inner workings of the chip without you signing an NDA.

Re:Why didn't they just ask Federico Faggin?

[Snotnose]

I'm going to go out on a limb and guess that, due to how primitive the tools were back then, when they got a signal to a pin they celebrated without worrying which pin it came out on.

Re:Why didn't they just ask Federico Faggin?

[cold fjord]

Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.

Maybe its time for:

Interviews: Federico Faggin Answers Your Questions
Last week you had the chance to pose questions to Federico Faggin .... father of Intel's 4004 43 years ago...

The man is very accomplished and has an amazing history.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

But then you at least tried. Considering that bloggers these days consider themself journalists it is not uneasonable to expect them to do some really really basic research (but had this been a "real" news article, it would like be just as unresearched)

Information certainly wan't to be free. and we get what we pay for it.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

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.)

Re:Why didn't they just ask Federico Faggin?

[ChrisMaple]

With an optical microscope you could actually look at a Z80 die, see the transistors (all 8500 of them) and conductors, and write up a schematic of the chip. Considered a trade secret or not, the Z80 is known and completely defined. Nonetheless, it's possible that you're right and contracts may prevent him from talking about stuff that's no longer secret.

Re:Why didn't they just ask Federico Faggin?

[matfud]

If you had read the article you would know that it is part of an effort to deconstruct the Z80 using optical information and yes they can see all the transistors although identifying them and thier function can be tricky as they were layed out by hand to minimise the space needed.

I have no connection to the project but reading some of the pages on the site are quite interesting if you are electronics minded.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

He was presenting not long ago at my school:
http://ibc.chapman.edu/Mediasite/Play/0e85bffe0c8646488c679301a15184c01d

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

He's not only alive, but very accessible and a nice guy.

Re:Why didn't they just ask Federico Faggin?

[Anonymous Coward]

Better run it past Masatoshi Shima as well (Z-80 Project Leader).

Mysteries of the past

[Anonymous Coward]

When I grow up I also want to be an archaelogist.

Why is it necessary to reverse engineer this?

[Anonymous Coward]

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.

Re:Why is it necessary to reverse engineer this?

[cnettel]

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.

Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have. Some of the lessons learned regarding being frugal make sense, but you will also learn a lot of tricks that are either directly counter-productive, or at the very least steal your attention from what you should be concerned with, even in those very cases where you are really focusing on performance and power efficiency (in addition to the myriad of valid cases where developer productivity is simply more important than optimality).

It used to be that you couldn't pre-calculate everything since you didn't have enough storage. These days, you shouldn't pre-calculate everything since it will actually be cheaper to do it again rather than risk hitting main memory with a tremendous amount of random accesses, or even worse, swap. Up to some quite serious size data sets a flat data structure with fully sequential accesses can turn out to be preferable to something like a binary tree with multi-level indirections. (Now, the insane amount of references even for what should be a flat array in anything from Java to Python is one reason for why even very good JITs fall short of well-written C, Fortran, or C++.)

Re:Why is it necessary to reverse engineer this?

[Z00L00K]

Add to it the great book Programming the Z80 by Rodnay Zaks.

That book is one of the best books I have encountered when it comes to how to utilize a device.

Personally I think that it should be in the collection of books even if you don't aim to program specifically for the Z80 because it explains a lot of general CPU architecture and logic as well.

Re:Why is it necessary to reverse engineer this?

[oldhack]

"Only" 64KB? Kids these days...

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

True power is being able to engrave your program on stone tablets, then convincing everyone that they're actually laws from God.

Being able to program a Z80 may give you a wider perspective on programming, but beginning CS students need problem-solving basics like algorithms and design patterns. Saying that it should be taught first is like saying that kids need to learn Latin before they learn English.

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

The Z-80 was a great chip

*smirk*

The best part of working with it, is Zilog's Documentation

That still has misleading images that shows an incorrect function for the rotate instructions due to lazy copy-pasting.

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have.

All those benefits are true even up to 32-bit controllers like the 68000, except that the branch there actually is free if it is already loaded in the pipeline.

The only thing the Z80 had going for it compared to competing 8-bit controllers was that it had plenty of CPU-registers. Other than that it is pretty crappy due to the ALU being 4-bit and the instructions are looped internally to simulate 8-bit functionality. That's why even the nop-instruction takes 4 cycles. (5 if you count the DRAM refresh.)

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

Your metaphor would hold if English were a higher language that is compiled to a Romance language. Machine code is still around and you can't understand a compiler/interpreter without understanding how the machine works. And to understand how well an algorithm performs, you need to understand the machine.

Re:Why is it necessary to reverse engineer this?

[Earthquake Retrofit]

"Back on Earth, I used to go to a little tavern called the Z-80 Club. Programmers from the nearby industrial park usually gathered there after work. A few students like myself were tolerated, but expected to keep out of the way. One guy always came in at 4:30. He looks about 40 years old with long hair and clean shaven. He'd walk in and be treated like he owned the place and always sit the same little table in the corner. 'Who's he?' I asked after noticing all the deference people showed him. 'Assembly programmer.' is all they would say as if that explained it."

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

As someone who has programmed a fair amount of Z80 assembly (And enough of it cycle timed to know the instruction timings by heart, even for a couple of undocumented instructions used to do byte access to the index registers.) I consider your description as inaccurate as the Zilog manual.
I'm not clean shaven at all.

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

Agree, would be nice if people could code for speed and efficiency.

Re:Why is it necessary to reverse engineer this?

[ChrisMaple]

While we're at it, all undergraduates should only be allowed to submit programs on punch cards, and have to wait 3 days to see if their program compiled and ran. And walk to class barefoot in the snow.

Re:Why is it necessary to reverse engineer this?

[Euler]

I think it may be somewhat daunting for a first-year student to go through the learning curve of what would effectively be debugging and optimizing code for an embedded platform... But it needs to be threaded in every CS course how to write code that is appropriate for the given application: speed/code/memory trade-offs and how to avoid code that blocks inappropriately, how to write programs that correctly work with the OS in terms of yielding, using timers, and such. Also, just calling the math library routines isn't the answer in many cases. CS grads should be able to demonstrate how to write their own math functions optimized for special application domains such as fixed-point integer math, decimal formats, interpolation, approximating trig functions, etc.

I personally feel like computer hardware has become incredibly powerful, but the user experience is more or less constant as programmers don't see the value in tuning applications to be as responsive as possible. On the other hand, that can often be due to outside pressure from non-programmers to always add "just one little feature, this won't add much overhead, right?"

Re:Why is it necessary to reverse engineer this?

[Euler]

I wish I could have 64KiB on the platform I work with...

Re:Why is it necessary to reverse engineer this?

[khallow]

How about from the currently esoteric point of view of rebuilding human society from scratch?

The Z-80 is one of a few chips that has the unusual feature that it is both simple enough to be built out of vacuum tubes or crude handmade integrated circuits (for example, you would need somewhere in the neighborhood of 5k to 10k tubes, complex but not impossible for a small machine shop) yet barely complex enough that you can run a simple version of Linux on it (I gather Linux hasn't yet been ported, but there are apparently people working on it).

The Z-80 design creates a hardware-side pathway for bootstrapping computer technology from vacuum tubes and transistors to modern software tools and languages. Reverse engineering the design might at some future point put considerable computation power in the hands of a desperate society.

Re: Why is it necessary to reverse engineer this?

[Anonymous Coward]

0h, how often have I been dismayed by newer programmers who have no sense about how they might use resources and have no concept about how their software would not scale to larger loads? Having had to deal with the severe memory limits and slow clock speeds of those old 8-bit machines was a lesson that has kept on giving to me over the years as a programmer.

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

Today it takes more CPU cycles to render some webpages than it did to play through an entire game of SNES Megaman X.

Re:Why is it necessary to reverse engineer this?

[chuckugly]

For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.

With a cache miss costing 200 cycles (more or less) and a trip to L2 being more expensive than computing a square root, our choices with regard to memory layout are possibly MORE crucial now to getting decent economy and performance out of the machines we have today.

Re:Why is it necessary to reverse engineer this?

[Anonymous Coward]

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).

Great docs, but not perfect. There were a number of reasonably well-known undocumented opcodes and behaviours (and some less so) that weren't included, though most are documented online now (give or take some flag weirdness on the BIT-related instructions). For example the LD IXh,... and related instructions (DD 2E d if I recall - can't be bothered googling), and what happens to the upper address lines during IN/OUT instructions (it echoes the A register, which was used in some computers).

Definitely agree that first years should study this stuff! I was rather obsessed with the Z80 for a long time - even wrote an emulator for my favourite 8-bit, emulating the Z80 using X86 assembly code - and learnt a lot more from this than I did in some courses allegedly teaching CPU architecture.

Re:Why is it necessary to reverse engineer this?

[matfud]

With programs generally being much much larger many such optimisations can just be lost in the noise. In some domains it is still useful but even more difficult than it was in times gone by.
Pipelining/OOE/register renaming and the multitude of processors with the same IS but remarkably different implementations, cache sizes/associativity/memory, memory size and connectivity
How many cores per CPU and how do they share those caches and memory buses.
How many independent memory banks per processor/chip (can change the cache miss time)
Memory architectre and or federated levels of connectivity (on high processor # manchines)
Operating systems can make it nigh on impossible to predict cache hits/misses as they premptively trash all your cache local code)

Just trying to optimize on modern proessors and OS's is stupidly difficult even if there were not so many variants. Still there can be significant gains sometimes (although that tends to be on small timescales relative to the OS task time. Sometime it is better to use performance libs and hope that whoever wrote them did it well :)

Re:Why is it necessary to reverse engineer this?

[chuckugly]

I'm not talking about hand tuned assembly, I'm talking about being aware of your data layout and what data is hot, accessed together, and so on. Those things ARE a big deal and are commonly doable, even if they are commonly ignored. The famous case where Bjarne S had an associate demo a simple random data insertion/random deletion using a vector vs a list is simple but instructive.

Older systems and complexity theory might favor the list, but the vector beat it badly on modern hardware simply because the hot data is all together in a vector.

Re:Why is it necessary to reverse engineer this?

[matfud]

I am not disagreeing with you but some of the things I pointed out above are varibles with respect to harware and most of them DO affect memory locality. If you make an assmption that x parts of data are localy cached you can be truely wrong when run on a compatable chip with a different cache layout or even the same chip but with a different offset that is only partialy aligned with the cache.

Some algorithms in general tend to keep the data used close to gether and they may benifit. Some algorihms uses data in chunks scattered all over the place but the chunks are particularly freindly for the system and they work well (keeping it cahched well).

But as I said it is remarkably hard to do those kinds of optimisation without a particular system to run on.

Re:Why is it necessary to reverse engineer this?

[chuckugly]

Depends on the breadth of systems being targeted. If we exclude exotics (which have their own very vertical software and optimizations) it's really remarkable how uniform current platforms are. Everything from the ARM in a tablet to the 16 core desktop will have a pre-fetcher, multilevel cache, and a huge cost for missing. Simple things like grouping the frequently modified data together in a single allocation (like std:::vector) and then unifying those into more complex data structures by indexing into those vectors (maybe) can yield huge speedups across a wide range of hardware.

Even the 2000 core GPU in the same desktop will have similar concerns, even if not identical, and will often benefit from the same sort of thinking. As always, code and measure. People who have done so will tell you, it can be done, and it's not really hard.

As an exercise, name the systems where arranging data to not sit across a 64 byte boundary would be a horrible thing. Odds are if you're realistically targeting such a platform, being general purpose isn't a big deal.

Re:Why is it necessary to reverse engineer this?

[matfud]

When your data and or instructions are not aligned on cache boundries and/or not limited by them (4k seems pretty standard for x86 and x64 3rd level caches but the processor may have different ideas about how that is segmented for L2 and L1) then you can cause cache thrashing by trying to tune for those specific variables. (your can cause the same by not tuning for them)

You say that it is remarkable how uniform current platforms are? I am interested as to why you think that as even on just x86 and x64 there are huge differences.

Anything "exotic" excluded.
chuckugly I like to learn :)
I would like to hear why you think that. I know you can boost some tight loops by many factors if you can get then in the L1, L2, L3 cache I may learn something. For larger scale dataprocessing it can be very tricky to keep the instructions in a cache page with regularly changing data (used in small blocks) also in the cache.

And no it is not easy and never has been. It can be remarkably hard on anything other that a micro-optimisation

 

Re:Why is it necessary to reverse engineer this?

[chuckugly]

On most current architectures a cache line is 64 bytes or a small multiple of 64 bytes, not 4K, and the CPU will almost always have a prefetcher that will try to optimize sequential accesses. Here is a pretty accessible rundown on some of the things a person can do very easily.

Re:Speaking of anonymous

[Anonymous Coward]

They have to throttle users who don't log in and they have to stick a captcha in their face too. Otherwise the entire site is overrun with GNAA posts or, worse, rants by APK. I'm posting this anonymously - but I am logged in. So there is no captcha, but there is throttling. I know I can post two items like this back to back, but then I do get the "wait a bit" message.

i remember

[acdc_rules]

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.

Re:i remember

[Anonymous Coward]

Neat thing is that you can still do that today. Even ARM processors are made in PDIP, for some reason.

Re:i remember

[segin]

Here's an ARM Cortex-M0 in DIP.

Re:i remember

[Euler]

While you can still buy a lot of embedded processors in DIP format, I haven't considered it very much - but yes, those were the days. Now you can just buy reasonable micros on affordable eval boards or other very simple boards with plenty of wire-wrap headers or solder points. You can cut a lot of the mundane work like breadboarding a voltage regulator, memory, osc, serial transceiver, etc.

Re:i remember

[Megane]

Even though most of them aren't DIP anymore, you can do a lot more useful things with modern microcontrollers because they don't waste most of their pins on an address and data bus.

Re:i remember

[Nethead]

Agree! Though I was a sixer, I miss those days. Wire wrap board, some '138s and JEDIC RAM. Put a 6522 (or 8255? in your case), maybe a 6551 and you have a computer. I had a hacked image of CBM BASIC that would take I/O from a serial chip. Did wonderful things with that.

I miss the 8052AH-BASIC very much, made a payphone controller board out of that one. That was one hell of a chip. So quick to code on. Self sensing serial speed, had the software to burn an EPROM, Give it +5, a colorburst xtal, and hang a 8k SRAM on it with a Dallas SmartSocket and Bob's your uncle.

Ah, the days when you could run down to Radio Shack at 8:40pm and buy some TTL glue and the wire wrap supplies to finish a project.

Please, you are kidding?

[Anonymous Coward]

There were full published data sheets, pinouts, etc. back in the 80's. People did hardware upgrades with soldering irons on the Sinclair Spectrum or the cheapo version the ZX81. The Z-80 also had some shared function data/address pins too, alternating between clock cycles and the ULA was somewhat of a mystery.

How can this be a historical discovery? Shit I've gotten old.

Re:Please, you are kidding?

[AaronW]

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.

Re:Please, you are kidding?

[Anonymous Coward]

I also built an H89. Nice box. Never saw a hard drive for one.

Why didn't they just ask Federico Faggin?

[Anonymous Coward]

Why even bother? There is no rule that a chip has to be bonded out to a package so as to achieve a particular ordering of bit in busses. It's the way it is because it was the least complex, easiest way to do it. A boring reason, but there it is.

Re:Up-to-the-minute reporting from Slashdot

[BringsApples]

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.

Why is it necessary to reverse engineer this?

[elgatozorbas]

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.

While I agree, I wonder if this is actually true. To what extend does knowledge about efficient coding on an 8 bit machine with limited memory teach us anything about programming these heftier CPUs? Maybe the only people that should really have chewed the bits are the writers of compilers. For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.

BASIC vs. Z80 assembly language

[MillionthMonkey]

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.

Re:BASIC vs. Z80 assembly language

[pubwvj]

What you describe has nothing to do with the Z80 processor but rather the ZX81 kit you had.

I had a Exidy Sorcerer which had a Z80 in it also. A great computer. It was my third but not my final Z80 based machine. All of them were tops for their time and a lot better than you're describing. You merely had a poorly done implementation.

It is important to differentiate the OS (what you're really complaining about) from the processor.

Re:BASIC vs. Z80 assembly language

[david.given]

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).

Re:BASIC vs. Z80 assembly language

[Duncan Booth]

One thing I remember from CP/M was that when a program terminated you could save the memory it had been running in to disc as an executable program. A lot of programs (e.g. Wordstar) used this to avoid having to read any kind of configuration file: instead you just changed settings within the program, exited, and saved the memory; when you ran the saved version you had your saved defaults. I also always kept a 0 length file around in case I accidentally exited a program such as a text editor without saving: run the 0 length file and it would just restart the editor with everything restored.

Re:BASIC vs. Z80 assembly language

[MillionthMonkey]

Yes, it was obviously a very shitty system, since they were selling them thirty years ago for about $99. It was like a 1980s version of a Raspberry Pi. But it did have a Z80 in there and that's how I learned assembly when I was a kid; I just dug to it through all the crap it was soldered to.

Re:BASIC vs. Z80 assembly language

[Anonymous Coward]

Ahh, Peek and Poke! What a fun way to get extra out of a TRS-80. I've still got one in the basement. Only problem I recall was that I'd poke in a statement to change the cursor on the model 3, and if I did the same poke on the model 4, the computer was toast. Or at least I didn't know how to reset it.

Re:BASIC vs. Z80 assembly language

[ChrisMaple]

Also in the WordStar executable was the ASCII text: "Nosy, aren't you?", a message to those disassembling the program.

Re:BASIC vs. Z80 assembly language

[Ambient Sheep]

Hah, I never knew that, but that's brought back a memory of disassembling "Halls of the Things" on the ZX Spectrum.

Was running through the code with my monitor/disassembler (DevPac, for those of you with long memories!) and I found the standard mapping table for the keyboard that pretty much every program had, but this time, immediately following it, was the ASCII text: "Yes cunt, a keyboard table". I nearly fell off my chair laughing... that someone had such hostility to spend the bytes at a time when memory was so seriously precious. A while later I found the main loop similarly flagged with similarly abusive comments scattered throughout it. :-)

At the start of the code was a phone number belonging to the devs' home city. The only reason I didn't call it was that it was two years after the game had come out, and the early 80s video game bubble had well and truly burst by then. Most games I hacked (purely for fun, not profit) pretty quickly, but that was the most difficult one I'd ever come across (mainly due to a cunning custom tape loader) and I'd actually given up, back in '83 when it came out. A couple of years later, one bored weekend, I had another go at it and managed it. It was worth the wait. :-)

Re:BASIC vs. Z80 assembly language

[Anonymous Coward]

I programmed assembly on the ZX81. This really brings back memories. Did you get 'Tony Bakers' book on assembly on the ZX81? I remember entering all of the programs and learning the lessons in the book. It was great, like solving puzzle after puzzle.

Re:BASIC vs. Z80 assembly language

[Anonymous Coward]

I remember that trick - but on a microbee in my case! Bonus points if the code you poked in broke the LIST (^L would clear the screen, but other combos could mess things up in far more "interesting" ways). A similar trick could get you self-modifying BASIC code - just reverse engineer the basic tokenization scheme and leave some empty whitespace lines at the start of your code to overwrite and Bob's your uncle.

And yes i also experienced the pain of cassette tapes. My brother and I would typically start a tape loading then bugger off outside for at least 20 minutes or so. Then you would come back, adjust the volume on the dodgy cassette deck connected to the computer, and try again. Usually took 2-3 attempts depending on how worn out the tape was.

Kids these days...

Re:BASIC vs. Z80 assembly language

[Anonymous Coward]

As I dimly recall, you could simply DIM an array with a large enough space for your program, and use that instead of having the visible REM statement. Those were the days.

Re:BASIC vs. Z80 assembly language

[MillionthMonkey]

I remember I had a yellow book that was for kids learning assembler, and it had a cartoon CPU with registers for hands and feet. I can't remember the title- I just pulled the ZX81 out of the closet to look for it, but it isn't in the box anymore. I still have the 16K pack and the awful little ZX Printer that sparked onto rolls of aluminum thermal paper.

Re:BASIC vs. Z80 assembly language

[david_thornley]

I fell in love with CP/M when I started working with it, after being familiar with several different OSes (mostly on mainframes). Here was an OS that got in my way no more than any other I'd tried, and it used few resources in doing it. (Later, MacOS became my favorite, since it actually seemed to help me, and then I encountered Unix. I haven't found anything I like better than Unix/Linux.)

Re:BASIC vs. Z80 assembly language

[MillionthMonkey]

I dimly recall that method too but IIRC the array couldn't be saved to tape- you needed POKE statements underneath the DIM. There was also another method involving adjusting the SP register to lower the top of the stack and claiming a few kilobytes of RAM for whatever purpose- but that approach had the same problem with not getting saved to tape.

Re:Up-to-the-minute reporting from Slashdot

[Anonymous Coward]

Right on. What a nice change to have a technically oriented article compared to the usual pissing matches and posturing - regardless of when the technology was generated.

Now we can reserve engineer TI calculators

[jfdavis668]

Now if we can only figure out how to create 96 by 64 bit displays.

Re:Now we can reserve engineer TI calculators

[93 Escort Wagon]

Now if we can only figure out how to create 96 by 64 bit displays.

Stop the madness! It simply can't be done!

I had a different idea for that pin order

[damn_registrars]

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.

Nah...

[Anonymous Coward]

I seem to vaguely recall such design allowed for a greater immunity against electrical interference between data lines (maybe during DRAM refresh?)

Definitely News For Nerds

[MikeTheGreat]

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" :) )

Re:Definitely News For Nerds

[Anonymous Coward]

You are disingenious. All your high-powered smartphone thingies are actually highly in-transparent in what they ACTUALLY do. In addition to the official functions. So maybe true freedom implies the ability to build your own little computer ?

5v lines

[Alioth]

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.

Re:5v lines

[Megane]

In fact, the earliest surface-mount TTL (the 54J/74J series) had the power and ground lines in the middle of the chip. Also, a few random regular TTL chips have middle power pins just to keep you on your toes.

Re:5v lines

[matfud]

Many modern chips that have analog components have the analog supply and ground close to the pins used for the analog functions (for pretty obvious reasons)

You many no longer be worried about running a few extra digital datapaths to make the outside data bus be in order but you still need to seperate analog and digital functions and that limits the output pins they can use

Waste of time

[Anonymous Coward]

Rather than "reverse engineering" this, why did the author not simply look at the data manual for the chip, where all this is perfectly clear?

Re:Waste of time

[Megane]

What? The data sheet only tells you which pins are which, not why the pins are where they are. That's what this guy is trying to find out.

Super Geek Post

[Squidlips]

Thank you!

6502 to Z80 work per clock ratio

[tepples]

Speed of Z80 at 4Mhz was comparable to that of 65xx at 1Mhz

I thought the work per clock ratio between 6502 and Z80 was closer to 2:1, not 4:1. This would put, say, a 1.8 MHz Atari 800 and a 3.5 MHz Spectrum together, or a 1.8 MHz NES and a 3.6 MHz Master System. Where do you get 4:1?

Re:6502 to Z80 work per clock ratio

[Anonymous Coward]

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.

Re:6502 to Z80 work per clock ratio

[tepples]

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.

Re:6502 to Z80 work per clock ratio

[Spit]

The 6502 memory access style with the unified map worked well for tickling the registers on coprocessors and on bitmaps; very fast and predictable for display timing. The Z80 bus method was abstracted some although still quite useful.

Regardless, they are such simple devices there's no excuse not to master them both for maximum pleasure.

Re:6502 to Z80 work per clock ratio

[Anonymous Coward]

" but the Z80 takes 4 clockticks per (basic) instruction."

I think the latencies in the z80 could be much higher, depending on what instructions you use.
I think the R800 had much less variation in cycles taken per instruction while the z80 latencies varied a lot across the instruction set.

Re:6502 to Z80 work per clock ratio

[jeremyp]

The 6502 had special addressing modes for accessing the bottom 256 bytes of memory. Addresses in both the 6502 and Z80 were 16 bit, thus taking two read cycles to get a whole address into the CPU so that you could then get the content at the address. However, with the 6502, "zero page" addresses could be read in one read cycle. Not only that, but pairs of zero page locations could be used for indirect addressing. They could be treated as a set of (slow) address registers.

When I first came actress the Z80 after having programmed the 6502 for a while (as a hobbyist), I was quite shocked at how all over the place its design appeared to be and I actually found it a little harder to program at first because there was more to learn in order to use the CPU effectively.

Re:6502 to Z80 work per clock ratio

[tepples]

Yeah, I'm aware of what the 6502 can do, having programmed a few games for a 6502-based platform. I just never got into the Z80, so I'm not sure how much the plethora of extra registers (AF BC DE HL IX IY) made up for the lack of indirect addressing modes like (d),Y.

Re:6502 to Z80 work per clock ratio

[oldhack]

Another issue with Z80/8080 instruction set, if I remember correctly, is that they are not orthogonal in regards to the registers. Some opcodes only work with registers B and C, others only with D and E, and so forth.

The ugliness of x86 instruction set has a long root.

Re:C=128 + 6502 cost.

[Anonymous Coward]

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.

Don't underestimate the importance of our ROOTs.

[MindPrison]

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.

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 /. back to the roots.

Future does not bode well

[Anonymous Coward]

If the Z-80 is so much a mystery, I can't wait until 30years from now someone tries to reverse engineer a modern Intel chip or even the old fabled Itanium for educational purposes. Or do modern chips have much better documentation and schematics that would be available?

Re:Future does not bode well

[Megane]

The big difference is that these old 8-bit processors were laid out entirely by hand with a lot of rubylith tape on a large piece of transparency plastic. That's why they're so interesting. But all the new stuff is entirely in CAD, with mostly automated layout.

Re:Future does not bode well

[ChrisMaple]

Modern Intel chips have documentation that is not available outside Intel. Consider things like registers for testing in the factory, circuits for disabling defective cores or defective cache memories, etc..

Re:Speaking of anonymous

[Anonymous Coward]

They have already punished you. Thanks for proving what those people are like. If you are not white then you are not welcome here.

Casette Tape Z81/TS1000 Heavy Metal

[Anonymous Coward]

..
I had a ZX81 and TS1000 in high school. My senior year I took it to school and a pal of mine got a hold of one of the Cassette Tapes with programs on it.

He put it in his Walkman and played it, this was 1982.

They thought it was some new dance mix.

I don't know for sure, but this was in Southern California.. shortly there after .. Heavy Metal was born.

gear heads

[Anonymous Coward]

The early geeks were hands on in the 70's.
All their non-geek buddies talked about mustaings, corvettes, and big-block v-8
The pin layout was nothing other than the geeks way of emulating a v-8 firing order, which never is in ascending order ;)

And it had a big carb and gass line in the middle of it.... Nothing more, nothing less.

 

Re:gear heads

[matfud]

But do you know WHY a V8 does not fire in ascending order?

Re:gear heads

[ai4px]

Oh contraire..... VW 4 cyl firing order is 4321. The old air cooled ones.

Re:gear heads

[matfud]

Damn you you opposed piston engines (which balance pretty well)

Finally

[Anonymous Coward]

Will be able to sleep tonight.

The refresh register is weird too

[Megane]

I had always wondered why the refresh register only counted 7 bits wide, which made that feature mostly useless when 64K DRAMs came out. (a few 64K DRAMs were made with 7-bit refresh, probably because of the Z80) Turns out that the increment/decrement circuit used in the Z80 had carry lookahead for groups of bits: 7 5 3 and 1. The I and R registers were implemented as a single 16-bit register, and to keep the I register from incrementing all the time, only the first group of the increment circuit was used, resulting in only 7 bits counting.

Not surprisingly, this comes from an earlier post on the same guy's web site: http://www.righto.com/2013/11/the-z-80s-16-bit-incrementdecrement.html

Fred Weeks

[Shaman]

I know Fred Weeks personally. He retired from his Zilog days a multi-billionaire and landed in Prince Edward County, Ontario.

Re: Speaking of anonymous

[Anonymous Coward]

If you aren't rich and white, then the chances of you being educated and a non-felon decrease dramatically. I'm not going to invest my valuable time reading anything an unsuccessful criminal has to say. Don't hate the player.

Re:Speaking of anonymous

[Anonymous Coward]

There is no reason to be loyal to Slashdot anymore. Ad block.
Once they tried to force New Slashdot they destroyed that loyalty.

Re: Don't underestimate the importance of our ROOT

[Stonent1]

A zealous grumpy old moderator if you are who I think you are. Moth!

Doesn't explain much.

[Anonymous Coward]

So that's why data pins 3, 4 and 5 are at one side? OK, so then, why aren't they at least in order? Why are the other pins not in order? Why did space constraints force these pins into an odd order when the Z80 designers were apparently quite capable of making all of the other pins come out of the chip in order?

The guy's argument is the position of three fucking transistors out of thousands. Sorry, but it isn't "why the Z80's data pins are scrambled," it's just one little fact that may be a piece of the puzzle, but certainly isn't anywhere near a complete explanation.

MSX

[Ihlosi]

Yes, MSX and possible the CPC6128 came close, but just that and they came too late. The killer 8-bit machine wouldn't have required any technology that wasn't available when the C64 came out.

In 1983, the 68k had been out for a few years already and new 8-bit computer designs were doomed.

1541

[Anonymous Coward]

A good example being the "Woz Machine" floppy controller compared with many Z-80 boxes needing a second 6mhz Z-80 to run their floppy drives.

Didn't the C64 need an extra 6502 (@ 1MHz) for its floppy drive? The 1541 basically had the same computing horsepower as the C64 itself ...

Re:1541

[Shirley Marquez]

Yes, the C64 had a separate processor for its floppy drive. So did Atari. But that's because both manufacturers chose to put peripherals like floppy disk drives on a serial bus rather than interfacing them directly to the main CPU.

I know that Atari did that to make RFI compliance easier. Signal radiation from a low speed serial bus is less of a problem than radiation from a parallel bus, and they didn't want to integrate the floppy drive into the main unit to keep the price down. (Some users chose less expensive tape drives or only used cartridge-based software.) At the time, the FCC had just adopted its first RFI standards for personal computers, and many manufacturers were griping that the new standards were impossible to meet. But Atari was able to point to their 400 and 800 models, which passed the tests with flying colors, and say that the standards were not impossible at all, they just required more attention to shielding than computer makers had been accustomed to.

Most modern personal computers are actually less well shielded than those old Ataris were. (Even Atari's own later models, the XL and XE series and the ST series of 68000-based systems, were not; they were only built as well as they had to be rather than as well as they could be.) Current day PCs depend in part on a bit of technical trickery to comply; spread-spectrum master clocks. Instead of using a single stable frequency, the master clock is intentionally varied over a small range; this makes the noise peaks smaller.

Ob. War Story

[Chelloveck]

I worked at Motorola in the late '80s in the Cellular Infrastructure Group. Moto's cellular switch was Z80 based, but it was a helluva hack. The thing had six Z-80s arranged in three nodes, each with an active processor and a hot standby. We had a custom MMU that extended the address space to 24 bits and could be mapped in 4096-byte blocks. Of the 16MB address space, 4MB was shared and simultaneously accessible by the active and standby processors.

It was mostly programmed in assembly, but we did have a "high level" language called MPL (Motorola Programming Language) which was little more than a big macro set around the assembly. It was very naive, had no optimization, generated crap code, and was buggy as hell. I always called it a pessimizing compiler. There was a newer, less buggy version available but we didn't use it. We had too many hacks and work-arounds that depended on the buggy behavior in the original.

All the code was, of course, linked into a single monolithic executable and loaded from tape. It took about 20-30 minutes to load the program. The processor board had a serial debugger terminal which could be used to poke changes directly into running memory. Each memory page had some space reserved for patches. I sometimes had to patch live customer machines by entering an assembly routine byte-by-byte into memory via the serial terminal and finally patching a CALL instruction into the appropriate address in main executable memory. And hoping really hard that I hadn't made any typos.

Later in its life peripheral boards were being built that were 68000 and PowerPC based and much more powerful than the main Z80 boards. The Z80 software was so crufty by then that the peripherals had hardware hacks to work around weird software behavior just because it was too damned hard to change the software.

Ah, memories...

And I thought....

[ai4px]

It was so the CPU was forced to slow down so the typebars didn't jam.

Another possible reason...

[GrpA]

Anyone who ever designed circuitry regularly enough with the Z-80 ( I would have designed over 40 boards using the z-80 during my career ) always used to think they did it that way so you could put the ROM chip next to the processor, while only using a few through-board connections. A 16k ROM could easily be connected to the Z-80 on a single-sided PCB with just 6 jumpers that fit neatly beneath the Z-80 chip itself.

Maybe that's not the reason it was built that way, but working with other designers at the time, that's what we all though -

Regards
David