Z80, the 8-bit Number Cruncher (2011) | Hacker News Reader

Z80, the 8-bit Number Cruncher (2011)

andreadrian.de

65 pointselvis7059 comments

Nice article!

Back in the day I wrote 10s of thousands of lines of Z80 assembler - it was my first actual paid job after university.

You got to know each register - they have their own character - need a loop - well you need B and DJNZ, need programmable IO, well you need C then, etc

I still have a soft spot for the Z80!

Reading that article I learnt some great techniques! The code I was writing always used the alternate register bank for interrupt handling so you could have really fast save and restore registers.

I never thought of using them to pass parameters and doing fast arithmetic - very neat!

    ; ADD ROUTINE 32+32BIT=32BIT
    ; H'L'HL = H'L'HL + D'E'DE
    ; CHANGES FLAGS
    ;
    ADD32:
        ADD     HL,DE   ; 16-BIT ADD OF HL AND DE
        EXX
        ADC     HL,DE   ; 16-BIT ADD OF HL AND DE WITH CARRY
        EXX
        RET

I loved writing Z80 assembly back in the 1980s but it was a bit of as shock to find out from Ken Shirriff [1] that this 'number cruncher' had a 4 bit ALU.

[1] http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-h...

EDIT: Just to be clear this is in no way intended to be a criticism of the Z80. On the contrary it's a tribute to the ingenuity of Federico Faggin and Masatoshi Shima that they were looking for ways to 'save' transistors in the ALU in a way which no-one would notice, which presumably enabled them to add more features elsewhere.

The Z80 is not above criticism. Its fancy loop instructions were slower than a regular loop.

But the 4-bit ALU was the result of a very astute observation that inefficiencies in the 8080 microachitecture would hide an extra ALU cycle.

Okay guys, this may be off-topic, not sure as I've not finished the article yet.

What (wiki?)books can I purchase that would help me bridge my mental understanding of computer circuitry from 'this is a circuit with a resistor and a power source and a lightbulb, while this is a CPU that has wires to memory and magic happens to make em talk' to 'I know the difference between TTL logic and a microprocessor and can fuzzily trace where the electrical signals go'?

I don't own but am aware of things called logic analyzers, 'progammers', and the difference between a microcontroler and a microprocessor (ish, the former is vaguely a system on a chip?), but I'm not sure where to start to fill in the many gaps in the bits of knowledge I have so far.

Wikipedia feeds me articles about logic gates, programmable logic, and Algorithmic Logical Units used in things like the Xerox Alto, but I don't know if this means I should try for electrical engineering courses or something simpler?

Not 100% sure this is precisely what you're looking for but Ben Eater's YouTube series on building an 8 bit computer is great to help build understanding how a microprocessor works.

[1] https://www.youtube.com/watch?v=HyznrdDSSGM&list=PLowKtXNTBy...

Thank you! I will definitely give this a try.

What a helpful online community.

I'm not sure what you're looking for (maybe I mis-read your requirements above), but for the step from "I understand the idea of simple boolean logic" to "I understand (quite concretely) how a Z80 (or 6502 or similar) CPU works", I'd recommend the book "The Elements of Computing Systems" from the Nand2Tetris site: https://www.nand2tetris.org/book

It's what made things click for me.

[EDIT: I also second Klelatti's suggestion... Ben Eater's youtube channel is ALL gold. He's an amazing teacher. I also purchased his clock module, and the 6502 kit - they are awesome!]

This is exactly what I was looking for, thanks. I will order that book and check out that YT channel as well, I prefer books to videos, but sometimes a video is worth 1 million words.

I don't know about books, but I learned about this in my first year in university (for CS-ish), and it was fascinating :)

I think the missing link you're looking for is the flip-flop [0]. It's a clever arrangement of logic gates (just AND, OR, NOT, etc) that can store a bit. The concept of a clock signal is very closely related. Then you learn about multiplexers and you realize that if you put a bunch of flip-flops that can store a bit behind a multiplexer [1], suddenly you have something that looks like very primitive RAM with a data and address bus!

At the time it blew my mind that you can (conceptually, at least) take a bunch of logic gates, arrange them in clever ways, and arrive pretty quickly at much "higher level" concepts like memory on an address bus.

[0] https://en.wikipedia.org/wiki/Flip-flop_(electronics)#D_flip...

[1] https://en.wikipedia.org/wiki/Multiplexer#Digital_multiplexe...

I don't have a great answer for you but I'll give it a shot. It sounds like you're trying to get from a basic understanding of analog circuits to understanding the makeup of a simple processor (e.g. the Z80).

The general progression is:

  1. Circuit Theory (how fundamental components work)

  2. Semiconductors(diodes, transistors, op-amps [skip those for now])

  3. Digital Electronics (basic logic gates and boolean algebra)

Once you finish learning about digital electronics you should have the fundamental knowledge to understand how a basic processor might operate. A reasonably good place to start might be here.

https://www.allaboutcircuits.com/textbook/

Read Volume 1, Volume 3 (skip chapters 7-13), and Volume 4. That should get you up to speed reasonably quickly.

Thanks for this, I was hoping to get a sketch of how I should orient my big-picture roadmap to understand digital electronics from the old 'electric light circuit kit' i used to have. While I can't claim that I'll complete this stuff quickly as the sibling reply mentions, I will certainly look into it.

Its about 4 courses (semester long) worth of studying I would consider essential. One circuits analysis course, two digital design courses, and computer architecture. By the end you should be able to build a simple RISC cpu on an FPGA.

This would be the right approach, but a multi-year one.

Try Charles Petzold's book "Code: The Hidden Language of Computer Hardware and Software". It goes through the structure of a computer at the binary level in a gentle way that's aimed at non-specialists.

There are a few amazing books out there:

Code by Charles Petzold, The Elements of Computing (Nand2Tetris course book), No Starch Press's Secret Life of Programs, Learning Computer Architecture with Raspberry Pi

I would recommend "But How Do It Know?" by J. Clark Scott.

I had built (with a couple of other people) a TCP/IP stack for the Z80 in the late 90s. And a small HTTP server to go with it. It had a weird CGI like interface to call some subroutine for a path. The intention was to use it in some kind of industrial equipment where users could directly point their browser to this HTTP server and get status updates. A super simple IOT, if you will. This was actually for Zilog itself who were positioning the (already faded) chip for embedded networking.

It was perfect for such applications!

Good memories.

Dataprobe's original "iBoot" worked like this:

http://dataprobe.com/iboot-hub/

It had a built-in web server running on an 8051! It interfaced with an Ethernet chip using a parallel FIFO interface- maybe NE2000 based chip? I don't remember..

I had a similar parallel interface to an Ethernet daughterboard. I too don't recollect the make. But there was a serial PPP based option as well - it made perfect sense when main stream modems were anyway 9600 baud or lesser.

One trick I used a lot with the Z80 is the conditional return instructions. Instead of doing a jump, structure your functions so you could return early on one of the condition flags. The jump instructions were 3 bytes, the return instructions were only 1.

And it could also save time. The Z-80 conditional return takes 5 cycles (or "T-States" in Zilog terminology) to execute if the condition is not met and 11 cycles otherwise. Quite worthwhile in testing for uncommon cases. Consider this routine to print a message that is terminated by nul or newline:

   PMESS  LD   A,(HL)     ; get character from message
          INC  HL         ; move message pointer to next character
          CP   10         ; newline?
          RET  Z          ; return if so
          OR   A          ; zero?
          RET  Z          ; done if so
          CALL PCHAR      ; print character
          JP   PMESS      ; keep looping

If instead of "RET Z" we had to do a conditional jump to a return it would be 10 cycles for each test instead of 5.

          CP   10
          JP   Z,DONE     ; 10 cycles, jump taken or not
          ...
          JP   PMESS
   DONE:  RET             ; 10 cycles, BTW

The conditional return just happens to be cheaper if not taken because it skips the work of popping the return address off the stack. Though purely an outcome of the implementation you can treat it as sort of a branch prediction.

Incidentally, the Z-80 also has relative branches (JR) that differ in execution time whether they are taken or not. The branch offset is a single byte so JR is only 2 bytes compared to JP's 3. A JR is 7 cycles if not taken, 12 otherwise. Again, we can treat it as a hard-coded branch prediction that predicts the branch is not taken. If space or distance to target is not a problem, a JR is faster if taken less than 60% of the time.

> The jump instructions were 3 bytes

Absolute jumps ("JP") were 3 bytes, relative jumps ("JR") were two, whether conditional or not -- but, that's still longer than the 1-byte return instruction...; Though, absolute jumps were the fastest - they did not need to access the stack and adjust SP like "ret", and did not need to do addition like "jr".

I used to know the opcodes by heart, but I last wrote Z80 code in 1987, and last wrote x86 machine code in 1997, and nowadays I don't remember all of the binary representations, and sometimes I get the binary representations of the two mixed. I'm getting old ...

It was only useful when stack wasn’t involved I presume?

Not sure about Z80 but stack is a bit of a luxury on 6502 ...

The Z-80 stack pointer (SP) is a full 16 bit register. The stack can be anywhere in memory and be as large as needed.

The 6502 has only an 8 bit stack pointer which points into page 1 only (addresses 0x100 .. 0x1FF).

The Z80 stack was only limited by your memory size.

The Z80 was the chip in the original Radio Shack TRS-80 computers. I got one back in 1979, when I was 15 years old. I had a book on the Z80, the text in this article brings back memories, and figured out how to do some simple machine language programming. Mostly simple graphics programs, storing values to the TRS-80's display memory buffer. Eventually I got the TRS-80 Assembler that made things a bit easier. I can't remember now how I actually input the machine language hexadecimal without using that assembler, but I'm sure I did. Or maybe not, my memory is sometimes not so reliable on these things, even when I feel certain.

I can hardly imagine how different things must be now for young kids growing up in internet era, where everything is at your fingertips. Information was much more difficult to get back in the old days, traveled much more slowly. But, still, kids had the energy to figure things out.

Now, imagine the thrill of holding an original Intel 8080 data book behind the Iron Curtain. With impeccably drawn diagrams, on high quality paper, in stark contrast with anything produced by the Soviet industry.

8088 was only three years later than z80 and it was much better than it. But cost also matters.. I just looked at 1982 Byte Magazine at the "JDR Microdevices" ad in the back:

    Z80A   $6.00
    Z80B   $18.95
    6502   $6.95
    6502A  $12.95
    6809   $24.95
    8088   $39.95

“Only three years” is two doublings according to Moore’s law, and that law held fairly strongly at the time (transistor counts, according to https://en.wikipedia.org/wiki/Transistor_count: 8,500 (“6,813 without depletion mode pull-up transistors”) vs 29,500), so of course it was much better.

For me the it's disappointing how small a step forward the 8088 was from the Z80 given the increase in the number of transistors.

It came a few years later but the ARM1 which used 25,000 transistors and was built on roughly the same process size [1] and was much faster than the 8086/8088 shows what might have been had Intel gone down a RISC route.

[1] https://en.wikichip.org/wiki/acorn/microarchitectures/arm1

> It came a few years later but the ARM1 which used 25,000 transistors and was built on roughly the same process size [1] and was much faster than the 8086/8088 shows what might have been had Intel gone down a RISC route.

The 8086 the 8088 was based on was released in 1978. The ARM1 was released in 1985. That was an eternity.

It was a long time but the ARM1 didn't benefit because of the development of Moore's law over that period - if you look at the process, die size and clock speed it's all comparable with the 8086 - the ARM1 was built with very mature (and cheap) technology.

As has been said elsewhere the ARM1 wouldn't have worked commercially in 1978 because of code density and bus width.

Well, okay, but it seems more significant to me that the ARM1 did not exist in the late seventies - which would have been really great - because the field advanced. The original comment struck me as a bit strange because it implies that Intel just made a single bad call, or something.

Very much agree - I was (not very effectively) trying to make the point that its not just about transistor counts and that what you do with those transistors - the field advancing as you say - matters a lot too. Credit to Hennessey etc who developed the original RISC concept.

I do think though that if you look back at the history Intel put huge resources into the iAPX432 which was hugely overambitious and they had to rely on the fallback of the 8086/88. There is probably a reasonable case that if they had hadn't split their resources we might have had something better than the 8086.

I think you needed cheaper RAM also to enable RISC. At the very least, a 32-bit wide interface was not going to fly this early.

You're absolutely right: ARM1 code density would have been much, much worse than 8088 (which Thumb partly solved later on) and the 32 bit bus wouldn't have been practical.

Edit: By complete coincidence browsing some related Z80 came across your memcpy comparison which is fascinating. The step up to the ARM1 is remarkable. I think I remember Herman Hauser saying that Acorn approached Intel for an x86 chip with higher memory bandwidth but were rebuffed and that led to the development of Arm.

The King of the era was 68000. 1979. Way ahead of time, comparable to 80286 in many ways, or even 386.

According to Sophie Wilson, the reason Acorn had to design ARM was that the 8086 and 68000, with no cache, were limited by their bus bandwidth, and so weren't really faster than a contemporaneous 6502; their only real advantage over it was a bigger address range.

She is in a position to know.

There was no ARM in 1979. At the time ARM came into existence, there were already much faster 68010-68020. The biggest advantage of 68000 is much nicer ISA. 6502 was fast in case of making simple integer computation; for math is was really bad.

I think it's fair to say when the Acorn team were considering what to replace the 6502 with the chips they compared with were the 68000, 32016 and 80286 - and they felt in each case that memory bandwidth was the constraining factor. In the end the Arm1 with 29,000 transistors had performance that was as good as or exceeded the 68020 with 200,000.

Incidentally, Robin Saxby the first CEO of Arm previously worked for Motorola and tried to sell the 68000 to the Acorn team!

Steve Furber has said the same thing and Herman Hauser has said they approached Intel for an 8086 with higher bus bandwidth, but were turned away!

Moore's Law allows later and more sophisticated processors to compete in price with earlier ones. But a separate factor is the "learning curve". The same chip built in the same old process node will get cheaper over time as production grows. The fixed costs will have been amortized, the per wafer yield will tend to go up and so on. That allows a processor initially sold for $300 to be sold for less than $10 five years later.

I'm not sure it's universally "better". The 8088 takes a lot more clock cycles for some operations. The 16 bit internals are certainly better, but it did have an 8 bit bus.

You can still buy new TI calculators powered by a Z80. Pretty long-lived platform.

They are pretty amazing, because you can start with Ti-Basic and once you're hooked you will want to know all about writing assembly. Doing that with the rich ecosystem/libraries and community available is much easier than doing the same with just the processor alone. You can load your games (presumably) with USB and have cursor keys right below the screen yay!

Unfortunately, TI did make ASM much harder to do earlier this year. There is a jailbreak for some OS versions: https://linustechtips.com/main/topic/1198899-texas-instrumen...

Interesting article.

Indeed the Z80 was used in the Amstrad CPC series. There, the firmware used the alternate register set for bookkeeping, so you could use them only in a code region surrounded with interrupt dis/enabling and saving/restoring them. The floating point format on the CPC is 40 bits, probably one of the formats mentioned in the article.

A few people still create prod for the Z80 every year, there are already 10 productions registered in 2020 on http://www.pouet.net/prodlist.php?platform%5B%5D=Amstrad+CPC...

The CPC had a huge graphics memory for the time: 16k, making nice-looking games in paper catalog but very limited full-screen animation without piles of hacks.

Lots of actual number crunching for 3D graphics in thi old prod "All in 3D" https://www.pouet.net/prod.php?which=14667 (no video, you have to run it e.g. in an emulatoe).

For an exceptional result of Z80 performing number crunching and graphical hacks, see this nice demo from 2017 "Amstrad CPC demo : Logon's run - 3D meets the aging bits" https://www.youtube.com/watch?v=22wSm4y27Wk . Or "Batman Forever" demo of 2011 https://www.youtube.com/watch?v=_syHewDu5lc

I personally made a production this year https://gourichon.org/cpcitor/justget9/beta/ a puzzle game with smooth animation, which got awarded at a local contest https://www.facebook.com/groups/1120607071477318/permalink/1...

I noticed an error in the "Z80 IF-ELSE" section. It says that the overflow flag is the equivalent of the carry flag for signed numbers. But this is wrong. The overflow flag indicates that the result of the signed operation is wrong. In fact, it is the sign and zero flags that should be tested. In case of overflow, the sign must be reversed.

See this document about the carry and overflow flags: http://teaching.idallen.com/dat2343/11w/notes/040_overflow.t...

The code for comparing HL >= DE should be: (Replaced JP PO by JP M + inversion of the sign if overflow)

  ;==================================================
  ; IF-ELSE CODE FRAGMENT
  ;
          LD      HL,-2000        ; HL = -2000;
          LD      DE,-1000        ; DE = -1000;

          AND     A               ; if (HL >= DE) {
          SBC     HL,DE
          JP      PO,NOOV
          LD      A,H             ; INVERSE SIGN BIT IF OVERFLOW
          XOR     80H             ;
  NOOV:
          JP      M,ELSE
          LD      A,1             ;   A = 1;
          JR      ENDIF
  ELSE:                           ; } else {
          LD      A,0             ;   A = 0;
  ENDIF:                          ; }
          HALT
  
          END

For anyone interested in Z80 assembly, the ZX Spectrum ROM disassembly, recently discussed on HN [1] is a treasure trove of annotated Z80 code including a full set of floating point routines.

[1] https://news.ycombinator.com/item?id=23757449

1977 me had to choose between a TRS-80 and an Apple ][. Apple had the games & color but man, the Z80 was so much nicer for assembly programming than the 6502. Z80 assembly and TRS-80 BASIC got me started on a lifelong career and passion.

People make low bit general purpose CPUs with modern processes? Or devices that use such CPUs still use ones with ancient designs?

They're cheap and easy to use.

https://www.digikey.com/catalog/en/partgroup/z80/15507

Most moderate complexity ICs have a microcontroller inside. Depending on performance needs an 8-bitter is sufficient. These will typically be a clone of an established architecture so that tooling is readily available.

Well... exactly.

Thing is, since I am a game-dev: it would be cool to have a cheap console or portable console that runs at quite high speeds.

For example what would be possible if I had a Z80 that ran at 2ghz?

Running an old 8-bit design at a very high clock speed would probably consume more power than a slower clocked ARM chip which could process as fast or faster due to the higher complexity of the chip. Using an old 8-bit design only makes sense when the computing requirements are extremely modest.

The TI 84 Plus CE graphing calculator has a 48MHz eZ80, a 320x240 16-bit color display, 154KB of RAM, 3MB of flash, and a built-in rechargeable battery. No audio capabilities, though.

Z80 machines of the 8-bit era were typically 2MHz or 4MHz.

> what would be possible ...

Toasted Z80

Reply on news.ycombinator.com