My first 16bit OS

[username291]

Hi, please may anyone review my 16bit real mode OS source code. Is the initial design really bad? I have little to zero experience in NASM too

I want to make an OS like MS DOS or MikeOS. But i dont know what to put in my kernel. So i decided to make some kind of shell with one command available so far

Could you point out my mistakes in the structure of the OS

https://github.com/MXLXN/Test-OS/tree/main

[Gigasoft]

There is no OS at the provided address. Did you forget to upload it?

[username291]

There is no OS at the provided address. Did you forget to upload it?

Literally it's not an OS yet I think
But the link should be OK?? I can see the repository

[Gigasoft]

Yes, there is a boot sector which loads another program which loads yet another program. But I'm not sure what design or structure you want us to review. Your "kernel" has no functions and doesn't do anything.

[username291]

Yes, there is a boot sector which loads another program which loads yet another program. But I'm not sure what design or structure you want us to review. Your "kernel" has no functions and doesn't do anything.

I just have no idea if i did what i did so far the right way
Do you see any big mistakes in my initial design? Do i even need to load shell from kernel, or i should load it from bootloader. I'm just clueless

[Gigasoft]

For starters, it probably shouldn't load the shell from a fixed location. 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.

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 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.

[eekee]

Separating build from source directories is good, it makes it easier to work with the source files when the project grows.

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.

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.

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.

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.