I have been continuously hacking on my first computer, received in a delicate cross-Nullabor operation in 1983, the lovely little Oric-1. It’s a 6502 ‘also-ran’ victim of the 80’s 8-bit computing war, but is still .. fascinatingly .. actively hosting new software, even today.
The retro scene is alive and well, and in many small ways, flourishing. Even the obscure platforms get new device peripherals designed for them - among other things in my retro corner, I have a remote controllable Amstrad CPC6128 with an M4 card, putting it on a network .. a couple of ZX Spectrum variants with so much storage attached, the ‘why not just put every single spectrum game on it, ever’ question just hangs in the ether .. and an original C64 and Commodore monitor rig, sitting at one end of the city waiting for a LoRa/meshtastic session, to set it up, so we can chat with the other Oric/ZX Spectrum/Amstrad/etc. systems all over the place.
Anyway, I just want to point out, there is a very thriving retro scene, so learning assembly and participating in it, in your own way, is a very stimulating hobby. Even if you are a master of all the current tooling, learning the tools of the ancients will make you appreciate just how much bloat we tolerate, needlessly.
In any case, its often surprising where 6502/z80-like systems turn up these days, too ..
This article is less about assembly programming and more a tour de force on retro game development for the Atari ST. The author talks about using inline assembler to optimize gfx and game rendering inner loops. Oh and the author ported Doom to the Atari ST.
Some people are drawn to assembly and that’s great. Me personally, after a course in undergrad studying MIPS assembly, I learned to appreciate what all the compiler does for us and moved on!
I've always had a deep interest for it, but the more I learn about what and how compilers can do stuff, the more I'm like "Ok, better just let the compiler handle it".
It's truly wild how much a modern compiler can transform code. There are circumstances where a human can do better (mostly around SIMD optimizations) but those require you to be in situations where you doing operations on large arrays of numbers. Not extremely common in most programming (beyond maybe making totals. Which is a SIMD operation that compilers do well).
Thanks for the summary. I was lucky enough to follow VoxelST and STDOOM on Twitter, yet skipped this thread on Hacker News because imho the title doesn't sell it well. Thankfully a friend and fellow ST nerd sent it to me. Can recommend revisiting the old social posts to read about this as it happened.
Ben Eater delves into 6502 assembly with regard to his bread-board 6502 computer. I recommend anyone interested in assembly do a search (on YouTube) for his series.
I got one of his kits and assembled it while working through his YouTube series.
(I didn't, at the time, continue very far into the assembly course, but perhaps will this Winter when I am hunkered down in the Midwaste with the blizzards beating down on my home.)
I had an Atari 1040 ST and I used to love programming it in 68000 assembler mostly using K-Seka. It really felt like programming a 32 bit CPU which was amazing after the 8 bit world that preceeded it. The instruction set was very orthogonal (other than the slightly odd split between A registers and D registers). When I graduated from 68000 assembly to ARM assembly it felt like a natural progression.
Probably my best project was a FORTH system. It used direct threading so each FORTH word was a proper assembly routine. It had primitive peephole optimization too! It was all written in 68000 assembler with K-Seka.
So if you want an assembler to learn, 68000 is a great choice. However you could learn 32 bit ARM which I came to prefer and that will still run on modern systems (at least if they have been compiled with 32 bit support or on the plentiful ARM microcontrollers).
Wonderful article! Programming 68000 assembly is a joy. People are quick to dismiss CISC instruction sets because they mostly encounter x64 with its baggage of legacy, but 68k is something else.
I remember reading Lance Levanthal's 68000 book and doing some toy exercises as my first kind of non-uni assy experience; then when I got to college some IBM 360. When I finally saw x86, omg what a nightmare.
Amazing work. I am the same age às the author and also would love to tinker with old hardware. This article taught me that I can do that with emulators all the while using modern developer tools! That’s very motivating, will see if I can get started. My first computer was a PC XT 386 IIRC, maybe I can do the same kind of thing on that.
Emulators are wonderful, I got into assembly for the 6502 processor used in the NES (Nintendo Entertainment System) and it's been an absolute blast, there is something so inherently satisfying and almost zen-like in it.
I guess it would be nice to have a more entry level piece not just a more advanced stuff and a story. Still nice. But not that involved and getting into IT is more than involvement and interaction.
I want to like it but my brain is too feeble for it.
I will wait for when efficiency (as well as speed) comes from elegance in the programming language itself rather than the human mind having to cater to some fundamental archaic syntax.
The thing about assembly is, in a limited context it's not that hard to understand at all.
Value goes into register, do some math on register, compare register to immediate, etc.
The difficulty comes the more code you add. The same thing happens in nearly any language. A single file python script is easy, the complexity in a mature async python app is hard. It's easy to add some numbers and val >> stout in c++, but managing all the dependencies and build chain is hard in a million line program.
It's no different, but assembly is neat because you can isolate the complexity via inlining and just step back and tell the computer exactly what to do.
> I want to like it but my brain is too feeble for it.
That's a self-defeating attitude which you don't want to reinforce :-(
Assembly is not difficult but writing large-scale programs/systems in it is. But almost nobody does this nowadays; it is generally C & Assembly. So you need to know/understand just enough assembly to get along.
Assembly is often easier than using programming languages, it's just less convenient most of the time. x86 will make you think you're too stupid to understand because it is a disgusting malformed monster. Assembly on other architectures make the computer feel like a machine rather than a magic box.
I never programmed assembly before 2025. For some reason i started tinkering with emulated 6502 cpu (same as in apple 2) and its FUN.
In matters of weeks I managed to develop my own cpu architecture b, opcodes, wrote VM and assembler for it.
Bare metal programming with those old CPUs is WAY easier than learning new web stack IMO.
I found playing with AVR microcontrollers to be a nice intro to assembly, and it can be quite rewarding to get some physical response from your code, like a display or turning a servo. I did already have some electronics experience going in though
Tangentially related. I want to play around with Web Assembly just to try to speed up (or perhaps parallelize) my own implementation of the "ray casting" "voxel" algorithm that the author demonstrates from the old Comanche game.
Honestly, Assembly is great. It's the most closer-to-the-metal, no-nonsense, raw experience you can get. The problem is that means it's also tedious and error-prone to write, but the elegant simplicity of the abstraction is still there.
I have been continuously hacking on my first computer, received in a delicate cross-Nullabor operation in 1983, the lovely little Oric-1. It’s a 6502 ‘also-ran’ victim of the 80’s 8-bit computing war, but is still .. fascinatingly .. actively hosting new software, even today.
The retro scene is alive and well, and in many small ways, flourishing. Even the obscure platforms get new device peripherals designed for them - among other things in my retro corner, I have a remote controllable Amstrad CPC6128 with an M4 card, putting it on a network .. a couple of ZX Spectrum variants with so much storage attached, the ‘why not just put every single spectrum game on it, ever’ question just hangs in the ether .. and an original C64 and Commodore monitor rig, sitting at one end of the city waiting for a LoRa/meshtastic session, to set it up, so we can chat with the other Oric/ZX Spectrum/Amstrad/etc. systems all over the place.
Anyway, I just want to point out, there is a very thriving retro scene, so learning assembly and participating in it, in your own way, is a very stimulating hobby. Even if you are a master of all the current tooling, learning the tools of the ancients will make you appreciate just how much bloat we tolerate, needlessly.
In any case, its often surprising where 6502/z80-like systems turn up these days, too ..
[dead]
This article is less about assembly programming and more a tour de force on retro game development for the Atari ST. The author talks about using inline assembler to optimize gfx and game rendering inner loops. Oh and the author ported Doom to the Atari ST.
Some people are drawn to assembly and that’s great. Me personally, after a course in undergrad studying MIPS assembly, I learned to appreciate what all the compiler does for us and moved on!
RISC processors, especially MIPS were not designed for hand written Assembly code.
While I have manually written code for Z80, 68000, x86, and MIPS, I never bothered with MIPS outside university project assignments.
I've always had a deep interest for it, but the more I learn about what and how compilers can do stuff, the more I'm like "Ok, better just let the compiler handle it".
It's truly wild how much a modern compiler can transform code. There are circumstances where a human can do better (mostly around SIMD optimizations) but those require you to be in situations where you doing operations on large arrays of numbers. Not extremely common in most programming (beyond maybe making totals. Which is a SIMD operation that compilers do well).
Thanks for the summary. I was lucky enough to follow VoxelST and STDOOM on Twitter, yet skipped this thread on Hacker News because imho the title doesn't sell it well. Thankfully a friend and fellow ST nerd sent it to me. Can recommend revisiting the old social posts to read about this as it happened.
For me MIPS is the best ISA for “stream of consciousness” assembly, you can just write it then tidy up the register usage and pipelining after.
Ben Eater delves into 6502 assembly with regard to his bread-board 6502 computer. I recommend anyone interested in assembly do a search (on YouTube) for his series.
I got one of his kits and assembled it while working through his YouTube series.
(I didn't, at the time, continue very far into the assembly course, but perhaps will this Winter when I am hunkered down in the Midwaste with the blizzards beating down on my home.)
You might also try the Atari ST game Midwinter :)
I had an Atari 1040 ST and I used to love programming it in 68000 assembler mostly using K-Seka. It really felt like programming a 32 bit CPU which was amazing after the 8 bit world that preceeded it. The instruction set was very orthogonal (other than the slightly odd split between A registers and D registers). When I graduated from 68000 assembly to ARM assembly it felt like a natural progression.
Probably my best project was a FORTH system. It used direct threading so each FORTH word was a proper assembly routine. It had primitive peephole optimization too! It was all written in 68000 assembler with K-Seka.
So if you want an assembler to learn, 68000 is a great choice. However you could learn 32 bit ARM which I came to prefer and that will still run on modern systems (at least if they have been compiled with 32 bit support or on the plentiful ARM microcontrollers).
Wonderful article! Programming 68000 assembly is a joy. People are quick to dismiss CISC instruction sets because they mostly encounter x64 with its baggage of legacy, but 68k is something else.
I remember reading Lance Levanthal's 68000 book and doing some toy exercises as my first kind of non-uni assy experience; then when I got to college some IBM 360. When I finally saw x86, omg what a nightmare.
Amazing work. I am the same age às the author and also would love to tinker with old hardware. This article taught me that I can do that with emulators all the while using modern developer tools! That’s very motivating, will see if I can get started. My first computer was a PC XT 386 IIRC, maybe I can do the same kind of thing on that.
Emulators are wonderful, I got into assembly for the 6502 processor used in the NES (Nintendo Entertainment System) and it's been an absolute blast, there is something so inherently satisfying and almost zen-like in it.
Great work - needed to read this today to pull me out of a state of modern software engineering induced malaise.
Still enjoying this assembly
https://news.ycombinator.com/item?id=45646958
I guess it would be nice to have a more entry level piece not just a more advanced stuff and a story. Still nice. But not that involved and getting into IT is more than involvement and interaction.
Comanche ( or at least an approximation of it ) on an Atari ST - that’s quite a feat!
I want to like it but my brain is too feeble for it.
I will wait for when efficiency (as well as speed) comes from elegance in the programming language itself rather than the human mind having to cater to some fundamental archaic syntax.
The thing about assembly is, in a limited context it's not that hard to understand at all.
Value goes into register, do some math on register, compare register to immediate, etc.
The difficulty comes the more code you add. The same thing happens in nearly any language. A single file python script is easy, the complexity in a mature async python app is hard. It's easy to add some numbers and val >> stout in c++, but managing all the dependencies and build chain is hard in a million line program.
It's no different, but assembly is neat because you can isolate the complexity via inlining and just step back and tell the computer exactly what to do.
> I want to like it but my brain is too feeble for it.
That's a self-defeating attitude which you don't want to reinforce :-(
Assembly is not difficult but writing large-scale programs/systems in it is. But almost nobody does this nowadays; it is generally C & Assembly. So you need to know/understand just enough assembly to get along.
Start with Jonathan Bartlett's Programming from the Ground Up for a nice introduction - https://news.ycombinator.com/item?id=11702025 Then look at Daniel Kusswurm's and Larry Pyeatt's books. Also https://news.ycombinator.com/item?id=45782206
Assembly is often easier than using programming languages, it's just less convenient most of the time. x86 will make you think you're too stupid to understand because it is a disgusting malformed monster. Assembly on other architectures make the computer feel like a machine rather than a magic box.
Or why robots are playing DOOM now. What programming for the Atari ST in 2025 has taught me.
I’ve never worked with assembly before, but I learned a lot from this article.
I never programmed assembly before 2025. For some reason i started tinkering with emulated 6502 cpu (same as in apple 2) and its FUN. In matters of weeks I managed to develop my own cpu architecture b, opcodes, wrote VM and assembler for it.
Bare metal programming with those old CPUs is WAY easier than learning new web stack IMO.
Where would you suggest someone starts if they want to get into this stuff? Start writing an emulator? Which one would you recommend?
I found playing with AVR microcontrollers to be a nice intro to assembly, and it can be quite rewarding to get some physical response from your code, like a display or turning a servo. I did already have some electronics experience going in though
Low-Level Programming: C, Assembly, and Program Execution on Intel x86-64 Architecture by Igor Zhirkov.
A chip8 emulator
As in the article, try the hello world example in Hatari emulator.
Tangentially related. I want to play around with Web Assembly just to try to speed up (or perhaps parallelize) my own implementation of the "ray casting" "voxel" algorithm that the author demonstrates from the old Comanche game.
My straight Javascript implementation: https://github.com/EngineersNeedArt/Mooncraft2000
Honestly, Assembly is great. It's the most closer-to-the-metal, no-nonsense, raw experience you can get. The problem is that means it's also tedious and error-prone to write, but the elegant simplicity of the abstraction is still there.
Macros :)
It is a very encouraging message.
Am I the only one who won’t click on links to something on medium.com?
Replace medium.com with scribe.rip in the URL
[dead]
[flagged]