Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: calcdude84se on December 23, 2010, 12:16:19 pm
-
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! :D
This is my attempt at yet another third-party OS (hence YATPOS, which is not its name :P), 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 (http://code.google.com/p/partesos/source/browse/) and ask any questions you might have. (Like my goals for this project, for example)
Thanks for the support I know you'll provide :)
-
sounds cool! is this going to be put in the major projects section when it gets farther along?
-
I can only hope for that. :)
Edit: Merth asked on Cemetech about this, so I'll post my response:
Thanks for asking :)
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)
-
This looks interesting. I still can't wait for KOS, though. Are you going to be releasing a kernel as well?
-
The kernel is my first goal. To be honest, though, the way I'm designing it, the kernel is almost no code; things like the code that does memory management and file system stuff are not required to be part of the kernel. ;)
Yeah, I'm looking forward to KOS too. All the projects I am looking forward too ;D
-
This looks nice, calcdude! I hope you eventually finish it, as I am sure it would be a great asset to the community! :)
-
The kernel is my first goal. To be honest, though, the way I'm designing it, the kernel is almost no code; things like the code that does memory management and file system stuff are not required to be part of the kernel. ;)
Yeah, I'm looking forward to KOS too. All the project I am looking forward too ;D
I had already seen the page, but it used to be empty if I remember. Creating a topic will motivate you to code more on it :) Good Luck!
-
Kerm asked about my plans for directory structure etc., so:
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. I especially like the Unix tree. Does that mean USB devices get added to /dev. ;-)
No, but seriously though, that sounds good. I'm looking over your code for page 00 at the moment. Is there a list of all the RST calls?
-
I meant Unix tree more in the sense of how further file systems are mounted rather than being assigned letters. (in contrast to Windows)
List? The macros file contains short usage information on the relative substitution ones.
I've yet to generate actual separate documentation, though.
-
All this conversation reminds me of a Windows for Calculator... Windows OS, it could be a Shell App too.
An UNIX would be great too, though.
-
Interesting, I am curious how this will turn out.
-
Interesting, I am curious how this will turn out.
UNIX is Open-Source so will it be open-source? Just wondering.
@DJ: So do I...
-
Given that I have a Google Code project, it's open source ;)
(And, for now, licensed under the GNU GPL v2)
-
Sounds cool! So, this sounds like it's basically a super bare-bones setup, where you could change literally anything, am I right?
-
That's the goal, to make everything extremely flexible. To quote from Cemetech:
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.
-
I love being quoted. ;-)
I don't know, ever since getting an Android phone and seeing how it's run on many different physical phones, I've been interested in seeing OSes be very portable.
-
I like the portability approach :D
-
I like the portability approach :D
True, but I'm thinking unless we get some standardization among the OSes and what programs they run, with all the OSes we are getting, it's going to be a mess.
-
Oh I meant the fact he wants his OS to be easy to port among all z80 devices, even non-calc ones. But I agree that it would be best if ParteOS and KOS, for example, had some compatibility or converters so people don't have to write games and programs for 3 different calculator OS platforms.
-
Oh I meant the fact he wants his OS to be easy to port among all z80 devices, even non-calc ones. But I agree that it would be best if ParteOS and KOS, for example, had some compatibility or converters so people don't have to write games and programs for 3 different calculator OS platforms.
I'm actually working on a way to standardize stuff. But that's a secret project for now. ;-)
-
Cool to hear, that would be awesome :D
It would suck if the community was split, otherwise. Fewer people would play certain programs because they would use an OS that won't run them. Kinda like Linux vs M$ a few years ago.
-
Cool to hear, that would be awesome :D
It would suck if the community was split, otherwise. Fewer people would play certain programs because they would use an OS that won't run them. Kinda like Linux vs M$ a few years ago.
Yeah, I know what you mean there. The idea is to make OSes have the same core (Much like KOS does). With the delay of KOS, I'm wondering if it would be possible to... Oh, that gives me a great idea, dj!
-
Lol I am curious now :P
-
A compatability layer (kinda like Wine) is very feasible. I've been playing with ways to do this with TIOS<->KOS compatability.
-
A compatability layer (kinda like Wine) is very feasible. I've been playing with ways to do this with TIOS<->KOS compatability.
Well, with what I am thinking, you would have to re-write another kernel, or I would write it. But, it would allow any OS that worked with the KnightKernel to work with this.
-
Actually, I'm thinking of something different, involving precompilation. It would allow TIOS asm to run on KOS, and possibly the vice-versa. It would also allow PartesOS and KOS compatibility.
-
By precompilation do you mean essentially assembling the same ASM program for different OS's, with the aid of macros, presumably?
-
This is what I'm thinking of:
Copy the program data twice into RAM. In the first copy, scan it to find all the calls and all the lds. If the call lies within the program code, modify it appropriately so that it will call the correct address (for instance, if its a TIOS program that is $200 bytes long, and the calls address lies within $9D95-$9F95, its an internal call). For loads, change the address (if internal) to the second copy, or (if external), compare it with some SafeRAM values for the original OS and modify the pointers to match areas in RAM set aside to mock up the SafeRAM in the original OS. Then keep a jump table that leads to routines that are similar to commonly used routines in the original OS. Modify all external calls/jps matching one of these addresses to call your imitation jump table instead.
It wouldn't be perfect by any means, and there could be problems with SMC, but it could potentially run some programs across OSes.
-
Nice, that should work. Having to copy it twice to avoid corruption cause by substitutions isn't very satisfactory space-wise, but that ought to work. Theoretically we could do this to any cooperative foreign program, too. :D
-
Until having this spark o' inspiration, I thought running TIOS programs under KnightOS would be impossible. This would be really quite cool. I think applications would have the best compatibility for lack of SMC. DCS would probably tie into the KOS GUI system quite well, and there is heavy kernel support for most of MirageOS's functions.
We should work together to try and get good compatibility going between OSes. We could probably use a similar code base.
-
I think sheer architectural differences will be a problem there. Where you have a kernel call (presumably direct) I'll have a library call to a driver/library which is named for the program at runtime.
Your double-copy substitution method ought to help, though.
Also, how hard do you think it would be to give the programmer the ability to specify data sections for your executables?
-
What do you mean by data actions?
-
*sections
Parts of a program that are data. It would avoid the necessity to load in two copies of the program.
-
It would be quite an inconvenience on the programmer, I'm afraid. KnighOS is designed in such a way that it can be convenient to the developer and could still probably manage to handle an architecture with specified data sections for compatibility layers. Also, it makes sounds like an easy road to precompiled programs for location independence, and that stops SMC from being possible with calls, jumps, and relative loads.
-
I'm curious if there are any updates with this?
Do you have a features list anywhere?
-
Life's been getting in the way x.x
I think I'll be able to start progressing again soon, I hope :/
-
Life's been getting in the way x.x
I think I'll be able to start progressing again soon, I hope :/
Alright, good luck. Maybe after compat8x is done, you can make sure your OS works with it.
-
sorry to hear, I hope you have time before summer time. X.x
-
Is this still being worked on, or is it on hiatus?
-
Holy fuck, it's been three years (and one week). To be brief, it's on permanent hold. Sorry :( (Xeda reminds me it's in my signature, so I've taken it out)
I'm definitely still interested, at least theoretically, in making a TI-83+ series OS, with goals similar to the ones I've named for this project.
What happened, mainly, was that I was never sure how to achieve those goals while maintaining efficiency. (To save you from looking it up, my main goals were to have unlimited extensibility and abstraction. I don't know how much programming you've done, but unlimited extensibility, as I envision it, requires theoretical support for arbitrary-precision numbers (or at least 4-byte ones), which are not efficient. And unlimited abstraction requires that everything be indirected; I, again, don't know if you've done any assembly programming, but bcalls are horrendously slow in comparison to doing whatever they do directly, and I'm basically proposing making every external call a bcall.)
Of course, all this slowness is theoretical--the system never got to a state where I could see it for myself--but it was enough to prevent me from writing code. In retrospect, I do think I worried a bit too much, and there likely would have been optimizations available to help some (KnightOS's use of SMC to make relocation efficient is one example). After all, the whole thing is a hobby project, and it's not like blazing fast performance was ever an achievable goal ;). (To really give up on performance, maybe I should just make the OS a LISP interpreter :P)
Unfortunately, I'm now busy with other things. I've just talked myself back into doing this, which is unfortunate because I'm not sure I have the time. I think I will try this again, but it will be quite slowly. (Admittedly, anybody who's been following this has been doing so for years, so I think they can be patient :P). With luck, there'll be an update from me here within a month. :)
(And as a plus, if I design it correctly, it should be easy to optimize, at least in parts, due to the very separated nature of it. So I'm feeling optimistic again)
-
Hopefully you still have some time to be around. I understand, though, and it's nice to see you again btw :).
-
calc84dude is back! Woot! Rejoice!
Excited to see the results :)
-
Oh I meant the fact he wants his OS to be easy to port among all z80 devices, even non-calc ones. But I agree that it would be best if ParteOS and KOS, for example, had some compatibility or converters so people don't have to write games and programs for 3 different calculator OS platforms.
Calc games on Game Boys!
-
Is it possible to install a custom OS on a Game Boy/Game Boy Color anyway?
-
No, but maybe on the cart...
-
IIRC (too lazy to go double check) the OS on all mobile Nintendo gaming devices can be modified, but you have to have a cart/compatible media storage/somehow interfaced alternative storage device (i.e. a flashcart and a MicroSD :3 ) volume with code that will modify it, and a way to run this code.
Seems risky to me, as the OS could not be modified any other way and if you screw it up or modify it so that it cannot be changed again, you've essentially bricked a device.
-
IIRC (too lazy to go double check) the OS on all mobile Nintendo gaming devices can be modified, but you have to have a cart/compatible media storage/somehow interfaced alternative storage device (i.e. a flashcart and a MicroSD :3 ) volume with code that will modify it, and a way to run this code.
Seems risky to me, as the OS could not be modified any other way and if you screw it up or modify it so that it cannot be changed again, you've essentially bricked a device.
No I don't think so. IIRC The GB family has a ROM chip, The DS doesn't seem to be moddable, only the DSI and the 3DS have updates.
-
IIRC (too lazy to go double check) the OS on all mobile Nintendo gaming devices can be modified, but you have to have a cart/compatible media storage/somehow interfaced alternative storage device (i.e. a flashcart and a MicroSD :3 ) volume with code that will modify it, and a way to run this code.
Seems risky to me, as the OS could not be modified any other way and if you screw it up or modify it so that it cannot be changed again, you've essentially bricked a device.
In that case, I see a good googling would've gone a long way for me :P
DS Lite is definitely moddable, though: I've used programs that will do that for me, and will also skip the DS OS and go straight to the flashcart.
No I don't think so. IIRC The GB family has a ROM chip, The DS doesn't seem to be moddable, only the DSI and the 3DS have updates.
-
I'm not dead, I swear.
Update time:
The project is moving forward, slowly. (I like to get hung up on design issues)
There's more documentation than code at this point, mainly because very little has yet been implemented.
I'll update my sig with it, but the code's on GitHub and can be found at https://github.com/calcdude84se/partesos/ (https://github.com/calcdude84se/partesos/)
A note on the source code: I'm using Code Browser (http://tibleiz.net/code-browser/ (http://tibleiz.net/code-browser/)) and loving it; the source code is best read with it. The z80 language definition I made for it is attached to this post; you should use it if you use Code Browser.