I started programming in 1978 (In Assembler) and wanted to know not only how the software worked but how the hardware worked.
Found a great kit using the Z80 and built it and spent many nights with a logic probe and oscilloscope learning digital eletronics. Also devoured the Z80 manual learning the instruction set.
I'm nearly 70 now but remember those days like they were yesterday.
It sounds like it may be right up your alley. Its a simplified digital logic simulator, you make basic circuits from NAND gates, and then build these into functional units in later levels, then further on you build an instruction decoder, and combine it with these functional units and before long you have a Turing complete architecture and you are writing your own assembly on it - Assembly language that you defined, from scratch. You'll find the need for new opcodes... so, you build them!
Challenging game for sure, but very, very rewarding.
Software binary compatibility is less important now than it has been for 30 or 40 years of x86 dominance because now we are so over-served by hardware that most software runs just fine in emulation (especially transpiling/JIT).
Compatibility also wan't too important in the 70s and the 6502 wasn't compatible with anything else. Everyone expected to rewrite everything back then whether between manufacturers or just a new model from the same manufacturer.
I started 3 years later than you on a 4K Radio Shack computer running a 6809 8-bit CPU. I can still remember quite a few opcodes and a few months ago helped some on retrocomputing.stackexchange.com find a rather tricky 6809 assembly language bug without looking anything up. It's weird how stuff sticks around in our heads, since I haven't written any 6809 code in more than 40 years.
Despite being entirely self-taught due to never having programming classes or books, I enjoyed a long, quite successful career as a serial startup entrepreneur. In 1981 the only info for 'toy micros' was small hobby zines, local user's groups and just learning by disassembling other people's code. I started with the ROMs in the computer and learned by looking up the opcodes on a Motorola quick reference card. I got it by cold calling Motorola trying to sound like an 'adult' and the salesperson took pity on me and mailed the card for free.
I still think there's something invaluable about learning computers from first principles down to the metal.
Next to the TI calculators already mentioned by someone else, I think what might be the largest use of a Z80 core in a consumer product happened approximately 2 decades ago: https://en.wikipedia.org/wiki/S1_MP3_player
There was an active modding scene around them, and even some attempts at creating a replacement firmware, but unfortunately most of that seems to have disappeared.
The article claims:
> The Z80 is fully binary compatible with the 8080 instruction set.
It wasn't in regards to the flag register. The parity flag behaved differently for some ops.
And of course it would be possible to write an 8080 program that used undefined ops that would execute in some random way (often just duplicating an existing instruction) while the Z80 repurposed that opcode for something new.
By the same thinking that have the parent post The 80286 and 80386 aren't binary compatible with the 8086. Because they replaced undefined opcodes with new stuff.
Making the parity flag not perfectly compatible was a wise choice.
In legacy programs the parity flag was seldom tested and practically never after the instructions where in Z80 it behaved differently.
This allowed the repurposing of the parity flag as an overflow flag, which was an extremely useful extension of Z80.
The instruction sets of Datapoint 2200, Intel 8008 and Intel 8080 share with that of RISC-V the distinction of belonging to the extremely few ISAs where overflow is not detected by hardware.
Datapoint 2200 and its first successors had the excuse that they were extremely simple and cheap designs, which were never intended for general-purpose computing.
RISC-V has absolutely no excuse. The lack of overflow detection is its greatest mistake.
It doesn't have a carry flag either. Multiprecision integer operations absolutely suck in RISC-V, you need three operations (SLT and two adds, with an awful dependency chain too) to do an add with carry, and op fusion can only do so much. At least add an instruction that computes the carry out, like "Rd += Cout(Rs1 + Rs2)" and the similar one for subtraction...
Unfortunately the criticism from that link is absolutely correct.
Moreover, at that link it is shown only the ugly way in which RISC-V does multi-word addition.
Checking the standard arithmetic operations for overflow is much more horrible and inefficient than that, and checking for overflows must be done in any program that claims to follow safe practices.
I started out on Z80 when HLL compilers were expensive for me and the shareware alternatives weren’t so accessible as open source is today. Everyone should do at least a little assembler to gain an appreciation of what they are asking the machine to do, and the Z80 was simple enough to reason about.
As the proud owner of a ZX-81 I remember staring at the Z80 instruction reference at the end of the user's manual without the faintest clue of what any of that meant. It took me some while before I managed to wrap my head around how CPUs actually run programs (vs. the high level abstractions like BASIC or other languages).
That machine was my intro to computers too, and I was fascinated by “fast mode” blanking the screen and the interesting tradeoffs between hardware and software.
Another proud ZX-81 owner, my first computer bought as kit. It made me the TI pioneer in my little city. So cool times, everything was complex and simple at the same time. I had a flight simulator in only 1Kb ram :D
Actually, BASIC’s flat structure helped me a lot in understanding Z80 assembly when I was 12. You see, memory addresses were line numbers, registers were variables, JP was GOTO, CALL was GOSUB. CP was IF, JP, Z was THEN GOTO, and LD was LET, and so forth.
Z-80 was the processor for my introduction to programming in assembly language on a TRS-80 model I in early 1983. Bill Barden's assembly language books and Hardin Brothers' "The Next Step" column in 80 Micro magazine paved the way.
I wrote a quick post a while back about my Z-80 experiences here:
When I was a teenager ca. 1980, my local Radio Shack had a shelf of books, and I worked my way through them as my funds allowed. Since the TRS-80 used a Z80, they had Barden's book on the Z80, published by Howard Sams. I already understood programming a bit thanks to learning BASIC, and my curiosity about micro's was piqued by my mom's subscription to Byte Magazine.
Maybe it's because it was so clearly written that a kid could understand it, but it was a revelation, and I read it cover to cover. I never actually touched a real Z80, but it was a good enough introduction that I had no problem understanding other micro's including the 6502 and early microcontrollers such as 8051 and PIC.
Even today, I suspect that I "understand" modern micros by falling back on the Z80, and I recommend learning an 8-bit micro because they're simple enough for mere mortals to comprehend.
Happy Birthday Z80! My first job out of university was in Z80 assembly. (Sega Game Gear.)
As a kid, it was all about 6502 micros, but my early professional love was Z80 and it still warms my heart to think about. Sure, the “other” 8 bit CPUs had zero page, but block instructions and 16 bit extensions FTW. <3
35 years ago I had to program a Z80 by "assembling" programs by hand and punching hexcodes into a board. This was made easier by writing an assembler for it. This was my way into tools which took me eventually to working on a major C++ compiler.
Yeah but that would have been the late 70's... oh my gosh that was 1991!
It was cool to do that kind of stuff, you knew exactly what your program was doing (if all went right) at all times, but it sure was a slog to get anything complex moving.
During the eighties, there were a lot of people, including myself, who could read directly the hex codes of the Z80 instructions as easily as its symbolic assembly language.
That was very handy for reverse engineering programs like the Microsoft CP/M BASIC interpreter or FORTRAN compiler.
No mention of the TI-84 calculator? Used by millions of American schoolchildren, programmable in BASIC, and runs on Z80 (B/W models)/eZ80 (color display models) to this day
Europe too :) When I was in high school, TI-84 Plus was the calculator the school told all of us to buy. And I see that stores in my country are still stocking them so I have to assume they are still being bought and used.
Many hours were spent by me and my friends making and showing off little programs in TI-BASIC on those calculators. None of us ever took it all the way to learning Z80 assembly however. I printed a whole manual about Z80 assembly programming for the TI-84 Plus and started reading it but never wrote a single line of assembly for it. Yet.
Same here (actually had a voyage 200, but same same I guess). It's actually quite insulting that TI kept (and keeps?) selling waaay outdated hardware at horrendous prices. It's the SAP/Oracle business model applied to school hardware.
While I agree on bit about horrible prices, the TI calculators are well suited to their intended task[1] so I will object to the outdated hardware part. Stability is a good thing in the context of classrooms. Why should schools be spending money on replacement hardware, software, and textbooks when the curriculum itself is fundamentally unchanged?[2]
[1] Except the screens on the older models were truly horrible, from a brightness and contrast perspective.
[2] From my recollection, the calculators interfaced with hardware and software from other vendors. Then, of course, there was the vendor lock-in provided by textbook publishers.
I found a funny irony that in the country of free market, a calculator model was enforced nation wide in the schools. Here, in Spain, the teacher would only ask to the kids to get a calculator. They never ask for a concrete model or brand. Perhaps, they will only go ask to not get a programmeble calculator.
I agree that you not need to have more powerful calculator. A cheap Casio or HP calculator it's enough for the 99% of time. I keep using my old Casio from my formative years. It's in an interesting calc. Powerful enough to write formulas and complex calculations, but can't store formulas or programs. Just in the nice spot that allowed it to be used in exams.
> Same here (actually had a voyage 200, but same same I guess).
Not the same, actually! Unlike the TI-83/84 series, the TI-89, -92, and Voyage-200 all used a 68000 CPU, with a completely different (and much better) operating system.
We had both depending on the school and sometimes even the teacher. fx-9750G and GII didn't support assembly programming... unless you used an undocumented procedure to flash them with unsupported firmware from a different calculator model...
Happy Birthday Z80!!!!! My first little Timex computer! <3
I was just thinking of you the other day in fact! Do you remember that terrible flight simulator we wrote in your BASIC, then discovering your assembly!!!! Yes, I remember, at 10 I was incapable of ASM, but that's why they made the 6502C years later!!!!! I still love you Z80, you did pop my cherry! <3
I hope ur not still upset about that whole AIM-65 incident.....
The Z80 was how I learned assembly programming in high school.[0] Was a bit of an unusual choice, but high school students still carry these funky Z80 (or eZ80 now with the color screens) devices every day, so being able to hack on it and have plausible deniability while in class felt great :)
There are plenty of open core alternatives that replicate the architecture and ISA. Many of these are cycle accurate. Some have been tape-out proven. Hobbyist retro-computing enthusiasts who wish to build a Z80 system still have options even once new old stock and recovered CPUs become scarce.
First, my Father wanted to try to add some peripherals to the original TRS-80 Model 1. So, what he was interested in doing was asserting the BUSREQ pin to tell the Z80 to get ready so that he could have the bus, ideally waiting for the BUSACK signal to know when it was his.
Unfortunately, on the Model 1, when you assert the BUSREQ pin, it is tied directly to the tri-state buffers that handle the address and data bus. So, as soon as you make the request, the Z80 loses all access to its memory and data -- mid cycle. Which, you know, can be Bad. Radio Shack labels this pin TEST and uses it for internal testing. But it was definitely a bit of a disappointment to my Fathers efforts.
The second one is when I learned that the Game Boy Advance has a Z80 built into its chip. The designers drag and dropped a Z80 core (tweaked for GB) just so they could run legacy GB games on it. It just kind of bends your view of the computing world when something as significant as a Z80 can just be shoved into the corner of a die for "just in case" functionality.
That just means you have a more exciting design problem! Now you have to stop the clock and then assert TEST for probably a certain maximum number of cycles (dynamic logic) before enabling the clock...
Are you sure about that anecdote around the GBA? It would make more sense that they used the Sharp SM83 core - which is pretty far from a Z80 considering it's missing IX, IY and the entire alternate register set. It certainly does have some Z80 instructions and even some SM83 specific instructions. On the dial between 8080 and Z80 it feels closer to 8080 to me.
The Z80 has a relative jump. Teenage me was loading a hand-assembled search function as an initialised array of integers in Basic, and relative jumps didn't need to be adjusted for the load location, which reduced the amount of post-load adjusting of addresses. It was +100x faster than Basic, just a straight scan.
When I started TAFE (the equivalent of community college in the US I assume?) in Australia in 2003, one of the subjects in the electronic engineering course was to study and program a Z80. I was awful at it, but it was a good introduction to how a computer works. I wonder if they're still using this CPU as a way to teach the fundamentals of computers?
This is the CPU that I first learned to code on, first in TI Basic (TI-8[1356] ftw) and then Z80 assembler. Crazy to think that the CPU was "old" when I started, and it's still doing good work in those calculators even 20+ years later.
The heart of the mighty Australian Microbee. I still have the Rodney Zak’s book somewhere although I’ll admit doing anything fancy with assembler back then was a bit beyond me
Arguably, Exxon's plan to build a computing ecosystem rival to IBM's would have worked too, if the 16 bit successor of the Z80 would have maintained upward binary compatibility with Z80.
CP/M was an absolute beast in the era, with massive installed base and software support, employing 500 people in 1982. A CPU that could run unmodified Z80 software in a 64k segment would have allowed DRI to ship 16 bit CP/M with only basic tweaks and likely kill the market for the PC.
It was, famously, DRI dragging their feet on 8086 support that motivated the release of QDOS, which was then bought by Microsoft and relicensed at an immense markup to IBM as MS-DOS.
Happy birthday! The Z80 was the first CPU I rode, more luxurious than the subsequent 6502 and 6510. I still have a TI calculator with a low-energy Z80.
The MOS 6502 was introduced at the WESCON tradeshow in September 1975 and sold for $25 quantity 1. They had a transparent vase full of them, 'proving' they did volume -- but those were all chips that failed post-manufacturing testing, except for the very top layer. Still...
Spoiler: the undocumented WZ registers are just microcode temporaries to hold large operands. For instance when reading a jump instruction, the jump destination can't be read directly into PC since that would mess up reading the second half of it, so it's read into WZ and then WZ is transferred to PC. This is invisible to the programmer.
One might say the instruction is really "jump to WZ", or JWZ, which, of course, refers to Jamie Zawinski (not really).
I still remember clearly sitting down to play with the TRS-80 at the local Radio Shack in the 1970s
Unlike anything I had ever experienced, it was life changing, I would bike to the store every day after school
Family couldn't afford the computer but I bought all the books and would read them at home over and over and gawk at all the accessories in the catalogs
Then family surprised me with it as a birthday present with all the relatives paying for it, pretty sure I was the only person in town with one, even the school didn't get one for years
Didn't have any way to save programs, not even the cassette recorder which was too expensive, had to memorize them and retype every time I turned it on
Annoying part of 8080 was that the command set had holes in it and mystery restrictions. Which were hard to remember. And 12 undefined opcodes. Z80 solved all that.
However, you had to be a programmer Anno Dominii 1975 to fully understand what heavenly Joy and Jubilation Z80 was.
And yes. There was 8080-assembler in PDP-11, but it was just regular PDP assembler with extra macroes. It did not know those forbidden commands and thus produced undefined opcodes with random and entertaining results.
I started programming in 1978 (In Assembler) and wanted to know not only how the software worked but how the hardware worked.
Found a great kit using the Z80 and built it and spent many nights with a logic probe and oscilloscope learning digital eletronics. Also devoured the Z80 manual learning the instruction set.
I'm nearly 70 now but remember those days like they were yesterday.
Truly a magnificent CPU
Same! Also built external peripherals for my ZX81.
May I suggest you check out the game "Turing Complete" https://turingcomplete.game/
It sounds like it may be right up your alley. Its a simplified digital logic simulator, you make basic circuits from NAND gates, and then build these into functional units in later levels, then further on you build an instruction decoder, and combine it with these functional units and before long you have a Turing complete architecture and you are writing your own assembly on it - Assembly language that you defined, from scratch. You'll find the need for new opcodes... so, you build them! Challenging game for sure, but very, very rewarding.
The game is still in early access, but very near a full release. They just put out a trailer: https://www.youtube.com/watch?v=goclUECM2ds
This looks very cool. In a similar vein, there's https://www.nand2tetris.org/.
Both the Z80 and the 6502 were products of corporate rejection.
I'd love to see another designer introduce a FORK86-64, but things are much more complex now.
We have RISC-V.
Software binary compatibility is less important now than it has been for 30 or 40 years of x86 dominance because now we are so over-served by hardware that most software runs just fine in emulation (especially transpiling/JIT).
Compatibility also wan't too important in the 70s and the 6502 wasn't compatible with anything else. Everyone expected to rewrite everything back then whether between manufacturers or just a new model from the same manufacturer.
I started 3 years later than you on a 4K Radio Shack computer running a 6809 8-bit CPU. I can still remember quite a few opcodes and a few months ago helped some on retrocomputing.stackexchange.com find a rather tricky 6809 assembly language bug without looking anything up. It's weird how stuff sticks around in our heads, since I haven't written any 6809 code in more than 40 years.
Despite being entirely self-taught due to never having programming classes or books, I enjoyed a long, quite successful career as a serial startup entrepreneur. In 1981 the only info for 'toy micros' was small hobby zines, local user's groups and just learning by disassembling other people's code. I started with the ROMs in the computer and learned by looking up the opcodes on a Motorola quick reference card. I got it by cold calling Motorola trying to sound like an 'adult' and the salesperson took pity on me and mailed the card for free.
I still think there's something invaluable about learning computers from first principles down to the metal.
It feels a bit like a first language. That's the one that really sticks with you.
Next to the TI calculators already mentioned by someone else, I think what might be the largest use of a Z80 core in a consumer product happened approximately 2 decades ago: https://en.wikipedia.org/wiki/S1_MP3_player
There was an active modding scene around them, and even some attempts at creating a replacement firmware, but unfortunately most of that seems to have disappeared.
The article claims: > The Z80 is fully binary compatible with the 8080 instruction set.
It wasn't in regards to the flag register. The parity flag behaved differently for some ops.
And of course it would be possible to write an 8080 program that used undefined ops that would execute in some random way (often just duplicating an existing instruction) while the Z80 repurposed that opcode for something new.
But "undefined ops" are not part of the "8080 instruction set"; supporting those would be "binary compatible with the 8080 silicon".
The parity flag is a breaker though; "binary compatible for code only relying on the 8080 instruction set, other than values of the parity flag".
By the same thinking that have the parent post The 80286 and 80386 aren't binary compatible with the 8086. Because they replaced undefined opcodes with new stuff.
Making the parity flag not perfectly compatible was a wise choice.
In legacy programs the parity flag was seldom tested and practically never after the instructions where in Z80 it behaved differently.
This allowed the repurposing of the parity flag as an overflow flag, which was an extremely useful extension of Z80.
The instruction sets of Datapoint 2200, Intel 8008 and Intel 8080 share with that of RISC-V the distinction of belonging to the extremely few ISAs where overflow is not detected by hardware.
Datapoint 2200 and its first successors had the excuse that they were extremely simple and cheap designs, which were never intended for general-purpose computing.
RISC-V has absolutely no excuse. The lack of overflow detection is its greatest mistake.
RISC-V has no overflow flag? That's fascinating. I'll have to dig into that!
It doesn't have a carry flag either. Multiprecision integer operations absolutely suck in RISC-V, you need three operations (SLT and two adds, with an awful dependency chain too) to do an add with carry, and op fusion can only do so much. At least add an instruction that computes the carry out, like "Rd += Cout(Rs1 + Rs2)" and the similar one for subtraction...
https://gmplib.org/list-archives/gmp-devel/2021-September/00...
Unfortunately the criticism from that link is absolutely correct.
Moreover, at that link it is shown only the ugly way in which RISC-V does multi-word addition.
Checking the standard arithmetic operations for overflow is much more horrible and inefficient than that, and checking for overflows must be done in any program that claims to follow safe practices.
I started out on Z80 when HLL compilers were expensive for me and the shareware alternatives weren’t so accessible as open source is today. Everyone should do at least a little assembler to gain an appreciation of what they are asking the machine to do, and the Z80 was simple enough to reason about.
As the proud owner of a ZX-81 I remember staring at the Z80 instruction reference at the end of the user's manual without the faintest clue of what any of that meant. It took me some while before I managed to wrap my head around how CPUs actually run programs (vs. the high level abstractions like BASIC or other languages).
That machine was my intro to computers too, and I was fascinated by “fast mode” blanking the screen and the interesting tradeoffs between hardware and software.
Another proud ZX-81 owner, my first computer bought as kit. It made me the TI pioneer in my little city. So cool times, everything was complex and simple at the same time. I had a flight simulator in only 1Kb ram :D
The ZX81's 1k chess - actually 672 bytes - was, and still is, legendary.
Actually, BASIC’s flat structure helped me a lot in understanding Z80 assembly when I was 12. You see, memory addresses were line numbers, registers were variables, JP was GOTO, CALL was GOSUB. CP was IF, JP, Z was THEN GOTO, and LD was LET, and so forth.
Z-80 was the processor for my introduction to programming in assembly language on a TRS-80 model I in early 1983. Bill Barden's assembly language books and Hardin Brothers' "The Next Step" column in 80 Micro magazine paved the way.
I wrote a quick post a while back about my Z-80 experiences here:
https://jimlawless.net/blog/posts/z-80/
When I was a teenager ca. 1980, my local Radio Shack had a shelf of books, and I worked my way through them as my funds allowed. Since the TRS-80 used a Z80, they had Barden's book on the Z80, published by Howard Sams. I already understood programming a bit thanks to learning BASIC, and my curiosity about micro's was piqued by my mom's subscription to Byte Magazine.
Maybe it's because it was so clearly written that a kid could understand it, but it was a revelation, and I read it cover to cover. I never actually touched a real Z80, but it was a good enough introduction that I had no problem understanding other micro's including the 6502 and early microcontrollers such as 8051 and PIC.
Even today, I suspect that I "understand" modern micros by falling back on the Z80, and I recommend learning an 8-bit micro because they're simple enough for mere mortals to comprehend.
Happy Birthday Z80! My first job out of university was in Z80 assembly. (Sega Game Gear.)
As a kid, it was all about 6502 micros, but my early professional love was Z80 and it still warms my heart to think about. Sure, the “other” 8 bit CPUs had zero page, but block instructions and 16 bit extensions FTW. <3
35 years ago I had to program a Z80 by "assembling" programs by hand and punching hexcodes into a board. This was made easier by writing an assembler for it. This was my way into tools which took me eventually to working on a major C++ compiler.
RE "....assembling programs by hand and punching hexcodes into a board......"
You translated you assembly language to machine language. ( Machine language is the only language a CPU can understand. )
Yes 'assembling' is exactly what GP did when they converted e.g. `LD A, B` into 0x78.
I wouldn't call it a 'translation'. It's encoding. (We don't think of converting between ASCII codes and symbols as translation.)
Yeah but that would have been the late 70's... oh my gosh that was 1991!
It was cool to do that kind of stuff, you knew exactly what your program was doing (if all went right) at all times, but it sure was a slog to get anything complex moving.
During the eighties, there were a lot of people, including myself, who could read directly the hex codes of the Z80 instructions as easily as its symbolic assembly language.
That was very handy for reverse engineering programs like the Microsoft CP/M BASIC interpreter or FORTRAN compiler.
No mention of the TI-84 calculator? Used by millions of American schoolchildren, programmable in BASIC, and runs on Z80 (B/W models)/eZ80 (color display models) to this day
> Used by millions of American schoolchildren
Europe too :) When I was in high school, TI-84 Plus was the calculator the school told all of us to buy. And I see that stores in my country are still stocking them so I have to assume they are still being bought and used.
Many hours were spent by me and my friends making and showing off little programs in TI-BASIC on those calculators. None of us ever took it all the way to learning Z80 assembly however. I printed a whole manual about Z80 assembly programming for the TI-84 Plus and started reading it but never wrote a single line of assembly for it. Yet.
Same here (actually had a voyage 200, but same same I guess). It's actually quite insulting that TI kept (and keeps?) selling waaay outdated hardware at horrendous prices. It's the SAP/Oracle business model applied to school hardware.
While I agree on bit about horrible prices, the TI calculators are well suited to their intended task[1] so I will object to the outdated hardware part. Stability is a good thing in the context of classrooms. Why should schools be spending money on replacement hardware, software, and textbooks when the curriculum itself is fundamentally unchanged?[2]
[1] Except the screens on the older models were truly horrible, from a brightness and contrast perspective.
[2] From my recollection, the calculators interfaced with hardware and software from other vendors. Then, of course, there was the vendor lock-in provided by textbook publishers.
I found a funny irony that in the country of free market, a calculator model was enforced nation wide in the schools. Here, in Spain, the teacher would only ask to the kids to get a calculator. They never ask for a concrete model or brand. Perhaps, they will only go ask to not get a programmeble calculator.
I agree that you not need to have more powerful calculator. A cheap Casio or HP calculator it's enough for the 99% of time. I keep using my old Casio from my formative years. It's in an interesting calc. Powerful enough to write formulas and complex calculations, but can't store formulas or programs. Just in the nice spot that allowed it to be used in exams.
> Same here (actually had a voyage 200, but same same I guess).
Not the same, actually! Unlike the TI-83/84 series, the TI-89, -92, and Voyage-200 all used a 68000 CPU, with a completely different (and much better) operating system.
I wrote a web-based emulator for the Voyage-200 a few years ago: https://woofle.net/v200/
It depends on the country I guess. In Spain I never saw a person using Texas Instruments calculators. Casio and HP are way more popular.
We had both depending on the school and sometimes even the teacher. fx-9750G and GII didn't support assembly programming... unless you used an undocumented procedure to flash them with unsupported firmware from a different calculator model...
and nobody enforces a calculator model
Not all of Europe, Portugal was all about Casio and HP.
TI-83 for me. We didn't have that advanced technology.
TI-83 was built on Z80 as well. I remember hand-assembling a program for it with pen and paper, something I did earlier with the Sinclairs.
The TI-84+ might be one of my favorite retro computers.
Happy Birthday Z80!!!!! My first little Timex computer! <3
I was just thinking of you the other day in fact! Do you remember that terrible flight simulator we wrote in your BASIC, then discovering your assembly!!!! Yes, I remember, at 10 I was incapable of ASM, but that's why they made the 6502C years later!!!!! I still love you Z80, you did pop my cherry! <3
I hope ur not still upset about that whole AIM-65 incident.....
There is a drop in compatible FOSS clone of Z80 https://github.com/rejunity/z80-open-silicon
The Z80 was how I learned assembly programming in high school.[0] Was a bit of an unusual choice, but high school students still carry these funky Z80 (or eZ80 now with the color screens) devices every day, so being able to hack on it and have plausible deniability while in class felt great :)
[0] https://github.com/siraben/zkeme80
My first computer was a soviet clone of a ZX Spectrum, which started it all almost 40 years ago...
The Z80 stopped being manufactured last year unfortunately
There are plenty of open core alternatives that replicate the architecture and ISA. Many of these are cycle accurate. Some have been tape-out proven. Hobbyist retro-computing enthusiasts who wish to build a Z80 system still have options even once new old stock and recovered CPUs become scarce.
There are clones, and updated packages these days like the EZ80, but they're not the same and they don't have the easy-to-use DIL form-factor.
Still I've always loved the z80, since my first computer the ZX Spectrum. Even now I play with z80 assembly now and again (mostly for CP/M retro-use).
Two of my favorite Z80 anecdotes.
First, my Father wanted to try to add some peripherals to the original TRS-80 Model 1. So, what he was interested in doing was asserting the BUSREQ pin to tell the Z80 to get ready so that he could have the bus, ideally waiting for the BUSACK signal to know when it was his.
Unfortunately, on the Model 1, when you assert the BUSREQ pin, it is tied directly to the tri-state buffers that handle the address and data bus. So, as soon as you make the request, the Z80 loses all access to its memory and data -- mid cycle. Which, you know, can be Bad. Radio Shack labels this pin TEST and uses it for internal testing. But it was definitely a bit of a disappointment to my Fathers efforts.
The second one is when I learned that the Game Boy Advance has a Z80 built into its chip. The designers drag and dropped a Z80 core (tweaked for GB) just so they could run legacy GB games on it. It just kind of bends your view of the computing world when something as significant as a Z80 can just be shoved into the corner of a die for "just in case" functionality.
Just shows how far we had come at the time.
That just means you have a more exciting design problem! Now you have to stop the clock and then assert TEST for probably a certain maximum number of cycles (dynamic logic) before enabling the clock...
Are you sure about that anecdote around the GBA? It would make more sense that they used the Sharp SM83 core - which is pretty far from a Z80 considering it's missing IX, IY and the entire alternate register set. It certainly does have some Z80 instructions and even some SM83 specific instructions. On the dial between 8080 and Z80 it feels closer to 8080 to me.
The Z80 has a relative jump. Teenage me was loading a hand-assembled search function as an initialised array of integers in Basic, and relative jumps didn't need to be adjusted for the load location, which reduced the amount of post-load adjusting of addresses. It was +100x faster than Basic, just a straight scan.
jr?
When I started TAFE (the equivalent of community college in the US I assume?) in Australia in 2003, one of the subjects in the electronic engineering course was to study and program a Z80. I was awful at it, but it was a good introduction to how a computer works. I wonder if they're still using this CPU as a way to teach the fundamentals of computers?
The eZ80 is still manufactured even though the original Z80 is not.
the Z80 outlived the company that made it, the company that bought that company, and will probably outlive whatever acquires the remains next
This is the CPU that I first learned to code on, first in TI Basic (TI-8[1356] ftw) and then Z80 assembler. Crazy to think that the CPU was "old" when I started, and it's still doing good work in those calculators even 20+ years later.
I just got six Schottkys this very morning, 1N5819 40V/1A, to replace the main board rectifier diodes in my Z80-powered ADA MP-1 pre-amp.
The heart of the mighty Australian Microbee. I still have the Rodney Zak’s book somewhere although I’ll admit doing anything fancy with assembler back then was a bit beyond me
What a milestone. Still my favorite processor, and I have about 10 here at home in various yet to be finished projects (of course).
I had no idea about the Exxon connection to Zilog. That was wild.
Arguably, Exxon's plan to build a computing ecosystem rival to IBM's would have worked too, if the 16 bit successor of the Z80 would have maintained upward binary compatibility with Z80.
CP/M was an absolute beast in the era, with massive installed base and software support, employing 500 people in 1982. A CPU that could run unmodified Z80 software in a 64k segment would have allowed DRI to ship 16 bit CP/M with only basic tweaks and likely kill the market for the PC.
It was, famously, DRI dragging their feet on 8086 support that motivated the release of QDOS, which was then bought by Microsoft and relicensed at an immense markup to IBM as MS-DOS.
My son programmed a Z80-based instruction set into a Juno probe sensor. Still kicking.
Happy birthday! The Z80 was the first CPU I rode, more luxurious than the subsequent 6502 and 6510. I still have a TI calculator with a low-energy Z80.
Cheers to Rodnay Zaks for "Programming the Z80"!
https://archive.org/details/Programming_the_Z-80_2nd_Edition... is where I learned about the "W" and "Z" registers -- if you don't know what they do, I won't spoil your fun reading Zaks! See also http://www.z80.info/zip/z80-documented.pdf
The MOS 6502 was introduced at the WESCON tradeshow in September 1975 and sold for $25 quantity 1. They had a transparent vase full of them, 'proving' they did volume -- but those were all chips that failed post-manufacturing testing, except for the very top layer. Still...
Spoiler: the undocumented WZ registers are just microcode temporaries to hold large operands. For instance when reading a jump instruction, the jump destination can't be read directly into PC since that would mess up reading the second half of it, so it's read into WZ and then WZ is transferred to PC. This is invisible to the programmer.
One might say the instruction is really "jump to WZ", or JWZ, which, of course, refers to Jamie Zawinski (not really).
Zaks is a name I remember fondly, but for me the starting point was "An Introduction to z80 machine code" by R.A & J.W Penfold.
Off topic: nice, retro website look!
I still remember clearly sitting down to play with the TRS-80 at the local Radio Shack in the 1970s
Unlike anything I had ever experienced, it was life changing, I would bike to the store every day after school
Family couldn't afford the computer but I bought all the books and would read them at home over and over and gawk at all the accessories in the catalogs
Then family surprised me with it as a birthday present with all the relatives paying for it, pretty sure I was the only person in town with one, even the school didn't get one for years
Didn't have any way to save programs, not even the cassette recorder which was too expensive, had to memorize them and retype every time I turned it on
Annoying part of 8080 was that the command set had holes in it and mystery restrictions. Which were hard to remember. And 12 undefined opcodes. Z80 solved all that.
However, you had to be a programmer Anno Dominii 1975 to fully understand what heavenly Joy and Jubilation Z80 was.
And yes. There was 8080-assembler in PDP-11, but it was just regular PDP assembler with extra macroes. It did not know those forbidden commands and thus produced undefined opcodes with random and entertaining results.
Back in the day, I studied Z80 assembly to write something about Pokémon red. I didn't realize it was this old
Sharp SM83 assembly. ;-)