Author Topic: Projects Update, Zeda  (Read 2726 times)

0 Members and 1 Guest are viewing this topic.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Projects Update, Zeda
« on: November 07, 2013, 06:53:47 pm »
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 :P

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.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Projects Update, Zeda
« Reply #1 on: November 08, 2013, 12:52:47 am »
Glad to see you into calc dev again :D

As for the new Grammers, by on par with BASIC speed, does it mean that it will be much slower than Grammer 2? (since that was already way faster than TI-BASIC)

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Projects Update, Zeda
« Reply #2 on: November 08, 2013, 08:38:58 am »
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.

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: Projects Update, Zeda
« Reply #3 on: November 08, 2013, 11:55:50 am »
You really planned to write GrammerOS ? O.O did you start anything yet ? Because an actually useful and practical OS that people would install isn't written in 6 months ...

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Re: Re: Projects Update, Zeda
« Reply #4 on: November 08, 2013, 12:10:00 pm »
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)

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Projects Update, Zeda
« Reply #5 on: November 08, 2013, 12:22:03 pm »
@Matrefeytontias: GrammerOS has been planned since Grammer first started :) I have been working on parts of its code every so often and rewriting it for better ideas.

@DJ_Omnimaga: Yes, those types of loops get optimised to something much faster before execution. There is a command called 'Goto [lbl]If [condition]'. 'While ' is replaced by the GotoIf and the EndWhile is replaced by a Goto that jumps back to the GotoIf (making it faster and labels are all precomputed, meaning no stack overflow issues).
Repeat is like While, except the End gets replaced by a GotoIf, jumping back to the beginning of the block.

'If' gets replaced by a GotoIf not(condition) and jumps to the End (or the Else condition), et cetera.

For() gets replaced by an initialising condition, then the EndFor gets replaced by an increment code and a GotoIf. FOr example:
Code: [Select]
For(A,1,10,.1)
<<stuff>>
End
get replaced by:
Code: [Select]
1→A
lbl for1
<<stuff>>
A+.1→A
Goto for1 If A!=1
Since labels are all precomputed offsets, all of these Goto commands are really fast.

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: Projects Update, Zeda
« Reply #6 on: November 08, 2013, 01:12:50 pm »
Is it an actual OS already, or is it just code for now ? I mean, do you have a 8xu to test ?

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Projects Update, Zeda
« Reply #7 on: November 08, 2013, 02:51:50 pm »
I do not have an 8XU to test it, it is just a bunch of code. I want to write a simple command line interface first, as an App that clears RAM and uses nothing from the OS. Then if I can successfully use it as a calculator and make a simple program, I will try to turn it into an 8xu.

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: Projects Update, Zeda
« Reply #8 on: November 08, 2013, 04:40:06 pm »
Grammer4 being a whole new OS? O.O
wow

Anyways, good to see you still working on stuff :D

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Projects Update, Zeda
« Reply #9 on: November 08, 2013, 09:46:04 pm »
@DJ_Omnimaga: Yes, those types of loops get optimised to something much faster before execution. There is a command called 'Goto [lbl]If [condition]'. 'While ' is replaced by the GotoIf and the EndWhile is replaced by a Goto that jumps back to the GotoIf (making it faster and labels are all precomputed, meaning no stack overflow issues).
Repeat is like While, except the End gets replaced by a GotoIf, jumping back to the beginning of the block.

'If' gets replaced by a GotoIf not(condition) and jumps to the End (or the Else condition), et cetera.

For() gets replaced by an initialising condition, then the EndFor gets replaced by an increment code and a GotoIf. FOr example:
Code: [Select]
For(A,1,10,.1)
<<stuff>>
End
get replaced by:
Code: [Select]
1→A
lbl for1
<<stuff>>
A+.1→A
Goto for1 If A!=1
Since labels are all precomputed offsets, all of these Goto commands are really fast.

That's cool to hear. :) This means we at least won't have to do things like this in order to keep our games running at decent speed. :P

Code: [Select]
:ClrHome
:0→D
:0→A
:Disp "THIS WILL TAKE","A LONG TIME."
:Pause
:While A<1000000
:Pxl-Change(D,A)
:Pxl-Change(D+1,A)
:Pxl-Change(D+2,A)
:Pxl-Change(D+3,A)
:Pxl-Change(D+4,A)
:Pxl-Change(D+5,A)
:Pxl-Change(D+6,A)
:Pxl-Change(D+7,A)
:Pxl-Change(D+8,A)
:Pxl-Change(D+9,A)
:Pxl-Change(D+10,A)
:Pxl-Change(D+11,A)
:Pxl-Change(D+12,A)
:Pxl-Change(D+13,A)
:Pxl-Change(D+14,A)
:Pxl-Change(D+15,A)
:Pxl-Change(D+16,A)
:Pxl-Change(D+17,A)
:Pxl-Change(D+18,A)
:Pxl-Change(D+19,A)
:Pxl-Change(D+20,A)
:Pxl-Change(D+21,A)
:Pxl-Change(D+22,A)
:Pxl-Change(D+23,A)
:Pxl-Change(D+24,A)
:Pxl-Change(D+25,A)
:Pxl-Change(D+26,A)
:Pxl-Change(D+27,A)
:Pxl-Change(D+28,A)
:Pxl-Change(D+29,A)
:Pxl-Change(D+30,A)
:Pxl-Change(D+31,A)
:Pxl-Change(D+32,A)
:Pxl-Change(D+33,A)
:Pxl-Change(D+34,A)
:Pxl-Change(D+35,A)
:Pxl-Change(D+36,A)
:Pxl-Change(D+37,A)
:Pxl-Change(D+38,A)
:Pxl-Change(D+39,A)
:Pxl-Change(D+40,A)
:Pxl-Change(D+41,A)
:Pxl-Change(D+42,A)
:Pxl-Change(D+43,A)
:Pxl-Change(D+44,A)
:Pxl-Change(D+45,A)
:Pxl-Change(D+46,A)
:Pxl-Change(D+47,A)
:Pxl-Change(D+48,A)
:Pxl-Change(D+49,A)
:Pxl-Change(D+50,A)
:Pxl-Change(D+51,A)
:Pxl-Change(D+52,A)
:Pxl-Change(D+53,A)
:Pxl-Change(D+54,A)
:Pxl-Change(D+55,A)
:Pxl-Change(D+56,A)
:Pxl-Change(D+57,A)
:Pxl-Change(D+58,A)
:Pxl-Change(D+59,A)
:Pxl-Change(D+60,A)
:Pxl-Change(D+61,A)
:Pxl-Change(D+62,A)
:Pxl-Change(D,94-A)
:Pxl-Change(D+1,94-A)
:Pxl-Change(D+2,94-A)
:Pxl-Change(D+3,94-A)
:Pxl-Change(D+4,94-A)
:Pxl-Change(D+5,94-A)
:Pxl-Change(D+6,94-A)
:Pxl-Change(D+7,94-A)
:Pxl-Change(D+8,94-A
:Pxl-Change(D+9,94-A)
:Pxl-Change(D+10,94-A)
:Pxl-Change(D+11,94-A)
:Pxl-Change(D+12,94-A)
:Pxl-Change(D+13,94-A)
:Pxl-Change(D+14,94-A)
:Pxl-Change(D+15,94-A)
:Pxl-Change(D+16,94-A)
:Pxl-Change(D+17,94-A)
:Pxl-Change(D+18,94-A)
:Pxl-Change(D+19,94-A)
:Pxl-Change(D+20,94-A)
:Pxl-Change(D+21,94-A)
:Pxl-Change(D+22,94-A)
:Pxl-Change(D+23,94-A)
:Pxl-Change(D+24,94-A)
:Pxl-Change(D+25,94-A)
:Pxl-Change(D+26,94-A)
:Pxl-Change(D+27,94-A)
:Pxl-Change(D+28,94-A)
:Pxl-Change(D+29,94-A)
:Pxl-Change(D+30,94-A)
:Pxl-Change(D+31,94-A)
:Pxl-Change(D+32,94-A)
:Pxl-Change(D+33,94-A)
:Pxl-Change(D+34,94-A)
:Pxl-Change(D+35,94-A)
:Pxl-Change(D+36,94-A)
:Pxl-Change(D+37,94-A)
:Pxl-Change(D+38,94-A)
:Pxl-Change(D+39,94-A)
:Pxl-Change(D+40,94-A)
:Pxl-Change(D+41,94-A)
:Pxl-Change(D+42,94-A)
:Pxl-Change(D+43,94-A)
:Pxl-Change(D+44,94-A)
:Pxl-Change(D+45,94-A)
:Pxl-Change(D+46,94-A)
:Pxl-Change(D+47,94-A)
:Pxl-Change(D+48,94-A)
:Pxl-Change(D+49,94-A)
:Pxl-Change(D+50,94-A)
:Pxl-Change(D+51,94-A)
:Pxl-Change(D+52,94-A)
:Pxl-Change(D+53,94-A)
:Pxl-Change(D+54,94-A)
:Pxl-Change(D+55,94-A)
:Pxl-Change(D+56,94-A)
:Pxl-Change(D+57,94-A)
:Pxl-Change(D+58,94-A)
:Pxl-Change(D+59,94-A)
:Pxl-Change(D+60,94-A)
:Pxl-Change(D+61,94-A)
:Pxl-Change(D+62,94-A)
:
:A+1→A
:0→D
:Lbl B
:If A=47:Then:Pxl-Change(62-D,47):D+1→D:If D=63:Then:48→A:End:Goto B:End
:If A=48:Then:Stop:End
:End

(This was by Netham45, btw :P)
« Last Edit: November 08, 2013, 09:50:26 pm by DJ Omnimaga »