Last edited by SirCmpwn on 14 Jun 2010 04:01:11 pm; edited 4 times in total

Hi there. Let me explain a bit about KnightOS.

You may have heard of it, but this is the first time I'm really showing a lot of detail about it.

KnightOS is based on the KnightKernel. I have spent most of my time thus far working on the KnightKernel. KnightOS is based off of the KFS, or Knight Filesystem, where the OS resides. KFS is a directory based filesystem that resides in ROM. The OS lives inside this filesystem, and the kernel will run /OS/boot.kxe on startup. At the moment, the KFS driver is only partially implemented.

The KnightKernel will use a multitasking based system to run programs. It uses the system interrupt to manage this. This has yet to be fully implemented, but programs must be location independent. A combination of RSTs and macros are provided to help facilitate this with little to no impact on the developer. The current plans are to implement real-time interpretation, but pre-interpretation is being considered. The tasker is partially implemented.

The last thing the KnightKernel does is manage the basic drivers. It manages a LCD driver, RAM driver, I/O driver, USB driver (as well as several basic drivers for usb devices), keyboard driver, a KFS driver, and a FAT driver. Already done is the LCD driver, RAM driver, keyboard driver, and KFS driver (the KFS driver is only partially complete).

The RAM driver manages memory allocation and garbage collection. The other drivers should be relatively self-explanatory.

The rest is done by the OS itself. The OS has not been started yet, excepting a simple boot program. What it will do is outlined below:

*Boot up, load what it needs to login
*Show the login screen (optional)
*Upon a successful login, it will show the "Castle" (name pending review), which is similar to a start menu
*From the Castle, users can run the programs they use most, or expand to all installed programs and run them from there
*Once a program is run, it is given a new GUIArea
*Only one GUIArea is shown at a time
*Similar to DCS, GUIAreas are not usually controlled by the program, but by the OS. The program defines their GUIArea (or uses a command line, alternitavely), and the OS handles drawing and updating it.
*Multitasking would normally be slow on most calculators. However, most programs will be waiting for input from the GUIArea, and KnightOS can cut down the multitasking if the program's GUIArea is not being shown
*Pressing the Graph button will open a list of the current GUIAreas
*Pressing Y= will open the Castle
*Programs can provide QuickIcons, similar to taskbar icons in Windows, that will be displayed at the bottom of each GUIArea
*GUIAreas do not take up the entire screen, but leave a small amount at the bottom for OS stuff
*The user can press any of the three remaining function keys to select the QuickIcons, and browse to the one they wish to interface with
*Programs that do not wish to use the GUIArea interface can request to use the entire screen instead. This requires user input.
*Programs wishing to use the entire memory can request it, and all other processes will be shut down at the user's approval.

Installing KnightOS will actually install an installer program, which will help set initial preferences and install the OS. These preferences include user name, calculator name, password, and more. It will also be able to load your TIOS variables into the KFS before formatting the filesystem so you don't loose your files. The user preferences will also have an uninstaller, which will reformat the filesystem to be compatible with TIOS.

KnightOS will take several forms, customized to what the user wants to do with it. Here are the current forms planned:

*General: For the average user. It will come with some simple programs and the full math suite
*Developer: Will not include the full math suite, but only basic tools. Will also include Mosaic and several developer tools.
*Gamer: Optimized for gaming, it will come pre-loaded with popular games
*Ultimate: All programs and features

Edit: Changed tenses to be appropriate. The ones that are in present tense are correct, so stop being a nazi, Kerm.

Wouldn't some of these be mutually-exclusive? In other words, in order to include all the standard math features, wouldn't you need to remove some of the games or developer features? Actually, I personally don't see any point in not just having a single Ultimate version with all the features included, if you could indeed fit everything together.

*Well the upside to it having all features built in would be that the OS would get attention, but the downside would mean a lot of hard work by other people would be absolute and a lot of people would be PO'd

*Well the upside to it having all features built in would be that the OS would get attention, but the downside would mean a lot of hard work by other people would be absolute and a lot of people would be PO'd

Ah, that makes sense. Also, am I to understand that no program is allowed to use the full 96x64? It would seem that would give you a huge disadvantage in terms of convincing game programmers to use your OS.

Also allow me to make some corrections for the sake of pedantry.

SirCmpwn wrote:

Hi there. Let me explain a bit about KnightOS.

You may have heard of it, but this is the first time I'm really showing a lot of detail about it.

KnightOS will be based on the KnightKernel. I have spent most of my time thus far working on the KnightKernel. KnightOS is based off of the KFS, or Knight Filesystem, where the OS resides. KFS will be a directory based filesystem that resides in ROM. The OS will live inside this filesystem, and the kernel will run /OS/boot.kxe on startup. At the moment, the KFS driver is only partially implemented.

The KnightKernel will use a multitasking-based system to run programs. It will use the system interrupt to manage this. This has yet to be fully implemented, but programs must be location independent. A combination of RSTs and macros will be provided to help facilitate this with little to no impact on the developer. The current plans are to implement real-time interpretation, but pre-interpretation is being considered.

The last thing the KnightKernel will do is manage the basic drivers. It will manage a LCD driver, RAM driver, I/O driver, USB driver (as well as several basic drivers for usb devices), keyboard driver, a KFS driver, and a FAT driver. Already done is the LCD driver, RAM driver, keyboard driver, and KFS driver (the KFS driver is only partially complete).

The RAM driver manages memory allocation and garbage collection. The other drivers should be relatively self-explanatory. Does it already perform Garbage Collection?

The rest will be done by the OS itself. The OS has not been started yet, excepting a simple boot program. What it will do is outlined below:

[snip]

KnightOS will take several forms, customized to what the user wants to do with it. Here are the current forms planned:

*General: For the average user. It will come with some simple programs and the full math suite
*Developer: Will not include the full math suite, but only basic tools. It will include Mosaic and several developer tools.
*Gamer: Optimized for gaming, it will come pre-loaded with popular games
*Ultimate: All programs and features

Well, you have to consider the years of hard labor involved in the shells and addons people have created over the years such as usb flash drivers, drawing functions, etc. people might be ticked to see their projects end up like NSYNC.

Basically, i'm saying you should leave programmers room to grow, that why so many people program for TI.It has little to offer and needs improvement.

wow, this is intense, I was thinking, are you going to make something that will allow us to format USB storage devices to KFS? Also, how much control over the filesystem will we have? like will we be able to access all areas? Another thing is; how long is the boot process? if it's long enough will we be able to have editable boot images or something?

wow, this is intense, I was thinking, are you going to make something that will allow us to format USB storage devices to KFS? Also, how much control over the filesystem will we have? like will we be able to access all areas? Another thing is; how long is the boot process? if it's long enough will we be able to have editable boot images or something?

1) Yes, you will be able to format USB devices. You will also be able to boot to USB devices.
2) You will be able to read and write from every page except the kernel pages and the certificate page from the GUI. Of course, all programs will have access to the full Flash if they unlock it.
3) The boot process right now is all but instantaneous. I don't notice a delay. As I add more stuff, it might be longer. However, there are different key combinations that you can use on startup to perform various tasks, such as dumping the ROM or testing the drivers, and eventually, booting into different devices or partitions.

Ah ok, are you going to include computer scripts for formatting?
Hmm, with USB devices could you 'install' the TI-OS on it and dual boot? so like, in the filesystem, what folders are off limits? also, what's the basic filesystem look like?
Are you going to write a scripting language for it? like bash or batch?

No folders are off limits, some just have warnings. Everything in /OS/ has warnings.
It has total incompatibility with TIOS. There is no way you could possibly make TIOS run on KnightOS. Period.
A command line is planned, and you can script it in a similar manner to how you can script for a Windows PC. I don't know enough about Linux to compare the two.
The basic filesystem is based on the KFS, which is still under development. It is a directory based filesystem without flags, meaning that there are no readonly flags, or Date/Time stamp, ect. I don't quite yet feel too comfortable posting details about that one, because it is nowhere near close to complete.

ah ok.
No what I meant is like booting off of a USB on a computer, you just use the USB as the ROM instead of the devices ROM.
sweet! I'm defiantly going to be abusing the scripting then
ah ok, well I can't wait for when you are

xenonparadox, very funny
Eeems, how the filesystem driver works is that it only copies files to RAM for viewing and editing, and then copies them back to the filesystem. (Potentially). To boot from the USB, it just copies files from the flash drive to RAM, instead of ROM to RAM.
Deep Thought, probably not Basic, that has yet to be decided, though. Remember that this is lightyears away from even an alpha. However, assembly is going to be supported.

Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.