You are taking these ideas into crazy places! Fun to think about. Given this context, I have a few thoughts: Contemporary processors may be interesting when

You are taking these ideas into crazy places! Fun to think about. Given this context, I have a few thoughts: Contemporary processors may be interesting when simplified some. Your projects make me think about the Zachtronics games. http://www.zachtronics.com/tis-100/ http://www.zachtronics.com/tis-100/ That is an assembly language game with surprising depth. People, who play it seriously will learn quite a lot. Using older hardware in tandem with current is a lot of fun. The terminal, for example, still does exactly what it was designed to do and is still useful today. A C64 has a user port for this kind of thing. Apple 2 computers saw all manner of expansion cards capable of data capture, control, computation... making ones own card with a PIA was a standard type project, just as connecting a circuit to the user port was. BASIC was often enough for many basic controls, say regulating temperature, or turning things off and on based on time, or other data states, assembly language brought more of the speed possible, and with more speed, we get more posibilities. Take one bit wired to a speaker. That is what the Apple and IBM PC shipped with to make sound. The PC had a spiffy timer to bang out notes, and the Apple had nothing but a toggle. Speaker on, or off. Here is where the fun part was back in the day: At first, it seems useless. Access an address and the speaker pops out. Do it again, and the speaker pops in. One can type this right into the computer with a BASIC POKE statement, or the monitor by address and watch the speaker change states. A loop gets one some clicks rapidly, or maybe a buzz, depending. But in assembly language a lot more is on the table! Suddenly one realizes it is possible to turn the speaker on or off long before it has reached the other state. There are lots of other realizations, such as what a read modify, write instruction does compared to one that does a single read or write. There are any number of simple, seemingly shallow examples out there, racing the beam, making sounds, cramming more onto a floppy, and so on. But what happens when the hardware is simple, driven by software gets right at the heart of assembly language, in my view. Hardware may be designed to do something, and if designed reasonably, will do that thing. But, where it may be simple, or over engineered, has bugs, whatever, all suggest more, and as time passed we saw people get far more out of a lot of hardware than intended. Demoscene comes to mind here. Maybe four thoughts! You should definitely take a look at this guy: https://m.youtube.com/watch?v=jmTwlEh8L7g https://m.youtube.com/watch?v=jmTwlEh8L7g Here is the assembly programmer mindset modeled well. People generally approach it wanting to get more out of their hardware, or understand what is really happening better, or to help them with subtle program errors. Some do it for fun too. This work suggests the ideas evolved during early computing, hacking on hardware, exploiting bugs, design choices, and more continue to play out on modern processors and systems just fine. Keys to the kingdom for those willing to play.