I haven't had much time to be active lately, but I thought I would update on my long term programming goals.

---

I am rewriting FileSyst at the moment to have what I see as a more intelligent design. I decided that it would be beneficial to store files and folders in alphabetical order. This would be more aesthetically pleasing and no more difficult than the current method. Currently, I append new files to the end of the folder data, and then since the working directory is stored as an array of addresses, those values must be updated to reflect the changes of addresses, and each folder's size bytes in the path need to be updated. By storing alphabetically, this would still be the case, but I am also going to use an index.

Using the index, I can search for files more quickly. Instead of comparing the name of the files, reading through the header to get to the size bytes, and skipping the file to move to the next (which is already quick enough and similar to how TI searches the VAT), I can be more elegant using a binary search. This means I start halfway in the index, compare the names and then I jump another halved distance either up in the array or down until the halved distance becomes 0. To put this into perspective, if a folder had 128 files, instead of checking through an average of 64 files to locate one, I could instead check at most 7 files before locating the correct one.

I have already written this search routine and it is functional

If the file doesn't exist, I create the file by inserting a two-byte address into the index, then inserting the necessary RAM, then adjusting all of the appropriate index values in every folder in the path, and adjusting the size bytes of the folders. (This is only marginally better than the old method, speed wise).

As well, folder paths can be stored by index number, so the addition or deletion of a file will only require 1 byte incremented or decremented in the working directory path.

---

I have been continuing my work on writing Z80 Floating Point Routines to add to my collection of integer math routines. Currently, the 24-bit floats are the most complete, including addition, subtraction, multiplication, division, square roots, logarithms, and arctangent. The 80-bit floats which are on par with the TI-OS floating point numbers (except with about 5 digits of extended accuracy) have only the basic 4 functions (+-*/).

---

I am also aware that Grammer 3 should be a powerful programming language and that Grammer 4 should provide a replacement Operating System. FileSyst already contains a pseudo-language for command line functions such as CD(), OPEN(), et cetera. However, it currently does not allow nested functions or the like. I am in the process of rewriting this parser to allow complicated nesting of functions and I redesigned the file system layout with the intent to add variable support. I want to take advantage of the file system to store local variables and global variables, but I want to make it fast and that is why the binary search method sounded like the best option to me. So now imagine that you have a program running called Test.fs and you create a variable. Test.fs will be treated like a folder, too, and the variable will be stored inside it. Now say you wanted to call a subroutine called Func(). Internally, Func will be treated as another program/folder inside Test.fs where it can have its own variables. If it tries to access a variable that doesn't exist in its folder, it will go up a level in the folder system to see if the var exists there, and so on.

My hope is that this proves to be at least on par with the speed of TI-BASIC, if not faster. I imagine this could turn into Grammer 3 or Grammer 4, too.

Oh, I should clarify. To use the same kind of math abilities, this should be about as fast as BASIC. Graphics and such should still be faster, and if the programmer uses integers or even 24-bit floats instead of full 80-bit floats, the program should run much faster than TI-BASIC.

Oh, I should clarify. To use the same kind of math abilities, this should be about as fast as BASIC. Graphics and such should still be faster, and if the programmer uses integers or even 24-bit floats instead of full 80-bit floats, the program should run much faster than TI-BASIC.

Oh I see now. Would For loops and If blocks be faster than Basic too? Sometimes they are the cause of slowdowns (especially for loops in ASCII Space Invader clones, forcing you to use one output command per ship)

Is it an actual OS already, or is it just code for now ? I mean, do you have a 8xu to test ?

Grammer4 being a whole new OS?
wow

Anyways, good to see you still working on stuff