Separating build from source directories is good, it makes it easier to work with the source files when the project grows.
Gigasoft wrote: ↑Thu Aug 14, 2025 4:53 am
For starters, it probably shouldn't load the shell from a fixed location.
Maybe, but you'd be surprised how much fixed locations and sizes were used in historical OSs. In TestOS, the start and number of sectors for the shell could be passed from the Makefile, but it's a bit of mucking about to set up.
Gigasoft wrote: ↑Thu Aug 14, 2025 4:53 am
Most OSes have a concept of files, which can reside on different types of media. Other common features are memory management and a concept of tasks.
Files are good, yeah. For a long time, I used numbered fixed-size blocks instead, it's an old Forth thing. Sometimes it's a nice way to do things, keeping each 'screen' of code small and simple, but other times I chafe at the fixed small size of each block (64 cols, 16 lines), at organizing all those little blocks, and at typing large block numbers, so I've decided my OS will have files. After all, the latter 2 issues are eased by using several block
files. 
OS Memory management needn't be complex. It was often very primitive all the way through the 16-bit and even 32-bit eras. I remember a friend getting 64-bit AMD Sempron CPUs within a year or two of Linux finally making it possible for programs to return freed memory to the OS. Prior to that, Linux took after the original Unix which itself was designed to have only 1 userspace program in RAM at a time, with the other programs swapped to disk. Memory management in that case just needed a few variables; a small structure per program.
8086's segmented memory makes it easy to have small tasks. Larger tasks might be tricky.
Gigasoft wrote: ↑Thu Aug 14, 2025 4:53 am
Also keep in mind that software running in real address mode will be unable to make use of most hardware, so it's not a good idea for a PC operating system. It's basically just going to make your life harder.
It'll run in emulation and retro systems until the collapse of civilization.
The maker scene is starting to produce BIOS-PCs in the same way it's been producing other 8- and 16-bit systems for years.
Conversely, an OS for modern PCs will only run on the small number of computers you write drivers for. Even if you target a popular laptop, the majority of potential users won't have it. And if you write it for a VM, that's not too different to targeting an emulator.
This is why I'm writing an OS for the Nintendo DS
-- fairly simple hardware and more emulators than I can even imagine. It's a bit more complex than early PCs, I will have to make the CPU cache work. On the other hand, I get a "hand up" with flashcarts'
dynamically linked disk interface -- the flashcart loads a library with drivers for its SD-card interface and FAT; I can save writing a filesystem for later.
Gigasoft wrote: ↑Thu Aug 14, 2025 4:53 am
It should also be noted that an OS is not a good project to start on if you are a beginning programmer or aren't proficient in assembly. It is advisable to have read a book on operating system design before you begin, and have solid experience with large software projects.
True, but a 16-bit OS needn't be a complex project. It's not the simplest, but needn't be very complex.
