And once You think you’ve run hw to its limits there are plentiful demos and examples around to blow your mind watching what people have been able to do with these machines (often in obscure ways).
Indeed, a whole book was written about it: https://en.wikipedia.org/wiki/Racing_the_Beam
The 2600 is fascinating and fun to code for, but for asm newbies I'd recommend the C64 or NES...
The Gameboy Advance is a marvelous little platform. It runs a modified ARM7, so if you learn its machine language a lot of that knowledge will transfer into the industry. It runs at a brisk 16 MHz, which is fast enough that it can run compiled C code quite comfortably, but slow enough that performance still matters very much once you try to push the system's limits. Even if you run it in C rather than assembly (perhaps ideal for a true beginner), the whole machine is chok full of bare-metal standbys. Most of the graphics and sound hardware is memory mapped, requiring very specific bit patterns written to special addresses to tell the rest of the hardware what to do. Working with graphics requires an understanding of interrupts and synchronization. Finally, being a games system with a screen, buttons, and a speaker built in, there's a lot of projects you could build... but the easiest is to make a game! And what a blast that system is to make games for. Powerful enough to do all sorts of compelling things, but simple enough to program (even as a beginner) that you can easily have backgrounds and sprites onscreen in about a day of effort.
While the processors are simple, making non-trivial programs is hard, because the machines as a whole have lot of limitations, making programming very intricate, compared to more modern systems (say, 16-bit 80x86, but I guess even Amiga and so on).
If the target it challenge for the sake of challenge, then nothing makes those machines special, I mean, one can code directly in machine code if that's the intention :-)
We had to simulate everything, and the final project was to take the professor's Basic program and execute it correctly, and compile his other program and then execute that correctly.
That class was the absolute best thing I ever did, I learned so much in that class. It was the only class that I went to every day and took seriously, I got the only A in the class.
I had started programing back in the mid-70's by the time I got to college in 82 I had a bunch of side jobs writing code. I didn't focus too much on my college career, I was working my side programming gigs, and I was tutoring other students. That class got my attention and I loved it.
MIX was, in theory, supposed really to be the opposite: so universal/generic that you'd ignore the language and focus on the lesson. Similar to the motivation for using Scheme in SICP. Obviously times have changed :-).
Sort of the difference between putting on eyeglasses to see the world better (MIX) or putting on eyeglasses to learn about how lenses work.
Check out this assembly programming series, it's less assembly code on the Amiga to get something on screen or getting mouse/keyboard input than with highlevel languages and APIs/frameworks today:
> I think the opposite is true because those machines were built around assembly programming.
This isn't true. It was extremely simple to get something work based on that tutorial, and to move to something more complex.
Doing that on an 80s 65xx-based machine would have been significantly more difficult, because that generations had significant limits in the coprocessors (AFAIK, the C64 could play music in games, but it was a workaround; it wasn't designed to do so).
Surely Amiga is easier, as the coprocessors were significantly more capable, but the parent based the discussion on C64 development.
> While the processors are simple, making non-trivial programs is hard, because the machines as a whole have lot of limitations, making programming very intricate, compared to more modern systems (say, 16-bit 80x86, but I guess even Amiga and so on).
Programming in those time was an art. Now some people have 32 GB of RAM and they are not able to use it efficiently.
> If the target it challenge for the sake of challenge, then nothing makes those machines special, I mean, one can code directly in machine code if that's the intention :-)
I've seen OS's that at 20 MHz and 4MB RAM did things that Windows, Linux or MacOSX cannot do today with 1000 times more resources. It is really a shame.
Because that was all the processor was doing. No virtual memory, no disk, no IO, no graphics. Just feeding the DSP data on one side and NAT routing on the other.
Under the same line conditions, the PII running windows was useless running at 450Mhz. Mouse would barely respond, keyboard was lagging, screen wouldn't update.
Like you said, depending on what you are trying to achieve, you can perform near miracles on confined hardware if you have confined demands.
It's the same as learning on GW-BASIC or equivalent: You learn some bad habits due to the environment which you must unlearn the moment you move on to a real system.
The 6502 was a real system. Conversely, I'd say Visual Basic is a terrible environment and I have a few friends that made millions using it, so, not sure who gets to be the judge.
What blew my mind was using a modern C++ compiler to build optimized software for that old hardware. Here's an example with the Commodore 64 .
Hence why microcontrollers like ESP32 are much more poweful than many think of.