Re: TIB: Faster Getkey??? (was GetKey)
[Prev][Next][Index][Thread]
Re: TIB: Faster Getkey??? (was GetKey)
{{ OOP programming stuff. }}
That's kind of redundant saying that, especially when OOP=object oriented
programming (at least that's what I thought it meant).
Anyway, I'm getting really nauseous about this whole "Faster Getkey" program
thing. First we were talking about making a faster routine in finding out
which key is pressed and then doing something about it, and the second thing I
know is we were talking about how the calculator and its programs are set up.
I might be repeating someone else with a few of the following comments, but
this will give some light to some questions. The programs are set up like
strings except they have a different header to tell the calc it's a program.
For some calculators, there is also a bit or byte to tell it if the program
has been executed or edited. When the program is run, the first thing the
calculator does is check if it has been edited.
If the program has been edited, it first goes through the program tokenizing
the BASIC programming language into 2 byte words (I know a word is 2 bytes and
it sounds redundant, but if I have said "tokenizing the BASIC programming
language into words", it would've sounded stupid). Like I said before, this
doesn't happen to some calculators (82/83) because it already tokenizes the
language as you type (notice that you can't type "if", you have to actually go
to PRGM/If in order for it to work). The program must be tokenized because
the it helps the calculator search better (it's harder searching different
size commands compared to same sized token commands). The program is then
"handed" over to the parser.
If the program has been executed before, or has just been tokenized and there
are no errors, then the program is then parsed and executed again. Before
this happens, a type of "program counter" is stored in memory for that
specific program (I believe it's in the header of the program itself, but I'm
not certain). The program is also stored on a type of stack along with its
current program counter when subprogramming (a return on a null stack stops
the program, and a subprogram passed the stack size will cause an error).
Inside the parser, it gets quite simple actually. First the parser takes the
2 bytes stored at the current location, increments the program counter twice,
and checks the bytes through the list of tokens, first by checking the first
byte with common commands (like If/then, disp, etc.) and then the second byte
for more specific commands (like pton/off, etc.) or as for some calculators,
the first byte tells it if it has parameters or not (such as clrlcd or
clrdraw) and the second byte is the exact command, jumping to the command
running subroutine. The routine either needs no parameters and simply does
something and returns to the parser (like ClrDraw), or it has commands and
does something with them (be it make B=1 for a 1stoB, or store a %10000000 at
the screens first location for a pixelon 0,0) and then returns to the parser.
The parser then finds the next 2 bytes by repeatedly incrementing the program
counter until it finds the known first byte (depending on that first bytes'
possibility explained above). But that's just 1 assumed method some thing,
others find out that a "return" is found inside the program, and assume that
the parser searches for the next return and then increments 1 to find the next
command.
As for a LBL/GOTO statement, the parser does in fact search through the
program from the beginning to find the matching Lbl of the Goto statement, but
the slowness of your program is not JUST the placement of the Lbl versus the
Goto, but actually it's both that and the fact it is searching for the Labels'
token along with the match (4 or 5 bytes I believe--it's just harder for a
program to search a string for 5 matching characters rather than just 1
character).
The some rules that I have learned are:
never use a Goto inside an If/Then statement
never use a Lbl past 5K of program size
use a Goto to get from bottom to top quickly
avoid if statements if you can
never use testing in an If statement if you can't avoid it
calculate a formula for an If statement before you call the If statement if
you have to use it
use MOD to wrap around a number (for example: when you want a pixel to wrap
around a screen, then use this command)
use MIN/MAX to set tolerances (used in some games to keep speed to a specific
range)
For example:
10->A
10->B
0->C
0->D
ClrDraw
PxlOn B,A
Lbl A
0
Repeat Ans
getky
End
If 24
MAX(-1,C-1)->C
If 25
MAX(-1,D-1)->D
If 26
MIN(1,C+1)->C
If 34
MIN(1,D+1)->D
If 45
Return
PixelOff B,A
MOD(A+C,20)->A
MOD(B+D,20)->B
PixelOn B,A
Goto A
-Rob
p.s. Here's a challenge, if the program does search for the Lbl token along
with the label letter and everything, create a string that contains the
following program tokenized on the computer:
"Lbl A:Disp 0:Goto B"
and then send it to the calculator with the following program:
Program: ASM
:"Lbl A:Disp 0:Goto B" <---tokenized string
:Goto A
:Lbl B
The theory on this is that the Goto will search the whole program byte by byte
for the LBL A part, and start executing all the commands after it. If this
works, then you could find a way to Exit the parser without Exiting the
program, creating a header for an ASM program =)...if it doesn't work, oh
well, it would've been nice.