I know, that's why I am not done with it. I am working on the file system which is required to use the "Launch" program. Otherwise, it can't find the programs in /usr/share/applications/
AHelper wrote:
I know, that's why I am not done with it. I am working on the file system which is required to use the "Launch" program. Otherwise, it can't find the programs in /usr/share/applications/
What kind of file system are you planning? Stored in ROM or RAM? Designed for the vagarities of that storage medium? Hierarchical or flat? Permissions/ACL bits? Name restrictions? Filetypes?
elfprince13 wrote:
KermMartian wrote:
allynfolksjr wrote:
How the heck do you pronounce this? GlassOS? or GlabOS. I can't tell if you picked the because it looked cool and wanted it treated like a "b", or because you actually knew what it was and wanted the double S.
Actually, I started reading it as GLaDoS, the evil AGI from Portal.


I also assumed it was a pun on GLaDoS.


As did I Smile
KermMartian wrote:
AHelper wrote:
I know, that's why I am not done with it. I am working on the file system which is required to use the "Launch" program. Otherwise, it can't find the programs in /usr/share/applications/
What kind of file system are you planning? Stored in ROM or RAM? Designed for the vagarities of that storage medium? Hierarchical or flat? Permissions/ACL bits? Name restrictions? Filetypes?


The data will be stored to ROM. Writes will be done to the file system index (last pages of ROM) on fopen, and data will be written to the file data on every fputs/fputc.

The file system will have no limit to filename length, and the only characters allowed are graphic characters (excluding '/' and ".",".."). Files will be stored in a folder parenting method, nothing new.

Like linux, the only way of getting file types is by checking the MIME-Type. So, yay. There will be no permissions as this is a single-user OS.

The heap2 method (the ROM's heap version) must use flags to decide read-only, deletion, compression, etc. so that will be fine. Files HAVE NO MAX SIZE! The files can be segmented all over the entire fs. The only problem is making a routine that is able to resort the data in the OS without exploding.

Any personal flames with ti's vat or comments on my method are very welcome as I am currently writing it all out Cool Good Idea
You are aware, of course, that you can only write 0s to Flash unless you clear a whole page? Have you planned for that? You didn't answer my question about hierarchy. Are there any special files? How are directories stored (unless there are no explicit directories, and directories are simply implied by files). I don't think calling file types "MIME types" is a good idea, because that's an established system and convention. I'd say you should create your own name and system.
KermMartian wrote:
You are aware, of course, that you can only write 0s to Flash unless you clear a whole page? Have you planned for that?


I already know about the 0's. That's why my heap2 calls are very careful to initialize empty numbers as 1's (flags are inverted, etc). And erasing the entire page is a sort of limitation. Since the ti84pse has a lot of ROM to deal with, it isn't that bad. But when the calc turns off (or when required), the fs will run a 'garbage collect' to re-malloc the data in a better order.

KermMartian wrote:
You didn't answer my question about hierarchy. Are there any special files? How are directories stored (unless there are no explicit directories, and directories are simply implied by files).


The file system is split into a few parts. First, the range 0x08-0x60(ish) is where all of the file data is placed. This only includes the actual data of files. At the end, the file system stores a separate list of malloc'd data, instead they describe names and relations of files and folders. A 'folder' is simply a bit in the flag field in the index sector that tells the OS that the name and related data stored is a folder. The files is the opposite.

(going into raw details)
The malloc'd data in the index uses a "unsigned int parent;" field to determine what folder the data is under. For example, if the user does

Code:
fopen("/usr/example", "w");

then the os will malloc data in the last sector in the fs and write "example" as the data, with the parent field set to the number of the folder '/usr' (from the unsigned int id; number). When the user does

Code:
fputc(FILE, 'X');

then the OS will malloc data of an unset length somewhere in the ROM (the page with most free mem) and will write that character to it. Once the user does

Code:
fclose(FILE);

then the OS will finalize the malloc'd data by setting the length and making sure that the "unsigned int frag;" (fragment) number is ++'d the right way. That is, in a nutshell, how the file system rolls.

KermMartian wrote:
I don't think calling file types "MIME types" is a good idea, because that's an established system and convention. I'd say you should create your own name and system.


True, but I was mainly referring to the idea, not the name. The OS doesn't do anything special with using a period, so, just like *nix getting a file's MIME-Type to see what kind of file it is, the OS will leave leave it up to the program to determine the types of files. Limited support will be given in the future, such as checking for binary symbols, patters, etc. may or may not be added way later.

Sorry, talked a lot. Neutral

<edit>
Small addon...
After trying to make the heap2 fail, it somehow... worked... I am still testing the fs, but so far flash writing doesn't look bad at all Smile The only issue is defragmenting the whole thing.
(above post too big -_-)

If anyone has any pointers on the best way to manage headers for absolute address calls in the OS will be welcome! I am currently using a php file to scan the starting address of functions and construct a header for it, but they tend to be ugly... I was thinking about jump tables... But not sure of the overhead
The TI-OS uses a set of fixed bcalls that in turn jump to their actual location in the OS, so that between versions you just need to call the same place. I would therefore think that a jump table would be your best bet. Also, your post above is not way too big at all; I read it, but I just never got a chance to respond. Smile
hmm... I guess I will have to use a jump table after all... I just had a lot of:

Code:
#define FUNCTION_FLASHUNLOCK 0x24D2

in a header file... it works, but oh well... I will have to modify the OS header again... I do have libraries (non-ROM 0) using jump tables, but I will try to merge that layout into ROM 0...

I will assume that the B_CALL is much faster than my technique (push, set page, jump, pop, return) since it is SDCC playing with function params. Very Happy

How do B_CALLs work internally, as-in how does it handle the stack? Or do the functions themselves deal with that?
BCalling is fairly complex; your OS should implement a cross-page calling mechanism in z80, assuming you know z80 ASM well enough. You see why those #defines are a bad idea in the light of constantly-changing routine addresses (not to mention the need to specify both the address and page of routines as your OS grows)?
This is the source of my library calling routine that I use for everything not on ROM 0, such as that monster printf, sinf, sqrtf, etc... It calls code in a library's header that will jump to the function from a jump table

Code:

void sys_execLib(byte page, unsigned int jumpID, ...) __naked
{
    // Stack looks like this:
    // Return (2), XXX (1),Page (1), Jump (2), .....
    // Uses 6 Bytes per library call
    __asm
    ;di
    ;    Save the state of the lib
    ;The stack will look like this:
    ;    page (1), return (2)
                     ld hl,(#_var_sys_lib_index)
                     in a,(#_Port_Mem_B1)
                     ld (hl),a
                     inc hl
                     pop de ; XXX (1),Page (1), Jump (2), .....
    ; push de
    ld (hl),e
    inc hl
    ld (hl),d
    inc hl
    dec sp
    pop af ; Jump (2), .....
    ld (hl),a
    inc hl
    ; sdcc wants the stack preserved!
    pop de
    push de
    ld (hl),e
    inc hl
    ld (hl),d
    inc hl
    ld (#_var_sys_lib_index),hl

    out (#_Port_Mem_B1),a

    ; Page set, stack is nice, go and call the jump code
    call #0x4006
    ; stack is  .....
    ; Clean up
    ld hl,(#_var_sys_lib_index)
; lib stack is:
    ;   Jump (2), A (1), return (2), old port (1)
                                dec hl
                                ld d,(hl)
                                dec hl
                                ld e,(hl)
                                ; DE is the jump
    ;push de
    push de ; jump, ...
    dec hl
    ld a,(hl)
    push af ; xxx,page,jump,...
    inc sp
    dec hl
    ld d,(hl)
    dec hl
    ld e,(hl)
    push de ; Stack OK!
    dec hl
    ld a,(hl)
    ; A is the old page
    out (#_Port_Mem_B1),a
    ld (#_var_sys_lib_index),hl
    __endasm;
    if (var_sys_lib_index == (unsigned int)(&var_sys_lib_stack))
    {
        __asm
        ;ei
        __endasm;
    }
    __asm
    ret ; Manual
    __endasm;

}


As for the absolutes, php is doing my slave work in parsing the code output and making the headers with addresses for me, so I don't mind at the moment...
Maybe you don't mind, but you need to think about non-you programmers making programs to run under your OS. Razz
KermMartian wrote:
but you need to think about non-you programmers making programs to run under your OS. Razz


I know Wink That's why I am concerned about my level of insanity... Don't even look at my build system, it may save your life

<edit>

So far, fopen is becoming a pain to write... I will have to spend 24 hours of celebrating when the thousand line section is done... I don't even want to know the compiled size of this Mad
Your fopen() is 1,000 lines of C code? May I ask how/why?
not just fopen, but:


Code:


   .globl _fopen
   .globl _fs_setupFileStruct
   .globl _remove
   .globl _fs_getFrag
   .globl _fs_getFragCount
   .globl _fs_setFlags
   .globl _fs_getData
   .globl _fs_getIndex
   .globl _fs_search
   .globl _fs_format
   .globl _fs_checkSanity
   .globl _fs_createFile
   .globl _fs_findSpace
   .globl _fs_createNode
   .globl _fs_parseFolders
   .globl _fs_getFolder
   .globl _fs_getNextPage
   .globl _fs_getNextID
   .globl _fs_isIndexLast
   .globl _heap2_check
   .globl _heap2_getFree
   .globl _heap2_malloc
   .globl _heap2_init
   .globl _flashWrite
   .globl _flashWriteArray
   .globl _flashErase


The total assembled size of that is 0x1319, aka 4,889 bytes... It can't be trimmed down that much
Doxygen is soo fun to use, therefore I put up the doxygen on my website:
Arrow https://cloud.ahelper.me/pub/glassos/man/index.html

(The web server is unstable, if it is offline, try again in a few hours, or days Laughing )

It only documents one file, but the others are soon to follow. Why do I have that being made? Because I forgot how parts of my OS work, what functions do... 5 minutes after writing them.

The OS is still being transformed from having test code executed in ROM 0 to having the tasking system set up and making a program launcher. Fun stuff
Okay, so can I see your USB code, and the machine code it translates into. Also, I hope you understand the consequences of making a device appear under a VID and PID such as this.
graphmastur wrote:
Okay, so can I see your USB code, and the machine code it translates into. Also, I hope you understand the consequences of making a device appear under a VID and PID such as this.


The USB code that I use is Arrow http://brandonw.net/svn/calcstuff/Linky/trunk/USB/

I am many revisions behind, as the USB code that I use is incomplete and I haven't been testing it. I can't really give you the machine code because the code uses GlassOS's global variables, such as:


Code:

__at 0xC136 volatile USBPeripheral* peripheralInterface;   //Pointer to USB peripheral mode setup/interface information


Besides, interfacing with C using asm isn't easy and secondly, the USB code has been intermixed with the ISR...

About the device name, well, what consequences are there when you can change the name of the device on-calc?

<edit/update> !!!

GlassOS is now semi-stable! Smile
I will be using it at this stage to fix my headers, multitasking, and write that annoying Linky front-end. After that, I will be able to finish the FS and GUI lib to make a release somewhere (soon, moving quickly)

Todo in order:

  1. Make a test GUI for Launcher
  2. Add in binary file support for the fs and finish glasslib3 (stdio functions)
  3. Create Linky,updating the USB functionality
  4. Create a USB backend and make QLinky (Qt4 frontend)
  5. Finish GUI Library
  6. Create multitasking functions (task-switching is a better term) and the rest of the core functions
  7. Finish Linky and Launcher
  8. Pre-release
  9. Create a large set of programs for use in GlassOS
  10. Create a gfx library and a game
  11. Tweek the OS for use on other calcs, including ones without extra RAM
  12. Final Release


Not that long away from getting something done Wink
I just want to reiterate what Graphmastur said about the technical and legal ramifications about VID/PID. As I bugged SirCmpwn to be precise with, also, are you writing multitasking or multithreading, is it to be pre-emptive, cooperative, or something else, and are you familiar with all the necessary operating systems/scheduler concepts?
KermMartian wrote:
I just want to reiterate what Graphmastur said about the technical and legal ramifications about VID/PID. As I bugged SirCmpwn to be precise with, also, are you writing multitasking or multithreading, is it to be pre-emptive, cooperative, or something else, and are you familiar with all the necessary operating systems/scheduler concepts?


Well, the VID/PID is just there right now to get it to work, although I plan to change it back to the original ti84pse numbers because, well, its the same device and the numbers are pre-set by the bios.

The multitasking right now is simply task switching. I may create a simple method of using a timer to change processes, but I am just using a single process at the moment.

<edit>

I didn't know of the legalities of the VIM/PID until just now (I just read the stuff on it). I see that I can't use my own vim/pid, but realize that I was simply using the dead:beef as a simple test; that will not be the final name. I will use the same descriptor in the boot (it is already set when the OS gains control) as I don't think that that will be an issue, will it?
  
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, ... 26, 27, 28  Next
» View previous topic :: View next topic  
Page 2 of 28
» 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