> My only gripe with modern machines is how narrow their interface is, I wish they exposed more of their internals.
Modern machines are quite the opposite. It's the current crop of main stream OS's and their associated API's which are to blame, not the hardware designs.
> e.g., I'm too young to remember the Commodore computers, but it's my understanding that you could change the display colors and sprites by poking a memory address.
The commodore 64 was a very simple machine with little memory. Only one program ran at a time so no OS was needed. And the memory registers you poked at was the API as things were very simple back then.
However, you can certainly do the same with modern GPUs[1] but they are so massively complex that the manual for the Intel graphics controllers are well over 1000 pages, some manuals exceeding 2000 pages[2]. For comparison, the manual for the voodoo2 is 132 pages[3].
> I'm not advocating for specifically that, modern computers are connected to the Internet and it would be a security disaster, but that kind of interaction with the machine is something that's missing.
That's why we have an OS to control access to those bits of hardware. The internet has nothing to do with it.
The problem you face is most modern operating systems are massive, bloated even, to the point where the interfaces are buried underneath miles of code. How does one approach a simple hardware project of poke at bitmaps and pixels stored in the Intel GPU from a "modern" Operating system.
The Linux kernel is something like 10% AMD GPU driver code, mostly auto-generated by massive build tools which are as complex as the kernel itself. So no wonder you see the system as narrow, its so massive it blurs into one indistinguishable monolithic blob which gives it that narrow feel.
> Only one program ran at a time so no OS was needed.
The Commodore 64 had a simple OS, and it does have all the elements to be called a primitive OS. The features include:
- Devices (0 was the keyboard, 1 was cassette, 2 was RS-232, 3 was the screen, 4-30 were the serial bus where printers and disks lived)
- Uniform I/O calls across those devices (you must OPEN a device, and then can use CHRIN, GETIN, CHROUT, LOAD, SAVE calls to move data, and then you have to CLOSE it).
- Handles (called "logical file numbers", up to 10 open at once supported) - a bit more sophisticated than CP/M really.
- A rudimentary notion of standard input/output (called the "default" input and output device)
But this primitive OS definitely depended upon what could be considered a single background task to read the keyboard (SCNKEY) and update the timer (UDTIM) - triggered by an IRQ that was set to fire off 60 times a second (50 for PAL). Tape I/O overtook this IRQ and messed up the timer though.
However nothing in this primitive OS except for reset routines even acknowledged the presence of the SID chip or features of the VIC beyond the text display, so you were definitely on your own there.
> How does one approach a simple hardware project of poke at bitmaps and pixels stored in the Intel GPU from a "modern" Operating system.
Linux exposes a `/dev/fb0` device, doesn't. Can't you `mmap()` this device and peek/poke to your hearts content, assuming something else isn't trying to write to `/dev/fb0`?
Modern machines are quite the opposite. It's the current crop of main stream OS's and their associated API's which are to blame, not the hardware designs.
> e.g., I'm too young to remember the Commodore computers, but it's my understanding that you could change the display colors and sprites by poking a memory address.
The commodore 64 was a very simple machine with little memory. Only one program ran at a time so no OS was needed. And the memory registers you poked at was the API as things were very simple back then.
However, you can certainly do the same with modern GPUs[1] but they are so massively complex that the manual for the Intel graphics controllers are well over 1000 pages, some manuals exceeding 2000 pages[2]. For comparison, the manual for the voodoo2 is 132 pages[3].
> I'm not advocating for specifically that, modern computers are connected to the Internet and it would be a security disaster, but that kind of interaction with the machine is something that's missing.
That's why we have an OS to control access to those bits of hardware. The internet has nothing to do with it.
The problem you face is most modern operating systems are massive, bloated even, to the point where the interfaces are buried underneath miles of code. How does one approach a simple hardware project of poke at bitmaps and pixels stored in the Intel GPU from a "modern" Operating system.
The Linux kernel is something like 10% AMD GPU driver code, mostly auto-generated by massive build tools which are as complex as the kernel itself. So no wonder you see the system as narrow, its so massive it blurs into one indistinguishable monolithic blob which gives it that narrow feel.
[1] https://wiki.osdev.org/Accelerated_Graphic_Cards
[2] https://www.x.org/docs/intel/
[3] http://darwin-3dfx.sourceforge.net/