2010-09-11 - More Vector Fonts

More modifications to the C# font renderer, adding all the glyph data into the code, and getting it to load glyphs at random, I think it is complete as far as it needs to be.

I have rewritten the wiki article on TrueType fonts to clarify some of the ideas that I was trying to sequence whilst tired.

2010-09-10 - More Vector Fonts

Few modifications to the font rendering program.  Little bit of work on the TrueType article.

2010-09-09 - Vector Fonts

After a break due to pressures at work and moving house, I have been spending this week working on a new angle, that of TrueType fonts.

I investigated Bézier curves (required for font drawing) and created a prototype application in C# to test the code.  Following that, I looked into the structure of TrueType font files and added the glyph data for a few glyphs into the program.

With a few teething troubles, mainly due to some of the data interpretation oddities not being explicitly defined in the specification, I have a mostly working font renderer.  This has not only given me valuable experience with the file format and a testbed to analyse different font files, it also means I can write an article on TrueType fonts in the OSDev wiki and use it in my OS for font rendering.

2010-07-18 - Makefiles!

Going to put some time this morning into figuring out the mysteries of Makefiles.  Given that my OS will very soon have multiple moving parts, I think it would be good to have one which will allow me to build specific sections.

2010-07-16 - More Library Loading

Finally spotted the stupid mistake which was causing my library initialisation to fail.  The initialisation function attempts to write out a debug string to indicate its progress, however, it called the Panic function before the module level variable had been set up, so it was calling a function of a NULL pointer ... doh!

Having fixed the stupidity, the library is loading, initialising, finding the printf function, and displaying a string.  \ o /

2010-07-12 - ELF Library Loading

A significant effort over the last two days, and I believe the ELF loader is finished.  The sections are loading correctly, the symbols are being found and processed, and the relocations appear to be complete.  Some debugging still needs to be done on the whole thing as attempting to call the library initialise function results in the code spinning off into the weeds and causing issues.  Oh well, that's an effort for another day.

Whoever said that ELF was easier than COFF was either stupid, lying, or has never dealt with COFF.  It's so much more straightforward because it's not built with millions of extensibility plans.  One symbol table, one section table, one relocation table, one string table ... thank you very much.

2010-07-01 - ELF Loading

To summarise the last month, I've been looking on-and-off at getting the ELF loader working.  I also found that the data store for my MemoryManager was not being cleared on initialisation (bad when booting in from DOS).  Additionally, it seems my kernel is much bigger than I thought, and setting the boot disk image to be at 0x17E00 isn't enough.  Oh well, another few K should fix it for now.

2010-05-30 - LD Problems

Ok, bit the bullet today and posted to the OS Dev forum to try to find out what I might be missing in the LD options.  The first reply came back suggesting that I needed to create a "none" targeted GCC (more specifically LD as that is the problem) which isn't completely helpful in it's own right, but has given me an idea.  The DJGPP and MinGW versions of LD only output PE files, so if I grabbed the source of LD and built it from scratch, would I be able to get it to support everything, including a COFF output?

2010-05-14 - PCI Sound

With the ATA save (mostly) working now and LD not playing ball with making sensible .o COFF files for me to load, I'm going to take a break from that side and advance on a different front.  I'm wanting to get some form of sound capability working (beyond the PC speaker) so I'm going to get back to the pci system.

A quick compare through the various versions that I have reveals that I haven't actually worked on this front since implementing the consolidated datatypes, so perhaps it is time to look at this anyway.  I also have my trusty PCI reference manual.

I haven't figured out how to provide a generic interface for the PCI system into the rest of the OS in the ideal world system, I imagine it will be some form of Bus Device with a context, but that's not important right now.

2010-05-13 - Debugging the Filesystem

Continuing the investigation of the corrupting filesystem.  It seems the first hurdle being failed is identifying the sector number of the start of the root directory, this is being read out as 6336 on a volume that only has 15Mb of space.  Upon further investigation, the driver believes that there ate 197 FATs on the disk and 32 sectors of reserved space.  Looking at the on-disk structure by hand reveals the expected 2 FATs and only 1 sector of reserved data.  I believe the problem is that something is writing outside it's allocated memory and trashing the FAT context object.  This could be tricky to track down.

I'm going to reimplement the ShowContext function through the DOS layer.  This will allow me to examine the context at each stage of the process and see at what point the values are being corrupted.

ShowContext() function reimplemented so that it's accessible from the front end via the dos layer ("ShowContext HD1:" ... Win!).  The values in it are definitely wrong for both HD0: and HD1: (the two hard drive partitions).  So, either it's not allocating enough space then being overwritten, or it's being overwritten by some misbehaving code, which can only be somewhere in the MOUNT command.

A modification to the ShowMem command so that it shows the exact allocated block at that location (if one exists) and a lot more poking later and it seems the problem is somewhere within the list code.  Adding the third entry to the DosDevice list seems to cause some memory corruption.  I'll tweak the mountlist first to see if I can confirm this, then look into why.

AH HA!  In the FAT context creation code, it allocates space for the FAT context and the boot sector (kept around for posterity), and it uses the BDD to determine the amount of space it needs to allocate for the block.  However, the hard drive is returning a block size of zero because that seems to be what is coming from the drive.  A mistake in the FAT code doesn't correctly account for this, causing it to allocate 0 bytes, and then write into it, which the next operation promptly overwrites.  Let's fix this.

\o/  It works properly now.  There are a few oddities, such as it only seems to use every other cluster for subsequent saves, but it seems to be behaving.

Identified a minor problem in the Dos subsystem where searching for "HD:" would find the first device starting with HD instead of specifically "HD:", but this was easily fixed, and a small modification to provide a global variable called CurrentDirectory which is used if no device name is identified in the given filename.

Moving on to look again at the modules now, it would be nice to be able to create a program that can be loaded, executed, then flushed, even if only for a demo.  This will also be useful as having the kernel itself depend on libraries will cause no end of trouble, so I can make the loaded modules (executables) do that instead.  So how about HelloWorld.exe?

Ok, so LD isn't playing ball.  Firstly it linked the two .o files into an MZ executable, then it linked the two files into a COFF file, but didn't actually tie up the references or combine the sections to produce a single COFF file.

2010-05-12 - Loading and Saving with the Filesystem

I have the ATA driver now implementing the BDD Interface, and I've also set up the mountlist to use the device.  I had actually forgotten that the mountlist system actually looks up the device symbols in the kernel library, and that I needed to add the AtaBDDI into the kernel library definition in order for it to work properly.

Little bit of debugging needed on the Ata Driver.  It seems it's not picking up the partitions correctly yet.  A minor mistake in the mountlist parser meant it wasn't getting the Partition number value correctly.

A few tweaks later and it seems to be creating the contexts correctly, as well as departitioning the drive ... om nom nom.  The type command (otherwise known as the fatload command).

In theory, I should now be able to combine the load and save commands to make a copy command.  Should be very useful in getting the library files onto the hard drive and whatnot.  To the batcave ...

Ok, so attempt one wasn't completely successful.  Perhaps when I was rewriting the FAT driver to use the generic directory search methods I may have missed something.  The file is loading, but is spinning off into some infinite loop when trying to save the file.  I suspect the FindFirst() call.

Ok, so the flag to allow creation of new directory entries (which will need to extend a cluster-based directory if needed) was not fully implemented and was not returning an empty entry in the root directory to be used for the new file.  Let's try this again.

The save was successful, but the new file wasn't found.  although I have a sneaking suspicion as to why, I didn't actually write the filename and whatnot to the directory entry before I saved it ... Oops.

Another significant change to the FAT filesystem driver, and one which should solve a bunch of potential issues.  I have created a routine which processes the Path and splits it into an array of strings (one for each directory) in the FAT 8.3 format (with correct spacing to match the filenames).  This should greatly ease the troubles of dealing with these names and comparing them for matches.  It will also handle generation of a save filename and fix an issue with ensuring the file does not already exist.

Everything in place, however, something is wrong now as when using the ATA driver, the filesystem is being corrupted in some way.  Needs more investigation.

2010-05-11 - ATA Driver

Looking back at the ATA driver today and trying to make it conform to the Block Device Driver Interface (BDDI).  Having to rework quite a few pieces of it, and make it implement the MountList parser to read the parameters it needs.  A significant modification above and beyond the Amiga implementation is the ability to specify the partition number, the device driver will take this and look up the range for that partition, and define the device accordingly.

I have also put a lot more work into the IdentifyDrive ATA command, mainly because the sector count and bytes per sector are required elements of data for the driver context.  For this, I have (finally) created a C struct to correspond to the output from the command (at least to ATA-1 specifications) so that this can be extended as and when required.

2010-05-10 - FAT FileSystem Interface

Finally finished reworking the FAT driver so that everything works through the FileSystem interface.  A few things are still missing, such as directory listings, but that's not important right now.  I have also (finally) implemented the ability to find a directory entry, edit it, then save it back through generic functionality, which saves greatly on repeated code.

2010-05-02 - How Processes Find the Kernel

In at the deep end today.  I've put together a structure that will be pointed to be a stack pointer in the initial state of every module loaded (library or process) that will give the code the "first step" in starting up.  I will almost certainly be reviewing this later, but it'll do for now.  All the code is being abstracted through process.c at the moment, but I'm going to have to extract this as it's more library.

2010-04-28 - Debugging Multitasking

It would be nice to review some of the UI stuff that I have lying around, but I really should continue to work on the library loading parts first, because then I can work on the UI stuff as a separate library, copy it onto the machine, and have it run.

Not only would the code then be separate and compiled independently, I could also use it as a testbed to test out the Library loading parts and start planning out the API layers that will have to exist between the different areas of the OS.

Ok, the first part that I am missing is the filesystem delete code.  As I'm currently working with a FAT filesystem in a single-threaded system, a delete procedure should be fairly straightforward.  I know, I don't really NEED this in place to be able to proceed with UI devlopment, but I've been putting it off.

Still reviewing the current codebase, and was pleasantly surprised to find that the process system is almost entirely implemented.  A process command initialises the system by hooking in the interrupt 0 handler, and a second processtest command initialises two process functions which each do nothing other than loop for a "long" time, then print a character on the screen.  All of this works perfectly.  If I were to work on this aspect of the OS, it would probably be good to produce a "Top" command to list running processes and also modify the Timer_Delay() function (which currently just loops until the tick counter is correct) so that it suspends the task for a given amount of time.  This would be much more efficient as my processes are spinlocking because they woudn't use any CPU time when not running.  They can't use the current delay function as they may well miss the expected tick count because they weren't running.

Ok, so that's TOP written.  It's horrible code, but it should work for now.

Next thing I need is a state value for the processes.  Each processes will either be the current task (running), be waiting to run (waiting) or suspended (sleeping).  Once I have this, I can then provide functions to change the state of a task.

It seems there is still some instability in the process subsystem.  I introduced a third task to observe the behaviour, and the system threw an Int13 after about 4 "A" iterations.  The Code Segment in the exception must be a mistake because it's reading 0xECD7, but nothing I have changes the CS pointer, so how has that happened?

A quick change to the child Processes and they now load their registers with specific values when they start processing.  Hopefully, this should not only allow me to test that their register values are being properly maintained, but also see which process it is that is causing it to crash (not that it matters, they are trivial and almost identical).  An added bonus is that I should be able to see if there's a phase error in the exception stack frame which would mean that the value displayed as CS is actually from a different register ... if it crashes again.

I wonder what happens if you perform an iret operation to a hlt instruction?  Does it go back to being halted?  Does the IP advance beyond the hlt?  If I have an "idle task" which infinitely halts the processor, can I just leave that running.  The processor will awaken as required, do things, then halt again.  Maybe have to experiment.

Ok, the processing code failed again, another Int13.  The CS pointer is still 0xECD7 oddly enough, suggesting that the failure is the same (or at least similar) as the one before.  The full detail is :

EAX = 0x00011816  EBX = 0xFFFFFFFF  ECX = 0x000A6DB0  EDX = 0x00011AA0
ESP = 0x0020040F  EBP = 0x00200443  ESI = 0x00000001  EDI = 0x00000048
EIP = 0x00000020  CS  = 0x0000ECD7  Flg = 0x00000008  Cde = 0x00010202

The Stack and Base pointers look perfectly valid for the values I'm using, which suggests that the interrupt information does not have a phase error, however the A, B, C and D registers do not have the expected values in them.  The command that was running immediately before this was interrupted by a character paint event (which happily completed within its time slice).

2010-02-25 - Debugging

A bit of debugging today and found why it was broken ... it helps if you don't overwrite your own stack when reading data.  Fixed that and I now have "OS-in-a-Bochs".

Considering how to implement a directory listing system, I can load files if I know what they're called, but it would be nice to be able to enumerate them.  Also finishing the FAT implementation of Delete would be handy so that I can overwrite files.  Oh, and the streams, always the streams.

2010-02-24 - Bootloading from a FAT Filesystem

Finished entering the code that I came up with last night, added a few tweaks to improve it, and also fixed some invalid pushes and pops.  First test suggests that it was successful, but an examination of the memory says it wasn't.  This problem was quickly tracked down to not having reset BX (the buffer address) back to 0, so it should have gone to 0x0600:0600 (or 0x06600).  After fixing that and a quick test, it loads the block successfully.  \ o /

Next I need to put a disk to the bootblock so that it is complete.  I think actually putting a kernel on may be a good start, and a load of other files just so that I can tell if sectors have loaded (instead of all zeroes).

The calculations for the start and length in blocks of the root directory have been successful, but the load is failing.  Going to examine the parameters being passed to the BIOS INT 0x13 call

The Drive and Head parameters were the wrong way round in DX.  Fixed that.  It's now loading the Root directory correctly, searching for the file, then loading the FAT correctly.  I don't think the search is quite correct though, it found the file even when I changed the filename to something wrong.

With one small exception, the first draft is complete, using 440 bytes of 512

First block of the file is being loaded correctly, but the FAT read to find the next cluster seems to have yielded incorrect results.

Fixed up the FAT reading code, there were a number of errors, and it seems to have read all the sectors of the Kernel into memory.  Just need to get the counter incrementing correctly so that they are not all written on top of each other, and it will be done.

Also need to test reading beyond Cylinder 0

\ o /  The counter is now incrementing correctly, and the kernel had been loaded, and I've put in the call to jump to the Kernel, and it's loaded up ... with 40 bytes of bootblock to spare

I am limited to the first 8Gb for loading the kernel by the BIOS, and I am also limited to 43'690 clusters by the cluster computation algorithm.  In fairness though, FAT12 is going to give up long before my code does.

As for performance, not so much.  The primary problem here is that I load the entire root directory into memory, scan that, then load the entire FAT into memory and scan that whilst loading the kernel.  Given that loading sectors from a disk is going to be quite slow, this may well be a significant performance hit.

Having done "the math" against a Windows XP formatted 1.44Mb floppy, the FAT occupies 9 sectors and the Root Directory occupies 14, so the "entire data" load that I was worried about clocks in at just under 12Kb, less than 0.5% of the disk ... so meh.

I still need to add retry code and a few failure paths, so I'll probably eat my 40 bytes fairly quickly.

In any case, I'm happy, I have a full FAT12 file finder and loader in 389 bytes of code (with some more for data)

The other avenue that this presents is the possibility that I could create a small FAT12 Partition on the Hard drive in my test machine and put my boot block in the first block of the partition, then have my OS booting from the hard drive (with a few tweaks).  I could then PXE boot a new kernel, and then get the kernel to save itself out of memory onto the disk.  It's no Windows Update ... but then again, this would work

Looks like I have some more debugging to do, just dropped the latest (~85Kb) kernel onto the disk image and it's failing to load.  Could be either filesize, or the location of the sectors, or both. :S  Back to the debugging ...

It has loaded 66 sectors, it is about to try to load cluster 0x034C, which I think is block 875, but I have tried to test them individually, and them seem to work.

2010-02-23 - Bootblock Development

Bootblock:
1)  Correct the origin issue.  My code has to run with an Origin of 0 so that I can relocate it to 0x7A00 with ease
2)  Set the DS register correctly, it is needed for accessing the memory.
3)  Remember that sector 0 is invalid
4)  Read to the end of the chain, not to the end of the file.  File size is irrelevant, truncation is futile, the sectors will be assimilated
5)  The teletype function is INT 0x10,AH=0x0E
6)  Add LBA-CHS conversion to the sector loader.  Means one register for sector numbers up to 65536 (32Mb disk)


Because I am loading the code at 7C00 then copying it to 7A00 out of the way, there is no meaningful value I can use for the Origin of the file except zero.  Anything else and I either need to add an offset to each jump and memory reference before the 7A00 switch, or to everything after it.

I have gotten the code to work now using an Origin of zero.  The code segment I was loading was a power of 16 out.  Never can remember that Segment:Address syntax.

If I use a single 16-bit register (in real mode) to represent my sector address on disk, that gives me only 65536 sectors which means a limit of a 32Mb disk with a common 512-byte sector size, or rather, that we can only read the first 32 Mb of the disk.

Given that the CHS translation of the BIOS allows us to read the first 8Gb, I'd like to extend the LBA mapping to use two 16-bit registers to store the value.

However, in order to then compute the CHS values from the LBA value, I need to perform "long division" and "long modulo" on the two registers separately and then combine the result.

So just trying to compute the algorithm now.

Hmm, upon further investigation, the DIV instruction actually works against a 32-bit register pair anyway, specifically DX:AX, and would allow me to address 2Tb of drive, not that FAT12 can effectively support a drive that big, nor that the BIOS CHS can actually address a drive that big.

Anyway, given that the INT 0x13 command requires specific values in specific registers, and that the 32-bit DIV instruction requires the use of other specific registers, I shall try to write a LBA-CHS conversion algorithm that takes advantage of these whilst being efficient.

2010-02-22 - Bootblock Development

Ok, change of tac for today ... using assembly to find and load a file from a FAT drive.  Should allow me to create kernel files and drop them onto a disk to be able to demonstrate on Bochs or a real machine, whilst also being able to take the same file and PXE boot it still.

Going to assume a file in the root directory with a known name that is within the reach of the BIOS functions

Wow, didn't realise how rusty I am on Assembly, four hours of development and I have fewer than 100 lines to show for it

2010-02-21 - DosDevices and Filesystems

Work is progressing on the Dos Abstraction layer.  The mountlist parser is finished, and the filesystem and device are being looked up by the library loader and accessed.  If found, they are being put into a DosDevice structure and added to the list of devices.

I have just finished the abstracted version of LoadFile (which used to be implemented by the FAT driver dierctly to load from the "current" FAT volume) so that it looks up the dos device in question("BOOT:"), find the Filesystem attached to it, and call the LoadFile routine on that filesystem, passing it the path of the file.

Onoes!  /o\  A memory leak has developed somewhere within the Dos_Loadfile routine.  It's leaking 32 bytes, but it is cause the available space for the file to drift by 544 bytes each time.  Something must be done!  One scheme is to modify MM_Malloc() so that it records the return address of the call to MM_Malloc(), that way, the address of the instruction that allocated the space will be on record.

Success!  With a little inline assembly, I have been able to read the address of the instruction that is calling MM_Malloc() and store it along with the used block entry.  When my used block is full (and the system is therefore going into a controlled fail) it writes out the top entries in the memory list so that I can see what the block size is and where it was allocated, and can track it down.

My file searching function (that finds the first directory entry that matches the filename) was being called, but the returned entry was not being freed in all cases.  That was fixed, and now it is looping the load quite happily with no leak.  \ o /

Memory leaks and allocators aside, I need to finish off changing the Fat driver so that it uses the Context and not any global variables.  A good place to start would be to remove all the global variables and then see where we are :)

Ok, so I have spent most of the evening re-writing the Fat driver to use a structure for its state instead of global variables.  This way it will be able to handle multiple Fat volumes at once.

Damn, that's why it doesn't work.  I need to implement the mountlist parsing within the Ram driver.  It needs to read the parameters and make sense of them.  However, on the up side, it did remind me the LoadFile routine needs to test for a DosDevice being passed, a FileSystemContext within that DosDevice, and for the Context to be flagged as valid.

\ o /  A quick implementation of the versatile strtol() string-to-long converter and I'm able to finish parsing the mountlist values into the ram driver, and it has found the disk image in memory correctly, and FAT has deemed that it is valid.

Now ... why is it throwing an interrupt 6 (Invalid OpCode) when I try to read the drive?

Fixed the invalid opcode ( was passing 0 instead of the context ) and put in the appropriate exception path for that too, and then fixed the general protection fault that it hit after that.  I was using a ternary operator without the correct parenthesis.  Instead of allocating 1024 bytes, it was allocating 2, then using 1022 bytes of other allocation's space with "predictable" results.

You can now request that the Dos layer load a file such as "Boot:test~1.lib" and it will look up "BOOT:" in the device list, find the FileSystem attached to it and tell it to open "test~1.lib", which will then use the BlockDeviceDriver in the DosDevice to read the "disk".

2010-02-20 - Streams and DosDevices

Investigated streams more, and I have created a "FILE" structure that actually just creates a queue buffer similar to those I already have.  It means that I can now use generic functions to interact with them, and improve their complexity later on.

Looking now at expanding the definitions of the device and file system drivers to head toward my previously designed Dos abstraction layer.

If I'm going to have to parse this mountlist in order to derive all the required information, it would make sense to implement the C library strtok function, which is what I'm doing now.

Ok, String_strtok() seems to work, and I copied the example mountlist in to test in on that.  A few tweaks and I should have the routine to parse the mountlist for the devices.

Dropped strtok because it won't work in this situation.  It would be valid to have no space between the name and the equals sign, which would leave us no room for the null terminator.  I have instead parsed the mountlist by hand into a "sanitised" mountlist string.  The sanitised string is then being parsed again and copied into the appropriate Dos device structure.  Now I need to change the Library loader so that it can return a reference to the library if it is already loaded, then get the Dos system to find the library (filesystem driver, device driver) specified in the entry and initialise the device.

I've updated the Fat driver and the Ram driver to expose their interface structures with a name that won't clash with other things, and I've added them both as entries in the Kernel library so that they can be found by name when referenced by the mountlist

The Dos system is now pulling the device and the filesystem out of the mountist definition and looking them up in the library.  I also have them calling the CreateContext routines and passing the definition.  Now I need to get the CreateContext functions to create the appropriate context element from the settings in the mountlist.

2010-02-19 - Streams and Lists

Ok, a few more ideas.  The library loader should, could and would (will) be easily adaptable to load executables.  They would be loaded into memory in exactly the same way, except instead of being linked into the library list, we just need to identify an entry point (main?), call it, then free the memory afterwards.  Perhaps some investigation of an executable COFF (like how to make one with DJGPP) would be good.

Started to lay down some code for the stream.  I've planned a small number of functions from the standard C library that should allow me to re-implement some of the buffers (such as the keyboard scancode, command, and video output buffers) using C standard.  This should also allow the stdin, stdout and stderr streams to be passable into files which can then use them as required.

Lists have been made doubly-linked, so that items can be added to the end.  They have also gained the ability to allocate "containers" to reduce memory allocations.  Each list will contain a linked list of containers within it, and each container holds a header and a number of list entries.  The list entries themselves are still doubly linked.  Currently, each container holds 18 entries (so the total size comes in just under 256 bytes) and so that will be 18 times fewer allocations for list entries.

Time spent this evening debugging the list improvements which were programmed blind.  The NextIndex wasn't being updated, and I wasn't setting the ListHead pointer in the add if it was the first element.  Should implement Remove as well.  The interrupt handler would benefit from this technology.

I should create a filesystem driver for Amiga OFS, and device drivers for the floppy drive.  However, both of these should be delayed until I have the Dos abstraction layer in place and have settled on the basic block device and filesystem driver entry points and structures.

Ok, so I was looking at the newly working doubly linked list and decided that a bubble sort algorithm (for functionality, not efficiency) would be beneficial.  A little while later, the system reminded me that I had improved the interrupt handler with a display of the registers at the time of the interrupt ... of course this meant the sort code was not 100% functional.

Success!  The bubble sort on the doubly linked list is complete.  A minor speed increase was gained by changing the sort so that it swapped only the values on the elements instead of the elements themselves.  Now back to the streams.

2010-02-18 - Library Loading

The Library Initialise routine is in place, and is exposing the String_kprintf function, brilliant, so now all I need to do is lookup that symbol and I get the routine out, so, to call Library_FindSymbol() ... oh wait ...

For historical reasons, it seems sensible to use memory address 4

2010-02-17 - Library Loading

Pah, the library loader is broken.  Having determimned much more information about the COFF format (the second time around), I stated work on the Library Loader V2, and it was going well.  After fixing a few little problems, it turns out the allocation is completely messed up; the data area's on the test area, and the bss is nowhere to be seen.  Oh, and everything is a variable, no functions in sight.  Damn!

After just writing an article about how the section table was one-based, I forgot.  The symbols were looking up their sections assuming they were zero-based.  This is why all the symbols were variables and not functions, and also why they were using the wrong pointer as their relative point and ending up on top of each other.

Success!  The test was successful and the DEADBEEF was returned ... Now how to use this technology?

I think I need to change the Command system to use a list instead of an array, and add the ability to add commands on the fly.  Modify the library initialiser to create a Kernel library with an entry point to the add command routine.  Have loaded libraries auto-initialise and add commands.

2010-02-16 - Atomicity So Far

Kernel codenamed "Atomicity".

Current situation:

• The kernel is still monolithic and being delivered over PXE.
• No streams yet, although they have been planned.
• Process code is in this kernel, and has been working, but is currently disconnected.
• The List code is singly-linked and works a treat.
• The Fat driver is working well after some teething troubles (the sector pointer wasn't advancing)
• The block device is currently a RAM drive pointing to an image being loaded after the kernel.
• Focus has moved away from the FAT driver.
• Focus has moved toward the library loader to again attempt to break out of monolithicism.

Plans

• Change the List to be a doubly-linked list
• Implement stream functions