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!
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.
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.
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.
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
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:
“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.
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.
> 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.
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.
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!
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.
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.
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 ...
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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).
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.
60 comments
[ 2.0 ms ] story [ 123 ms ] threadThing 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?
Toasted Z80
Z80 machines of the 8-bit era were typically 2MHz or 4MHz.
https://www.digikey.com/catalog/en/partgroup/z80/15507
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!
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
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 8086 the 8088 was based on was released in 1978. The ARM1 was released in 1985. That was an eternity.
As has been said elsewhere the ARM1 wouldn't have worked commercially in 1978 because of code density and bus width.
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.
She is in a position to know.
Incidentally, Robin Saxby the first CEO of Arm previously worked for Motorola and tried to sell the 68000 to the Acorn team!
The 6502 has only an 8 bit stack pointer which points into page 1 only (addresses 0x100 .. 0x1FF).
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.
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 perfect for such applications!
Good memories.
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 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.
[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.
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.
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?
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...
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!]
[1] https://www.youtube.com/watch?v=HyznrdDSSGM&list=PLowKtXNTBy...
What a helpful online community.
The general progression is:
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.
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
[1] https://news.ycombinator.com/item?id=23757449
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...
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)