figuring out how to tell that to the chips directly and remember it all with hex or pokes makes my brain explode.
Memorizing those addresses is not a good use of your brainpower. I have relied on setting up constants to handle this, so then I only have to remember names of registers and use mask constants for singling out bits. Plus, doing this kind of programming means that you really need to have things like the VERA guide handy. Another good strategy is to roll common operations into macros so that doing them looks a lot more like calling a function in a high-level language then just manually copying, pasting and tweaking the same snippet of assembly over and over. Doing things like this requires putting some concerted effort in at the beginning (or just borrowing from the many open source examples from this community), but that pays off in greatly simplifying development.
Memorizing those addresses is not a good use of your brainpower. I have relied on setting up constants to handle this, so then I only have to remember names of registers and use mask constants for singling out bits. Plus, doing this kind of programming means that you really need to have things like the VERA guide handy. Another good strategy is to roll common operations into macros so that doing them looks a lot more like calling a function in a high-level language then just manually copying, pasting and tweaking the same snippet of assembly over and over. Doing things like this requires putting some concerted effort in at the beginning (or just borrowing from the many open source examples from this community), but that pays off in greatly simplifying development.
Ohhh that makes a lot of sense to me. I guess I was looking at things the wrong way then. I was watching videos like from 8-bit show and tell and just figured if Robin knew to just poke and peek stuff, or manually editing hex values in TMP to do what he needed that it must be how everybody else was doing stuff too. I never thought to build a "library" of code of sorts to refer back to based on what I needed at the time.
I never heard of Karel before clicking on that link, and it looks a lot like Logo, which was my initial introduction to programming many, many years ago on the Apple II. We started out doing very similar turtle commands to turn and move forward and backward, and put the pen up and down to draw pictures.
Yes, the concepts are similar. KAREL was designed explicitly as a teach tool, and LOGO is a little more complete... I seem to recall we did most of our KAREL exercises on paper and didn't actually run programs on a computer until halfway through the class. Hence the super light syntax and the grid - all things to make it easier to simulate on paper, rather than requiring a compuiter.
I've done a bit of programming on a very basic level before. I mostly meant the nitty gritty of the internals. It seems like all of you are super knowledgeable about pokes and peeks with specific memory addresses or telling the chips to do very specific things and I feel like I missed that class in school lol. I can understand the concept of loops, functions, variables, and such with programming, but figuring out how to tell that to the chips directly and remember it all with hex or pokes makes my brain explode.
Definitely the microcontroller - an assembler one not a 'C' one, or something like the Ben Eater 6502, where you are working at the parts level, no libraries, no high level languages in the way. Also do some basic digital electronics if you haven't done any of that.
They don't always teach the internals nowadays :(
Once you've got a handle on how processors work, you can design your own very simple processor out of logic gates .... that's about as low as you can go.
Definitely the microcontroller - an assembler one not a 'C' one, or something like the Ben Eater 6502, where you are working at the parts level, no libraries, no high level languages in the way. Also do some basic digital electronics if you haven't done any of that.
They don't always teach the internals nowadays ?
Once you've got a handle on how processors work, you can design your own very simple processor out of logic gates .... that's about as low as you can go.
This is sort of the direction I was looking for. Something that kind of bridges the gap between languages and the hardware.
This is sort of the direction I was looking for. Something that kind of bridges the gap between languages and the hardware.
The problem is nowadays they try to make it easier by writing the code in 'C' - maybe an Arduino might be a good place to start, but it's not really assembler. But there's a lot of training/example/tutorials for it, maybe have a look there first ? There's plenty of Arduino tutorials involving electronics and switching things with the Arduino and plenty of starter sets. It may not be quite what you want. It might be a place to start ?
A complete kit to build it, a book and an accompanying TV-series. Ben Eaters site reminds me a lot of this. Some enthusiasts are pursuing it again nowadays as it had become easier to have PCBs made and thereby improve on the design. But the info is not so neatly packaged and you'd have to get all the components yourself (and it's in german). But you could make it with different hardware configs "from a simple 8-bit single-board computer based on a Zilog Z80A processor to a 32-bit system equipped with a Motorola 68020 CPU".
P.S: just found out there was even a 1-Bit computer in that vein:
I’m reading the book Ben Eater read to learn: Digital Computer Electronics, by Malvino and Brown. If you want to understand how the machine works, how the hardware is structured, it’s an interesting read.
Then, you may want to learn 6502 assembler (something I wanted to do since I was a kid). I’m not there yet, but besides Matt’s excellent videos, and the infamous Commodore book, you have things like this:
