7 ms·
MarkeyJester’s Motorola 68000 Beginner’s Tutorial (2012)
- bahmboo 10y agoHaving written many hundreds of thousands of lines of 68K asm I can admire this for its archaeology and desire to understand how things used to work. Also, would never go back, it was painfully slow going.
- puzzle 10y agoI miss 68K coding and quite regularly wish I could be paid to do it again. The 020+ days with even crazier addressing modes was a lot of fun. x86 just doesn't cut it.
- 3chelon 10y agoI first learned Zilog Z80, and when I started programming 68k it felt like a high-level language in comparison! I too have written 100's of thousands of lines of 680x0 assembler and still get a warm nostalgic glow when I see move.l, add.w, etc!
- stuaxo 10y agoHow about ARM? The instruction set also seems quite nice.
- wolfgke 10y agoThere is no unique ARM instruction set, but three different ones that are in common use (and some additional less common ones): There are AArch32/A32, Thumb-2/T32 (Thumb for older processors) as the two common 32 bit instruction sets and AArch64/A64 as 64 bit instruction set. For example AArch64/A64 does not support no conditional execution (the encoding bits that are now available are used to encode 32 instead of 16 registers). On the other hand Thumb cannot encode many instructions that AArch32/A32 can. Thumb-2 was specifically developed to deliver instructions to provide equivalent functionality. If you want to look into details look at how UAL assembly is encoded quite differently into A32 or T32 instructions. Also for older ARM processors support for Thumb was optional (though very common). On the other hand modern 32 bit microcontroller cores of the ARMv8-M series (cf. http://www.arm.com/products/processors/instruction-set-architectures/index.php http://www.arm.com/products/processors/instruction-set-archi...) only support T32. TLDR: Of which of these common three ARM instruction sets are you talking about in your question "How about ARM?"?
- AnimalMuppet 10y agoAh, good times, good times. I mainly read 68K assembler when reading compiler output, but it was beautifully clear and understandable.
- microtherion 10y agoI think the clearest assembler code I've ever worked with was PowerPC. Moving from that to x86 when Apple transitioned to Intel was rather a shock.
- totallymike 10y agoI was just using this the other day! I'm hobbling together a Genesis/MegaDrive emulator in Rust, and also trying to wrap my head around the m68k at the same time. It's tough to find good documentation about how the cpu works, and this is a fantastic reference.
- mikepavone 10y agoThe official documentation is actually pretty decent, but it takes a while to get a feel where all the things you need are. It's complicated by the fact that the documentation is split between the 68K family programmer's manual, which has more general info about the architecture across all CPUs in the family, and the 68000/68010 user's manual, which has info specific to those implementations. Motorola's patents for the 68000 are also quite informative (see US patents 4,325,121, 4,296,469 and 4,307,445) if you're interested in the low level details of the implementation. The first of those actually contains a complete microcode/nanocode listing of a pre-release version of the CPU. For Genesis/Megadrive emulation generally, you should check out this thread [1] on SpritesMind. It contains links to other forum topics with useful info about the hardware (68K included) discovered by the community. [1] http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=2227 http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=2227
- totallymike 10y agoThis is marvelous. Thank you! I have copies of the two Motorola manuals, and they are comprehensive and quite useful. The OP is tremendously helpful as well because it's a bit higher level. Now I can flip between the manual for opcodes and the tutorial for assembler names and contextual understanding. I'm excited to dig into this thread as well. There's a lot here that looks fascinating. Particularly the microcode exploration, the reference on the sound chip, and the interrupt handling. Not to mention timing information. I haven't gotten much further in my experimentation than rudimentary execution of a few opcodes, and have mostly been floundering around trying to make the code and project feel ergonomic. I'm discovering (and expected) that there is quite a lot of stuff you want to set up early on in a project like this. Mainly debugging and other sundry tooling. I'm away from my laptop, but I'll try to post the code somewhere tomorrow.
- st3fan 10y agoThe MC68000 is wonderful. First 'big' CPU that I wrote code for. As a teenager. Cracked many games on the Mac (512KE). 0x4e71.
- asimuvPR 10y agoAnyone know where I can source the m68k with required support equipment in eastern US? Thanks.
- Taniwha 10y agoNXP's coldfire chips are a (not so) direct descendant of the original 68k CPUs
- rvense 10y agoI think there's still one or two variants of the original family available from the usual places (Mouser, etc). Then there's Coldfire, which is more modern with things like on-board peripherals and debugger support.
- gaius 10y agoEbay - plenty of Amigas and STs still around.
- 3chelon 10y agoI have a couple of DIP packages lying around, probably new. Unsure what you mean by support equipment though?
- asimuvPR 10y agoAnything required to program the chips. Its been trata since I've worked with older chips and dunno what's required.
- Taniwha 10y agoBTW there are (were) two main forms of assembler formats, the one shown above and "unix form" which is a little more terse "movl" vs. "move.l" addressing modes are also slightly different - neither is 'right', you use what your tools do
- marssaxman 10y agoAhh, I miss the 68K architecture. It made sense, unlike x86, and it was fun to use, unlike PowerPC.
- wolfgke 10y agox86 makes sense as soon as you write the opcodes in octal instead of hexadecimal: > http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt "The only proper way to understand 80x86 coding is to realize that ALL 80x86 OPCODES ARE CODED IN OCTAL. [...] For some reason absolutely everybody misses all of this, even the Intel people who wrote the reference on the 8086 (and even the 8080)."
- marssaxman 10y agoThanks for that link.
- mikepavone 10y agoTo a certain extent that's true of the 68000 too. Octal becomes convenient whenever you have a bunch of 3-bit fields. To me, the thing that's kind of gross about x86 are all the exceptions. Outside of 64-bit mode you can't do byte operations on [e]si, [e]di, [e]bp or [e]sp (though for the last of those, there is little reason you would want to). In 64-bit mode, you can do that with a REX prefix, but then you can't access the ah, bh, ch and dh. There's only one size bit in the main opcode byte so they had to add a prefix byte when they added 32-bit support and another one when they extended to 64-bit. Unsigned multiply instructions have a fixed destination register/register pair. Numerous instructions have special shorter encodings you can use for certain registers. All of this makes a lot of sense in the context of the 8086. It needed to be easy to port assembly from the 8080 and memory was incredibly limited. As a product of its time it seems like a pretty good design, but it wasn't a forward thinking design. The 68000 by contrast was a (mostly) 16-bit implementation of a 32-bit, forward-looking, ISA. It's a shame x86 survived while 68K is mostly dead.
- wolfgke 10y ago
- nprz 10y agoHa, this was my go-to resource for my computer architecture lab. It helped a ton, really great guide.
- gaius 10y agoLove the 68k. So orthogonal.