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.

Quote

If there are certain programs that require a shell to be run, an easy way to do this is check if DoorsCS7 is on the calc and have it open the file. It felt kind of like cheating to me when I did that, but it saves a lot of work. of course, you would still have to handle the case of DCS7 not being on the calc

That's a really good idea... IDK though, I want my shell to work as a replacement for DoorsCS and Mirage. Do you think learning ASM is worth it?

If you want to replace those shells, you will end up learning at least a little assembly. MirageOS, ION, DoorsCS7, and others like them not only work as a shell, but they also provide subroutines for assembly programs to use. For example, any MOS programs relying on the ionFastCopy routine (or whatever it is called) will need to have the appropriate jump table at the appropriate address so that the program can function.

If you want completely accurate precision that is very fast (at the cost of requiring more RAM), it might actually be more beneficial to store the following information about each bullet:
x coord
y coord
width
height
remainder
Each frame, you would do something like the following:
for(a=0,#ofbullets-1)
  call AdjustCoords
  pxl-change(x,y)
  x?buf(5*a)
  y?buf(5*a+1)
  w?buf(5*a+2)
  h?buf(5*a+3)
  r?buf(5*a+4)


AdjustCoords:
buf(5*a)?x
buf(5*a+1)?y
buf(5*a+2)?w
buf(5*a+3)?h
buf(5*a+4)?r

pxl-change(x,y)
if remainder >0
  x+1?x
  r-h?r
  return
If remainder=<0
  y+1?y
  r-w?r
  return
Essentially, it makes sure that the bullet stays as close to being on track as it can. If it moves too far in the x direction, it corrects by moving in the y direction. All the while, it adjusts the remainder (if remainder dips below 0, then we know it has moved too far off track and we need to adjust by moving in the y direction.

The pseudocode isn't perfect-- it only accounts for being able to move right or up. You will want to store the x and y directions of the bullets as well. The rest of the data is derived from:


initial (x,y) depends on where the bullet originates
initial (w,h) will remain constant and comes from subtracting the enemy objects coordinates from the bullet origin coordinates. If these are positive, then direction will be 1 for the given direction. If either is negative, direction needs to be set as -1 and then you need to make it positive with abs().
initial remainder should be set as w
Finally, (w,h) needs to be readjusted by multiplying them by 2.

(in non-integer arithmetic, we would just set initial remainder as w/2, but we would lose accuracy in integers if w was odd, so we just use w and then double width and height)


An increment, add/subtract and compare is much faster than computing arctangent, multiplying/dividing and using sin() or cos(). It also does not require inflated pixels, but it can work just fine with them, too. I have vague memories of doing something like this over the summer that got hundreds of bullets on screen at 6MHz. I'll try to find it and edit this post.


EDIT: Oh, it was actually an old topic that you posted in, but for a refresher: http://ourl.ca/19321/356834

It is indeed Here, check this out and click the little button thing at the bottom to show speed/size for various outputs.

It turns out my estimates were off, though, and it is actually even faster than I predicted

Between yesterday and this morning, I have formulated a more sound process for coming up with these formulas. For more information, I made a document here. (I am still modifying it and checking it for accuracy, otherwise, I would upload it, too).

As a result of yesterday's ventures, I managed to avoid the guess 'n check method and derive a formula for 13-bits of accuracy. It only requires one more multiplication, too:

(240x+115x³)/(240+195x²+17x⁴)

However, this is less suitable when using 8.8 fixed point math than the previous (then again, if you are using 8.8 fixed point, you probably won't need 13-bits of accuracy).

It didn't do anything adverse for me ... What apps do you have installed?

Now that I have had more time to think, I would like to point out that of the 5 admins, they have made 147 posts in the past 2 months and two of them made more than twice the posts of the other two combined.
DJ_Omnimaga made 822 posts.

On other forums that I have been a part of, there are usually at least to or three very active admins and admins are among the most active users. Currently two of the admins are pretty active on the forums (and so would be more noticeable to users that cannot access IRC), so that is good, but DJ_Omnimaga is by far the most active/experienced member on the site.

PixelScape Does some of that, so maybe you could propose something like this to Deep Thought who I believe worked on Omnimaga's new image uploader, too. Maybe he could allow users to upload images that included tags to the repository, then have PixelScape be able to search the repository (as well as anybody on Omnimaga looking for images in the uploader), then the user could click the one they want and options for copy/pasting it to the editor, or directly reading it in some format for source code.