Acess OS Project - Blog

ACPICA

thePowersGang — Tue, 11 Dec 2012 10:30:56 +0800

Well, r0.15 hasn't happened yet, how typical of me :)

In the meantime, along with doing quite a few fixes to AxWin3, I've started implementing ACPICA into Acess. This is the first external project that's been included, and I've tried to do it with minimal modification of the sourced code, and without having to include the code in the Acess tree.

So far, it's been a success. There's a makefile that automatically extracts the ACPICA code from its tarball, patches it for Acess and then compiles it into a .a for the kernel to link against.

The kernel shim is almost complete, but there are probably some bugs sitting about that ends up confusing the ACPICA code and causes it to run out of cache entries.

For the curious (and lazy), the ACPICA shim is in `KernelLand/Kernel/arch/x86/acpica.c` and the Makefile hackery is in `Externals/ACPICA`

GUIv3 Released (belated announcement)

thePowersGang — Sat, 31 Mar 2012 23:07:08 +0800

Ok, so in the beginning, back with AcessOS/AcessBasic, there was AxWin. It was my attempt at making a GUI system, and to an extent, it worked... although I never wrote anything real for it. Then I started work on AxWin2, which was going to be a very tablet/iOS style interface. There would be no windows, just full screen tabs. This turned out to be a nightmare to implement, and the lack of dialogs would have crippled it.

So, I started planning AxWin3. This sat unloved in the git tree for quite a while, until not long after the 0.13 release, I started really working on it. 0.14 is the first GUI release, however stability is questionable.

On that note, I plan to finish bugfixing everything sometime soon (at least for this round of features) and release 0.15

ASCII Star Wars

thePowersGang — Sun, 07 Aug 2011 12:54:41 +0800

In preparation for the UWA open day next weekend, I have been giving the Acess2 networking code a real workout using the telnet ASCII Star Wars stream from towel.blinkenlights.nl (thanks to the guys who made that)

After several days of fixing fiddly bugs (including some dumb ones in non-networking code), I managed to get the entire show to play through. :)

The next week will be spent cleaning up some little issues and getting the display presentable, so I can show it off for the UCC's stand.

Suddenly, new release

thePowersGang — Sun, 13 Feb 2011 20:10:36 +0800

So, finally after three months, I've uploaded a new release file. Most of the changes between the two versions have been in the networking code (implementing routing tables, cleaning up usability issues).

Aside from that, there were a heap of bugs fixed and issues resolved (e.g. user apps shouldn't be able to segfault and take out the kernel any more)

Take that GNU LD

thePowersGang — Tue, 12 Oct 2010 02:00:00 +0800

So, GNU LD doesn't like linking 64-bit code to an ELF32 file, and hence was causing all sorts of issues with the x86_64 port (random corruption / data truncation)
This has been fixed by adding a way for an architecture to run a command after linking, that in the case of the x86_64 build, converts the output elf64 file into an elf32 file that GrUB can boot. (This also means that the disassembly actually works properly)

Threading is now my bitch

thePowersGang — Sat, 02 Oct 2010 21:48:38 +0800

In response to my post earlier today, I was spurred to take another look at the threading code. It turns out taking a break was a good idea.
The bug was in the new mutex code, to speed things up I was using a double ended linked list as a queue. Works quite nicely... if you remember to set the end pointer to NULL once the queue is emptied. I had forgotten to do that, hence the mutex acquire code was trampling the active thread list, causing bugchecks to fire.

Threading is a bitch

thePowersGang — Sat, 02 Oct 2010 13:48:15 +0800

For the last month or so I have had blocker bugs in the Acess2 threading code. This has broken any real progress on the rest of the kernel, leaving me unable to work on the fun stuff (read IP/TCP and filesystems).

A quick explanation of the bug follows:
The main issue is that the list of currently running processes is not being maintained correctly, for some reason threads that are acutally sleeping are being kept on the running queue, this is causing bugchecking code to fire and panic the kernel. The converse is also happening, so threads that are still supposed to be active are being taken off the active queue (or not being put back on).
I feel that this bug is due to concurrency issues somewhere, but a visual inspection of the source shows no places where the thread lists are edited without proper locking in place, and enabling debugging seems to mask the bug somehow due to timing differences.
If someone feels like reading the code and finding my fault for me, please feel free to email me at acessdev [at] gmail [dot] com or acess [at] mutabah [dot] net

Site is active, x86_64 build progressing

thePowersGang — Sat, 26 Jun 2010 19:00:03 +0800

Well, this site is now the official page for Acess, now to work on the OS itself.

The x86_64 port is progressing sort of nicely... except for some very strange linking artifacts that seem to cause some strings to be corrupted.
I hope to have Acess ready for release as a non-networked system soon, but I just can't resist working on those new features. :D

Darn stack alignment

thePowersGang — Fri, 28 May 2010 14:19:07 +0800

The x86_64 port of Acess is going well, after several changes to the build system, it can now be compiled (however, quite a few functions are stubs).
There is also quite a few bugs in the low level kernel. The current one is a problem with the IRET from the IRQ handler not popping the correct sizes (I think I just realised that you need to use an IRETQ in long mode, I'll post this and check)

x86_64 Build!

thePowersGang — Sat, 15 May 2010 15:55:36 +0800

Because my old laptop decided to keep randomly locking up when I was using it, I got a new one.
This one is a Toshiba NB300, and hence has a 64-bit CPU. This posed a slight problem to compiling Acess, as I had been using the native compiler.
Although I managed to get a i586 cross compiler up pretty quickly, I still decided to exploit the capabilities of my new machine and port Acess to x86_64.
This port has lead to quite a few fixes to the build system, and some changes to the layout of the architecture API.
See the git commit logs for the current progress on the port.

TL;DR - There is now a 64-bit port of Acess in development.