Hello,
Linked below is some of the developer docs I've been working on for KnightOS. Most of the actual information is not there, but the idea here is to get the format down. Any suggestions on either the information you see or the format of the documentation would be greatly appreciated.
Download

1) Allows loading of 20 libraries - that seems arbitrary; where did you come up with that number?
2) Clipboard - pointer to RAM? I thought only one program could be in RAM at a time.
3) Why even have a FastCopy(Unsafe) routine? Why not just make everything use FastCopySafe?

1) That is how much RAM is dedicated to the lib table
2) No, several programs can be in RAM at once, this is how multitasking works. The pointer should lead to somewhere where the copied data is stored.
3) I've been toying with that idea, and will probably implement it soon.

Regarding point (2), you say multitasking here, but in your documentation, you discussing multithreading. Multithreading means letting a single program split itself up into several threads that get time-sliced. Multitasking means running many single- (or multi-) threaded processes (programs) at the same time. Which is it?

I mean tasking, thank you. Will fix in the documentation.

Aight, that makes more sense then, thanks. Do you have any mutual exclusion (mutex) mechanisms designed yet? Mutex locks are an important part of a multi-tasking or multi-threading system to ensure that certain single-user resources like the keypad, LCD, and link port are only used by one process at a time.

Having not heard of mutex type of things, no. However, routines like FastCopySafe are thread-safe and only work if the current thread has focus.

In other words, you simple di/ei around the FastCopySafe routine's body? More about mutexes:

http://en.wikipedia.org/wiki/Mutual_exclusion

For that particular routine, yes. However, if a program doesn't have access to a port, then the system routines for accessing that port will simply return.

A simple mutex method is here: http://www.junemann.nl/maxcoderz/viewtopic.php?p=65647#p65647
Qarnos used SMC to get around a lack of a test-and-set instruction on the z80.
The main advantage to a mutex instead of a di/ei wrapper is that a program which doesn't use the resource being mutex'd can still run, provided that the task switcher would still be running. (which it wouldn't be in a di/ei wrapper)
In short, a mutex essentially wouldn't freeze the system while the resource is being used.

That is an awesome little system there

Agreed, that's an extremely-impressive little nugget of code! Thanks for sharing that with us, calcdude.

I'll put some thought into this and get back to you all, thanks!

Just to be clear, you're providing multi-tasking functionality only, right? In that case, exposing mutex functionality to the userland programs will be less vital, but it's still probably something you'll need in kernel code.

Well, wouldn't it work out fine if ports had a thread ID associated with them, and only that thread could access them through system routines?

In theory, yes, but you'll still need some way to pass data to and from those *processes*, I suppose view memory buffers? You'll therefore need a mutex protecting those memory buffers

You mean bring data from one thread to another?
I will have shared-state threads, where both threads have the same registers and stack, but just different code. I also currently have SendToThread, which will put HL into a thread's cache, which can be retrieved with RecieveFromCache.

Say two different processes want to communicate with the keyboard. If they issue conflicting group selections, you could easily wind up reading the wrong keys. Therefore, you'll need a way to coordinate who has access to the keyboard port, either directly by a mutex or by a mutex-coordinated I/O buffer.

That's a good point. I could make a routine that would handle requests to access the keyboard. Also, threads will be frozen when they are not in focus unless they ask otherwise, so if a thread is not visible, it won't run.

Ohhh, then you don't even really need multitasking, just the ability to enter and exit tasks on the fly.