Author Topic: KnightOS (Read 205735 times)

DJ Omnimaga · « **Reply #600 on:** November 30, 2010, 03:01:31 pm »

I'm not sure about that. Do the ROMs even contain them anyway, though? I think SirCmpwn included a ROM of WFRNG OS on ticalc.org and they let it in, so I guess distributing ROMs of third-party OSes is fine as long as no TI-OS code is included.

SirCmpwn · « **Reply #601 on:** November 30, 2010, 05:37:57 pm »

The boot pages aren't included in the ROMs I distribute. They are just FF over and over. KnightOS uses custom flash writing routines. And RAM corruption is not avoidable, but crashes are potentially recoverable, and infinite loops can be stopped.

Munchor · « **Reply #602 on:** November 30, 2010, 05:43:31 pm »

Quote from: SirCmpwn on November 30, 2010, 05:37:57 pm

The boot pages aren't included in the ROMs I distribute. They are just FF over and over. KnightOS uses custom flash writing routines. And RAM corruption is not avoidable, but crashes are potentially recoverable, and infinite loops can be stopped.

Great, that means less crashes and more performance!

SirCmpwn · « **Reply #603 on:** November 30, 2010, 05:46:26 pm »

Well, crash recovery is when it realizes it crashed at boot time, and offers to try and recover. It only tries once, though, so you won't get trapped. It may not work very well, but I guess we will see.

Munchor · « **Reply #604 on:** November 30, 2010, 05:53:56 pm »

Quote from: SirCmpwn on November 30, 2010, 05:46:26 pm

Well, crash recovery is when it realizes it crashed at boot time, and offers to try and recover. It only tries once, though, so you won't get trapped. It may not work very well, but I guess we will see.

I think that a less-crashable-OS-than-Texas's would be a perfect advertisement for KnightOS and it could get famous JUST because of that

willrandship · « **Reply #605 on:** November 30, 2010, 05:56:14 pm »

Plus, since all your files are already in the archive, it should already be much more safe for your files, right? The RAM is reserved for running programs.

SirCmpwn · « **Reply #606 on:** November 30, 2010, 06:44:42 pm »

Update
Hardware locking is now been implemented for the LCD port, and I am adding locks on the I/O, USB, and Keyboard hardware as well. Of course I can't entirely stop programs from accessing the ports, but I can ask them to play nice, and all of the official routines are compliant with hardware locks. The screenshot below is a demonstration of this technique, based on the same program from the previous update. There are two threads, both waiting for keypresses. Thread 01 is waiting on 1, and thread 02 is waiting for 2, and when those keys are pressed, they display their message. Thread 01 is also watching for S, however, and when it sees it, it releases the LCD and gives control to thread 02. In the screenshot, I alternate pressing 1 and 2, then press S every so often to switch LCD control. Both threads try to write to the LCD, but only one is successful, and I can change which one that is.
The KnightKernel is progressing extremely well, and all I have left is to add hardware locking to other ports, add one flash control routine, and implement the filesystem. Then it's just basic programs until the developer release.

Deep Toaster · « **Reply #607 on:** November 30, 2010, 06:47:05 pm »

Quote from: ScoutDavid on November 30, 2010, 05:53:56 pm

Quote from: SirCmpwn on November 30, 2010, 05:46:26 pm
Well, crash recovery is when it realizes it crashed at boot time, and offers to try and recover. It only tries once, though, so you won't get trapped. It may not work very well, but I guess we will see.

I think that a less-crashable-OS-than-Texas's would be a perfect advertisement for KnightOS and it could get famous JUST because of that

Except most students wouldn't even know the TI-OS crashes so much

And yay for another update!

SirCmpwn · « **Reply #608 on:** November 30, 2010, 06:48:11 pm »

Quote from: willrandship on November 30, 2010, 05:56:14 pm

Plus, since all your files are already in the archive, it should already be much more safe for your files, right? The RAM is reserved for running programs.

That is correct. Most crashes will never loose files.

However, no one seems to realize that TIOS is virtually bug-free, until you install some 3rd party assembly software on it that causes bugs.

jnesselr · « **Reply #609 on:** November 30, 2010, 06:49:29 pm »

And usb... Worked on that a bit today. Figuring out how to write programs to use it is going to be a pain, though. I still need to know how much of the usb routine I can use if any. I'm okay with using just the ports and writing our own routines. Your choice.

SirCmpwn · « **Reply #610 on:** November 30, 2010, 06:50:36 pm »

We should try to leverage the second boot page as much as possible, because it is read only, but there is plenty of room in the kernel.

DJ Omnimaga · « **Reply #611 on:** December 01, 2010, 05:37:46 am »

Quote from: SirCmpwn on November 30, 2010, 06:44:42 pm

Update
Hardware locking is now been implemented for the LCD port, and I am adding locks on the I/O, USB, and Keyboard hardware as well. Of course I can't entirely stop programs from accessing the ports, but I can ask them to play nice, and all of the official routines are compliant with hardware locks. The screenshot below is a demonstration of this technique, based on the same program from the previous update. There are two threads, both waiting for keypresses. Thread 01 is waiting on 1, and thread 02 is waiting for 2, and when those keys are pressed, they display their message. Thread 01 is also watching for S, however, and when it sees it, it releases the LCD and gives control to thread 02. In the screenshot, I alternate pressing 1 and 2, then press S every so often to switch LCD control. Both threads try to write to the LCD, but only one is successful, and I can change which one that is.
The KnightKernel is progressing extremely well, and all I have left is to add hardware locking to other ports, add one flash control routine, and implement the filesystem. Then it's just basic programs until the developer release.

I don't really get it, but nice to see this is progressing.

SirCmpwn · « **Reply #612 on:** December 01, 2010, 08:35:06 am »

This basically prevents two threads from both accessing the same hardware. There could be problems if two threads were trying to access the screen at the same time, for example.

willrandship · « **Reply #613 on:** December 01, 2010, 10:00:47 am »

That definitely sounds handy. Is there a way programs could lock a portion of the screen RAM? That way, two programs could use the scren at the same time, without conflict.

DJ Omnimaga · « **Reply #614 on:** December 01, 2010, 02:42:54 pm »

Quote from: SirCmpwn on December 01, 2010, 08:35:06 am

This basically prevents two threads from both accessing the same hardware. There could be problems if two threads were trying to access the screen at the same time, for example.

Ah, thanks for clarifying.

What if someone runs an ASM program that totally takes control of the entire calc, though, even disabling interrupts? Isn't ASM that powerful or will your program detect what code is about to be ran and prevents its execution like an antivirus?

Author Topic: KnightOS (Read 205735 times)

DJ Omnimaga

Re: KnightOS

SirCmpwn

Re: KnightOS

Munchor

Re: KnightOS

SirCmpwn

Re: KnightOS

Munchor

Re: KnightOS

willrandship

Re: KnightOS

SirCmpwn

Re: KnightOS

Deep Toaster

Re: KnightOS

SirCmpwn

Re: KnightOS

jnesselr

Re: KnightOS

SirCmpwn

Re: KnightOS

DJ Omnimaga

Re: KnightOS

SirCmpwn

Re: KnightOS

willrandship

Re: KnightOS

DJ Omnimaga

Re: KnightOS