When computers were simpler

Hello Lains. Lately I've been interested in how computers really work. Like many here I know some things, like programming, about file systems, libraries, how the CPU works, etc. I already did something for the NES (CPU 6502). I'm thinking of going down the level and studying more about how a computer is built, how CPU interacts with memory, how a video signal is transmitted, etc., and how an operating system works at low level, even playing with USB and outputs serial, but the main systems today are too complex for that, full of layers, window managers, X11, drivers, and soykaf like WIN32API. I'm thinking of playing with simpler systems like the Apple 2 or Commodore 64, I'm also thinking of some alternative operating systems like FreeDOS, TempleOS or Haiku. Have you ever had experience with these technologies? Is it a good way to learn?

You must go as far back as the UNIVAC to fully apriciate how the computer works, however here are some things to look up, in this order, to quickly better understand. Read "As We May Think" by Dr. Vannever Bush, look up "The Mother of All Demos" (all three reels are on Archive), read "Computer Lib/Dream Machines" by Ted Nelson. These should start you on your path to enlightenment.

>how CPU interacts with memory look up QPI. Its not well documented because it's not really relevant to anybody but motherboard manufacturers, but there is some material online about it. >how a video signal is transmitted depends on the protocol. VGA is really easy to understand. >how an operating system works at a low level it varies widely. You can look at the guts of linux if you want to. Basically most OS'es do, at the bare minimum: -process/thread management(by far the most esoteric in my experience, as it is incredibly hard to efficiently schedule threads and figure out how that soykaf works at the CPU level) -memory management -message passing best way to learn how a kernel works at a low level? Try to write your own. Run it in QEMU so you don't have to worry about hardware weirdness.

>>15332 The Xinu Approach is a pretty great introduction to writing a basic OS.

Either get a real C64 or build one of the many z80 based systems on hackaday or elsewhere. If you want to do anything at all to do with graphics or sound the C64 is the better option. Apple II would be OK but tend to be overpriced due to Apple collectors. The C64 does not support 80 columns which is problematic for using it as a terminal. The C64 Programmers Guide has nearly everything you need to know, and there are many videos about the machine. I would recommend getting an sd2iec for mass storage. The z80 option allows you to actually build the machine yourself if you want. Look for a setup that already has CP/M ported and some sort of storage system. Most of these machines do not have any sort of graphics or sound and just output to serial expecting a terminal. Some of them have built in terminal emulators allowing you to connect a ps/2 keyboard and VGA monitor directly. The z80 is also somewhat similar to x86 assembly. Documentation isn't anywhere as consistent or easy to find as C64 stuff though and any graphics and sound is very specific to the machine you got.

Well, there is NAND2Tetris if you wanna learn about how to build a functional computer from NAND gates. I haven't looked at all the chapters yet but it's definately on my todo list. https://www.nand2tetris.org/

>>15328 I'm not OP, but this all looks really interesting. Thank you, lainon.

Thanks for the tips and directions. I decided to build my own computer as a long-term project, I started to study electronics and electricity and it's being fun. Unfortunately I live in a country where it's hard to find old microprocessors and old computers. mouser.com is a good place to buy these things?

I wonder if this is good advice, but... Maybe work with stuff like Arduino. My friend had a problem with a single-core Arduino wherein one module (let's say, GPS) would halt the entire controller waiting to get a signal, and other important tasks had to be kept waiting for it when they should also be responding. He considered using interrupts and implement some rudimentary scheduling, but didn't have the time before he had to deliver his project. Next project, in which he also had two equally important tasks with laggy I/O, he decided to use an ESP32, which I believe has two cores, and ran them separately on each core. I wasn't involved in these projects but hearing about them made me realize how important this low-level stuff is and to better appreciate what operating systems accomplish for us.

>>16620 Sorry for the single line paragraphs.