8 ms·

I cannot agree that the simplicity of the 6502 wins over the 68000. The 68000 has more registers and wider data types: but the registers are all uniformly the

• musicale 2y ago
  > 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 Learning to hack around the limitations of a tiny machine is a good step toward becoming a seasoned software (and possibly hardware) engineer! The advantage of tiny systems is that you can understand them completely, from silicon to OS to software. The 6809 is simpler than the 68K, and more powerful and orthogonal than the 6502, but there isn't the same software base for it. I think Motorola was onto something with the 6809 and 68K instruction sets and programmer-facing architecture. IIRC PDP-11/VAX and NS32K are similarly orthogonal.
  • russdill 2y ago
    I love the 6809 and friends, but knowing 6502 just seems so much more relevant and easier to get real hardware as well.
  • hcfman 2y ago
    Totally! I wrote an assembler once for the 6809, it was a lovely architecture.
  • DonHopkins 2y ago
    The 6809 is the Chrysler Cordoba of 8 bit microprocessors, the personal sized luxury processor with styling in timeless good taste, rich Corinthian leather, and an efficient sophisticated multiply instruction. https://youtu.be/tfKHBB4vt4c?t=9 https://youtu.be/tfKHBB4vt4c?t=9
  • groby_b 2y ago
    Came here to say that. If you must start learning with 8-bit, the 6809 is the processor of choice. (Unless you want to really dive into "how can I work around limitations", and then you pick an F8 and pull your hair as much as you like)
  • geoelectric 2y ago
    I learned assembly on a 6809 (TRS-80 CoCo) platform. It was only later that I really appreciated how cool of a CPU it really was. It’s a shame that Tandy missed the boat on including coprocessors for game support in their computers, especially that one. If they’d just included decent audio and maybe something for sprite management it would’ve been highly competitive.
    • musicale 2y ago
      Apple II had primitive graphics and sound, but was incredibly successful. Atari 800 featured powerful video processing with display lists and sprites, 4-channel audio, etc., but was much less successful. As I understand it, Radio Shack did not encourage third-party software and support for its systems, not realizing that it was the key to success. OS-9, originally a 6809 OS, seems to have survived for quite some time. https://en.wikipedia.org/wiki/OS-9 https://en.wikipedia.org/wiki/OS-9
      • geoelectric 2y ago
        Yeah, once OS-9 came out we got some decent game ports too. That’s where I discovered Epyx Rogue! It was very late in the lifespan of the system though. C64/128 was what I was thinking of more than anything re 8-bit competition, keeping in mind I’m talking mid-late 80s by this point. I do also remember Atari 800 (and later) doing considerably better than you imply. But you’re right, Apple captured the early-mid 80s gaming market nicely.
• mikepavone 2y ago
  Yeah. If you want to teach someone to implement a CPU, then the sort of simplicity the 6502 brings to the table is useful, but it's definitely not the most straightforward CPU to write code for. The 68000 instruction set is very C-like (probably because it draws a lot of inspiration from the PDP-11 which was C's first target). Implementing it sucks (I know from experience) because the ISA is on the large side and all the little pragmatic exceptions add up. But because these exceptions are fairly pragmatic, they're not really a big issue when writing code.
• zozbot234 2y ago
  6502 is a better "toy" asm than the Z80, but that's not saying much. It's not even obviously better than the AVR 8-bit insn set. As far as more modern platforms, I think there is a strong case for teaching RISC-V over something like MC68k. RISC-V can be very simple and elegant (in the base integer insn set) while still being very similar to other modern architectures like ARM, Aarch-64 and MIPS. It's also available in both 32 and 64-bit varieties, and the official documentation is very accessible. MC68k just has tons of quirks which aren't really going to be relevant in the modern day and age. (About the only thing it has going for it is the huge variety of hardware platforms that happened to make use of it, many of which still have thriving retro communities around them. But that's more of a curiosity as opposed to something genuinely relevant.)
  • adrian_b 2y ago
    Some people believe that RISC-V is simple and elegant, other people believe that RISC-V is one of the worst and ugliest instruction-set architectures that have ever been conceived. Usually the first class of people consists of people with little experience in assembly programming and the second consists of those who had experience in using multiple ISAs for assembly programming. Using RISC-V for executing programs written in high-level programming languages is fine. It should be noted that in the research papers that have coined the name RISC, where there was a list of properties defining what RISC means, one of them was that RISC ISAs were intended to be programmed exclusively in high-level languages and never in assembly language. From this point of view, RISC-V has certainly followed the original definition of the term RISC, by making the programming in assembly language difficult and error prone. On the other hand, learning assembly programming with RISC-V is a great handicap because it does not expose the programmer to some of the most fundamental features of programming in an assembly language, because RISC-V does not have even many features that existed in Zilog Z80 or in vacuum-tube computers from 70 years ago, like integer overflow detection and indexed addressing. Someone who has learned only RISC-V has an extremely incomplete image about how a normal instruction set architecture looks like. When faced with almost anyone of the several thousands of different ISAs that have been used during the last three quarters of a century a RISC-V assembly programmer will be puzzled. 6502 is also too quirky and unusual. I agree that among the old ISAs DEC PDP-11 or Motorola MC68000 are better ISAs for someone learning to program in an assembly language from scratch. Writing assembly programs for any of these 2 is much simpler than writing good assembly programs for RISC-V, where things as simple as doing a correct addition are quite difficult (by correct operation I mean an operation where any errors are handled appropriately).
• wk_end 2y ago
  The 68K is still a tiny bit awkward, with its 24-bit bus and alignment restrictions and middling support for indexing into arrays (no scale factor). The 68020 is about as close to C as an ISA can get - it’s extraordinarily pleasant.
  • adrian_b 2y ago
    While I agree that 68020 felt like a great improvement over 68000 and 68010, scaled indexed addressing is an unnecessary feature in any ISA that has good support for post-incremented and pre-decremented addressing. Scaled indexed addressing is useful in 80386 and successors only because they lack general support for addressing modes with register update, and also because they have INC/DEC instructions that are one-byte shorter than ADD/SUB, so it is preferable to add/subtract 1 to an index register, instead of adding/subtracting the operand size. Scaled indexed addressing allows the writing with a minimum number of instructions of some loops where multiple arrays are accessed, even when those arrays have elements with different sizes. When all array elements have the same size, non-scaled indexed addressing is sufficient (because you increment the index register with the common operand size, not with 1). However there are many loops where scaled index addressing is not enough for executing them with a minimum number of instructions, while using post-incremented/pre-decremented addressing still allows the minimum number of instructions (e.g. for arrays of structures or for multi-dimensional arrays). Unfortunately not even MC68020 has complete support for auto-incremented addressing modes, because besides auto-incrementing with the operand size there are cases when one needs auto-incrementing with the increment in a register, like provided by CDC 6600, IBM 801, ARM, HP PA-RISC, IBM POWER and their successors (i.e. when the increment is an array stride that is unknown at compile-time). On x86-64, using scaled indexed addressing is a necessity for efficient programs. On the other hand on ISAs like ARM, which have both scaled indexed addressing and auto-indexed addressing, it is possible to never use scaled indexed addressing without losing anything, so in such ISAs scaled indexed addressing is superfluous.
  • kazinator 2y ago
    The 24-bit bus means that you can use the top bits of a pointer as a tag. In a small system we don't need that much memory, this can actually be a great advantage. We are rediscovering the value of tag bits in 64-bit systems.
• jjav 2y ago
  6809 for me was ideal first assembly language. The 6502 was too limited.
• sippndipp 2y ago
  I've always loved the Z80 and felt home with the 68k.
• eschneider 2y ago
  6502 and 68000 are both perfectly good assembly languages, but I think the best remains PDP-11 assembly. It scans so nicely in octal. :)
  • cbm-vic-20 2y ago
    For anyone interested, learn the PDP-11 instruction set from the first model, the PDP-11/20, before DEC added protection modes, memory management hardware, etc. A summary of the instruction set is in Appendix A, and it's worth taking a look at chapters 3 and 4 of the PDP-11(/20) Handbook to get more detail on each instruction and the addressing modes. https://bitsavers.org/pdf/dec/pdp11/1120/PDP-11_Handbook_Second_Edition_1970.pdf https://bitsavers.org/pdf/dec/pdp11/1120/PDP-11_Handbook_Sec...
• crest 2y ago
  One of the downsides having learned to code close to the metal on old CPUs is that you understood how that system worked and it‘s easy to assume assembler and the resulting machine code are the truth, but on modern CPUs that‘s a lie. A modern beefy out of order CPU will do insane optimization dynamically at runtime and the instructions you carefully scheduled to avoid register spills are nothing but a suggestion to the actual hardware. sigh<
  • brucehoult 2y ago
    That was never about the instruction set, it was more about the operating system -- or lack of one. As for modern CPUs and OoO etc, that's only about performance. The CPU, no matter sophisticated, must produce exactly the same results as the simplest in-order CPU. Hardware is never going to spill a register to RAM when you didn't write that. The maximum that is going to happen -- and this is pretty recent -- is that memory at small offsets from the SP might be treated as if it was extra registers, and this renaming can be tracked over smallish adjustments to the SP. "You can't understand what modern CPUs do" is much overblown. Just write good clean code and it will work well on everything.
    • TheOtherHobbes 2y ago
      The performance is the point. 8-bit CPUs are so slow assembler could be - often had to be - hand-optimised for speed. You can't do that on modern CPUs, because the nominal ISA has a very distant relationship to what happens inside the hardware. The code you write gets optimised for you dynamically, and the machine is better at it than you are. You may as well write in a high-level language, because the combination of optimising compilers with optimising hardware is probably going to be faster than any hand-written assembler. It's certainly going to be quicker to write. The 68000 is a very nice, clean machine to code for, but the main point of doing it today is historical curiosity. It's quite distant from modern computing.
      • brucehoult 2y ago
        You can do that on modern CPUs, and I do. If you can't do it, it's simply because you haven't studied the CPUs closely enough. I write compilers, and I write critical routines by hand when compilers don't do a good job.
• giamma 2y ago
  While I learned programming with 6510, I agree that 68000 instruction set was much nicer and easier to read and learn. I would also chose 68000. This said, 65XX on an early Commodore computers was extremely rewarding to use because there was no memory protection and you could write code altering video memory, mess with sprites, fonts, borders, interrupts, write self modifying code etc etc. 68000 assembly on Amiga was more safe and controlled.
  • marssaxman 2y ago
    68000 assembly on Macintosh was the wild west, nothing protected at all, and it was so much fun.
    • renewedrebecca 2y ago
      When I was in college, they taught the Computer Architecture course using the 68000. Coded GUI stuff on the Mac 128k with assembler, and it was surprisingly easy, especially compared to doing anything with the 8086.
• Keyframe 2y ago
  I come from a similar but different angle. Have been at 6502, 68k, z80, and some x86/64 over past few decades (mostly demo). I also wonder if this article/post was written by AI - he argues for 6502 that it has 6 registers, and thus it's simple. ANYONE who ever touched 6502 for more than a week will know you're pretty much dealing with three, and that's where the nickname of a sempahore CPU comes from (three registers). 6502 is fun and neat, especially if you want to program those machines. If you want more modern approach, it's not really all that suitable. Do what we did in the 90's then and start with MIPS if you want to follow the path of glory days or just start out with Neon. I'd even argue Z80 with all its registers and complexities is more similar to what you'll find today (far from it, but let's entertain the connection between past and present as OP does). There's nothing inherently complicated about modern asm. Take FASM, start. It's not complicated, but it gets complex rather quickly which was and will be always true for such low level approach. Then you start macroing and sooner or later you have your own poor man's C on top.
  • vardump 2y ago
    6502 really has 262 registers: 256 zero page plus those standard ones mentioned. Or 260 for 6510, as zero page addresses 0 and 1 are for I/O. Practically anything non-trivial uses those zero page addresses as extra registers.
    • Keyframe 2y ago
      I get what you're saying but I wouldn't personally call zeropage bytes _registers_, even though they are physically connected to internal ones. I treat them as a special zone of memory that has special properties. There are many of these things and just like you would start with any of the old machines you'd first take a look at the memory map to see where's what and how to use it. Registers in a traditional sense would be those few mentioned of which you'd only ever really touch A, X, and Y.
      • vardump 2y ago
        > even though they are physically connected to internal ones They're not physically connected, other than through the bus. I mean, zero page is part of DRAM.
• WorldMaker 2y ago
  My school started with a 6502 lab and then followed it with a 68k lab. That still seems like the right order to me all these years later. Starting with the smaller, more cramped chip and learning its limitations makes it all the more interesting when you can "spread your wings" into the larger, more capable one. You scale up the complexity of the programs you need to build with the complexity of the chips. In the 6502 lab it was a lot about learning the basics of how things like an MMU works and building basic ones out of TTL logic gates. In the 68k lab you take an MMU for granted and do more ambitious things with that. There's useful skills both from knowing what the low level hardware is like as intimately as a 6502 can get versus the skills from where it is easier to program because you have more modern advantages and fewer limitations. The other thing about that order was that breadboarding the 6502 hardware was a lot more complex, but it made up for it in that writing and debugging 6502 assembly was a lot easier. There are a ton of useful software emulators for the 6502 and you can debug your code easily before ever testing it on lab hardware. At one point in that lab I even just wrote my own mini-6502 emulator specific to our (intended) breadboard hardware design. On the other side, there a lot fewer software emulators for the 68k and the debug cycle was a lot rougher. The 68k breadboard hardware was a bit more "off the shelf" so it was easier to find an existing emulator that matched our (intended) hardware design, but emulator itself was buggier and more painful to use and ultimately testing on the real hardware was the only trustworthy way to deal with it. I also wasn't going to try to write my own 68k emulator. (Though some of the complexity there was the realities of hardware labs in that the hardware itself starts to pick up its own localized quirks from being run only on breadboards for years.)