I've been a bit reluctant to create a topic for this project of mine, but I feel confident enough that I will continue it, not to mention that a person or two have asked me to do this, so here's the topic! Smile
This is my attempt at a third-party OS, which I have chosen to call PartesOS.
I don't have much yet, mainly just some core code and lots of ideas yet to be realized in code, nowhere near enough to release a demo.
I'm not sure how much I want to write right now, so feel free to browse the most recently committed version of the source code at the PartesOS Google Code page and ask any questions you might have. (for example, my goals for this project)
What are your goals for this project?
Also, what is the correct way to pronounce "PartesOS"?
Thanks for asking Smile
My main goal is to be able to provide a powerful environment for coders.
The main things I will try to provide are multitasking and a capable library and driver framework. Although it has no practical import as of this speaking, normal executables would theoretically be able to run on any z80 device to which this OS is ported.
It's intended to be pronounced as "par-tays-oh-ess." The 's' in "Partes" is to remain unvoiced, though. ('s', not 'z', sound)
Edit: In other words, "partes" is pronounced as the Latin word.
Ah, I was initially thinking "Paar-teeez-oohs". Thanks for the clarification. Actually, I checked out your code at some point, but I forget what my takeaway was, so I will have to look again. May I ask why exactly multi-tasking (do you mean multithreading, actually?) is a goal?
Kerm, the code is a work in progress.
Why do you say that I mean multithreading? Allowing the running of multiple programs simultaneously is multitasking, isn't it? (At least I thought it was.)
Multitasking is a goal because... Okay, I don't really know why. However, the way I plan to implement libraries, drivers, etc. means that, even if I only allow one process to exist at a time, the framework is essentially the same. (Libraries etc. will essentially be processes with certain flags set.)
Multitasking is running multiple single-threaded programs at the same time. Multithreading is allowing each program to be separated into multiple threads for the sake of parallelism, which is more or less useless on calculators. Smile I suppose you probably do indeed mean multithreading, then; my bad. Smile It sounds like you're thinking well. Do you have any thoughts on what kind of file storage / file system you want to set up?
You meant to say "multitasking," right? Razz
Yeah, I've given thought to that Smile
Briefly, I plan for a Unix-style directory tree (if multiple file systems should ever become a concern) and allowing files/folders to be in multiple folders (so an explicit link type is unnecessary)
I also have plans for how garbage collection will be implemented. The next commit I make to the SVN repository should include near-full documentation on the file system.
Sounds good, glad you have it well-thought-out. Do you plan to store the file system entirely in RAM, in Flash, or some mix of the two? If one of the latter two, what special provisions are you making for the unique aspects of Flash (ie, resetting bits is easy, setting bits is hard)?
Yay! Competition! Several questions though, are you using the package I released with Asylum? I tried releasing it as TIC83+ in the Cemetech archives but Kerm was really busy that week and never really got around to it. Just curious because you started this topic exactly 3 days after I posted the source.

Aside from that, what kind of libraries will Partes have? Will it have a text based gui like TIOS, explorer based like MOS, or will you try to go graphical like DCS? Will it be more calculator based like TIOS or function based like Asylum? Do you have special features in mind, like OAM or anything thats inspired you from other devices?
Anakclusmos wrote:
Yay! Competition! Several questions though, are you using the package I released with Asylum? I tried releasing it as TIC83+ in the Cemetech archives but Kerm was really busy that week and never really got around to it. Just curious because you started this topic exactly 3 days after I posted the source.
I seriously doubt it; I'm sure he was his own very polished set of tools, because as he said, he's been working on this for many, many months, and I looked at it months previously on Google Code.

Quote:
Aside from that, what kind of libraries will Partes have? Will it have a text based gui like TIOS, explorer based like MOS, or will you try to go graphical like DCS? Will it be more calculator based like TIOS or function based like Asylum? Do you have special features in mind, like OAM or anything thats inspired you from other devices?
An excellent set of questions; I'll look forward to hearing what calcdude has to say.
No, Anak, all code in this project so far is mine, with some knowledge from WikiTI.
Kerm, most of that work was planning, but I guess that's important Smile
Right now my goal is to finish a minimal set of useful libraries that any OS built off of the kernel can use. (These are things like display routines etc.)
For the PartesOS itself, I'll probably start with a minimal user interface (terminal-style) and build up from there.
It will definitely be more styled after earlier computer OS's than anything like TI-OS.
Probably a defining feature is that I plan to make the whole design very flexible and modular. Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.
calcdude84se wrote:
It will definitely be more styled after earlier computer OS's than anything like TI-OS.

In the long run, what are you going for though?Explorer or full GUI?

calcdude84se wrote:
Probably a defining feature is that I plan to make the whole design very flexible and modular. Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.

You mean, like all the basic routines and whatnot would be in the kernal, and if you port the kernal to another z80 device the programs for it would run? Sounds kinda difficult.
calcdude84se wrote:
Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.
My personal opinion would be that that would be well-nigh impossible: how would it know the allowed pages for doing stuff, the ports to use for communication and memory mapping and all that, etc?
KermMartian wrote:
calcdude84se wrote:
Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.
My personal opinion would be that that would be well-nigh impossible: how would it know the allowed pages for doing stuff, the ports to use for communication and memory mapping and all that, etc?


I was thinking the same thing...
KermMartian wrote:
calcdude84se wrote:
Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.
My personal opinion would be that that would be well-nigh impossible: how would it know the allowed pages for doing stuff, the ports to use for communication and memory mapping and all that, etc?


The only way I see that happening is if part of the kernel actually handles commands based on what device it is on. Sort of like a preference file or something. So "displayLCD" would display the screen on whatever device it was on. And you would set up memory and stuff to handle it.

I'm not entirely sure, but it sounds interesting.
graphmastur wrote:
KermMartian wrote:
calcdude84se wrote:
Note what I said to Merth earlier, that, theoretically, if the kernel, memory manager, and basic drivers should be ported to another z80-based device, all other programs should just work without any porting. A bit ambitious, perhaps, but I'll try.
My personal opinion would be that that would be well-nigh impossible: how would it know the allowed pages for doing stuff, the ports to use for communication and memory mapping and all that, etc?


The only way I see that happening is if part of the kernel actually handles commands based on what device it is on. Sort of like a preference file or something. So "displayLCD" would display the screen on whatever device it was on. And you would set up memory and stuff to handle it.

I'm not entirely sure, but it sounds interesting.


Even if possible, it wouldnt work for all z80 devices, maybe the TI82, 83, 83+, 83+ SE, 84, 84+ and maybe a few other calculators with similar memory and port layouts.
Sadly, I agree with graphmastur and Anakclusmos, but if you could figure out some kind of fingerprint to identify a bunch of different devices, you could probably find a way to use the same kernel for a variety of devices as per graphmastur's suggeestion.
KermMartian wrote:
Sadly, I agree with graphmastur and Anakclusmos, but if you could figure out some kind of fingerprint to identify a bunch of different devices, you could probably find a way to use the same kernel for a variety of devices as per graphmastur's suggeestion.

I've actually been thinking of this a bit more. The idea of having multiple kernels for one device. I realized it was a bit insane, so decided to revise the idea just a bit.

Instead of having a kernel for a bunch of different devices, have a kernel for each device. Think of it as a way to even out all the differences between the devices so an OS has an even playing ground to work on any device. I'm thinking that the kernel would deal with memory and such, so that to the OS, there was just a huge piece of memory or what not, and let the kernel handle all of the details of that.

The OS would have to do screen updates for the particular screen size and color depth (if any) it was on, but that wouldn't be too difficult, I don't think.
We did some chatting about "dual-booting" tonight on HCWP that may or may not be relevant to this project. It definitely would take a ton of work, though.
I think graphmastur got it. I did say "...if the kernel, memory manager, and basic drivers should be ported to another z80-based device..."
The fact that all other things should just work after that should give you an idea of the level of modularity and abstraction that I'm aiming for. How practical that will turn out remains to be seen.
  
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
Page 1 of 2
» 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