dim("VPTR(prgmTEST,Zeda:Doc Test) BASIC(Zeda:Doc Test)
However, once I add in the CD command (which is basically only three bytes of code at this point):dim("CD(Zeda:Doc) VPTR(prgmTEST, Test) BASIC( Test)
Anyways, since the program isn't very presentable, I won't release a program yet. Currently, there are two other projects that are already in the works to use this program-- ScopeOS by Codebender (with help from myself and Roguebantha) and Linux which is being done by Roguebantha (originally using BatLib, but that is why we have included certain BatLib commands in this app).CD(path) This will open a folder (or use ".." to go up one folder level)
CF(filepath,field,data) This will change a field in the header data of a file. Fields could be for passwords, descriptions, or specifying what programs to open the file with.
CI(filepath,icon#|icondata) This will change the icon number, or if you supply hex data, it will change the icon to a custom icon.
CN(filepath,newname) This will change the name of a file.
COMP(filepath) This will compress a file
COPY(filepath,newpath|newfilepath) This will copy a file from one location to another
DADD() Returns a string with the current directory
DEL(path) or DEL(filepath) This will delete a folder or file.
GETD(path,#) Returns info aboutt he nth item in the directory (so you can create a list of variables or whatnot)
HIDE(filepath) This will mark a file or folder as hidden
LOCK(filepath) This will mark a file or folder as locked
MOVE(filepath,newpath) Moves a file to another directory
ND(loc) This adds a new directory
SCUT(lfilepath,newloc) This creates a shortcut of a file.
VPTR(VarName,filepath) This will create a file that points to an OS variable
dim("GETD()
dim("CD(ZEDA)
dim("GETD()
dim("GETD(ZEDA)
dim("CD(ZEDA:DOC) CD(..:PROG) GETD(..)
dim("VPTR(prgmA,ZEDA:PROG PROGGY)
dim(8,"EA
dim(8,"(ZEDA:PROG PROGGY)
dim("GICON(ZEDA:PROG PROGGY)
dim("GICON(ZEDA)
dim(22.1,dim("GICON(ZEDA:PROG PROGGY)"),16,1,1,0,99
dim("CD(ZEDA) DEL(:DOC) GETD()
dim("DEL()
Note that dim(8) returns the contents of the variable and dim(22) draws a sprite
CF(Zeda:Prog Hi,1,'This is a Hello World program.')
Which reminds me, I changed string inputs to require single quotation marks
how long have those other OSs you mentioned been worked on? i don't see much about scope os on the project page thereScopeOS has been worked on for about a month, though I've seen no code, screenshots, or examples of it XD The Linux OS one I have seen some pretty cool screenshots of:
dim(0
CD(Zeda:Games)
VPTR(prgmRPG, RPG) ;creates a file that links to the program "RPG"
AFA( RPG,'BATB') ;Add the file association for BatLib BASIC
Return ;Exist the FileSyst parser and return to BASIC
Then, whenever you do OPEN( RPG), FileSyst will try to install BatLib, then run the program.| 1 byte 1 byte n bytes 1 byte 33 bytes 1 byte 2 bytes n 2 bytes n | Type (1Fh indicates it is a folder, all other types are open) Name Size Name Icon (If this is -1, it is a custom icon, 0 is default, anything else is a preset) IconData (If the Icon is not a custom Icon, this is omitted Info (this is for info about Hidden,Locked, Shortcut, or OS var, among other things) Fields Size Fields Data Data Size File Data |
Looking nice, but can you also use it in basic programs?Sorunome, that screenshot is of it being used in a BASIC program.
And if yes, is it compatible with BatLib as it uses dim( too?The answer is yes and no. The two cannot work at the same time, but in this update I will introduce a new command OPEN() that is able to open BatLib programs (among other things). Also, a bunch of BatLib commands are provided at the moment with FileSyst, though some may be removed later.
I updated prgmCMD to include the OPEN command and you can see as it opens DK5ION that this should be very useful!
is it calling those other apps to open the selected files? if so, it would be nice to have a hook that's called whenever a program is run from the homescreen, seeing as there isn't really anything out there that chooses what to use in opening a file dynamically like that.Yes, the program checks for the associated app or program and has it loaded (it also installs the necessary hook and restores the parser hook after running). However, since the app does this based on data stored in the file header and not the program, it would be difficult to install a hook to intercept the prgm token to do this. From the homescreen, people can do dim("OPEN( <<file>>) and it will work, so long as the file has the proper file association set.
It was off the homescrean :PLooking nice, but can you also use it in basic programs?Sorunome, that screenshot is of it being used in a BASIC program.
Oh, that is pretty cool, does batlibs chainhook still work then?And if yes, is it compatible with BatLib as it uses dim( too?The answer is yes and no. The two cannot work at the same time, but in this update I will introduce a new command OPEN() that is able to open BatLib programs (among other things). Also, a bunch of BatLib commands are provided at the moment with FileSyst, though some may be removed later.
-Getting rid of the File Association field and just using file extensions. For example, DonkeyKong.IONThat's actually a great idea for any shell...
:Input "Name:",Str1
:dim(-1 ;start a block of FileSyst code
:CD(Game/Str)
:NEW( Name.str)
:SINSRT( Name.str,Str1)
:Return ;Exit the block of FileSyst code
That will create the file Name.str in folder Game/Str and fill it with the contents of Str1.CD(Sub) ;open the folder Sub.
VPTR(prgmSUB01, 01) ;create an OS pointer to prgmSUB01 named 01 stored in folder Sub.
OPEN(Sub/ 01) ;use the OPEN() command to open the file. The file type is auto detected and opened with the appropriate routines.
I use this technique to keep sub programs in archive. As well, you can have some sub-programs that require different parser hooks, so if prgmSUB01 is a regular BASIC program, but prgmSUB02 needs Celtic 3, prgmSUB03 needs BatLib, and prgmSUB04 needs DoorsCS7, you could do:CD(Sub)
VPTR(prgmSUB01, 01)
VPTR(prgmSUB02, 02.c3)
VPTR(prgmSUB03, 03.batb)
VPTR(prgmSUB04, 04.dcs7)
As long as the appropriate apps are on the calculator,the programs will run. For a Celtic 3 program, FileSyst first checks if the Celtic 3 app is on the calculator, if it isn't, it checks if DoorsCS7 is on the calculator. If one of them is on, then FileSyst will try to install their hooks and then run the program. From the readme:/==============================================================\
| OPEN(File) |
\==============================================================/
| This can be used to open files based on its file extension. |
|If it does not have a file association, FileSyst will try to |
|open it as a nostub assembly program or BASIC program. Built |
|in file types and the programs that open them are: |
+======+=======================================================+
|Assoc:| Programs (In descending order of priority) |
+======+=======================================================+
| ION | DoorsCS7,DoorsCS6 |
| MOS | DoorsCS7,DoorsCS6 |
| DCS | DoorsCS7,DoorsCS6 |
| DOC7 | DoorsCS7+DocDE7 |
| BAT | BatLib |
| BATB | BatLib |
| C3 | DoorsCS7,Celtic 3 |
| XLIB | DoorsCS7,Celtic 3,xLIB |
| DCS6 | DoorsCS6,DoorsCS7 |
| DCS7 | DoorsCS7 |
| DCSB | DoorsCS7 |
| OMNI | Omnicalc |
| GRAM | Grammer |
+======+=======================================================+
| For example, if you try to run an xLIB program, FileSyst |
|first searches for DoorsCS7, if that isn't available, it tries|
|Celtic 3 and then xLIB. |
| Further, xLIB and Omnicalc don't have any actual installers |
|aside from manual installation. If FileSyst has to install |
|these, it uses a method that should only work on specific |
|versions, xLIB v.602b and Omnicalc v1.26 and v1.26MP. |
| Now, for some example code: |
| CD(Zeda/Games) ;Change the directory. |
| VPTR(prgmDK5ION, DonkeyKong.ION) ;Makes an OS shortcut. |
| OPEN( DonkeyKong.ION) ;Run DonkeyKong. |
| |
| OPEN() should return to the program properly, but there is |
|always a chance that it won't if an assembly program doesn't |
|quit properly (or if a BASIC program uses Stop). |
\==============================================================/
The problem is that I still don't understand Flash protocol and USB protocol. I am not sure, though, but I think SirCmpwn released a template for an operating system, so I could probably use that.Raw flash commands are documented on the Wiki. (http://wikiti.brandonw.net/index.php?title=83Plus:OS:Raw_Flash_Commands) BrandonW is the only documentation for USB.
Are there any hooks can be reached with some Axe? I'd like to test it by doing a graphical wrapper.Are you talking about the latest side project or FileSyst? FileSyst does have a jump table to handle a bunch of things. LangZ80 does not have one yet, but I can easily add in some jumps to the parser and a few of the routines. I have it so that it really can take HL as the location of the code, BC as the size of the code, and it does the interpreting from there. I also have a routine that converts the output to a 16-bit integer instead of a string, and I can make a call that reads from a 0-terminated string (like Axe uses) so you could do something like this in Axe:
LANG("VAR1")→A
And then it would either return a pointer to VAR1 if it is a string, or it would return int(VAR1) for Axe.Xeda, are they viable for a full-fledged OS?If I understand correctly, yes, these routines are currently adequate as a calculator. It defaults to a precision of 128 bits for floating point math (the TI-OS uses <48 bits) so it is much more accurate, and integers are arbitrary precision, up to 2040-bits (614 digits). I plan to add a few more variable types, including Sprite, Array, and List. As well, custom variable types so that types like Complex, Complex List, Complex Array, Matrix, can be made from these.