alt Hacker NewsI am this very term teaching 18-year-old students 6502 assembly programming using an emulated Apple II Plus. They've had intro to Python, data structures, and OO programming courses using a modern programming environment.
Now, they are programming a chip from the seventies using an editor/assembler that was written in 1983 and has a line editor, not a full-screen one.
We had a total of 10 hours of class + lab where I taught them about assembly language and told them about the registers, instructions, and addressing modes of the chip, memory map and monitor routines of the Apple, and after that we went and wrote a few programs together, mostly using the low-resolution graphics mode (40x40): a drawing program, a bouncing ball, culminating in hand-rolled sprites with simple collision detection.
Their assignment is to write a simple program (I suggested a low-res game like Snake or Tetris but they can do whatever they want provided they tell me about it and I okay it), demo their program, and then explain to the class how it works.
At first they hated the line editor. But then a very interesting thing happened. They started thinking about their code before writing it. Planning. Discussing things in advance. Everything we told them they should do before coding in previous classes, but they didn't do because a powerful editor was right there so why not use it?...
And then they started to get used to the line editor. They told me they didn't need to really see the code on the screen, it was in their head.
They will of course go back to modern tools after class is finished, but I think it's good for them to have this kind of experience.
Replies
I took several classes along these lines in college; one writing a rudimentary OS on bare metal 68k asm, wiring up peripherals on breadboards, etc. Creating an ALU using only 74 series logic chips and the like. This was 30y ago, but the 1970s chips were already antiques, but the lessons were timeless. I'm happy courses like this still exist and I wish everyone had an opportunity to take them as part of standard computer science curriculum. For me at least, they fundamentally shaped my perspective of computing machinery that I never would have experienced otherwise.
Today I program 6502/7 asm for my Atari to help me unwind and it grounds me and gives me joy, while in my day job I'm easily 10 levels of abstractions higher.
I had a similar experience recently coding a wordle clone on and for a Psion 3a (an early 90s palmtop pc) the screen only shows a few lines of code, and the built in ide is little more than a text editor. I really enjoyed the process
thank you for picking an enjoyable architecture!
scaring people away w x86 cruft right out the gate is no good for anyone :-)
>> Ed is for those who can remember what they are working on.
https://www.gnu.org/fun/jokes/ed-msg.html
My first job out of university I was taught how to use a line editor in IBM UniData. It was interesting getting used to writing code that way.
But it was an amazing day when I discovered that the "program table" was just a directory on the server I could mount over FTP and use Notepad++.
My first real program was a UVEPROM copier. It was written in MC6800 Machine Code, and we had 256 bytes (not kilobytes) of RAM for everything; including the code. That was in 1983.
I am currently working in Swift, with an LLM, on a fairly good-sized app, in Xcode, for a device that probably has a minimum of 64 GB of storage, and 8 GB of RAM.
I don’t really miss the good ol’ days, to be honest. I’m having a blast.
I love all of this, but at least let your students use vi, it was around back then (or close). plus they don’t have to give it up when they go back in the real world, it’s an evergreen skill!
Is this course online available? Sounds like great fun.
still remember my assembly class with HC11 20 yrs ago: amazed by how much we can do with so little hardware.
Whoa, I didn’t know such an thing existed. What emulator do you use?
I took a very similar class 9 years ago, and it was honestly one of the most helpful things I got out of my CS degree. The low level and limited tooling taught me to think before I start writing.
I've had other people look askanse at me, but on greenfield work I tend to start with pen and graph paper. I'm not even writing pseudocode, but diagramming a loose graph with potential functions or classes and arrows interconnecting them. Obviously this can be taken too far, full waterfall planning will be a different exercise in frustration.
I find spending a few hours planning out ahead of time before opening an editor saves me tons of time actually coding. I've never had a project even loosely resemble the paper diagram, but the exercise of thinking through the general structure ahead of time makes me way more productive when it comes time to start writing code. I've tried diagramming and scaffolding in my editor, but then I end up actually writing code instead of big picture diagramming. Writing it on paper where I know I'll have to retype everything anyway removes the distractions of what method to use or what to name a variable.
The few times I've vibe-coded something this was super helpful, since then I can give much more concrete and focused prompts.