I hope you do finish it. It'd be fun if you and LAX 18 collaborated while seeing who could finish first, but idk about that.
jcgter777 wrote:
I hope you do finish it. It'd be fun if you and LAX 18 collaborated while seeing who could finish first, but idk about that.
I will still be working on this, but I would also like to help with LAX18's shell, maybe provide a new code language or something?
I have a question. Will BOSSlibs be implemented into BOSShell? Or will they be used to make programming BOSShell easier? (or something else?)
After a few months of not working on it at all 
, I have finally decided to start working on BOSshell again! 
Have I made progress since the last update, you may ask?
Not really...
But after restarting the code again
, I have made some progress in developing the idea and eventual program that is BOSshell.
So, I have some new ideas to make this shell something to acually use, rather than speculate whether I will ever finish it.
I have decided on a number of TO-DOs (likely to change, as usual )
TO-DO:
-the entire code
-optimizing the new gui
-optimizing the filesystem
-optimizing the file formats
-especially the executable formats
...
And a lot more by the looks of it!
But Beck, why do you bring this up now, after so long of a standstill?
Because I realize that I have made promises that I have not kept, and I am now in a lot better of a space (and better at ICE-ing) to make this dream a reality.
...
So, without further ado, I present (most) of my ideas for a better BOSshell right here!
DISCLAIMER: This is a promo, not an ad
COMING TO A CE NEAR YOU:
https://drive.google.com/open?id=1XMELtQilfa_VCOzOwuGDOm2fGwqQyQno
EDIT: Cemetech doesn't seem to like embedding google drive links
I hope you all enjoy it!
(but some more than others. Like I said earlier, I have promises to keep
)
, I have finally decided to start working on BOSshell again!
Have I made progress since the last update, you may ask?
Not really...
But after restarting the code again
, I have made some progress in developing the idea and eventual program that is BOSshell.
So, I have some new ideas to make this shell something to acually use, rather than speculate whether I will ever finish it.
I have decided on a number of TO-DOs (likely to change, as usual )
TO-DO:
-the entire code
-optimizing the new gui
-optimizing the filesystem
-optimizing the file formats
-especially the executable formats
...
And a lot more by the looks of it!
But Beck, why do you bring this up now, after so long of a standstill?
Because I realize that I have made promises that I have not kept, and I am now in a lot better of a space (and better at ICE-ing) to make this dream a reality.
...
So, without further ado, I present (most) of my ideas for a better BOSshell right here!
DISCLAIMER: This is a promo, not an ad
COMING TO A CE NEAR YOU:
https://drive.google.com/open?id=1XMELtQilfa_VCOzOwuGDOm2fGwqQyQno
EDIT: Cemetech doesn't seem to like embedding google drive links
I hope you all enjoy it!
(but some more than others. Like I said earlier, I have promises to keep
)
Well, today's been a very productive day!
I have managed to get a lot of work done on BOSshell!
(just some bugs regarding the 'r' token)
DONE:
-Protocol for '.bxe' files (bytecode and source codes complete)
-General protocol for BOSshell files
-Protocol for '.txt','.lnk','.img' files
In Progress:
-Protocol for '.htl' files
-Homepage (50% complete)
-Foldersystem (read (75%), write(0%))
-Entry Password (75%)
-New and improved input routine! (80% complete)
TO-DO:
-editors and viewers for a variety of BOSshell file types
-'.bxe' file executor
-Protocol for '.sty' files
-Protocol for directories (these are not files, they are associations in the folds file)
IMPORTANT NOTE:
I am eager to accept any and all help on this project.
If you help me in any way regarding this program, your username will be in the credits!
I have managed to get a lot of work done on BOSshell!
(just some bugs regarding the 'r' token
)
DONE:
-Protocol for '.bxe' files (bytecode and source codes complete)
-General protocol for BOSshell files
-Protocol for '.txt','.lnk','.img' files
In Progress:
-Protocol for '.htl' files
-Homepage (50% complete)
-Foldersystem (read (75%), write(0%))
-Entry Password (75%)
-New and improved input routine! (80% complete)
TO-DO:
-editors and viewers for a variety of BOSshell file types
-'.bxe' file executor
-Protocol for '.sty' files
-Protocol for directories (these are not files, they are associations in the folds file)
IMPORTANT NOTE:
I am eager to accept any and all help on this project.
If you help me in any way regarding this program, your username will be in the credits!
Ok, not much development of actual code in the last week or two, but some notable changes in the conceptualization.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with [i]actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with [i]actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
beckadamtheinventor wrote:
Ok, not much development of actual code in the last week or two, but some notable changes in the conceptualization.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with [i]actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with [i]actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
This sound AMAZING!!! I look forward to applying to become a BOSshell developer!!! BTW, what language will extensions, applications, etc. be in? Will it be custom or a standard language (BASIC, ICE, C, ASM) or a hybrid?
The REAL LAX18 wrote:
beckadamtheinventor wrote:
Ok, not much development of actual code in the last week or two, but some notable changes in the conceptualization.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
#1: All file types deprecated.
#2: Replaced by a package-based system, that can actually become part of the shell's code. However, packages can also contain prgms, avars, any var type (beware of corrupted files though). Also: file type associations are going to be a major part of applications/extensions
DISCLAIMER: file type associations are not new var types. They are based on the first set of bytes in an appvar.
#3: BOSshell 'applications' and extensions (contained within packages) will be able to edit much of the shell, allowing for more possibilities.
#4: BOSshell will now have registered developer codes which will be given only to registered BOSshell developers, and are specific to each application/extension. However, this does not impede on your ability to make applications/extensions, the codes are only for the purpose of preventing unregistered developers from creating potentially unwanted software without the knowlege of the user. This is similar to the way Windows alerts the user to software from unknown developers.
#5: Input routine problems (mostly) solved
#6: I am debating using ez80 assembly for applications/extensions, using a seperate interface (such as an appvar or memory adress) to work with BOSshell's settings, files, functions, file type associations
#7: I might just decide to use only 'applications' instead of extensions. I should probably just call them software or programs to avoid confusion with actual[i] apps, which they are not.
If you took the time to read that behemoth of an update, (thank you for listening) and you are likely already invested in the project.
If you are interested in becoming a registered BOSshell developer, please contact me in PMs. I will likely accept, but I will only do so after a process (to be determined later).
NOTE: I will revoke the a developer's status if they produce malevolent software on purpose, or if they produce unintelligibly bad software. There will be up to three warnings, based on severity.
This sound AMAZING!!! I look forward to applying to become a BOSshell developer!!! BTW, what language will extensions, applications, etc. be in? Will it be custom or a standard language (BASIC, ICE, C, ASM) or a hybrid?
Well, I'm debating on creating a new (interpreted?) language, but it'll probably be faster if written in or compiled to ez80 asm.
Also: I need to start using the term 'software' instead of 'applications', to ease confusion with [i]actual apps, which they are not
Lots of work done today!
-Homescreen (WIP)
-Cursor
-string Input routine (WIP)
-working Password system
-A number of icons (which look pretty good if I do say so myself)
-Sleep mode (which basically just sets all the pixels to black until a key is pressed)
New gif screenshot!
https://drive.google.com/open?id=19msY5eWZ6orKnZibeme5RYHthksoMs_T
NOTE: I know that the lowercase symbol is shown as the uppercase during user input, I had already made and uploaded the gif by the time I realized Also I know that the user input doesn't blank out characters after the [del] key is pressed; but it does do backspace.
BOSshell is a work in progress right now, but the ball is starting to roll again.
-Homescreen (WIP)
-Cursor
-string Input routine (WIP)
-working Password system
-A number of icons (which look pretty good if I do say so myself)
-Sleep mode (which basically just sets all the pixels to black until a key is pressed)
New gif screenshot!
https://drive.google.com/open?id=19msY5eWZ6orKnZibeme5RYHthksoMs_T
NOTE: I know that the lowercase symbol is shown as the uppercase during user input, I had already made and uploaded the gif by the time I realized
Also I know that the user input doesn't blank out characters after the [del] key is pressed; but it does do backspace.
BOSshell is a work in progress right now, but the ball is starting to roll again.
Looking good!!!
If you need a string input routine, I have one in ICE that I used on TerminalCE (never released). It handles uppercase, lowercase, and numbers. Ill post the GitHub repo if you need it.
If you need a string input routine, I have one in ICE that I used on TerminalCE (never released). It handles uppercase, lowercase, and numbers. Ill post the GitHub repo if you need it.
- 03 May 2018 01:32:11 pm
- Last edited by beckadamtheinventor on 05 Jun 2018 08:47:42 pm; edited 1 time in total
BOSshell now has a website!
Please check it out frequently, as there will be updates to the page, and eventually downloads!
P.S. I will be putting up the download on Cemetch as well.
EDIT: I am in the process of switching to another repository site.
Please check it out frequently, as there will be updates to the page, and eventually downloads!
P.S. I will be putting up the download on Cemetch as well.
EDIT: I am in the process of switching to another repository site.
Help Wanted
So... after a few days of contemplating the logistics of programming BOSshell, I have realized that I will need some (a lot) of help to complete it.
I currently need help with the software format design, and the interpreter needed to run it.
I am looking for anyone with above-average knowlege of ICE, and/or experience with designing programming languages, specifically lower-level languages, or a significant knowlege of how a compiler works, and how to write one.
Any help on this project would be greatly appreciated!
(please PM me if you are interested)
P.S. You do not need to be a registered developer to help develop this project, but you will be afterwards!
So... after a few days of contemplating the logistics of programming BOSshell, I have realized that I will need some (a lot) of help to complete it.
I currently need help with the software format design, and the interpreter needed to run it.
I am looking for anyone with above-average knowlege of ICE, and/or experience with designing programming languages, specifically lower-level languages, or a significant knowlege of how a compiler works, and how to write one.
Any help on this project would be greatly appreciated!
(please PM me if you are interested)
P.S. You do not need to be a registered developer to help develop this project, but you will be afterwards!
Help (still) wanted
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
beckadamtheinventor wrote:
Help (still) wanted
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
I will help you as much as I can but I cannot guarantee that I can help with everything.
LAX18 wrote:
beckadamtheinventor wrote:
Help (still) wanted
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
Hey, i'm still in need of help with BOSshell development.
I am looking for a co-developer, who knows ICE well enough to write a shell, specifically to help write the software language. This language must be able to do everything that ICE can, have the ability to run as part of key loops (small portions of the program subroutined)(this feature is to allow for 'background' software), and work with file type associations (I need help with this as well).
I will help you as much as I can but I cannot guarantee that I can help with everything.
If you are able write ICE, can help with defining a language that has all the features posted above, and able to handle my erratic schedule for working on the project, you're in!
(You might even help me with my work ethic along the way too
)
PM me if you're interested
Updates to the ideas behind BOSshell:
#1: extensions/software for BOSshell are going to be written in any language you choose, as long as it can be compiled to eZ80 ASM.
#2: Almost all of BOSshell's main gui will be customizable!
#3: Most of the features of BOSshell will be added as assembly sub-programs (like file editors). This means that much of the features of the shell will be added later, but this also means that you guys can help me develop it! (it will also be released sooner 
)
So the CE will soon have a fully customizable, but still function out-of-the-box shell!
#1: extensions/software for BOSshell are going to be written in any language you choose, as long as it can be compiled to eZ80 ASM.
#2: Almost all of BOSshell's main gui will be customizable!
#3: Most of the features of BOSshell will be added as assembly sub-programs (like file editors). This means that much of the features of the shell will be added later
, but this also means that you guys can help me develop it! (it will also be released sooner )
So the CE will soon have a fully customizable, but still function out-of-the-box shell!
So... in order to complete BOSshell, with its ability to be customized, I would need to run ASM from portions of an appvar; putting all the extension code into one file. (I already know how to do this)
Bad news: I don't know how to run ASM from an appvar, and I don't think that ICE currently has that capability.
Good news: That doesn't mean that PT_ won't be able to add that function to ICE. If all else fails, I'll just write some of the code in ASM or C and just include that code in BOSshell.
/me bugs PT_
Bad news: I don't know how to run ASM from an appvar, and I don't think that ICE currently has that capability.
Good news: That doesn't mean that PT_ won't be able to add that function to ICE
. If all else fails, I'll just write some of the code in ASM or C and just include that code in BOSshell.
/me bugs PT_
mets11rap wrote:
Idea: Add the option to use the calculator keys as a trackpad sort of like TI83 Fruit Ninja.
Thats actually a realy good idea!
I'll add that as an optional UI package to come with the shell!
(which will come out asap as soon as I can run ASM from portions of an appvar in ICE)
beckadamtheinventor wrote:
mets11rap wrote:
Idea: Add the option to use the calculator keys as a trackpad sort of like TI83 Fruit Ninja.
Thats actually a realy good idea!
I'll add that as an optional UI package to come with the shell!
(which will come out asap as soon as I can run ASM from portions of an appvar in ICE)
Cant you store the ASM in its raw form in the App Var, then copy it to a pointer that is embedded in the program?
Register to Join the Conversation
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
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