OSDev.org

Back in the day (I wasn't there), 8 or 16 bits seemed to be all one needed to get plenty of very productive work done. The Commodore 64 is one the most sold computers ever, and it was only 8 bits. MS-DOS was also pretty easy to use, and it was all over businesses, and is still used in some today.

Given all this, do you think it would be worth developing a modern, 16 bit OS? Obviously, it wouldn't be a super computer, but I think that a system that could use modern file formats, and maybe even do basic networking, could be quite useful, not to mention cheap.

Small and simple tasks can indeed be solved on 16-bit systems, and even on 8-bit ones. However, modern computing too often requires modern hardware (modern speeds, modern memory/storage sizes, modern instruction sets). For example, implementing bzip2, which operates on blocks of 100 to 900 KB, may be quite problematic on a 16-bit system, even if it has enough disk space to contain input, output and any intermediate data that doesn't fit in RAM. You can forget about web browsing as we know it today. A 16-bit hosting compiler is a problem as well since it itself needs quite a bit of memory for all of its data and clever algorithms, more than 64KB. You need to either split it into multiple stages or use overlays of some kind. Only the most primitive compilers like the classic Small C by Cain/Hendrix/etc would fit easily, but they'd produce horrible (large and/or slow) code.

As for small and cheap, there are such 32-bit systems already. Raspberry Pi on ARM is one. I participate in the RetroBSD and LiteBSD projects, running on PIC32MX/MZ MIPS CPUs with just 128/512 KB of RAM. There are a bunch of small and cheap systems, capable of running OpenWRT. There are Windows 10 computers on intel Atom CPUs for about $100. I mean, there are better systems for $10-$150 and they aren't as awkward to program as something like 6502, Z80, i8051 or i8086-80286. Unless you want to make it extremely cheap and sell millions of units, there's probably no point trying.

I am actually developing on 16-bit assembly to try coming up with my OS kernel project.
It is just what i get used to when i was working in the field back in the days.
I see challenge compiling C and asm compiling together and ran into lot of isues and had to resort to using turbo C compiler in order for it to work (partly). Someone suggested me start coding in 32-bit and use Microsoft assembler and compiler instead of all this trouble but I dont have much experience. so for at least now I still stuck to 16-bit for now.
So my 0.02$, for learning curve, it fits the bill, for any other purposes, probably not.

Back in the day a slide rule was all you needed to get productive tasks done. But I don't know of anyone nowadays who is interested in constructing a better slide rule.

I can think of no viable reason to write a 16-bit operating system unless it is targeted at a very old, or very simple, processor. And such an OS would be not much of an intellectual challenge.

If we are talking about Intel processors, 16-bit - or real - mode, is limited, clumsy, difficult to program, and of no interest to me whatsoever. Even 32-bit protected mode begins to look pretty primitive compared to what else is available. Why aim for the gutter when the stars are there waiting?

One thing you'll come to realize about this board is that is it pretty important how you pose a question. As an example, I might ask, "Is it better to develop using C or assembly". I would venture to say, 90% of responses would advocate "C", because the question is so wide is scope. Now I'll qualify the question "I want to learn all the ins and outs of IA32 architecture, should I use C or assembly". Now the answers will be markedly different.

Fundamentally though, 32 bit is native to IA32 and as it's already been suggested, why would you limit yourself. That being said and assuming the types of tools you have to work with are DOS let's say, there is nothing wrong with starting out in read-mode (16 bit) and once you've become more familiar with processors instruction set, then move onto protected mode. Assuming again, you'd be using DOS, you have some pretty simple tools to use such as DEBUG.

I would suggest that if you're going to program in assembly, learn the instruction set first, especially as it applies to the affect instructions have on condition bits. Then there's 1's and 2's complement, signed and unsigned values 8, 16 & 32 bit operands. Even in real-mode you can use 32 bit registers.

I would suggest using NASM though as it is far more comprehensive than MASM or ML for that matter.

For a full-blown OS or proper support for modern hardware, 16-bits is a bad choice. However if you just want to toy with things, going 16 bits and using the BIOS (or even DOS) allows you to selectively pick what things you want to try with hardly any dependencies. After all, we all code for fun in the end.

Combuster wrote:For a full-blown OS or proper support for modern hardware, 16-bits is a bad choice. However if you just want to toy with things, going 16 bits and using the BIOS (or even DOS) allows you to selectively pick what things you want to try with hardly any dependencies. After all, we all code for fun in the end.

I agree 100% - write what you want to and what you think is fun. But the OP was posited in terms of a useful operating system, even going so far as to say it would be cheap.

Slightly as an aside, most of the 16-bit real mode OS kernels I've seen won't even execute on a 16-bit x86 processor (they use 386+ instructions, for example), and many of them rely on BIOS and hardware conveniences standardized in the 32-bit era. Try to run them on an actual 16-bit PC and you'll get nothing at best and hanging/rebooting/crashing systems at worst.

Don't sit in the 16-bit-ish world and half-arse it because you want to hold onto the BIOS.

FelixBoop wrote:Given all this, do you think it would be worth developing a modern, 16 bit OS? Obviously, it wouldn't be a super computer, but I think that a system that could use modern file formats, and maybe even do basic networking, could be quite useful, not to mention cheap.

What would be the advantage? No, if you're looking at it from that angle you must come to the conclusion that it's not worth doing it because it won't be better than the same OS written in 32 or 64 bit mode (assuming you're talking about x86).

There is really only one valid reason for writing a 16 bit OS today: "Because I can". When you decide to write a 16 bit OS just for the fun of it, why not. But don't think it's a useful choice.

Kevin wrote:There is really only one valid reason for writing a 16 bit OS today: "Because I can". When you decide to write a 16 bit OS just for the fun of it, why not. But don't think it's a useful choice.

Whether 16-bit OS or not, there's also knowledge and experience. My hobbies and past projects virtually always helped me do my work or even get a job. When doing something, along the way you learn something that becomes useful. It may not be the project that you've done that has value, but things in the area of the project, solutions to specific problems, which needed solving, overall understanding of how things are done and what they involve, things like that.

FelixBoop wrote:Given all this, do you think it would be worth developing a modern, 16 bit OS? Obviously, it wouldn't be a super computer, but I think that a system that could use modern file formats, and maybe even do basic networking, could be quite useful, not to mention cheap.

If you are talking about stock PC hardware, then this part is incorrect, for a reason most people wouldn't consider: volume. Up until around 2008, each successive generation of PCs sold roughly twice as many units as the previous generation. Furthermore, as time has passed, most of the older hardware has been destroyed, either having been disposed as obsolete, or from wear and tear, power surges and short circuits, accidental damage, and so forth. The practical result of this is that it is far easier to find hardware from after, say, 2005, than it would be to find hardware from before 2000. Since 32-bit 80386 and 80486 systems were solidly established as the mainstream by around 1992, this means that an XT-class system is going to be more valuable (slightly) than any systems from between 1995 and 2005 (though given that those are generally are going at scrap value today, it hardly matters). You would be hard pressed to find an actual 8088 system today, or even an 80286 system, so there's more or less no gain in terms of availability in writing for them.

Outside of the PC world is a somewhat different story; 16-bit and even 8-bit microcontrollers are still fairly common, though even those are quickly being phased out in favor of ARM and other 32-bit RISC designs, which are both easier to code for and often use less power due to more modern designs. For custom hardware, 16-bit is at least reasonable, though even there a 32-bit processor is likely to make more sense. Unless you intend to build a custom CPU from TTL, I would not recommend using 16-bit hardware.

This leaves the question of whether it is worthwhile from a software perspective. The answer, simply put, is not just no but HELL NO!, especially if the target is an x86 PC system. Simply put, the original x86 architecture and instruction set stinks on ice, and while a lot of the flaws were corrected (or at least compensated for) by the 32-bit extensions, it is still a truly wretched design that even Intel wants to see the back of - it only persists because no one wants to have to re-write every single piece of Windows software people want to keep using. Most of the other microprocessors prior to the 68K were pretty bad, but none were quite as bad as the one that ended up on top; since most processors designed after the 68K were 32-bit RISCs (the 68K was a good but baroque CISC design in the vein of the VAX minicomputer), and were designed to optimize compiled code, they are all much cleaner, less ugly, and ironically enough, easier to write assembly code for (though writing efficient assembly code for them by hand is still a damnable pain in the rear).

[EDIT: I just added my Historical Notes on CISC and RISC essay to the wiki, for anyone who is interested.]

Even if this weren't the case, the benefits of having a linear address space of 4GiB or more (with memory protection and demand paging to manage it) are more than reason enough to target a 32-bit or later system.

So, if you mean to have non-stock hardware, from a coding perspective, you would in most cases be better off with an ARM- or MIPS-based SBC like the Raspberry Pi, the Beagleboard, or the MIPS Creator, if you can. Keep in mind, however, that used stock hardware will be much cheaper (and can often be gotten for free) for most desktop purposes.

This is a bit of a tangent, but slightly related and some people might find it interesting:

My first stage boot loader (512 bytes) loads a 2nd stage (up to 64K) in, obviously, real mode. The second stage switches to PM, which brought up an issue: do I make a 3rd stage bootloader (how many freakin bootloaders do I want?) or do I mix 16 and 32 bit code (sounds messy).

And what I ended up doing was switching to 16 bit protected mode and writing my code in such a way that in would run in both real and protected mode. My print function is probably the best example of how I accomplished this. Normally you'd expect the a RM print function early on to do something like: But I did: videoSegment was initialized with 0xb800m but after switching to PM it was overwritten with 0x18, which is a descriptor for a data segment with a base of 0xb8000, allowing the same code to run in both real and protected mode.

azblue wrote:My first stage boot loader (512 bytes) loads a 2nd stage (up to 64K) in, obviously, real mode. The second stage switches to PM, which brought up an issue: do I make a 3rd stage bootloader (how many freakin bootloaders do I want?) or do I mix 16 and 32 bit code (sounds messy).

The BIOS mostly works in real mode, so there's not a lot of sense in switching to protected mode until after you've loaded the kernel into memory. In your second stage, before switching to protected mode, you should load your kernel. You can use unreal mode to access memory above 640k. (I install a GPF handler that switches to unreal mode. That way, I never have to call it - it'll automatically run whenever I try to access something outside the segment limit.)

Once your kernel is loaded, you can switch directly to 32-bit protected mode, with no 16-bit protected mode in between.

azblue wrote:And what I ended up doing was switching to 16 bit protected mode and writing my code in such a way that in would run in both real and protected mode.

Uselessness of 16-bit protected mode aside, code that can run in multiple different modes is always interesting to see.

Octocontrabass wrote: Once your kernel is loaded, you can switch directly to 32-bit protected mode, with no 16-bit protected mode in between.

azblue wrote:And what I ended up doing was switching to 16 bit protected mode and writing my code in such a way that in would run in both real and protected mode.

Uselessness of 16-bit protected mode aside, code that can run in multiple different modes is always interesting to see.

That was a big part of my motivation; I thought being able to run in real and protected mode was pretty cool.

As for loading the kernel, I was booting from a floppy and my 2nd stage had the code to directly read the disk and load the kernel.

Of course, that makes for a pretty limited OS, as it leaves me unable to boot from anything else, but it was cool for a little project early on

azblue wrote: My first stage boot loader (512 bytes) loads a 2nd stage (up to 64K) in, obviously, real mode. The second stage switches to PM, which brought up an issue: do I make a 3rd stage bootloader (how many freakin bootloaders do I want?) or do I mix 16 and 32 bit code (sounds messy).

Two should be enough. My FAT 12/16/32 bootsectors can load DOS-type .EXEs of up to 400 KB in size. My C compiler supports 16-bit real mode and has a special "huge" model, in which all pointers are 32-bit flat (limited to 1MB range) and which frees the programmer from dealing with segmentation explicitly (segment/offset conversion/loading instructions are generated by the compiler behind the scenes, which is expensive, but today's computers are fast and if it's a boot loader, it runs just once in a long while and it shouldn't matter much for a hobby OS anyway, but if you really really care, you can still write some assembly code, including "inline" assembly code). With these tools you can develop quite a decent loader using C for most parts. Ben Lunt has written a bootloader for his OS mostly in C using my compiler (he actually modified it to have it switch between 16-bit and 32-bit code generation using special pragmas and he has included some segmentation support in pointers, both of which I think are hacky and unnecessary, but hey, it worked for him!).

Mixing 16-bit code with 32-bit code is possible and there are several options. It doesn't have to be very messy. For example, you can have a binary with 16-bit (mostly) and 32-bit parts. The 32-bit part can be just attached to the 16-bit part. You can do that with your shell's copy command or you can use assembler directives to simply include a binary file (e.g. incbin in NASM).