Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Quigibo

Pages: 1 ... 39 40 [41] 42 43 ... 135
601
The Axe Parser Project / Re: Axe Parser
« on: January 05, 2011, 05:08:56 pm »
Question:

Okay, so I'm almost done with the new Axiom specifications and SDK and am beginning to convert my asm mode 7 engine to an Axiom at the same time as writing the axiom interpreter.  As you might know, there will be several new Token replacements specifically for Axioms.  Originally, I was planning to add 12 tokens to replace the parametric variables X1T-Y6T, but I decided against that now because I am introducing those as 6 entirely new variables to make communication with very large Axioms more convenient.  This is to prevent passing a gajillion arguments every time you need to call an Axiom that requires global variables.

So, I need to figure out a good spot to put these tokens.  I would prefer a single menu where I can use every or almost every single token on that menu.  I was thinking about the [2nd] [DISTR] menu but I could use the window tokens, zoom tokens, or another place instead.  Anyone have a preference?

Also, if you can think of a some generic token names that would be useful to you, but not too specific, feel free to throw them out there.  Also, all new tokens will have a left parenthesis attached, but you can close it like this() to use it as a no-argument token.  Some ideas I am considering so far are:

Start()
Next()
Up()
Down()
Left()
Right()
Render()
DrawL()
DrawR()
DrawS()
Print()


And don't forget, there are still all the TI tokens in addition to these so if you were writing an 8.8 sine routine for instance you could use sin-1() or sinh().

602
Axe / Re: Writing to variables or executing a basic program
« on: January 05, 2011, 01:31:14 pm »
First of all, if you do a getcalc with a real variable you should always subtract 2 from the pointer since reals don't have size bytes in front; the size is ALWAYS 9 bytes.

Code: [Select]
GetCalc("varA",9)-2->A
Secondly, real numbers are floats, not integers, you have to manipulate them with float{} like this:

Code: [Select]
float{A}->B
8->float{A}

Running BASIC programs sounds like it could be done with a bcall, but I don't know of any.

603
Axe / Re: Help with movement.
« on: January 05, 2011, 01:02:55 pm »
You know, if you can't get to the ram clear menu or are unable to clear your ram for some reason where taking out the batteries doesn't work, you can always take out the backup battery (which powers the ram) to guarantee a ram clear even if the calculator wasn't frozen.

604
TI Z80 / Re: Idea: 3D Engine using nothing but unaltered 8x8 sprites
« on: January 05, 2011, 04:31:27 am »
Wouldn't it look a lot better to have the top and bottom sprites be triangles to make a smoother transition between slices?  Also, I'm pretty sure it would still be raycasting, but 8 times faster since there are 1/8 as many rays being casted which is plenty fast considering how fast the pure axe raycasters were already.  Any other way of doing it would not allow you to move around as smoothly since you would have to always stay in the center of the path.

605
The Axe Parser Project / Re: Assembly Programmers - Help Axe Optimize!
« on: January 04, 2011, 05:32:59 pm »
I think most of those I just missed thanks for catching them.  The p_EQNX and p_NENX were intentionally left out though because I need to rewrite my optimizer to handle negative shorts first.  As for your new optimizations, I'm not sure If I want to add those because It would require me to write a lot more code for the parser since I just have all the math operations and optimizations macro'd in right now.  Checking for a variable would be a little tricky in that section.  But I'll try it out later if I have time.

606
ASM / Re: Running ASM programs larger than 8 KB
« on: January 04, 2011, 02:56:25 am »
Wouldn't jumps have an issue if you had to jump to a different page?  It would mean a lot of ram page swapping, wouldn't it?

Nope, if its only 2 pages, there are no other pages.  Page 1 is $4000-$7FFF and page 2 is $8000-$BFFF.  A jump to say... $9001 would simply be jp $9001.  You just have to have your orgin on page 2 to .org $8000 and .org $4000 on page 1.

607
ASM / Re: Running ASM programs larger than 8 KB
« on: January 04, 2011, 02:49:11 am »
By the way, I just though about this... you *could* run a contiguous program of 32kb on the calculator.  Its easy too.  In a 2 page app, just swap the 2nd page of the app into the $8000-$BFFF region and that's it!  Unfortunately though, you wouldn't be able to call any OS bcalls or use self modifying code, but other than that, it would work.

608
The Axe Parser Project / Re: Features Wishlist
« on: January 04, 2011, 02:24:58 am »
You can try this.  They even have pseudo code :)

609
The Axe Parser Project / Re: Features Wishlist
« on: January 04, 2011, 02:11:10 am »
@Runner, I was thinking of having "While 1" and "Repeat 0" to auto optimize to no code at all so that would take care of the Do part.  The end condition might work if I add new "EndIf" and "End!If" instructions (which only work on while/repeat loops).  It would be pretty cool too because it would mean you can have pre-check and post-check for the same loop!  Something I haven't seen yet in other languages...

@Builderboy: Very difficult.  The new algorithm has no knowledge of X and Y while drawing the line so it doesn't know when its going off-screen.  If I let it keep drawing, it continues writing to more of the screen ram causing a loop around effect and a possible crash if it goes too far off screen past the end of the L6 buffer.  Likely the next version will just draw nothing if you go off-screen as that would give a size and speed optimization and is more likely what you would want in that case.

610
Axe / Re: The Optimization Compilation
« on: January 03, 2011, 09:58:59 pm »
Only *64 and *128 are more optimized as a bunch of *2's but it will make them larger by 1 and 2 bytes respectively.  You can always look at the commands.inc file to see exactly what routines are used and how big they are.  Also, I think *256/2 is faster than *128 but that only works if the original number is between 0 to 32,767.

611
TI Z80 / Re: Axe Cuberunner
« on: January 03, 2011, 04:23:21 am »
happybobjr, try this version.  I recompiled it with a new grayscale routine that has a 59 T-state minimum delay instead of 57 and I also managed to save a byte from it.  Hopefully I won't have to delay it too much more... Also anyone else with a newer calculator let me know if this version works on your hardware.

612
TI Z80 / Re: Axe Cuberunner
« on: January 02, 2011, 05:06:08 pm »
Is the new grayscale routine causing screen glitches?  I made it faster but I'm not sure if its too fast for the LCD driver.  It works on my calculator with the bad LCD, but are other people having problems?

613
The Axe Parser Project / Re: Bug Reports
« on: January 01, 2011, 08:39:17 pm »
Thanks for all the reports.  I'm looking into all this stuff.  It's weird because most of this involves code I didn't touch since many versions ago.

614
Axe / Re: Writing to the same pointer
« on: January 01, 2011, 06:45:43 am »
Static pointers are called static pointers because they're, well... static.  Once you define them, you can't change their value.  This is because once you define something it has to be in memory somewhere.  You can't change where something is in memory without using a copy.  BUT!  Since Axe 0.4.6 you can now do this "almost" automatically by storing them to variable pointers like so:

Code: [Select]
If L=1
"Test"->A
"Stuff"->B
End
If L=2
"Blah"->A
"Dude"->B
End
Disp A,B

This works because the VALUE of the pointer can change, but the place where the data is in ram cannot (without a copy).

615
The Axe Parser Project / Re: signing apps
« on: December 31, 2010, 09:47:26 pm »
There is already a signer included with Axe under "Tools".  I made a batch file for it so its super easy to use.

Pages: 1 ... 39 40 [41] 42 43 ... 135