|
Mine was the Atari 800XL. Atari Basic hadn't PEEK and POKE as the C64 (though something similar which I can't remember right now), but some more possibilities to switch graphic modes and plot things. But I never learned how the machine worked from that, it was still magic. I tried typing in listings, but you only knew that there was a typo somewhere after you finished hundreds of lines. Finding the typo was out of the question for me. Also, it was obvious that the result of the listing, usually a game, was of much lower quality than the games I already had or could copy from friends. The reason I learned Basic was that I wanted to know how games work. They always fascinated me since I saw Space Invaders somewhere. I quickly understood, mostly with the help of more advanced friends, that you couldn't make games with Basic, it was too slow. You had to learn machine language. So that's what I eventually did, and that's how I really understood the machine down to the point where I could tell what almost every single of the roughly 40000 available bytes did. It took a long time to get there, those 8-bit machines where already quite layered in hindsight when you think about: How 6502-instruction, assembler, disk I/O, joystick input and graphical output where tucked together with what today be probably called the Atari-API was not immediately obvious and the result of 20 years of technical development, but nowhere explained for a 12 year old! My enlightment moment was this dialog with a friend: Me: "Why does this assembler program crash? Why do I have to reset? Why can't the computer handle it?", friend: "Because deep down, executing your program is also a program. If your program crashes, that program crashes.". I think that was the most profound lesson ever to me. It's programs all the way down! So, yes I know that CPUs have their own instructions and that every programming language ultimately compiles to that. But that knowledge helped me little with what I consider the next large learning steps over the decades: Learning C on x86, learning how Unix/Linux works, learning what the internet is fundamentally build up on, learning Javascript+HTML5, learning how fundamentally different asynchronous programming is if you can't assume that I/O might not respond immediately and possibly never. My favorite language today is vanilla javascript. I love the simplicity, no compiler insisting on type safety, a great UI, almost platform independent, lots of cool APIs. I think JS is as remote from Assembler as you can get. Bottom line, I think it really doesn't matter to know about machine instructions, same as it didn't matter at the time how CPUs worked on the hardware level. That still mystifies me: The 6502-equivalent of an if-clause was branch-not-equal (BNE), but how did that work in reality? What's happening on the silicone then? How can a lifeless thing make a decision? Never really understood whats beneath the turtles. |
My itch didn't stop after learning BASIC or machine code, I wanted to know what has deeper down. After reading the Zacs Z80 book, this was my next port of call and is still a damn good teaching aid on how microprocessors actually work, all the way from transistors, flip-flops, boolean logic, memory, address & data buses, timing, logical shifting, adding, multiplying etc.
It's still on my bookshelf and will probably get passed to my granddaugher if she shows any interest.
https://archive.org/details/understanding-microprocessors-ra...