Jump to content

Talk:Zilog Z80/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Article title

Following the naming convention for Wikipedia microprocessor articles, I moved the Z80 article back to its Zilog Z80 name after a contributor renamed it Z80. The redirect should be sufficient. --Wernher 10:55, 23 April 2004 (UTC)

Should the list of advantages not also include the important fact that the Z80 did not need complex glue as the 8080 did up until the 8085. That was a big factor too Alan 00:31, 24 September 2004 (UTC)

"The Z80 was also used in the defense industry"

While military uses of the Z80 may well be worth of investigating, this sentence alone, and slighly out of context, is better left off the article. I've moved it here as a reminder to anyone who knows of any specific uses, or can otherwise elaborate on this sentence.

LjL 00:16, 28 April 2005 (UTC)

Raytheon use a Z80 core in some of their older GPS and interrogator systems as well as the good old Z80 husky (which it was my job to stick in a freezer and then boiling water to see if it died - which it didn't). 82.153.169.114 (talk) 16:18, 17 November 2005 (UTC)

6502 stuff

The Z80, and its primary competitor, the MOS Technology 6502, sparked off a series of computer projects that would eventually result in the home computer revolution of the 1980s.

Aside from the vacuity of the statement, I don't even think it's strictly true. The Apple II and Commodore PET, later Commodore 64, and the Atari game/computer systems, were far more significant in the home computer area than the Z80 systems were, at least based on numbers sold. Z80s were important, but never had the penetration that 6502-based systems had in the old 8-bit days. I've taken the statement out. I speculate that if you were to poll people who've written BASIC programs, 3 out of 4 would say their first program was written on a 6502 machine of some kind (well, my first BASIC was on a PDP 11 but I'm older than dirt).

That may be true in North America, but the rest of the world is a different story. The Z80 was used in many more systems, and cummulatively those system otsold the 6502 systems by a good margin, certainly in Europe. The 6502 was not at all common in Japanese systems either. 81.178.94.33 21:34, 17 June 2007 (UTC)
The ZX-80 sold in reasonable numbers; the ZX-81 in large numbers, and the Spectrum in pretty impressive volumes. Wasn't the Japanese MSX series designed around the Z80? Then there were many computers that, while they may not have sold in such volume, used the Z80, so that it had an additional importance over and above just the number of chips sold. At university the Z80 appeared to be the preferred reference 8-bit chip (absolutely no idea why, or if this is UK-centric), further making it important. The 6502's popularity, according to Chuck Peddle, was that it was cheaper than the Z80 when he started the Pet line. (I can't remember the interview source for this quote.)Bendel boy 13:27, 9 February 2007 (UTC)

My criticism of Wikipedia is that, often, the article on X immediately sounds like Although X was great and wonderful, it was immediately replaced by/competed with Y which we all know and use today. An article about topic X should stay on topic X at least long enough to give the reader a good idea of what X is, before it branches off to talk about the successors Y and Z, and how Tesla patented W in 1903. --Wtshymanski 16:15, 22 May 2005 (UTC)

If that is the case, then shouldn't that statement also be removed from the 6502 article? The Z80 may not be as popular as the 6502 in the US, but however for Japan, Europe and the former USSR (cloned Z80s) it was the CPU of choice, sparking off their home computer markets, so I feel that your statement is a little US-centric. I think the statement is fine, but it could be placed somewhere in the history section, rather than the introduction.
As for your criticism about the divergence in introduction, it seems to be your personal preference. If the majority of articles start off this way, then it seems most people do not have this problem. I think it is a good idea to mention the alternative/competitor/etc in the intro, but again that is personal preference. I would like to know what others feel about this before deciding what to do.
ADSR6581 16:54, 22 May 2005 (UTC)
I would speculate without any sources at all, that there were more home computers sold between 1980 and 1985 in Minneapolis than in the whole of the then-Soviet Union. I don't think the USSR, at least, had much of a part in the so-called "home computer revolution" . The whole field of personal computers is US-centric. Professionally written encyclopedias in my experience don't start contrasts and comparisons until somewhat further into the article than the introductory paragraph. --Wtshymanski 17:16, 22 May 2005 (UTC)
So Europe and Japan didn't have one, either? The field of personal computers certainly wasn't as US-centric in the early 1980s as it is now, and the European and Japanese markets were probably larger than you think. While I would accept that the 6502 had a larger impact, I don't believe that the statement that you've removed was biased. --StuartBrady 18:12, 30 April 2006 (UTC)

eZ80 Memory Address

The eZ80 website and the wiki entry both state that it can access 16mb of memory directly.
-- Jeremy Harmon 05:57, 13 July 2005 (UTC)
I'm not sure what the issue is? The Z80 is an 8-bit CPU, but it does have extended 16-bit instructions (which are slower as well). I assume this really comes down to how the Z80 requests memory from the BUS - does it do two fetches or just one?
-- Michael Abbott 06:22, 9 October 2005 (UTC)
The eZ80 actually uses an 8-bit data bus, with a 24-bit address bus. Some registers are extended to 24-bits (ie, UBC, UDE, UHL). When running in this mode (called ADL mode by Zilog), a 24-bit (3 byte) memory access takes 5 cycles (as opposed to 4 cycles in 16-bit/non-ADL mode, called Z80 mode by Zilog). The eZ80 in ADL mode would do three fetches to 'bring in' all three bytes, as opposed to two fetches for Z80 mode.
It's interesting to note that the eZ80 generally performs about one instruction per cycle - this is possible because it pipelines the instruction stream (it fetches one instruction, then while it's decoding that instruction it fetches another, and while it executes the first it's decoding the second and fetching a third instruction, etc., to about four levels as far as I can tell). The JP and CALL opcodes 'flush' the pipeline.
In practice, this works so well that one needs fast memory/IO (12-15 nsec) in order to properly function using zero wait-states.
-- JN 05:05, 4 December 2005 (UTC)

RISC or CISC?

Does anyone know definitively if the Z80 is RISC or CISC? I'd think it's CISC because of the varying length of opcodes (both in size and tstates), but I'm not sure. --Andy Janata 11:37, 13 September 2005 (UTC)

Why is this a needful question? "RISC" and "CISC" are technical terms useful in a very narrow class of discussions of the philosophy of design of processors, but in my opinion aren't useful terms when describing historical designs. Read the RISC article and decide if the Z80 fills the bill (I'd be surprised if it did) and then decide if the RISC/CISC nature is as interesting as, say, built-in DRAM refresh. --Wtshymanski 13:53, 13 September 2005 (UTC)
Agree that it doesn't really matter. But technically, the answer is CISC. Although the precise definition of RISC is somewhat controversial, and many things are now called RISC that would not have been back when RISC was first invented, it is fairly clear that the Z80 doesn't meet ANY of the usual RISC qualifications. The instruction set is not reduced, the instruction length is variable, the instruction execution time is variable, the register organization is ad-hoc, and instructions other than loads and stores have operands or destinations in main memory. --Brouhaha 23:12, 13 September 2005 (UTC)
Thanks for the replies. I was wondering because we were talking about the differences between RISC and CISC in my assembly class. We're using the Atmel AVR ATMega16 in class... I was just wondering what the Z80 (which is used in my TI-83+ that I also program in assembly for) was, and I did think it was CISC. --Andy Janata 19:39, 20 September 2005 (UTC)
I believe it's fair to say that RISC largely was about doing without (relatively) slow ROM-tables, either for decoding of irregular opcodes or for the sequencing of internal operations. The simple instructions, regular encoding and register-structure was not so much a goal in itself as it was an "easy" way to manage with a purely combinatorial implementation of the control "store". Perhaps "ROM-less CPU" (ROLC...) would have been a better name than "RISC" :-). Henrik Kjersén 20:02, 31 January 2006 (UTC)

The GameBoy

I think it's worth noting that the Z80 in the GameBoy was rather different. Most notably, it didn't have the IX or IY registers (no DD or FD instructions). It also had instructions for HL incrementing ("LD (HLI), A", "LD A, (HLD)") which were extremely useful. Otherwise, it had a number of "optimisation instructions" ("LD A, (0xFF00 + XXh") including some of the CB instructions being moved into the basic instruction set. -- Michael Abbott 06:30, 9 October 2005 (UTC)

  • I would think that the Gameboy has iy, and ix (unless its a different product number; z80 has several different versions) but the OS rather doesn't use it. For example, the TI-OS does not use IX under normal circumstances on the TI-83 plus, but you can still use it.
    • Game Boy doesn't have an operating system, only a simple boot ROM that checks for the Nintendo logo in the cartridge. It lacks the IX, IY, I, R, AF', BC', DE' and HL' registers, but adds some instructions such as using a 16-bit register as a pointer and then incrementing or decrementing it, LD r,(FF00+nn) and LD r,(FF00+c) (and the matching store operations), and with Game Boy Color, the ability to switch to double-speed mode via the STOP instruction.

yah that makes a ton of sense. "It lacks the IX, IY, I, R, AF', BC', DE' and HL' registers" Your trying to tell me than the GameBoys CPU doesn't have ANY registers at all? Were you tired when you wrote that? It wouldn't even be called a "modified Z80" if they got rid of all the registers, It wouldn't even be a CPU in the first place:| What I think you meant to say was that it lacks the IX and IY registers, which makes sense because why would a programmer use extra slow address registers that has to be "indexed" (a practically useless feature that many processors had for no apparent reason) when they can't even come up with a use for it anyway. It takes some guy with an IQ of over 300 to actually figure out a use for these registers. And I know it has no use because Chuck Norris found a use and what ever Chuck Norris does can not ever be done. If Chuck Norris brushes his teeth, nobody else can. FBI WARNING: My post is suposed to be silly and satirical. If you start flaming me because I'm not as boring or as normal as you, you will be fined $110,000,000,000,000,000 under copyright protection law.

"If you start flaming me because I'm not as boring or as normal as you" Ah, you're not "boring or normal", right, because it couldn't possibly be that you're painfully unfunny and just can't admit that to yourself — Preceding unsigned comment added by 94.3.30.15 (talk) 11:42, 11 July 2013 (UTC)
He was talking about the alternative AF,BC,DE,HL, not the main registers. // HenkeB (talk) 14:29, 17 December 2007 (UTC)
That sounds like it was more like an 8080 than a Z80. BrianDGregory (talk) 19:38, 23 November 2010 (UTC)

BTW, the correct title is Game Boy, with a space. 65.95.157.80 08:14, 29 September 2006 (UTC)

Clarify

What does "too minicomputer-oriented" mean? I tried to get this to say "too complex for embedded controllers" but someone thinks this phrase explains the failure of the chip. I'd appreciate a citation or some reference. --Wtshymanski 03:14, 1 April 2006 (UTC)

It means (1) User and System modes, (2) Direct multiprocessor support, (3) On-chip MMU, (4) On chip instruction and data cache, and more - all fairly typical mini computer features. At the time, most designers of embedded systems came from electronics, and designed their systems, from the ground up, without using any RTOS or similar. They wanted simple and predictable* chips that could easily be learned in detail, not minicomputers on a chip (like 286/386 etc). Many engineers also work this way today, and that is one of the reasons why old designs like Z80, PIC, 8051, 65816 etc are still selling. --HenkeB 21:55, 1 April 2006 (UTC)
(*) Regarding EXACT instruction timing, among many things
Neat. Could you summarize and put that into the article? If only there were Wikifootnotes in the articles. --Wtshymanski 21:52, 19 April 2006 (UTC)

All the stuff about what the company did after the Z80 should go into the ZiLOG article. --Wtshymanski 20:16, 1 April 2006 (UTC)

Z180 and eZ80 are compatibles, so they should be there. A short remark on Z8000/Z80000 in the introduction is also in order. Please note that the Zilog Z8 is not mentioned anywhere ;-) --HenkeB 21:55, 1 April 2006 (UTC)

R register

I'm sure I remember the R register wrapping around at 128 and not at 256. You could store an 8 bit value in it though and retrieve it later (modulo having to subtract stuff for the instructions executed in between) and have the MSB preserved. If I'm remembering this correctly it is important enough to add to the article. I suppose it's possible that this was a machine-specific bug. DrHydeous 10:54, 18 April 2006 (UTC)

That was definitely true of the original Z80 CPU. Some of the later variants and derivatives may have different behavior. I agree that it's worth noting in the article. --Brouhaha 09:04, 19 April 2006 (UTC)

Done :-) I've also explained how the value in R changes instead of just saying that it "incremented automatically with no simple relationship to program execution" DrHydeous 20 Apr 2006

Unfortunately, you've got it wrong. It is incremented on every M1 cycle, not on every memory read. --Pak21 14:32, 20 April 2006 (UTC)

8085 ripoff?

I learned back in school that the Z80 was created after some internal arguments in Intel, and that quite a few engineers went over to Zilog, who created the Z80 at record speed, this being binary compatible with the old 8085 apart from a new instructions. Is this right?

The Z-80 was binary compatible with the 8080, not the 8085. The 8085 was Intel's answer to the Z-80: it had some electrical improvements (mainly being 5V-only, instead of requiring three supplies), and a few other minor differences, but it did not have the Z-80's major architectural advances. There are some opcode conflicts between the 8085 and Z-80, while there are none between the 8080 and Z-80. Nearly all 8080 code runs correctly on the Z-80; code that was written for the 8085's extensions over the 8080 will not run correctly on the Z-80.
The Z-80 was created after several Intel engineers left; it is not known how much of the Z-80 was lifted directly from the 8080, if any. Jay Maynard 23:19, 20 May 2006 (UTC)

Nonsensical caption

The caption of the first picture says, "One of the first Z80 microprocessors manufactured; the date stamp says well before July 1976." What does that mean? -- Kjkolb 07:50, 4 July 2006 (UTC)

The date stamp on that Z80 was from before July 1976. The wording isn't great, though. 7623 probably means "1976, week 23", which should be June... --StuartBrady (Talk) 10:45, 4 July 2006 (UTC)

Arcade games

Many many moons ago, I worked at Chuck E. Cheese as a video game repair technician. Several games we had used the Z80 as their CPU. Unfortunately, as this was in the 1993-1995 timeframe, I don't remember WHAT games they were now or even which manufacturer made the games. I do recall having to order and swap out a Z80 at least once, and we definitely had them in at least 2 games. Not putting this in the article since obviously my vague memory isn't encyclopedic... but someone more determined than I may want to run down the names of those games so as to update this article with info on the use of Z80 in arcade games. Murple 06:30, 31 July 2006 (UTC) —The preceding unsigned comment was added by Murple (talk • contribs) .

The MAME source will give tell you many games which used Z80s, either as their main processor or as secondary sound processors or the like. Cheers --Pak21 08:10, 31 July 2006 (UTC)

Bulk copy

Didn't the Z80 have a bunch of bulk copy operations? To my inexperienced mind, that was the thing that marked the Z80 out from other processors of that era. eg LDIR - load from (DE) into (HL), increment both DE and HL, decrement BC, repeat until BC is zero, or something like that, in a single operation. Or was that some kind of sneaky assembly macro?

Chris Thornett 17:09, 24 August 2006 (UTC)

No, that's an honest to goodness Z80 instruction (0xed 0xb0). There was also a decrementing version (LDDR) and repeated versions of IN, OUT and CP. Cheers --Pak21 18:13, 24 August 2006 (UTC)
LDIR seems to be basically LDI-and-do-not-modify-instruction-pointer-unless-zero. It is also VERY slow. —The preceding unsigned comment was added by 145.253.2.232 (talk) 09:39, 15 May 2007 (UTC).
What do you mean by "VERY slow"? It was a quite fast and powerfull instruction. Do you have some sort of faster (and shorter) program that can bulk-transfer kilobytes of memory in Z80 assambley language? With a very simple and short program usind LDIR or LDDR you could copy somewhere (above the 32kilobyte boundary) in the memory the entire screen of a ZX spectrum in around 1.5 video frames or you could do a video-page swap in around 2 frames. OK, that was not acceptable for flicker-less animations during games, but there were other applications that saw benefit of that.89.137.187.188 (talk) 08:49, 24 March 2008 (UTC)Apass
It is indeed a powerfull instruction - when it comes to size of program. However, I never used the instruction when speed was of the essence. Since LDIR uses 21 T-states for each byte transferred (exept the last byte, which is 16), and LDI always uses 16 T-states, I almost exclusively use a series of LDIs for achieving the same effect. Or a series of PUSH/POP - depening on the nature of the problem (an LD A,(HL); do something; LD (HL),A; INC HL is also surprisingly effective). However, moving a ZX Spectrum screen with LDIR takes 145147 T-states - that's slightly more than 2 video frames. Using a series of LDIs takes 110592 T-stats which is ~1.6 frames. --Frodet (talk) 12:15, 24 March 2008 (UTC)
Indeed, slightly more than 2 video frames in a 60 frames/second system but in a 50fps system (which I used) it is like 1.8 frames. Anyway, moving a screen with LDI is, for sure, fast, but by no means the best solution in terms of program size. Now, back to the point, LDIR / LDDR are not "VERY" slow instructions as 145.253.2.232 said. 21 T states is pretty long, but much shorter than LD A, (DE); LD (HL), A; INC DE; INC HL; DEC BC; JPNZ... (yes, there are other ways of doing it, but my point is that it is not "VERY" slow)89.137.187.188 (talk) 15:18, 24 March 2008 (UTC)Apass
One frame on a 3.5MHz ZX Spectrum @ 50 HZ is 70000 T-states. I agree, it is much quicker than the equivalent series of op-codes. What is "VERY slow" depends on one's point of reference. --Frodet (talk) 21:23, 24 March 2008 (UTC)
They are very slow if you consider that they are supposed to be CPU-internal optimised loops. They may be, fingers crossing and all, faster than a simple loop, but as said above, unrolled loops and PUSH are faster. While I admire the elegance of simply not incrementing PC (thus being "glued" on the instruction until BC is 0), this is not optimal for speed. --88.74.180.216 (talk) 18:00, 20 June 2009 (UTC)
They certainly should be described as very slow, painfully so. A memory->memory transfer should take 6 CLKs (2 x 3 CLKs) whereas LDIR/LDDR take 21 CLKs, over three times slower. The Z80 DMAC could do 6 CLKs/transfer and I do appreciate that was a dedicated IC, not extra squeezed-in instructions. also I understand that the slower simplicity of refetching the opcode every pass simplified the interrupt response circuit, allowing it to suspend and resume block transfers easily and promptly. Nonetheless, block transfer instructions could be outrun by hand-crafted sequences of instructions and that was very worthwhile to do in games.--TonyM101 (talk) 21:53, 10 February 2014 (UTC)
Maybe so, but your 6 CLKs does not include incrementing and decrementing the three 16-bit register pairs, each of which requires use of the ALU and internal register buses. For comparison, INC DE takes 6 T-states. — Loadmaster (talk) 00:13, 11 February 2014 (UTC)
Quite. You increment the source pointer HL using the ALU, while writing to (DE) using the BIU. You increment the destination pointer DE using the ALU, while reading from (HL) using the BIU. You have 2 CLKs free to decrement BC. It's all perfectly possible to do, the LDIR sequence is full of parallel tasks. That's how a DMAC can do it in 6 CLKs. INC DE does take 6 CLKs but only 1 or 2 are INCing DE - 4 CLKs are for fetching the opcode and 1 CLK is for decoding it. I fully appreciate that it may well be difficult to do this with the internal circuit architecture of the original Z80. It doesn't alter my point that it's a very slow implementation of the job it does. And when you tried putting it to serious use, such as graphics manipulations in games or creating space in a memory map, you noticed how little faster than its software equivalent it was. I'm afraid the fact that people might appreciate the Z80 for having them doesn't suddenly redefine everyone's idea of 'fast' and 'slow.--TonyM101 (talk) 16:40, 11 February 2014 (UTC)

Undocumented I/O

It would be useful to know if any computer or device ever utilized this. I would like to know, because addressing hardware on the ti-83 flash family is rather annoying with the out(XX),a instruction...

ZX81 did, for instance.
Annoying, how? (I do not know the TI calculators in detail).
(OUT (nn),A has A on A15..A8 while nn is on A7..A0, btw)
/HenkeB 16:30, 17 September 2006 (UTC)
The KC 85 used this for expansion module switching if I recall correctly. (I think it was a "module output" port in B and the C register was used as module address, or the other way round) The CPC used it as well, only IIRC they even took all 16 bits as address and proceeded to incompletely decode it (you had to use 0xfffe, 0xfff7 or something like that, one bit zero-ed out addressed the hardware, saved decoder chips)

Also I do not think this was "secret" or "undocumented", it was like a standard feature —The preceding unsigned comment was added by 145.253.2.232 (talk) 09:42, 15 May 2007 (UTC).

There is nothing 'undocumented' about this, Zilog reference documentation explains this just fine. You just have to read carefully.

Both Sinclair ZX81 and ZX Spectrum use this feature for keyboard scanning, the high order address lines are connected to the keyboard matix (via diodes). When reading some I/O port, the value that is present in A or B register (depending on instruction used) determines which keyboard row is read. Perhaps there's other uses that aren't widely known. --Alwin 195.240.190.250 (talk) 03:50, 6 March 2009 (UTC)

Well, this was undocumented in Zilog's original documents, so early Z80-hardware designers probably had to figure this out by experimenting. The usage of this feature for keyboard scanning was actually described in the ZX81 article, until someone removed it. (for eZ80, even IXH and IXL was made official, btw). HenkeB (talk) 14:15, 7 March 2009 (UTC)

- The Amstrad CPC uses B to denote the OUTput port, not C. In other words, it enthusiastically, nay essentially, uses this quasi-undocumented form of addressing. This led to the vast majority of OUTs for that system taking the format LD BC,(port*&100)+data:OUT (C),C. Which, of course, means that Zilog's chosen mnemonic seems totally opposite to reality in this context. Oh - for the same reason, this also made OUT (n),A almost completely useless, too.

On Hobbit (computer), IIRC, the FORTH I/O primitives used 16-bit port address, and this was actually documented in the FORTH reference manual. And the Hobbit screen and memory extension accessory was heavily using the 16-bit port addresses to access the cache/extended VRAM on the SME board. I recall vaguely there was some conflict with the stock AY8910 Hobbit audio extension board first units (which didn't validate the port MSB to be 0), and so the AY used to start emitting sounds when the SME was used. I don't remember if this was ever fixed in later AY extension units. BACbKA (talk) 08:36, 13 December 2012 (UTC)

Different Product Numbers

It should be noted here that there are different product numbers for the z80 (check Zilog's site). Many different versions of the z80 function a bit differently.

Product numbers differ for Z80 CPU / Z80 SIO / Z80 PIO / Z80 CPU with intergrated peripherals etc., and also among speed grades, package versions (DIL, PLCC, LQFP, etc), and so on. The core Z80 is precisely the same however (except for the newer Z180 and eZ80, which are different but still Z80-compatible). /HenkeB 01:28, 9 September 2006 (UTC)

Other Undocumented Instructions

In the section Undocumented Instructions: "There are several other undocumented instructions as well." Shouldn't this have some source or a list of these instructions? Or does it just mean there are other variations of the ones already mentioned (eg loading into the upper half of IY)? 65.95.157.80 08:19, 29 September 2006 (UTC)

Sure, this remark was intended to imply that we had not forgot about these instructions, just left them out for the moment. If (when I check WP the next time) someone hasn't added a description of the few useful ones, at least, together with a little discussion on chip versions and manufacturers, I may consider doing it myself. /HenkeB 16:40, 1 October 2006 (UTC)

It should also be mention that some originally undocumented instruction over time become documented (e.g. IX is now documented combination of 8-bit IXH and IXL registers - [1]) —Preceding unsigned comment added by 89.164.231.96 (talk) 01:37, 8 April 2009 (UTC)

COMP JU+TER as Example of U880 usages

The COMP JU+TER is based on the U883 which is a variant of the Zilog_Z8 microcontroller with integrated BASIC, not the Z80. —The preceding unsigned comment was added by 212.23.126.1 (talk) 19:52, 28 March 2007 (UTC).

Musical Instruments

I have found a Rogers Electronic Organ that uses multiple Z80s (at least 20 or so). It is truly an interesting sounding organ. :) Sneakernets 05:01, 28 August 2007 (UTC)

I've added a link to the Sequential Circuits Split-8, and added the MAX (these two were relatives of the ones listed already, i.e. the Prophet-600, Multi-Trak, and Six-Trak). I've opened my Split-8 up to service it, and the Z80 is there plain to see.

P.S. that organ Sneakernets refers to is very intriguing... Rwintle (talk) 03:32, 6 July 2008 (UTC)

No Workstations

I actually worked for Zilog back when it was trying to sell systems. I wrote some of the docs for the System 8000, which I believe was their only Z8000-based system. This system shouldn't be described as a "workstation". This term wasn't applied to single-user Unix boxes until Sun was founded a few years later. The System 8000 was designed to be accessed by multiple users with terminals over serial connections. In other words, it was a time-sharing system.

All in all, though, this is a pretty good article. --Isaac R 19:54, 7 September 2007 (UTC)

Military use of Z80

I've read in an aviation magazine that the Patriot air defense system uses 6 x Z80 processors. I can't find more references right now, but I think that sticks with the "The Z80 was also used in the defense industry". —Preceding unsigned comment added by 79.107.73.166 (talk) 05:07, 28 October 2008 (UTC)

Hard-optimized?

It also turned out to be quite useful for hard-optimized manual assembly coding. (in section Programming model and register set)

Can somebody tell me what this means? (They don't mean "hand-optimized", do they?)

Thanks

--thundt (talk) 17:30, 30 April 2009 (UTC)

CoPocessors

I did not find information about the coprocessors. Like 8080, Z80 could not multiply and divide. Was created the firm arithmetical coprocessor, such as i8231? And the floating-point-coprocessor of as i8232? Or Z80 could use those developed Of intel for i8080 coprocessors? Marlagram (talk) 17:20, 1 June 2009 (UTC)

Soviet Clones

I've done a minor edit to the article. I've removed mentioning of KR580 CPU which is irrelevant to this article, as it was i80 clone. T34 and 1858 were not "slightly" different than original z80's, but complete copies. T34's were German made chips (U880?) put cased by Angstrem fab in Soviet Union. 1858 was supposed to be completely built by Angstrem, but I can't find more info on this. —Preceding unsigned comment added by 216.38.138.34 (talk) 19:05, 1 June 2009 (UTC)

original research

I've tagged this article with "original research" because there are vast amounts of text with no distinct references. There are many examples of strong claims with no references:

  • "The Z80 quickly took over from the 8080 in the market," where "quickly" is a vague weasel word, as is "market".
 Fixed Removed "quickly", and sourced statement. --LjL (talk) 13:38, 17 July 2009 (UTC)
  • The source code is completely unreferenced and un-verified
Which source code? Do you mean the table comparing opcodes of related processors? --LjL (talk) 13:38, 17 July 2009 (UTC)
Yes, that source code. The caption says this is a small program; nothing there is sourced, and it's almost completely without context anyway. -- Mikeblas (talk) 06:41, 21 July 2009 (UTC)
Uhm, but the caption does not say it's a small program...? It merely says it's an illustration of four syntaxes - and I personally doubt it might be a program, anyway, as I don't know of many programs made entirely of "LD" instructions. I've sourced the Z80<->8080 part, anyway. --LjL (talk) 14:58, 22 July 2009 (UTC)
  • The Masatoshi Shima quote is un-cited and should be deleted immediately until a reference for the quotation is found.
 Fixed Quote removed. --LjL (talk) 17:00, 17 July 2009 (UTC)
  • "The bit set, reset, and test instructions are well adapted to I/O control." is a matter of opinion.
 Fixed Assertion removed. It'd probably be more relevant on an article specifically about such kinds of instructions. --LjL (talk) 18:34, 17 July 2009 (UTC)
  • There are assertions without basis, such as "because the flag-influencing properties of the 8080 had to be copied for compatibility"
 Fixed Changed into "were copied", without giving a reason. I suppose it can be cited if it's still very controversial notwithstanding the toning-down. --LjL (talk) 01:03, 18 July 2009 (UTC)
  • The "Undocumented instructions" section is dubious: documenting them here makes them documented. It doesn't scope the lack of documentation, nor the vendors which did or did not implement the unnamed op-codes.
☒N I don't agree. "Undocumented instruction" customarily means an instruction that's not documented by the maker; that's an old and definitely attested usage of the term, so much that the very Illegal opcode article on Wikipedia gives it as an alternative term. It's quite obvious that if someone knows about them, then they are "documented" somewhat, but this is not predicate logic. --LjL (talk) 17:50, 17 July 2009 (UTC) Anyway, I've added citations for the main instructions described, as well as to substantiate the use of the term itself. --LjL (talk) 00:25, 18 July 2009 (UTC)
Even so, that the op-codes were un-documented by the maker is not too easy to source. "illegal opcode" isn't appropriate, since the opcode is legal, just not documented. "implementation defined" would probably be best. -- Mikeblas (talk) 06:41, 21 July 2009 (UTC)
Except that it's a neologism as far as processors instructions go, and as far as I can see, and most certainly not the WP:Common name for this. A Google Books search gives me naught for Z80 and implementation defined. "Implementation-defined" is a term that is often used for C/C++ implementations where things aren't clearly defined by the ANSI standard. It's not routinely used for undocumented processors instructions. "Undocumented instructions", on the other hand, is. I'm sure that, after all the fuss you made about alleged original research, you wouldn't want to do any yourself - so, let's stick to the well documented "undocumented instructions". --LjL (talk) 13:09, 21 July 2009 (UTC)
It's quite easy to determine if certain instructions/opcodes are undocumented; check the processor's databooks. If the instructions/opcodes are not documented by the manufacturer but have been documented by others, they are by industry terms "undocumented". The "undocumented" opcodes for Zilog processors such as the Z80, Z180, etc have actually been very well documented by experts. A large amount of this information is available at [2] --Tothwolf (talk) 21:34, 21 July 2009 (UTC)
  • The "Instruction execution" section is entirely un-cited, and it's entirely possible that it also applies to only certain vendor's implementations of the processor, or certain versions of the processor from the same vendor
It'll need to be sourced, but keep in mind the article is primarily about the Zilog Z80, so what matters to that section is that those bits of information are true for that vendor. And I know that they are (but again, yes, it needs sourcing), as those timings were often heavily relied upon by programmers. --LjL (talk) 13:38, 17 July 2009 (UTC)
 Doing... A citation about that is added. --LjL (talk) 14:51, 18 July 2009 (UTC)
  • The claim that a certain list of processors is "fully compatible with the original Z80" is very substantial, and deserves references.
 Fixed Added references for the claim about the Z180, 64180, 84013 - wording removed in other cases where it's barely relevant anyway --LjL (talk) 15:21, 20 July 2009 (UTC)
  • "partially compatible" is weaselly.
 Fixed Removed the "partially", although generally speaking I don't find it very weaselly (a processor can be compatible with another only when restricting to a subset of instruction, but it's probably not an encyclopedia's job to explain that in full detail). But in this case, I agree, it was a bit weaselly ("they're not binary compatible at all, but they're still partially compatible"). Calling them "derivatives" is enough. --LjL (talk) 13:38, 17 July 2009 (UTC)
  • "non-compatible" deserves references
 Fixed Referenced it. --LjL (talk) 15:21, 20 July 2009 (UTC)
  • "prduced in large numbers" is unreferenced and weaselly
Where does it say that? --LjL (talk) 18:28, 17 July 2009 (UTC)
  • "notable uses" is completely unreferenced
 Doing... References are in the process of being added. --LjL (talk) 17:00, 17 July 2009 (UTC)
Not all of the TRS-80s were Z80 based. The TRS-80 Models I, II, III, 4, and 4p certainly were. The Model II used a Z80 but could also accept a Motorola 68000 processor card. The Model 16 (which looks similar to a Model II) used a Motorola 68k but also used a Z80 for I/O purposes. The TRS-80 Color Computer line used the Motorola 6809 and the Model 100 used the Intel 80C85 (which is mostly compatible with the Z80).
Not all of the Sharp MZ systems used a Zilog Z80, some of them (the MZ-700 for certain) used the Sharp-produced LH0080 Z80 clone (which was also used in many other Z80 compatible systems from the time period).
--Tothwolf (talk) 22:24, 17 July 2009 (UTC)
 Fixed Specified that not all models necessarily have a Z80. I think more specific information should only be provided in the respective articles. --LjL (talk) 14:30, 18 July 2009 (UTC)
I'm not sure... I don't think its fair to say most of the TRS-80 models were Z80 based, but maybe roughly half of the models were. The Sinclair ZX81 also used the NEC µPD780C in large numbers, but like many manufactures, Sinclair seems to have also used genuine Z80s as well. --05:57, 19 July 2009 (UTC)
  • Several of the footnotes contain assertions which should be referenced; #7, #9. #8 is synthesis. #6 mentions some "Special assembler", which seems quite remarkable and should be referenced.
I'm not sure which references you mean now... #7 has been added by me, and it is a reference, so I assume you mean some others. I had assumed they were all quotations from the reference "Zilog Components Data Book", but I suppose some might not be (some don't especially sound like they are, admittedly). --LjL (talk) 13:38, 17 July 2009 (UTC)
 Doing... I've fixed the one about a "special assembler", anyway, by providing sources. --LjL (talk) 00:53, 18 July 2009 (UTC)

There are many other issues in this article. I didn't initially enumerate any of these issues on the talk page here because I thought the problems with the article to be obvious per Wikipedia policies, and do so now only because clarification was requested. -- Mikeblas (talk) 04:58, 17 July 2009 (UTC)

Well, that particular template (as opposed to "Unreferenced" or "Refimprove" for instance) does require explaining the issue on the talk page. Thanks for doing it.
If you don't mind, I'll use this section as a sort of to-do list, so my comments may change after changes to the article. --LjL (talk) 13:38, 17 July 2009 (UTC)
I think a significant of your concerns has either been addressed or been tackled to the point where the reasonable assumption is that the statements in the article are not original research, but are merely in need to be sourced. Therefore, I'm changing the tag from Template:Original research to Template:Refimprove at this point. --LjL (talk) 22:53, 17 July 2009 (UTC)
What you call a "table" isn't really a table; it's source code of an algorithm re-implemented in different languages. The whole section is speculative and unreferenced. While you've sourced a lot of things in the article, you've really improved the problem: it's full of speculative and arguable opinion. -- Mikeblas (talk) 05:31, 19 July 2009 (UTC)
WP:SOFIXIT, but don't go around removing whole sections at random. Thank you. I have addressed part of the concerns you expressed, and I have stated my intention to address the rest. If you have not expressed the "right" concerns, that's your problem, not mine. Find sources. I have shown that sources could be found for a lot of the stuff that you just labeled "original research". Have you looked at the documentation for the template you used? It says: "This template should not be applied without explanation on the talk page, and should be removed if the original research is not readily apparent when no explanation is given". You treated me almost as if you were doing me a favor by caring to explain what your problems with the article were. That is not the case. Do you actually have evidence that stuff you're removing is original research? If it's just unsourced, then help source it, not remove it. Thanks. --LjL (talk) 13:22, 19 July 2009 (UTC)
I fixed it by removing the material. Original research is not permitted here. There's nothing notable about the uses; the choice of this part (if this part really was the one used) didn't make most of the listed products materially different. Even stipulating that the products are using this processor, is that fact encyclopedic in any way? Are you asking me to provide a reference to show that some material isn't referenced? How would I possibly "prove" that? This article is making claims about several companies and dozens of products. It's irresponsible to publish them without verifying they're true. So, let's not publish them until we know them to be true. That's why a deletion is in the best interest of the site and its readers.
Then if that's what you think, feel free to lobby for modifying WP:PRESERVE (don't expect my help with that, though...). But while it's there, please respect it. This is hardly a biography of living persons or anything sensitive, and I had already indicated my intention to source the problematic parts, and you can clearly see that I'm doing it. Honestly, I believe you've been exceptionally rude. --LjL (talk) 13:04, 21 July 2009 (UTC)
Sorry you feel like it was a favor. The reason I didn't initally provide a comment was because I thought the fact that the article was OR was obvious: nothing is referenced, strong claims are everywhere, there's lots of POV, and there are many weasel-isms. Given a punch list tends to make only those sections identified better, while other problems persist. -- Mikeblas (talk) 06:26, 21 July 2009 (UTC)
So let's blank the whole article, aye? --LjL (talk) 13:10, 21 July 2009 (UTC)

Another derivative

ROHM Electronics manufactured a derivative with part name BU184C00. I do own one, plastic 40-DIP: 

     ROHM
 BU184C00A-PS

Z80CA CPU 806 809A I'm not sure how to include this part in the main page so I leave this comment here. —Preceding unsigned comment added by 95.214.61.45 (talk) 19:57, 20 January 2010 (UTC)

Notable uses

I wonder my changes to the notable uses in desktop computers were reverted, because I thought it made sense to mention 2 of the most well known machines featuring that cpu (which I would think is a "notable use"). Even more so when it seems worth mentioning machines (like the C128) which only used that cpu as kind of an add on. 193.16.163.152 (talk) 14:15, 3 August 2010 (UTC)

See the edit comment. We have a list of popular Z80 computers. The ones specifically listed in the article should be notable in some way; for example, it is peculiarly notable that manufacturers of computers with other processors thought that access to Z80 programs was commerically worth developing add-ons for a Z80. If we don't use the links, pretty soon this article will be overrun with everyone's favorite Z80 computer and it will be useless as an article. --Wtshymanski (talk) 15:16, 3 August 2010 (UTC)

Z-80 price

The Zilog Z-80 was more expensive than the Intel 8080. This October 1977 mail order advertisement. lists the Z-80 for $36.95 and the 8080A for $15.95. The October Jameco Electronics ad in Popular Electronics listed the Z-80 for $24.95 and the 8080A for $10.95. There were many mail order suppliers and pricing was very completive. The Z-80 price was always higher than the 8080 price. I uploaded the advertisement because it used a large type font; most ads were in 6 point or smaller type. -- SWTPC6800 (talk) 03:47, 3 November 2010 (UTC)

Exxon

In the picture, it show that Zilog is a Exxon partner, is that true? --190.21.187.34 16:51, 8 February 2011 (UTC)--190.21.187.34 16:51, 8 February 2011 (UTC) —Preceding unsigned comment added by 190.21.187.34 (talk)

FAOL

In case anyone thinks the FAOL banner above is useful for improving this article, it appears the Italian Wikipedia version of the Z80 article is based on translation of the Sept. 2010 edition off en.wikipedia. The Italian Wikipedia doesn't seem to mind using "loc cit" in footnotes, but somehow I don't think that's the key to its featured article status there. --Wtshymanski (talk) 19:15, 13 May 2011 (UTC)

Suggest merge

The Sharp and NEC second-source parts have about 1 paragraph each. Should these not be merged to the present list of second-source parts? If we're hurting for space we could delete the description of microprocessors that aren't from Zilog and that dno't have any compatibility with the Z80. --Wtshymanski (talk) 13:48, 11 July 2011 (UTC)

already merged by the time I got to it :P Sn1pe! (talk)(edits) 00:11, 28 January 2014 (UTC)

Z80 In-Circuit Emulator

Was wondering if there is scope here for some in-depth discussion of some of the Z80's more interesting attributes. Here is my context : I met the Z80 in the late 70's and it was love at first sight (after I'd fallen out with the 6502). The first detail which I liked were the tri-statible control lines - particularly the address bus. Instantly I recognized the potential for a low-cost in-circuit emulator using a minimal architecture at a time when it wasn't easy to persuade my then employer to part with hundreds of pounds at a moment's notice. So I set to work and developed a fully-functional Z80 ICE in 3 weeks just in time to present a paper on it at Loughborough University in England (around 1978). Anyway, it would be nice to resurrect it (modernized of course) if anybody is interested.DkellyZ80 (talk) 20:17, 21 August 2013 (UTC)

T-cycles

This Zilog Z80 article mentions T-cycles. The Intel 8008 article mentions T-states. What are T-cycles? Are T-states the same thing, and if not, what are they? Are T-cycles something only relevant to the Zilog Z80, and T-states only relevant to the Intel 8008, or are they something relevant to many different CPU designs and so should be mentioned and defined in the CPU design article? --DavidCary (talk) 05:23, 9 March 2014 (UTC)

T state and T cycle are used interchangeably (perhaps incorrectly so), but you could perhaps distinguish them as a cycle being the time to shift between states. All microprocessors use these, although the "T" terminology might be specific to some manufacturers, such as the Intel/Zilog world, having a vocabulary separate from the Motorola world. Certainly Texas and their 99xxx series had a very different approach to timing issues (Owing to how clock signals were distributed, the external clock on those CPUs ran much faster, but achieved less per clock cycle).
Internally, CPUs have two design issues to make them faster: getting more processing done in a clock cycle and simply making the electronics operate faster so that clocks can be run faster. These are quite separate issues and the overall "workload" of a processor depends on their product.
The "efficiency" of a processor design can be measured in T states (or cycles). How many T states are needed to perform an Add operation etc. The fewer "ticks" it takes, the more Adds can be added in a working day.
The clock speed of a processor depends on the speed of the electronic gates within it. As this improved, the Z80 repeatedly doubled its speed from 1MHz to 8MHz. Each T state became proportionately shorter, but as the Add operation still required the same number of T states (the internal logic of the processor wasn't changing), the Add also became faster.
T cycles were used in practice, even by application programmers. If you added the T cycles to execute a loop operation, then multiplied by the T cycle time for that processor at that clock speed, you could predict the time to execute one iteration of a loop, thus how many loops would be needed to wait for a millisecond, etc.
The time of a T state relative to the clock depends on a matter of definitions as much as anything. The 99xxx clock was a multiphase clock where each external clock cycle drove relatively less of the "T cycle clock", compared to how the Z80 worked. I doubt that Texas silicon went much faster than Zilog at the gate level, but the external crystal clock was often three times the speed. As the 99xxx also used an unusual architecture with registers in memory, many operations also required more T cycles to perform than a Z80 would have done. So comparing the "working speed" of two such different processors could be tricky: on one hand one was faster, on the other hand, slower. Andy Dingley (talk) 12:01, 9 March 2014 (UTC)

Possible Errors

Why are we comparing the Zilog Z-80 to the Intel 8086/8088 processors? The Zilog Z-80 was an 8-bit processor, a "replacement for" the Intel 8080. The Intel 8086/8088 CPUs were 16-bit, source code compatible only, and came along later. It might make sense to compare the Zilog Z8000 to the Intel 8086/8088 CPUs. (But they were not very compatible.) 108.166.130.170 (talk) 12:02, 12 August 2014 (UTC) (Jeffrey Todd Grigg. I was working in the industry at the time.)

This article sucks

I came to read about the Z80, not about the 8080 or the 8085. Remove everything that isn't relevant to the Z80. — Preceding unsigned comment added by 68.79.127.40 (talk) 05:33, 19 December 2016 (UTC)

The 8080 is very relevant to the Z80, both historically and technically, as the article explains (at least partly). I will try to expand on that, when I have more time to spare. 46.236.92.150 (talk) 16:13, 15 January 2017 (UTC)
There's already nothing here that isn't relevant to the Z80. Andy Dingley (talk) 17:33, 15 January 2017 (UTC)

Built-in FOR loops; the DJNZ instruction

Is my old mind deceiving me, or did the Z80 have a built-in "FOR" loop instruction? As I recall the assembler was "DJNZ foo" (Decrement and Jump if Non-Zero to foo). It would decrement the B register and jump (back, usually, for a loop) to an address "foo" if B was nonzero. Useful in terms of simplifying programming but horribly expensive in terms of machine cycles (and so non-RISC it hurts). If I didn't dream this, was such an instruction available on any other MPs at the time? If it wasn't, it should be mentioned as a notable feature of the Z80. Tonywalton Talk 23:31, 24 August 2013 (UTC)

Tony, I have taken up your suggestion and added a paragraph for the DJNZ looping instruction. And would you believe it, the new two-byte JR instructions weren't highlighted either! Makes me wonder how 8080 coders put up with so much more non-relocatable code. Too bad our CALLs are all still absolute, but TRSDOS provides an @WHERE SVC so relative CALLs can be emulated in software.Wikkileaker (talk) 13:24, 22 June 2016 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Zilog Z80. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 05:48, 2 July 2016 (UTC)

Pronunciation

An IP address user has been repeatedly reverting edits that attempt to add the pronunciation of the chip to the article. — Preceding unsigned comment added by Mattl (talk • contribs) 16:08, 20 July 2016 (UTC)

Probably because you're adding it (repeatedly) and editing it to favour only a single pronunciation. That goes against both WP:ENGVAR and WP:NPOV. Andy Dingley (talk) 16:56, 20 July 2016 (UTC)
Removing both pronunciations was probably the wise choice. I don't think there is any ambiguity as to how to pronounce it in the US, and separately in the UK... And if you pronounce it the "wrong" way, you would most likely be understood anyway. Dhrm77 (talk) 18:07, 20 July 2016 (UTC)
Agree with removal, the reader is unlikely to be confused in how to pronounce it for themselves. A previous change comment said that "as the product is American, the American pronunciation is the correct one". There is no evidence that Zilog insisted on a certain pronunciation and 40 years-worth of UK engineers will continue saying 'zed-eighty'. It seems to be instructions on how pronounce the letter 'Z'. We're talking about the past and Wikipedia's role here is to inform, not to legislate. ToaneeM (talk) 14:50, 09 August 2016 (UTC)
Yes. With the designer of the Z80, Federico Faggin (CEO of Zilog), being Italian and his closest co-designer Japanese, the original and intended pronunciation may actually be quite different from the US- as well as the UK-version.94.245.25.21 (talk) 18:54, 11 August 2016 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Zilog Z80. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:01, 20 July 2016 (UTC)

The z-80 is binary backward compatible with 8080

It could run 8080 software as is. in fact it's own instruction set had different mnemonics then the 8080 which means you could not compile 8080 ASM source with z-80 tools — Preceding unsigned comment added by 85.250.45.1 (talk) 06:54, 24 August 2018 (UTC)

Architecture

The Z80 architecture

The file Z80 arch.svg shows registers W, Z, W' and Z'. I have worked with the Z80 for many years and have never heard of these registers. I suppose that they could be the holding registers when reading a direct address in an instruction such as LD A,(1234h), where 34h is first read into Z, then 12h is read into W, then WZ is output to the 16 bit address bus in order to read the byte at address 1234h. But this wouldn't explain the presence of W' and Z'. These registers wouldn't need to have twins in an alternate bank. Does someone have an explanation, or is the drawing wrong? Dhrm77 (talk) 13:50, 13 May 2016 (UTC)

They're the "invisible" registers. As you note, they're used by the control unit but aren't programmer-accessible or described in any opcodes, and they're used to support the direct-memory operations which made the Z80 such a welcome programming improvement over other contemporary CPUs. I've no idea if they were in the alt bank too. Andy Dingley (talk) 14:27, 13 May 2016 (UTC)

Probably the drawing is wrong, as is claimed here [1] in the accepted answer. I can't identify the source of the image, but the W' and Z' also appear here [2] which gives as source Fig. 2.14 from here [3] which is on page 64 in the pdf-file, page 65 of the book. There however the intermediate registers are not shown at all. I agree that alternative intermediate registers do not seem to make any sense. Polskiblues (talk) 12:19, 9 April 2019 (UTC)

It's generally accepted that Zaks will always be right on anything it says about the Z80. However it's only Programming the Z80, and it's such a short book (under a thousand pages! How short that would seem after a few more years of CISC processors...) that there's an awful lot it doesn't say. Certainly once all the higher-speed and non-Zilog Z80s appeared, we found that there were many ways to build an op-code compatible chip which matched the full spec of what it was supposed to do, and there were even ways to detect from undocumented side effects just which type of chip it was.
W & Z were inaccessible to programmers (if there were ways to access them, they're unknown to me, although I wouldn't be surprised if there was an undocumented LD DE, WZ or something). They were inaccessible (Zaks, pp.87–89) to the programmer deliberately: they were always modified during the direct memory operations such as LD A,(nn) (also JMP nn (Zaks, pp.89–91) ) and it was anathema to the "Z80 generation" that an operation like that could have side-effects affecting other registers (that was from the "bad old days" of processor behaviour). So they existed, and they were discussed (as the easiest way to explain the timing issues in direct memory ops, for one), but they were not accessible (neither read nor write) by 'mere mortals'. And we didn't yet have pink shirts to tell us how to do "impossible" stuff.
Were they in the alt bank? Not a clue. I suspect that it neither matters, nor was even defined by the Z80 spec. Two Z80-compatible implementations could each do it either way, and there would be demonstrably no way to even tell how they did it – they were locked that far away from the programmer. Possibly one implementation found it easier (it's only 16 more bits, after all) to just implement them twice and simplify some decoding logic. There were no "exchange" operations for them, because there were no operations to access them at all.
Now both EX <register> and EXX were both fast operations on the Z80, and equally fast. So I'd always assumed that "exchanging the alternate register values" (Zaks, pp.162–163) was nothing of the sort (the Z80 internal bus couldn't have moved that much data that fast, and certainly not doing it four times in the same number of T states!). Instead it was just some frobbing of the MUX decode and might only take storing a four bit mask somewhere invisibly internal. Did the MUX address similar pairs of W, Z, W' and Z'? Not a clue – and as there were no operations which could interrupt an operation, so as to make this visible, that just didn't matter. It was not just unknown, it was unknowable. Andy Dingley (talk) 14:53, 9 April 2019 (UTC)
I'm troubled by the registers of colour. W and Z do make sense as internal registers not to be accessed by the programmer, but necessary for instructions like LD A,(nn) where you need to store information somewhere temporarily in the CPU. However because of their temporary nature you don't need alternatives W' and Z', it only complicates your layout. i.e. any layout which has W' and Z' can be reduced by simply throwing them away i.e. putting Z and W in their place and ignoring the register-bank-switching bit set and reset by EXX. Also it seems, that the red colour seems to indicate registers accessible by the programmer. So W and Z should be grey, while I and R should be red. Polskiblues (talk) 16:25, 17 December 2019 (UTC)

References

  1. ^ https://retrocomputing.stackexchange.com/questions/6671/what-are-the-registers-w-and-z-inside-a-z80
  2. ^ http://www.z80.info/z80arki.htm
  3. ^ http://www.z80.info/zip/programming_the_z80_3rd_edition.pdf

Current Uses

I removed the template about being better written in prose (I disagree) and I added a template about more citations. A good source I've found is Google patents, after 2000: https://patents.google.com/?q=z80&after=priority:20000101 If anyone wants to contribute more uses about this fascinating CPU, I'll be willing to help. https://stackoverflow.com/a/49392402/3163618 Wqwt (talk) 19:19, 20 March 2018 (UTC)

@Wtshymanski: Granted, the list can probably be pruned a bit but I would not delete it altogether. I think that systems using the Z80 which have their own Wikipedia articles should be listed here. For now I'll restore the existing list. Drahtlos (talk) 20:27, 28 March 2019 (UTC)

I'm not a fan of that list. It's such a scatter-gun of "things which used microprocessors at the time that the Z80 was a popular microprocessor". Were any of these made possible by the Z80? Was the behaviour of the Z80 particularly evident through them? S-100 and CP/M, yes, but otherwise? Andy Dingley (talk) 20:56, 28 March 2019 (UTC)
Agreed. It's a cruft-attracting list and gives the reader no sense of "why" a Z80 was chosen for any given job, other than it existed. --Wtshymanski (talk) 21:39, 28 March 2019 (UTC)

Is the NSC800 a "second source" or a "derivative"?

It's a clone (some sources say there are enhancements, but I haven't found any yet) as far as software is concerned, but has a different pinout with an 8085-style multiplexed bus, so isn't hardware compatible.

If I can find the claimed enhancements, it goes into "derivative".

Ref: https://media.digikey.com/pdf/Data%20Sheets/National%20Semiconductor%20PDFs/NSC800.pdf
Ref: //sci-hub.st/10.1049/ep.1981.0107
64.44.80.252 (talk) 04:19, 9 January 2021 (UTC)

Bugs: we really should have a source for this

Under Zilog Z80#Bugs we list a bug that I couldn't find mentioned anywhere else. From the description, it would be a bug, as the User's Manual says that the condition bit C is not affected by OTDR. However, I think that this wouldn't be such a difficult bug for users to run into, and this makes me think that it should be more widely reported around the Internet. Lastly, there's also a slim chance that it may have been a bug in a few chips, not all Z80s.

Pinging Dhrm77 who introduced this section in [3], who claims to have "(...) found the problem described back in 1991 while making extensive use of the OTIR and OTDR instructions (...)": do you remember where you found it described? Did you try and manage to reproduce it? BernardoSulzbach (talk) 18:22, 6 July 2021 (UTC)

I never found it described anywhere. I had written a program using a lot of OTIR and OTDR and optimized in such a way that the state of the Cy was important. The program wasn't working as expected, and I eventually found out that although the Z80 documentation says that OTDR doesn't affect carry, it in fact does. Furthermore, I wanted to know how it affected Cy. And after many experiments, I found out that it does a spurious compare between the last (or perhaps all) bytes being transferred and the Accumulator, and the result of that compare is what sets or resets Cy. I forgot what I did to solve the problem, either not use Cy to store some information, or save the flags... Also I don't remember which exact processor I was using, it could have been the Mostek equivalent MK3880, the SGS Z84C00, the NEC µPD780, or the actual Zilog Z80 running at either 4Mhz or 6Mhz. And I'm not sure if I tried other processor to determine if the bug exist across multiple versions of the Z80, So it is possible that the bug only exists in some versions. But for anyone who still uses a Z80, it's a very simple matter to verify the problem. I think I remember later trying that bug on a Z180, and found that in fact the bug doesn't exist on that processor. Email me if you have more questions. Dhrm77 (talk) 21:11, 6 July 2021 (UTC)
Also, I am not surprised that nobody else found the problem. What I was doing was a little special. I had to send a lot of bytes to a particular port, out of order. For example, send 4 bytes in ascending order, then the next 4 bytes in descending order, then the previous 4 in ascending order again, and so on... So I would use OTIR, then add 3 to HL, use OTDR, subtract 17, use OTIR again, and so on... The problem is that there is no SBB instruction for HL, you have to use SBC which uses Cy. So Cy needs to have the right value, otherwise you are sending the wrong bytes. This isn't typical programming. So no wonder no-one else found the problem. Dhrm77 (talk) 21:27, 6 July 2021 (UTC)
In this forum thread (in German) people tested various CPUs and found that the orignal Zilog Z80 does indeed have a bug with the CY handling for the OUTI opcode while the East German U880 and the Romanian MMN80 do not. Drahtlos (talk) 22:02, 6 July 2021 (UTC)
Interesting... My problem was with OTDR, not OUTI, but the 2 instructions are related, and neither should affect the Carry. That's interesting how they use that bug to distinguish between 2 brands of processors. Perhaps someone could gather more information about that, and expand that section. Dhrm77 (talk) 01:50, 7 July 2021 (UTC)

TLCS 90

is not a Z-80 compatible device. This device has all instructions Z-80 have, but instruction binary bit-assigns are completely different, and does not have binary compatibility. 2400:4051:4CE0:C400:922B:34FF:FED6:A16D (talk) 11:09, 15 August 2021 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Zilog_Z80/Archive_1&oldid=1253490972"