I've only got experience with the 6502 and ARM instruction sets, and they're quite similar, the ARM being a heavily upgraded (and incompatible) version of the former. You've got arithmetic operations, memory operations, and program control, and that's it. ARM added multiplication which never gets used. Oh, and a bazillion registers.

Looking at the 8086 instruction set, it's got stuff that I don't even know what to do with. String operations, right there in machine language. An operation to compare two values in memory (the extra microcode to take care of that is probably slower than loading the values to registers, then comparing). Arithmetic shifts? Probably all useful stuff if C didn't exist and you don't have a macro assembler, though. Which was pretty much true with the original IBM PC.

VAX has a million different instructions, in fact it almost looks like it was created to run UNIX. Probably not too far from the truth. It has instructions to deal with polynomials.

I come back again to asking why the Atari is so much easier to program than anything else, and I am reminded of why I was frustrated with programming the TI-84+: there's no easy way to program it on the device. Aside from Atari's assembler, Machine Language for Beginners came with a short-but-useful assembler written in BASIC, that lets you write small programs and get a feel for the processor. You can literally write a small, 6-instruction program, assemble it to a safe memory location, and execute it right there, then give control straight back to BASIC. So, let's say you want to play with the arithmetic functions, you can write a little program, save its output to memory, and then PEEK it back in BASIC.

On the TI calculators, well, you'd have to write the program on you computer, transfer it to the device, execute it, and heck I don't even know if there's an equivalent to PEEK and POKE on the thing. So you'd also have to write code that outputs your little test data to the screen in some fashion. The barrier to entry is a lot higher.

Same with coding on the DS, since it doesn't have a flexible runtime environment. You have to write quite a bit of complex code just to play with the thing. It's easier when you're piggybacking off of DevKitPro, but that obfuscates the hardware away and it's harder to see what you're actually doing.

I suspect this is also why Python is such a beginner-friendly language, since it has an interactive interpreter. You can play with functions before working them into formalized programs.

So yeah, BASIC is a pretty limited system by today's standards, but it gets the job done if you know what you're doing.

Oh, who was it that said that programmers will always adapt to use up all the available memory?

I've been doing some preliminary studies on Atari 8-bit programming. Which means I've pretty much come full circle, because the Atari 400 was really the first computer I ever "programmed." So far my studies have included:

So, with my background in Nintendo DS hacking, it's interesting to look at the features and limitations of the old 8-bit computers.

For instance, in the more common graphics modes, you have access to "playfield" graphics, 4 players, and 4 missiles. The playfield is a bitmap that fills the entire screen, if you like. That's it. Then you have the players, which are 8-pixel-wide strips spanning the entire height of the screen. Your player graphic occupies a small part of this strip, you can move the strip horizontally through a register, and to move the image vertically you rewrite it to a different portion of the strip. Player graphics are accelerated in hardware and draw quite smooth. Missiles are similar to players, except they're 2 pixels wide, and take their color from the player they're associated with (or you can switch them into a special mode where they emulate a fifth player). What's nice is that collision detection is supported in hardware for all the players, missiles, and the playfield, so you don't have to write costly collision detection code.

Now, the thing about the playfield is that it takes a lot of computational time to change it around, so you can't really animate it that much. No scrolling backgrounds, then. You're also pretty tightly limited in the amount of stuff on the screen, though you can still employ tricks like flickering one player back and forth horizontally to make it appear to be two.

It's fun to look at the existing games and try to figure out what combination of playfield, player and missile graphics were used to put it together. The older-looking games obviously use the hardware without any special tricks, and newer games definitely have more interesting stuff going on software-wise.