Ahh, finally. My first publicly-avaliable floppy image. I really wanted to wait til' I had something cool (under the hood, at least), so I've finally got something to show.
It's running 4-seperate threads with on-demand virtual-address mapping and 4k pages. Each process does _not_ run in its own address space, but I'm almost there. As soon as I've done that, I'll have a simple shell, which will be a seperate program. I'll have never tried to implement a shell into the kernel, so it will be literally UI-less since creation, to final touches.
The Console will have been loaded from the same floppy, by the bootloader.
Also, I've got no sources online, but I'm almost to the point I think I can share some things. I know I'm very close to the point I can share the 890 lines of ASM for my bootloaders (Stages 1 and 2). And I'm also close to the point of releasing my editing tools to help anyone who'd like them (includes a Command-Line hex viewer with commands to read any portion of a file or compare two files and another tool that creates floppy images formatted with my Home-Brew filesystem).
The kernel code itself will not be released, at earliest, until version 0.1.0a. Currently it is 0.0.6a, but the following versions will take the longest to implement.
My plans are:
0.0.7a - Simple 'processes' that have their own address space
0.0.8a - Processes run in user or supervisor space
0.0.9a - Simple process communication
0.1.0a - Simple drivers, start implementing C standard library
...and etc.
Also, check out the documents. Not all of them are online, but the ones that are will help give you a basic idea of my OS's running enviroment and the layout of the floppy image. The information on the modules is incomplete, as you can probably tell. A module will be akin to a DLL file, in that it can provide either a user-level service (such as figure out a square root) or a supervisor-level service (such as interface to the video card).
Also, I'd like criticism on the layout of memory. I'm not really sure about its final structure. You might notice that 2mb of memory is used up for a memory map - The upper 2GB is the same for all processes, so a permanent area of 2mb is set aside to provide page mappings for this area. That way memory can be saved, and I can have as little as about 20K overhead per process.
Enough ranting. Heres the link to my site:
http://demi.cjmovie.net/
As you might notice, it has archives dating back to august (when it was first created) in the history section, but this is the first time I've actually released the link. I kept them there as a bit of an archive for future reference.
I'd like to see if anyone has trouble running it. I know it runs fine in BOCHS, and I'm about to reset (after I finish posting this) to test it on my system. You might also notice, in BOCHS at least, it takes a few seconds - just barely - to start up. 99% of this time is taken up by clearing the entire 2mb area of the memory map so that we don't have any accidental present bits set .
Demi OS (0.0.6a)
Re:Demi OS
OK, for the appeasement of all of the board, I have some of my sources online. This also includes the source for my two incomplete tools and my two-stage bootloader.
Re:Demi OS
@Yanix: There is no requirement for source code. He is free to do what he wants. If he wants to give out source code, thats his choice.Where is the source