I've been waiting for you to show up in IRC since Friday so I could give you this routine, but since I haven't seen you yet there, here it is! It returns strings like the OS would when displaying numbers on the home screen with the Float setting. It perfectly mimics the OS routine for every reasonable input I've tried, even when using hacked float variables that have exponents above 99. The only thing it doesn't perfectly mimic is hacked floats that contain invalid hexadecimal characters. But that shouldn't happen too often.

Anyway, you said you wanted this for speed. Good news! The OS routine appears to take an average of about 5500 cycles in my tests, whereas my routine takes an average of about 1600 cycles. It'll cost you 244 bytes, but the choice is yours.

And anyone besides Hot_Dog, feel free to grab this routine as well. Note though, that because I made this routine to Hot_Dog's specifications, it has a few weird quirks. The location of the string returned has to be a constant, but you can change that. Right now it's set to OP4. You'll also probably want to get rid of the ld (hl),20 \ inc l at the start of the routine, another weird quirk Hot_Dog said he needed. Also, note that the string returned is a null-terminated string of tokens, not characters. You should be able to change this though by simply changing all the token values in the routine to ASCII values.

Hi. I don't think this has ever been properly addressed, so I would like to formally address the matter of crediting others when it comes to programming works. Although everything that follows is only my opinion and you do not need to agree with it, I would like to state it. Feel free to post responses agreeing or disagreeing with me. The first paragraph will deal with what I would deem to be general etiquette. The second paragraph will be focused on Axe.

When making a project, you may often turn to others for help. Whether it's requesting sprites, using a routine somebody created, or simply letting someone optimize some parts of it, I feel that it is courteous to recognize their help in some form. In some cases, like in the case of minor code changes or optimizations by another person, a simple thank you would suffice for their aid. If you want, you can give them a small credit in the readme for your finished program. Or if you learned some stuff about coding from a help post somebody made, you may want to shoot them a quick thanks for the guidance, but it isn't necessary to cite small amounts general programming help. But I believe that if someone contributed specific help that your game relies on, like sprites or an important routine, it is fitting to cite who contributed that important part of your finished product. No need to put their name in your program's splash screen, or necessarily in the program at all. But a thanks at the bottom of a readme, no matter how small, can mean a lot. It means the efforts this person made to help you were really helpful after all. It means the time they put aside to help, no matter how much, was time spent well and worth spending again to help others.

When it comes to Axe projects, in a lot of cases the programmer will release the Axe source with their finished work. Sometimes he or she will say that their project is an Axe project but will want to keep the source protected, which is completely fine. But what can irk me a bit is seeing programmers produce something with Axe and fail to report is as being an Axe project. On one hand, I find it a little unsettling that it isn't mentioned, possibly as if they want others to think that they wrote it in assembly. But a possible slight deception is not what I find most unsettling. What I find unsettling is that failing to recognize it as an Axe project means failing to recognize perhaps the most important part of your project's existence: Kevin Horowitz. As I stated earlier, I believe it is proper to give credit in a final product to someone who may have provided you with some graphics or some code. But what about Quigibo? He provided every routine your program uses. He provided bug fixes for problems you might have run into. He provided a documentation and command information which likely taught you a lot of the concepts and commands you know. And most importantly, he provided his time. More than a year of it, so your program could exist. And I think the least any one of us can do to repay that is give a few seconds of thanks and recognition in return.


~~~

I can never focus on one project at once and have thus never really finished and published any projects, or the readmes to go along with them. I have never had the chance to give thanks in any published projects. But I have still programmed in Axe and enjoyed it for countless hours. So I would like to be the first to officially say:

Kevin Horowitz, thank you for the work you have done. Your helpfulness and commitment to Axe have known no bounds, and neither do my thanks to you.

TL;DR: 2 modified .xml files for TI's Program Editor to convert it from a TI-BASIC into an Axe program editor.

---

I like programming for calculators on the computer for a few reasons. You have a much larger space to work with, things like copy, paste, undo, redo, etc. Also, your programs are always safe on your computer if your calculator crashes.

A lot of my calculator programming is done in Axe. Because the Axe language is based on TI-BASIC tokens and programs, I write and edit my programs with the TI-BASIC program editor called "TI Program Editor" bundled with TI-CONNECT. Unfortunately, TI decided to remove the only useful program to me from the TI-CONNECT suite, so you can't download it from TI anymore. You may or may not be able to find a download link in the description of a video from a YouTube search, though...

Anyway, I write Axe programs with this software that was intended for editing TI-BASIC programs. Because of this, it obviously lacks things like Axe token replacements and such. Even worse, it doesn't properly support some tokens like lowercase letters, making some programs impossible to open and others annoying to edit. And although it has a nice catalog of commands and calculator tokens to select from, it can be tedious to navigate it and find the Axe commands you want. Anyways, it looks like this:




It definitely has some nice features for TI-BASIC program editing:

• Tabbed file management
• Easily edit program details like the name it will be on a calculator or lock status
• The usual text editing features like cut, copy, paste
• A font specifically designed to mimic the font on the TI calculators and display special characters very nicely
• A categorized catalog of special symbols and all the functions you would find on your normal calculator, often sorted by an identical menu system
• Token hotkeys, useful for quickly entering common tokens you can't type on a keyboard

For an Axe programmer, a lot of those features are just as nice as for a TI-BASIC programmer. But the fact that it wasn't designed for Axe programming, chokes on some lowercase letters, and has a few other quirks sometimes made it difficult for me to write Axe programs on it. I could have decided to write my own Axe IDE, but I'm lazy. So I decided to just modify TI's already existing and pretty well-developed program editor. The same program you saw above with two modified source files suddenly becomes so much more Axe friendly:




Every token that displays differently in Axe has been changed to its Axe equivalent, so no more needing to look up which rotate command Shade_t() was! Commands actually make sense! And you can now simply type something like Copy( and not wonder why you get a compile error at the "o". Additionally, although the old catalog of tokens and TI-BASIC commands remains in a section called "Normal" in the command chooser, a whole new section exists just for Axe! In this section are tokens for every symbol, variable, and constant used in Axe, followed by tokens for every Axe command. And if you're familiar with the Commands.htm file included in Axe releases, it should be a piece of cake to navigate the commands because they're sorted in the same exact order. I just finished this myself so haven't been able to fully try programming with it, but I'm sure it will be a lot nicer programming in Axe with it now than without it.

---

If you have TI's Program Editor and want to test this out, I have attached a zip file containing the two modified xml files that constitute this modification. To hAxe the program, simply find the directory it exists in and replace "83PlusDictionary.xml" and "TI-83 PlusFunctionTree.tree" with the modified versions in the zip file. It may be a good idea to back up the originals first, though.

And once you've tested it out, tell me how it is!

This is a somewhat challenging routine I've been trying to develop for z80 assembly. I'm trying to find a way to multiply two signed 16-bit operands together and get a signed 32-bit result.

I already have one working method, although it's fairly hacky. Its general structure is as follows:

• Xor the high bytes of the two operands and push af
• Convert the operands into their absolute values
• Multiply these two values with the normal restoring multiplication algorithm
• Pop af and return if sign flag is unset
• Negate the result of the multiplication and return

Somehow, I get the feeling there are faster and/or more elegant solutions than this.

The most elegant solution would just be a modified restoring multiplication algorithm that deals with signed numbers correctly. After having stared down the restoring multiplication algorithm for about the past hour, I don't know how reasonable this is, though. And unless there's some simple change I'm not seeing that would suddenly make this work, any solution of this form would probably consume a lot of extra cycles in each iteration.

Something that has occurred to me as a more achievable and probably faster solution, albeit larger, consists of a test that branches into one of three different versions of the restoring multiplication algorithm. Which algorithm to use would be determined based on whether neither, one, or both of the operands are negative. This is the method I am currently trying to develop. After a bit of messing around with the restoring multiplication algorithm, though, I'm still fairly confused about how to form the two modified algorithms that would be needed.


Any ideas?

I had started work on an Axe raycaster a while ago, but forgot about it. However, squidgetx's raycaster reminded me that I had one too, so I went back to work on it. Anyways, it works pretty nicely, although somewhat slowly , and I have different versions with different features. It's pure Axe though, which is pretty awesome. I run all my versions of it at 15MHz.

Unless you want me to go into the technical details, I won't, because that stuff is pretty ugly. But screenshots are cool!

Most of what I need to do now is try to make it faster, because these are all using the full 15MHz and it would be nice to save some processing power for other things!


EDIT: Attached a zip file containing the source code and compiled executables for all four versions.

Is there such a thing? I know there are things like GetCSC and direct port input, but I'm wondering if GetKey has a non-waiting equivalent that also uses the A/keyExtend output format.

A bunch of people have been pestering me about the dysfunctionality of an old sprite editor of mine, so I'm working on it again. I plan to support masked 3-color (black, gray, and white) grayscale sprites, and I want the user to be able to see transparency. To do this I'm going to display the sprite in 4-color grayscale, with transparent being represented as one shade of gray and actual gray being the other shade. The question is, which method looks better: transparency being represented as light gray (left) or dark gray (right)? I'm torn because, to me, the option on the left better portrays the sprite being over a transparent layer, but in the option on the right, the sprite itself simply looks better.



Another image (also, sneak peak at the epicness that will be the new sprite editor - note the full filesystem - no, it's not just a mock-up):


Another, with non-Zelda sprites:

Quick question: the SDK says programs, appvars, and groups are all 14-byte VAT entries, but lists are 13 bytes. Are lists actually 14 bytes, just with the last byte not representing anything? It seems that having fixed-length entries is probably more reasonable, just trying to confirm this.