How much time did you take to do this, I can read code, but I simply can't casually take a look at code like this and say, hey that's cool, hey that's interesting, I have to concentrate and go line by line, a more debugging state of mind.
There are programmers that can sort of skim read code which just amazes me.
Keep in mind that a lot of this kind of code follows a pattern : lots of EQU ("equates") statements that link a variable to an address like a port or a signal line.
Then you'll have the setup code that gets everything into a basic state where it's ready to run the next part
The big loop
Here's where the action's act. Just spin in a big loop, waking up every few hundred cycles or so to check and see if a button is pressed, or the IR chip is sending a byte, or the battery is dead, etc.
If you're already doing something, keep doing it until you're done.
If you're done, wait around for a while or go do something else.
At least, that's what I come expecting. So when I see code like this that basically fits that model, parsing it is simple.
And, like I said, there are great comments. Even a couple about the round-robin service routine that made me laugh.
Well that would be the answer ...
what's funny to me is the idea that a person can go do something else for 10 or 20 years (C, C++, DotNet, robotics) and barely touch a line of assembly, yet it's all still there waiting. Maybe it's because game development in 6502asm was at the start of my career and I was so passionate about it, but some things are just ingrained. Even stuff like favoring zero-page memory (the first 256 bytes of memory from $0000 to $00FF) because it can be accessed in one cycle instead of two like indexed, offset or direct access memory. Later, moving to the 68000 family felt like a high-level language (Multiply AND divide opcodes -- you mean I don't have to write a multiply routine?)
But having a asm background has ruined me in some ways. Learning C was straightforward enough, and the jump to C++ felt very natural. However, I find modern languages repulsively inefficient (e.g. Ruby) and struggle with functional programming (Lisp, Elixir). Python feels reminiscent to Applesoft BASIC so while I have to look up the syntax every time, it still feels normal.
somewhat related, since I'm rambling...
I recently read "Making 8-bit arcade games in C" by Steven Hugg and found it brought on a strong dose of nostalgia. It's a really ambitious book that attempts to give a feel for programming various 8bit game platforms, and covers some surprisingly advanced techniques and some basic stuff that schools may not event each any longer (two's complement, run-length encoding, interrupts, etc.). The book has some rough edges and wanders a bit but the good parts easily outweigh the defects. It achieves its aim of
Speaking of game programming -- how about meta-game programming? programming in a game.
I bought a game called TIS-100, and found it to be loads of fun in the same way a mechanic might buy a derelict car and restore it to new condition, or an EE might fiddle around with an old tube radio just for fun. The premise is that an uncle dies suddenly/disappears and leaves a prototype computer behind. Hidden in this computer are some signal processing circuits that hold a secret. You (the player) are tasked with restoring this prototype military computer to unlock the knowledge held within. Very simple, only a handful of opcodes, but it's a challenge and fun in a way I haven't felt since the 80s. Being forced to juggle a variable around on the stack or between indexes or the accumulator an only having a few bytes of storage requires a different type of thinking. Good stuff.
TIS100 definitely isn't for everyone and the challenge curve gets rather steep but once I "got it" it was one of those stay-up-all-night challenges. https://store.steampowered.com/app/370360/TIS100/
great review: https://blog.codinghorror.com/heres-the-programming-game-you...
It seems assembler makes it a bit more complicated without much benefit, and surely there's a compiler for a chip as common as the 6502.
Back in the 80's and 90's the best compiled languages were probably COBAL and Forth. As far as I know nobody seriously used these for games or applications.
There are more recent C compilers, but the code generation is multiples of size and speed (5* maybe?) away from assembler.
Because it was cheap: https://groups.google.com/d/msg/comp.lang.forth/LzOasFOyIMg/... (forth not mentioned here; plausibly(?) extrapolating)
Some nearby discussion about 6502 market penetration (I can't determine whether Forth is being discussed here - oh and dodge the cartoon fistfight-cloud wending its way between the posts, happens a lot on this usenet group): https://groups.google.com/d/msg/comp.lang.forth/Yoa9u55cpbo/...
And back when this product was released, optimizing compilers were really poor by comparison with a human for these tasks.
Today you probably wouldn't bother with assembly for all but the most timing critical parts.