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 - Runer112

Pages: 1 ... 3 4 [5] 6 7 ... 153
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 20, 2016, 11:46:36 am »
This is because text entry on the home screen is implemented using an edit buffer. An edit buffer expands the edited variable to consume all free user RAM to ensure that no expansion or mass data movement needs to occur while editing, which could cause noticeable slowdowns.

The most straightforward solution would be to close the edit buffer, create whatever variables you need to create, and then reopen the edit buffer. The trickiest part would be reopening it to the same location, which frankly I haven't done enough with edit buffers to confidently say I know how to do. At the very least, in case you didn't know, I can tell you that the name of the homescreen entry variable is "prgm!".

Axe / Re: Quick Grayscale Tutorial
« on: March 08, 2016, 01:39:44 pm »
@nabako As you may be able to tell by your post's weird formatting, "[sub]" is the forum's opening tag for subscript text. However, I believe you may have misread what actually said "[sup]", which is the forum's opening tag for superscript text.

Neither of these tags work in code boxes, though, which the author of the original post didn't seem to realize. So I'm guessing you're really wondering about "[sup]r[/sup]", which is supposed to represent a superscript "r". On the calculator, this is the radians token, found in the angle (2nd + apps) menu.

Axe / Re: Axe Q&A
« on: March 07, 2016, 11:17:26 pm »
I'm not quite sure I understand what you're aiming to do with these tokens. But you can definitely reference any token in Axe, as tokens are just one- or two-byte values, and you can display them with the ▶Tok variant of the text display commands.

Most characters do exist as a token, although the cursor and all of its variants are among those that do not.

Axe / Re: Axe Application transfering
« on: February 24, 2016, 01:46:19 pm »
Axe can compile the application's code just fine, but it can't calculate the signature, which requires a relatively complicated cryptographic procedure. And calculators check this cryptographic signature when receiving an application and reject the application if the signature is wrong.

However, you can still send the application to a computer. As pimathbraniac mentioned, you need to sign the application on a computer. But (as long as you're on Windows) rather than grabbing the signing program and using it manually, you may find it easier to check out the "Tools\Application Signing" folder in your (extracted) Axe download. As the name of "Drag App Over Me.bat" suggests, just drag and drop the application (.8xk) file onto this to sign it.

TI Z80 / Re: Yahtzee, Axe edition RC 1
« on: February 08, 2016, 11:45:41 pm »
Can I then store getKey to a variable? Like 
Code: [Select]
EndIf getKey->G

Of course.

TI Z80 / Re: Yahtzee, Axe edition RC 1
« on: February 08, 2016, 09:26:40 pm »
And your loop should more or less get turned into that asm code, i'm not familiar with Axe but in your program try pressing [2nd]+[On]. You'll exit your program and the RAM your program occupied won't be freed (a massive RAM leak).

This should not happen, as Axe uses _GetKeyRetOff, which returns kOff rather than actually shutting off the calculator.

However, I agree that it's better to go with a _GetCSC loop in a case like this. Which, in Axe, simply translates to While 1 : EndIf getKey. If interrupt are enabled (which you can do with FnOn), put a Stop in the loop to save battery, too!

TI Z80 / Re: Yahtzee, Axe edition bugs
« on: February 04, 2016, 08:48:29 am »
Here I have enclosed the source file and executable file for the Yahtzee game. Current untraceable bugs:

1. Saferam L1 not clearing after a Fill(), a looped zero, and other means of zero-ing the data

I stepped through both instances of Fill(L1,...) in a debugger, and both are behaving correctly. If there's any unexpected data there after this, you must be putting it there. :P

The Axe Parser Project / Re: Features Wishlist
« on: January 17, 2016, 03:27:59 pm »
The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.

The Bitmap() command does this.

The option to run the program right after compile whithout having to go back to the home screen would be nice.

Sounds like a good idea.

Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.

Also a good idea, although it turns out to be a bit tricky to implement this. But I can look into it.

Axe could check if the program is the same before backing it up.

Another good idea.

If you attempt to run a source code file it could compile then run.

This would require a parser hook, which would clash with any other parser hook used to implement running programs from the home screen or hybrid BASIC libraries, and would make all BASIC programs slightly slower. So this isn't worth it. However, this functionality would fit well into any apps that already provide such hooks, like zStart or DoorsCS.

A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2

This shouldn't really be the job of a drawing comamnd, and it wouldn't really be any more optimal to include the functionality built-in. The user's code should make such adjustments.

The ability to write bytes directly to archive would be neat.

This is, for mostly all intents and purposes, not possible. Additionally, I'm not comfortable giving user code the ability to, whether intentionally or accidentally, destroy archived data or the OS— or if something went horribly wrong, the boot code, which would brick the calculator.

Add Memkit!!!

Yes, this should really be done. It could never fit before, but with all the optimizations that 1.3.0 brought, it might fit now.

Pause until something happens, like pause until the enter key is pressed.

Adding a built-in just for this would be entering the realm of feature creep. This can be done very easily in user code: Repeat <something> : End.

A command like Stop that makes the program quit rather than overflow an array.

I don't understand what the "overflow an array" bit has to do with this, but if I'm understanding correctly otherwise, the Returnr command does this.

The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)

Libraries coded in Axe should be just that: coded in Axe. This provides many benefits, including the ability to easily see/modify the source if necessary and receiving the benefit of future compiler optimizations. If you're interested in particular features of the axiom system that are unavailable to Axe programs, you should request those directly.

As for compiling as an appvar, I can probably make an appvar compile target.

Maybe more areas of free RAM?

There aren't really many sizable areas of "free" RAM remaining. The fact that there were 6 decent sections and that there are 6 numbered list variables was a rather happy outcome that will probably remain that way.

If you want to search for more RAM to use, consider checking out thepenguin77's list.

Larger apps?

Multi-page app development is hard enough in assembly when you have full control of paging. Coming up with a relatively painless way to provide multi-page app development to Axe code is even harder. I've brainstormed approaches in the past, but never came up with a satisfactory approach.

Draw text to different buffers.

The fact that text can only be drawn to the main buffer is a limitation of the OS's text drawing routines. Trying to replicate said routines would involve a number of obstacles that (from my perspective) simply aren't worth dealing with.

Make the Line( command show up even when one end is off the screen.

This request has been around for a long time, and it's definitely one that deserves to be implemented. But implementing it in a complete and relatively optimal manner is rather daunting and I haven't (nor has anyone else) been able to do so.

A feature for a 2-dimensional list (matrix) would also be useful.

Considering 1-dimensional lists don't even exist in Axe, this is a bit of a stretch. Implementing such constructs (properly) would really require a type system, which Axe doesn't have. Such features are the kind of things I'd imagine in an Axe 2.0, but I don't see that becoming reality right now.

These are just some ideas I don't know how may are possible or feasable.

I'm grateful for all your suggestions. It's nice to see that some people are still interested in making Axe better. :)

Axe / Re: Axe tutorial
« on: January 17, 2016, 12:17:53 pm »
I think that on the Getcalc( command it should specify what files are. (instead of saying file it should say file Y0 -Y9)

You're right, information about files is lacking from the command list. I've made a note to add such information.

I think that {ptr -2}r should also be included in some way.

Yes, this should probably be mentioned in the GetCalc() documentation. Noted.

Possibly you could say that Buff(5) is the same as Data(0,0,0,0,0). I thought that Buff( could only be used for screen buffers and if you needed to add 500 bytes of program memory you had to do Data(0,0,0,0,0,0,0,...

Considering that Buff() is in the Data and Storage section rather than the Screen and Buffer section and that it doesn't suggest that it can only be used for screen buffers, I think it should be clear enough as-is. A buffer is simply a data storage area. Note that, throughout the command list, all references to a "buffer" that imply a screen buffer include some kind of qualifier, such as "main," "back," or "768 byte."

I might reword it slightly, but I don't want to be verbose in what should be a succinct command list.

Axe / Re: Axe tutorial
« on: January 17, 2016, 11:39:14 am »
Hey Runner can I modify the Axe command list to make it a little clearer (like changing corrupts to modify in the free RAM section)

If you have suggestions to make the command list better, I can simply include them in the official version for whenever 1.3.0 is really released. But yes, I agree that the "corrupt" wording is weird, and I'll fix it for 1.3.0.

EDIT: As a side note, if you have other suggestions like this, perhaps the general Axe Parser thread would be the place to make them.

Axe / Re: Axe tutorial
« on: January 16, 2016, 09:31:24 pm »
There's a fantastic Axe tutorial, written by @kindermoumoute,@Matrefeytontias, and @nikitouzz, that's really detailed and pretty up-to-date. There's just one slight hitch: it's written in French. But I've always thought that, if someone were to translate it to English, it could easily serve as the definitive general Axe tutorial.

Axe / Re: Axe Q&A
« on: January 12, 2016, 05:02:55 pm »
Is there a way to re-size an appvar? I was hoping to just use x -> {ptr-2}r but that didn't work.
(I know about making a new one and copying, but My appvar can get bigger than half of max RAM)

In pure Axe, not really.

I may wind up using memkit...

Probably a good idea. MemKit's functions like should really be Axe built-ins, but for whatever reason, it's always hung around as an axiom.

The Axe Parser Project / Re: Axe Parser
« on: January 11, 2016, 08:27:59 pm »
Hey Runner, I know you are busy but how much time do you think it will take to finish Axe 1.3.0?

I'm not sure... there's probably not a ton of work to do, but I have very little free time lately. :-\

Considering the developer is still active, he definitely seems like the person to approach with ideas, not me. :P

BTW, Runer112, do you think you have time to work your magic on Robot Wars?

What's Robot Wars? Searching, I could only find a TI-86 game, and a TI-82 game named Robot War.

Pages: 1 ... 3 4 [5] 6 7 ... 153