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 [2] 3 4 ... 153
The Axe Parser Project / Re: Axe Parser Grayscale
« on: January 02, 2017, 12:50:20 am »
Could you upload the program and provide a link, or paste the relevant part?

Making a guess, though, the second issue you described could be a combination of two individual issues: drawing the two parts of each sprite to the wrong (inverted) buffers, and calling DispGraphr (meant for 3-level grayscale) instead of DispGraphrr (meant for 4-level grayscale).

As for the first issue, if the "dots" aren't horrendously prominent, then that's probably just a side effect of updating the screen out of sync with its refresh rate. The closer it is to about 60Hz, which is very roughly the refresh rate of the calculator screen, generally the better the grayscale looks. You can achieve (nearly) perfect grayscale with GrayLib, but that may be overly complex if you're still just becoming familiar with the language.

The Axe Parser Project / Re: Getting Started with Axe Parser
« on: January 01, 2017, 02:21:31 pm »
Oh wait... do you actually have a plain TI-84+? If so, that's totally fine for using Axe. The TI-84+SE is just a TI-84+ with more storage, which is mostly unnecessary.

If anything, you could sell the TI-84+CSE. For hobbyist usage, it's actually less useful than the older monochrome calculators (but the newer TI-84+CE is probably better than both).

The Axe Parser Project / Re: Getting Started with Axe Parser
« on: January 01, 2017, 01:17:59 pm »
Oh boy... well this might be a bit of a bummer.

Just to verify that you actually have a TI-84+ C Silver Edition: your calculator looks like this, correct (though it may have an accent color other than black)?

Most programs/applications written for the older, monochrome TI-83+/84+, including Axe, are incompatible with the newer TI-84+ C Silver Edition (TI-84+CSE for short). The TI-84+CSE was TI's first foray into a color model in the 83+/84+ line, and not a very good one. It's more or less dead to TI, and to the community, being replaced by the newer and better TI-84+CE. The TI-84+CE has an up-and-comping on-calc compiler project similar to Axe, ICE, and has a great C toolchain (not on-calc), but the TI-84+CSE has nothing comparable.

When did you get this calculator? If you purchased it recently, I would honestly recommend attempting to return it and buying a TI-84+CE instead. If you can't do this, you're unfortunately stuck with a nice color screen but few good programs/applications to make use of it because the underlying hardware is horribly underpowered. :(

The Axe Parser Project / Re: Getting Started with Axe Parser
« on: January 01, 2017, 12:29:40 pm »
Reading the included Documentation.pdf, although it's somewhat outdated and certainly doesn't cover every language feature, is probably the best introduction to the language. I'd also recommend reading Changes.pdf, which can be found in the Axe 1.0.0 release (but don't actually use Axe 1.0.0), as it details some important language features added with that release that aren't covered in the main documentation.

After reading both of these, I would finally recommend looking through Commands.html, which is the exhaustive language feature/command list, and pick out and play with commands that interest you. This document is by far the most useful language reference, and I recommend always having it on hand while using and still learning the language. Some people just view it in their browser, some people print it out, and now, thanks to @E37, you can even view it right on your calculator (get it via the first attachment to that post,

There's also one excellent, very comprehensive Axe tutorial, but there's a slight caveat: it is written in French. Although there will be some annoying translation errors, I believe that running through it with a browser-based translation service is still the best comprehensive Axe tutorialization experience there is.

The Axe Parser Project / Re: Dynamically access variables
« on: December 13, 2016, 01:48:58 pm »
You can do this by writing the addresses of the three sprites into a buffer, yes. The code would look something like this:

Code: [Select]
However, best would be to declare the sprite data in sequence so each one's data immediately follows the next, which allows this:

Code: [Select]
other stuff here

And a suggestion: in either case, your life would be made easier by using zero-based numbering. That generally translates into simpler/more efficient code. In the first case, you could remove the -2, and in the second case, you could remove the -8.

The Axe Parser Project / Re: Bug Reports
« on: December 06, 2016, 06:11:51 pm »
Ok. I think I have found another. (I'm not sure what's causing it)
I have found that recompiling a certain app causes flash corruption. I'm not 100% sure but it has happened 2 times in a row.
It does use hooks and inline assembly but I have used similar programs without mishap.

Since I need to reset my calc anyway I figured I will try to figure out what is causing it. (I'm sure it is Axe since I haven't been using assembly recently and I have been using the same apps for a year and they never showed any problems)
Oh, and it is 1.2.2a as always.

Nothing immediately comes to mind as a possible reason for this. I think the only way I'd be able to reliably track down a bug like this would be if I could reproduce the bug in an emulator and actively debug it. However, it seems likely that your specific code and/or calculator environment may have something to do with it, as I haven't heard other reports, so reproducing it from scratch would be difficult.

Your calculator is an 84+CSE, not an 84+CE, right...?

If not, I'm afraid to say you've come all this way for nothing, as this emulator is for the 84+CSE only. Blame TI for the very confusingly similar model names.

On the plus side, the 84+CE has significantly more powerful hardware than the 84+CSE (still paltry by modern mobile device standards) and it has some pretty decent games already. No Game Boy emulator (yet?), but you may want to check out the list on

Which ROM did you guys use? I tried different GBA and GBC ROMS from different websites, and every single one doesn't work can someone suggest a ROM website to use? Many thanks  :mad: :w00t: :thumbsup:

As the first post and the readme both mention, this emulator supports only original Game Boy games. Game Boy Color and Game Boy Advance games are not supported (and due to significantly higher emulation requirements and the fact that this project and calculator model is mostly dead, likely never will be).

A suggestion of a my two favorite original Game Boy games that should work: Pokemon Red/Blue (maybe Yellow?) and Link's Awakening (not DX).

The Axe Parser Project / Re: Bug Reports
« on: September 29, 2016, 01:47:42 pm »
... And I'm back! With more bugs! As always, I am using 1.2.2a! @Runer112
The first one isn't really a bug but more of an unexpected feature. p2 found this one. Interrupts can occur in the middle of commands like Output(x,y,expr) and if that interrupt changes the location of the cursor, then the Output command will display at the end of where the interrupt left the cursor. I'm not sure if you want to do anything about it or just leave it.

I found the other bug, and it is a bug for sure. Compiling :5 and {Y1}r will compile normally, but on zoom compile it will throw error: undocumented. The five can be replaced with any number and the 'and' can be replaced with any bit-wise command (including the 2 byte plot token ones). The file must have the r after it and be the second argument. In all of the cases normal compile will not error but zoom will.

The first thing isn't a bug. It's the programmer's responsibility to ensure thread-safety. :P

The second thing, I've recorded on the to-do list and will investigate (eventually).

TI Z80 / Re: Standard RPG Game
« on: September 18, 2016, 10:15:07 pm »
This is because of Axe's weirdness of all functions sharing the same argument variables, r1-r6. Often you can fix the problem by using the "recursive" syntax that you initially tried using, but that turns out not to even help in this case. That's because argument values are saved to their respective variables immediately after they're evaluated, making code like this:

Code: [Select]
Lbl DrawChar

Really act like this:

Code: [Select]
Lbl DrawChar

As you can see, r₁ is overwritten after evaulating the first argument and r₂ is overwritten after evaluating the second argument to the Mask() call, resulting in their uses in the second and third arguments producing bad values.

Although it's rather annoying/silly, a simple way to fix this is to assign the argument variables manually like demonstrated in the code block above, but in the reverse order, so none are overwritten before their old values are done being referenced (if there were cyclical dependencies, you'd have to introduce temporary stores as well):

Code: [Select]
Lbl DrawChar

Also, because Axe is really dumb and doesn't (yet) know about the commutative properties of mathematical operators and how to optimize by switching operand order, I would recommend that you get in the habit of doing this yourself. It is almost always best to make constants the second operand, or if neither operand is a constant, try to make a simple variable the second operand. Here's the fixed code from above with this optimization applied in a couple places:

Code: [Select]
Lbl DrawChar

The Axe Parser Project / Re: Bug Reports
« on: September 17, 2016, 06:32:18 pm »
What version of Axe does this occur in?

Regardless, this bug doesn't seem too surprising, but it's mostly Axe's fault. I've made a note to fix it.

EDIT: Upon further inspection, this is zStart's fault. For some reason, it takes it upon itself to delete the output program before invoking Axe, but unlike Axe, it doesn't check if the output and input names are the same. So I'm not too concerned with any buggy behavior that stems from bad API call input.

ASM / Re: 83+/84+ Free Ram Areas
« on: August 25, 2016, 12:42:38 pm »
It seems that only happens for app bcalls (an app calling to its other pages), but I've added the information to the table in the first post.

The Axe Parser Project / Re: Bug Reports
« on: August 24, 2016, 01:20:36 pm »
The Axe application in 1.3.0 version is stable?

Definitely not. I "released" it outside of the updates thread because I expected stuff to be broken and wanted to crowdsource the bug finding process. And stuff was definitely broken, including some rather important things like backups and compilation of all but the simplest mathematical expressions.

Looks pretty neat. However, I should point out that you've somehow lost all the plus signs (not just here, on git as well).

Are floats not part of the plan? I'd be slightly disappointed if that's the case. I recognize the pain of supporting them on hardware without an FPU (or even a good ALU), but any programs involving serious math or graphics really need them.

Axe / Re: Axe Q&A
« on: August 18, 2016, 02:41:32 pm »
For many reasons, one of the largest being code origin, you cannot simply include one assembly program into another.

Provided you have access to the source of this program (which it sounds like you do), the only way I can think to legitimately include assembly code into an Axe program is to modify the assembly program into an Axiom. Depending upon the complexity of the assembly program, you may need to utilize many of the more advanced/confusing Axiom features. I'll refrain from attempting to explain them all unless it is discovered that some of them are needed.

A much simpler way is to abandon the requirement that the assembly program be included in the Axe program and simply call the assembly program from the Axe program with the RunPrgm Axiom.

Pages: 1 [2] 3 4 ... 153