MaxCoderz

mind putting me on the mailing list so I can watch anything happening with the project?

Yup, I mind You can watch the list here:
http://groups.google.com/group/calc-lovers/topics?hl=en

hmmm, applied to join, but it hasn't been approved yet.


here's my suggestions:

implement a basic CLI that allows the enduser to run programs, manage files and define things to be run at startup (start a shell of choice, start the VM, etc). Programs should be able to take arguments and such so you'll have to implement some sort of stack to handle that. Don't implement the VM with a GUI, have it be an app/program that takes an argument with a filename of the byte compiled program. Then allow any graphical shells handling filetypes to associate the byte compiled programs as a file of the VM app. Make the programs that require arguments define how many and what kind they need, and then if you decide to implement a GUI shell yourself, make sure that programs require arguments can be passed them at run time, from the GUI. for more integration with native programs, the VM should also be allowed to take a second argument that would be the name of a file you want your program running in the VM to try and open.


before I give any suggestions on RAM/Archive usage or possible file system setup: is this targeted at the 83+BE only, only the calcs with extra RAM pages, or both?

elfprince13 wrote:implement a basic CLI that allows the enduser to run programs, manage files and define things to be run at startup

That’s a kind of shell already, therefore a user-space application. The kernel provides an API to manage files and execute programs, anything on top of that is less interesting at this point.

elfprince13 wrote:Don't implement the VM with a GUI, have it be an app/program that takes an argument with a filename of the byte compiled program. Then allow any graphical shells handling filetypes to associate the byte compiled programs as a file of the VM app.

You’re not proposing anything new here.

elfprince13 wrote:Make the programs that require arguments define how many and what kind they need, and then if you decide to implement a GUI shell yourself, make sure that programs require arguments can be passed them at run time, from the GUI.

Well, I don’t think parameter passing conventions should be the business of the kernel. The only thing we need at the lower level is the ability to pass a pointer to the executable, which can point to arbitrary data. We’ll have enough time to worry about the details later.

All this is really early to talk about. First we need to have the base OS running, which does nothing but create a sensible environment to execute assembly programs in. User interfaces and higher level languages come later.

elfprince13 wrote:before I give any suggestions on RAM/Archive usage or possible file system setup: is this targeted at the 83+BE only, only the calcs with extra RAM pages, or both?

Definitely both.

CoBB wrote:

elfprince13 wrote:before I give any suggestions on RAM/Archive usage or possible file system setup: is this targeted at the 83+BE only, only the calcs with extra RAM pages, or both?

Definitely both.

There's a trick to that.

The 83+SE is completely discontinued now, any left on the shelves are left overs.
The 84+(SE) can't have an os installed on it the same way. It needs a 3rd party sender and for the 84+ to be exploited. Which can't be guaranteed if they keep updating the software.

Shouldn't it be possible to trick the software into thinking the OS is valid?

Jim e wrote:The 83+SE is completely discontinued now, any left on the shelves are left overs.

Sure, but there’s still a lot of them around. And most of the code wouldn’t be different anyway. Do you see any particular difficulty in supporting both?

Not sure if anyone is taking suggestions or if this has been suggested, but running any program would be nice (such as noshell, but it does not have to be able to run archived programs).

CoBB wrote:

Jim e wrote:The 83+SE is completely discontinued now, any left on the shelves are left overs.

Sure, but there’s still a lot of them around. And most of the code wouldn’t be different anyway. Do you see any particular difficulty in supporting both?

I think so, because of the extra Rom. I can't be sure, but I think that the regular TI-OS handles it by copying flash pages to a page that the black editions have as well, and then executing. But again, thats only from memory and I can't even be sure if that is hard to do...

A proper file system should abstract any differences in flash hardware from the kernel, so it that's the only difference I don't see a problem. But I think porting is very much not a first priority

kalan_vod wrote:Not sure if anyone is taking suggestions or if this has been suggested, but running any program would be nice (such as noshell, but it does not have to be able to run archived programs).

Sorry, we're not taking suggestions at this point.

And on the topic of running current Ti programs: it'll be an entirely new OS, and Ti-OS dependant software will not "just" run on it, it'll need porting or emulation (at the very least a recompile with a new include). You don't expect your Windows game to run on Mac OS or under Linux either, do you?

If you want to see this feature, you could consider writing an emulation layer on top of Vera yourself, as soon as we're done defining the kernel API.

I'm sorry I haven't been around so much, I have some great ideas about Vera but I'm currently figuring out google groups and the wiki... And on top of that I'm going to university (wich will bring a lot changes in my life), and I would like to make time for it.
Short said: you can put me on 'non-active' I should be able to continue in a week

Okay, thanks for the heads up.

Edit: For all interested in what we're discussing, and the decisions made as a result of those discussions, there is a read-only wiki available here: http://vera.timendus.com/

Feel free to discuss anything you read on the wiki here in this topic, but please realize that the actual dicisions are being made in the mailinglist and that your ideas may or may not be used or even noticed.

Okay, I didn't mean it to sound that harsh

Feedback is very much appreciated; please do tell us what you think and discuss the limitations of our ideas. We need to be kept in check

Bravo