But you still didn't specify if it's cooperative or preemptive task switching. Since you said you may create a simple method of using a timer to change processes [in the future], I am going to assume that you're doing cooperative multitasking.

Sorry, I was responding from school... while writing a paper... and I still am...

I guess that I am doing preemptive task switching. I do have to note that the multitasking feature isn't finished. It is able to set up processes, but I haven't have the OS stable enough to conduct enough tests on the subject. I am concerned about my GUI library and adding features/fixing bugs. I should have pictures of it soon. Multitasking will occur sometime after that, so stay tuned

The basic process creation function was made, so I can now run multiple programs. I don't have any other supporting functions, such as ISR stuff for task switching keys, process swapping, etc..

A logo for GlaßOS was done simply with the "Domestic Manners" freetype font as a 16x72 image. The GUI is working and will be tested with the Launcher program. I am still adding on features/tweaking things in the library, but pictures/animations will soon follow. Once I have done this, I will finish the file system once and for all.

I'm glad you understand the implications of that. Not fun legal trouble. There are some test VIDs you can use, though. (Me thinks)

Also, are you hosting your code anywhere we can see?

Not yet as my code is really painful to see. I will clean it up and do something with it... And so it would be best to leave the VID/PID as it is?

Also, so far, I have over 8065 lines of C code in the project. I am trying to get pictures out but maybe not today...

You can if you want, just don't release it with those. I wouldn't actually go with TI's either. What to do, what to do. Kerm should buy a VID for cemetech. That would be awesome!

Yes, because I have lots of thousands of dollars to spare. I think when Cemetech goes public we'll have to get a handful of VIDs, though. Anywho, preemptive multitasking means there is a timer or interrupt that switches tasks, whether the tasks like it or not. Cooperative means that each task must voluntarily give up the CPU to let other tasks run.

um, thousands of dollar$... I could release the code without the descriptor and give a load of legal cheese talking about making your own VIM/PID to use the USB with the usual "provided as-is and author takes no responsibilities of user-made descriptors" and let it fly... But that's only an idea, nothing solid yet



See, that's why I was aiming for more custom, as it can be both or neither. The OS can run in dedicated mode where only one program runs with limited ISR stuff where the program must manually tell the OS to switch tasks, such as a USB program that needs to be in the foreground.

The OS may in the future offer multitasking, but I have been exploring the idea and don't have many uses for it. If anyone has any applicable ideas of full-blown programs that need to run in the background, I'd like to hear

I said neither because programs are allotted a certain amount of time to run before they are switched out to another one, but only to ones that request it. Also, a program can, say, enter a key loop, reset the task timer, and halt in order to let other programs run when the foreground program isn't doing much of anything.

No offense, but I think that that's a pretty terrible idea. I would strongly discourage doing that.

I know

I still don't know about the VID/PID. I am simply using the descriptor that was from Linky (which was from TIOS). Any other suggestions besides buying a VID/PID?

(As a side note) Yeah, sdcc is being a pain and deciding "Oh, you shouldn't have that char*, *removes from stack*" It is making my GUI library explode

Use TI's? Or, if you want, and this isn't legal either (MeThinks) but you could use a different product ID.

Hey, Kerm, I seem to remember some companies allowing test VID/PID pairs. Does it ring a bell with you?

That rings a bell, but I can't think of any exact examples. I think some Googling at this point might not go amiss.

Using TI's ID's is perfectly legal, that would be like saying you have to use a different mac address for your router if you put custom firmware on it. You can change the other descriptors to differentiate yourself. And since you are using linky based code you should be able to support TI's dusb protocol, which IMO is the best route for compatibility reasons.
I know you plan on having a different FS layout but reusing TI's file format for programs and other files wouldn't be a bad idea as well. This way you can use existing programs for sending and recieving files for ease of use for the users.

(1) Yeah, the USB group states that the VID is owned by the vendor and is only set by USB-IF and the PID is set as the vendor sees necessary. TID's, however, are... lacking info... I am not 100% sure if it would be legally safe to distribute (even though it can be linked to a pre-built linky)

(2) I am not using the virtual packets, that will be up to the individual programs.

(3) Like I said in the original post, this is a complete replacement OS. When you say "TI's file format for programs", do you mean the VAT or how the asm program is laid out? Also, tilp can communicate with linky, but it doesn't handle things like communications with plugins or raw network data (wink wink)

1. The VID and PID are linked to the device not the OS so it is perfectly legal to use them, in fact that is what you should do in this case.

2. So you are not planing impelementing your own or any existing USB protocol? Really IMO it would be in your best interest to mimic TI-OS's current protocol with possibly some of your own extensions. If not you will have to write your own linking program as libticables2 is meant for talking via TI's protocol and nothing else.

3. I mean use TI's on computer file format, IE .8xp with some customizations to the actual data so that you can just send them via TI-Connect or TILP and then the OS will read the data section and store them as your FS expects. While this may require more code on your part but would make life easier for the user.

The final option is to just write a linking program, file format and everything from scratch and while this is more work it does allow you to customize everything for your specific OS.

No matter what you do you will have to have some way to send files to and from the calc and so you will have to put some thought into how you want that done.

I think I agree with all of those points above. Surely you can pretend to be the TI-OS for the sake of linking programs and then just reinterpret what you get calculator-side?

1 I do see your point and agree. The USB-IF implies that the VID/PID are assigned per-product, not per-software.

2 If you look at the Linky code, I simply use the bulk transfer functions. The protocol is determined by the client program. Why? Take this as an example. I am planning on porting the Linky's HID Mouse driver. In order to do this, the client program will use the USB commands to reconfigure the descriptor and will use the bulk transfers to send mouse movement to the computer. (If someone really wants to, you can make the ti84 act as a gCn bridge to take IO <-> USB)

3 So you are basically saying to encapsulate the data in a specific format, such as the 8xp, 8xk, 8xu, etc.? The calc will be able to read the same data on the computer. It doesn't make sense to do this for this OS because then you can only have 2: executables and non-executables. I understand that such extensions would be user-friendly, but that just isn't applicable for this OS.

I am indeed writing my own linking software. It will be made for Qt/KDE. It will be able to use a plugin system in order for client programs to get data from a computer, such as grabbing file data, IRC, network connections, etc.. I already have libusb1 working and sending data to the calc. It should be fun writing a Qt app again


As a side note, I am still fighting with my GUI library. I will update the example program on the first post and post a quick update later on showing the main features of the library. Pictures, um, are needed at this point.

<edit>
The reason that I can't make the TI-OS protocol is because the OS doesn't do anything with the USB other than run the ISR and because the OS isn't in charge of managing the USB, other programs are. I am trying to make the OS as configurable as possible. If someone wants to write a program that uses the TIOS protocol, then GlassOS will allow that.

Your missing my point, you need to send files somehow and I am saying in place of writing your own protocol just use TI's. When you send or receive the file it would appear to TILP, TI-Connect, etc as say an appvar but really the data section of that appvar has extra metadata for your file format. On calc you ignore the header and just parse the data section and store the file via w/e storage you have planed while still not requiring users to install extra software on their computers.

But tilp/ticonnect (afaik, brandonw hasn't gotten linky to work with ticonnect) can't handle the file naming. It's like saying take an ext4 hard drive and strip out all of the folders, renaming them to 8 chars, and then not showing which file is which. Take:


Code:

This wouldn't convert easily at all, given that doing basic resizing and stripping would give:

Code:


Not to mention that you can't create folders, so you basically can't send files to the calc because the fs wasn't made to do that. Even if the calc program allowed the user to choose where every file goes, which file is being acted on, it just makes it harder than needed. Even if you rename conflicting files, it isn't possible as you can have 4,681 files with the same name and tilp would most likely hate you for it. It isn't humanly readable if all of your files suddenly become "spre4352" instead of "/home/some folder/spread sheet" (not saying that I would think of anyone actually doing this, but in theory).

:-S

Which is why I was saying your could embed that info into the appvar when it is actually requested and programs linked on the computer would already include that info as part of the data section of the appvar. But yes passing unique names to the linking program would provide a challenge along with many other issues.