True. I think someone should write an editor allowing us to write Axe language programs and compile them.

As for crashes, I wonder how SirCmpwn plans to handle them... will the OS just clear the RAM like the 83+ OS or something like that? I hope it's not like on 68K calculators where you need to press a key combination due to removing a battery not unlocking the calculator...
Regarding the idea of an OS with built-in Axe support, I must say some variation of what I always say when someone suggests turning a popular concept or shell into an OS, for example Doors CS. I think it's awesome to make a third-party OS, but in the end I'm worried about the utility of doing so, as it seems to me so many more people would be willing to install an App with a shell or language or functionality and not lose the TI-OS (which they need to follow along in math class) than would be willing to install a new OS, which might not even have math support.
It would be freaking sweet if you could make it so that if someone ran AxE source, KnightOS would automatically attempt to compile it and run it.
KermMartian wrote:
Regarding the idea of an OS with built-in Axe support, I must say some variation of what I always say when someone suggests turning a popular concept or shell into an OS, for example Doors CS. I think it's awesome to make a third-party OS, but in the end I'm worried about the utility of doing so, as it seems to me so many more people would be willing to install an App with a shell or language or functionality and not lose the TI-OS (which they need to follow along in math class) than would be willing to install a new OS, which might not even have math support.
GRUB anyone? Dual-boot on a calculator ftfw! Laughing
That would be pretty epic Razz

On a more realistic note, I agree. I think a third-party OS would at the very least need an extensive Math feature, as well as some type of TI-OS emulation or mimicking, if not for "backwards compatibility"/easy-adaptation, then for *cough* fooling those who are suspicious of your calculator's OS validity/eligibility. Evil or Very Mad Laughing
Speaking of apps, though it won't work for Sir, making an OS that could also be an app to the TI-OS would be useful. (Yeah, it wouldn't be as fast, but w/e) Razz
Yeah, being almost forced to include math abilities to get a popular OS is annoying...
Compat layers... are fun Razz
This will probably address most of the questions that were asked in my absence.

I'm planning on writing a TIOS app that will install KnightOS.

Also, Kerm, the memory is layed out like this, as of this moment:
Bank0 (ROM\Page00): Common kernel functions, boot code
Bank1 (ROM): Temporary ROM data/code
Bank2 (RAM): Allocated executable RAM
Bank3 (RAM): Allocated data RAM

Bank1 is the most complex, because it will wear several different hats. It will be swapped in for kernel routines on different pages, swapped in to read from the KFS table, and swapped in to read from the file table.

So, kernel routines that exceed page00 will be swapped into bank1. However, the kernel is intended to be minimal, and there is actually a very good chance it can be contained on a single page, thus eliminating the endless swaps. The features I'm planning are mostly going to be based in the OS.

Dual-boot will be possible if both OSes use the KnightKernel. TIOS will not be possible without some serious and potentially illegal modifications.

Axe relies heavily on TIOS routines, I would guess from seeing what it does, and it would require a custom version of Axe to run under KnightOS.

I plan for KnightOS to include all the math functions you would get out of TIOS and much more, all delivered in a much more logical format.

Crashes won't usually be a big problem unless 3rd party programs start messing with the ROM manually, because users will not have any access to the RAM. RAM is reserved for program's usage. A clear of the RAM would mean you would loose unsaved data from any open programs, nothing more.
SirCmpwn wrote:
Crashes won't usually be a big problem unless 3rd party programs start messing with the ROM manually, because users will not have any access to the RAM. RAM is reserved for program's usage. A clear of the RAM would mean you would loose unsaved data from any open programs, nothing more.
Except that so many crashes are due to programmer errors that accidentally write RAM that they don't mean to. It's virtually impossible to come up with a foolproof way to prevent accidental writes to RAM, so crashes will be possible in some way until calculators get virtual address spaces. Razz
Well, no way could possibly be foolproof. I have considered a checksum system, though, which would check the integrity of the RAM when allocating memory. I'm not sure how I would go about implementing this, though.
SirCmpwn wrote:
Well, no way could possibly be foolproof. I have considered a checksum system, though, which would check the integrity of the RAM when allocating memory. I'm not sure how I would go about implementing this, though.
Huh, that's actually not a terrible idea, depending on how you implemented it. As you may or may not know, the TI-OS keeps a checksum of RAM during things like powerdown, and uses it to detect electrical-based corruption and reset the memory to a sane state. Of course, because of the way some of our ASM-based crashes occur, we tend to trigger that same protection mechanism. Your OS could easily decide to reset RAM to a sane state, but try to recover in some way, which shouldn't be the end of the world since you're planning to store the VAT/FS in ROM instead of RAM, correct? Which makes it occur to me that if you do indeed do this, you need to be careful to make it a file system that does very sparing writes.
The filesystem is stored solely in ROM, and the current methods of editing files involve minimal writes. Programs can load files into RAM for editing and specify a buffer to insert at the end for a little wiggle room. Once done, then the file is put back in ROM.
No VAT, KFS (Knight Filesystem). It is a directory based filesystem. As soon as I get the FAT driver done, you can optionally use FAT instead, although KFS is recommended.
Sounds promising.
KnightOS Information (PDF)
SirCmpwn wrote:
You're still abusing those tenses. Smile Looks nice though, and it inspired me that after Doors CS 6.6 beta is released, besides thinking about optimizations and features to add, I need to consider working on the manual and SDK.
Spec writing is a must for all major projects. Good to see something tangible up to read, Sir Very Happy

I'm trying to not get my hopes up too much (in no way offensively; this is a big project), but it's hard not too. Sounds like it'll be awesome if it makes it to a stable version Smile
swivelgames wrote:
Spec writing is a must for all major projects. Good to see something tangible up to read, Sir Very Happy
As discussed on IRC, I'm horrible at this and always end up with feature creep. >_<

swivelgames wrote:
I'm trying to not get my hopes up too much (in no way offensively; this is a big project), but it's hard not too. Sounds like it'll be awesome if it makes it to a stable version Smile
Sounds about the same as my view. Healthy skepticism combined with encouragement. I always fear that OS projects will go the way of Vera, though. Sad

http://timendus.student.utwente.nl/~vera/wiki/index.php/Main_Page
swivelgames wrote:
Spec writing is a must for all major projects.

I try to always have a basic spec for every project I make. Usually, these end up on my phone. Brainstorming is a very, very good way to figure out how to make something work, and writing it down lets you refine and optimize it.

swivelgames wrote:
I'm trying to not get my hopes up too much (in no way offensively; this is a big project), but it's hard not too. Sounds like it'll be awesome if it makes it to a stable version

I'm concerned that too many people are getting their hopes up. An OS is a huge undertaking, and one that I'm doing solo, so the pressure is really on. I don't want to disappoint all the people who are obviously excited for it >_<
KermMartian wrote:
swivelgames wrote:
Spec writing is a must for all major projects. Good to see something tangible up to read, Sir Very Happy
As discussed on IRC, I'm horrible at this and always end up with feature creep. >_<
Haha. Bah, once you get in the habit of writing simple specs it actually becomes habit when making projects. You should definitely practice. There's no specific "bad" or "good" spec. Just write one that you understand (since you're really the whole team in your projects, so the 'customer' and 'other team members' are all yourself Wink ). They really are quite useful. Just remember to write a reasonable spec, and once you've got the basics in there you can add the extra fluffy features in to the spec or keep them on the side for after the main product is finished. Smile

Spec's really help you keep yourself on track with your project and not veer off the road when you see a shiny light (new feature/idea) and crash the project. Smile

SirCmpwn wrote:
I try to always have a basic spec for every project I make. Usually, these end up on my phone. Brainstorming is a very, very good way to figure out how to make something work, and writing it down lets you refine and optimize it.
Amen! I always write notes in my phone or on my computer. Brainstorming is actually quite enjoyable Razz


SirCmpwn wrote:
I'm concerned that too many people are getting their hopes up. An OS is a huge undertaking, and one that I'm doing solo, so the pressure is really on. I don't want to disappoint all the people who are obviously excited for it >_<

KermMartian wrote:
Sounds about the same as my view. Healthy skepticism combined with encouragement. I always fear that OS projects will go the way of Vera, though. Sad

http://timendus.student.utwente.nl/~vera/wiki/index.php/Main_Page

My thoughts exactly. Pressure on a project is never a bad thing, just don't let it discourage you. ^^,
The notepad program on my phone takes about a minute and a half to scroll from the top to the bottom of the list of notes XD.
Hahah, same with mine Laughing

And I have a massive directory full of .txt files in My Documents. Very Happy
Update
*Re-working the KFS driver to be structured better for possible extensions in the future
*Added quicksort and random generation utility methods
*Took the splash screen out of the kernel
*Hammered out some bugs in memory allocation
  
Register to Join the Conversation
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.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4 ... 27, 28, 29  Next
» View previous topic :: View next topic  
Page 3 of 29
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement