MOS 6502 vs. Zilog Z80 | Matt Godbolt

[@melkiorwiseman5234]

I've programmed in both "flavours" of machine code. In my opinion, the 6502 had an advantage in having many "relative" instructions including (although this may have only been in the 6510) the Program Counter Relative instructions. This is on top of having the Zero Page data handling instructions. All of this made the CPU able to run a bit faster than the Z80 (all other things being equal). Where the Z80 had an advantage was having I/O ports and a LOT of internal registers. The I/O ports meant that the CPU could access external hardware without needing to "memory map" it, so it didn't need to sacrifice memory space to access hardware. Having a lot of internal registers allowed some types of operations to work faster, and also helped the CPU to handle a multi-user, multi-tasking environment far better than the 6502 could have done. You could also use "Memory Banking" in the Z80 more easily than in the 6502 and without having to sacrifice some memory to use as an I/O port to control the memory banking. So, overall, I think that it's "horses for courses". Personally, I tend to prefer the Z80, but I can't say for sure that it's "better" than the 6502 because it depends on what you're trying to accomplish.

[@Calilasseia]

Ah, so the Z80 only had a 4-bit ALU? That explains how they were able to implement a half carry bit for the DAA instruction in the flags register! And solves neatly a problem for emulator writers too. Wish I'd known this years ago!

[@onuktav]

5:10 I'd never have thought that I'd see someone talking about those protection routines. Back in the 80s, I happened to hack into one such game (Fairlight, if I'm not wrong) on the ZX Spectrum. It was encrypted with a routine using the Z80's refresh register, something similar to the timers mentioned. But I could copy the decryption code to somewhere else in RAM and run it successfully, which made things way easier than what Matt described. The decryption revealed a similar routine+encrypted block. I tried it again and from that point on, every consecutive attempt revealed another block, like Matryoshka dolls. After several hours and around 120 such copy+decrypt runs, I finally got to the game. It had lost a lot of weight at the end -- the save file was several kilobytes smaller.

[@gregorymccoy6797]

I really appreciate talks / presentations like this. I hope you guys can make more of these!

[@johnjakson444]

in 1979 I had the privilage of reverse engineering about a dozen processor chips, F8, 1802, 8080, 8085, Z80, 9900, 8086, 68000, Z8000, and others. By far my favourites were the 16/32 bit machines. For its MOS simplicity the 9900 was a marvel, it was really only a 1bit serial cpu so was very economical with transisters and at speed could really only run at maybe 250kips taking atleast 18 cycles for 16 bit register ops but it had the grown up architecture of a mini computer which it was derived from TI990. I had programmed the 9900 at TI too so I was biased. Later the 68000 would be my wife. As for the 6502 vs z80, 2 very different beasts neither of which I would want to write grown up code for. Of course my real job at the time was to work on the design of a UK microprocessor for parallel programing. I was impressed with my BBC though, decent piece of kit with loads of language compilers for it, I was much less impressed by that Sinclair Ql POS with the crippled 68008 in it but that was replaced with a Mac ASAP.

[@JH-pe3ro]

The 6502's chief advantage in an architectural sense comes from being more "connected"; it can share a data bus better and use fewer cycles per instruction, which lends itself to doing timing-intensive raster tricks of the type seen on the 2600. It definitely wants you to get your hands dirty to make it fast. Z80 programs have more task-specific features - they can fill memory, operate over 16-bit values and have port I/O instructions, all of which are nice programmer conveniences. It's a little more suited towards extending a system with additional processing and a lot of arcade systems would carry multiple Z80s. Nobody talks about the M6809 but those who have used it say it's a better, later 8-bit design that gets a lot of things right. This battle of the architectures continues today with the eZ80 in Agon Light versus Neo6502's W65C02S - and the characterization is similar, just updated to use modern microcontrollers. Agon has quite a bit more memory and the ESP32 that it's paired with is a higher spec, but it opts for the clean design, doing everything over serial UART with a special instruction set - and as a result you have to program the ESP32 like a modern GPU and ration your bandwidth to get it to go fast(and the democoders are getting it there, although it's still WIP tooling and firmware). The Neo6502 can lean on its RP2040 to act as a coprocessor and interact freely with the main program, which is more direct in one sense, but also more of a chimera. (Personally, as an Agon user who wants the clean design, I like where it's going - it allows a graphics engine to be reused in a completely different codebase without changing anything. Just send the same bytes over UART)

[@galier2]

The big advantage of Z80 over 6502 is that it is more suitable for compilers as it can place the stack where it wants. That's why there are several absolutely fine compilers (on the CP/M site they list around 18 C compilers and 7 or 8 Pascal compilers). Even if the generated code is far from being optimal, compared to a competent assembly coder, the ease of use makes up for it. On the 6502 there are very few compilers and the few there are generate really bad code. The poor stack being the major problem.

[@stephenwhite506]

The 6502 has the advantage over the 6800 in that it is little endian. This enabled it to pipeline better and early out of some address modes. Because it fetches the low byte of an index address first it can add the low byte of the index at the same time as it is fetching the high byte. If there is no carry it can early out.

[@ArneChristianRosenfeldt]

@@galier2so the Z80 has SP relative addressing or a BP. Somehow when I think of a stack, I think of 8086 or 68000. I don’t quite get if compiler for 6502 are global compilers. Like for a PC I would compile -O3 and it would take ages. I would link assembly and C and C++. But why would I need a linker for small projects? Inline assembly inline methods and C++ ! Small project only need 256 bytes of Stack. The rest is video back buffer, songs, sprites - the game assets.

[@ArneChristianRosenfeldt]

@@stephenwhite506a compiler can do a global analysis and find all recursions. All functions outside of this store their local variables at absolute addresses. Thanks to little Endian, this is really fast. Inner loops and terminal functions get addresses in the zero page. Global analysis finds out where capacity is left of the stack. Sometime push and pop give compact code. It is a bit weird that we cannot push pointers. Rather we push pointers into zero page. And there the actual 16 bit (little Endian) pointer sits !? Also weird to Store array of Struct spread over pages to use x as array index.

[@74HC138]

The similarities between Z80 and x86 are not accidental or coincidental. Federico Faggin designed the 8080 (the forerunner to the 8086, the first x86) and then Faggin left Intel to found Zilog and design the Z80, as a binary compatible CPU to the 8080.

[@andrewdunbar828]

Federico goes all the way back to the 4004!

[@daveturner5305]

If I recall correctly the 6502 had a 2 phase clock as did the 6800, whereas the Z80 had a 1 phase clock. Furthermore the Z80, at least in the original 1MHz version, had a 1 phase clock and used static memory. For experimentation this made the Z80 a wonderful choice even if the first ones available in the UK (approx 1976) cost £120 apiece. I know I bought one. Neither one was better than the other it all depended on what you were attempting to do, and one's budget. At the time static 1kx8 memory per unit was about £12 apiece.

[@occamraiser]

My benchmark price (for Sinclair QL - era memory) was £1 per K.

[@daveturner5305]

@@occamraiser I wonder whether there is a Moore's law for memory?

[@HA7DN]

The Z80 had internal DRAM refresh circuitary, meaning cheaper RAM could be easily used.

[@daveturner5305]

@@HA7DN True and I did implement it eventually, but at the time, 1976, I was particularly interested in the ability to 'clock step' the Z80 through every positive and negative transition of the clock cycle and observe effects using leds to monitor all the address, data and control lines. This was impossible using dynamic RAM, without budget busting separate RAS/CAS circuitry.

[@8bitwiz_]

Unfortunately, due to the weird design of counters in the Z-80, the refresh register only counts 7 bits. This may be the actual reason that a surprising number of 64Kx1 DRAMs had 7-bit refresh.

[@djrmarketing598]

99.99999% of the population has no clue what these guys are talking about. If you understood what they're talking about, you truly were in a magical computer era at the time. I happened to get into assembly language on my Commodore when I was about 11-12 in the late 80's because my dad wrote computer software independently.

[@Raspredval1337]

I know what a 6502 is but not the other one. I even tried to make simple NES emulator in cpp, pretty cool stuff

[@Mikey__R]

We were talking about this at work the other day. Most software devs who have grown up on Java or C# are so removed from the hardware, they've no idea how their code might translate to the metal. We write in C++, I think my background in microcontrollers, and before then the Z80 in the Sinclair home computers, gave me a bit of an unfair advantage.

[@easterneurope451]

​@@Mikey__Rhyper abstraction and endless frameworks. I miss asm and c so much. 6502, Z80, M68K, x86 asm were my flavor. I think i am done with programming.

[@occamraiser]

I finished my Computer Science Degree in 1983 - it was indeed a very special period. Anyone with a brain and an interest could write industrial quality software with just an Asssembler code / addressing mode cheat-sheet :)

[@daveturner5305]

Whilst emulators for the old microprocessors are relatively easy to obtain now, unless you lived the era it would be difficult to truly understand the wonder experienced then. I suspect that in every generation a tiny percentage of the population have had and will have similar experiences as technology advances. My vain hope is that sociological advances will eventually catch up.

[@redram4574]

Very nice. There's not much low level podcast-y stuff on yt

[@occamraiser]

Interesting title. At the beginning of my professional career these two processors along with the 6809 were the mainstays of all single board computers being used professionally - until the 8085 turned up. Ahhh, happy days :) writing assembler and knowing that I was the master of arcane arts that only comparative a handful of people shared at the time.

[@johnmckown1267]

I was a Z-80 zealot. My BFF was 6502. We came to an agreement: "He's an idiot, but I like him anyway." 😅

[@HSkraekelig]

I loved the Z80. It made no sense to me to allocate blocks of precious memory address space to IO. yuck!

[@andrewdunbar828]

@@HSkraekelig Some Z80-based machines still memory mapped some stuff anyway. I don't remember what though.

[@RKelleyCook]

I too was a Z-80 zealot still in possession of my TRS-80 Model 1. The Z-80 was innovative and powerful microprocessor with its quasi 16-bit registers. With this power you could write assembly much shorter than the 65xx. However, I've come to realize the simplicity of the 6502 actually made it the true king of 8-bit processors. It took a decade for anything to match its IPC rate. And at 1 MHz, it would out perform simple code running on a 8088 that was clocked almost 5 time faster.

[@xjet]

The 6502 was fast and fun to program *ONLY* if there were enough page-zero addresses (the first 256 bytes of memory) free to allow the many indirect addressing modes that relied on that chunk of memory. Unfortunately, most store-bought 6502 systems had much of the page zero memory already used by the system software. The Z80 had some cool instructions (such as LIDR) but those could be effectively emulated with macros on the 6502 so that wasn't as important as some suggest. I recall spending *many* hours hand-coding assembly into machine code for both processors. Happy days!

[@ArneChristianRosenfeldt]

On C64 or plus4 you can deactivate the system software and swap out the ZP contents.

[@andrewdunbar828]

Game programmers never used LDIR and related instructions after the very earliest days. Handy to make readable assembly code when you don't care about speed but very slow.

[@xjet]

@@andrewdunbar828 I used to make macros that did the same as the Z80 "block" instructions. That way I could use a conditional which meant the code could be generated for Z80-specific machines or was limited to 8080 opcodes so as to be compatible with the 8080 and 8085 processors of the day.

[@Zadster]

Hacking games was a phenomenal way to learn how things really worked! So much motivation, combined with the sponge-like brain of a young child, I wish I could learn that quickly and perceptively now!

[@stephanschmidt2334]

Biased as I learned assembler in the 80s on Amstrad Z80, but the Z80 felt more designed than the 6502 to me - "Z80 Assembly Language Subroutines" is still my favorite computer book.

[@8bitsaga]

Same to me. My platform was (and IS) the MSX.

[@liamquigley4670]

I did a little bit of assembly programming on both back in the day at University and I far preferred the 6502.

[@andrewdunbar828]

I'm an old Z80 coder on the Speccy and only ever wrote the tiniest little bit of 6502 once on the Apple II and I always just believed the 6502 was faster, because everybody always says so. But then the CERBERUS came out about two years ago, with a 6502 and Z80 on it and all of their tests, including BBC Basic running on both, showed the Z80 was actually faster than the 6502.

[@Calilasseia]

The picture is a little more complicated. Memory copies on a Z80 are far faster, because after the register initialisation, you run a single instruction - LDIR. You have to write a software loop to achieve the same result on a 6502. But 6502 table indexing is faster, because the instructions to do so were native from the beginning, not bolt-ons post-8080. If you need to use IX or IY for your table indexing, that's slower than the 6502 equivalent. Tasks that take advantage of the Z80 being able to perform 16 bit arithmetic in one instruction, or take advantages of goodies such as LDIR, will always outpace other 8-bit CPUs, but interrupt handling is complicated on a Z80 (sometimes requiring support chips) and pushing 8 registers will always be slower than pushing 4. Also, any Z80 instruction requiring a prefix byte (DD/FD for IX/IY register use, CB for BIT instructions etc) will run more slowly than instructions on a CPU that doesn't use a prefix byte.

[@andrewdunbar828]

@@Calilasseia In Speccy game code nobody uses LDIR and friends in fast loops because they're famously slow. The fastest way to clear memory is to move the stack pointer to the end of the memory block you want to clear and push all the registers over and over. First game I disassembled that did this was 1985's Starion. There's a similar technique for copying. Nobody uses IX/IY in fast loops either.

[@Calilasseia]

@@andrewdunbar828 ... that approach won't work for COPYING memory blocks though, which is the use case I specified.

[@andrewdunbar828]

@@Calilasseia The approach does work and is used. KZbin deletes comments with links but Google for "How To Write ZX Spectrum Games - Chapter 13" "Double Buffering". Another source if you Google "Chasing the raster on the ZX Spectrum in Sidewize". There's probably a bunch out there.

[@sfperalta]

Having come of age in the 8-bit era and spent the last 40 years working professionally as a software engineer, I would say that the attraction of these chips were that they were accessible and understandable by hobbyists without advanced degrees. It was fun, but ultimately these computers could not keep up with the ever expanding needs of business and science. But they still remain accessible and useful as hobbyist kits and are still quite good fun.

[@galier2]

10:00 Motorola 6800 had direct page addressing, i.e. the same thing as zero page addressing (6809 could even set any page as direct addressing). What it didn't have were the pointer addressing modes (zp),Y and (zp,X) which were these genious addressing modes that made lookup tables so damn easy on 6502. The innovation was not the zero page addressing, but the pointer indexed modes.

[@8bitwiz_]

It should be noted that when Motorola came out with the 6801/6803, which added a few new instructions, one of those new instructions was ABX. When I try to write 6800 code (as someone who had actually in the past been paid to write 6809 code), the lack of ABX becomes quite apparent.

[@anonemouse3768]

I programmed both chips. A 1MHZ 6502 had about the same performance as a 2 MHz Z80. My major problem with the Apple II 6502 was the memory mapped I/O. It took a big chunk of usable memory away from programming. I preferred both to the Intel 8080 series chips.

[@terpcj]

I was very familiar with the 6502, Z80, and 8080 back in the day. I found the actual, bare metal, programming with the 6502 was more fun and also more fraught. It was so easy to corrupt memory if you weren't paying attention (C pointers were Fort Knox in comparison). And since you often had to make a useful program with just 4k of memory (some of it reserved), overwriting code or memory was just something you had to do at times. That said, I found writing Z80 assembly a lot more fun. Sure, the executable could be slower, but the code was a lot more readable. For all of them, though, I groaned with having to write so many floating point libraries just to get work done. Counting bytes and cycles was huge and there were so many trade-offs. Most programming nowadays lacks that sort of forced encouragement to innovate. TBF, there's only so much you can do with a 1 MHz, 8-bit CPU with 4k RAM. At least we still have uC's.

[@andrewdunbar828]

I'd say there are some equivalents today. Shader coding feels a bit like those days. And SIMD requires the detailed knowledge and low level finessing. And there's also FPGA programming. Then again I feel like I'm too old to learn a lot of that stuff now...

[@srus]

My first assembly code I developed was on Z80 inside a ZX Spectrum in 1986 when I was the EE student. Then first assembly code I developed on 68HC11 inside a custom board was at my first job in 1990. Nice memories.

[@japa86]

Same thing, was a EE student in 86, but was already playing with z80 asm since 82 as a teen. Got to learn all z80 opcodes (hex) by heart. Did some pretty crazy stuff in assembly at 15... still writing assembly for fun 40 years later, now on Arduinos. Awesome memories!

[@stinchjack]

Ive dabbled with Z80 assembly. I rely heavily on all those registers, and couldnt imagine trying to write assembly with the few registers available on the 6502

[@xuthnet]

As was mentioned, the 6502 relied very heavily on zero page indirection which gave you a bunch of interesting effects. One of the biggest things you could do is have a "stack frame" (in the C fashion) by having a pair of zero page bytes pointing at the beginning of the stack frame and saying "load the accumulator with the byte 10 bytes in memory after the address I've stored in zero page".

[@jnharton]

You can always use main memory if you just need a place to store/retrieve a value from. The 'zero page' of the 6502's memory space is special because access to it are faster.

[@xuthnet]

@@jnharton Not only was zero page one cycle faster, it was used for the various indirect addressing modes.

[@BoianMitov]

As mentioned by others, the 6502 used the Zero page effectively as 128 index registers, so in the old days we were rarely short on registers ;-)

[@nonarKitten]

Don't forget the stack. FORTH proves how powerful the stack is, you just view A as your "top of stack".

[@joelavcoco]

I believe that the 6502 inherited the zero page from the 6800. In the 6809 it was called the Direct Page, and the 6809 has an 8-bit DP register that allows you to place the direct page anywhere in memory. Each running process in OS-9, for instance, can have its own direct(zero) page. I don't immediately see in my 6809 book where there is an option to use 2 bytes in the direct page as an index, and I don't remember it from the CoCo days. However, the 6809 has 16-bit index registers X and Y, as well as 16-bit stack pointers U and S that can be used somewhat like index registers, so that wasn't really needed. Not sure about the 6800.

[@galier2]

6800 only had 1 16 bit register X. It has U and S. This was its major drawback as it had only 1 index register. Implementing a simple memcpy function was made very costly as it had either to swap the X register all the time or use a lot of self modifying code.

[@thavith]

I never got to program the Z80, but had a lot of funny coding in 6502 ASM. I wrote a "sprite" for d-hires for the Apple //c. It ran on the interrupt that happens with the monitor scanlines goes from the bottom of the screen back up to the top (can't remember name of that), so I had a few cycles to play with. Just enough time to create a Macintosh looking mouse pointer that would move when you moved the mouse. The cool thing was, it ran in the background, so felt like multitasking... I hope I still have that code somewhere...

[@theronwolf3296]

Memory value here. I had a 8080 based computer (back in the mid 1980s so I created an assembly compiler in BASiC (no kidding) and created a few drivers etc.

[@vast634]

oh the ZX Spectrum, my first computer. Playing Jetpack with funny little rubber keys

[@gregorymccoy6797]

Additional registers win from a programming standpoint.

[@SianaGearz]

Who needs registers when you're constantly pumping RAM every cycle and you have zero page? It's almost as if you had 256 extra registers. If a register only operation takes 2 cycles, then a zero page one takes 3 and any other page substantially longer. It's a minor performance concession on an overall pretty fast processor.

[@Mikey__R]

TBH, I think the days are past where this is really a consideration. I don't think there are many projects left out in the wild that program in assembly, everyone is compiling their code now. So long as the compiled code meets the performance requirements, I think very few devs will care what architecture they're running on. For general purpose architectures, at least. I suppose the exception would be special purpose processors like DSPs, GPUs, some of the wilder neural net processors...

[@qwertykeyboard5901]

​@@SianaGearzHaving a full 16 bit stack pointer is _pretty nice._ Allows storing variables on the stack.

[@daybyter]

@@qwertykeyboard5901 Yup. And when you try to do multitasking, you can easily have multiple stacks and just exchange the stackpointer in the task scheduler. This might be the reason, why Linux is still not ported to the c64... 😂

[@qwertykeyboard5901]

@@daybyter The C64 doesn't have enough memory, nor a proper MMU with page file support. THAT is why linux isn't on that machine.

[@ricomariani]

Zero page addressing mode = 256 registers :D

[@ArneChristianRosenfeldt]

128 because I Store pointers there. It would be cool to have a burst mode. Like that the PLA in C74 does not need to run or MOSTEK fast page or 4 byte burst could be used. Instructions could be loaded in a two byte burst. 2 x 4 bits for 16 bit source registers. Load 4 bytes. Then store two bytes in the target. Pipeline to not miss a memory cycle. Hidden Akkumulator caches result from last instruction if target is any source of next. Like on Spark, 8 local registers, 4 parameters, 4 global. JSR shifts the window by 8.

[@franciscotoro827]

I have a question I hope some one can shed some light on for me. These 2 processors, were developed in the 70's and used though out the 80's even into the 90's even in use today for some things. question 1 was the 6205 made in the 70's the exact same as ones made in 1988. like a modded 6502 was used in a 2600, but then standard 6502 was in the 400 and 800, the 5200 and lynx, it was used in all early Comidors, and apple 1,2,3..... my question were processors super simple in there function back then, or sooo capable that the rest of the computer had to catch up with it, like ram and co processors, and video components ? Like if you look at games from 1980 on home pc's and systems compared to a game from 1989, the difference is almost as big as the jump from Wolfenstien to Halo, but now imagine I told you both games were run on the same CPU.... I think you would have questions

[@esra_erimez]

This is very interesting and informative

[@ricomariani]

That cat and mouse game started as soon as 1980 :D

[@8bitwiz_]

It's a trick question. The answer is "6809".

[@gregorymccoy6797]

The z80 does have a 4bit ALU but it feeds it at half M cycle. So from a practical standpoint there is no handicap.

[@andyhu9542]

Was about to comment that. However, with an 8-bit ALU it can potentially do the calculation in half M cycle and use the other half to write back the value and fetch the next instruction. Maybe that count as a handicap?

[@MattGodbolt]

Ah today I learnt! Thanks

[@ArneChristianRosenfeldt]

Multiple ADCs need to store the carry somewhere. So you can do only one per cycle (physical clock). Phases or - what is an M cycle - don’t help here. 6502 does 16 bit add in two cycles, z80 needs 4.

[@andyhu9542]

@@ArneChristianRosenfeldt Too sad that there is no 16-bit addition instruction on the 6502, only 16bit+8bit used in addressing.

[@ArneChristianRosenfeldt]

@@andyhu9542 I can see why: 6502 has 8 bit registers. No muddling with pairs. Not for the stack. Addition needs two operands. One needs to come from a register. 68k showed that big registers and a powerful rotation instruction is the way to go.

[@MikePerigo]

08:57 Been there did that,also failed. Gave up and had to play Alien 8 from cassette. The only game I failed to convert to disk. I had to wait until hardware snapshot images became available to bypass the loading routines.

[@fromgermany271]

As my 1st contact to micros was a book about KIM-1, a 6502 kit, and I had no clue what these weird codes meant, I became an „intel guy“, because when looking at the Z80, I had enough clue to understand this stuff. Today 6502 with its zero page stuff more looks like a microcode system, where you can implement your virtual machine with, like Voz did it in the Apple2. But today I rarely care about assembler anymore 😎

[@ssl3546]

Oh man you are going to have 10,000 subscribers so fast. It is so hard to find videos about classic computers that isn't bleaching yellow plastic or other dumb crap

[@andrewgrant788]

The BBC Micro used a 6502, the ZX Spectrum used a Z80. Clearly the 6502 must be better.

[@borealis8uno]

If you have in the RAM speed a bottleneck, Z80 wins. Amstrad/Schneider CPC is an example: if designed with the MOS 6502, it would have had it at 1Mhz, while with the Z80 it was able to run at 4Mhz (~3.3 effective, but still something more in terms of computing power compared to the MOS)...

[@BsktImp]

LD HL, hello_msg LD B, 0 print_loop: LD A, (HL) CP 0 JR Z, end CALL &BB5A INC HL INC B JR print_loop end: RET hello_msg: DB "Hello, world!",0

[@gp2k00]

Sweet, sweet Z-80 code. Love it. Can tighten it up a little bit by replacing: CP 0 JR Z,end with OR A RET Z

[@MichalKobuszewski]

@@gp2k00 Love the comment section on such channels, where you can find people reviewing assembly code for a 40 year old CPU!

[@BsktImp]

@@gp2k00 Of course your right - on both counts (pun intended)! And likewise reference to the B register. :)

[@gp2k00]

@@BsktImp I wondered about what B was doing but I thought that maybe it was important to the routine at &BB5A.

[@BertGrink]

Is that for the Amstrad CPC?

[@andyhu9542]

Anyone saying that 6502's cycle efficiency is a good thing have not designed hardware with a Z80. The Z80 has all the correct signal happening at the correct time, in the correct order thanks to the many M cycles. With 6502 everything happens on the same clock edge and it's a massive race condition. This indirectly caused the many timing issues plaguing early revisions of the BBC Micro.

[@MattGodbolt]

A fair point! Simple for me the programmer! 😂

[@xuthnet]

I don't know what the Z80 is like but the 6502 is mostly just stupidly simple and this can be used to your advantage. Wozniak's solution with the Apple ][ is quite elegant (use 2 Mhz ram with a 1 Mhz processor and alternate access to the ram between the processor and the support hardware). Alternately you have one line to pull to pause the processor which lots of people have successfully managed.

[@xlerb2286]

Yup. It was so easy to design hardware around the Z-80 a not very bright high school student (me) could do it. My first Z-80 machine had an 8250, 8255, a Zilog CTC chip, 2K ROM and 4K RAM on a point to point wired perf board. No troubles getting it up and running. Figuring out how to write some code to use the hardware was way harder. That would have been somewhere around 1981.

[@andyhu9542]

@@xuthnet The Z80 also have a WAIT line, and it has a BREQ line that the 6502 don't have. This line allows peripherals to access memory as the host of the bus. I would say for an expert either CPU is suitable for designing an innovative system. But as someone who has designed and built computers around both chips, I would say it's easier to sketch up a minimal system with the Z80.

[@dave24-73]

Z80 is two to three times slower than 6502 since its fastest instruction is 4 cycles and 6502's is just 2.

[@Myndale]

Great video. I was born in '71, so I'm just old enough to remember a time in which these chips didn't yet exist. When they did arrive though, the effect they had on the world was nothing short of astonishing.

[@AnnatarTheMaia]

MOS 6502 - the original RISC.

[@ArneChristianRosenfeldt]

You mean RCA 1802 ? Show me any RISC which distinguishes between int and intptr registers!

[@AnnatarTheMaia]

@@ArneChristianRosenfeldt no, I mean MOS 6502. I do not understand your request: int and intptr are higher level language constructs. What does that have to do with a reduced instruction set?

[@ArneChristianRosenfeldt]

@@AnnatarTheMaia Ah, now C is a high level language? Joke aside, I did not know about intptr when I learned C. I had the feeling that it was introduced later to better model the low level. Modern CPUs deal with pointers and integers the same way, but totally different with floats. And someone here linked to a RISCV vector extension, which really looked to not to be filled with intptr. Oh. Anyway, I just meant that on 6502 you have Akkumulator for int (values, logic, bit shift) and you have the X,Y,S pointers which you can use in addressing modes and iterate. On 68000 you have 8 address registers (intPtr32bit) and 8 value registers. I dunno Z80, but on 8086 to keep you code size small you have values in AX, DX, while you have pointers in SI,DI,and SP. RISC does not have a clear definition, but axing the difference between ValueRegisters and addressRegisters looks like a reduction to me. Makes it easier for a compiler to allocate registers ( main advantage of RISC). I mean, I don't know why people have so long compile times. Where is the linker? With dedicated registers, you just need to build the code bottom up. The instructions dictate the registers. There is some combinatorial complexity involved. With RISC you just compile up down, probably not hit the 32 register limit on MIPS. I hate that on MIPS by convention so many registers are reserved. AArch64 at least puts SP and ZP under the same name and leaves 31 to the compiler. I like the way on Z80 and JRISC: If someone wants "System Register", hide them in a (logical) second bank which costs the system call a few ticks, but not me in my inner loop.

[@AnnatarTheMaia]

@@ArneChristianRosenfeldt for those of us who started with assembler on the Commodore64, Amiga or the ATARI ST, C was always a high level language. My mathematics teacher would always get so pissed off at me, because every time he'd write some program in C I'd laugh at him and tell him that only lamers use high level languages, but it was true: back in the day, if one couldn't figure out how to program the hardware in assembler because one didn't understand the hardware, one reached for a high level language such as C or Pascal. Those were truly lame people... nowadays one would be lucky to find someone who even knows how to program in C, people are even more computer illiterate than they were back then...

[@AnnatarTheMaia]

@@ArneChristianRosenfeldt as far as I know, only the MC68000 had dedicated data and address registers (d0 - d7 / a0 -a7); all other microprocessors have general-purpose ones (ax, bx, cx, dx, r0 - r32, a, x, y, and so on...) 6502 doesn't care if you use the x and y registers as general purpose ones, although only the y register can be used for indexed access and the accumulator for arithmetic. Same with 80x86, ax, bx, cx, dx are considered general purpose registers, and on SPARC you can use r0 - 32 although compilers never do that, using i0 - i7 and o0 - o7 instead, to make use of register windows and comply with the System V ABI.

[@occamraiser]

Wow S/W engineers with real souls talking about microcode :) - spoilt by the cultist wearing the C++ shirt though :(

[@aldob5681]

hw many years spent waiting to tell that anecdote????