2013-04-27 - Bootloader Design

So, my plan is this ...

The 512-byte boot sector loads a small 16-bit loader.  This loader will then load a text file detailing modules to load, the first being the 32-bit kernel.  The 16-bit loader will then load all of these 32-bit modules.  Its last act will be to switch to 32-bit mode and start the 32-bit kernel proper.

The downside to this is that the 16-bit loader will have to understand the various file-systems it may encounter, but this can be mitigated by requiring a small boot partition which contains the modules.

The upside is that the config file can be modified to account for many different boot devices, including, but not limited to, the following situations:

• Booting from a floppy (which will need a floppy driver)
• Booting from a hard drive (which will need a S/PATA driver)
• Booting from a CD-ROM drive (which will need an ATAPI driver)
• Booting from a network (which requests file by name)
• Booting from a USB device (which requires PCI, USB, and class drivers)

The bigger upside is that the 16-bit bootloader will be able to request blocks from any (bootable) block device using the BIOS routines and will be able to load any file by name from a PXE network boot using the BIOS routines.  That way, we're not doing the same thing as a certain other OS of booting from a USB drive using the BIOS, jumping into protected mode, then finding that our boot device went away.

One downside is that we only have 640k of space to load the modules into (which should be OK as they can be read-only drivers for the various  drives)

The 16-bit loader will also have to create an identifier from the boot device in order to pass this to the 32-bit kernel so that I can find the same boot device using the 32-bit drivers (when the BIOS is no longer available).
It could even be made "intelligent" to the point of identifying (guessing) what device drivers it will need, but it is dependant on the BIOS if it's even possible to get any information about what the booted device is.

Most BIOSes just pretend that a USB hard drive is a normal hard drive, leaving a surprise for the OS when they jump to 32-bit armed with an ATA driver and find no drive to boot from

2012-01-01 - Time and Video Drivers

Being the start of a new year, I figure what better "time" to write the C library time.h functions.

Although, the other idea of adding a SetTransform() to the Video Driver interface to allow the code to set a 2D transformation matrix to allow subsequent plots and whatnot to be scaled is inspired.

I've separated out the definitions for the DOS driver interface and created a file for the Video Driver interface.  Unlike previous incarnations of this, I have added the same Context approach as other drivers use so that multiple displays on one adapter (or multiple adapters of the same type) can be handled easily.

2011-12-28 - Structure Changes

I've added the Libs, list and DOS elements back into the kernel, and wired them in.  I've also changed the way that the standard C library features are structured into the kernel.  They now have their own virtual directory courtesy of NetBeans.  I've also changed the naming convention for the standard function to remove the prefix which I had been using before.

2011-12-05 - NetBeans and Subversion

Recovering from the flu, I decided to have a look at NetBeans.  I have it installed on this new machine, along with MinGW and MSYS, but I haven't gotten around to doing any OS dev work yet.

I looked at NetBeans and poked around with a few test projects, trying to figure out how best to get my structure of OS to work through the IDE.  I've come up with the idea that creating a C/C++ Static Library is the best approach, and putting 99% of the OS code into it.  That seems to use the ar tool to create a .a file which contains all the .o files.  I have then added post-build steps into the project makefile to take this .a file and link it in with my existing start.o to create the binary kernel files as I have before.  The makefile also compiles the bootblock.  I have set the Project run command to run the Bochs bxrc file (via a batch file) to then fire up Bochs with my OS loaded.

A "quick" install of Apache and Subversion later, and NetBeans is happy to push the code into the source control repository, and I can keep track of changes.  All looks good.

Currently, this set of code only contains a few of the previous files, it sets 32-bit protected mode, clears the VGA Mode 3 screen, and displays a title.  It's more of a test for the environment.  In any case, if this approach works, it will make a very good starting point to re-integrate all of the code and create the modular kernel that should have been working ages ago.

I have sent a copy of the project to Pink to test on his Linux install.  He reports that he has been able to get it to build by adding a Debug-Linux configuration into the project and tweaking some settings.  We may be able to get a Subversion repository exposed so that it can become a collaborative project, at least from the point of view of being able to get the code and run the progress so far.

2011-07-13 - Threads and Processes

A few more tweaks to the Process subsystem today.  I've taken an old set of code that I was working on before this issue with Bochs not working came up, and I applied the fixes to make it work in Bochs to it.  After a little tweaking, it started to work and tick along correctly.

Tested a few threads as well (the character generator program that I developed previously) and it all seemed to work.  There is a slight issue with the display when scrolling which the semaphore should have fixed, but I think it's actually a render issue with Bochs.  The semaphore itself tested correctly.

The next step from here is to remove the Sleep(Time) code from the process system and implement a GetPid() function, Sleep(Pid) and Wake(Pid) to allow threads to control one another.  The Sleep(Time) will be reimplemented as a separate subsystem which will use its own thread (or even an interrupt handler) to wake a thread up once its timer has expired.

This should then give me the following functions:

• GetPid(): Returns the current Pid
• Sleep(Pid): Sets the given Pid to sleep
• Wake(Pid): Sets the given Pid to waiting
• Sleep(Time): Sleeps the thread for some time
• TickHandler(): Checks for threads needing waking and wakes them.

The Top command would be modified to display the Pid in the table, and command versions of Sleep() and Wake() will be added to allow thread control for testing and lolz.

2011-07-12 - Bochs and Threads

Recently I have been looking into Bochs to try to figure out why the multitasking code (which works on physical machines) fails under Bochs.

The discovery was made yesterday that the reason it was failing under Bochs specifically is because Bochs does not start with zero-initialised memory, and that the initialisation code for my multitasking did not clear its variables.  What's more is that the compiler assumed that the BSS would be zeroed, and even refused my explicit zero initialisation.  This was fixed up and the code got further before crashing.

Last night and today, I was looking into the Bochs debugger and trying to figure out why it seemed that the code compiled on my laptop was causing it to fail even after fixing the above issue.  After hours of stepping and deleting code and stepping and disassembling, I could not figure how the EBP register was being overwritten by the EIP value.
Finally, I spotted it.  The code I was using (modified from some tutorial code) set up the tasking jump using unnamed registers, and the GCC compiler was choosing its own registers to use.  Unfortunately, one of it's choices conflicted with a register I was using.  A few tweaks later and the code compiled correctly.  Also setting the "clobber" registers to the call made it compile reliably.

This was a particularly difficult issue to track down as each time the code was changed and recompiled, it could have compiled differently, and some changes would "fix" the problem, even though they did not directly affect it.  This made the problem intermittent at best.

2011-05-04 - Delays and Sleep

So, I need to create some form of Timer_Sleep() function that works in a similar manner to my Timer_Delay().

Timer_Delay() currently spinlocks until the designated time ... functional, but not advisable.

Timer_Sleep() has to instead suspend the thread until the allotted time, then wake it up again.