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).
