Wow! 1000 views in the first four hours, which is a new record for my little channel. I wish UA-cam had told me a while ago that they wanted me to produce Z80 content. 🤣 Thanks everybody for your support! I'm working on the "Hello, World!" ZX Spectrum tutorial right now, and I hope you like it when it comes out on Monday. Cheers!
@@solhsa nice site. (About the second set of registers A'-L'. they are useful as scrap registers in interrupt routines, Just switch and you don't need to push them and later pop them of the stack)
For those who really want to see how the Z80 and 6502 differ and how best to use very different architectures, there is nothing better than reading actual code that solves the same problem on both CPUs. A good starting place are the two books by Leventhal and Winthrop: _6502 assembly language subroutines_ (1982) and _Z80 assembly language subroutines_ (1983).
The first computer I owned, a TRS-80 model 1, had a Z80 processor. I did a lot of assembly language programming on it as it was the only way to get acceptable performance. However, at work and when working with friends, I often worked on 6502 code (not 65C02). So I know both of them. It was often a lot "easier" to do programming jobs that required working on strings in memory on the Z80, as it had all those 16-bit registers that could hold memory addresses, and that you could easily increment or decrement to walk through strings. That was a hassle on the 6502. But of course with a macro assembler, it was quite easy to hide that. One could either say the 6502 had a lot less registers, or that it had way more. Because the zero page could be viewed as registers. However, this also meant it was more suitable for small dedicated systems than for "a real computer", as this zero page would often be used a lot by the operating system of the computer and was not so readily available to applications, especially not when you would want to use a higher level language and the number of variables would often be a lot more and they would not fit in zero page. The same issue occurred with the stack, which was only one page in length. Enough for assembly language programs that wanted to do some nested subroutine calls and save some registers along the way, and to handle interrupts, but it was way too small for stack frames as used in a higher level language to hold local variables. Note that most of the code running on the Z80 usually was in fact 8080 code, so it would not use those extra features on the Z80 like the IX and IY registers, the alternate registers that could be swapped, etc. A lot of code was never "optimized" for the Z80, e.g. the BASIC ROM on the TRS-80 contained almost no Z80 instructions at all except the use of IX in some low level routines for I/O that were added especially for that system, and the relative branches whenever possible (done as an optimization to save ROM space). This was true for a lot of other systems as well, as CP/M was originally written for the 8080 as well and even though the majority of CP/M systems was Z80 based there still was the desire to have some compatibility with the 8080 so the extra instructions were often not used. One thing that I learned when working on these two processors is that althoustruction set is more powerful, the processor still is slower. For a fair comparison you should compare a Z80 running at twice the frequency of a 6502, as this would result in about the same memory speed. But still, those nice Z80 instructions often burn a ridiculous number of clock cycles! The 2-3 6502 instructions that would do the same thing as a Z80 instruction often would execute in less time. In many cases, a small loop that has to execute as fast as possible can be done quicker on a 6502 than on a Z80. Even the amazing LDIR instruction consumes 21 cycles per copied byte, which at the equivalent 6502 clockrate would be 10-11 cycles, which is enough to write a special-case variant of the same thing in 6502 instructions. (of course it is more difficult to write the general case with 3 16-bit values for src,dst and count, but that is often not required anyway)
On the British Z80-based microcomputers and on the videogame arcade cabinets the instruction set was fully utilized. I doubt as many CP/M machines were ever built as ZX Spectrums alone were built. On the Speccy the LDIR was ignored fairly early and the most advanced games actually used the stack pointer when they needed the fastest possible loop, such as clearing the screen or drawing the screen from a RAM buffer. In the microcomputer games world, the fastest smoothest games on the C64 were due to using the other hardware well and were games with scrolling and sprites. On the speccy there was no other hardware for scrolling or sprites but we even got full framrate 3D wireframe games using only the CPU and the C64 couldn't manage that with the 6502. It seems that there was almost no crossover between the Z80's serious CP/M world and its gaming world.
@@andrewdunbar828 it should be noted that the 6502 in the commodore was only runs at 1 MHz, whereas the spectrum's z80 is at 3.5; hardly an apples to apples comparison of the CPU architectures
@@elideaver Even worse is the fact that the input clock frequency has not much to do on the final performance. Both 80xx and 6xxx architectures do not use the clock the same way to sequence the instructions. It is more on the data bus side that a better comparison can be done.
I’ve programmed both, plus many other microprocessors. The Z80 definitely has a more rich instruction set, thought I do like programming some of the microcontrollers that have a pretty close architecture to the 65c02. The 68hc08 is quite nice, it fills in many of the gaps in the 65c02 instruction set. It is a bit of a different mindset when coding for one or the other. I find that the Z80 is more register-centric where 65c02 as well as all of the 680x families are more stack and/or memory oriented.
I'm definitely on the team Z80. I love that it has separate I/O address space as well as a family of dedicated peripherials. I have built an entire computer with it from scratch, it wasn't too difficult either. Anyways, great episode! Keep up the good work.
@@ehsnils I went for RC2014-style design, but with some modifications. I wired everything by hand on prototype boards. Apart from the CPU, I currently have PIO card with LEDs, buttons and switches, CTC card, DART card, AY-3-8910 sound card, 20x2 VFD card 32k ROM + 32k RAM card and 16k + 512k RAM expansion card (with 512k chip missing at the moment). I also want to build an IDE card and VGA card and probably some more like RTC or FPU. It runs assembly programs, either from ROM or loaded from serial and 32k BASIC. I'm planning to get 56k BASIC runnung when my missing memory chip arrives, and perhaps CP/M later on.
I could always see the clever optimisation of the 6502 but I was team z80 - all those extra registers and the additional 16 bit commands made it easy for my style of coding. I was a little frustrated when at college we had to do 8088, in an odd way it felt like a backwards step from z80.
@@lezbriddon Zilog's successors to the Z80 all failed. When non-tech people starting buying computers for boring business reasons, IBM a big old company they trusted. In the meantime there was the Motorola 680x0 in Apples, Unix boxes, Atari STs and Amigas until the 486 and Pentiums showed that Intel was going to drive things forward for a while.
Zilog cocked up their Z8000 (aka Z8K) 16 bit micro. However they did release a fantastic eZ80 microcontroller decades later that can run at 50MHz and lots of RAM. It's used with some TI-84 calculators.
IBM decided to use the 8088 because it could easily port 8080 CP/m programs as .COM files and be able to run new 16-bit 8088 programs as .EXE files. If you look at the design of the IBM PC - it's just an adaption of a basic S100 bus system with a clever keyboard interface.
I once read that the only reason why the initial IBM PC used the 8088 was because the 68008 wasn't going to be available for another 6 months. Imagine how much better the (CPU) world would have been if it would have been the other way around.
In 1983, a company called Visual Technology came out with a machine, the V1050, that used a Z80 for the main CPU and a 6502 for the graphics processor.
Thumbs up within 2 seconds from me. I grew up with z80 and it’s a miracle to see a video like this. Congratulations on posting this, it might be watched in 1000 years time!
I loved the Z80. Was very popular in GDR since we produced a clone chipset to the Z80 so we could use all peripheral chips or even replace broken CPUs (as in my Spectrum) with in-country production chips.
For me the big plus with the Z80 was the vectored peripheral interrupt mode 2. It meant that with the right peripherals you could do very fast and efficient interrupt handlers compared to other CPUs of the time. The only pity was that in response to an interrupt all registers were pushed adding some 14 or so write instructions when your interrupt routine might have only needed 3 or so of the registers.
I've found that people always prefer the one that they learned first. I think the Z80 was also chosen in many systems because it was easier to support at the board/electronic/chip level, memory, clock signal, etc... It been a long time, so I could be wrong.
That is true for a lot of people but not all. I started with Z80, then 68000, then 6805, then 68HC11, then AVR, then MSP430, then ARM. My favourite for assembler programming is MSP430, and my favourite for small systems using C (hides some assembler ugliness) is AVR. For bigger embedded systems I prefer ARM and for still bigger systems then 68000 (both in C). Debugging on MSP430 is also marvellous because you can monitor variables live while the code is running, something the others won't let you do.
I have a very interesting experience: I planned to build a 6502 computer for years but switched to Z80 halfway! The reason is that the Z80 has a secret 'protected mode' which can be realized by connecting IORQ with external circuitary, effectively disabling any IO operation. IO can be enabled by a flip-flop connected with a simple 74LS30 gate which 'filter out' a RST instruction, creating a controllable 'interrupt entrance gate' into a system-level subroutine.
I like both, but my preference is towards the 6502, because it does more with less (more per clock cycle, with fewer transistors), and the instruction set is so much more orthogonal. Zero page mode was a neat hack, and not without precedence: it wasn't uncommon at one point to use the bottom block of memory as a register bank, and the zero page basically gave you a bank of slow registers to complement the three main fast registers. One fun thing about the Z80's DJNZ is that it's Turing complete by itself!
Dude, because we all wish someone like you could teach us all the architectures. This video is a good transition to your z80 series, as I'm fairly proficient with 6502 but I need to catch up with a childhood growing up without a z80 based micro.
I've been on team Z-80 since the early 80s! When my friends all bought Apple ][, I bought an Exidy Sorcerer. Never regretted that decision. Just finished a retro Z-80 project on a breadboard, so much fun and so easy to use the entire family of Zilog chips. Here's to the venerable Z-80 and all that it brought to the world.
A look at instruction timing would be interesting. That's where you pay for the Z80's larger instruction set, sometimes in surprising ways. It always amused me that when you count up the t-states, a loop on the Z80 can be written to run faster using simpler instructions rather than the built-in LDIR, etc., convenience opcodes. Try it! Thanks for a fun revisit of the old 8-bit CPU rivalry.
In fact it is surprising that there were no newer devices from Zilog or competitors that would implement the same instruction set in way less clock cycles. After all, that happened in the 8086 line quite frequently. Maybe because in the Z80 days there was more software that actually relied on the instruction timing and would not run OK on a device that executed the instructions faster at the same clock frequency?
@@Rob2 that would be my guess. And really, the Z80 is "fast enough", especially the Z80A and later revisions, for any of its target applications. You don't need a ton of computing power for embedded systems, usually, and predictability is much more valuable
@@Rob2 There is a chip called the R800, which is a more modern 'pipelined' CPU, which supports the Z80 instruction set. It also has a full 16 bit ALU, which makes instructions like ADD HL, BC take only 1 or 2 cycles instead of 11. On average the R800 executes instructions 4 times faster than the Z80. At around 8MHz, that means its speed is equivalent to a Z80 running at 32MHz.
The Z80 was better suited to business type applications due to the 16 bit stack pointer. The 65C02 could only handle 256 bytes of stack space, or 128 levels of nesting with no parameters. With the Z80 you could push parameters onto the stack, call the subroutine and not worry about space (at least any more than you worried on an 8 bit machine). The 65C02 was the faster of the two, running at least twice as fast clock for clock, and better suited to control (zero page could be treated as a big block of registers). You pays your money and you takes your choice.
The 6809 was the best 8-bit CPU I ever worked on. I has great addressing mode. The 6809 are a great beginners CPU. Addressing mode are more like the 68000 CPU, but still 8-bit computer.
I used the 6809 very late, in the early 2000s making a SUMO BOT using a 6809 SBC. I adored the assembler. I had been using 68000 since the early 90s and that for me, is still the nicest CISC cpu; especially with the great AMIGA chipset. It is so flexible in it's addressing. And it had a mulu.w instruction! Something that made me very happy. Something I envied the dodgy 8086 having and something I missed on the 6502 :D So there was a machine that again, outperformed the massively expensive XT we had for mere pennies on the dime, in comparison :D
I used to work heavily with 6502 assembler. I always felt that the way MOS Tech designed the instruction set was by creating a big chart with all the base instructions along the top and every instruction mode known to mankind along the side, then fired a shotgun at it and implement instructions wherever the shot landed.
When Steve Furber and Roger (now Sophie) Wilson saw the way that the 6502 derivatives were created they thought OMG!! What a mess!! and thus created the ARM processor.
I did a lot with assembly, FORTH, and even some C back in the Z80 days. I played with a few different CPUs back in those days. I'd say the 68000 was my favorite but it was overkill for little embedded systems back in the day - and much more expense to build up into a system. For building up a small system from scratch in a hurry nothing could beat the Z80 for me. I could start with a box of parts and in a day have a little hand wired machine running, and for much less than $50. I never warmed to the 6502 but that's just personal preference.
it would not be possible to have a similar speed at hw level ( a true silicon chip) for tech reasons. However SW emulation or FPGA could reach very high speed . for example a FPGA could run a 6502 @ 50Mhz
Great and very interesting vlog, thanks! Re: feat of building a CPU back then is not only the size (and hence, defect ratio), but also the lack of tools. Masks were done manually by cutting and assembling them. They were verified visually, just imagine, no post-layout simulator. I recommend reading Commodore: A Company on the Edge by Brian Bagnall, where that part of history on the 6502 is very well described (the rest though is average and goes down from mid-book to the end, but the first part is more than worth it).
Z80. My first computer was an H/Z89a with 2 Z80s. My first code was "Hello World" in Assembly (with flashing text). Then I got Fortran-IV and Dartmouth BASIC interpreter. All a great experience.
@@honkhonkler7732 I had a lot of fun coding the 6502 which was actually the 6510 in the C64 computer (and not quite the 65C02 but close). The Z80 looked fascinating and more advanced but I never got the opportunity to use it. The 6502 was quite nice.
Sega Master System, Sega Genesis, Neo Geo AES/MVS...Z80 for the win! Just a legendary processor with an unbelievable history behind it. Not to mention how many arcade cabs were run on Z80's.
Z-80: Plods along, lifting one foot at a time. 6502: Canters along. The Z-80 has the DJNZ instruction, "Decrease and Jump if Not Zero" which is just one byte long and does the equivalent of DEC B followed by JR NZ -- obviously this is handy for creating loops. The 6502 -- which inspired the original ARM instruction set, where _every_ instruction was conditional -- is a bit more RISC-like in some ways, including the way it uses both edges of the clock: data is written or read from memory on the "tick" and moved internally on the "tock". The Z-80 only moves data on the "tick". Some microprocessors of the era used RAM to hold the processor registers; and you can consider the 6502's short addressing modes as being 16-bit opcodes that use the whole of zero page as either 256 8-bit registers or 128 16-bit registers.
As a z80 coder I saw the zero page of the 6502 more so as a way to implement instructions that otherwise don't exist. Whether that is the norm I wouldn't know though.
Very good, fair conclusion. Did hand coding for both Z80 CPU and 6502 and 6802. The 6802 is very similar to the 6502; simple! This is VERY important if you are hand coding. Fun times back in the early 80s for me. MC6809E is the Queen of 8 bit. Perfect register set.
Same. An friend and I tried to have them run simultaneously. It did work at first but there was some bug in that Microsoft card and it never ran stable.
For me, the Z80 always had the edge if you needed more memory space since the Z80 had proper I/O ports rather than having to use memory mapping for I/O as in the 6502. On the other hand, the 6502's PCR (Program Counter Relative) instructions were a really slick way of making a machine code program which could be loaded and run anywhere in RAM. I always preferred the Z80 and I think it still has the edge in my mind, but I also like the 6502.
My first computer was an OSI C1P (6502); Next was an S100 (Z80). Made programming the 6502 feel like a straitjacket. I now run CP/M Plus on a Z280 @20 MHz. Zilog rules. ;-)
My favorite 8-bit microcontroller to write in assembly was the Motorola HC05. Its a von Neumann processor with address modes available all applicable instructions. Others, like the 8051, PIC, and AVR, have Harvard architecture, with RISC-ish instructions.
There's more ISA innovation in either of these processors than you'd get in 10 years of CPUs now. Chuck Peddle and Federico Faggin were both absolute geniuses.
Back in the day, I learned Z80 first doing assembly by pencil and paper and using the fantastic "front panel" debugger on the Research Machines 380Z. Later on I moved to 6502 using the BBC Microcomputer's BASIC assembler and my initial thoughts were "this is rubbish... where are the registers? Why is there no DJNZ?" But, after a while, you realise that neither is "better" or "worse" they just have different approaches and each has it's advantages. My next port of call was CP/M and the 8080... and I never could get over how "ugly" the Intel assembly language was and that carried through to the 8086, 80286 and 80386. These days it's all AVR, ARM and MIPS... my enduring legacy is Intel = ugly. I did a bit of 6800 and wish I'd had a look at 68000 but I just never had the chance.
65C02 needs to use more expensive static RAM because it doesn't have built in refresh. Well, no. The Apple ][ used DRAM but the video display memory layout was designed so that the video output also refreshed the DRAM. In 1983 some friends and I made a wire-wrapped M6809 computer. We used 64 kbit DRAM, and we arranged for an interrupt every few ms which executed 256 bytes of NOPs (I think they may have been multi-byte NOPs). The percentage overhead was acceptably low. Interestingly the Z80 hardware refresh was designed only for up to 16 kbit DRAMS (7 bit counter for an 128x128 array) and could not be used as-is to refresh 64 kbit chips.
I didn't mean to imply that the 6502 couldn't use DRAM, just that it needs to be fast and requires external logic. SRAM is just the path of least resistance, if a bit more expensive per kB, but that cost can be offset by not requiring logic to manage the DRAM.
@@slithymatt fair enough. Nowadays we can use cheap DRAM with a convenient parallel-SRAM interface e.g. www.digikey.co.nz/product-detail/en/issi-integrated-silicon-solution-inc/IS66WV51216EBLL-55TLI/706-1427-5-ND/5320130 Also, parallel flash is much cheaper and faster than EEPROM.
I do want to do a 6809 series eventually, as my first computer was a CoCo2 and I also had a Vectrex at the same time. What I really need to find is a good emulator for at least one of them, preferably the CoCo2
@@slithymatt - XRoar or MAME are probably the best for Coco 1/2. Unless you want to use a web based one (like Mocha: www.haplessgenius.com/mocha/). MAME and VCC are good for Coco 3.
@@slithymatt - Also, feel free to catch an episode of CocoTalk (live every Saturday at 2 PM Eastern, on UA-cam, Twitch and Facebook), and if you have any questions on the emulators, the Coco in general, current assemblers, etc., feel free to ask us in the chat. (ua-cam.com/channels/spFbd1b1vwuhsj0ZVehd2w.html for the UA-cam channel).
6809 with OS/9, version 2 with multi user. In uni. we had two systems, where we used to code C in. To bad the memory protecting was non existing, so when we wanted to try a program, we had to warn the other students so they could save their files. :-) Except that, it was a great OS, Unix like with dynamically loadable modules. Really liked it.
Great detailed compare and contrast video. I wonder how instruction count and byte counts would compare for significant equivalent code samples. 6502 instructions do less but take fewer bytes to encode.
Not many fewer. The three byte opcodes only take one byte operands, so there is a hard limit if 4 bytes per instruction instead of three for 6502. And there are way more Z80 instructions that are single byte implied opcodes
I used Zero page indirect addressing for generating background graphics using interrupts, on the old Commodore Range like the C64, C16 Plus 4 and Vic 20 which is the machine I learnt ASM on. Also used to a lesser extent due to hardware differences on the early Ataris like the 400 and the other 8 bit machines up to the 128k version. The main reason for using it was 'if you can believe it' the speed.
Great video! However, I wouldn't call the "alternate registers" A' etc real registers. You can't do anything with them other than swap them for A etc. So they are really more like a fast storage area for register values. In practice they were rarely used I think
@@andrewdunbar828 Thanks for your reply, I stand corrected! But was I right in saying A' etc are not proper registers in that you can't do anything with them other than swap for A etc. Eg you can't add numbers onto A'.
@@JohnBlackburn1975 You could "do" anything with them, but the only opcodes the CPU had was to swap them. So you basically mixed swap opcodes and other opcodes, kinda like using a stack or banked RAM or storing variables in memory, but faster and they swapped in fixed sets.
I think you forgot the 65C02 zero page indirect mode which was added to the 65C02, as in LDA ($34). It's like Indexed Indirect. But better because you can pass a raw pointer to a function without having to reset one of the index registers.
I mentioned it in passing, but didn't make a slide for it as it didn't add much to the conversation after already covering direct Zero Page and Absolute Indirect modes.
Even though I am die-hard 6502 fan (it was my first love), I have to admit that the Z80 is a better CPU. Well, maybe not better, but easier to program for. The bigger register file is so nice, and the shadow registers makes interrupt handling so much easier.
In 6502, the 0 registerback could be thought of as registers (256 of them). But yes, I was a 8085/Z80 coder, not so much 6502. I also loved the 6809, which still think is the best 8-bit CPU ever built.
I think the 6502 is easier, as you can do direct in memory manipulation, saving on load and store instructions on the Z80 (which ironically is a very RISC thing). But I always missed a single 16 bit register on the 6502. If they'd implemented a W register with 16 bit length that would've really made it a killer CPU. 16 bit is where the Z80 shines over the 6502 and when you need to do a lot of >8 bit work, it for sure is the better choice.
Just paused the ad to say f 6502 already I always thought if I learned an old cpu assembly language and architecture it would be 6502 but it turned out to be the z80. I’m only half kidding, like what you want ❤️💙💜💗🖤💛💚❣️
The two chips I most enjoyed working with (at the time) were the Z80 and 6309. The Z80 had several useful features including an alternate register set (which I used very heavily both for OS implementation and ultra-fast algorithmic code), dual memory mode and banked memory support. However, at least where we were in South Africa, the 6309 from Hitachi was nearly as good and had the advantage of extreme low power operation. Paired with static CMOS memory we built a programmable data acquisition machine for use in mining. The year was 1982. With external register banking, we combined 256kbytes of RAM, a 4 line graphic capable LCD, membrane keyboard, photocoupler serial communications and a MW radio charger for the Nicad batteries. We got a lot of use out of the cmos versions of motorola's 8/16 bit CPUs (mostly from Hitachi) but the Z80 (and CMOS versions of the Z80) ultimately eclipsed the motorola chips. For algorithmic code, and especially DES encryption, it was possible to make extensive use of the alternate register set and single byte instructions to achieve performance that would embarrass an 8088 running at 8MHz with the equivalent encryption executed in C! The last time I used the Z80 was in EFT-POS terminal designs. After programming the 68000 series chips (especially the 68032) I found the Intel x86 chips to be a disappointment. Yes, they triumphed, and by the time we got the 486 they were decent enough chips. But their success was more a consequence of business/marketing decisions rather than technical merit. In particular I loathed Intel/IBM's paged memory system. What were they thinking?
well, this stuff is simple old school stuff for us older people, but this where the rubber hits the road. I know people prefer what they first started with, but it's best to be flexible when it comes to a cpu or microcontroller for that matter. Theres no need to know every instruction, but it's important to know the ones you need for your specific application. I haven't built a home brew computer with a Z80 in a long time..who knows maybe I'll feel nostalgic and put together one. I have one or two Z80s in my parts box and plenty of TTL chips. The Z80 greatly outclasses the 6502. The only reason the 6502 was so popular was because it was cheap compared to the Z80 and it was fast. It generally takes more code to do the same job, but it's not too shabby. I think it would be better to compare it to the mc6800 and the 6809. One thing to do is not get stuck on how many different ways you can address ram with the Z80 or do the same thing different ways. It's just a preference thing. One thing people should understand is learning the instructions is not learning to program. Good video though. Building a project of some type would probably bring this all together for some people. I'm amazed at all the interest in this stuff. Today things are so much easier. In the 80's this was all we had and everything cost so much more than today.
I did a bunch of 6502 coding (all in hex) on the C64. I coded a Pacman clone but never figured out how to do sound and did a bunch of other stuff just for fun. The first CPU I had a play with was the Signetics 2650 8 bit CPU.
Nice comparison. I think when compairing Z80 and 65C02 maybe the comparision should have been between eZ80 (quote "runs at 50 MHz, but has 3-stage pipeline, so in theory it could reach 3× the speed of Z80 at the same frequency"). :-) One flaw on Z80 is that some instructions takes up to 23 clock cykles. I guess thats where the simplicity beauty of 6502 shines. Another thing is to look more into the design goals when the chip was made. In case of the Z80 you had the NMI -non-maskable interrupt making it easy for external hardware to call for a special routine and leave whatever the CPU was doing. Another design goal was full support for dynamic ram refresh built into Z80 (most other CPU:s demanded external extra cirtuits for this and dynamic ram where cheaper than static ram). And also, ready made chip family for PIO (Parallel Input-Output), SIO (Serial Input Output), CTC (Counter/Timer Channel) made construction easy and compact. Combined with a (for the time beeing) cheap developers kit made Z80 popular.
@@daschewie There is few fair comparison in the CPU world. But normal should have been comparision of Z80 and 6502 hence my comment. (By the way...read the rest of previously comment more info there).
@@daschewie Well, if you're not happy with the eZ80, then how about Hitachi's version of the Z-80, the HD-64180? The Hitachi chip included lots of on-chip peripherals and an MMU, but IIRC, it was still a Z-80 as far as software was concerned (albeit with many/most? requiring fewer clock cycles), to which Hitachi added an 8x8 multiply and a handful of new and improved block transfer style instructions. The Hitachi part also had pipline (3-stage?) and could run at up to 10Mhz. It was good enough that Zilog licensed the HD-64180 from Hitachi and marketed their own version of the chip called the Z-80180 and to which they added some more instructions and called it the Z-180.
You don't have to use those slow instructions on the Z80 though. You can instead use several simple instructions, just like on the 6502. For slow code that didn't matter we used to use the slow instructions because they were easy to program and read. For fast looping code all kinds of crazy tricks were done. In the ZX Spectrum game programming world they found out abusing stack pointer was the fastest way to clear the screen. But you wouldn't use tricky stuff like that for every loop.
@@andrewdunbar828 True! They could actually have stripped of like 35% of all Z80 instructions since the slowest and most advanced could be replaced by a row of allready existing commands. But those where the days...
We're all little in this fight, but I started assembly programming with Motorola chips, and I'm still in team big-endian. May have to throw the 6809 into the melee...
That's strange to me. I couldn't manage the move from z80 to x86 (via m68k) but my friends from 6502 backgrounds didn't find x86 confusing the way I did.
You missed to mention that the Z80 supported 128 IRQs directly in IM2. Much better than the clumsy interrupt mess of the x86. Also, if you need pipelining and cache, the Z280 is the 16bit version that has that. It also has multiplication/division, support for SMP and multiple-coprocessors.
@@caldodge That didn't really make the Z80 faster since it used more clock cycles for its instructions. Also, back when these were widely used, RAM was clocked as fast as the CPU, so zero page access was not slow for the 65C02. On average the 65C02 micros of the early 80s were faster than the Z80 based ones. The BBC Micro was a speed demon, helped by having a 2MHz 6502 and 4MHz RAM (the latter allowed the CPU and the VDG to interleave their access).
@@deffunc this is the usual fake notice: RAM was not so fast than cpu. the c64 had to stop the cpu when the VIC-II do some memory access. this proves the fact that ram was not so fast. the 6502 lacks dram refresh. adding this will take some bandwith requiring the cpu to stop the apparent faster clock on z80 is a requirement. for a z80 it is 'normal' to have a 3.5Mhz clock speed like for a 6502 was normal to have 1.5Mhz. Faster speed would have been possible with later models, but they required faster ram. Next because the z80 split it's clock in internal sub operations it is not so aggressive in memory bandwidth requirements. In other words you can use the same ram chips on 6502 @1Mhz or on z80 @3.5Mhz. But to have a 4Mhz 6502 you need more fast dram that allowed you to use a 20Mhz z80. I've programmed the z80, 6502, 8086/8088. Most people argues that z80 is a lot faster than 6502. In reality the performances largely depends on hw where the cpu is used and the kind of operations the cpu is employeed for . Yes, in the overall the z80 was faster than 6502 but not because of its clock , instead more because of its internal architecture. Comparing pure processing power a 3.5Mhz z80 with 1Mhz 6502 cpu the former is faster, but a lot depends on kind of instructions you use. in the average the z80 was faster in the range 30-50% than a 6502. Of course you can create your own examples tailored to show the 6502 or z80 to be the winner but in the average the range is as explained. For example a simple TXA is two times slower than a LD B,A on z80 even at same clock speed, but i can say the opposite if i use some sophisticated addressing modes available on 6502 missing on z80. the z80 ad some kind of indexed addressed but due to two byte operation code they are very slow. In this situation even a z80 @4Mhz could be slower than 6502 @ 1Mhz. the 6502 however, because of its simple instruction set and limited registers is more easy to program and optimize. on z80 you need to plan accurately the register usage if you want to squeeze the last drop of power.
@@gasparinizuzzurro6306 For micro benchmarks such as memory copy or maybe anything else that fits into the Z80 registers, you could (with some pain) make the Z80 go quite fast. But the 6502 Zero Page was basically as fast to use as Z80 registers except you have 256 8 bit "registers" or 128 16 bit int/pointer registers, so in more complex code the Z80 has to continually spill and reload things from RAM, while the 6502 just has everything sitting there. I agree that just programming naturally on the 6502 gets much closer to optimum performance than doing the same on the Z80.
The BBC micro used DRAM with a 6502 by interleaving access with the 6845 video chip. This achieved DRAM refresh and dual port RAM at the same time. Genius.
I have a small 65C02 design that runs reliably at 20MHz. I have heard of people pushing them further than that too. The real limit seems to be the support chips. If you want it to go faster, drop an optimized VDL code implementation into a ultra fast FPGA and you could get impressive speeds. Of course you'd have to implement the RAM, ROM and I/O in there too to get all that to work together.
@@winstonsmith478 well, it's a matter of preference, really. The Commander X16 is being sold as a hobbyist computer, so through-hole DIP is the best way to do it, when a lot of folks want to solder from a kit. The plan is to phase in later versions that are discrete SMT chips and eventually an FPGA or ASIC implementation, which could have a "turbo" mode, potentially.
@@slithymatt Ah, I understand now. For me, it's like a Turing Test. If it does exactly what I want, act exactly like computer XYZ, I don't care what's inside. For me, for example, a Raspberry Pi-based emulator that can emulate the entire Amiga line at greater than full speed, for most models at MANY times full speed, is plenty good enough and CHEAP. If it looks like a duck, walks like a duck, and quacks like a duck... I can understand the desire to preserve original hardware, but it's still a bit amusing to me to see a Raspberry Pi-based module made to plug into the Amiga CPU socket to emulate a faster MC680XX CPU while retaining timing compatibility with all other stock motherboard components or one dedicated just to provide HDMI output when the Raspberry Pi alone could be used to emulate the entire system at greater than full speed.
Eventually I build simple computer with both CPUs. They are both “my child’s”, love them equally. Now if you put an 68k in the ring I dump the two 8bitter quickly ;-)
One computer with both CPU's? I'm dying to see someone make a retro style machine with both classic CPUs in it! OR do you mean you built two, one with a Z80 and one with a 6502?
@@andrewdunbar828 two different boards, one to drive a LED/key IO system, and one to drive Relais. Forgot which for what and even more why two different CPU. I was young ;-)
@@PebblesChan Even as an Aussie growing up when Microbee was at its height I almost never saw one and have still never touched one. I was reading up on them a lot a year ago in lockdown though. There were very expensive compared to Spectrums and even C64s. I think there were in the Apple II/BBC price range, which is probably why mainly schools had them.
@@andrewdunbar828 I was part of the original development team for the microbee. It was designed to meet the requirements for NSW schools and be a precursor to notebook computers by having non-volatile RAM enabling students to take microbees home to continue work and bring it back to school. If you were in the midst of writing a BASIC program, when you got home one can continue writing your program. Likewise when using its word processor one can just continue editing. It also it had a full sized keyboard so students could learn to touch type. If you want to know more about the microbee then take a squiz at www.microbeetechnology.com.au/forum. As for price point they were about $399 retail (cheaper for schools) far cheaper than the $2000 for an Apple ][.
A quick correction: The jp (hl) command (and jp (ix) jp (iy) ) is actually equivalent to ld pc,hl, not ld pc,(hl) despite the way the mnemomic is written (I have always though jp hl would be more logical). In other words it jumps to the address stored in the hl register pair, not to the address contained at the memory location given by hl. In many cases, push hl // ret would have the same result as jp (hl) though it would also overwrite some stack memory. "If the Program Counter contains 1000h and the HL register pair contains 4800h, then upon the execution of a JP (HL) instruction, the Program Counter contains 4800h." (p275, Z80 CPU User Guide - Zilog).
Z80.... it's complicated ;). And the discussion usually never ends. Seen folks go "Z80 sucks at " only to be proven wrong due to some very creative register use.
Machine level programmed on both, and while i liked the simplicity of the 6502, the Z-80 just made more sense to me. More registers, the ability to do 16 bit math and all the addressing modes made it a no brainer for me. Sure, the 6502 could be faster, and if optimized was, the Z-80 was just simpler to write code for.
I'm Z80 all the way. I've been using them since the 80's, (ZX81/ZX Spectrum/TRS-80 Model 1), mostly with BASIC but with bits of Z80 M/C thrown in to enhance sound/graphics. I don't use assemblers though, I store M/C in data lines, I find it easier to de-bug them that way. (for some reason) BTW, Subbed. :)
I'm lucky enough to have spent many years programming both types of these CPUs (and others). I agree with you. At the end of the day, the Z80 is just 'more computer' than the 6502. But are frustrating though, with their 8-bit word length. I prefer something like the 68K range of CPUs, or, my all-time favourite, the TMS99xx range from Texas Instruments. Beautiful, orthogonal instruction sets, genuine 16-bits word lenghth, with hardware multiply and divide.
I first used the Z-80 in 1978 and I must admit, your exploration of that chip was interesting in that it was filtered through the lens of the 65C02. Sort of like describing English using the grammar rules of French ;-) Not bad or wrong, just... different. Keep up the good work!
I have an established audience from my 6502 content, and I want to help bring them into the Z80 stuff. That was a big reason for this video, to bring the old and new audiences together
The other big difference between the two is that Z80 doesn't use memory-mapped ports. It has a different address space for I/O via the IN and OUT instructions.
Doesn't _need_ memory-mapped I/O would be more accurate. There's nothing stopping you using it if you want faster I/O access at the cost of memory address space.
@@lister_of_smeg6545 Some things were faster on I/O, some were faster with memory. Depended a bit on what you wanted to do. E.g. for I/O there are the INIR and OTIR instructions that can send a number of bytes to a single port quite quickly. But when you need to do some bit-testing between the actions (as usual), they are not useful and accessing memory mapped devices via HL is often quicker.
Apparently lots of the '80s videogame cabinets did use memory-mapped ports. There was nothing stopping you from mapping hardware to either address space.
Interestingly the bit set res instructions where not introduced in the x86 until the introduction of the 80386. The DJNZ instruction is called LOOP in Intel x86. How about the LDIR, CPIR etc. Instructions and that out instructions ? Nothing like that in de 65C02?
I first programmed Apple ][ Basic on a neighbour's computer in 1979, then TRS-80 Basic on a schoolfriend's Model 1. I first heard of assembly or machine code when we were programming the TRS-80 and probably saw Rodnay Zack's book at that time. I finally got my own computer, a 48K ZX Spectrum in 1982 and moved from Basic to machine code after maybe a year, teaching myself from magazines and the Speccy manual which listed all the Z80 opcodes. I never even saw an assembler and didn't get the point of hex. I figured out the decimal for all the opcodes and addressing modes, etc. Poked my code into memory using Basic DATA statements. I did write my own disassemblers for Z80 though. Code was saved onto cassette as floppy drives were only for the rich in Australia in those days. Fortunately the Speccy seemed to load and save to cassette faster than the C64 could with a floppy. School finally offered a computer class which did include some 6502 on the Apple ][, but I don't remember how hard I found using the 6502 after the Z80. Our project was probably too trivial. A few years later when I got into Amigas I found it natural to move from Z80 to 68000. Interestingly many of my friends in those days had moved from the C64 to the Amiga and also found it natural to move from 6502 to 68000. But to me looking at 6502 and 68000 they look nothing alike. I never got into x86 assembly after we moved to 486s. It seemed ugly and confusing. I think my 6502 friends found that transition easier. The 6502 page-zero stuff probably made the x86 segment stuff seem easier for them than for me.
@@AndersJackson I was quite shocked when I first saw C64s loading games off floppy with fastloaders. They were still slower than Speccies loading games off tape with fastloaders - and a lot more expensive (-:
Conditional is not called an addressing mode because it doesn't address anything (i.e. a destination for data such as RAM or a register). It's definitely an operand though.
LDIR took 21 cycles per byte if i recall correctly, that's why i built an expansion for my speccy with a Z80A-DMA, only 4 cycles per byte ;-) needed a bigger power supply though ...
@@jfkastner Oh wow, non hardware related DMA usage. Something new to me. Never used DMA like that before. I have used DMA for data I/O in PCs and ADC/DAC related on microcontrollers. No idea if the 8237 in the PC could even transfer RAM-to-RAM.
@@ChipGuy don't know the 8237 ... the Z80 DMA did a busreq so the CPU was 'playing dead', and it could reach anything the CPU could - source&destination in I/O or RAM. you could even modify the timing per DMA register settings
There is an old isometric game called "Amaurote" - quite interesting, difficult to play, fun to watch... my point is on Z80 machines (ZX Spectrum) it runs well BUT 6502 machines cannot handle this game: Atari 800 version is slower and completely monochrome, C64 version is colourful and fust but is in plain 2D. Seriously Z80 has an edge when it comes to anything other than primitive 2D graphics.
I'm team Z80 because I just can't be dealing with all those 6502 addressing modes. That said I gave up writing cpu emulators because I couldn't be asked to implement 800 odd Z80 opcodes! That said, before I gave up completely, I did discover the Zilog Z8000. Now that's a nice CPU design! Shame it never made an impact between the MC68K and i8086.
IIRC the Z-8000 was designed with discrete logic, rather than using microcode like the x86 family. So it was buggy, and it took too long to work out all the bugs (I had seen the Z-8000 manual, and loved the instruction set, but was disappointed with its failure to thrive).
In 1977 I chose the TRS-80 instead of the Apple ][ because the 6502 instruction set was "odd". The Z80 instruction set is much more logical in terms of completeness of instructions and memory layout.
I'm firmly in the 656xxx family.I have worked in both instruction sets. My issue with the x80xxx instructions is that they waste states. Oh we can run at a higher clock rate so we can do 4 T cycles per fetch and that makes us faster..... BS. The 65xxx and 68xxx systems used dynamic instruction clocking.
It was always fun on the Commodore 128 which had a MOS Tech. 8502 (evolution of the 6510 from the C64 which was also an evolution of the 6502) and a Z80.
Keep in mind that the same person that designed the z80 did the 8080 … and Intel copyrighted the mnemonics… so ZILOG had to create new ones… the LD replace the MOV and simplified the thought time with a minimized instruction set … IMHO memory mapped IO sucks because it takes program storage and use address space away…
I love the MOS6502 and I respect the Zilog Z80. What fun it would be if these two giants could work together as one, so that if one of the two processors is a bit tired and wants to rest for a few clock cycles, that the other will take over, both using the same memory, the same IO, the same whatever! Just like on my proximately forty years old Apple II clone where they are more microprocessors on the same motherboard, like brother and sister. It is a pity I have no clou how it works. Maybe (probably) there is a disk with software to let the 6502 work with all IO and the Z80 is doing the CP/M programmes. I know that one of the two microprocessors is tri-state and the other must act like he is, I guess.
If you look here, you have a much larger test set, and it show that the 6502 suffer for the low number of registers. It's small size reduced the cost though. en.wikipedia.org/wiki/Motorola_6809#Market_acceptance
@@AndersJackson ive always thought that with the zero page the 6502 had 255 registers, or less depending on how you use them; all mute at this point; back in the day the z80 was a bit of mystery
Imagine a Z80 CPU with 32-bit wide registers, hardware multiplication and division, relative jumps and calls with 8-, 16-, or 24-bit displacements, stack-relative addressing, and four complete register banks, each consisting of AF, BC, DE, HL, IX, IY _AND_ AF', BC', DE', HL', IX', IY' register pairs. Further imagine that it also has a full 32-bit address bus as well as a 16-but data bus and can run at 18MHz. Oh and there's a new Interrupt mode, IM3, as well, which takes a 16-bit offset from the data bus to add to the base address defined by the I register (which is now 24 bits wide). Of course the Program Counter and the Stack Pointer are also 32 bits wide.
@@emesde Yup... Or perhaps the Z382 which has a number of additional functions added to the chip, which can be seen here: archive.org/details/zilog-z-80382-product-specification/page/5/mode/1up
As a Z80 guy in about '83 or '84 hearing about the Amiga and the 68000 made all my dreams of that type come true. I remember how excited I was when a friend who worked for Melbourne House told me over the phone how many registers there were going to be!
Sixty-Five C oh Two Is my preferred processor by far. I do have the best of both worlds I run cpm on my Apple //e using a a z80 card from Microsoft. I’m lucky enough to own a ZX Spectrum to get to do some bare metal programming on both chips. Would be keen for you to cover a proper RISC chip like HPs PA-RISC architecture
I used an HP-9000 in University for my VLSI design class. That was a seriously impressive computer in the 1990s. Never got a chance to look at the assembly code, though.
My take is that if you are proficient in assembly programming, whatever CPU/MCU (new to you) you have to program for, you will have to make yourself very familiar with the particular architecture and therefore it really does not make much difference. BUT, my opinion is that I very much prefer the Z80 assembly mnemonics and structure because it is much more logical. The 6502 mnemonics are trying to squeeze just about everything in three letters and are therefore very hard to memorize garbled things, and loading and storing are different mnemonics, whereas the Z80 mnemonics are longer but consistent, e.g. moving a value is always a "load" (LD) and the conditionals are always the same (e.g. Z for "if zero" or NC for "if no carry"). This is also a reason why I was very sad to see the Siemens/Infineon C167 MCU architecture disappear because it had just about the best naming conventions for both assembly mnemonics and register naming!
Decrement Jump if not zero -- this is a single-instruction set that is universal for boolean algebra (normal computing). Maybe they added it to the Z80 as a joke?
I’m going to have to say “Apples and Oranges”. Some of Z80 features that you consider to be negatives, coming from the 6502 world, are actually more powerful than anything that the 6502 has to offer. Page Zero has a completely different purpose in both processors, so you really can’t compare them. I had to go back to my original Z80 documents from Zilog, as your Z80 syntax is a little off, and then I realized that you’re mixing some of the 6502 syntax into some of the Z80 syntax. BTW, there are quite a few hidden Z80 commands, and some of them are rather useful. ;)
Wow! 1000 views in the first four hours, which is a new record for my little channel. I wish UA-cam had told me a while ago that they wanted me to produce Z80 content. 🤣 Thanks everybody for your support! I'm working on the "Hello, World!" ZX Spectrum tutorial right now, and I hope you like it when it comes out on Monday. Cheers!
I'm currently working on one - sol.gfxile.net/z80/ =)
Your Channel has nearly 4k of Subscribers. Incredible.
@@solhsa nice site. (About the second set of registers A'-L'. they are useful as scrap registers in interrupt routines, Just switch and you don't need to push them and later pop them of the stack)
@@solhsa Bookmarked!
This is a definite subscribe for me!
For those who really want to see how the Z80 and 6502 differ and how best to use very different architectures, there is nothing better than reading actual code that solves the same problem on both CPUs. A good starting place are the two books by Leventhal and Winthrop: _6502 assembly language subroutines_ (1982) and _Z80 assembly language subroutines_ (1983).
The first computer I owned, a TRS-80 model 1, had a Z80 processor. I did a lot of assembly language programming on it as it was the only way to get acceptable performance.
However, at work and when working with friends, I often worked on 6502 code (not 65C02). So I know both of them.
It was often a lot "easier" to do programming jobs that required working on strings in memory on the Z80, as it had all those 16-bit registers that could hold memory addresses, and that you could easily increment or decrement to walk through strings. That was a hassle on the 6502. But of course with a macro assembler, it was quite easy to hide that.
One could either say the 6502 had a lot less registers, or that it had way more. Because the zero page could be viewed as registers.
However, this also meant it was more suitable for small dedicated systems than for "a real computer", as this zero page would often be used a lot by the operating system of the computer and was not so readily available to applications, especially not when you would want to use a higher level language and the number of variables would often be a lot more and they would not fit in zero page.
The same issue occurred with the stack, which was only one page in length. Enough for assembly language programs that wanted to do some nested subroutine calls and save some registers along the way, and to handle interrupts, but it was way too small for stack frames as used in a higher level language to hold local variables.
Note that most of the code running on the Z80 usually was in fact 8080 code, so it would not use those extra features on the Z80 like the IX and IY registers, the alternate registers that could be swapped, etc. A lot of code was never "optimized" for the Z80, e.g. the BASIC ROM on the TRS-80 contained almost no Z80 instructions at all except the use of IX in some low level routines for I/O that were added especially for that system, and the relative branches whenever possible (done as an optimization to save ROM space).
This was true for a lot of other systems as well, as CP/M was originally written for the 8080 as well and even though the majority of CP/M systems was Z80 based there still was the desire to have some compatibility with the 8080 so the extra instructions were often not used.
One thing that I learned when working on these two processors is that althoustruction set is more powerful, the processor still is slower. For a fair comparison you should compare a Z80 running at twice the frequency of a 6502, as this would result in about the same memory speed. But still, those nice Z80 instructions often burn a ridiculous number of clock cycles! The 2-3 6502 instructions that would do the same thing as a Z80 instruction often would execute in less time. In many cases, a small loop that has to execute as fast as possible can be done quicker on a 6502 than on a Z80.
Even the amazing LDIR instruction consumes 21 cycles per copied byte, which at the equivalent 6502 clockrate would be 10-11 cycles, which is enough to write a special-case variant of the same thing in 6502 instructions. (of course it is more difficult to write the general case with 3 16-bit values for src,dst and count, but that is often not required anyway)
On the British Z80-based microcomputers and on the videogame arcade cabinets the instruction set was fully utilized. I doubt as many CP/M machines were ever built as ZX Spectrums alone were built. On the Speccy the LDIR was ignored fairly early and the most advanced games actually used the stack pointer when they needed the fastest possible loop, such as clearing the screen or drawing the screen from a RAM buffer. In the microcomputer games world, the fastest smoothest games on the C64 were due to using the other hardware well and were games with scrolling and sprites. On the speccy there was no other hardware for scrolling or sprites but we even got full framrate 3D wireframe games using only the CPU and the C64 couldn't manage that with the 6502.
It seems that there was almost no crossover between the Z80's serious CP/M world and its gaming world.
@@andrewdunbar828 it should be noted that the 6502 in the commodore was only runs at 1 MHz, whereas the spectrum's z80 is at 3.5; hardly an apples to apples comparison of the CPU architectures
@@elideaver Even worse is the fact that the input clock frequency has not much to do on the final performance. Both 80xx and 6xxx architectures do not use the clock the same way to sequence the instructions. It is more on the data bus side that a better comparison can be done.
@@andrewdunbar828 LDIR - это надо использовать с умом
I’ve programmed both, plus many other microprocessors. The Z80 definitely has a more rich instruction set, thought I do like programming some of the microcontrollers that have a pretty close architecture to the 65c02. The 68hc08 is quite nice, it fills in many of the gaps in the 65c02 instruction set. It is a bit of a different mindset when coding for one or the other. I find that the Z80 is more register-centric where 65c02 as well as all of the 680x families are more stack and/or memory oriented.
Wow , I was born in 67 and The Z80 was about the best I had to Work with as we only Had Kit's at first , Gee I remember those days :) QC
I'm definitely on the team Z80. I love that it has separate I/O address space as well as a family of dedicated peripherials. I have built an entire computer with it from scratch, it wasn't too difficult either. Anyways, great episode! Keep up the good work.
Welcome to the club of homemade Z80 computers. I wired mine. Still have the board, but I'm missing one IC.
@@ehsnils I went for RC2014-style design, but with some modifications. I wired everything by hand on prototype boards. Apart from the CPU, I currently have PIO card with LEDs, buttons and switches, CTC card, DART card, AY-3-8910 sound card, 20x2 VFD card 32k ROM + 32k RAM card and 16k + 512k RAM expansion card (with 512k chip missing at the moment). I also want to build an IDE card and VGA card and probably some more like RTC or FPU. It runs assembly programs, either from ROM or loaded from serial and 32k BASIC. I'm planning to get 56k BASIC runnung when my missing memory chip arrives, and perhaps CP/M later on.
I could always see the clever optimisation of the 6502 but I was team z80 - all those extra registers and the additional 16 bit commands made it easy for my style of coding. I was a little frustrated when at college we had to do 8088, in an odd way it felt like a backwards step from z80.
Yeah I never understood why "modern pcs" in the 80s where not z80 based over the x86 style
@@lezbriddon Zilog's successors to the Z80 all failed. When non-tech people starting buying computers for boring business reasons, IBM a big old company they trusted. In the meantime there was the Motorola 680x0 in Apples, Unix boxes, Atari STs and Amigas until the 486 and Pentiums showed that Intel was going to drive things forward for a while.
Zilog cocked up their Z8000 (aka Z8K) 16 bit micro. However they did release a fantastic eZ80 microcontroller decades later that can run at 50MHz and lots of RAM. It's used with some TI-84 calculators.
IBM decided to use the 8088 because it could easily port 8080 CP/m programs as .COM files and be able to run new 16-bit 8088 programs as .EXE files. If you look at the design of the IBM PC - it's just an adaption of a basic S100 bus system with a clever keyboard interface.
I once read that the only reason why the initial IBM PC used the 8088 was because the 68008 wasn't going to be available for another 6 months. Imagine how much better the (CPU) world would have been if it would have been the other way around.
In 1983, a company called Visual Technology came out with a machine, the V1050, that used a Z80 for the main CPU and a 6502 for the graphics processor.
Thumbs up within 2 seconds from me. I grew up with z80 and it’s a miracle to see a video like this. Congratulations on posting this, it might be watched in 1000 years time!
I loved the Z80. Was very popular in GDR since we produced a clone chipset to the Z80 so we could use all peripheral chips or even replace broken CPUs (as in my Spectrum) with in-country production chips.
So many of us in the UK were brought up with zx80,81 and Spectrum so love watching stuff like this
For me the big plus with the Z80 was the vectored peripheral interrupt mode 2. It meant that with the right peripherals you could do very fast and efficient interrupt handlers compared to other CPUs of the time. The only pity was that in response to an interrupt all registers were pushed adding some 14 or so write instructions when your interrupt routine might have only needed 3 or so of the registers.
I've found that people always prefer the one that they learned first. I think the Z80 was also chosen in many systems because it was easier to support at the board/electronic/chip level, memory, clock signal, etc... It been a long time, so I could be wrong.
Nope. See my statement
That is true for a lot of people but not all. I started with Z80, then 68000, then 6805, then 68HC11, then AVR, then MSP430, then ARM.
My favourite for assembler programming is MSP430, and my favourite for small systems using C (hides some assembler ugliness) is AVR. For bigger embedded systems I prefer ARM and for still bigger systems then 68000 (both in C). Debugging on MSP430 is also marvellous because you can monitor variables live while the code is running, something the others won't let you do.
I have a very interesting experience: I planned to build a 6502 computer for years but switched to Z80 halfway! The reason is that the Z80 has a secret 'protected mode' which can be realized by connecting IORQ with external circuitary, effectively disabling any IO operation. IO can be enabled by a flip-flop connected with a simple 74LS30 gate which 'filter out' a RST instruction, creating a controllable 'interrupt entrance gate' into a system-level subroutine.
I like both, but my preference is towards the 6502, because it does more with less (more per clock cycle, with fewer transistors), and the instruction set is so much more orthogonal. Zero page mode was a neat hack, and not without precedence: it wasn't uncommon at one point to use the bottom block of memory as a register bank, and the zero page basically gave you a bank of slow registers to complement the three main fast registers.
One fun thing about the Z80's DJNZ is that it's Turing complete by itself!
Writing a quick sort using only DJNZs would be a neat trick! But there is the small issue of not being able to write to memory...
Dude, because we all wish someone like you could teach us all the architectures. This video is a good transition to your z80 series, as I'm fairly proficient with 6502 but I need to catch up with a childhood growing up without a z80 based micro.
I've been on team Z-80 since the early 80s! When my friends all bought Apple ][, I bought an Exidy Sorcerer. Never regretted that decision. Just finished a retro Z-80 project on a breadboard, so much fun and so easy to use the entire family of Zilog chips. Here's to the venerable Z-80 and all that it brought to the world.
A look at instruction timing would be interesting. That's where you pay for the Z80's larger instruction set, sometimes in surprising ways. It always amused me that when you count up the t-states, a loop on the Z80 can be written to run faster using simpler instructions rather than the built-in LDIR, etc., convenience opcodes. Try it!
Thanks for a fun revisit of the old 8-bit CPU rivalry.
Yeah, I was taken aback when I saw that 16-bit LDs took 20 cycles!
In fact it is surprising that there were no newer devices from Zilog or competitors that would implement the same instruction set in way less clock cycles.
After all, that happened in the 8086 line quite frequently.
Maybe because in the Z80 days there was more software that actually relied on the instruction timing and would not run OK on a device that executed the instructions faster at the same clock frequency?
@@Rob2 that would be my guess. And really, the Z80 is "fast enough", especially the Z80A and later revisions, for any of its target applications. You don't need a ton of computing power for embedded systems, usually, and predictability is much more valuable
@@Rob2 There is a chip called the R800, which is a more modern 'pipelined' CPU, which supports the Z80 instruction set. It also has a full 16 bit ALU, which makes instructions like ADD HL, BC take only 1 or 2 cycles instead of 11. On average the R800 executes instructions 4 times faster than the Z80. At around 8MHz, that means its speed is equivalent to a Z80 running at 32MHz.
@@Rob2 in fact there are. The Zilog eZ80 has been around for two decades. It is binary compatible, pipelined, and can be clocked up to 50 MHz.
I had the ZX81 and Sharp MZ80K, both had the Z80 CPU, a friend had the BBC Micro which had the 6502. Still preferred programming the Z80 though.
From what I understand about these two CPUs, the Z80 may be slower but it is FAR more flexible.
The Z80 was better suited to business type applications due to the 16 bit stack pointer. The 65C02 could only handle 256 bytes of stack space, or 128 levels of nesting with no parameters. With the Z80 you could push parameters onto the stack, call the subroutine and not worry about space (at least any more than you worried on an 8 bit machine).
The 65C02 was the faster of the two, running at least twice as fast clock for clock, and better suited to control (zero page could be treated as a big block of registers).
You pays your money and you takes your choice.
The 6809 was the best 8-bit CPU I ever worked on. I has great addressing mode.
The 6809 are a great beginners CPU. Addressing mode are more like the 68000 CPU, but still 8-bit computer.
Apparently so but I usually hear they weren't widely adopted because they were a lot more expensive than the Z80 and 6502.
@@andrewdunbar828 68000 is a 32 bit CPU, so yes, it was more expensive.
Not so much fot 6809, witch is a 8-bit CPU, just like Z80 and 6502 (or 6800).
I used the 6809 very late, in the early 2000s making a SUMO BOT using a 6809 SBC. I adored the assembler. I had been using 68000 since the early 90s and that for me, is still the nicest CISC cpu; especially with the great AMIGA chipset.
It is so flexible in it's addressing. And it had a mulu.w instruction! Something that made me very happy. Something I envied the dodgy 8086 having and something I missed on the 6502 :D
So there was a machine that again, outperformed the massively expensive XT we had for mere pennies on the dime, in comparison :D
I used to work heavily with 6502 assembler. I always felt that the way MOS Tech designed the instruction set was by creating a big chart with all the base instructions along the top and every instruction mode known to mankind along the side, then fired a shotgun at it and implement instructions wherever the shot landed.
It does seem that way, a bit. LOL
When Steve Furber and Roger (now Sophie) Wilson saw the way that the 6502 derivatives were created they thought OMG!! What a mess!! and thus created the ARM processor.
I did a lot with assembly, FORTH, and even some C back in the Z80 days. I played with a few different CPUs back in those days. I'd say the 68000 was my favorite but it was overkill for little embedded systems back in the day - and much more expense to build up into a system. For building up a small system from scratch in a hurry nothing could beat the Z80 for me. I could start with a box of parts and in a day have a little hand wired machine running, and for much less than $50. I never warmed to the 6502 but that's just personal preference.
Team 65C02 here. I’d love to see a 65C02 (or even 65C816) humming along at 4 GHz!
That would be NUTS!
Would be interesting to see how it stacks up against a modern processor. Probably very poorly.
@@benholroyd5221 to say the VERY least. But x86 assembly is pretty awful for programming
@@slithymatt it don't mind it actually.
it would not be possible to have a similar speed at hw level ( a true silicon chip) for tech reasons. However SW emulation or FPGA could reach very high speed . for example a FPGA could run a 6502 @ 50Mhz
Great and very interesting vlog, thanks! Re: feat of building a CPU back then is not only the size (and hence, defect ratio), but also the lack of tools. Masks were done manually by cutting and assembling them. They were verified visually, just imagine, no post-layout simulator. I recommend reading Commodore: A Company on the Edge by Brian Bagnall, where that part of history on the 6502 is very well described (the rest though is average and goes down from mid-book to the end, but the first part is more than worth it).
Z80. My first computer was an H/Z89a with 2 Z80s. My first code was "Hello World" in Assembly (with flashing text). Then I got Fortran-IV and Dartmouth BASIC interpreter. All a great experience.
Team Z80 all the way. I had an MSX computer in the 80s.
The 6502 was more efficient per clock.
@@honkhonkler7732 I had a lot of fun coding the 6502 which was actually the 6510 in the C64 computer (and not quite the 65C02 but close). The Z80 looked fascinating and more advanced but I never got the opportunity to use it. The 6502 was quite nice.
Sega Master System, Sega Genesis, Neo Geo AES/MVS...Z80 for the win! Just a legendary processor with an unbelievable history behind it. Not to mention how many arcade cabs were run on Z80's.
Oh yeah, tell me about! I'd like to see your "per clock efficiency" when chugging a memory block larger than 256 bytes 😁🤣
Z-80: Plods along, lifting one foot at a time.
6502: Canters along.
The Z-80 has the DJNZ instruction, "Decrease and Jump if Not Zero" which is just one byte long and does the equivalent of DEC B followed by JR NZ -- obviously this is handy for creating loops.
The 6502 -- which inspired the original ARM instruction set, where _every_ instruction was conditional -- is a bit more RISC-like in some ways, including the way it uses both edges of the clock: data is written or read from memory on the "tick" and moved internally on the "tock". The Z-80 only moves data on the "tick".
Some microprocessors of the era used RAM to hold the processor registers; and you can consider the 6502's short addressing modes as being 16-bit opcodes that use the whole of zero page as either 256 8-bit registers or 128 16-bit registers.
I always was partial to the 68000's DBRA instruction.. and BPZ (branch for a pizza).
I always get a little thrill calling that one, it's like a high level call right there in the microcode.
As a z80 coder I saw the zero page of the 6502 more so as a way to implement instructions that otherwise don't exist. Whether that is the norm I wouldn't know though.
I would say it's more like having 256 extra registers.
Very good, fair conclusion.
Did hand coding for both Z80 CPU and 6502 and 6802. The 6802 is very similar to the 6502; simple! This is VERY important if you are hand coding.
Fun times back in the early 80s for me.
MC6809E is the Queen of 8 bit.
Perfect register set.
If the 6809 is the queen of 8 bit, then the Hitachi 6309 is the empress. Upward compatible, with extra registers and hardware divide.
@@zzy09azy oh yes!
When I found out what Hitachi did, I thought: "Cool..., Very Fucking Cool..."
When I was a child I was having a Sinclair ZX Spectrum, and I had done games and animation and sound effects with Z80.
I had both. My Apple II had a 6502 and the CP/M card with a Z80.
Me too!! but with my C128 :) Love to think that one of my first computers was dual processor.
Same. An friend and I tried to have them run simultaneously. It did work at first but there was some bug in that Microsoft card and it never ran stable.
@@MarianoLu It's a shame the Z80 was so crippled in the C128 )-:
For me, the Z80 always had the edge if you needed more memory space since the Z80 had proper I/O ports rather than having to use memory mapping for I/O as in the 6502. On the other hand, the 6502's PCR (Program Counter Relative) instructions were a really slick way of making a machine code program which could be loaded and run anywhere in RAM. I always preferred the Z80 and I think it still has the edge in my mind, but I also like the 6502.
My first computer was an OSI C1P (6502); Next was an S100 (Z80). Made programming the 6502 feel like a straitjacket. I now run CP/M Plus on a Z280 @20 MHz. Zilog rules. ;-)
My favorite 8-bit microcontroller to write in assembly was the Motorola HC05. Its a von Neumann processor with address modes available all applicable instructions. Others, like the 8051, PIC, and AVR, have Harvard architecture, with RISC-ish instructions.
I did a lot with the HC11 back in the 90s. Great for all sorts of projects!
There's more ISA innovation in either of these processors than you'd get in 10 years of CPUs now. Chuck Peddle and Federico Faggin were both absolute geniuses.
Back in the day, I learned Z80 first doing assembly by pencil and paper and using the fantastic "front panel" debugger on the Research Machines 380Z. Later on I moved to 6502 using the BBC Microcomputer's BASIC assembler and my initial thoughts were "this is rubbish... where are the registers? Why is there no DJNZ?" But, after a while, you realise that neither is "better" or "worse" they just have different approaches and each has it's advantages. My next port of call was CP/M and the 8080... and I never could get over how "ugly" the Intel assembly language was and that carried through to the 8086, 80286 and 80386. These days it's all AVR, ARM and MIPS... my enduring legacy is Intel = ugly. I did a bit of 6800 and wish I'd had a look at 68000 but I just never had the chance.
65C02 needs to use more expensive static RAM because it doesn't have built in refresh. Well, no. The Apple ][ used DRAM but the video display memory layout was designed so that the video output also refreshed the DRAM. In 1983 some friends and I made a wire-wrapped M6809 computer. We used 64 kbit DRAM, and we arranged for an interrupt every few ms which executed 256 bytes of NOPs (I think they may have been multi-byte NOPs). The percentage overhead was acceptably low. Interestingly the Z80 hardware refresh was designed only for up to 16 kbit DRAMS (7 bit counter for an 128x128 array) and could not be used as-is to refresh 64 kbit chips.
I didn't mean to imply that the 6502 couldn't use DRAM, just that it needs to be fast and requires external logic. SRAM is just the path of least resistance, if a bit more expensive per kB, but that cost can be offset by not requiring logic to manage the DRAM.
@@slithymatt fair enough. Nowadays we can use cheap DRAM with a convenient parallel-SRAM interface e.g. www.digikey.co.nz/product-detail/en/issi-integrated-silicon-solution-inc/IS66WV51216EBLL-55TLI/706-1427-5-ND/5320130 Also, parallel flash is much cheaper and faster than EEPROM.
It would be interesting to hear your take on the Motorola 6809 and/or Hitachi 6309 vs. the older generation 8 bits.
I do want to do a 6809 series eventually, as my first computer was a CoCo2 and I also had a Vectrex at the same time. What I really need to find is a good emulator for at least one of them, preferably the CoCo2
@@slithymatt - XRoar or MAME are probably the best for Coco 1/2. Unless you want to use a web based one (like Mocha: www.haplessgenius.com/mocha/). MAME and VCC are good for Coco 3.
@@slithymatt - Also, feel free to catch an episode of CocoTalk (live every Saturday at 2 PM Eastern, on UA-cam, Twitch and Facebook), and if you have any questions on the emulators, the Coco in general, current assemblers, etc., feel free to ask us in the chat. (ua-cam.com/channels/spFbd1b1vwuhsj0ZVehd2w.html for the UA-cam channel).
6809 with OS/9, version 2 with multi user. In uni. we had two systems, where we used to code C in. To bad the memory protecting was non existing, so when we wanted to try a program, we had to warn the other students so they could save their files. :-)
Except that, it was a great OS, Unix like with dynamically loadable modules. Really liked it.
@@AndersJackson I had OS/9 for my CoCo2, but I was 13 and had no idea what to do with it. LOL!
Great detailed compare and contrast video. I wonder how instruction count and byte counts would compare for significant equivalent code samples. 6502 instructions do less but take fewer bytes to encode.
Not many fewer. The three byte opcodes only take one byte operands, so there is a hard limit if 4 bytes per instruction instead of three for 6502. And there are way more Z80 instructions that are single byte implied opcodes
I used Zero page indirect addressing for generating background graphics using interrupts, on the old Commodore Range like the C64, C16 Plus 4 and Vic 20 which is the machine I learnt ASM on. Also used to a lesser extent due to hardware differences on the early Ataris like the 400 and the other 8 bit machines up to the 128k version. The main reason for using it was 'if you can believe it' the speed.
Great video! However, I wouldn't call the "alternate registers" A' etc real registers. You can't do anything with them other than swap them for A etc. So they are really more like a fast storage area for register values. In practice they were rarely used I think
In the Speccy scene even hobby programmers like myself used the alternative registers extensively. We avoided storing values in memory at all costs.
@@andrewdunbar828 Thanks for your reply, I stand corrected! But was I right in saying A' etc are not proper registers in that you can't do anything with them other than swap for A etc. Eg you can't add numbers onto A'.
@@JohnBlackburn1975 You could "do" anything with them, but the only opcodes the CPU had was to swap them. So you basically mixed swap opcodes and other opcodes, kinda like using a stack or banked RAM or storing variables in memory, but faster and they swapped in fixed sets.
I think you forgot the 65C02 zero page indirect mode which was added to the 65C02, as in LDA ($34).
It's like Indexed Indirect. But better because you can pass a raw pointer to a function without having to reset one of the index registers.
I mentioned it in passing, but didn't make a slide for it as it didn't add much to the conversation after already covering direct Zero Page and Absolute Indirect modes.
Even though I am die-hard 6502 fan (it was my first love), I have to admit that the Z80 is a better CPU. Well, maybe not better, but easier to program for. The bigger register file is so nice, and the shadow registers makes interrupt handling so much easier.
In 6502, the 0 registerback could be thought of as registers (256 of them).
But yes, I was a 8085/Z80 coder, not so much 6502. I also loved the 6809, which still think is the best 8-bit CPU ever built.
I think the 6502 is easier, as you can do direct in memory manipulation, saving on load and store instructions on the Z80 (which ironically is a very RISC thing). But I always missed a single 16 bit register on the 6502. If they'd implemented a W register with 16 bit length that would've really made it a killer CPU.
16 bit is where the Z80 shines over the 6502 and when you need to do a lot of >8 bit work, it for sure is the better choice.
Just paused the ad to say f 6502 already I always thought if I learned an old cpu assembly language and architecture it would be 6502 but it turned out to be the z80.
I’m only half kidding, like what you want ❤️💙💜💗🖤💛💚❣️
The two chips I most enjoyed working with (at the time) were the Z80 and 6309. The Z80 had several useful features including an alternate register set (which I used very heavily both for OS implementation and ultra-fast algorithmic code), dual memory mode and banked memory support.
However, at least where we were in South Africa, the 6309 from Hitachi was nearly as good and had the advantage of extreme low power operation. Paired with static CMOS memory we built a programmable data acquisition machine for use in mining. The year was 1982. With external register banking, we combined 256kbytes of RAM, a 4 line graphic capable LCD, membrane keyboard, photocoupler serial communications and a MW radio charger for the Nicad batteries.
We got a lot of use out of the cmos versions of motorola's 8/16 bit CPUs (mostly from Hitachi) but the Z80 (and CMOS versions of the Z80) ultimately eclipsed the motorola chips. For algorithmic code, and especially DES encryption, it was possible to make extensive use of the alternate register set and single byte instructions to achieve performance that would embarrass an 8088 running at 8MHz with the equivalent encryption executed in C! The last time I used the Z80 was in EFT-POS terminal designs.
After programming the 68000 series chips (especially the 68032) I found the Intel x86 chips to be a disappointment. Yes, they triumphed, and by the time we got the 486 they were decent enough chips. But their success was more a consequence of business/marketing decisions rather than technical merit. In particular I loathed Intel/IBM's paged memory system. What were they thinking?
well, this stuff is simple old school stuff for us older people, but this where the rubber hits the road. I know people prefer what they first started with, but it's best to be flexible when it comes to a cpu or microcontroller for that matter. Theres no need to know every instruction, but it's important to know the ones you need for your specific application. I haven't built a home brew computer with a Z80 in a long time..who knows maybe I'll feel nostalgic and put together one. I have one or two Z80s in my parts box and plenty of TTL chips. The Z80 greatly outclasses the 6502. The only reason the 6502 was so popular was because it was cheap compared to the Z80 and it was fast. It generally takes more code to do the same job, but it's not too shabby. I think it would be better to compare it to the mc6800 and the 6809. One thing to do is not get stuck on how many different ways you can address ram with the Z80 or do the same thing different ways. It's just a preference thing. One thing people should understand is learning the instructions is not learning to program. Good video though. Building a project of some type would probably bring this all together for some people. I'm amazed at all the interest in this stuff. Today things are so much easier. In the 80's this was all we had and everything cost so much more than today.
I did a bunch of 6502 coding (all in hex) on the C64. I coded a Pacman clone but never figured out how to do sound and did a bunch of other stuff just for fun. The first CPU I had a play with was the Signetics 2650 8 bit CPU.
Hesitating... mmmmh... Will not light the pyre eventually. Good job 😊
Nice comparison. I think when compairing Z80 and 65C02 maybe the comparision should have been between eZ80 (quote "runs at 50 MHz, but has 3-stage pipeline, so in theory it could reach 3× the speed of Z80 at the same frequency"). :-)
One flaw on Z80 is that some instructions takes up to 23 clock cykles. I guess thats where the simplicity beauty of 6502 shines.
Another thing is to look more into the design goals when the chip was made. In case of the Z80 you had the NMI -non-maskable interrupt making it easy for external hardware to call for a special routine and leave whatever the CPU was doing. Another design goal was full support for dynamic ram refresh built into Z80 (most other CPU:s demanded external extra cirtuits for this and dynamic ram where cheaper than static ram). And also, ready made chip family for PIO (Parallel Input-Output), SIO (Serial Input Output), CTC (Counter/Timer Channel) made construction easy and compact. Combined with a (for the time beeing) cheap developers kit made Z80 popular.
That is not a fair comparison, the ez80 has 16bit mode, it is better to compare it with a 65816
@@daschewie There is few fair comparison in the CPU world. But normal should have been comparision of Z80 and 6502 hence my comment. (By the way...read the rest of previously comment more info there).
@@daschewie
Well, if you're not happy with the eZ80, then how about Hitachi's version of the Z-80, the HD-64180?
The Hitachi chip included lots of on-chip peripherals and an MMU, but IIRC, it was still a Z-80 as far as software was concerned (albeit with many/most? requiring fewer clock cycles), to which Hitachi added an 8x8 multiply and a handful of new and improved block transfer style instructions.
The Hitachi part also had pipline (3-stage?) and could run at up to 10Mhz.
It was good enough that Zilog licensed the HD-64180 from Hitachi and marketed their own version of the chip called the Z-80180 and to which they added some more instructions and called it the Z-180.
You don't have to use those slow instructions on the Z80 though. You can instead use several simple instructions, just like on the 6502. For slow code that didn't matter we used to use the slow instructions because they were easy to program and read. For fast looping code all kinds of crazy tricks were done. In the ZX Spectrum game programming world they found out abusing stack pointer was the fastest way to clear the screen. But you wouldn't use tricky stuff like that for every loop.
@@andrewdunbar828 True! They could actually have stripped of like 35% of all Z80 instructions since the slowest and most advanced could be replaced by a row of allready existing commands. But those where the days...
Big end-i(a)n, vs little end-i(a)n
We're all little in this fight, but I started assembly programming with Motorola chips, and I'm still in team big-endian. May have to throw the 6809 into the melee...
@@slithymatt As a Forth programmer, the 6809 was always the one I wanted when I was doing assembly language primitive Forth words.
I'm in team Z80. But I'm also in team big-endian. You can blame my 680x0 years for that.
coming from an x86 background z80 seems much more familiar, which isn't necessarily a good thing
That's strange to me. I couldn't manage the move from z80 to x86 (via m68k) but my friends from 6502 backgrounds didn't find x86 confusing the way I did.
You missed to mention that the Z80 supported 128 IRQs directly in IM2. Much better than the clumsy interrupt mess of the x86.
Also, if you need pipelining and cache, the Z280 is the 16bit version that has that. It also has multiplication/division, support for SMP and multiple-coprocessors.
Cowboy walks into a saloon, sidles up to the bar and says "I'll have a frozen daiquire and an RCA CDP1802 (cosmac)".
*daiquiri
so which is the winner of the MOS 6502 vs the Zilog Z80 smackdown? the Motorola 68000
Z80 is a register centric processor, the 65C02 is a memory centric processor.
Spoiler alert!
And registers are faster than memory locations.
@@caldodge That didn't really make the Z80 faster since it used more clock cycles for its instructions. Also, back when these were widely used, RAM was clocked as fast as the CPU, so zero page access was not slow for the 65C02. On average the 65C02 micros of the early 80s were faster than the Z80 based ones. The BBC Micro was a speed demon, helped by having a 2MHz 6502 and 4MHz RAM (the latter allowed the CPU and the VDG to interleave their access).
@@deffunc this is the usual fake notice:
RAM was not so fast than cpu. the c64 had to stop the cpu when the VIC-II do some memory access. this proves the fact that ram was not so fast.
the 6502 lacks dram refresh. adding this will take some bandwith requiring the cpu to stop
the apparent faster clock on z80 is a requirement. for a z80 it is 'normal' to have a 3.5Mhz clock speed like for a 6502 was normal to have 1.5Mhz. Faster speed would have been possible with later models, but they required faster ram.
Next because the z80 split it's clock in internal sub operations it is not so aggressive in memory bandwidth requirements.
In other words you can use the same ram chips on 6502 @1Mhz or on z80 @3.5Mhz. But to have a 4Mhz 6502 you need more fast dram that allowed you to use a 20Mhz z80.
I've programmed the z80, 6502, 8086/8088.
Most people argues that z80 is a lot faster than 6502. In reality the performances largely depends on hw where the cpu is used and the kind of operations the cpu is employeed for . Yes, in the overall the z80 was faster than 6502 but not because of its clock , instead more because of its internal architecture.
Comparing pure processing power a 3.5Mhz z80 with 1Mhz 6502 cpu the former is faster, but a lot depends on kind of instructions you use. in the average the z80 was faster in the range 30-50% than a 6502.
Of course you can create your own examples tailored to show the 6502 or z80 to be the winner but in the average the range is as explained. For example a simple TXA is two times slower than a LD B,A on z80 even at same clock speed, but i can say the opposite if i use some sophisticated addressing modes available on 6502 missing on z80. the z80 ad some kind of indexed addressed but due to two byte operation code they are very slow. In this situation even a z80 @4Mhz could be slower than 6502 @ 1Mhz.
the 6502 however, because of its simple instruction set and limited registers is more easy to program and optimize. on z80 you need to plan accurately the register usage if you want to squeeze the last drop of power.
@@gasparinizuzzurro6306 For micro benchmarks such as memory copy or maybe anything else that fits into the Z80 registers, you could (with some pain) make the Z80 go quite fast. But the 6502 Zero Page was basically as fast to use as Z80 registers except you have 256 8 bit "registers" or 128 16 bit int/pointer registers, so in more complex code the Z80 has to continually spill and reload things from RAM, while the 6502 just has everything sitting there.
I agree that just programming naturally on the 6502 gets much closer to optimum performance than doing the same on the Z80.
After Spectrum Success, Clive Sinclair jumped to 16 bit world choosing Motorola's 68K for that great QL but unsuccesful computer.
The BBC micro used DRAM with a 6502 by interleaving access with the 6845 video chip. This achieved DRAM refresh and dual port RAM at the same time. Genius.
I have a small 65C02 design that runs reliably at 20MHz. I have heard of people pushing them further than that too. The real limit seems to be the support chips. If you want it to go faster, drop an optimized VDL code implementation into a ultra fast FPGA and you could get impressive speeds. Of course you'd have to implement the RAM, ROM and I/O in there too to get all that to work together.
And at that point, you might as well have the CPU and everything in the FPGA
@@slithymatt Which brings up something I've wondered about - why not do as much as possible using FPGAs instead of discrete, legacy ICs?
@@winstonsmith478 well, it's a matter of preference, really. The Commander X16 is being sold as a hobbyist computer, so through-hole DIP is the best way to do it, when a lot of folks want to solder from a kit. The plan is to phase in later versions that are discrete SMT chips and eventually an FPGA or ASIC implementation, which could have a "turbo" mode, potentially.
@@winstonsmith478 PS, Big Brother loves you. 😉
@@slithymatt Ah, I understand now. For me, it's like a Turing Test. If it does exactly what I want, act exactly like computer XYZ, I don't care what's inside. For me, for example, a Raspberry Pi-based emulator that can emulate the entire Amiga line at greater than full speed, for most models at MANY times full speed, is plenty good enough and CHEAP. If it looks like a duck, walks like a duck, and quacks like a duck...
I can understand the desire to preserve original hardware, but it's still a bit amusing to me to see a Raspberry Pi-based module made to plug into the Amiga CPU socket to emulate a faster MC680XX CPU while retaining timing compatibility with all other stock motherboard components or one dedicated just to provide HDMI output when the Raspberry Pi alone could be used to emulate the entire system at greater than full speed.
WDC's w65c02s can run nearly twice it's specified 14MHz though one needs fast memory when running operating over ~20MHz.
Eventually I build simple computer with both CPUs. They are both “my child’s”, love them equally. Now if you put an 68k in the ring I dump the two 8bitter quickly ;-)
One computer with both CPU's? I'm dying to see someone make a retro style machine with both classic CPUs in it! OR do you mean you built two, one with a Z80 and one with a 6502?
@@andrewdunbar828 two different boards, one to drive a LED/key IO system, and one to drive Relais. Forgot which for what and even more why two different CPU. I was young ;-)
The Aussie microbee Gamma and Applix1616 computers have a 68000 and Z80 co-processor.
@@PebblesChan Even as an Aussie growing up when Microbee was at its height I almost never saw one and have still never touched one. I was reading up on them a lot a year ago in lockdown though. There were very expensive compared to Spectrums and even C64s. I think there were in the Apple II/BBC price range, which is probably why mainly schools had them.
@@andrewdunbar828 I was part of the original development team for the microbee. It was designed to meet the requirements for NSW schools and be a precursor to notebook computers by having non-volatile RAM enabling students to take microbees home to continue work and bring it back to school. If you were in the midst of writing a BASIC program, when you got home one can continue writing your program. Likewise when using its word processor one can just continue editing. It also it had a full sized keyboard so students could learn to touch type. If you want to know more about the microbee then take a squiz at www.microbeetechnology.com.au/forum. As for price point they were about $399 retail (cheaper for schools) far cheaper than the $2000 for an Apple ][.
A quick correction: The jp (hl) command (and jp (ix) jp (iy) ) is actually equivalent to ld pc,hl, not ld pc,(hl) despite the way the mnemomic is written (I have always though jp hl would be more logical). In other words it jumps to the address stored in the hl register pair, not to the address contained at the memory location given by hl. In many cases, push hl // ret would have the same result as jp (hl) though it would also overwrite some stack memory.
"If the Program Counter contains 1000h and the HL register pair contains 4800h, then upon the execution of a JP (HL) instruction, the Program Counter contains 4800h." (p275, Z80 CPU User Guide - Zilog).
Z80.... it's complicated ;).
And the discussion usually never ends. Seen folks go "Z80 sucks at " only to be proven wrong due to some very creative register use.
Machine level programmed on both, and while i liked the simplicity of the 6502, the Z-80 just made more sense to me. More registers, the ability to do 16 bit math and all the addressing modes made it a no brainer for me. Sure, the 6502 could be faster, and if optimized was, the Z-80 was just simpler to write code for.
everyone forgets my fave - RCA's 81802 COSMAC
I'm Z80 all the way. I've been using them since the 80's, (ZX81/ZX Spectrum/TRS-80 Model 1), mostly with BASIC but with bits of Z80 M/C thrown in to enhance sound/graphics. I don't use assemblers though, I store M/C in data lines, I find it easier to de-bug them that way. (for some reason)
BTW, Subbed. :)
My first computer was a trs 80 with a z80 😃 felt like we were living in star trek 😆
80 all the way, and if starting it 'rodney zaks programming the z80' is the bible/rosetta stone. I still have that book I bought in 84
Watch out for the typos and mistakes in that book! I prefer using Zilog's typewriter printed manuals.
I'm lucky enough to have spent many years programming both types of these CPUs (and others). I agree with you. At the end of the day, the Z80 is just 'more computer' than the 6502. But are frustrating though, with their 8-bit word length. I prefer something like the 68K range of CPUs, or, my all-time favourite, the TMS99xx range from Texas Instruments. Beautiful, orthogonal instruction sets, genuine 16-bits word lenghth, with hardware multiply and divide.
after working with Z80 the TMS9900 was 'a dream' till the 68k came along ... then i 'found' the NS32000 ... but that unfortunately didn't grow
Nice video, but too many comments complaining that it's too long!
The 6502 is a cycle monster.
Anybody else remember the "Big Board" SBC from the early '80s? Made by Digital Research Computers out of Bend, OR.
I first used the Z-80 in 1978 and I must admit, your exploration of that chip was interesting in that it was filtered through the lens of the 65C02. Sort of like describing English using the grammar rules of French ;-) Not bad or wrong, just... different. Keep up the good work!
I have an established audience from my 6502 content, and I want to help bring them into the Z80 stuff. That was a big reason for this video, to bring the old and new audiences together
It would be cool if there was a sort of in between of these chips. I'd probably call it a 6Z802
6 zee 8 oh 2
The other big difference between the two is that Z80 doesn't use memory-mapped ports. It has a different address space for I/O via the IN and OUT instructions.
Yeah, that's more like what I was used to coming from Motorola assembly
Doesn't _need_ memory-mapped I/O would be more accurate. There's nothing stopping you using it if you want faster I/O access at the cost of memory address space.
@@lister_of_smeg6545 Some things were faster on I/O, some were faster with memory. Depended a bit on what you wanted to do.
E.g. for I/O there are the INIR and OTIR instructions that can send a number of bytes to a single port quite quickly.
But when you need to do some bit-testing between the actions (as usual), they are not useful and accessing memory mapped devices via HL is often quicker.
Apparently lots of the '80s videogame cabinets did use memory-mapped ports. There was nothing stopping you from mapping hardware to either address space.
I think the X16 is a great computer for demonstrating 6502-based systems. For the Z80, you can look at the ZX Spectrum Next.
I have been! ua-cam.com/video/kTKi5rfYndY/v-deo.html
@@slithymatt haha I know - it was the plural "you" :)
I think the separate i/o addressing just about wins it for me as we dont have to have specific memory mapping decoding logic.
Interestingly the bit set res instructions where not introduced in the x86 until the introduction of the 80386. The DJNZ instruction is called LOOP in Intel x86. How about the LDIR, CPIR etc. Instructions and that out instructions ? Nothing like that in de 65C02?
Nope, all the 65C02 instructions do basically one thing, nothing taking more than 7 cycles.
I first programmed Apple ][ Basic on a neighbour's computer in 1979, then TRS-80 Basic on a schoolfriend's Model 1. I first heard of assembly or machine code when we were programming the TRS-80 and probably saw Rodnay Zack's book at that time. I finally got my own computer, a 48K ZX Spectrum in 1982 and moved from Basic to machine code after maybe a year, teaching myself from magazines and the Speccy manual which listed all the Z80 opcodes. I never even saw an assembler and didn't get the point of hex. I figured out the decimal for all the opcodes and addressing modes, etc. Poked my code into memory using Basic DATA statements. I did write my own disassemblers for Z80 though. Code was saved onto cassette as floppy drives were only for the rich in Australia in those days. Fortunately the Speccy seemed to load and save to cassette faster than the C64 could with a floppy. School finally offered a computer class which did include some 6502 on the Apple ][, but I don't remember how hard I found using the 6502 after the Z80. Our project was probably too trivial. A few years later when I got into Amigas I found it natural to move from Z80 to 68000. Interestingly many of my friends in those days had moved from the C64 to the Amiga and also found it natural to move from 6502 to 68000. But to me looking at 6502 and 68000 they look nothing alike. I never got into x86 assembly after we moved to 486s. It seemed ugly and confusing. I think my 6502 friends found that transition easier. The 6502 page-zero stuff probably made the x86 segment stuff seem easier for them than for me.
C64 used serial communication to the floppy drive, so it wasn't fast... :-)
@@AndersJackson I was quite shocked when I first saw C64s loading games off floppy with fastloaders. They were still slower than Speccies loading games off tape with fastloaders - and a lot more expensive (-:
Would be interesting to see the Motorola 6809E added the mix.
I extensively programmed ASM on these two CPUs; and I'd go with Z80 for it's richer instruction sets.
Conditional is not called an addressing mode because it doesn't address anything (i.e. a destination for data such as RAM or a register). It's definitely an operand though.
21 00 00 11 00 40 01 00 40 ED B0 C9 :) (Written without looking on the cheat sheet)
LD HL,&0000
LD DE,&4000
LD BC,&4000
LDIR
RET
Without looking on any cheat sheet! :-D
@@unpreppedprepper2710 Well done!
LDIR took 21 cycles per byte if i recall correctly, that's why i built an expansion for my speccy with a Z80A-DMA, only 4 cycles per byte ;-) needed a bigger power supply though ...
@@jfkastner Oh wow, non hardware related DMA usage. Something new to me. Never used DMA like that before. I have used DMA for data I/O in PCs and ADC/DAC related on microcontrollers. No idea if the 8237 in the PC could even transfer RAM-to-RAM.
@@ChipGuy don't know the 8237 ... the Z80 DMA did a busreq so the CPU was 'playing dead', and it could reach anything the CPU could - source&destination in I/O or RAM. you could even modify the timing per DMA register settings
There is an old isometric game called "Amaurote" - quite interesting, difficult to play, fun to watch... my point is on Z80 machines (ZX Spectrum) it runs well BUT 6502 machines cannot handle this game: Atari 800 version is slower and completely monochrome, C64 version is colourful and fust but is in plain 2D.
Seriously Z80 has an edge when it comes to anything other than primitive 2D graphics.
Both were great processors. Moto’s 6800 was not bad either back in the late 70’s.
I'm team Z80 because I just can't be dealing with all those 6502 addressing modes. That said I gave up writing cpu emulators because I couldn't be asked to implement 800 odd Z80 opcodes!
That said, before I gave up completely, I did discover the Zilog Z8000. Now that's a nice CPU design! Shame it never made an impact between the MC68K and i8086.
IIRC the Z-8000 was designed with discrete logic, rather than using microcode like the x86 family. So it was buggy, and it took too long to work out all the bugs (I had seen the Z-8000 manual, and loved the instruction set, but was disappointed with its failure to thrive).
In 1977 I chose the TRS-80 instead of the Apple ][ because the 6502 instruction set was "odd". The Z80 instruction set is much more logical in terms of completeness of instructions and memory layout.
HealthKits HDOS used an interrupt instruction for service calls to the os… placed on the stack was the list of parms …
I'm firmly in the 656xxx family.I have worked in both instruction sets.
My issue with the x80xxx instructions is that they waste states.
Oh we can run at a higher clock rate so we can do 4 T cycles per fetch and that makes us faster.....
BS.
The 65xxx
and 68xxx
systems used dynamic instruction clocking.
It was always fun on the Commodore 128 which had a MOS Tech. 8502 (evolution of the 6510 from the C64 which was also an evolution of the 6502) and a Z80.
It's a shame the Z80 was so crippled though )-:
Keep in mind that the same person that designed the z80 did the 8080 … and Intel copyrighted the mnemonics… so ZILOG had to create new ones… the LD replace the MOV and simplified the thought time with a minimized instruction set … IMHO memory mapped IO sucks because it takes program storage and use address space away…
I love the MOS6502 and I respect the Zilog Z80. What fun it would be if these two giants could work together as one, so that if one of the two processors is a bit tired and wants to rest for a few clock cycles, that the other will take over, both using the same memory, the same IO, the same whatever!
Just like on my proximately forty years old Apple II clone where they are more microprocessors on the same motherboard, like brother and sister. It is a pity I have no clou how it works. Maybe (probably) there is a disk with software to let the 6502 work with all IO and the Z80 is doing the CP/M programmes. I know that one of the two microprocessors is tri-state and the other must act like he is, I guess.
i’m in the 6502 camp and see speed tests that favor the 6502, is that true? What about code density between the two?
It's too variable, you could easily rig a test that favors one over the other.
If you look here, you have a much larger test set, and it show that the 6502 suffer for the low number of registers.
It's small size reduced the cost though.
en.wikipedia.org/wiki/Motorola_6809#Market_acceptance
@@AndersJackson ive always thought that with the zero page the 6502 had 255 registers, or less depending on how you use them; all mute at this point; back in the day the z80 was a bit of mystery
Imagine a Z80 CPU with 32-bit wide registers, hardware multiplication and division, relative jumps and calls with 8-, 16-, or 24-bit displacements, stack-relative addressing, and four complete register banks, each consisting of AF, BC, DE, HL, IX, IY _AND_ AF', BC', DE', HL', IX', IY' register pairs. Further imagine that it also has a full 32-bit address bus as well as a 16-but data bus and can run at 18MHz. Oh and there's a new Interrupt mode, IM3, as well, which takes a 16-bit offset from the data bus to add to the base address defined by the I register (which is now 24 bits wide). Of course the Program Counter and the Stack Pointer are also 32 bits wide.
Like the z380?
@@emesde Yup... Or perhaps the Z382 which has a number of additional functions added to the chip, which can be seen here: archive.org/details/zilog-z-80382-product-specification/page/5/mode/1up
As a Z80 guy in about '83 or '84 hearing about the Amiga and the 68000 made all my dreams of that type come true. I remember how excited I was when a friend who worked for Melbourne House told me over the phone how many registers there were going to be!
Sixty-Five C oh Two Is my preferred processor by far. I do have the best of both worlds I run cpm on my Apple //e using a a z80 card from Microsoft. I’m lucky enough to own a ZX Spectrum to get to do some bare metal programming on both chips. Would be keen for you to cover a proper RISC chip like HPs PA-RISC architecture
I used an HP-9000 in University for my VLSI design class. That was a seriously impressive computer in the 1990s. Never got a chance to look at the assembly code, though.
My take is that if you are proficient in assembly programming, whatever CPU/MCU (new to you) you have to program for, you will have to make yourself very familiar with the particular architecture and therefore it really does not make much difference. BUT, my opinion is that I very much prefer the Z80 assembly mnemonics and structure because it is much more logical. The 6502 mnemonics are trying to squeeze just about everything in three letters and are therefore very hard to memorize garbled things, and loading and storing are different mnemonics, whereas the Z80 mnemonics are longer but consistent, e.g. moving a value is always a "load" (LD) and the conditionals are always the same (e.g. Z for "if zero" or NC for "if no carry"). This is also a reason why I was very sad to see the Siemens/Infineon C167 MCU architecture disappear because it had just about the best naming conventions for both assembly mnemonics and register naming!
Decrement Jump if not zero -- this is a single-instruction set that is universal for boolean algebra (normal computing). Maybe they added it to the Z80 as a joke?
The MEMOTECH MTX512 has the ZILOG Z80A but I wish it had the ZILOG Z800.
So did Zilog, I bet!
@@slithymatt The sound to light program in the MEMOTECH MTX512 Program book is an excellent example of Z80A machine code.
I’m going to have to say “Apples and Oranges”. Some of Z80 features that you consider to be negatives, coming from the 6502 world, are actually more powerful than anything that the 6502 has to offer. Page Zero has a completely different purpose in both processors, so you really can’t compare them. I had to go back to my original Z80 documents from Zilog, as your Z80 syntax is a little off, and then I realized that you’re mixing some of the 6502 syntax into some of the Z80 syntax.
BTW, there are quite a few hidden Z80 commands, and some of them are rather useful. ;)
the 'hidden' commands were nice (e.g. a DD ahead of an HL opcode) BUT they might NOT work on chips from other fabs