41–50 of 93 posts
I value "infinite online resources" but having integrated books of documentation in the IDE includes such valuable writing. I miss it so much when going through the hastily-written "getting started" tutorials I end up with nowadays (the scope of problems trying to be solved is way different of course)
Agree with the author’s thesis of how the folks that “grew with computers” have an advantage over those approaching them now, in terms of understanding the inner workings. I’m not sure that this matters much in terms of solving actual problems though, which is probably a good thing. But I somehow find it a little bit sad that this is the case, so I’ll plug my own https://www.endbasic.dev/ because it’s very fitting in…
Given my age at the time, programming was accessible but modifying hardware was hard. Part of the reason is that few sensible adults would hand a soldering iron to a six year old. Part of the reason is that software is easier to learn than electronics. Part of the reason is the hardware was the product back then, something you did stuff with rather than something you did stuff to (contrast the 1977 Apple ][ to the 1982 Commodore 64, and you'll get an idea of how quickly the mindset changed). It wasn't until my early 20's until I learned that people were not only modifying the hardware, but making their own peripheral cards. Someone ten years older than me likely had a different perspective simply because electronics was more relevant ... since software hadn't started eating the world.
Even those people were likely in the same boat as I if they took a moment to think about the generation prior to them. I remember reading something by one of the grandfathers of computing. They blew my mind when they started talking about hard drives, not in terms of the logical layout of the disk nor in terms of the electronics but in terms of the physics. There was a time when people had to think about computers in those terms because they were in the process of developing those lowest layers of abstraction.
I guess what I'm saying is that each generation will have a different perspective on what computers are and how computers work. They will also have different perspectives on what "low level" means. While it is sad to see a lot of the old knowledge and old ways fade into obscurity, we shouldn't pity the younger generation for not having what we had. First of all, the old knowledge hasn't really disappeared for those who choose to pursue it. Second, they are going to be building a new layer on the technological stack anyhow. What they need to understand is the layer directly below them, not what's twenty layers down.
Couldn't find it only, but found the sony one at https://hansotten.file-hunter.com/uploads/files/sonymsx2basi... fun to see the difference
Even if they were simple it was hard to program them because there was a very limited amount of information on how to do it. The few books available didn't cover a lot of things. Learning was mostly done lots of things until you succeeded. And that took a lot of time and patience. The Internet, stackoverflow, Reddit, YouTube, forums, Udemy, Github, and the thousands of tutorials, examples and documentation site make things a lot easier.
I started to learn programming on an 8 bit Sinclair ZX Spectrum and the only good things that came out of that is that it teached me to work on very constrained systems and to build up patience and will to try and fail until I succeed.
4 or 5 years later when I've experienced IBM PCs at school, it felt like going from horse and carriage to a rocket. Yes, the rocket might be a bit harder to maneuver but you can do much more things, faster.
Actually the best games and software were programmed in assembler and you had to load them from cassette tapes.
You couldn't do much in Basic.
>. In the 8-bit computer era, many games were available only as printed BASIC listings in computer magazines and books. Actually the best games and software were programmed in assembler and you had to load them from cassette tapes. You couldn't do much in Basic.
Such things were printed in magazines as BASIC listings and they were, in fact, "programmed in assembler" and typed in by hand.
An interesting thing is that RISC OS is still available for the Raspberry Pi and it's a direct descendant from the operating system of the BBC Micro - not emulated. It still has the same level of direct hardware access, so if you ever wanted to use peek and poke (well, those are the ! and ? operators in BBC BASIC) on some modern graphics hardware, there's a way to do it. There's a built-in ARM assembler in there too.
What I think was really different about the time was the quality of the documentation. Nothing modern has the same sense of empathy for the user or achieves the same combination of conciseness and comprehensiveness. For instance, here's the BBC Micro's Advanced User Guide: https://stardot.org.uk/mirrors/www.bbcdocs.com/filebase/esse... (it's of particular historical note, because today's ARM architecture grew out of this system). You could build the entire computer from parts using just this 500 page manual, and you'll note that it's not actually a huge amount more complicated than Ben Eater's 6502 breadboard computer.
Weird thing: RISC OS actually has backwards compatibility with some of the old APIs so some of the stuff in the advanced user guide still works today on a Raspberry Pi (plus it comes with a BBC Micro emulator which was originally written because Acorn didn't want their new machine to fail due to a lack of software). These days there's also https://bbcmic.ro of course :-)
The Programmers Reference Manual for RISC OS is similarly well written, and surprisingly quite a lot of it is still relevant: most things still work on a Raspberry PI, and even modern operating systems still work pretty much the same way on the architecture. While things like MEMC, IOC and VIDC are long dead, there's a pretty direct lineage for the modern hardware to these older chips too.
Not entirely true. While I've learned as a kid many of the insides and outsides of my ZX Spectrum clone, from the limited info I could gather and from tinkering, I tried to learn about most complex systems later, as much as I could.
I learned x86 assembly under MS DOS, I learned writing device drivers in C for Windows, I learned a bit of Linux system programming in University, I learned a bit of OpenGL and shaders, I learned a few bits about hardware, I learned about logical gates like NAND and simple digital circuitry. And those are basic things I've learned long time ago.
Having low level knowledge is useful but also having a higher level knowledge. I think concepts like algorithms, parallel and concurrent programming, formal languages and automata theory, cryptography, statistics, machine learning and other high level stuff I've came across in University were equally useful.
I tackled many areas of programming, desktop software, device drivers, embedded software, video games, mobile apps, web front-end, web backend. Now I am building microservice based apps with Kubernetes and Azure. I am thinking of brushing up my knowledge on ML.
I liked pretty much everything I did and I approached everything with a learning mentality.
One can't learn everything like in the '80s but one can learn a lot of things to keep him entertained and help him accomplish great things while having enough knowledge of how things work under the hood.
I am probably not an expert in any one field of programming but know enough things to be useful in many areas. I rather like being a jack of all trades than highly specialized because there is more than one thing that interests me and I am always curious about different things and I like to learn. That being said, being an expert in one thing is not a bad place to be and experts can be paid a lot.
Learn a bit about GPUs, some OpenGL, DirectX, shading language or Vulkan and tinker with the GPU.
If you want to learn how computers work now is easy. Learn C and a bit of assembly, read about hardware and try to do low level stuff. Play with memory, play with system calls. Learn a bit about GPUs, some OpenGL, DirectX, shading language or Vulkan and tinker with the GPU.
Now, on Scheme:
sudo chicken-install srfi-203
sudo chicken-install srfi-216
cat ~/.csirc
(import scheme)
(import (srfi 203))
(import (srfi 216))
sudo chicken-install hypergiant
csc -L -lGL example.scm
6502 it's much easier than the Intel clusterfuck.
Either that or RISC-V.