Chip Hall of Fame: Zilog Z80 Microprocessor (2017)(spectrum.ieee.org)
spectrum.ieee.org
Chip Hall of Fame: Zilog Z80 Microprocessor (2017)
https://spectrum.ieee.org/tech-history/silicon-revolution/chip-hall-of-fame-zilog-z80-microprocessor
76 comments
Most notably Microsoft Basic was not compatible initially. The CP/M version is but that came much later.
> Zilog still makes the Z80, which is used in some embedded systems.
Still used in the TI range of graphing calculators. Specifically, the TI-84 CE range[0]. I can't speak for other countries, but graphing calculators are mandatory in Dutch high schools, and the TI series is the default choice for many (I got a TI 83+ Silver Edition when I was 14, which was "new" at the time - guess my age). I suspect because it's low-powered enough to still require that students Learn The Material too (instead of doing the symbolic calculus through the calculator). Texas Instruments must be having quite a large mark-up on such a dirt-cheap piece of electronic hardware though.
Anyway, because of that, Z80 assembly was my second programming language TI Basic being the first[1]. It really is quite accessible - I mean you basically memorise the entire instruction set after a while because it's so small and simple[2].
Funny enough, I remember when moving to higher level languages that almost every tutorial that I read on warned me that pointers were really, really hard, and I couldn't see why at that point. I guess that if you start from the ground up instead from the top down, some things get easier.
[0] https://en.wikipedia.org/wiki/TI-84_Plus_series
[1] https://www.ticalc.org/archives/files/fileinfo/328/32816.htm...
[2] http://wikiti.brandonw.net/index.php?title=Z80_Instruction_S...
Still used in the TI range of graphing calculators. Specifically, the TI-84 CE range[0]. I can't speak for other countries, but graphing calculators are mandatory in Dutch high schools, and the TI series is the default choice for many (I got a TI 83+ Silver Edition when I was 14, which was "new" at the time - guess my age). I suspect because it's low-powered enough to still require that students Learn The Material too (instead of doing the symbolic calculus through the calculator). Texas Instruments must be having quite a large mark-up on such a dirt-cheap piece of electronic hardware though.
Anyway, because of that, Z80 assembly was my second programming language TI Basic being the first[1]. It really is quite accessible - I mean you basically memorise the entire instruction set after a while because it's so small and simple[2].
Funny enough, I remember when moving to higher level languages that almost every tutorial that I read on warned me that pointers were really, really hard, and I couldn't see why at that point. I guess that if you start from the ground up instead from the top down, some things get easier.
[0] https://en.wikipedia.org/wiki/TI-84_Plus_series
[1] https://www.ticalc.org/archives/files/fileinfo/328/32816.htm...
[2] http://wikiti.brandonw.net/index.php?title=Z80_Instruction_S...
> Anyway, because of that, Z80 assembly was my second programming language TI Basic being the first.
I didn't have the cable you needed to transfer binaries from a desktop computer to the calculator, and I never finished the cable I tried to build myself from scrap parts. Hence, I never got past the TI Basic, which you could program on the calculator itself. :-)
Here's a TI Basic rendering of a sphere (the Moon seen from Earth, say): https://i.imgur.com/xWb1xk2.jpg
I didn't have the cable you needed to transfer binaries from a desktop computer to the calculator, and I never finished the cable I tried to build myself from scrap parts. Hence, I never got past the TI Basic, which you could program on the calculator itself. :-)
Here's a TI Basic rendering of a sphere (the Moon seen from Earth, say): https://i.imgur.com/xWb1xk2.jpg
I had a similar high school experience. Not as much asm but spent way too many hours writing basic programs on that thing. prob should have spent more time listening in class.... nar! :-D
Same. I wrote a horse racing program on the 82 that I sold to students so they could use it for betting. It was my first profitable software product :)
It was lame as crap. Just used the PRNG to multiply one of 5 variables by 10 and then draw them on the screen. Longest number won the race.
If you were clever enough you could reseed the RNG and pick a winner every time.
It was lame as crap. Just used the PRNG to multiply one of 5 variables by 10 and then draw them on the screen. Longest number won the race.
If you were clever enough you could reseed the RNG and pick a winner every time.
I wrote a solver of quadratic equations that occasionally adjusted the answer to be wrong by a few percent. The plan was to disseminate it to the class. I don't remember to what extent I managed or dared. I have now put my black hat days behind me.
That’s so incredibly evil that I love it :)
Imagine a high-school programming class where they teach you how to program on your calculator. Such a wasted opportunity - I'm pretty sure quite a few people in my class (including myself) would have loved that.
I had the TI-85, and after BASIC I learned Z80 assembly. I wrote a bunch of programs for that calculator in HS. I love it, and I still love the Z80. So simple yet brilliant.
I had the same experience with pointers.
Started coding with a Timex 2068 back in the day, and went through Z80, 8086, 68000, Basic and Pascal dialects before getting to learn C, nothing special about C pointers.
Started coding with a Timex 2068 back in the day, and went through Z80, 8086, 68000, Basic and Pascal dialects before getting to learn C, nothing special about C pointers.
I mean at that stage you've probably mastered tricks like self-modifying code (I remember learning how to do that for the midpoint circle algorithm, but I can't find the source on-line any more). Pointers are simpler than that.
Yeah, kind of doing our own JIT, without knowing that was a thing.
Pointers are pretty easy when drawing boxes and arrows. Sometimes I wonder if they don't teach them anymore.
Pointers are pretty easy when drawing boxes and arrows. Sometimes I wonder if they don't teach them anymore.
I spent many happy years making the Z80 dance, from Summer 1976 through Spring 1989, architecting and writing statistical multiplexors at MICOM Communications in LA. Micro 800 line. That is a Hard Real Time application, and the hardware for the first model was only 4KROM and 4KRAM. I made one Z80 do what the competition (CISCO) swore required 5, and laughed discreetly at us, but it worked, sold out the bottom end market from under them, and suddenly we had a runaway and I got an excellent team to buttress and ultimately take over the baton from me. I would dream in Z80 ASM in those days.
The Z80 had two hardware features that made it possible, and that nobody here has mentioned yet:
1: two sets of working registers, with a one byte instruction to toggle between them. I instruction cyclke to context switch between application and interrupt handlers. Only the TI 9900 came close with its in-RAM working register sets.
2: hardware vectored interrupt dispatch, fully suppported by theor accompanying peripheral line. Just a few clocks from raising an interrupt to executing the first line of code (typically switch context then ...) of not only the device but it's reason for interrupt code. No code wasted interrogating bitfields and scanning registers. 2 usecs interrupt response time. Faster than an Intel i960 with its 50MHz clock, that came along later.
The Z80 had two hardware features that made it possible, and that nobody here has mentioned yet:
1: two sets of working registers, with a one byte instruction to toggle between them. I instruction cyclke to context switch between application and interrupt handlers. Only the TI 9900 came close with its in-RAM working register sets.
2: hardware vectored interrupt dispatch, fully suppported by theor accompanying peripheral line. Just a few clocks from raising an interrupt to executing the first line of code (typically switch context then ...) of not only the device but it's reason for interrupt code. No code wasted interrogating bitfields and scanning registers. 2 usecs interrupt response time. Faster than an Intel i960 with its 50MHz clock, that came along later.
Surprised that the TI-8X series and TRS-80 got mentioned as popular applications, but not the Gameboy! (well, it's not _exactly_ a Z80, but it's close enough that reasonable Gameboy emulators are feasible on a TI-83+SE: https://www.ticalc.org/archives/files/fileinfo/419/41990.htm...)
The ironic bit is that the emulation experience is fundamentally flawed because the TI-83+SE has a lower resolution display than an original Gameboy. The original TI-83 launched in 1996, the Gameboy in 1989.
The ironic bit is that the emulation experience is fundamentally flawed because the TI-83+SE has a lower resolution display than an original Gameboy. The original TI-83 launched in 1996, the Gameboy in 1989.
One nifty thing the Z80 did was built-in DRAM refresh: http://www.piclist.com/techref/mem/dram/slide4.html
"Access cheap DRAM just like you do SRAM" must have been an effective sales pitch at the time.
"Access cheap DRAM just like you do SRAM" must have been an effective sales pitch at the time.
> Access cheap DRAM just like you do SRAM" must have been an effective sales pitch at the time.
Yes, yes it was
Yes, yes it was
From back when 3 guys could make a CPU in a year.
The Z80 was also a big deal in Europe, where it powered two (major) brands of micros in UK alone, and was cloned extensively in the USSR.
The Z80 was also a big deal in Europe, where it powered two (major) brands of micros in UK alone, and was cloned extensively in the USSR.
And the MSX standard, pretty big in Japan and a few other places.
Netherlands of course, Spain as well
Sinclair's machines were Z80 based - was there another major brand using it? All the ones in the UK I can think of were 6502 based...?
Amstrad. Their CPC range sold well enough that they ended up buying most of Sinclair Research and releasing a few models of Spectrum variants based on Amstrad industrial design.
One model post-purchase Spectrum even included the same kind of oddball 3 inch floppy drive that Amstrad had been using (another had a built in cassette player, similar to what the first Amstrad CPC had).
One model post-purchase Spectrum even included the same kind of oddball 3 inch floppy drive that Amstrad had been using (another had a built in cassette player, similar to what the first Amstrad CPC had).
The Spectrum +3 . Also, was my first computer.
Andreas bought Sinclair, because Sinclair lost a lot of money, trying to get his "electric car"
I had the +2, the one with the cassette player.
Amstrad CPC464 and CPC6128 were UK based Z80 machines. Not too bad. Mine had a little drive inbuilt and ran CPM. My first computer was a Sinclair ZX80 so anything was better than that.
Amstrad programming is still a thing :)
https://vimeo.com/69787152
https://vimeo.com/69787152
I just added a CPC6128 to my retro collection, and promptly blew it up. :(
I'm going to repair it though, even if I have to replace every single chip. :)
I'm going to repair it though, even if I have to replace every single chip. :)
Oh no! What happened?
Mine is happily running; it's a 464 w/ green phosphor monitor. I'm on the lookout for a reasonably priced colour monitor but they're rare as hen's teeth in Australia.
https://vimeo.com/63990420
Mine is happily running; it's a 464 w/ green phosphor monitor. I'm on the lookout for a reasonably priced colour monitor but they're rare as hen's teeth in Australia.
https://vimeo.com/63990420
Not 'major brands', but all the East German 8-bit computers were Z80-based, and by far most of the other Eastern European machines (AFAIK only the Bulgarian Pravetz used 6502 clones).
I wrote an emulator which covers most of the East German 8-bit machines, some had quite interesting ideas implemented: http://floooh.github.io/virtualkc/ (needs WebAssembly)
I wrote an emulator which covers most of the East German 8-bit machines, some had quite interesting ideas implemented: http://floooh.github.io/virtualkc/ (needs WebAssembly)
The TRS-80 line. In hindsight it seems kind of shocking more computers didn't use them. The machine language was far bettr than the 6502 (IMHO), and they were typically clocked twice as fast.
They were clocked twice as fast because they worked less efficiently internally. The 6502 will read or write exactly one byte per machine cycle; the Z80 equivalent of the machine cycle is the T-state, of which it will spend 4 per instruction byte, 3 per operand or data byte, and 8 (I think?) per data byte read due to an instruction with a prefix. As today, though for different reasons, throughput of CPUs of the time was limited by memory bandwidth, and the Z80 has at least a 3-4x disadvantage here.
This does make the Z80 sound much worse than it is. A 6502 instruction takes at least 2 cycles, which for certain types of instruction means a cycle wasted. TXA and ASL A take 2 cycles, for example, even though both are one byte. It's 1 cycle to read the byte for the instruction, and then 1 cycle effectively wasted. The equivalent Z80 operations take 4 T-states, on the other hand: just the cost of reading the byte for that instruction.
The Z80 also has the upper hand with some more general instructions. LDIR is 21 T-states per byte for the equivalent of a memcpy, where the equivalent 6502 loop might approach 9 cycles per byte only with multiple unrolls, while being far less general. The Z80 also has 16-bit operations, which the 6502 lacks entirely. It's 11 T-states to add one register pair to HL, which is the sort of thing the 6502 will take 15-18 cycles over, and that only in the best case.
But it's not entirely a wash - in fact, quite the opposite. The Z80 has no analogue of the 6502's X-/Y-indexed addressing modes, and with only 3 register pairs (IX and IY being uselessly slow) you'll struggle to keep the necessary addresses live - a pain for anything that's table-driven. (It's 10 T-states to load the address, then 4 to replace the low byte with the index, then 7 to fetch the value there. The 6502 can do that whole lot in 4 cycles. You can also load the other index register this way, then use that to load the accumulator: 8 cycles for a table-indexed table lookup.) The 16-bit operations are annoyingly specific, and for many types of operation you need to shuffle data through the accumulator and back again. In practice this stuff typically negates the Z80's apparent register count advantage.
When I first read through the Z80 data sheet, the thing seemed basically magical by comparison to the 6502! But once I tried to actually write any code, I found there'd typically turn out to be this fairly consistent 4:1 T-state:cycle ratio. You can engineer situations where the Z80 is hilariously better... but they'd be engineered. For typical code, you can expect 4:1. You'll need a lot better than double the clock rate for the Z80 to win.
(Interesting and possibly relevant interview with Sophie Wilson, ARM designer and formerly with UK's Acorn, that touches on how memory bandwidth can influence CPU effectivness: http://www.computerhistory.org/collections/catalog/102746190)
This does make the Z80 sound much worse than it is. A 6502 instruction takes at least 2 cycles, which for certain types of instruction means a cycle wasted. TXA and ASL A take 2 cycles, for example, even though both are one byte. It's 1 cycle to read the byte for the instruction, and then 1 cycle effectively wasted. The equivalent Z80 operations take 4 T-states, on the other hand: just the cost of reading the byte for that instruction.
The Z80 also has the upper hand with some more general instructions. LDIR is 21 T-states per byte for the equivalent of a memcpy, where the equivalent 6502 loop might approach 9 cycles per byte only with multiple unrolls, while being far less general. The Z80 also has 16-bit operations, which the 6502 lacks entirely. It's 11 T-states to add one register pair to HL, which is the sort of thing the 6502 will take 15-18 cycles over, and that only in the best case.
But it's not entirely a wash - in fact, quite the opposite. The Z80 has no analogue of the 6502's X-/Y-indexed addressing modes, and with only 3 register pairs (IX and IY being uselessly slow) you'll struggle to keep the necessary addresses live - a pain for anything that's table-driven. (It's 10 T-states to load the address, then 4 to replace the low byte with the index, then 7 to fetch the value there. The 6502 can do that whole lot in 4 cycles. You can also load the other index register this way, then use that to load the accumulator: 8 cycles for a table-indexed table lookup.) The 16-bit operations are annoyingly specific, and for many types of operation you need to shuffle data through the accumulator and back again. In practice this stuff typically negates the Z80's apparent register count advantage.
When I first read through the Z80 data sheet, the thing seemed basically magical by comparison to the 6502! But once I tried to actually write any code, I found there'd typically turn out to be this fairly consistent 4:1 T-state:cycle ratio. You can engineer situations where the Z80 is hilariously better... but they'd be engineered. For typical code, you can expect 4:1. You'll need a lot better than double the clock rate for the Z80 to win.
(Interesting and possibly relevant interview with Sophie Wilson, ARM designer and formerly with UK's Acorn, that touches on how memory bandwidth can influence CPU effectivness: http://www.computerhistory.org/collections/catalog/102746190)
You sound like an expert! How long would code take, for 32 bit floating point multiply, on Z80 vs 6502?
I'm curious, as a way to compare progress with todays 500 GFLOPS phone GPUs, and 10 TFLOPS PC GPU cards.
But neither Z80 nor 6502 have native 32 bit, nor fp, nor multiply, so a program is needed... this must have been done, for some applications.
I'm curious, as a way to compare progress with todays 500 GFLOPS phone GPUs, and 10 TFLOPS PC GPU cards.
But neither Z80 nor 6502 have native 32 bit, nor fp, nor multiply, so a program is needed... this must have been done, for some applications.
http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html#mo...
You’d be lucky to get KFLOPs on an 8-bit processor.
You’d be lucky to get KFLOPs on an 8-bit processor.
A 4MZ Z80 (or 8080) is about as fast as a 1MHz 6502, because of that.
Arguably the biggest "brand" connected to the Z80 was CP/M[1].
[1] https://en.wikipedia.org/wiki/CP/M
[1] https://en.wikipedia.org/wiki/CP/M
I remember sort of learning (just superficially) Z80 and 6502 assembly at the time (mid to late 80s) and thinking Z80 assembler was much simpler.
I can testimony for Z80 assembly (tough I cannot say anything about 6502).
In high school one of our teachers made us program a Z80 board by hand.
And when I say "by hand" I mean it quite literally: first a flow-chart, then a conversion to z80 assembly (two passes: pencil first, pen later), then datasheet at hand a conversion into z80 opcodes (this time it was three passes, the third one was to recalculate all jumps, absolute and relative ones).
Last step was to input each opcode into memory by hand using an hexadecimal keypad. Then go to address 1800h, hold breath and press RUN.
In retrospect, it was a very enlightening experience considering I and my school mates were like 16-17.
But keep in mind, if a 17 years old can do this with relative ease (it was a technical high school, after all) that should tell you something about the simplicity and effectiveness of the Z80 instruction set.
Z80 <3
In high school one of our teachers made us program a Z80 board by hand.
And when I say "by hand" I mean it quite literally: first a flow-chart, then a conversion to z80 assembly (two passes: pencil first, pen later), then datasheet at hand a conversion into z80 opcodes (this time it was three passes, the third one was to recalculate all jumps, absolute and relative ones).
Last step was to input each opcode into memory by hand using an hexadecimal keypad. Then go to address 1800h, hold breath and press RUN.
In retrospect, it was a very enlightening experience considering I and my school mates were like 16-17.
But keep in mind, if a 17 years old can do this with relative ease (it was a technical high school, after all) that should tell you something about the simplicity and effectiveness of the Z80 instruction set.
Z80 <3
I bootstrapped a 6809 assembler by hand. That took a while :)
It is until you start treating the 6502 as a RISC CPU with 256 registers at 0x0000. I had that “ohhhhh” moment when I had a BBC master back in the late 80s. Zero page FTW. Z80 feels like wading in treacle after that. X86 is an abomination
The 6502 is a much simpler CPU (3.5k transistors vs. 8.5k for the Z80), but the Z80 is easier to use and less limiting --- more registers and addressing modes, a stack not limited to 256 bytes and fixed location, and a more regular octal-format instruction encoding[1].
[1] http://www.z80.info/decoding.htm
[1] http://www.z80.info/decoding.htm
Some of this was due to syntax of their assembly languages. 6502 had letters for different addressing modes, whereas Z80 used parentheses for a memory lookup, e.g. LD A,(HL) uses HL as a pointer, loading its pointed-to value into A (IIRC).
6502 had more addressing modes, but some of them, if not all, could have used Z80 style syntax. After all, it would just be a different the assember (i.e. compiler) frontend, generating the same target machine code.
6502 had more addressing modes, but some of them, if not all, could have used Z80 style syntax. After all, it would just be a different the assember (i.e. compiler) frontend, generating the same target machine code.
[deleted]
I like reading history about old chips like this, i've read about the z80 before... but where is the rest of the article? so short, the z80's story is far longer than this.
For the rest of the article start by reading https://en.wikipedia.org/wiki/Datapoint_2200
Datapoint allowed Intel to continue development with the same architecture but required all future processors to have a shuffled instruction set. The mov group on the 8008 and the 2200 was octal 3ds with d being the destination register and s being the source register. The first digit 3 got shuffled to 1. The registers were also shuffled:
8008 bits 8080
A 000 B
B 001 C
C 010 D
D 011 E
E 100 H
H 101 L
L 110 (HL)
(HL) 111 A
Datapoint did not want Intel's future processors to be able to execute Datapoint machine code. They had a lot invested in their software.
Datapoint also had a 5500 processor which was more powerful than the 2200. It was microprogrammed rather than the simpler logic decode of the 2200. It was compatible with the 2200 but had many more instructions (think Z80). Yes it was that instruction set. The engineers at Intel who worked on the 5500 design left to form Zilog.
I worked as an electronics technician at Datapoint and performed test and repair of many 2200 and 5500 processor boards including writing short machine code routines to exercise the hardware.
After I left Datapoint (1977) I worked for Tandy where I repaired thousands of TRS-80 Model 1 computer boards which used the Z80. When the Tandy engineers came into the repair area with the programmers who had written Level 2 BASIC for the TRS-80 with the first masked ROMs, they tried the ROMs on a board and it didn't work. I told them that all the boards in the area needed repair but I had one that I had just repaired. I was introduced to Bill Gates and Paul Allen and the ROMs were put on my repaired board. I typed in a one line program to count and print numbers on the screen and it worked. Bill Gates offered me a job at Microsoft which had about a dozen employees but I turned him down and stayed at Tandy. I wrote more test programs and transitioned into full-time programming.
8008 bits 8080
A 000 B
B 001 C
C 010 D
D 011 E
E 100 H
H 101 L
L 110 (HL)
(HL) 111 A
Datapoint did not want Intel's future processors to be able to execute Datapoint machine code. They had a lot invested in their software.
Datapoint also had a 5500 processor which was more powerful than the 2200. It was microprogrammed rather than the simpler logic decode of the 2200. It was compatible with the 2200 but had many more instructions (think Z80). Yes it was that instruction set. The engineers at Intel who worked on the 5500 design left to form Zilog.
I worked as an electronics technician at Datapoint and performed test and repair of many 2200 and 5500 processor boards including writing short machine code routines to exercise the hardware.
After I left Datapoint (1977) I worked for Tandy where I repaired thousands of TRS-80 Model 1 computer boards which used the Z80. When the Tandy engineers came into the repair area with the programmers who had written Level 2 BASIC for the TRS-80 with the first masked ROMs, they tried the ROMs on a board and it didn't work. I told them that all the boards in the area needed repair but I had one that I had just repaired. I was introduced to Bill Gates and Paul Allen and the ROMs were put on my repaired board. I typed in a one line program to count and print numbers on the screen and it worked. Bill Gates offered me a job at Microsoft which had about a dozen employees but I turned him down and stayed at Tandy. I wrote more test programs and transitioned into full-time programming.
Me too, love this stuff. For those of us who haven't a clue about coding or software (I'm a retired neurosurgical anesthesiologist), reading this comments section and its ilk is like visiting the Egyptian Museum in Cairo and gazing at the hieroglyphics. My understanding of what I'm reading/seeing is nil but the wonder titer is high.
And, then, they thought: "hum... let's do our 16 bits microprocessor... and forgot the retro compatibility with our own 8bit chip!".
What could go wrong?
The 8086 wasn't binary compatible, but it was (more or less) software compatible---you could mechanically translate 8080 assembly to 8086 assembly and get about 95% converted without issue.
Motorola broke compatibility completely when they transitioned from 8-bits (6800, 6809) to 16/32 bits (68000) [1].
[1] From a hardware perspective, the 68000 is a 16-bit system; from a software perspective, it's a 32-bit system.
Motorola broke compatibility completely when they transitioned from 8-bits (6800, 6809) to 16/32 bits (68000) [1].
[1] From a hardware perspective, the 68000 is a 16-bit system; from a software perspective, it's a 32-bit system.
I think he's talking about Zilog's 16 bit processor, which was completely incompatible with everything and is more or less forgotten now. (Literally in my case, I can't even recall its name).
Yes, I was talking about Z8000. Amazing processors (Z8001 and Z8002), but Zilog took too long to clean the bugs. That, and the lack of retrocompatibilty sealed its fate and Motorola 68k took over.
Zilog tried again and again (Z80000, Z180 with Hitachi, Z280, Z380...) but never recovered.
I have two Z380 waiting for the completion of its motherboards... :-)
Yes, of course, that's the one. In the embedded shop I worked it I'm sure we looked at it briefly - it was overkill for our applications and also didn't have the natural advantage of being in any way compatible with the desktop computers we used for embedded software development.
I think an even bigger issue was the internal incompatibilities between 68000 variants, while Intel kept on maintaining compatibility all the way to the present day.
It's pretty amazing how well Intel has achieved that goal. Modern Intel CPUs can still natively run MS-DOS and applications for it. There are obviously problems with some games running too fast, and I seem to remember some issue in a common runtime (Turbo Pascal?) where a timing calibration loop would divide by zero because it took zero timer ticks to run a busywait loop. Those were already issues 20+ years ago, though.
Microsoft's first hardware product was a Z-80 card for the Apple II:
https://en.wikipedia.org/wiki/Z-80_SoftCard
My Apple II had one for basically the sole purpose of running Wordstar under CP/M (I don't recall why we didn't just use Apple Writer).
https://en.wikipedia.org/wiki/Z-80_SoftCard
My Apple II had one for basically the sole purpose of running Wordstar under CP/M (I don't recall why we didn't just use Apple Writer).
Had this book on my shelves for many years https://archive.org/details/Programming_the_Z-80_2nd_Edition...
z80 is a lovely instruction set, and a delight to work with. These days CPUs are incredibly complicated, with massive instruction sets, pipelining and caches, microcode and SMP, lots of crazy nonsense going on. Anyone who has ever worked with the x86 family at a low enough level knows just how insane it is. z80, on the other hand, is just a reasonably fast CPU with predictable timings and an instruction set which can fit on an index card (well, if you use both sides). It still has plenty of secrets to discover, though - easily half of the instruction set is undocumented and full of useful tricks. I have spent a lot of time with this CPU, none of it wasted :)
After suffering the gaps in 8080 command set for years, this was the greatest joy ever. Also the new assembler was such a pleasure, you could just LD everything to everywhere.
The Z80 was a contemporary of MOS Technology’s 6502, and like that chip, it stood out not only for its elegant design but also for being dirt cheap (about US $25).
Anybody got a graph of historical 6502 vs Z80 prices?
EDIT: Some previous HN discussion "On choosing the Z80 over the 6502 (2014)" https://news.ycombinator.com/item?id=10763274
Anybody got a graph of historical 6502 vs Z80 prices?
EDIT: Some previous HN discussion "On choosing the Z80 over the 6502 (2014)" https://news.ycombinator.com/item?id=10763274
I designed a few Z80 projects in the early 80s, and they were a few pounds then.
My father's first computer was a Sinclair ZX81, powered by a Z80. He still has it at home.
I tried getting it working a few years ago, but it wouldn't work with the TV. I wasn't really interested enough to get an old TV to use with it. Pretty amazing though, not many people are able to say they still have their first computer.
I tried getting it working a few years ago, but it wouldn't work with the TV. I wasn't really interested enough to get an old TV to use with it. Pretty amazing though, not many people are able to say they still have their first computer.
I still have a Timex 2048 (a clone of Sinclair ZX Spectrum). It is not the first Spectrum I used, but first I owned. It works still and I have a family tradition of plugging it into our TV set each Christmas and playing the games we have grown up with. Years ago I could use my PC workstation to "play" tape recordings into it but nowadays you have to use an Android phone [1] as I think there is too much of sound filtering built in and the tapes just don't load.
[1] https://play.google.com/store/apps/details?id=dk.rift.tzxdro...
[1] https://play.google.com/store/apps/details?id=dk.rift.tzxdro...
http://www.old-computers.com/museum/computer.asp?st=1&c=1168
I think my dad still have it in the basement, but i recall he never got much out of it.
I think my dad still have it in the basement, but i recall he never got much out of it.
I still have my 6502 based Acorn Atom, bought in 1980, a predecessor to the BBC computer.
Put the input to the TV modulator into something like this:
https://sewelldirect.com/composite-rca-to-vga-converter
https://sewelldirect.com/composite-rca-to-vga-converter
I still have my ZX81.
My dad bought it for the family when I was 11. It was to me the most anazing and fascinating thing. It absorbed my attention completely. I remember handwriting code on the bus to school.
I still have my first computer, Amstrad CPC464 running fine today. It boasts a Z80 too.
They still manufacture z80 DIPs and it’s crazy easy to build homebrew computers with them (you really only need a few chips total to have something that works.) it’s something I think anyone that uses computers heavily should try.
In the 8080, most ALU operations set the "P" (parity) flag to indicate if the result had an even or odd number of 1 bits. On the Z80, that flag would be set the same way for logical operations (AND, OR, XOR), but for ADD/SUB operations it was used as an overflow flag -- not carry out, but it indicated that the 2s-complement result wasn't able to accurately represent the result.
There were also some changes in the way the half-carry (nibble carry out) flag was handled in some instructions too.