Edited my post for port 3A. It reads as 0F on my calc, so it's different from everybody else's results so far. Although that's not the only thing different about my calculator compared to the other calculators tested so far.

actually, i have a question to ask as well. which is more optimised?

Code: [Select]

if getkey(3)
+x->x
end
or

Code: [Select]

if getkey(3)
x++
end
the ++ and -- commands are a bit new, so i'm not sure how to go about using them yet. is there a difference in Inc vs. add in the way these are compiled?

The second one is more optimized, 7 bytes and 38 cycles versus 8 bytes and 47 cycles. And as calc84maniac said, for 16-bit variables V++ is exactly the same as V+1→V.

---

Back on topic, here's the most optimized code I could produce. It's 90 bytes versus the original code's 142 bytes. It will look a little messy, but that's to be expected of very optimized code. Also, when the user presses the left and right keys or up and down keys at the same time, instead of moving in one of the directions, you simply do not move. Hopefully this is an acceptable change. If not, tell me and I'll try to produce some slightly less optimized code that accounts for this. This code also assumes that you haven't reallocated the Axe variables. If you have, change the blank #Realloc() on each of the first two lines to point to that reallocated section.

min(getKey(1)#Realloc(38+L₁)+A#Realloc()-getKey(4)sub(CN1)-1,48)→{38+L₁}ʳ
min(getKey(3)#Realloc(36+L₁)+A#Realloc()-getKey(2)sub(CN1)-1,64)→{36+L₁}ʳ

.Correct negative 1
Lbl CN1
ReturnIf +1
+1
Return


Quote from: Quigibo on July 08, 2011, 02:43:17 pm

Map(λ(r₁²),L₁,100)

I have couple remarks on that
First of all, since we will presumably be able to make routines such as Map( ourselves, could you show us the syntax for calling a subroutine by address? (Something like sub(r₁, ...)^r, perhaps? (Where r₁ is any expression))
Secondly, will inlining be supported? (In general, not just for Map() That is, if an anonymous subroutine (or lambda, whatever you want to call them) is passed to a routine and that routine has a call for it exactly once, will the compiler replace the call with the routine itself? Otherwise, your example, among other useful invocations, will be much slower than it should be.

To answer your first question, you'll probably want to call most functions with a label name, like Map(ARGS). However, you will now be able to call arbitrary addresses as well with (ADDRESS)(ARGS); (ADDRESS) is like a stand-in for the name of the function.

To answer your second question, the point of passing anonymous subroutines to functions as pointers is so you can pass any routine's pointer. The compiler will have no idea if a certain routine of yours is only ever going to be called with a pointer to one external function. If you're only going to pass one external function into your function, then you should just incorporate the first inside of the second.

On the sample video, I like the top-left one, Relative - Threshold, best. The ones with dithering, in the right column, continuously show horrible pixel jitter. It would probably look less bad on a real calculator than on the emulator, but some kinds of lighting will reveal the jitter and video quality will suck.

I was a little worried about that myself, but I'd like to see how it looks on a real calculator first. And if it does look too jittery, he can try using positioned dithering instead. That would drastically reduce any jitter, while hopefully still maintaining a decent looking video.

Change anywhere I said "x squared plus y squared" to "x squared plus y, squared." The comma is important to include I guess.

As far as I know, the only finished and released Mario games were written in z80 assembly, not Axe. So it sounds like you don't want an Axe disassembler, just a regular z80 disassembler.

However, unless the author of a program explicitly tells you that you can use their code in your own project, do not use their code. Even if it's not illegal, more importantly it's just not right.

I know I've been majorly ninja'd and you already have a working solution, but I'll post this anyways. I tried to go a lot more in depth of explaining how objects and data work in Axe, and how to properly manipulate them.

---

An important thing to remember about Axe is that the only data type it directly operates on is a 16-bit integer. In languages like TI-BASIC, something like :"HELLO" actually makes the last entry that string. However, in Axe, :"HELLO" will make the last entry a pointer to that string, which is stored inside of your program. This is because it cannot fit the whole string into its 16-bit data type, so it instead stores a 16-bit reference that tells where the real string is stored.


This means a few things. Most importantly for you, it means that Zeros(36)→{L₁} isn't actually storing the 36-byte object to {L₁}, it's storing a pointer to the object to {L₁}. And because there is no 2-byte ^r modifier after the closing brace, it's actually only storing the low byte (8 bits) of the pointer to {L₁}. But this is relatively unimportant, since either 8 or 16 bits of the pointer is not what you want.


Because using → to store objects doesn't cut it, we want to use some commands specific to blocks of data. If you wanted to put a block of data at L₁, you would first need to define the data in your program. Then, you can move that data from your program to L₁ using the Copy() command. This is found under MATH ► CPX ► 1. Here is how you would create 36 bytes of zeros in your program and then move them to L₁:

Zeros(36)→GDB0Z      .Add 36 bytes of zeros to the program and store a pointer to it in GDB0Z
Copy(GDB0Z,L₁,36)    .Copy 36 bytes of data starting at GDB0Z to L1


In most circumstances when you want to move data to an external location, the code above is the way to go. However, when you want to fill a location with one value, there's a slightly better way to go: the Fill() command. This is found under LIST ► OPS ► 4.You feed this a pointer and a size, and then it copies the byte pointed to ahead [size] times. Take note that because it copies the already existing byte [size] times, you'll be left with [size]+1 bytes. So as graphmastur posted, you would want to do this:

0→{L₁}         .Give the fill a seed value of 0 to copy forwards
Fill(L₁,35)    .Copy the value pointed to by L₁ (which is 0) ahead for 35 bytes


Finally, the optimized code! It uses some tricks that I've picked up from extensive experience with Axe and is 2 bytes smaller and a tiny bit faster. You don't need to know these tricks, but after enough practice with Axe you may pick up such tricks on your own.

and 0→{L₁}ʳ    .Give the fill a seed value of 0 to copy forwards
Fill(L₁,35)    .Copy the value pointed to by L₁ (which is 0) ahead for 35 bytes


Sure, I'm not really doing anything with the engine so you can use it if you like. My only request is that if you use this engine, you credit me for my hard work making it.