Author Topic: KnightOS (Read 205597 times)

DJ Omnimaga · « **Reply #105 on:** August 04, 2010, 11:46:14 pm »

Sounds promising. Btw I forgot: What was the max size of programs? Is it the total RAM size (or close)?

SirCmpwn · « **Reply #106 on:** August 05, 2010, 12:10:00 am »

Most of RAM, yes. There is a little bit that the OS uses. You can't go past C000h, though, that's a hardware constraint.

thepenguin77 · « **Reply #107 on:** August 05, 2010, 12:40:18 am »

While things are still in the very early stages, what if you used page 83 instead of page 80 for the second ram bank. This wouldn't be compatible with 83+, but it would allow code execution everywhere. Or at least swap 83 in when programs are executing. This way, you are already better than TI-OS in terms of program size.

SirCmpwn · « **Reply #108 on:** August 05, 2010, 08:40:53 am »

Yeah, I may consider that. I'm also experimenting with the idea of removing the execution restriction from page 80.
I also got kld and kcall to work last night.

SirCmpwn · « **Reply #109 on:** August 05, 2010, 08:57:26 am »

Update
KnightOS now supports relative loading, jumping, and calling within executing programs via the kld, kcall, and kjp macros. This is how it works:
Before running, the code for kld hl, HelloWorld, assuming that HelloWorld is at 0015h, looks like this:
rst 08h
ld hl, 0015h
Now, KnightOS loads the program into RAM and executes it. However, programs do not know where they will be loaded at runtime. Let's assume that it is loaded into 8100h. When rst 08h is executed, KnightOS changes the code to this:
nop
ld hl, 8115h
This way, it is much faster and it never has to execute the rst again. The same method applies to kcall and kjp.

nemo · « **Reply #110 on:** August 05, 2010, 09:17:08 am »

i know it's hard to set release dates, but do you think you'll release an early alpha version sometime before the new year? it'd be cool to use it during the school year

regardless, nice progress. keep up the good work!

SirCmpwn · « **Reply #111 on:** August 05, 2010, 09:26:50 am »

I can almost guarantee an alpha or a beta (or a release) by the end of this year. Note the "almost."
I will probably have the full KnightKernel released by Sunday for programmers to build their own OSes on.

Deep Toaster · « **Reply #112 on:** August 05, 2010, 09:32:06 am »

Quote from: SirCmpwn on August 02, 2010, 10:58:54 pm

What do you mean? Users won't have access to the RAM, if that's what you mean. That's just stupid, and TI should have never done it. Put valuable user data in a place that is wiped everytime the calculator crashes or the power is lost?
* SirCmpwn smacks TI

So basically (in terms of the TI-OS), this means that everything's going to stored in archive and run from archive, right?

Quote from: SirCmpwn on August 05, 2010, 08:57:26 am

Update
KnightOS now supports relative loading, jumping, and calling within executing programs via the kld, kcall, and kjp macros. This is how it works:
Before running, the code for kld hl, HelloWorld, assuming that HelloWorld is at 0015h, looks like this:
rst 08h
ld hl, 0015h
Now, KnightOS loads the program into RAM and executes it. However, programs do not know where they will be loaded at runtime. Let's assume that it is loaded into 8100h. When rst 08h is executed, KnightOS changes the code to this:
nop
ld hl, 8115h
This way, it is much faster and it never has to execute the rst again. The same method applies to kcall and kjp.

Wow, that's great! Will it do that right after the program is called, but before the program actually starts?

Quote from: nemo on August 05, 2010, 09:17:08 am

i know it's hard to set release dates, but do you think you'll release an early alpha version sometime before the new year? it'd be cool to use it during the school year regardless, nice progress. keep up the good work!

What about the calculator's true purpose, though

ztrumpet · « **Reply #113 on:** August 05, 2010, 09:41:35 am »

Wow, that sounds neat! Nice progress Sir.

nemo · « **Reply #114 on:** August 05, 2010, 09:43:03 am »

Quote from: Deep Thought on August 05, 2010, 09:32:06 am

What about the calculator's true purpose, though

hmm... depends upon Knight's functionality then. I remember Sir did say that a CAS was something he hopes to implement. doubt it'll be in an alpha or beta though. hopefully enough math features will exist to get by. depends on how math-intense Trig will be for me as well.

Sir, will equation graphing and tables be implemented in the possibility of a beta?

Deep Toaster · « **Reply #115 on:** August 05, 2010, 09:51:15 am »

Quote from: nemo on August 05, 2010, 09:43:03 am

Quote from: Deep Thought on August 05, 2010, 09:32:06 am
What about the calculator's true purpose, though

hmm... depends upon Knight's functionality then. I remember Sir did say that a CAS was something he hopes to implement. doubt it'll be in an alpha or beta though. hopefully enough math features will exist to get by. depends on how math-intense Trig will be for me as well.

Sir, will equation graphing and tables be implemented in the possibility of a beta?

Wow, I actually totally forgot about graphing ... wait, this is a graphing calculator?

Graphing might actually be useful in certain places

thepenguin77 · « **Reply #116 on:** August 05, 2010, 09:59:59 am »

Sir, I was just thinking, how smart is your kld routine? I am just worried that if you had data like .db $45, $CD, $FF, $00, that kld would mess with it.

jnesselr · « **Reply #117 on:** August 05, 2010, 10:02:14 am »

So the start of an asm program will be .org 0000?

Deep Toaster · « **Reply #118 on:** August 05, 2010, 10:10:50 am »

Quote from: graphmastur on August 05, 2010, 10:02:14 am

So the start of an asm program will be .org 0000?

Oh yeah, about that: it'll still work with all the major assemblers, right?

calc84maniac · « **Reply #119 on:** August 05, 2010, 10:17:54 am »

Quote from: SirCmpwn on August 05, 2010, 08:57:26 am

Update
KnightOS now supports relative loading, jumping, and calling within executing programs via the kld, kcall, and kjp macros. This is how it works:
Before running, the code for kld hl, HelloWorld, assuming that HelloWorld is at 0015h, looks like this:
rst 08h
ld hl, 0015h
Now, KnightOS loads the program into RAM and executes it. However, programs do not know where they will be loaded at runtime. Let's assume that it is loaded into 8100h. When rst 08h is executed, KnightOS changes the code to this:
nop
ld hl, 8115h
This way, it is much faster and it never has to execute the rst again. The same method applies to kcall and kjp.

Nice, that's a great idea. It certainly removes the need for searching through the code manually and figuring out the difference between code and data. I assume the same rst routine is used for kld, kcall, and kjp? (btw, in the case of kjp, it might generate faster code to move the nop after the jump)

Edit: Also, are you making programs be loaded at memory addresses aligned to multiples of 256? This might be a good idea, because you will only have to modify one byte with this routine, and secondly programs can still have 256-byte-aligned lookup tables (which are very common in z80 asm)

Author Topic: KnightOS (Read 205597 times)

DJ Omnimaga

Re: KnightOS

SirCmpwn

Re: KnightOS

thepenguin77

Re: KnightOS

SirCmpwn

Re: KnightOS

SirCmpwn

Re: KnightOS

nemo

Re: KnightOS

SirCmpwn

Re: KnightOS

Deep Toaster

Re: KnightOS

ztrumpet

Re: KnightOS

nemo

Re: KnightOS

Deep Toaster

Re: KnightOS

thepenguin77

Re: KnightOS

jnesselr

Re: KnightOS

Deep Toaster

Re: KnightOS

calc84maniac

Re: KnightOS