Development

So due to a few leagal reasons it looks like I will have to change the name of the project! So all suggestions welcome, for the time being I'll leave it at NoNameOS to avoid getting sued :)

Version 0.6.0 of AMOS has at last been released! A large amount of bugs have been fixed throughout the kernel, including a critical bug in the physical memory manager. The FAT driver has been improved with write support. A new CPU bound test application of the Towers of Hanoi has been included for stress testing the system. I have tested 0.6.0 on VMWare, Qemu, Bochs and a variety of machines in my lab and it seems to be stable.

The Implementation documentation for 0.6.0 is also up on the site, get the PDF here. Its a high level look at the kernel code. Used allongside the source code comments should provide a good way for people to understand the implementation. If I get around to fixing up the design documentation I will put it up also. As an aside the AMOS project recieved a first class honours result! :)

I would be gratefull to everybody who visits this site to give the 0.6.0 release a test and maby even look over the code and forward me on all bug reports, cheers.

Download the 0.6.0 release over on SourceForge.Net here.

So a couple of people have been wondering about the status of AMOS lately as development has been a bit on the quiet side. At the moment I am sitting my final year degree exams and development is on hold for at least four more weeks. I have the 0.6.0 release ready (code up in CVS) and will release it soon along with the implementation documentation. Changes included better standard C library support, improved DMA memory allocation, a big bug fix in the physical memory manager and lots of smaller fixes.

As for CVS, SourceForge.Net rolled out their upgraded CVS hosting yesterday and access has changed slightly, see the updated CVS Access post for details.

So I finally fixed a potentially fatal flaw with the paging subsystem. Before the bottom 4MB's were identity mapped and when a new page table was needed it was allocated from the physical memory manager and the appropriate entries were set by writing to that physical address! big problem after you receive a physical page above the 4MB mark. The new system uses the fractal mapping technique, whereby you map in the page directory into the last entry of itself, letting you address the page directory and all its page tables for the current address space in a linear fashion via the top 4MB's in the 4GB address space (see the picture below). In addition a quickMap() function is available to quickly map in a physical page into the current address space so as we may read or write to it, very useful as this page might be for another address space we are manipulating and will not be accessible via the fractal technique. The kernel is linked to run at the virtual address 0xC0001000 so we have an unused page table entry for the address 0xC0000000, which quickMap() uses to temporarily map in a physical page for access. The INVLPG instruction (only available on the 486 chips or higher) is used to flush the specific TLB entry (0xC0000000), incurring a mild performance hit. The new code is up in CVS.



The above diagram shows the typical address space layout for a process. Each process has its own unique address space, defined in the top 4MB's via the fractal paging technique. The kernel at the 3GB mark upwards is common and mapped accross all processes. Below the 3GB mark is the unique address space for the process. Below the 16MB mark is physical memory eligable for DMA operations.

Updated the website to encompas more than just the development blog, look to the right and you can see you may navigate to sections like screenshots and download, sweet!

Released 0.5.0 with the near finished process manager subsystem and lots of bugfixes. A simple user shell application is included along with a test application. Each virtual console has an instance of the shell spawned on it so you can finally interface with the kernel via a pretty good set of system calls. Each process spawned is a user mode process (ring3) with its own address space so theirs good separation and protection between multiple processes in the system. The test application lets you perform some illegal operation to stress test how stable the kernel is, so you can perform page faults, general protection faults and the like at will. The kernel process (ring0) after initializing the kernel itself and spawning the initial shells turns into the systems idle process. I have tested 0.5.0 on VMWare, Qemu and Bochs and it seems to be pretty stable. Their are some known issues with the FAT driver; still no write support and some small bugs with file/path naming. Also virtual mount points are not included within list operations. Pressing F5 at any time will display the schedulers current process table.

Download the source code or binarys here:
AMOS 0.5.0 release (SourceForge.net)

And finally some screenshots of AMOS running, click to enlarge...


Spawning the test.bin application and generating a GPF exception.

Manipulating the file system.

Getting ready for a big release next week which will include the near finished process manager. We can now spawn user processes (ring3) . The kernel is fully reentrant and system calls are working. Synchronization between critical section is achieved through mutex's (read spin locks). A simple user shell for interfacing with the system is in place on all virtual consoles. Checkout CVS as all the code is up their anyway.