Still waiting

So we didn't quite reach our deadline for November 4th.

I think it has been a little too ambitious, considering the situations all developers are in now.

So we're definitely working towards the 0.1.1 release, and among the things we already mentioned would be in there, we'll also feature file buffer support.

Now that doesn't say a lot though. Basically all it says is that we have something that resembles a file, which you can write to, and read from. Seeks are also supported, but unfortunately, we can't sync with disk, or even clean up read items in a one way stream/pipe ...

Michel still is working on his PCI and APIC support and is thinking of including C++ code into the project (I wish him luck implementing the special operators, I'll continue doing C).

Doubted is whether or not we will be able to put PCI and APIC into the next release. There'll be a small discussion on that and we'll get back to you when we've got more news about the next release.

Until that time, the developers will be working on both school and the kernel.

Also, I've managed to set up gitweb on my own server, so if you like you can subscribe to the rss/atom feeds on there: http://orion-os.eu/gitweb/

I hope to have more news soon.

A new release already?

A new release is coming up on the horizon. We now have the date of Friday 4th of November 2011 planned for the release of Andromeda-0.1.1.

This will feature a brand new paging system, a new memory mapping system, minimal ACPI support and basic support for the Advanced Programmable Interrupt Controllers (APIC).

The paging system has been made in such a fashion that the memory requirement scales to the pages requested, instead of permanently occupying 4 Megs of RAM.

The same goes for the new memory map, and did I already mention it is based on the size of the actual physical memory!

This means that we always occupy 0.2% of physical memory available for the memory map, and depending of the amount of virtual memory usage a little bit more for the page tables.

Also we've conjured up a way to put the kernel at 3 GiB. It's called the overflow trick. The principle behind it is pretty simple. All you do is set up a segment which maps memory address 0  to the 3GiB location and make it 4 GiB long or so. Then you jump into the higher half code.

Simple as that. All you need to do is page the code to both low and high memory, disable the overflow trick and unmap the low memory code, leaving only high memory in place.

Whenever some low address is required, all you need to do is add 1 GiB to the address and the 32-bits integer flows over when the segment is applied, and the correct pointer is used.

Simple, stable and effective (do watch out with virtual machines that don't properly emulate the 32-bits overflow, they can be a real pain sometimes).

The ACPI support is created by Michel Megens, so not much for me to mention on that part. The same pretty much goes for APIC support.

And speaking of dates! My birthday was last Sunday (October 30th) at which I turned 19!