I believe 6502 instruction set is a good first assembly language

I cannot agree that the simplicity of the 6502 wins over the 68000.<p>The 68000 has more registers and wider data types: but the registers are all uniformly the same. It&#x27;s really just two registers A and D, copied a bunch of times in to D0 to D7, and A0 to A7. Whatever you can do with D0 can be done with D3 and so on. Some A&#x27;s are dedicated, like for a stack pointer.<p>Simplicity of structure has to be balanced with simplicity of programming.<p>It&#x27;s not that easy to program the 6502, because in moderately complex programs, you&#x27;re constantly running into its limitations.<p>The best way to learn how to hack around the limitations of a tiny machine is to completely ignore them and become a seasoned software engineer. A seasoned engineer will read the instruction set manual in one setting, and other pertinent documents, and the clever hacks will start brewing in their head.<p>You don&#x27;t have to start with tiny systems to get this skill. When you&#x27;re new, you don&#x27;t have the maturity for that; get something that&#x27;s a bit easier to program with more addressing modes and easier handling of larger arrays, more registers, wider integers.

I would argue that 6502 is a bad first ISA to learn if you want learn assembly. You‘ll spend most of your time fighting the quirks of this clever, but deeply flawed architecture. The idioms you learn to work around them don‘t translate to any better designed architecture that wasn‘t constrained by the tools and budget available to MOS at the time.<p>If you want to learn a small, yet powerful instruction set with a few quirks go for ARM v6M. It‘s still in meaningful production (no the Monster 6502 doesn‘t count), has good platform support in the latest open source toolchains (debuggers, compilers, assemblers, linkers, etc.).<p>If you value openness of the architecture enough to deal with a less mature platform (as of early 2025) then pick a RISC-V MCU instead. If you can‘t decide pick a RP2350 :-).<p>The ARMv6M instruction set is small and no loading constants doesn‘t require long winded instruction sequences if you do it as documented (PC-relative load instead of shifting in immediate data). You don‘t have to deal with self modifying code and&#x2F;or the zero page to index memory. Your registers are the same width as the address space. Yes it‘s 32 bits, but that makes it simpler to learn, use and teach than all 8&#x2F;16 bit and most 16 bit instruction sets I’ve seen because you don‘t have to work around to narrow registers for common operations. To anyone who thinks this sounds boring: don‘t worry ARMv6 still has enough quirks you <i>can</i> use for code golfing.

As someone who has been teaching assembly to undergrads for many years, I have a couple of things to say about this. First of all, I agree. The 6502 is great for beginners but that is not just merit of the 6502 language and I want to explain why.<p>I have taught 68K, MIPS, ARM, x86, etc., and the overall good student feedback I got by teaching 6502 is mostly because of the surrounding <i>context</i> that comes with the CPU. The reason 6502 clicked better than other modern alternatives (MIPS, ARM, x86, etc.) was because we use it to program a real machine that is simple to understand (i.e. Nintendo Entertainment System). Rudimentary memory mapped IO, no operating system, no pipelined instructions, no delay slots, no network, no extra noise, ...it&#x27;s just a simple box with a a clock inside, a CPU, some memory addresses, some helper chips, IO mapped to memory addresses, and that&#x27;s pretty much it!!! So, even though I agree that the 6502 is <i>not</i> the simplest instruction set out there, <i>THIS</i> simplicity of the system helped a lot.<p>And about the limitations of the 6502 CPU, these limitations were also important for students to understand that these instructions have a reason to be the way they are. CPUs were designed and wired given the constraints of that time, and that reflects on how we programmed for them.<p>So, even thought this was mostly empirical, I have to say picking 6502 and the NES to teach beginners was successful. Once again, not really because it was the 6502, but because the 6502 <i>forced</i> us to go simple in terms of the sytem we were moving bits left and right.<p>Once students played around with the 6502 and saw NES tiles moving on the screen, then it was super cool to evolve and show them how the 68000 did things differently, and then evolve more and show how MIPS came, show how pipelining works, how to take advantage of delay slots, and being able to compare the differences of RISC and CISC. It&#x27;s super simple to evolve once the basics are there.

I&#x27;m slightly surprised that no one has suggested PDP-11 assembler as a good starting point if you&#x27;re not going to learn a current instruction set. Perhaps it&#x27;s because it was the first one I learnt properly but all the early miccroprocessors felt like a step backwards. I did spend a few years writing Z80 assembler but I wouldn&#x27;t recommend it nowadays as it&#x27;s not a very orthogonal instruction set and 6502 doesn&#x27;t have enough registers to give you a proper feel for writing assembler.

I really don&#x27;t see how. When students are first exposed to computer programming, it might make sense to start with toy &#x2F; compact languages that don&#x27;t have any real-world use. But assembly is not the first language you&#x27;re supposed to learn!<p>It&#x27;s very utilitarian and most commonly just used for debugging and reverse engineering. So why would you waste time on the assembly language of a long-obsolete platform?<p>Plus, the best way to learn assembly is to experiment. Write some code in your favorite language and look at the intermediate assembler output, or peek under the hood with objdump or gdb. Try to make changes and see what happens. Yes, you can do that with an emulator of a vintage computer, but it&#x27;s going to be harder. You need to learn the architecture of that computer, including all the hardware and ROM facilities the assembly is interacting with to do something as simple as putting text on the screen... and none of this is going to be even remotely applicable to Linux (or Windows) on x86-64.

&gt; I believe 6502 instruction set is a good first assembly language<p>It was for me. In 1977 I lived in a little cabin in Oregon. I bought an Apple II as a diversion. Within a year I was working on a program that later became &quot;Apple Writer&quot; (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Apple_Writer" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Apple_Writer</a>), written entirely in assembly.<p>Some in this conversation identify 6502 assembly as rather clunky and difficult to use. In retrospect I have to agree, but in 1977 I didn&#x27;t have a basis for comparison.<p>There were no fast, high-level languages available for the Apple II, so my little program became an Apple product, primarily from the lack of alternatives.<p>Consider this -- Apple Writer lived in 8 kilobytes of RAM, but actually did things. It even had a macro language people used to process address lists.<p>I just boosted my main system to 96 gigabytes of RAM to be able to more easily host DeepSeek locally (I have an RTX 4090). I just realized that&#x27;s enough RAM to hold almost 12 million copies of Apple Writer.<p>This is all pretty surreal ... but I&#x27;ve had occasion to say that a number of times since 1977.

I prefer RISCV as an starting assembly language because: it has good design, it&#x27;s more intuitive, it has modern language and tool support (GCC, LLVM, Rust, etc.), and it runs on QEMU and real available hardware.

The topic of the 6502 ISA simplicity is a pet peeve of mine, because to me it&#x27;s clear that anybody thinking that such simplicity is a good thing, never progressed past a hello world.<p>Programming anything of moderate complexity on the 6502 is hard. 8 bits are way too restrictive (e.g. screen addressing on the Commodore 64). Multiplications&#x2F;divisions need to be hand-rolled. And even 16 bit sums&#x2F;subtractions are simple but still not trivial to perform efficiently.<p>The 8086+DOS platform is way easier to work on, in comparison (if one wants to learn basic assembly).

I go to an compsci-centered technical institute and my informatics professor (a retro nerd that loves to show us his arcade machines) went against the set program for our class, which is learning the 8808 assembly language, and instead focused on the 6502. It was honestly one of the best learning experiences of my life and i woudln&#x27;t have it any other way. He even got us to build the ben eater breadboard computer so it was particularly hands on and really interesting!)

My first exposure assembly language was the PDP-10. All I had was the DEC-10 processor manual. I was completely baffled by it. It had hundreds of instructions, with completely opaque descriptions. What was a register? What was an accumulator? What was an address? What was a stack? I had no idea. David Rolfe wrote some subroutines I needed for my Fortran version of Empire, and that helped a little, but I was lost.<p>One day, I asked my friend Shal Farley, what was a stack? He said &quot;Imagine a stack of plates. You added a plate (pushed it on the stack), and took off a plate (popped it off the stack). Suddenly, Shal had turned the lights on! I instantly understood it.<p>Then, I began working with a 6800 microprocessor on a little board. It had something like 40 instructions, that all fit on a card. 40 instructions were simple to learn, and suddenly, I got it.<p>I want back to the -10 manual, and it all made sense.

I’ve only ever learned two assembly languages: 6502 (when I was in elementary school in the early 80s) and 370 (my senior year of high school when I had access to the UIC mainframe thanks to taking night classes there). I can roughly follow the output of godbolt on those rare occasions that I’m curious enough to bother, but the complexity of modern CPUs and computer architectures are such that I don’t know that I really need to deal with assembly language now. That said, my mental model of how a computer works at a low level is very much based on how the Apple II was set up.

6502 was my first assembly language (back in the 80s). It was fine. However, when I later had to do some Z80 assembly programming I considered that instruction set a lot nicer. It had more registers. It had a swappable register set. It even had a few 16 bit instructions. Really nice.<p>I guess most people just give up once they see the ugliness of what they got from Intel.

6502 and 680x0 were just a delight. I learned C (and later C++) solely because I couldn’t escape x86 anymore and hated assembly on those chips.<p>Still do, really, though I’m decades beyond wanting to write anything in assembly now.

68000 is much more pleasent from my experience (~40 years ago, so might be wrong). Personally I also like the Z80 better than the 6502, but that is just taste. The biggest benefit of the 6502 was a zero page, I loved the idea. My favorite computer book of all time is &quot;Z80 Assembly Language Subroutines&quot;.

At my institution we teach MIPS, or rather, we teach MIPSY, which is our own version of MIPS which includes a bunch of helper pseudo-instructions.<p>It&#x27;s taught to all computer science and software engineering students. Most students would take it in their first year, second semester.<p>We cover everything from the basics to hand-compiling code with functions, stacks, arrays, pointers etc.<p>We have our own emulator and even web platform for students to step forward (and backward!) their code: <a href="https:&#x2F;&#x2F;cgi.cse.unsw.edu.au&#x2F;~cs1521&#x2F;mipsy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cgi.cse.unsw.edu.au&#x2F;~cs1521&#x2F;mipsy&#x2F;</a>

Can anyone speak on how it is to move from an older assembly, to a modern CPU? I asked to take an assembly class in local&#x2F;public college, and was told they wouldn&#x27;t hold the class because not enough students were interested. This was in 1998, and I truly couldn&#x27;t believe my ears.<p>I feel like learning modern assembly would be more useful, but maybe 6502 assembly is far easier to pick up? The first language I learned was Atari BASIC around 1991, and it was enough to get me to keep on moving to better languages and more powerful CPUs, but I wonder where I would have ended up if I learned assembly either before or after Atari BASIC. I try to keep up with technology, and have read quite a bit on different assembly dialects. I still haven&#x27;t learned an assembly that I can program in, and I suppose it&#x27;s because there are so many other high-level languages now and I feel like I need to keep up to what is used in &quot;industry&quot; rather than what is more obscure (but might help in debugging).

My first program was 6800 Machine Language. My second, was 6502 (VIC-20), my first ASM was 8085. With that, I actually wrote an embedded OS. The byte order seemed strange to me, after the Motorola chips. Also, the two-part memory addressing.<p>Eventually, I ended up doing ASM with 68000 (Mac Plus), but by then, I was well on my way with higher-level languages.<p>Starting from Machine Language helped me <i>a lot</i> in understanding some of the more fundamental concepts of software. It was also an excellent troubleshooting teacher, which has probably been the most valuable software development skill I have.<p>These days, though, with the current complexity of CPUs, I don’t think it would be reasonable to start folks off with assembly&#x2F;machine languages, anymore. I’m not sure that “retro” CPUs would really represent some of the difficulties experienced with highly parallel processors. I would worry that it might encourage an “idealized” view of the underlying architecture.

In addition to be a good starting point for programming, the 8-bit micros are also a good way to begin learning about the hardware side of microprocessor systems, since the external stuff (memory chips, etc.) was correspondingly simpler as well. And without pipelining, you can form a more straightforward mental model of what the system is actually doing.<p>For me, it was Z80, just because Radio Shack had a book on it. I never actually built or programmed a Z80 system, but I still fall back on that knowledge when working with microcontrollers.

The hairy part the 6502 instruction set is Subtract With Carry, and the confusion about how the carry flag works as a result of subtracting or comparing.<p>SBC is implemented by adding the ones-complement (XOR FF) of the number or register. And the carry flag is backwards compared to other architectures, such as the Z80. On input, Carry Set means that you <i>don&#x27;t</i> want an additional one subtracted, and Carry Clear means you <i>do</i> want an additional one subtracted. Then on output, Carry Set means that <i>no borrow</i> took place, and Carry Clear means that <i>borrow</i> took place. When borrow takes place, you get an additional one subtracted, and that lets you chain the low bytes up to the high bytes and subtract bigger numbers.<p>CMP is like SBC, except it always adds the extra one whether your input carry is set or not, making it act like you&#x27;d expect comparison to act.

Why not learn a language intended for didactic use?<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MMIX" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MMIX</a><p>has a quite deep corpus and what looks to be a good introduction:<p><a href="https:&#x2F;&#x2F;www.mmix.cs.hm.edu&#x2F;getstarted.html" rel="nofollow">https:&#x2F;&#x2F;www.mmix.cs.hm.edu&#x2F;getstarted.html</a><p>(and I say that as a person who owns a much battered copy of Inman &amp; Inman&#x27;s _Apple Machine Language_)

This may be an unpopular opinion but I think Knuth&#x27;s MMIX is ideal as an initial introduction to ASM these days.<p>It is Purpose built, load-store etc...<p><a href="https:&#x2F;&#x2F;mmix.cs.hm.edu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mmix.cs.hm.edu&#x2F;</a><p>You can use the simplified MMIX-SIM<p>Then you can move to typical RISC features like full pipeline, cache, etc...<p>Then you can move to actual hardware etc..<p>But I am probably bitter, I learned on a Heathkit ET 3400, and I find that a lot of the quirks of the 6800 are something I had to get around to understand modern processors.<p>MMIX may not be &#x27;useful&#x27; for real applications, but being intentionally free of those quirks is very useful for understanding the core concepts, at least for the few people I have had try it.

I started by reading disassembled real-mode x86 code. Not bad, not great. The thing that took me the longest to “get” was how much was implicitly coded into each instruction. Once I figured out how the accumulator worked, plus the way the flags influenced jump instructions, I found over time that most other architectures are more similar than they are different.

The 6502 was a great CPU for its time and price point. I wrote many programs in its assembly language. However, if you&#x27;re going to work on <i>modern</i> systems, there are too many differences for the 6502 to be a good first assembly language (unless the 6502 <i>is</i> your focus).<p>The 6502 was designed to be easily implemented with relatively few transistors. For that it was amazing. There is a <i>reason</i> it was popular! But its CPU registers are only 8-bit, its call stack is 256 bytes, and for real work you need to use the zero page (zpage) well. None of these are likely to relevant to a modern software developer using assembly. Its design encourages the use of global locations, again, an approach that don&#x27;t make sense on modern systems.<p>I say this as someone who <i>admires</i> what the 6502 was able to achieve in its time, and I even have a long-running page dedicated to the 6502: <a href="https:&#x2F;&#x2F;dwheeler.com&#x2F;6502&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dwheeler.com&#x2F;6502&#x2F;</a><p>If you want <i>retro</i> and <i>easy</i>, the 68000 has it beat in terms of simplicity of development. The 68K is quite regular &amp; a little more like modern systems (sort of).<p>However, I think starting retro is often a disservice. Most the time the <i>reason</i> to use assembly is performance. If you&#x27;re running code on chips more than a dollar or so, getting performance out of modern architectures is <i>MUCH</i> different than retro computers. For example, today a <i>lot</i> depends on memory cache latency, yet is typically not a serious concern on most retro computers. So learners will learn to focus on the wrong problems.<p>If you want a modern simple architecture, may I suggest RISC V? That&#x27;s under a royalty-free open source license, and real computers use it today. It&#x27;s pretty simple (your basic load-store architecture) and you can pick only the modules you care about. Full disclosure: I work for the Linux Foundation, but I&#x27;d say that anyway.<p>Plausible alternatives are ARM and x86. If you subset them, they&#x27;re okay.<p>The reality is that assembly languages reflect the underlying system, and that <i>will</i> change over time.

I do not know. I learned it when I was 12, but it was quite challenging for me. Pros: It is very ortagonal, has no memory-to-memory instructions<p>Zero page is like a having 256 generic RISC registers (a bit faster than accessing to other memory areas).<p>Very easy to understand how the assembly is micro-coded<p>Cons:<p>It is impossible to create a &quot;generic&quot; memory pointer with an index &gt;255 without auto-modifying code.<p>It is a true 8bit only system and cannot manipulate 16bit word easily Steve Wozniac created a small VM just to manage 16 bit Integers (see the his Byte magazine articles).<p>Too much addressing mode.<p>So I like 6502, but I disagree a bit.

The S in RISC does not stand for simple. What the? If someone&#x27;s going to write about assembly programming, they should at least know what CISC and RISK are.<p>I&#x27;m not saying 6502 assembly can&#x27;t be an interesting endeavor, but it&#x27;s a bit restrictive for a first language. Maybe if you already know some low-level programming like C. But it&#x27;s still easier to do things with a few more registers. And it&#x27;s not like you have to use every register and instruction available on the CPU to write some assembly.

It&#x27;s also a fun one to write an emulator for. There are plenty of example programs out there to test, and they draw graphics by writing bytes to a frame buffer at some offset in memory. You can read from that region in memory, interpret each byte as a color from a preset palette, and use it to display visual output &#x2F; graphics.<p>I wrote one in Swift a few years back, and then ended up developing it further into an NES emulator capable of playing Donkey Kong. It was a great learning experience.

In university we we&#x27;re taught a version of MIPS that was implemented into a decent simulator with an IDE showing the state of memory and registers with fine grained debug stepping. Some quirks of processor pipelines (i.e. nops after branch) could be enabled for realism or turned off to make things easier for new students.<p>That was pretty great for learning assembly, I can&#x27;t comment on any other approach - no doubt there are other good options.

6502 assembly was fairly easy to learn, but it didn&#x27;t translate to being a productive assembly programmer on the Apple &#x2F;&#x2F;e I had. In particular, I wanted to do fast 2D and 3D graphics (basically what Ultima III did) to write my own games. My goal was simply to implement SetPixel(x, y, c) which turns out to be tricky because the Apple screen was 280 x 192 so you had to deal with 16-bit math. See <a href="https:&#x2F;&#x2F;nicole.express&#x2F;2024&#x2F;phasing-in-and-out-of-existence.html" rel="nofollow">https:&#x2F;&#x2F;nicole.express&#x2F;2024&#x2F;phasing-in-and-out-of-existence....</a> for the weird nature of the Apple HIRES graphics mode, and <a href="https:&#x2F;&#x2F;github.com&#x2F;fadden&#x2F;fdraw&#x2F;blob&#x2F;master&#x2F;docs&#x2F;manual.md#nutshell">https:&#x2F;&#x2F;github.com&#x2F;fadden&#x2F;fdraw&#x2F;blob&#x2F;master&#x2F;docs&#x2F;manual.md#n...</a> for a project that implements fast drawing on the Apple today.

What is a &quot;good&quot; assembly language? The best I&#x27;ve ever seen was the VAX instruction set. The second best, probably m68k. These were big, CISC CPUs that were as nice as possible to program in assembly language.<p>The 6502 wasn&#x27;t. Everything about the 6502 was &quot;do more with less&quot; and you had to be really clever to eke out performance on it. But that&#x27;s a good thing! A clean, big CISC architecture like the former ones is also a good compiler target. The 6502 was deeply weird, but programming it in assembly was <i>necessary</i> to get it to fly. That&#x27;s an era. If you want to relive that era, then go for it. It&#x27;s much more quirkily fun that, say, the 8080 (the Z80 is another beast, though backwards compatible) and much more mainstream than the otherwise better 6809, all of which are also from the &quot;assembly language required for performance&quot; era.

I program in 6502 assembly all day. It&#x27;s certainly lovely as beginning assembly languages go, though it can also be limiting. The addressing modes encourage using the &quot;Zero Page&quot; (the memory from $0000 - $00FF) as something of an extended register set, which basically means you can have up to 128 pointers if you really want them, and lots of quick-access scratch space. If you&#x27;re used to other ISAs with lots of in-CPU registers, the first thing to do is allocate about 16 bytes of &quot;scratch&quot; space on zeropage and use those instead. I call mine R0 - R15. Once that clicks, the rest falls into place.<p>Problems with the ISA become obvious the moment you want to scale your program beyond toy complexity. The stack is absurdly tiny, and trying to use it as a calling convention quickly becomes both a performance and a nesting depth bottleneck. I work around this for my larger projects by using zeropage scratch as a sortof manually-managed local scope for routines, but it requires carefully tracking which otherwise global bytes my programs are using at various nesting levels. Recursion is off the table both with this technique (difficult to manage) and with the stack (256 bytes will be exhausted very quickly). The C compilers I&#x27;m aware of work around this (slowly!) by using a separate software stack for arguments to functions.<p>It&#x27;s pretty fun though! I&#x27;m working on a full modern indie game for the NES, which is 100% programmed in 6502 assembly for performance reasons. The existing C toolchains for the NES are either very slow (cc65) or not yet mature (llvm-mos). Most of the true complexity in the project is algorithmic stuff, like resource allocation and deciding how much work to do on a given frame. The 6502 ISA is a bit slower to write than higher level code, but it&#x27;s not really a major limiter now that I&#x27;ve got my process down.<p>Here&#x27;s that game if you&#x27;re interested: <a href="https:&#x2F;&#x2F;zeta0134.itch.io&#x2F;tactus" rel="nofollow">https:&#x2F;&#x2F;zeta0134.itch.io&#x2F;tactus</a>

I got into 6502 assembly when trying to do bit manipulations on an Apple IIc back in the day.<p>The problem was that Applesoft basic set the high bit on data going out a serial or parallel port which was a problem for printing and sending data out through a modem. So if you wanted to keep the high bit one had to use 6502 assembly.

Was the KIM-1 the first 6502 computer? I&#x27;m not sure.<p>In any event, try out the KIM-1 simulator if you want to use your 6502 coding skills: <a href="https:&#x2F;&#x2F;maksimkorzh.github.io&#x2F;KIM-1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;maksimkorzh.github.io&#x2F;KIM-1&#x2F;</a>

It really isn&#x27;t.<p>Biggest issue is that register width is half of pointer width, so for arbitrary pointers you at least need to make a trip through the zero page.<p>That fact alone really obfuscates a lot of what you&#x27;re trying to teach as a first stab in assembly.<p>I say this as someone who has a whole lesson plan in 6502 asm.

The difference between A and D in the 68000 was sometimes bothersome. I think riscv is cleaner to think about.<p>That said, I loved the zero page on the 6502...

I have mixed feelings here. On the one hand yes. It’s a good introduction because the simple patterns and instructions mean you can only do X a specific way. But when you start to write real programs, especially from a mindset of a programmer from the post 2010 times its starts to feel weird because the patterns become harder to grasp. So I‘m not 100% sure myself here. I love the 6502 and the instruction set. But on the other hand I feel that basic c and unoptimized assembly give you a more real live introduction to assembly? The issue is that it’s hard to judge for someone who already got introduced and grasps the concepts.

Every time I have tried to learn assembly, I&#x27;ve gotten frustrated with an overwhelming urge to try and automate it.<p>I end up having to talk myself down like &quot;no, we&#x27;re here to learn, not to create another language&quot;

+1 for <a href="https:&#x2F;&#x2F;skilldrick.github.io&#x2F;easy6502&#x2F;" rel="nofollow">https:&#x2F;&#x2F;skilldrick.github.io&#x2F;easy6502&#x2F;</a><p>You can go through that in one pleasant sitting.

I think that the first question to ask oneself is &quot;why do you want to learn assembly language?&quot;<p>If you want to learn to write programs in assembly language or to debug disassembly of programs written in higher languages, then learn the language for the platform that you want to target. This also covers the &quot;I want to write&#x2F;understand retro stuff&quot; case.<p>If you want to understand how high-level programs are compiled into assembly language, then read Aho[1].<p>If you want to understand how algorithms are implemented in assembly, read Knuth[2]. Knuth invented a hypothetical computer &quot;MIX&quot; with its own assembly level instruction set and I believe that MIX has actually been implemented in software several times.<p>If you just want to play a little bit with assembly, &quot;dipping your toes in the water&quot;, then I agree with the OP that 6502 is simple and easy to learn, but it is not practical for many modern use cases and has sharp edges.<p>[1] &quot;Compilers - Principles, Techniques and Tools&quot;, by Alfred V. Aho et al. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Compilers:_Principles,_Techniques,_and_Tools" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Compilers:_Principles,_Techniq...</a><p>[2] &quot;The Art of Computer Programming&quot;, Volume 1, by Donald Knuth, Section 1.3 &quot;MIX&quot; (p. 124 in the 3rd edition) <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Art_of_Computer_Programming" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Art_of_Computer_Programmin...</a>

Strong disagree. The RV32E subset of the RISC-V spec is even simpler than 6502 and has good modern support in cheap microcontrollers (CH32V003 etcetera) and widely available simulators.

6502 was my fist assembly language, it’s good from the point of view of learning basics like carry flags and how to do multi byte maths, that’s about all.<p>If I was to think of the most approachable assembler it would be the ARM assembler for the original ARM2. A real thing of beauty. Which is not what anyone would normally say about any assembly language! I remember going from ARM to MIPS and being utterly horrified by its ugliness compared to ARM!

Biased here (it was my first language period), but I agree. Simple addressing modes. Getting started with x86 seems like it would warp the thinking a little bit, you can always pick its peculiarities up later.<p>Having worked with the 6809 series as well, it wouldn&#x27;t be a bad choice either. The Freescale 68HC12 is still in production. Little systems with limited-yet-real I&#x2F;O give the programmer very useful feedback.

I wrote some 6502 as my final project for school (An NES game, so a specific environment) and I found it fun and extremely challenging. I&#x27;m sure there is a lot to be said for writing ASM in a modern context, but I think it&#x27;s a good exercise in learning. One of the benefits you get out of working with an 8-bit processor is dealing with data bigger than 8-bits.

I learned some 6502 last year in service of NES ROM Hacking. If you&#x27;re interested in doing the same, NesHacker&#x27;s Final Fantasy guide was instrumental in getting me started: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=HLzEhyvHBos" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=HLzEhyvHBos</a>

This discussion contains well argued points about the 6502 vs other instruction sets. Does anyone know of resources&#x2F;books that I could read that would help me have a more informed opinion on the pros&#x2F;cons of each instruction set?

My take is that any instruction set that has &quot;centralized&quot; instruction flags is an obsolete design, as it creates dependencies between instructions that could be otherwise executed out of order. So neither 6502 or 68000 is ideal.

6502 is a bit limited, so you&#x27;d have to resort to self-modifying code to get things done — and self-modifying code is a big no-no on any processor with cache, and therefore not a good habit to acquire.<p>For teaching, I would instead go with RISC-V. In particular RISC-V with the bitmanip extensions, which make some things much easier and gives it feature-parity with the base set on x86 and ARM. The Raspberry Pico 2 has two RISC-V CPUs with those. The board is easy to use, widely available and has a lot of support. There are also alternative boards with the same MCU but other form factors and features.

When I learned assembly at university, we were required to learn Intel 8086. I remember hating every second of it, because it was so useless.<p>Around the same timey I had to learn AVR8 family assembly (for ATMega328P) which was a joy in comparison.<p>I don&#x27;t think AVR assembly is any better or easier then 16bit Intel, but just the fact that it&#x27;s a usable and actually triable thing makes a world of difference.<p>I guess what i&#x27;m trying to say is that you shouldn&#x27;t underestimate the importance of learning something useful instead of something antiquated, even when it is not the simplest thing to do.

Unlike the author, I always found the Z80 to be far more simple and sane than the 6502.<p>Also, for me the excellent 68000 instruction set was design wise far more a continuation of the clean Z80 style than the messy 6502.

6502 is a good start. But IMO, ARM assembly is where it’s at as a starting point. Much more useful and it spans so many vendors and classes of devices. It’s not harder than 6502 IMO.

The best beginner assembly hands down is Z80. It may be a bit harder to start with, but if I could write games in it at 14 years old, an adult should have no issue at all.

The important thing to consider is WHY you want to learn assembly language.<p>I learned M68K in a college class in 1995. When I saw x86 asm 2 years later it looked like a mess. But I&#x27;ve never needed to write asm for a job.<p>I&#x27;m thinking about learning 6502 because my first computer (Atari 800) and first dedicated game console (original Nintendo NES) both used the 6502 and it would be fun to write games for them when I retire.

What about the modern 68K subset still manufactured as Coldfire? Much more orthogonal, modern (as of the 1980s) architecture.<p>On the other hand, the cleaner, more modern architectures are easily targeted by compilers. If you really want to live the &quot;assembly language required for performance&quot; era, the 6502 is fine. Equally quirky is MCS-51. I&#x27;ve written nontrivial assembly language projects for both &quot;back in the day&quot;.

This is like making a big deal of the flaws of the first automobile. OF COURSE, there are more appropriate ways to teach ASM today .... its been 50 years. As designer of the first sets of computer cards (yes, way before Apple) ... the Jolt, Super Jolt, SYM-1 we sold over 75K units mostly used to teach early college students to program. Ray Holt FirstMicroprocessor. com

I learned 6502 as a teenager in the 70s (after learning 6800 first). When 68k came along, I immediately recognized it was a superior architecture.<p>Nevertheless, when I went to teach a short intro to CPU class to high school students recently, I chose the venerable 6502 for programming. Why? Because performing the 8-bit arithmetic and performing hand assembly are all very manageable on the 6502. Any 8-bit CPU would do, frankly, but the connection between 6502 and early microcomputer history is intriguing (and I was familiar with it).<p>Everyone here is talking about how there are better assembly languages to learn first, but I wonder how many of them are practical for hand assembly. I still maintain that learning (and debugging software for) any CPU architecture beyond the 6502 was easy because of the skills I learned as a teenager, hand assembling 6502 code. That experience put me miles ahead of my colleagues who didn&#x27;t have that experience when it came to working with low-level coding in the decades to follow.

I first went deep on programming learning Z80 assembly for my TI-83. It has a lot of idiosyncracies, such as 8-bit registers that can be combined for 16-bit operations. But it was a lot of fun learning from tutorials and from reading other people&#x27;s code. It put me way ahead when I got to college, as I had already learned a lot about computer architecture.

I always advocate for people to learn 6502 because it&#x27;s easy and small. Not because they are going to write assembly but because they should have a basic idea of what their code is going to turn into. It doesn&#x27;t matter if someone writes in Rust, Java, .Net, Python, Lua or C, it&#x27;s all mov and cmp at the end of the day.

Having programmed the 6502 and struggled with 8-bit arithmetic, I can only say that I don&#x27;t believe it is a good first language at all. 32-bit ARM2 was so much more intuitive, where each and every instruction could be conditionally executed and there were 12? general purpose 32 bit registers in user mode.

6502 was my first assembly, though we didn&#x27;t have an assembler - we entered raw opcodes into the Epyx FastLoad monitor on the C64. You kids with your symbol tables and your fancy mnemonics.<p>a9 01 8d 20 d0 a9 93 20 d2 ff ...<p>When we got a KIM-1, we were able to write meaningful programs on it in a weekend, since we already had memorized all the hex.

I agree with the article. The 6502 was the first CPU I wrote a lot of machine code for both on the Acorn Atom, where the Basic had a buildin assembler, and the Atari XL-800, for which some roommates and I programmed a compiler in Basic and next made it self hosted.

i have to agree with a lot of sibling comments: i don&#x27;t think 6502 is a good pick. first, it&#x27;s highly atypical and limited. second, it&#x27;s borderline RISC and i&#x27;d start with a simpler to use CISC ISA. CISC makes sense and was designed exactly for hand-written assembler.<p>VAX or 68K would be cleaner CISC ISA to learn first.<p>8086 (16 bit) x86 has the advantage of being ubiquitous and you can run on &quot;hardware&quot; everywhere. but the disadvantage of being a little weird wrt. segment registers. x86 32-bit is complicated, but at least flat memory space and you can mostly ignore the segments.<p>MIPS or one of the RISC-V variants is a second one to learn to contrast RISC load&#x2F;store with CSIC.

I&#x27;m curious what people&#x27;s thoughts are on the 65816 (used by the SNES) instead of the 6502 (the NES instruction set).<p>Is this author arguing the 6502 is preferable because it&#x27;s simpler? Or because there are more&#x2F;better resources for learning?

What about the 6809 processor? I believe this was even simpler, it was very consistent.

The accumulator A is your mouth with 8 teeth, that can bite and chew and taste, the status register is your tongue, and the X and Y registers are your hands, that can help you shove stuff into your mouth and spit it out.

Personally I learned with 8086&#x2F;8088 via MikeOS [1] (written in NASM). Highly recommended.<p>[1] <a href="https:&#x2F;&#x2F;mikeos.sourceforge.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mikeos.sourceforge.net&#x2F;</a>

I would say that the 6809 is a better first assembly language of that era. (I keep hearing references to 68xxx, but the 6809 is closer.)

If you want a really accessible intro to assembly. Try playing TIS-100 or ShemzenIO. Those games give you a really good taste of the concepts.

Z80 was what I cut my teeth on. No idea if it&#x27;s &#x27;good&#x27;, but it made sense and didn&#x27;t particular weird at the time

NES emulator. Super nice exercise for the brave.

Serious question:<p>What is the best platform to learn assembly on and where do I start? Books, videos, building my own computer, etc?

I would like to mention stack machines, particularly of Chuck&#x27;s MISC type. I still have my Novix board somewhere.

Chip8 was really good too, and it gets your feet wet with some VM programming

It certainly was for me. I learned how to build Forth on my Commodore.

Nah, Z80 is sooo much better, lets discuss on the playground. :)

Makes more sense to learn an IR nowadays. Or WASM.

I liked the 8051 :)

&gt; modern RISC architectures such as ARM, MIPS or RISC-V. At some point, a serious assembly programmer should definitely learn some of them.<p>Yes.<p>&gt; However, they are not ideal to start with: the “S” in RISC stands for “simple”, but the simplicity is more about internal implementation of the chips than the instruction set.<p>That is in fact a much better description of the 6502, which is not even a RISC but rather something almost prehistoric, where you figure out how much circuitry you could fit on a chip (or board) and then figured out what instruction set you could fit to that hardware.<p>Note that 6502 was the first machine code I learned as a 17 year old in 1980, after I got bored with BASIC after two days. I learned z80 on a ZX81 the year after and PDP-11 the same year. VAX in 1982, 6809 in 1983, and 68000 in 1984.<p>&gt; Modern microprocessors are almost exclusively programmed with high-level languages and the direct usage of assembly instruction is not high on the list of priorities for CPU designers nowadays.<p>That&#x27;s just absolutely not true.<p>They might be in some way &quot;harder&quot; than a CISC instruction set such as VAX but any of the above are far simpler to program than 6502, especially the base RISC-V RV32I instruction set.<p>&gt; To illustrate this point, loading a 64-bit constant to a register on ARM64 can take 4 instructions with bit shifting.<p>Whereas you can&#x27;t do it at all on a 6502! Loading a 64 bit constant into 8 zero page locations takes 16 instructions and 32 bytes of code on a 6502.<p>Let&#x27;s not even talk about adding or comparing or multiplying two such values.<p>The GNU assembler for ARM64 doesn&#x27;t help you out, but on RISC-V you can just type ...<p><pre><code> li x10,0xfedcba9876543210 </code></pre> ... and the assembler will generate the multiple instructions for you.

AVR-8 for the win. AVR-8 is highly orthogonal and has a whopping huge 32 register file. Devices like<p><a href="https:&#x2F;&#x2F;store.arduino.cc&#x2F;products&#x2F;arduino-uno-rev3" rel="nofollow">https:&#x2F;&#x2F;store.arduino.cc&#x2F;products&#x2F;arduino-uno-rev3</a><p>are affordable and have good tooling. Memory capacity is tiny but it is fast, andthere is a lot of I&#x2F;O, you can even write console programs that use the serial ports or better, programs that do physical things and also communicate over the serial ports -- in some ways AVR-8 boards are <i>more</i> capable than conventional computers, phones, etc. So far as I can tell, AVR-8 was the <i>last</i> 8-bit architecture, if it has a real weakness it is that, compared to other microcontrollers, it&#x27;s a dead end because you&#x27;re going to upgrade to ESP-32 or ARM if you need more.<p>The 6052 has more registers than the PDP-8 but just barely. Writing compilers for the 6052 is difficult because there just aren&#x27;t enough registers not to mind a limited set of addressing modes. If you want to do anything interesting with the 6502 you are likely to use virtual machine [1] techniques such as Wozniak&#x27;s SWEET16 or the atrocious UCSD p-System [3] or Infocom&#x27;s Z Machine [4]. That kind of stuff is really fun, but so is writing straightforward AVR-8 code.<p>I have fond memories of the 6809 which supported really advanced software engineering techniques at the time [5] but if I had to pick a classic 8-bit architecture that is easy to find hardware for today it would have to be the Z-80, or the successor eZ80, which I think the only 24 bit micro that didn&#x27;t suck (had real 24 bit index registers!) Boards are available [6]<p>[1] as in &#x27;Java Virtual Machine&#x27;, not &#x27;VM&#x2F;CMS&#x27;<p>[2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SWEET16" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SWEET16</a><p>[3] <a href="http:&#x2F;&#x2F;pascal.hansotten.com&#x2F;ucsd-p-system&#x2F;" rel="nofollow">http:&#x2F;&#x2F;pascal.hansotten.com&#x2F;ucsd-p-system&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Z-machine" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Z-machine</a><p>[5] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;OS-9" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;OS-9</a><p>[6] <a href="https:&#x2F;&#x2F;www.olimex.com&#x2F;Products&#x2F;Retro-Computers&#x2F;AgonLight2&#x2F;open-source-hardware" rel="nofollow">https:&#x2F;&#x2F;www.olimex.com&#x2F;Products&#x2F;Retro-Computers&#x2F;AgonLight2&#x2F;o...</a>

&gt; the “S” in RISC stands for “simple”<p>TIL

Nope. Too many quirks. 68k or if you must do 8-bit 6809.

The 6502 was the first cpu that I programmed in machine code - on my Vic-20 and BBC Micros at school in the 80s. Later I wrote some code for the 6809. And later still I used 68000 dev boards as an undergraduate.<p>Its been a while now, but I remember feeling that the 68k was clearly powerful and elegant and a proper cpu, but also that I had little hope of understanding all the details. The 6502 was my first, and with hindsight was far less elegant with plenty of warts, but I felt at the time that I understood it pretty well. The 6802 was somewhere inbetween, I guess, and a very nice cpu to work with<p>I&#x27;ve never thought about it before, but I suppose I benefited from that progression 6502-&gt;6809-&gt;68k. Whether or not it makes sense now, I couldn&#x27;t say.<p>(Never got on with the Z80. That brash upstart &#x2F;s)