But my question is, is it possible to edit the Axe Parser source code to make it compile at least a few functions from BASIC? Like, the Disp, ClrHome, ClrDraw, For(, Menu(, Pause (to an extent), and While commands are fairly similar.

It would probably be better to just write a new parser, but yes, of course. I imagine that's how Axe got started.

Now, if one were to make an ASM to Axe decompiler, that would be epic...

(you'd have to make sure that the program was actually compiled in Axe and by what version)

I should just say that the best way to see the differences between Axe and BASIC is to try them both out. Most if not all of the questions you have asked thus far could be answered by trying to write "Hello World" or "Guess the Number" in both languages.

But I did the Hello Worlds:
[code]
[Axe] [Basic]
ClrHome ClrHome
Disp "Hello, World!" Disp "Hello, World!"
Pause Pause
[\code]

And, if you compiled the Axe program and ran both the compiled Axe and the Basic, you should see that the Axe one does not compile at all, since Pause in Axe is a different command from the Pause in Basic: while the latter is a "wait for Enter" command, the former takes an argument to create a time delay. I'll leave the challenge to you to create BASIC's Pause effect in Axe (hint: it's a Repeat loop with nothing inside).

BTW, tabs don't work in the forum world. If you want to create a code listing, use [code] tags, which will put your text in a box, take all characters inside verbatim, and make it monospaced, just like code should be displayed.

Of course, the differences between Axe and Basic in the Hello Worlds are much more about the process for creating each program type. You will have a very thourough knowledge of how Basic is different from Axe once you write a Guess the Number program in both languages.

Actually, that would compile fine as an Axe program, because Axe does have a Pause command. However, Axe's Pause does not act like TI-BASIC's Pause. That code will result in the same visual appearance, but instead of waiting for a key to exit, it will wait for about 25 seconds or so and then exit. (The reason for this is a little technical)

The closest thing to TI-BASIC's Pause is Axe's getKey^r. The main difference is that the latter actually treats 2nd and alpha as modifiers, so instead of breaking out of the wait, they will cause the corresponding modifier to appear in the top right corner of the screen.

Anyways, very basic things like ClrHome, simple string displaying, some loop structures, simple math, and A-theta variable usage are about the only things I can think of that work the same (or at least they may appear to) in TI-BASIC and Axe.

Oh, kk.

Um, Axe can support boolean commands? Like, the nand, nor, nxor, xor thing?

I'm assuming you know how the boolean commands work. Axe does support the boolean commands, but they are much different (and more powerful) than BASIC's boolean commands:
- BASIC's booleans are "logical", which means that they take the numbers as a whole. In essence, 0 is treated as false, both in input and output. Any other number is reported as true when accepted as input, and true is output as 1.
- Axe's booleans, on the other hand, are "bitwise", which means that every corresponding pair of bits in the lower 8 bits of the number is evaluated by the boolean expressions, which is typically a lot more helpful for hexadecimal and binary numbers (as in sprites), or numbers that are either 0 or 1. For example:

Code:

If you want to create logical expressions in your If statements and expressions, you use different operators:

Code:


Something I should also note is that the ":" operator is not the same as a new line in Axe, as they are in BASIC. In Axe, some "end of line" commands, such as the question marks, literally jump to the end of the line, not to the next colon, allowing you to make EXPR any number of sequential expressions. You can even use this to have multiple statements in parentheses (which is especially important when using λ() ([LOG]) to create functions without naming them, like when you are passing functions in as arguments for other functions).

Wait a second....

does Axe convert the Axe source code to ASM and then it compiles it to machine code?

Axe directely converts into machine code (which is the same as asm).
Asm is often programmed as a series of instructions, but every instruction just stands in for a series of bytes in machine code. So in fact, asm is just machine code made readable for humans.

Is it possible to decompile machine code to ASM?

Yes, but label and variable names are not saved, so you would see hexadecimal numbers as pointers. Also, it's actually called disassembling.

Machine code and ASM are the exact same thing, just different ways to represent it, for the record. It's not like compiling C to ASM, where you're changing the actual instructions in use. Machine code is easy for the CPU to read, ASM is easy for humans to read.

I thought that machine code for the zilog z80 is hex code.

ASM is actually hex code?

ASM is the set of commands in a plain-text format that's easy for humans to read. Machine/hex code is the same set of commands, but expressed in the way the processor will read it (as a hex value). For example, in z80 source code, you might see "ret." The hex code equivalent for this is C9. What an assembler does is it interprets the text format and writes out the equivalent hex value of the commands. They're the exact same thing in different formats; it's just that one format is easily legible by humans, and the other is easily processed by the computer.

Asm is Hex and machine code, more or less.
Machine code is the naive language of any processor. However sending a sequence of 1s and 0s to the calculator is very criptic. What is the difference bettween 1010 1001 1110 1111 1110 1110 1101 1011 and 1010 1001 1110 1111 1111 0110 1101 1011? Not much but two bits however that is a completely different instruction. One mistakes and boom, game over. As you may know any sequnce of 4 0s and 1s can be translated into a single hexdecimal digit. Likewise, any 8 can be translated into two hex digits.

So the above translates to A9 EF EE DB and A9 EF F6 DB. Comparing the codes F6 is definely not EE. This is at least less to look at than the endless series of 1s and 0s, and makes each command more unique.

Now, someone correct me if I'm wrong but on some level, when you run an AsmPrgm on your calc in the form of...

Code:
your calculator translates the text into machine code and then runs it.

Now the only problem is that this still is slightly criptic and sometimes may seem to make no sense. The code for ld a,b is 78 Hex 0111 1000 and ld b,a is 47 Hex. Those are two are completely different. Only if one has knowledge of bit fields and op codes, which are but 1s and 0s, can one find a system to translate each command. And even if you do, you still have to translate the result into hex, all the while taking up the programmers time.

Thus, at some point, a new system to represent the hex codes was coded. if in a .z80 source file you type in

Code:


Your Assembler, not Compiler, will go though and write to another file 78 every time it sees ld b,a C9 everytime it sees ret, ld a,b 48 and so forth. This is because every command has has only one hex equilant. (with few argurable excecptions like ld a,n n being any 1 byte number or ld c,(ix+n) ) unlike lanaguages like c++.

Also labels become a huge management issue in both hex and machine code. the jumps and conditions jump jr, and djnz are actually move up or down a certain number of bytes and jp is slightly different. jr =18 n, n being the number of bytes you wish to jump. jp=C3 n, n being the two byte address you wish to jump to. djnz = 10 n same as jr. Lets say I write hex code that wants to skip some code, that if the skipied code ran my calc crashed so i write

Code:
but later you decide to add a whole new instruction in the skipied code like EF4844. The skipied code is now 3 whole bytes longer, and thus the programmer is forced to mentally keep track of all his jump instrcutions and update them everytime something changes. The same code in Asm can writien as

Code:

Now no matter what I add to the skiped code section, the assembler will keep track of the offest of the jump during assembly time.

So in short Asm is Hex which on some level is Machine code. (At least if you consider hex what you type into your calc, because technically that is a sequence of charaters which is not the machine code it represents)

Asm is the more managable version of hex and machine code
Code:

So thats what those asm<-->hex programs are for...

Theoretically, you can easily convert machine code to an asm program?

Oh, and is the machine code for the Ti-84+ hex or binary?

Theoretically, yes but define easily .



I'm not sure if your just phrasing your question wrong but machine code is always in binary, regardless of make or model (at least I am 99% sure). If your asking if you can type binary into the calc the answer is technically no,not by normal means anyway, BUT you can write a hex program on the calc and convert directly to machine code as opposed to a string of characters. Unfortunately you cannot edit a machine code file, but it will be a smaller program than it's hex counter-part.

If I write a hex program called DISPHL1 in the BASIC editor

Code:

then on the home screen ran the the line
AsmComp(prgmDISPHL1,prgmDISPHL)
The calculator will make a new program named DISPHL and it will be pure machine code. Naturally you still need the Asm( token to run prgmDISPHL.
On my TI-83+ sliver edition the hex version is 27 bytes while the binary version is 21 bytes. Note that this memory count includes each letter in the name using one byte per character.

And other than for practice, you may not need to know this at all. There are many assemblers, even on calc assemblers like Mimas. however very few assemble them into hex code, as they either assemble it directly into machine code or they simply run the AsmComp(. Early versions of the OTBP on calc assembler, which primary uses basic to assemble, does output a hex file, plus all the data into an on-calc Str(n)

The problem with machine code is that you lose what little semantic structure there was left. On many platforms it is very hard to differentiate between data and code unless the binary executable format explicitly separates them, and all of the label names are lost. Disassemblers do their best, but it is unlikely to be as organized as it was to begin with.